作者： Matt Connor
Tailscale 在中国能用吗：分三层排查
Tailscale 在中国大陆能不能用，要分三层看：控制服务器登录、点对点直连、DERP 中继。每层给出对应的症状、该看哪条命令的输出，以及自建 DERP 与 Headscale 两条长期方案。
Tailscale 在中国能用吗
Tailscale 在中国大陆能不能用，答案不是一个「能」或「不能」，而要看三条互相独立的链路各自是否通。第一条：客户端能不能连上 Tailscale 的控制服务器，也就是登录和同步节点列表。第二条：两台设备之间能不能打通点对点直连。第三条：直连失败退回 DERP 中继之后，那个中继连得上吗，够快吗。三条链路的症状不同，原因不同,修法也不同。很多人在第一条就卡住，却以为是第二条的问题，于是花几个小时调防火墙和端口，白费功夫。
下面的内容是诊断方法，不是某个域名或某个节点「通不通」的结论。同一个账号、同一份配置，换一个省、换一家运营商、或者过一周，结果可以完全不一样。所以你要学会的是看自己这条线路此刻的数据，而不是记住别人的结论。
如果你还不清楚 Tailscale 的角色分工，先看 Tailscale 是什么，控制平面和数据平面各管什么。这里只补一句必要的背景：Tailscale 的数据面是 WireGuard 加密隧道，直接在两台设备之间跑；控制面只负责登录、下发公钥和节点信息，不碰你的数据。这就是为什么第一层和后两层会分开坏。
第一层：登录能不能连上控制服务器
客户端启动后做的第一件事是连控制服务器（control plane，控制平面），完成登录、取回节点列表和公钥。截至 2026 年 9 月,官方文档列出的域名包括 controlplane.tailscale.com、login.tailscale.com 和 log.tailscale.com，全部走 TCP 443 上的 HTTPS（HTTP over TLS，传输层安全协议）。
典型症状：tailscale up 打印出授权链接，但浏览器打不开那个页面；或者网页授权成功了，命令行却一直停在等待状态不返回。
先把 DNS（域名系统）解析和 TCP/TLS 连接分开看，这是两种完全不同的故障：
dig +short controlplane.tailscale.com
curl -sv --max-time 8 https://controlplane.tailscale.com 2>&1 | tail -n 20怎么读结果：
dig什么都不返回，或者返回的地址明显不对，说明解析这一步就没拿到正确答案，问题在 DNS 而不在 Tailscale。dig正常，curl输出停在Connected to ...之后、TLS handshake阶段超时或者报Connection reset by peer，说明 TCP 连上了但 TLS 握手没完成。curl返回了任何 HTTP 状态码，哪怕是 404，都说明这一层是通的：TLS 握手成功了，服务器回了话。这时候登录问题在别处，去看守护进程日志。
Linux 上日志在 systemd 里：
sudo journalctl -u tailscaled -n 50 --no-pager反复出现 dial 控制服务器失败、超时或被重置的行，说明第一层不通。这一层不通的时候，后面两层根本轮不到发生，因为客户端连对端的公钥都还没拿到。
做一次对照实验，比读任何攻略都有用：同一台机器，换手机热点或者换另一家宽带，再跑一次 tailscale up。换线路就能登录，说明变量是线路，不是你的配置。两条线路都登录不上，再回头查本机的代理环境变量、系统时间和证书。系统时间偏差过大也会让 TLS 握手失败，这一点经常被忽略。
第二层：有没有打通点对点直连
登录成功之后，Tailscale 会尝试让两台设备直连。这一步要穿过 NAT（network address translation，网络地址转换）。客户端用 STUN（session traversal utilities for NAT）向公网服务器问「你看到我的地址和端口是多少」，默认走 UDP 3478；WireGuard 直连隧道默认用 UDP 41641 作为源端口。
先看连接类型：
tailscale status输出里每一行末尾会告诉你走的是哪条路：
100.113.160.82 vps-tokyo you@ linux active; direct 203.0.113.15:41641
100.104.93.78 laptop you@ linux active; relay "tok"direct 后面跟着对端的公网地址和端口，表示已经直连。relay "tok" 表示这条连接在走 DERP 中继，tok 是中继所在的区域代码，你看到的代码取决于你落到哪个区域。
再看本机的网络条件：
tailscale netcheck下面是输出的格式示例，数值和区域列表跟你的一定不同：
Report:
* UDP: true
* IPv4: yes, 203.0.113.45:41641
* IPv6: no
* MappingVariesByDestIP: true
* PortMapping:
* Nearest DERP: Tokyo
* DERP latency:
- tok: 82.4ms (Tokyo)
- sin: 121.7ms (Singapore)
- sfo: 168.2ms (San Francisco)三个字段决定了直连的希望有多大。UDP: false 表示这条线路上 UDP 出不去，直连基本没戏，所有流量都会落到中继。MappingVariesByDestIP: true 表示你的出口 NAT 对不同目标用不同的映射端口，这就是通常说的对称 NAT，打洞成功率很低。IPv4 那行显示的地址如果和你在网页上查到的公网地址不是一回事，说明你在运营商级 NAT（CGNAT，carrier grade NAT）后面，家宽没有独立的公网地址，这在国内的家庭宽带上很常见。
想确认是不是暂时性的，让它一直试到直连为止：
tailscale ping --until-direct --timeout=30s vps-tokyo输出先是 via DERP(tok)，随后变成 via 203.0.113.15:41641，就是打洞成功的样子。一直停留在 via DERP(...)，说明这一层没通。中继延迟高和直连打不通是两个不同的问题，容易混在一起看，区分办法和调优方向在 直连与中继的差别以及怎么判断自己走的是哪一条 里写得更细。
有一个好消息：只要有一端有稳定的公网地址和可达的 UDP 端口，直连的成功率就高得多。你的 VPS 通常就是这一端。所以在 VPS 的安全组和防火墙上放通 UDP 41641 入站，是性价比最高的一步。
第三层：走 DERP 中继时，中继是否可用
DERP（designated encrypted relay for packets）是 Tailscale 的中继协议，跑在 TCP 443 上。中继转发的是已经加密的 WireGuard 报文，中继本身看不到明文，所以退回中继不会降低加密强度，降低的是延迟和吞吐。
判断方法还是 tailscale netcheck 的 DERP latency 那一段：
- 所有区域都没有数值，或者整段为空，说明这一层在你当前线路上也没有建立。
- 最近的区域延迟在 200ms 以上，或者每次跑出来的数字跳动很大，说明能连但体验会很差：SSH 打字有明显延迟，文件传输速度上不去。
- 数值稳定且最近区域在 100ms 以内，那么中继是可用的，剩下的事情是提升直连比例。
不要把某一次结果写成「某个节点被封了」。跨境链路的表现随运营商、省份、时段变化，你今天测到的超时明天可能消失。把输出存成文件，换线路再测一次，用对照来判断，这比任何一次单点测量都可靠。
为什么昨天能用，今天不行
状态会变，配置没变也会变。所以出问题的时候不要先动配置，先按顺序确认是哪一层坏了：登录通不通，tailscale status 显示 direct 还是 relay，netcheck 里中继延迟有没有数值。顺序错了就会在好的那一层上浪费时间。
留一份基线数据，出问题时才有对比：
tailscale netcheck > netcheck-$(date +%F-%H%M).txt
tailscale status --json > status-$(date +%F-%H%M).json
tailscale bugreport --diagnose前两条是给你自己看的，第三条生成一串诊断标识，是提交问题给官方时用的。
两个能长期解决问题的办法
自建 DERP 中继。在境外 VPS 上跑官方的 derper，再把它写进 tailnet 策略文件的 derpMap 字段，你的设备就会用自己的中继，而不是公共中继。官方装法是用 Go 工具链执行 go install tailscale.com/cmd/derper@latest，然后 sudo derper --hostname=derp.example.com，需要放通 TCP 80、TCP 443 和 UDP 3478；策略文件里加上 "OmitDefaultRegions": true 就只用你自己的区域。这条路的成败几乎全看 VPS 的线路质量，机器怎么挑、境外还是境内、取舍在哪，见 境外 VPS 与境内 VPS 的取舍。
自建控制服务器。Headscale 是 Tailscale 控制服务器的开源实现，部署之后客户端用 tailscale up --login-server=https://headscale.example.com 登录，第一层就不再依赖官方的控制服务器。代价是账号、密钥、升级和备份都归你维护，出问题也没有官方支持。部署步骤和运维细节见 自建 Headscale 控制服务器。
先修哪个，取决于哪一层坏了。登录本身就连不上，先做 Headscale；登录正常但中继慢，先做 DERP。两个都做完还是不通，说明这条线路上 TCP 443 的跨境连接本身不稳定，那就不是 Tailscale 能解决的问题了，换一类工具的思路在 线路不稳定时还能跑什么。
法规位置，以及这套东西做什么、不做什么
在中国，跨境 VPN 属于需要许可的电信业务，未经批准向他人提供跨境 VPN 服务是违规的。这里讨论的是另一件事：把你自己的设备连到你自己的服务器，一台笔记本、一台 VPS、一台放在家里的机器，组成一个只有你的设备能加入的私有网络。这不是规避网络管理的教程，也不涉及任何绕过手段。
它做的事：在你的设备之间建立加密隧道，让 SSH、数据库和内部后台不必暴露在公网端口上。它不做的事：它不提供匿名，控制服务器知道哪些设备属于你的网络；它也不承诺任何跨境链路的可用性。如果你把 VPS 设成出口节点，流量会从那台 VPS 出去，这一步的性质和后果由你自己判断，做法本身在 把 VPS 配成出口节点 里。涉及单位网络或者商业用途的，按当地规定和你所在组织的政策执行，必要时先问法务。
FAQ
Tailscale 在中国大陆到底能不能用？
要分三层看，没有统一答案。控制服务器登录、点对点直连、DERP 中继这三层各自可能通或不通，而且随运营商、地区和时间变化。实际用法是：先跑 tailscale up 看登录是否完成，再用 tailscale status 看连接是 direct 还是 relay，再用 tailscale netcheck 看中继延迟有没有数值。三层都通就能正常用，某一层不通就针对那一层处理。
tailscale up 之后一直卡住，是被封了吗？
先不要下这个结论，因为好几种原因会产生同一个症状。用 dig +short controlplane.tailscale.com 确认解析结果是否正常，再用 curl -sv --max-time 8 https://controlplane.tailscale.com 看是停在 TLS 握手还是拿到了 HTTP 状态码。拿到状态码说明这一层通，问题在本机，去看 sudo journalctl -u tailscaled -n 50，也检查系统时间是否准确，时间偏差过大会直接让 TLS 握手失败。最后换一条线路复测，这一步能把线路因素和配置因素分开。
tailscale status 显示 relay，还有办法吗？
有。先看 tailscale netcheck 的 UDP 和 MappingVariesByDestIP 两个字段：UDP: false 表示这条线路 UDP 不通，直连打不出去；MappingVariesByDestIP: true 表示对称 NAT，打洞成功率低。然后确认 VPS 侧放通了 UDP 41641 入站，因为只要有一端端口可达，直连成功率就会明显上升。直连确实打不通时，把中继换成自己在境外 VPS 上跑的 derper，延迟通常比落到公共区域更可控。
自建 DERP 和 Headscale，应该先做哪个？
看坏在哪一层。登录都完成不了，先部署 Headscale，因为它替换的正是第一层依赖的控制服务器。登录正常、只是连接慢或者走中继，先自建 DERP，因为它改善的是第三层的延迟和带宽。两者解决的是不同问题，没必要一开始就都上；先跑一次三层诊断，再决定花时间在哪一个上面。
自己搭这样一个私有网络，需要注意什么合规问题？
跨境 VPN 经营服务在中国需要许可，未经批准向他人提供这类服务是违规的。把自己的设备连到自己的服务器、只供自己使用，性质和对外提供服务不同，但你仍然要遵守服务商条款和所在地规定，尤其是把 VPS 设成出口节点、让日常上网流量从境外服务器出去的时候。不要把这套网络开放给他人使用，也不要用它承载单位数据而绕过单位的安全策略。有疑问时按本地规定和组织政策执行。