两台Tailscale连接设备间Ping高延迟问题排查方案咨询

1. 先定位延迟产生的层级 #

不要直接用系统自带ping测，先用Tailscale原生诊断工具确认连接状态：

• 两台设备分别执行 tailscale status，查看对端连接标识：
  • 标识为relay开头的节点名，说明两台设备未建立P2P直连，流量走公网DERP中继转发，是高延迟最常见的诱因
  • 标识为direct <公网IP:端口>，说明已建立直连，高延迟来自底层链路或本地配置问题
• 执行Tailscale专用ping命令：tailscale ping <对端Tailscale虚拟IP>，输出会直接显示当前连接类型、每包延迟、路径切换情况，直接区分是Tailscale协商问题还是底层网络问题。

近场设备走中继时高延迟非常常见：如果中继节点调度异常，分配到跨大区的DERP节点（比如同在美西却调度到美东中继），延迟超过3000ms属于正常现象。

2. 中继绕路/打洞失败排查 #

如果确认流量走中继，按以下顺序排查：

• 统一客户端版本：两台设备把Tailscale升级到最新稳定版，版本差超过3个小版本时，打洞协商协议不兼容的概率极高，升级后重启客户端等待1分钟重连再测。
• 分别在两台设备执行 tailscale netcheck，查看输出的NAT类型、端口映射支持状态：
  • 若NAT类型为Symmetric NAT，且UPnP/NAT-PMP/PCP端口映射全部显示为false，说明路由器拦截了UDP打洞探测包，无法自动建立直连
  • 对应配置调整：Comcast内网设备登录路由器后台，开启UPnP/PCP功能，关闭xFi高级安全、UDP洪水防护这类默认拦截非知名UDP端口的功能；AT&T Fiber设备登录运营商网关后台，关闭包过滤、UDP限流规则，AT&T家庭网关默认对非信任端口的UDP包限速阈值极低，很容易把打洞包拦掉。
• 临时关闭两台设备上的第三方防火墙、杀毒软件的网络防护模块，尤其是带"网络隐身""端口 stealth"功能的安全工具，这类工具会直接丢弃Tailscale发送的未请求UDP包。

3. 直连状态下高延迟排查 #

如果确认已经建立direct直连但延迟仍超过3000ms，排查底层链路问题：

• 先做本地基线测试：两台设备分别ping本地网关、对应ISP的公共DNS（Comcast测75.75.75.75，AT&T测68.94.156.1），如果本地测试延迟就超过100ms，直接联系对应ISP排查接入线路故障。
• 排查MTU不匹配问题：Tailscale基于Wireguard隧道，默认MTU为1280，若中间链路MTU小于该值，会出现大包丢包、反复重传，表现为延迟极高、带宽跑不满。测试方法：
  • Linux/macOS执行：ping <对端Tailscale IP> -M do -s 1252
  • Windows执行：ping <对端Tailscale IP> -f -l 1252
    如果上述命令丢包不通，把Tailscale虚拟网卡的MTU逐步下调到1200再测试。
• 排查ISP互联拥塞：复制tailscale status里显示的对端直连公网IP，用traceroute（Windows用tracert）追踪路径，查看哪一跳开始出现延迟跳涨：如果延迟在Comcast和AT&T的互联Peer点突然升高，说明本地运营商互联点拥塞，可以在Tailscale管理后台手动指定同城市的DERP节点作为备用，或者手动配置端口映射固定Tailscale监听端口，强制走其他互联路径。

4. 特殊场景校验 #

• 双栈网络绕路排查：如果两台设备同时开启IPv4/IPv6，执行tailscale ping --tsmp <对端虚拟IP>查看路径，Comcast和AT&T的IPv6互联经常出现跨区路由绕路，临时在Tailscale设置中关闭IPv6转发，强制走IPv4直连再测延迟。
• 配置校验：检查两台设备是否误开启了出口节点（Exit Node）、子网路由转发功能，若所有流量都被路由到对端转发，也会出现异常高延迟，临时关闭相关功能再测试。
• 设备负载校验：查看两台设备的CPU占用率，如果CPU持续跑满，Tailscale的加解密、包转发逻辑会被阻塞，也会出现数千毫秒的处理延迟，关闭高占用进程后再测试。

内容的提问来源于stack exchange，提问作者Ashesh Jain