先说一个典型部署场景。深圳办公室两台开发机放在家用宽带后面，光猫桥接之后上面还压着一层运营商 CGNAT；中国香港机房一台机器跑数据库从库和中转；新加坡一台跑定时批处理和增量同步；美西一台做对象存储归档。五台机器分属三个地区、四个网络出口，每天凌晨两点从新加坡往中国香港推一批几百 GB 的增量，rsync 任务窗口给了四个小时，结果大半时候六点还没跑完，白天业务带宽被占掉一截。
一开始怀疑是磁盘 IO，换 SSD 没用；怀疑是 rsync 参数，调了压缩级别也没用。真正的问题在网络路径上：新加坡那台机器出网走的是云厂商的 NAT 网关，安全组里图省事只放了 TCP，UDP 全禁；深圳办公室那台躲在两层 NAT 后面，出口还是典型的对称型映射。两头的 UDP 打洞全部失败，流量静悄悄地落到了中继上，绕行到第三地去。任务不是变慢了，是换了条完全错误的路。
这类问题在租用服务器做跨机房组网的场景里特别常见，因为出问题的地方既不在应用层，也不在带宽账单上，而在一条你肉眼看不见的 overlay 路径里。要把它讲清楚，得先把 Tailscale 这台机器是怎么跑起来的拆开看。
Tailscale 的底层隧道协议是 WireGuard，这一点很多人知道，但真正决定体验的是它把控制平面和数据平面彻底拆开了。控制平面也就是官方的协调服务器，干的事情只有三类：认证你的身份、分发各节点的公钥、下发你写的访问策略。它像一个共享投递箱，负责把「谁是谁、谁在哪、谁能找谁」这些元数据送到位，用户的一个字节的业务数据都不从这里走。
数据平面则是每台机器上那个 WireGuard 隧道接口（Linux 上通常叫 tailscale0）。节点启动时会生成一对 WireGuard 密钥，私钥写进本地状态文件，从来不出本机。协调服务器只拿到公钥。这意味着即便控制平面完全不可信，它也解不开你的业务流量；反过来，控制平面挂掉期间已经建立的连接还能继续跑，只是新节点加不进来、策略更新不下去。
这里有个反直觉的细节值得记住：每一条连接一开始都是走中继的。两个节点互相认识的过程先通过中继服务器交换各自观察到的公网地址和端口信息，同时并行尝试向对方的候选端点发 UDP 包。打洞成了就无缝切到点对点直连，没成就一直在中继上待着，并且后台还在不停重试升级。所以「我在用 Tailscale」这句话本身不保证直连，得看它当下那条路径是 direct 还是 relay。
节点地址从 100.64.0.0/10 这段里分配，也就是 100.64.0.0 到 100.127.255.255。选这段不是随手挑的，它是 RFC 6598 划给运营商级 NAT 的保留段，正常业务网络里几乎不会用到，因此和机房内网的 10.x、172.16.x、192.168.x 撞车的概率很低。这条设计直接决定了后面子网路由那一节会遇到什么麻烦。
打洞成功的本质是两端各自向对方发一个 UDP 包，在各自的 NAT 设备上「顶」出一条映射表项，让对方的回包能被放进来。这就要求 NAT 的映射行为是可预测的：我用同一个内网源端口访问 A，访问 B 时也最好还是同一个公网端口。这种叫端点无关映射或者锥形 NAT，打洞成功率很高。
第一道坎是对称型 NAT，也常被称为硬 NAT。它的行为是每换一个远端目标就重新分配一个公网源端口，外部完全无法预测。两端只要有一头是这种行为，协调出来的端口信息就是过期作废的，包发出去石沉大海。企业级防火墙、蜂窝网络的出口网关、部分云厂商的 NAT 网关，默认就是这种策略，目的本来就是把连接隔离到最细。
第二道坎是多层 NAT。家庭宽带一层 CGNAT，自己再接个路由器一层，公司出口再来一层。每加一层就多一次需要协调的映射，也多一种失败的姿态。行李箱式的堆叠下，单层能通的组合，叠起来未必通。这也是为什么同一台笔记本在办公室能直连、回家就连不上。
第三道坎是安全组和防火墙策略，而且是最容易被忽略的一道。很多运维在云控制台上的习惯是「只开要用的」，MySQL 开 3306 TCP、SSH 开 22 TCP，UDP 一条都不放。但 UDP 打洞需要的恰恰是出站的 UDP 41641 以及入站的对端回包。安全组把 UDP 一禁，节点连自己的公网映射都发现不了，tailscale netcheck 里 UDP: false 这一行就是这么来的。这一条也是本文开头那个案例的真凶：不是带宽不够，是策略挡死了。
还有一种更隐蔽的情况是运营商对 UDP 的限速或抖动。打洞能成，直连也建立起来了，但跑大流量时丢包率飙升，吞吐还不如走中继。这种时候不能只看状态里是不是 direct，得看实际业务的传输曲线。
DERP 全称是 Designated Encrypted Relay for Packets，直译过来就是「指定的加密包中继」。它转发的是已经用 WireGuard 加密好的密文，中继服务器本身解不开，也看不到你的内容。它对外的协议跑在 HTTPS 之上，通常走 443 端口，这也是为什么它能在最苛刻的网络里活下来——几乎没有任何网络会封掉 443 出站。
落到中继带来的变化有两个层面。时延上，原本一跳能到的包，现在要先上行到中继节点、再下行到对端，等于人为插入了一段往返。插多远，取决于中继节点选在哪。如果在两地之间的中点，代价还算温和；如果最近的中继在第三地甚至跨了洋，那个绕行距离会直接反映在往返时延上，交互式 SSH 的手感立刻就变了。吞吐上，中继节点本身有带宽和处理上限，多路并发时还会互相挤，大流量同步这种场景掉速最明显。
怎么量，而不靠猜。第一步用 tailscale status 看每个节点后面的标记，出现 relay 字样就说明这一条没走直连；第二步用 tailscale ping <目标>，它会持续打几个包并报告走的是直连还是经过哪个中继；第三步用 tailscale netcheck 看本机的 UDP 可用性和到各个中继区域的时延排序。这三步做完，你就能定位出问题出在本机出口、对端出口，还是中间某一段。
判断量级而不是记数字，这才是运维该有的习惯。你只需要知道：同一对机器，直连状态下跑出来的基线吞吐是多少，走中继之后掉到基线的几成，这个比例在你的业务窗口里能不能接受。具体掉几成，取决于中继位置、当时拥塞程度和包长，别人测出来的数对你没有参考价值，必须自己跑一遍。
MagicDNS 解决的是「记不住 IP」这个问题。开了之后每台机器会拿到一个形如 db-1.tailnet-name.ts.net 的名字，由 100.100.100.100 这个桩解析器负责解析。它的价值在重建节点之后才真正体现：机器重装系统重新入网，100.x 地址大概率会变，但名字不变，所有配置文件、监控探针、备份脚本里写名字就不用改。
但有个坑必须提前说：容器编排文件里的端口绑定地址必须是 IP 字面量，不能填 MagicDNS 名字，因为绑定发生在 Tailscale 的 DNS 就绪之前，解析不了。这类地方老老实实写 100.x 地址，然后接受它可能需要手工维护。
密钥这块有两套过期机制，混在一起最容易出事。一套是 auth key，也就是你给无头服务器生成的那个 tskey- 开头的注册密钥，有效期可在 1 到 90 天之间选择，不指定就是 90 天上限。它只在节点注册那一刻起作用，注册完之后它过期不影响已经入网的机器。另一套是 node key，每个节点入网时生成，默认 180 天过期，过期之后这个节点会掉出网络，所有连接断掉。
「半年后某天夜里整个区域失联」这种事故，基本都是 node key 过期造成的。对必须长期在线的服务器，正确做法不是每次到期去点一次重新认证，而是用带 tag 的 auth key 入网——打过 tag 的设备，key 过期默认是关闭的。反过来，对于弹性伸缩的工作节点、临时容器，恰恰应该保留过期机制，让僵死的节点自动清理掉，别在机器列表里堆垃圾。
新开的 tailnet 默认是全通的，任何设备能访问任何设备的任何端口。五台机器自己玩无所谓，一旦涉及多个人、多个环境，这个默认策略就是定时炸弹。
Tailscale 的访问控制策略文件里有两个关键块。tagOwners 声明谁能给设备打某个标签，比如 tag:prod-db 归平台组所有，只有平台组成员能把一台机器标成生产数据库。acls 声明谁可以访问谁，写法是源到目标的端口级授权，例如只允许 tag:worker 访问 tag:prod-db 的 5432 端口。
标签机制最容易写错的一点是归属关系：一台机器一旦被打上 tag，这个节点的 owner 就变成了那个 tag，而不再是当初执行登录命令的那个自然人。带来的好处是，员工账号被删掉之后服务器照常运行；带来的约束是，只有 tagOwners 里声明的主体才能改这个标签，普通成员想给自己加个 tag:prod 是加不上的，必须先有授权。命令行上用 --advertise-tags 提交，管理台确认后生效，这套「声明—审批」的分离，本身就是防提权的。
自动化给服务器打标签的做法，一般是生成带 tag 的 auth key，节点入网时自动带上标签，策略立刻生效。至于服务端自动打标签的具体轮询实现机制与字段，各版本有差异，以官方文档为准，不要照抄网上过时博客里的写法。策略文件改之前，务必用管理台里的 ACL 模拟器先跑一遍——这个文件写错一次，可能把你自己也锁在外面。
这两个功能经常被混为一谈，但解决的是完全不同的问题。出口节点（exit node）是给「我」用的：我把我这台设备的全部公网流量都从你那里出去，对外显示的源 IP 是你的。典型用法是在不可信的酒店网络里，让笔记本的流量从自己机房的服务器出去。子网路由（subnet router）是给「别人」用的：我把我能访问到的某个内网段宣告进 overlay，让其他节点也能访问到那个网段里的、根本没装 Tailscale 的设备，比如老式 NAS、网络打印机、工控机。
子网路由的启用分两步，这个设计是刻意的。第一步在机器上用 --advertise-routes=192.168.1.0/24 宣告，第二步必须到管理台里批准这条路由。分两步的原因是：光靠一条命令就能把整个内网暴露出去，风险太大，必须由有管理台权限的人点头。忘了第二步的人不在少数，表现就是路由宣告了但死活不通，回头去翻防火墙，其实路由压根没批。
冲突坑有两个。一个是路由冲突：如果两台机器宣告了重叠的网段，或者宣告的网段和某台客户端自己的本地网段重合，那台客户端去访问时就不知道该走哪条路。处理思路是优先收窄宣告范围，能宣告 10.0.5.0/24 就别宣告 10.0.0.0/8；实在要保留宽路由，就在客户端侧用 --accept-routes 的开关按需控制，避免全局接过来。
另一个是源地址改写。默认情况下经过子网路由器的流量会做一次源地址转换，对端看到的源 IP 是子网路由器自己的，好处是不用回程配置，坏处是审计日志里看不出真正来源，而且和 exit node 同机部署时会互相干扰。需要保留真实源地址时可以关掉这个转换，但前提是你得在目标网段配好回程路由，否则包回不来。这一条对做数据库审计、按源 IP 做白名单的场景影响很大，上线前一定要确认清楚。
官方的态度其实很明确：绝大多数人不需要自建中继。中继的正常角色是打洞阶段的牵线人和失败时的兜底，如果你发现自己的业务常年跑在中继上，那真正该修的是网络配置，而不是去搭一个更快的中继。官方甚至把自建 DERP 标注为 alpha，并在文档里反复强调这是一项需要投入资源持续维护的高级操作。
什么情况下值得建。第一种是合规与位置锁定：组织要求加密流量不得绕行到指定区域之外，自建中继能明确控制落点。第二种是网络环境确实极端，比如分支机构在严格的企业防火墙后面，直连永远打不通，而官方公共中继的地理落点又不理想，这时在中点位置放一台中继，绕行距离能显著缩短。第三种是追求可控性，不想依赖公共中继的可用性。
自建的硬要求得先看清。中继服务器必须有直连公网的能力，不能躲在 NAT、防火墙或者负载均衡后面，原因是它靠源地址识别设备，而且客户端用的是 HTTP 升级协议建立双向通道，多数云负载均衡不支持。端口上，HTTP 需要 80（不能用自定义端口），HTTPS 需要 443，STUN 需要 UDP 3478，同时必须允许 ICMP。证书方面默认走 Let's Encrypt 自动签发，只有这种证书会自动续期，换成其他证书就得自己重启进程。程序本身没有现成安装包，要用 Go 从源码构建，客户端更新后中继也可能需要跟着重建。
还有一条重要的安全开关：--verify-clients。不加这个参数，你的中继理论上谁都能拿来转发。加了之后，中继会校验连接方是不是你 tailnet 里的成员，但代价是这台机器上必须同时跑着 tailscaled 并且已登录。开了这个开关但机器没入网，中继会对所有客户端 fail-closed，表现出来的现象就是「中继配好了但一台都连不上」，排查方向别搞错。
维护账要算清楚：一台有固定公网 IPv4 和 IPv6 的机器、一个域名、证书续期监控、derper 二进制的版本跟进、以及用 derpprobe 做可用性探测。这些不是搭一次就完的事。如果你只是想降低跨国绕行，官方现在提供的 peer relay 方案往往更省事——它跑在你自己的机器里，时延更低，还不用维护独立的中继服务。
把 Tailscale 放回工具箱里对比，才看得出它真正的位置。下面这张表按五个维度铺开，时延和成本只给相对判断和「需实测量级」的提示，不给具体数字，因为你的链路、你的机房、你的业务包长都会改变结论。
| 对比维度 | 点对点直连（Tailscale 打洞成功） | DERP 中继转发 | 自建转发网关（frp / IPsec 网关类） | 运营商组网电路 / CN2 GIA 优化线路 |
|---|---|---|---|---|
| 部署难度 | 最低。装客户端、登录入网、放行 UDP 出站即可，无需公网 IP，无需手工分发密钥 | 低。与直连同一套客户端，无需额外配置，打洞失败自动接管 | 中到高。需要一台有公网 IP 的中转机、手工维护密钥或配置文件、自己处理多节点互联关系 | 最高。涉及运营商受理、两端设备调试、路由发布，变更周期长 |
| 时延表现 | 最低。路径等同公网两点之间的原生路径，仅叠加一层轻量加密开销 | 较高。人为插入一段到中继的往返，绕行距离取决于中继落点，需实测各区域时延后判断 | 取决于中转机位置，选在两端中点时接近直连，选偏了等同于中继甚至更差 | 路径确定、抖动最小，跨运营商绕行被压掉，实测波动幅度通常优于公网 overlay |
| 带宽吞吐 | 最高。跑在内核态 WireGuard 上，接近机器网卡与物理链路上限 | 受限于中继节点带宽与并发排队，大流量同步场景掉速最明显，需实测基线比例 | 受限于中转机的公网带宽，集中式转发容易成为瓶颈，需按峰值流量选购带宽 | 带宽可按需定档，与承载的业务量线性对应，扩容靠加带宽而非改架构 |
| 成本结构 | 软件侧有免费额度，主要成本是各节点本身的服务器与带宽，边际新增成本最低 | 与直连共用软件成本，但中继流量会额外消耗中继侧的出向带宽，自建时这部分要计入 | 需要额外一台公网中转机及其带宽，规模越大中转机规格要求越高，成本随节点数上升 | 初始投入与月租均最高，属运营商级收费项目，具体资费需向服务商询价 |
| 适用距离与场景 | 跨机房、跨云、办公室与家庭互联，节点数量弹性变化，最忌讳对称型 NAT 环境 | 作为兜底存在，适合对时延不敏感的管控流量、心跳、小批量配置下发 | 适合把内网服务单向发布到公网、或少数几个固定点互联，拓扑相对静态 | 适合两地三中心、生产数据库同步、对时延抖动与可用性有硬性要求的长期链路 |
| 故障排查难度 | 中。需要理解打洞与路径选择，但 status / ping / netcheck 三个命令能覆盖八成问题 | 中。中继不解密，看不到业务内容，只能靠连接事件和字节数判断 | 低到中。拓扑清晰、跳转明确，日志集中在中转机上，看得见摸得着 | 低。运营商侧有链路质量承诺，出问题可派单，但响应与排查节奏不受自己控制 |
表怎么读，比表本身重要。如果你的节点大多在数据中心、有公网 IP、安全组放通了 UDP，那么绝大多数时候你会落在第一列，这一档的收益最实在。如果你的节点大量散落在家庭宽带、4G 路由器、严格企业防火墙后面，那你会有相当比例的时间待在第二列，这时候应该回头去修网络，而不是习惯性地接受中继。
frp 这类工具解决的是另一件事：把内网的一个服务端口发布到公网上让别人访问。它是单向的、中心化的、面向「服务对外」的。Tailscale 解决的是「机器之间组成一个私网」，是双向的、全互联的、面向「内部互通」的。用 frp 的思路去套组网，你会发现机器一多，配置文件就失控了。反过来，用 Tailscale 去做一个需要被公网大量用户访问的服务入口，也不合适。
Zerotier 在形态上和 Tailscale 最接近，都是基于加密隧道的 overlay，都有打洞与中继。差异主要在控制平面的归属和策略表达上：Tailscale 的控制平面默认是托管服务，策略文件表达能力强，和 SSO 身份体系绑定紧；Zerotier 的控制器可以自建，社区里自建控制器的实践更多。选谁，更多是看你的团队更接受哪种运维模型和信任边界，而不是看谁的性能更强。
至于运营商组网电路和 CN2 GIA 优化线路这类，它们和 overlay 不是替代关系，而是不同层级的东西。overlay 解决的是「通不通、怎么通」，承载线路解决的是「通得稳不稳、抖不抖」。当你的 overlay 跑在一条质量稳定的底层线路上时，直连的成功率和稳定性都会上一个台阶；底层天天丢包抖动，再好的打洞算法也救不回来。
容器里跑 Tailscale，第一个拦路虎是 TUN 设备。Tailscale 默认在内核态工作，需要在宿主机上创建一个虚拟网卡，这就要求容器能访问 /dev/net/tun 并且有创建网络接口的权限。Docker 下的常见做法是给容器加上 NET_ADMIN 能力并把 tun 设备映射进去，同时打开 IPv4 转发。拿不到 TUN 设备的环境（比如部分共享容器平台、受限的 PaaS），就得退到用户态网络模式。
用户态模式用 --tun=userspace-networking 开启。它的好处是不需要任何特殊权限，坏处是实打实的性能代价：包要在内核和用户态之间多拷贝一次，处理路径也更长，跑小包管控流量无所谓，跑大流量同步就会明显感到吃力。我的判断标准很简单：这台容器是不是要承担持续的、大带宽的东西向流量，是就想办法拿到 TUN，不是就安心用用户态。
关于 --net=host。用了它，容器直接共用宿主机网络栈，Tailscale 建的路由和接口对整个宿主机生效，配置最省事，性能也没有额外损耗。代价是隔离性没了，容器里的端口会和宿主机抢，网络命名空间形同虚设。对一台专门做网关、只跑 Tailscale 的机器，这是可以接受的取舍；对一台还要跑业务进程的机器，我更倾向于用独立容器桥接网络，只在必要时把需要的路由挑出来。sidecar 模式的思路也差不多：业务容器照常跑，旁边挂一个 Tailscale 容器提供网络出口，两者隔离清晰。
开机自启这块，Linux 上装完包之后 systemctl enable --now tailscaled 一步到位，然后用 systemctl is-enabled tailscaled 确认结果是 enabled。这一步最容易被漏，表现就是重启之后机器失联，第二天早上才发现。unit 文件里建议加上 Restart 策略和网络就绪依赖，避免开机时网络还没起来就被拉起然后卡住。
tailscale up 后面那些参数的实际含义，值得逐个确认一遍而不是照抄。--auth-key 传注册密钥，无头服务器的标准做法；--advertise-tags 声明标签，需要 tagOwners 里先有授权；--advertise-routes 宣告子网，之后还要去管理台批准；--advertise-exit-node 宣告自己可以做出口节点，同样需要批准；--exit-node 指定本机流量从哪个节点出去；--exit-node-allow-lan-access 在使用出口节点时保留本地局域网访问能力，不然连本地打印机都找不着；--accept-routes 表示接受别人宣告的子网路由，不加的话别人宣告的网段你访问不到；--accept-dns 控制是否使用 MagicDNS，和自建 DNS 冲突时可以关掉；--hostname 指定节点名，自动化部署时强烈建议显式指定，否则机器列表里一堆随机名根本分不清谁是谁。改配置优先用 tailscale set，它只改增量，不会像重复跑 up 那样把已有参数覆盖掉。
第一个命令 tailscale status，看两件事。一是节点列表里每一台后面有没有 relay 标记，有就说明这一条当前走中继；二是那些节点是不是都在线、最近一次握手时间是不是够新。如果某台机器显示离线但进程在跑，大概率是 key 过期或者被管理台删掉了。
第二个命令 tailscale ping，比系统自带的 ping 有用得多，因为它知道 overlay 的存在。它会明确告诉你这一条走的是直连还是经由哪个中继，还会给出端到端的往返时间。做对比测试时用它最直观：先 ping 一次拿到基线，改动防火墙或安全组之后再 ping 一次，路径变化一目了然。用它排查「为什么这条这么慢」，比抓包快得多。
第三个命令 tailscale netcheck，回答的是「我这台机器的网络环境到底允不允许打洞」。输出里最关键的一行是 UDP 是 true 还是 false。false 意味着出站 UDP 被挡了，问题百分之百在本机这一侧的安全组、防火墙或者运营商策略上，先去放行再说。它还会列出到各个中继区域的时延排序，这个列表能告诉你你的机器在地理上离哪些中继近，自建中继时选位置就靠它。
三个命令串起来的排查顺序是：先用 netcheck 确认本机 UDP 通不通，再用 status 看全局哪些节点在走中继，然后用 ping 逐条确认具体路径。大部分「Tailscale 很慢」的工单，走到第二步就已经有答案了。真要往深挖，才是抓包和看日志。
得把话说清楚：Tailscale 是一张好用的网，但它不等于零信任。它能保证数据在传输中不被第三方看见、能保证只有授权节点能加入，但它保证不了节点本身是干净的。
第一个真实风险是 auth key 泄露。一个可复用的 auth key 如果进了构建日志、进了公开仓库、进了镜像层，那么在有人发现并吊销之前，攻击者可以用它注册任意多台机器入网。防法是三条：优先用一次性 key，给 key 设短有效期，并把 key 放在专用的密钥管理产品里而不是环境变量里。一次性 key 用完之后官方会自动吊销，这条特性在自动化场景里非常值得用起来。
第二个风险是节点被接管之后的横向移动。如果 ACL 里躺着一条「所有节点到所有节点的全端口放行」，那么任何一台机器被拿下，攻击者就拿到了整张网的通行证，包括那些你以为「在内网所以不用加固」的数据库和中间件。默认全通策略对单人五台机器无所谓，对团队就是灾难。
第三个风险是出口节点和子网路由的滥用。一台被宣告为出口节点的机器，会让所有使用它的客户端流量从它这里出去，如果这台机器同时在跑别的业务、日志留存又不当，等于把一堆人的上网行为集中到了一个点上。这类节点应该专用、最小化安装、日志策略提前定好。
对应的动作就三件事：ACL 按 tag 收敛到端口级，别用通配符；开设备审批，光有身份 provider 的账号还不够入网；定期轮换密钥并清理长期离线的节点。这三件事做完，横向移动的成本会高出一个数量级。
把账摊开看，overlay 方案省的是三块。第一块是公网 IP 的成本，节点不需要各自独占公网地址，家庭宽带、CGNAT 后面的机器也能入网。第二块是运维人力，密钥分发、节点发现、策略下发全由控制平面接管，节点从五台扩到五十台，配置文件数量不会爆炸。第三块是变更成本，加减节点是分钟级的事，不用走运营商工单。
亏的也是三块。头一块是排障的心智成本，打洞这件事本身有概率性，路径会随网络环境变化而漂移，出问题的时候你需要理解 overlay 才知道去哪找。再一块是中继流量带来的隐性带宽开销，自建中继时的出向流量是要计费的，跑得越多越贵，这部分在预算里经常被漏掉。还有一块是可观测性的削弱，中继不解密，你在中继上只能看到连接事件和字节数，看不到业务内容，等于少了一个原本在网关上能做的观测点。
对我见过的多数场景，五台到三十台机器、跨三到五个地区、以文件同步和内部服务调用为主的，overlay 的账是划算的。超过这个规模，或者业务对时延抖动有硬指标，就该认真评估底层线路了——把 overlay 架在一条质量确定的线路上，比在拥挤的公网链路里反复调优要省心得多。
问题：机器入网正常、状态在线，但所有连接都慢，看状态才发现全是 relay。为什么：打洞需要先通过 UDP 探测自己的公网映射，安全组把出站 UDP 禁掉之后这一步直接失败。怎么判断：跑 netcheck 看 UDP 那一行，false 就是它。怎么避：放行出站 UDP（含 41641 及临时端口范围），确认云厂商 NAT 网关没有做对称型映射，改完用 ping 复测路径是否切回直连。
问题：路由命令执行成功，其他节点就是访问不到目标网段。为什么：宣告和批准是刻意分开的两步，缺一不可。怎么判断：管理台里看该设备的路由设置，未批准的路由会明显标出来。怎么避：把批准动作写进部署清单，自动化场景下用 API 或者预授权，别指望人记得住。
问题：一切正常，某天夜里一批机器同时失联。为什么：node key 默认 180 天过期，到期未重新认证就掉网。怎么判断：管理台机器列表里看 key 到期时间，或者直接用 status 看节点是否离线但进程在跑。怎么避：长期在线的服务器用带 tag 的 auth key 入网（tag 设备的 key 过期默认关闭），弹性节点保留过期机制自动清理；同时把到期时间纳入监控。
问题：同步任务一跑，容器 CPU 打满，吞吐却上不去。为什么：用户态网络模式下每个包都要在内核和用户态之间搬运，处理开销显著高于内核态。怎么判断：对比同规格物理机上的基线吞吐，差距过大且 CPU 异常，就是这个原因。怎么避：持续大带宽的节点想办法拿到 /dev/net/tun 走内核态；确实拿不到就限制这类节点的业务角色，只让它们跑小流量管控任务。
问题：某些客户端能访问目标网段，某些不行，且随位置变化。为什么：客户端自己的本地网段和 overlay 里宣告的网段重叠，路由表里出现两条等价路径，选哪条不确定。怎么判断：在出问题的客户端上查路由表，看目标网段指向了哪个接口。怎么避：宣告时把网段收窄到实际需要的范围，规划阶段就给各分支分配互不重叠的内网段；实在无法避免重叠时，用 --accept-routes 的开关按需控制是否接收。
答：不建议这么用，两者的设计目标不一样。frp 这类工具解决的是把内网的一个服务端口映射到有公网 IP 的中转机上，让公网用户能访问，流量是单向的、拓扑是中心化的、访问方不需要装任何客户端。Tailscale 解决的是让你的机器之间组成一个私有网络，访问方必须是 tailnet 成员。如果你要让客户、合作伙伴、普通用户访问一个服务，Tailscale 不合适；如果是让自家分布各地的服务器、办公室电脑互访，那才是对的场景。硬要用 Tailscale 做对外发布，你得给每个外部访问者发一个入网邀请，管理和安全边界都会失控。
答：地理距离和能否直连是两回事，中间隔了几层 NAT 才是关键。同城两台机器，一台在办公室出口防火墙后面且是端口随机映射，另一台在家用宽带 CGNAT 后面，各自的公网映射都不可预测，协调出来的端口信息对不上，包发过去就被丢掉。用 netcheck 分别看两台机器的 UDP 状态和 NAT 行为，用 ping 确认路径，大概率会看到其中一头的 UDP 不通或者映射类型是硬 NAT。修的方向是放行 UDP、减少 NAT 层数（比如把光猫改成桥接、把二级路由器换成 AP 模式），而不是加大带宽。
答：最省事的正确做法是用带 tag 的 auth key 重新入网。打过 tag 的设备，key 过期机制默认是关闭的，不会再有 180 天这个定时炸弹。操作上先在 ACL 的 tagOwners 里声明好标签归属，再到管理台生成一个带该标签、可复用的注册密钥，然后在机器上用 --auth-key 加 --advertise-tags 重新入网，随后确认标签已经生效。注意区分两种过期：auth key 最长 90 天，只在注册那一刻起作用；node key 默认 180 天，才是让机器掉网的那个。临时容器和弹性节点则相反，应该保留过期机制让僵死节点自动清理。
答：免费版在设备数和用户数上都有额度上限，具体数字以官方当前方案页公示为准，别照抄任何文章里的旧数据。判断标准不看机器台数，看三件事：一是有没有多个人需要各自身份入网，二是需不需要标签分组、子网路由、出口节点之外的团队协作功能，三是有没有审计与合规要求。三台机器自己玩，免费额度通常够；一旦有第二个人加入、或者要按角色做权限隔离，就该认真评估付费方案了。还有一条容易忽略：打过标签的设备的计费方式与个人设备不同，规划时把这条算进去。
答：能开，但要清楚两者的流量方向和会互相干扰的地方。出口节点处理的是「客户端的公网流量从我这里出去」，子网路由处理的是「我身后的内网段可以被其他节点访问」，两者在功能上不冲突，一台机器同时宣告完全可行。真正要注意的是源地址转换：默认经过子网路由器的流量会被改写成路由器自己的地址，这会让出口场景下的审计变得困难。需要保留真实源 IP 时可以关掉这个转换，但必须在目标网段配好回程路由，否则包回不来。这类兼做网关的机器建议专用，不要在它上面再跑业务进程。
答：不是必须，取决于你要它做什么。如果这台容器是专门做网关的，只跑 Tailscale 不做别的，用 host 网络最省事，路由和接口对整个宿主机生效，性能也没有额外损耗，代价是网络隔离没有了。如果容器里还要跑业务进程，或者你对隔离性有要求，就用独立的桥接网络，给容器 NET_ADMIN 能力并映射 /dev/net/tun，让它只处理自己需要的路由。真正拿不到 TUN 设备时才退到用户态模式，那个模式不需要任何特殊权限，但每个包要在内核和用户态之间多搬一次，只适合小流量管控用途。
答：强烈建议保留。在 DERP 映射里有一个 OmitDefaultRegions 开关，改成 true 就只用自己的中继。听起来很干净，实际上等于把可用性赌在一两台机器上：你的中继宕机、证书过期没续上、derper 版本和客户端不兼容，那些打不了洞的节点就直接断了，连个退路都没有。正确的做法是默认保留官方公共中继作为兜底，让客户端按时延自己选，你的自建中继因为更近会被优先选中，只有在它不可用的时候才走公共的。同时别忘了开 --verify-clients，同时确认那台机器上的 tailscaled 已经登录，否则中继会对所有客户端 fail-closed，表现为配好了却一台都连不上。
答：中继转发的是已经用 WireGuard 加密好的密文，它解不开也看不到内容，这是架构层面的保证，不是配置出来的。客户端与中继之间的连接还会再叠一层认证，确保只有持有正确私钥的设备才能建立连接。真正需要担心的不是中继窃听，而是两件事：一是注册密钥泄露导致陌生设备入网，二是 ACL 写得太宽导致一台机器被拿下之后可以横向访问全网。对应的动作分别是一次性密钥加短有效期、以及按标签做端口级授权并开设备审批。把这两件事做好，比纠结中继能不能看数据有意义得多。
如果要给一个五台到三十台机器规模的团队出落地顺序，我会这么排。第一步把所有节点先跑起来，不管直连还是中继，先保证全网可达、业务能通。第二步集中处理打洞，逐个节点跑 netcheck，把 UDP 不通的、NAT 层数过多的、安全组挡住的一次性修完，用 ping 复测确认路径切回直连，这一步的投入产出比最高。第三步收权限，按角色定义标签，把默认全通的策略改成端口级授权，开设备审批。第四步才是性能与可用性优化，包括给长期在线的服务器用带 tag 的密钥、把中继落点调到合理位置、必要时引入 peer relay 或者评估自建。
顺序反过来做，多半要返工。先搭中继再修打洞，会把一个简单的安全组问题包装成一个运维项目；先写精细 ACL 再调网络，每改一次网络就要重新验证一遍策略。这个顺序不复杂，难的是忍住不做「看起来更高级」的那一步。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。把话题收回到机器配置上，按本文的场景给几条可执行的建议。
常年在线的骨干节点，选有固定公网 IPv4 的裸金属或者云主机，安全组里明确放行出站 UDP，别让打洞卡在第一步。操作系统建议用官方仓库安装，装完立刻 enable 开机自启并确认状态，这一步漏掉是最常见的失联原因。入网时用带标签的注册密钥，一次性把 key 过期的隐患处理掉，同时按角色规划好 tag，为后面收敛 ACL 留好接口。
中国香港自营机房那类带 CN2 GIA 优化线路的机器，适合承担两类角色：一是跨地区组网里的中点节点，把中国大陆与其他地区之间的 overlay 路径压在一条质量确定的线路上；二是做出口节点或者子网路由的载体，让分支机构的流量有确定的落点。需要说明的是，优化线路的价值体现在底层链路的稳定性上，它不能替你解决 NAT 策略或者安全组的问题，这两件事得分开处理。
如果确实要自建 derper，就别拿小带宽机器凑合。中继吃的是出向带宽和并发连接，按峰值流量去选带宽档位，并且把证书续期、二进制版本跟进、derpprobe 探测这些维护动作写进值班表。一万网络的机型与带宽档位较多，具体选型建议对照官网实时信息或者咨询确认后再下单。
Tailscale 官方文档 · How NAT traversal works：NAT 穿透的实现机理、直连与中继的切换条件、对称型 NAT 与多层 NAT 对打洞的影响。
Tailscale 官方文档 · Custom DERP servers：自建中继的适用场景、限制说明、必需端口（HTTP 80、HTTPS 443、STUN UDP 3478）、ICMP 要求与不得置于 NAT 或负载均衡之后的原因。
Tailscale 官方文档 · Encryption：控制平面与数据平面的职责划分、Noise IK 与 X25519 密钥交换、WireGuard 数据平面、中继仅转发密文的说明。
Tailscale 官方文档 · Auth keys 与 Key expiry：auth key 有效期 1 至 90 天、node key 默认 180 天过期、带标签设备默认关闭 key 过期的说明。
Tailscale 官方文档 · Access control lists 与 tagOwners：标签归属关系、ACL 策略语法、策略模拟器的使用。
Tailscale 官方文档 · Subnet routers、Exit nodes 与 Peer relays：子网路由与出口节点的启用流程、批准机制、peer relay 与自建 DERP 的取舍建议。
tailscale/tailscale 代码仓库 cmd/derper README：自建中继的运维注意事项，包括静态 IPv4 与 IPv6 要求、证书自动续期限制、--verify-clients 需同机运行 tailscaled、derpprobe 监控建议。
WireGuard 白皮书（WireGuard: Next Generation Kernel Network Tunnel，Jason A. Donenfeld）：隧道协议的密码学设计与内核态实现原理。
IETF RFC 4787（NAT Behavioral Requirements for UDP）：UDP 场景下 NAT 映射与过滤行为的分类定义，锥形 NAT 与对称型 NAT 的判定依据。
IETF RFC 5389（STUN）与 RFC 8445（ICE）：端点发现与连通性建立的标准化流程，打洞与候选路径选择的技术基础。
IETF RFC 6598（IANA-Reserved IPv4 Prefix for Shared Address Space）：100.64.0.0/10 地址段的用途界定，overlay 网络选用该段的依据。
Linux 内核文档 TUN/TAP（Documentation/networking/tuntap.rst）：虚拟网卡设备的创建条件与权限要求，容器环境部署的判断依据。
systemd 官方文档：unit 文件编写、开机自启与重启策略配置。
说明：本文涉及的部署场景与配置思路均为示例，价格与规格以服务商官网实时信息或咨询确认为准；各项软件参数以对应官方文档的最新版本为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
