Tailscale Peer Relay 排障复盘：候选可见但会话未建立

整理日期：2026-10-07。来源：9月29日实际对话中的排查反馈。原始完整日志未取得；用户观察、官方要求和本次推断分开记录，尚未确认最终修复。

现象比“网络不通”更具体

你的反馈：peer relay候选已可见，ACL相关配置已检查，UDP 40000监听及可达；但allocation请求计数为0、session为0，连接仍走DERP。该组合提示排查重点可能在客户端是否选择/发起relay协商，而非只重复开放端口。

“端口可达”需要保留测试方式、源/目的地址、时间和实际UDP响应。一次探测不证明真实会话路径、身份授权及转发均正确。

三种路径及控制面

直接连接是两端通信；peer relay通过tailnet设备转发；DERP是另一种中继回退。官方说明先尝试可用peer relay，再回退DERP；列出候选不等于已经建立转发会话。Tailscale Peer Relays

截至核查，relay及使用它的客户端要求1.86或以上；relay需配置UDP端口并有对应grant授权。示例端口40000是配置选择，不是所有环境的默认值；relay侧还需满足官方平台要求。升级版本与重新授权是否必要，应对照实际环境，本文未操作。

把零计数当成分支证据

教学诊断分为四步：候选/策略下发 → 客户端选择 → allocation协商 → 数据转发。

allocation=0只有在计数器口径、采样窗口和进程身份已确认时，才支持“该窗口未观察到协商请求”的结论。它不能直接证明防火墙正常，也不能证明版本bug；请求可能未发、走别的端点、采样被重置或计数器范围不同。

若allocation增加而session仍为0，查认证/授权、协商响应与双端状态；若session建立但DERP仍承载流量，查实际路径选择、探测结果和失败回退；若已有转发再谈吞吐，则单独测CPU、带宽、延迟与丢包。

最小证据包

保留两端与relay的准确版本、操作系统、策略快照中与本设备相关的grant、配置端口、候选/路径输出、同时间段日志，以及发起持续测试流量前后计数变化。可用status、netcheck和带时间戳的ping输出辅助，具体选项依安装版本帮助。

每轮只变一个条件：换已验证客户端、校验授权、确认目标端点，随后重测路径和计数。不要同时升级、改ACL、换端口，否则无法归因。

此前“relayCapableCap≥121导致问题”的说法未取得匹配版本的源码调用链与复现，本轮保留为待确认假设，不写成根因。也不宣称已修复。

与推理排障的共同方法

这是控制面/数据面分离的案例：候选已发布，不代表请求已发起；缓存已分配，不代表KV已传输；kernel支持声明，不代表实际走了该kernel。先按生命周期找最后一个有证据的阶段，再验证下一跳，比反复修改最末端参数更有效。服务器管理见让 Agent 稳定管理多台服务器：SSH 密钥、连接复用与 Ansible。