If you just want to access your company\u2019s machine running your code from home, or connect to your home NAS from your phone while you\u2019re out and about, Tailscale is probably the most hassle-free option available right now. Install it, log in, and you\u2019re good to go\u2014all in less than five minutes.<\/p>\n
But if you plan to use it as a high-traffic relay within China, or expect the free version to run stably at full bandwidth indefinitely, you\u2019d better adjust your expectations first. This tool\u2019s real strength lies in \u201dallowing a few devices to find each other, connecting directly whenever possible, and using the relay as a fallback when direct connections aren\u2019t available\u201d\u2014it\u2019s not meant to replace that FRP server you\u2019ve been running for three years.<\/p>\n
Here are my honest thoughts after using it for over half a year, along with a few pitfalls I\u2019ve run into. I\u2019m not here to hype it up or bash it\u2014after reading this, you should be able to decide for yourself whether it\u2019s right for you.<\/p>\n
First, I\u2019ll list a few common options available on the market so you don\u2019t have to keep looking them up. I\u2019ll explain which ones are best suited for whom, rather than simply ranking them by quality.<\/p>\n
FRP<\/strong> This is a tried-and-true solution. The principle is straightforward: you need a VPS with a public IP address to act as a relay; internal machines connect to it, and external users access your network through the VPS. It\u2019s the most stable option, and speed is the most controllable, since all traffic passes through your own server. The trade-off is that you have to maintain a VPS\u2014even a cheap one costs several dozen yuan a month\u2014and handle its upkeep yourself. This approach is suitable for those who are willing to tinker, demand high stability, and have significant traffic.<\/p>\n Cloudflare Tunnel<\/strong> This takes a different approach. You don\u2019t need to buy a VPS; Cloudflare provides a free tunnel that comes with its own domain and HTTPS certificate. The setup is ridiculously simple\u2014it\u2019s up and running with just one Docker command. However, its servers are all located overseas, so latency from within China is relatively high, connections occasionally drop, and it doesn\u2019t support UDP. If you just want to expose a web service for a client demo or share a file with a friend, this is the most hassle-free option. However, if you plan to use it for online gaming or remote desktop access, the experience will be subpar.<\/p>\n ZeroTier<\/strong> Similar to Tailscale, it brings scattered devices into a virtual local area network. ZeroTier has been around longer and has a larger user base in China. The problem is that its root servers are often unreachable from within China, and reconnecting after a disconnection is slow\u2014so the user experience can be a bit hit-or-miss.<\/p>\n Tailscale<\/strong> Based on WireGuard, it uses peer-to-peer encryption at the core. It first attempts to establish a direct connection (P2P) between two devices; if successful, it connects directly, with speeds approaching those of a bare-metal network. If that fails, it falls back to a relay server (DERP) for forwarding. It has a lower configuration barrier than the others mentioned above, with clients available for Windows, Mac, Linux, Android, and iOS\u2014simply install and log in.<\/p>\n These four aren\u2019t interchangeable; it\u2019s more like each has its own specific role. At home, I use Tailscale to connect my everyday devices, while at work, I have an FRP server set up as a dedicated relay, and I use Cloudflare Tunnel for ad-hoc demos. Mixing them all actually works best for me.<\/p>\n Once you've installed the client and logged in with your GitHub or Google account, your device will be connected to the network. Each machine will be assigned a static IP address in the 100.x.x.x range. From then on, you can access it directly using that IP address\u2014no need to remember a port or configure a domain name.<\/p>\n There are two types of everyday experiences.<\/p>\n When both devices are on the same local area network, or when network conditions are good enough to allow a direct P2P connection, the speed is essentially at the raw network level. When I access my home NAS from work, file transfers can reach over 30 MB\/s\u2014it\u2019s almost no different from doing it locally. The latency for an SSH connection to the server is only about ten milliseconds, which is much smoother than those commercial remote desktop tools.<\/p>\n The problem is when the P2P connection fails. Tailscale automatically falls back to the official relay node (DERP) for forwarding. Most of the official DERP nodes are located overseas, so latency when connecting from within China can skyrocket to 100 or 200 milliseconds, and bandwidth is also limited. Under these conditions, remote desktop connections will be choppy, and transferring large files is out of the question.<\/p>\n There\u2019s one limitation to keep in mind with the free version: each account is limited to 100 devices and 3 users. This is more than enough for individuals and small teams; if you\u2019re actually dealing with hundreds of devices, you should have already considered upgrading to a paid plan or setting up your own system.<\/p>\n Suppose you have a Linux server at home and a laptop outside the home, and you want to connect them to the same network.<\/p>\n First, install the client on both machines. On Linux, this is usually done with a single command:<\/p>\n For Windows and Mac, go directly to the official website to download the installer. It's also available in the respective app stores for mobile devices.<\/p>\n Step 2: Run Step 3: Take If you want your laptop outside your home to be able to access your entire home LAN (not just the server running Tailscale), you'll need to enable subnet routing on the server:<\/p>\n Replace the subnet with your actual home network subnet. Then, in the device settings of your Tailscale dashboard, approve the subnet route for this device. Many people forget this step, which results in them being unable to access other devices on the internal network\u2014and they end up thinking their configuration is wrong.<\/p>\n What should I do if the relay is too slow?<\/strong> High latency with official DERP within China is a major drawback. The solution is to set up your own domestic relay node on a VPS with a public IP address. Once set up, devices that can\u2019t connect via P2P will route through your own relay, reducing latency to just a few dozen milliseconds. The configuration isn\u2019t too difficult\u2014there are ready-made Docker images available online\u2014but be sure to open the corresponding ports (typically 3478\/UDP and a custom TCP port), as cloud service providers\u2019 security groups often don\u2019t include them by default.<\/p>\n Subnet routing is not working.<\/strong> In 90% of cases, it\u2019s because you forgot to approve it in the admin console. Tailscale\u2019s security policy requires that even if you\u2019ve advertised a subnet, it won\u2019t take effect until an administrator explicitly approves it. Go to the admin console, find that device, and simply click \u201cAllow\u201d in the routing settings.<\/p>\n The device occasionally loses its connection and does not reconnect.<\/strong> This issue is commonly seen on clients running on OpenWrt routers or on laptops that have been woken from sleep mode. Usually, simply restarting the service will resolve it. If you want a permanent solution, setting Tailscale to start automatically at boot and adding a script to periodically check the connection (restarting the service if the ping fails) can save you a lot of trouble.<\/p>\n Confusion over ACL permissions.<\/strong> By default, all devices on the same network can access each other. As the number of devices increases, you may want to restrict certain machines to one-way access. Tailscale\u2019s ACLs are written in JSON; the rules aren\u2019t particularly complex, but it\u2019s easy to get tripped up when configuring them for the first time. We recommend starting with the simplest rule\u2014\u201dallow all\u201d\u2014and tightening the restrictions once everything is working properly.<\/p>\n Having talked so much about the benefits, I should also mention the situations where it isn\u2019t suitable, so you don\u2019t end up spending a lot of time on it only to realize you\u2019re heading in the wrong direction.<\/p>\n If what you're going to do isFixed, High-Volume Transshipment<\/strong>\u2014For example, if you\u2019re consistently transferring dozens of gigabytes of backups every day or streaming video surveillance feeds\u2014then FRP paired with a reliable VPS is a better fit. Tailscale\u2019s strengths lie in its flexibility and convenience, not in handling high-traffic relaying; plus, once you go through DERP, you don\u2019t have full control over bandwidth or stability.<\/p>\n If youExpose only one HTTP service<\/strong>For external use\u2014such as giving a client a quick demo\u2014Cloudflare Tunnel is more convenient than Tailscale. It comes with its own domain and certificate, so you don\u2019t need the other party to install a client; you just send them a link.<\/p>\n If youPursuing Complete Autonomy and Control<\/strong>If you don\u2019t even want to entrust your account system to Tailscale, you might want to check out Headscale. It\u2019s an open-source control plane implementation of the Tailscale protocol. Set it up yourself\u2014the client remains unchanged, and you retain full control. The configuration is a bit more involved, so it\u2019s best suited for tech-savvy people with a penchant for perfection.<\/p>\n There\u2019s no silver bullet when it comes to bypassing corporate firewalls. I\u2019ve seen too many people spend half a year chasing after the \u201dperfect solution,\u201d only to find that their needs could have been met with just an FRP or a Cloudflare Tunnel. I\u2019ve also seen people who clearly just needed to remotely connect two computers, but insisted on setting up a complicated VPN tunnel instead.<\/p>\n Tailscale's value lies in making it as easy as possible for a few devices to find each other. It doesn't solve every problem, but for the specific issues it addresses, it currently works best.<\/p>\n My advice is this: Start by trying the free version for a week and add all the devices you need to connect to on a daily basis. Once everything is running smoothly, decide whether to set up your own DERP, upgrade to Headscale, or add an FRP based on the actual bottlenecks you encounter. Don\u2019t try to do everything at once right from the start\u2014that\u2019s just asking for trouble.<\/p>","protected":false},"excerpt":{"rendered":" Let me start with the conclusion: If you just want to access your company\u2019s \u2026 from home\u2026 <\/p>\nWhat's Tailscale actually like to use?<\/h2>\n
Build One from Scratch\u2014Up and Running in Three Steps<\/h2>\n
curl -fsSL https:\/\/tailscale.com\/install.sh | sh<\/code><\/p>\nscale up<\/code>, a browser window will pop up asking you to log in and grant authorization. If you log in to all devices with the same account, they will automatically join the same network.<\/p>\nTailscale Status<\/code> Take a look at the connection status. You'll see each device's IP address and whether it's currently connected directly or via a relay. At this point, the two machines can already ping each other.<\/p>\ntailscale up --advertise-routes=192.168.1.0\/24<\/code><\/p>\nA Few Pitfalls I've Actually Run Into<\/h2>\n
When I Don't Recommend Using Tailscale<\/h2>\n
A Few Final Words of Honesty<\/h2>\n