P21 子计划：节点网络路径视图与双节点诊断

计划状态：已实施，代码、发布与生产回读均已完成

所属阶段：P21 并行子计划，不改变当前阶段编号

当前工作包：无（PV-0 至 PV-7 全部完成）

📌 结论摘要

结论：新增独立“路径视图”标签页。 主图用分层结构图，加入可选起点/终点的双节点诊断；同时区分公网 TCP 路径与 Tailnet 隧道内的 TCP。依据是实时分布图负责呈现节点关系，而诊断需要逐层解释来源、协议、路线和证据；影响是用户能看懂“RR 公网 TCP 不通，但经 Edge/Tailnet 访问 RR 内部服务仍可工作”，不会把某一条公网路径误判成整台机器全坏。用户已于 2026-11-01 确认执行，代码、本地验收、镜像发布、DERP 探测安装与生产回读均已完成。

🗂️ 目录

• 结论摘要
• 范围与状态
• 现状证据
• 分层模型
• RR 公网与隧道边界
• 结构图设计
• 双节点诊断
• 路径触发条件
• 443 硬门槛
• 控制面位置
• 工作包
• 推荐执行顺序
• 验收标准
• 回退方案
• 未决项

📌 范围与状态

项目	当前结论	影响 / 下一步
本轮动作	已完成代码、测试、镜像发布、DERP 探测安装、生产回读、按节点汇总与控制面韧性评估	PV-0 至 PV-7 全部完成
计划归属	P21 并行子计划	不改变 P21 主阶段编号；未来可独立升级为新阶段
现有网络结构	Edge、DERP、Peer Relay、Tailnet 和 RR 控制面保持不变	先实现可视化与诊断，再评估运行口径修正
用户确认门槛	用户已于 2026-11-01 确认执行	全部工作包已完成，生产回读通过

📊 现状证据

证据对象	当前已确认事实	对计划的影响
RR 公网 TCP	2026-11-01 家庭出口 101 对 RR 公网 TCP 443、47522、80、8888、32118、39120 全部失败；Globalping 深圳、广州对 443、47522 均无回复	路径视图必须把“公网 TCP 路径”单独标红
RR Tailnet	101 到 RR Tailnet 为 UDP 直连，约 177ms	不能把 RR 节点整体标为不可用；应显示隧道内管理路径
控制面入口	mesh.yohan.fun 是 edge.yohan.fun 的别名，当前落到活跃 Edge；Edge 经 Tailnet 回源 RR	不迁移 Headscale 本体，不新增 dog 控制面前置
MM 到 RR 服务	MM nginx 通过 RR Tailnet 地址访问私有回源网关，HTTP 返回 302	证明“隧道内 TCP/HTTP”与“公网 TCP”是两层不同结论
101/102 到 dog	NAT 打洞变化可能造成路径随时间改变；最新复测两源都得到直连	双节点诊断必须带观测来源和时间，不能固化单次路径
MM、DD 等节点	101/102 对部分节点只能走 DERP	图形显示实测直连、Peer Relay 或 DERP 路线

🧱 分层模型

四层从下往上：公网 IP、传输协议、节点间路径、服务入口。 下层的故障会在上层表现为不同症状，所以诊断必须按层回答，而不是只给一个颜色。

层	内容	决定什么	当前端口与功能
公网 IP	每台 VPS 的 IPv4	整块 IP 被阻断时上层全部失效	不涉及端口
传输协议	TCP 与 UDP	被封的可能是公网方向的某协议路径，不应误判为本机协议栈停止	TCP 443 承载 Edge 网站与 DERP；UDP 443 承载 DERP 的 QUIC 通道；UDP 39478 承载 STUN 打洞探测；UDP 40000 承载已配置 Peer Relay 的节点；UDP 41641 是 Tailscale 常见直连端口，实际端口可协商
节点间路径	直连、Peer Relay、DERP	两台节点之间当前实际用什么方式传输	直连走 Tailscale UDP；Peer Relay 只在具备并发布中继能力的节点上展示；DERP 依赖合格区域和客户端可达的 TCP 443
服务入口	edge.yohan.fun 到当前 Edge 再到 Origin	用户访问网站走哪台机器	Edge 对外 TCP 443；Origin 回源 TCP 14443

🖼️ 结构图设计

主图用三段横带的分层结构图，不用流程图。 五台节点乘三条路径画成流程图会不可读；分布图只能回答“在哪”，回答不了“为什么不通”。

横带	内容	表达方式
上带	客户端与家庭出口	一台设备图标加出口标识
中带	公网 VPS 节点与内网节点，分组呈现	逐节点显示其实际承担的服务与协议能力；RR 显示控制面、管理隧道，Edge/DERP/Peer Relay 能力按登记和运行事实显示；未配置能力标“不承担/不适用”，不画成失败
下带	服务入口	edge.yohan.fun 到当前 Edge 再到 Origin 链路

线型	含义
实线	直连 UDP 通路
虚线	经 Peer Relay 中转
点线	经 DERP 中转

图右侧固定一个小的判断面板，只放两个自动开关的当前状态：Edge 切换、DERP 资格。判断过程不画进主图，避免主图承担流程职责。图上所有文案只用节点名称与人类可读状态，不出现任何内部编号。状态必须分开表达公网 TCP、Tailnet UDP 路径和节点服务角色，不能让一个协议状态涂红整台节点。

路径视图还要标注一类“已知不可用但可绕过”的事实：例如 RR 的公网 TCP 整段不可用，图上把 RR 的公网 TCP 标记为红色，同时用一条经 Tailnet 的连线表示“运维与管理流量走隧道、SSH 需要跳板”，避免看图的人误以为 RR 整台不可用。

🧭 RR 生产节点的公网与隧道分层

图中必须分开公网 TCP 和隧道内 TCP。 这里不是矛盾，而是目标地址和承载网络不同：公网直连 RR 的 TCP 整段失败；MM 反向代理访问 RR 的 Tailnet 地址，TCP 连接被封装在 Tailnet 的 UDP 数据面里，因此隧道内的 HTTP/TCP 仍然可以正常工作。

链路	实际路径	协议与功能	当前影响
公网直连 RR	中国方向 → RR 公网 IP	TCP：443、真实 SSH 端口及其他公网 TCP	整段不可用；不能直接 SSH、不能直接访问 RR 公网服务
MM 访问 RR 控制面	客户端 → mesh.yohan.fun → 当前 Edge → MM Tailnet 反代 → RR Tailnet 网关	外层 UDP：Tailscale 直连；隧道内 TCP：反代与 Headscale/API 服务	当前可用，不经过 RR 公网 TCP
MM 访问 RR 容器服务	MM Tailnet 地址 → RR Tailnet 地址 → RR 私有回源网关 → 容器/服务	外层 UDP：Tailscale；内层 TCP/HTTP：服务端口	当前可用；不能因为 RR 公网 TCP 失败就判断容器 TCP 失败
RR 运维 SSH	101/102 或当前 Edge → Tailnet → RR 的 SSH 真实端口	外层 UDP：Tailnet；内层 TCP：SSH	当前应走跳板，不能从中国直连 RR 公网地址

实测依据：RR Headscale 监听 Tailnet 上的控制端口；MM 的 mesh.yohan.fun vhost 回源到 RR Tailnet 地址；101 到 RR Tailnet 的 tailscale ping 为直连，约 177ms；MM 通过 RR Tailnet 私有回源访问返回 HTTP 302。影响是路径视图必须同时显示“公网 TCP 红色”和“Tailnet 隧道绿色”，不能把 RR 整台机器显示成完全不可用。

SSH 运维规则： RR 从中国方向不能直接连接公网 SSH，必须使用 102 或当前 Edge 作为跳板，经 Tailnet 到 RR；所有写死 RR 公网地址的脚本和探测都必须标记为不可用路径。

🔍 双节点诊断设计

双节点诊断必须明确标注“实测”或“未直接测量”。 当前探针只在 101 和 102 上运行。两端分别能被 101/102 探测，不足以证明两端彼此间的 NAT 打洞或中继路径；不能用传递推理伪装成实际路径。

项目	设计
输入	起点节点、终点节点；当前可用观测源为 101 与 102
输出结论	直连、经 Peer Relay、经 DERP、不可达或“当前无法直接判定”；标注“实测”或“依据快照推导”
逐源明细	101、102 各自实际执行的起点、终点、路线、延迟和时间；不把第三方节点的两段结果拼成一条实测路径
原因链	分开列公网 IP、TCP、UDP、控制面和服务入口的证据，例如“公网 TCP 失败，但 Tailnet UDP 直连成功，故隧道内 TCP 可用”
证据	展示判定依据的时间戳与来源，不展示内部编号与集合名
交互	选择后先返回最近快照；若所选起点不在可执行探针列表，显示“未直接测量”，不猜路线

不新增公开查询接口。 诊断直接消费现有拓扑接口返回的节点网络快照：每个目标已经带有 101 与 102 各自的路线、状态、延迟和检查时间，足以区分“实测”与“未直接测量”。这样少一个公开端点和一套鉴权面，也不会让页面在刷新时出现两份口径不同的数据。

🚦 路径触发条件

直连只依赖 UDP，TCP 不参与数据面。 Tailscale 的点对点数据走 WireGuard over UDP（默认 UDP 41641，也可用 STUN 协商后的任意端口）；TCP 443 只用于控制面 API、DERP 中继和网站入口。因此“TCP 被封”不等于这台机器不能做节点间直连。

路径	何时使用	前置条件	失效表现
直连	两端 NAT 打洞成功	双方 UDP 出站可用，NAT 映射稳定	tailscale ping 直接显示对端地址与延迟
Peer Relay	直连失败，且某台节点发布了 relay 服务	该节点开启 UDP 40000，客户端选中它作为中继	延迟高于直连，路径里出现中继节点
DERP	直连与 relay 都不可用	该区域在 DERP Map 中，且客户端到该区域 TCP 443 可达	延迟最高，路径显示经某台 DERP 节点

实测补充：当前四台 Edge 都已发布 relay 服务，但会话数为 0，说明“已发布”只是具备能力，并不代表正在承载流量。

🔐 443 硬门槛的保留与改进

结论：443 硬门槛保留，但要把判据做得更准，而不是去掉。 设定它的原因是一次真实事故：dog 的 TCP 与 UDP 从中国方向同时失效，而当时的 DERP 选择只看主控面到节点的延迟，结果中国方向全部流量被导向 dog，整个网络瘫痪。443 是“中国方向能不能连上这台机器”的最低成本代理指标，去掉它等于把这个故障模式重新打开。

可以改进的是判据质量，不是判据本身：

现状问题	影响	改进方向
只看 TCP 443，不看 UDP	不能代表任一观测源的 UDP 打洞结果	保留中国方向 TCP 443 为 DERP 硬门槛；逐源 UDP 结果单独展示，不替代该门槛
数据新鲜度错配	常规探测改成 2 小时一轮后，资格判据多数时间只能 hold	优先让每个 DERP 候选在门槛有效期内有独立、错峰的新鲜 TCP 443 结果；不放宽硬门槛或旧数据门槛
判据是全局而非逐源	某个来源可达、另一个不可达时无法体现	资格仍用中国方向整体结果，逐源差异只用于展示

另一个本轮发现的证据：RR 从 Globalping 三个城市看是 TCP 443 不可达（ICMP 25/25 成功、TCP 0/15 失败），说明 ICMP 可达不等于 TCP 可达，判据必须同时区分协议和来源。

新增探测的频率与探针数必须先做额度测算。初步选项是四个 DERP 候选错峰轮转：每 15 分钟检查一台、每轮最多 5 个 Globalping 探针，目标是每个候选 60 分钟内至少有一份新鲜 TCP 443 结果；按此估算约新增 20 tests/小时。这是计划估算，不是已经实施的调度；执行前必须与当前自动用量和 120 tests 人工储备一起核算，超出预算则先设计复用现有 Edge 检查的方案。

🧭 控制面位置评估

控制面已经有前置入口，RR 公网 443 被封不影响它。 实际链路是：客户端连接 mesh.yohan.fun，该域名是 edge.yohan.fun 的别名，落到当前活跃 Edge（现在是 MM）；Edge 再把请求回源到 RR 的 Tailnet 地址，Headscale 只监听 Tailnet，不监听公网。客户端从不直连 RR 的公网 443。

方案	收益	风险	结论
保持现状：Edge 前置 + Headscale 在 RR	已实现，客户端无感	依赖单一活跃 Edge	保持
整体迁到 dog	中国方向可达性更好	全部客户端要重连、状态与密钥迁移、dog 同时承担 Edge 与中继	不采用
在 dog 另建前置入口	与现有 Edge 入口重复	多一套证书、认证和故障面	不采用
102 只读热备	可承接已有 Console/Auth/API 的只读备用投影	不是 Headscale 热备，也不能直接作为公网入口	保持既有范围；Headscale 热备另行设计

PV-6 结论：控制面继续留在 RR，不迁移

结论：控制面保持现状，不迁移。 继续由 Headscale 在 RR 承担写权威、Edge 做前置入口、102 做只读备用；迁到 dog 或 102 都不会消除当前已证实的断点，反而增加状态迁移、客户端重连和回退风险。

评估维度	保持现状（RR 写权威 + Edge 前置）	迁到 dog	迁到 102
中国方向可达性	用户只连 Edge 的 TCP 443，不依赖 RR 公网 TCP	dog 当前可达，但会把控制面单点从 RR 换成 dog	102 没有公网入口，仍必须依赖 Edge 或反向代理
故障域	RR 整机故障时控制面写入中断，102 只读备用可降级	未消除单点，只是换了一台机器	与 RR 同属生产域，没有增加独立故障域
状态同步	没有同步成本	需要迁移 Headscale 数据库、密钥、ACL 和节点登记，并处理双写与回滚	需要新建 Headscale 数据复制与选主，工作量最大
客户端重连	不需要	全部客户端需要重新连接控制面或更新入口	同 dog，且 102 没有公网入口
回退	已有 Edge 回退与 102 只读备用	回退需要再次迁移状态	回退需要拆除复制与选主
结论	保持	不采用	不采用

只有出现下列情况才重新评估迁移： RR 无法恢复写能力、Tailnet 到 RR 的直连长期不可用，或 RR 整机需要长期下线。届时优先选择一台有稳定公网可达性、且能形成独立故障域的节点，并单独立项做状态迁移、双写校验和客户端重连演练；不在本计划内直接操作。

证据来源： P16 只读备用验收、当前路径视图的 RR 公网/隧道分层、RR 公网 TCP 多端口实测。本轮是只读评估，没有改 Headscale、Edge 切换或 DNS。

RR 的 TCP 是被整段阻断，不只是 443

RR 公网 TCP 整段不可用，不只是 443。 这是 2026-11-01 双来源复测的结论：同一天同一台机器，UDP 路径正常、TCP 路径全失败，所以不能把结论写成“只有 443 被封”。

来源	测试对象	结果
家庭出口 101	RR 公网 TCP 443、47522（SSH 真实端口）、80、8888、32118、39120	六个端口全部连接失败
Globalping 深圳、广州	RR 公网 TCP 443、47522	原始输出均为 No reply ... tcp_conn=1/2/3，连接失败
家庭出口 101	RR 的 Tailnet 地址，UDP 41641	直连成功，177ms

由此确定的使用约束：RR 的 SSH 不能从中国直接连，必须走跳板，跳板用 102 或当前 Edge，经 Tailnet 到 RR；任何写死 RR 公网地址的脚本、探测和运维动作都要按“不可达”处理。

不受影响的路径仍然成立：网站入口、控制面登录与注册、节点间直连、DERP、Peer Relay 全部走 Edge 或 Tailnet，不经过 RR 的公网 TCP。

仍然存在的单点不是 RR 的 443，而是“同一时刻只有一个活跃 Edge”：它故障时控制面入口会跟着切换，切换本身依赖 DNS 与 Edge 切换控制器正常工作。

RR 的公网 TCP 与隧道内 TCP

连接段	实际链路	协议层	结果与含义
中国用户到 RR 公网地址	用户 → RR 公网 IP	公网 TCP（测试的 443、真实 SSH 端口及其他常用端口）	当前已测端口均失败；运维不能把公网直连当可用路径
用户到控制面	用户 → mesh.yohan.fun → edge.yohan.fun 当前 Edge	用户到 Edge 为 TCP 443	不经过 RR 公网 IP
Edge 回源到 RR	MM → RR Tailnet 地址上的私有回源网关	外层 Tailnet 常见为 UDP 41641 直连，也可能按实测路径经中继；隧道内 39200/TCP 承载 RR 私有回源网关	实测 Tailnet 直连约 1ms，私有网关 HTTP 返回 302、约 15ms
RR 私有网关到 Headscale	RR 私有回源网关 → Headscale Tailnet 监听地址	39088/TCP，仅在 RR 内部/Tailnet 服务路径使用	不要求 RR 公网 TCP 可达
RR 运维 SSH	101/102 或当前 Edge → Tailnet → RR 的 SSH 真实端口	外层 Tailnet UDP；隧道内 47522/TCP 承载 SSH	可用于管理；从公网直接 SSH 失败时应使用 Tailnet 管理或跳板

RR 公网 TCP 故障不等于 RR 所有 TCP 服务都停了。 “整段不可达”指公网入站路径；MM 反向代理与 RR 服务之间的 TCP 连接被封装在 Tailnet UDP 数据面内，二者不矛盾。路径视图必须把两段分别画出，不能用一个“RR TCP 红灯”覆盖隧道内服务状态。

当前 Headscale 权威仍在 RR；102 现有“只读热备”具体覆盖 Console/Auth/API 投影，不是 Headscale 数据与控制面的热备。不建议因为 RR 公网 TCP 被封就迁移 Headscale 到 dog：客户端访问已有 Edge 前置，Edge 经 Tailnet 到 RR；迁移会增加状态/密钥迁移和节点重连风险，但没有解决已证实的业务断点。PV-6 只做只读容灾评估，不迁移、不切流。

本计划采用的运行口径是“RR 中国方向公网 TCP 整体不可达”，依据为两来源的多端口失败样本；这不是穷测全部端口的数学证明。新视图必须保留观测来源、时间和具体测试项目，避免把“公网入口不可达”错误解释成“主机 TCP 栈被关闭”。

2026-11-01 调度修正：每小时全量检查

结论：例行检查改为每小时五台全量。 同时把 10 分钟一次的活动 Edge 结果写回对应节点卡片。

问题	修正	影响
五台轮转一次约 10 小时，卡片最久 8–9 小时不更新	每小时一次全量扫描，五台同一时间更新	主机与公网入口时间对齐
活动 Edge 每 10 分钟探测，但结果只进顶部面板	将结果写回对应节点的入口时间和入口证据	活动 Edge 卡片保持新鲜，不伪造主机检查时间
页面只显示时间，不显示年龄	增加“X 分钟前”和数据延迟/过期标识	旧结果不会再看起来像实时
额度预测只按单目标计算	按五台全量重新计算	每小时约 100 tests，约 20% 小时额度

额度： 五台全量约 50 tests/小时，活动 Edge 约 30 tests/小时，DERP 约 20 tests/小时，合计约 100 tests/小时；保留 120 tests 人工储备，低于阈值时自动跳过例行全量。

数据边界： 按节点汇总和节点路径视图继续复用同一份快照，不新增探测。

🛠️ 工作包

工作包	内容	关键改动	退出条件
PV-0 只读基线冻结	逐项回读来源、目标、协议、数据时间和消费者	冻结服务/路径/资格数据契约与“实测、推导、未知”标签	RR 公网与隧道内链路、控制面入口、Edge/DERP/Relay 状态均能指向真实证据
PV-1 DERP 资格新鲜度	资格要求新鲜 TCP 443，当前采样节奏可能使状态长期 hold	443 保持硬门槛；先算配额，再选独立错峰检查或复用现有检查	所有区域按新鲜证据判定；过期时保留 last-known-good，不误删或误加
PV-2 Peer Relay 三态	只要“已发布”就判健康，实际会话为 0	改为已发布、有会话、未发布三态，页面分别显示	页面能区分“可用但没人用”和“真在用”
PV-3 路径视图与结构图	新增标签页与分层结构图	Console 新增标签、结构图渲染、图例	桌面与移动端可读，无内部编号，端口带协议
PV-4 双节点诊断	新增查询接口与界面	API 增加按节点对查询，前端加选择器与原因链	只有探针确实从所选起点执行到终点才标实测；其他组合标“未直接测量”，不得用两段观测推导出实际路线
PV-5 按节点汇总	三张卡缺少一台机器的完整画像	按节点一行显示主机、直连、入口三条结果	单节点可一屏看完三条路径
PV-6 控制面韧性评估	只读比较现有 Edge 前置、整体迁移 Headscale、102 热备的影响	评估可达性、故障域、状态同步、客户端重连、回退；不改控制面	输出有证据的方案比较；若需要变更，另立实施工作包并待用户确认
PV-7 文档与发布	计划、架构说明、验收记录	文档更新、提交、镜像发布、生产回读	精确提交、工作流全绿、生产回读通过

推荐顺序： PV-0 → PV-1 → PV-2 → PV-3 与 PV-4 → PV-5 → PV-6 → PV-7。PV-1/2 先修判据，PV-3/4 共用冻结后的路径数据，PV-5 基于最终字段整理单节点视图，PV-6 只形成控制面建议，不含迁移。

实施记录（2026-11-01）

工作包	状态	落地内容
PV-0 数据契约冻结	完成	路径视图直接复用现有拓扑快照与双源节点网络快照，不新增公开接口；每来源保留状态、路线、延迟、检查时间和数据年龄。
PV-1 DERP 资格新鲜度	完成（代码）	新增独立的 DERP 候选 TCP 443 探测：每 15 分钟检查一台，四台候选各约 60 分钟一轮，额度低于 120 tests 时自动跳过；资格脚本改读独立快照，单目标 75 分钟内有效。
PV-2 Peer Relay 三态	完成	节点、链路和检查结果都投影“已发布且有会话 / 已发布但无会话 / 未发布 / 状态未知”，页面不再把“已发布”直接等同于“健康”。
PV-3 路径视图	完成	Console 新增独立“节点路径视图”标签页，按观测来源、VPS 与内网节点、服务入口三段展示；VPS 固定按 RR → MM → d02 → DD → DOG 排列。
PV-4 双节点诊断	完成	诊断只对 101/102 真实执行过的来源到终点组合标“实测”；其他组合明确显示“未直接测量”，不把两段观测拼成一条实际路线。
PV-5 按节点汇总	完成	可达性页新增按节点汇总表：VPS 固定 RR → MM → d02 → DD → DOG，一行对照主机可达性、101/102 实测路径、公网入口 TCP 443 和最近检查；三个状态各自独立，不合并成整机判定。
PV-6 控制面韧性评估	完成（只读评估）	结论为保持 Headscale 在 RR、Edge 做前置入口、102 做只读备用；迁 dog 或 102 不消除单点，反而增加状态迁移与客户端重连风险。未改控制面。
PV-7 文档与发布	完成	文档、静态契约、浏览器契约与单元测试通过；提交、推送、镜像发布和生产回读完成，详见下方生产回读。
追加修正（2026-11-01）	完成	例行检查改为每小时五台全量；活动 Edge 结果写回节点卡片；页面增加数据年龄与数据延迟/过期标识。

生产回读（2026-11-01）

检查项	结论	证据
GitHub 工作流	通过	提交 8159789f 的 API 网关、Console、文档站与 Repository Guardrails 全部成功，post_push_verify=pass。
Console 路径视图	已上线	生产 app.js 含 45 处 networkPath；RR 容器内 index.html 含“节点路径视图”标签与诊断表单。
后续 Console 提交	兼容	8ce85e17 只修移动端嵌入页布局，基于 8159789f，工作流成功，Console 继续运行该提交。
Peer Relay 三态	生产生效	生产拓扑投影中 d02、DD、MM、dog 均为“已发布，当前无会话”；RR、101、102 等不承担节点为 null。
DERP TCP 443 探测	已安装并运行	首次探测 MM 返回健康、3 个探针；探测 timer 与原有采集 timer 均为 active。
DERP 资格控制器	已切换到独立快照	安装后四个区域计划状态为 ok；资格脚本改读 derp-eligibility-reachability-v1.json。

发布注意： 首次回读期间执行过一次同提交 Console 重部署，原因是并行部署任务在 RR 上重建了容器；重建后的 8ce85e17 仍包含本计划的路径视图代码，因此不需要再回退或重复发布。

🔜 推荐执行顺序

批次	内容	进入条件	退出条件
第 0 批	只读事实刷新与数据模型确认	用户确认本计划；现有双源快照可读	每字段标出来源、观测时间、证据等级；确认公网/隧道分层
第 1 批	DERP 资格新鲜度	第 0 批完成；保持 TCP 443 硬门槛	配额在预算内；资格只由新鲜中国方向 TCP 443 决定
第 2 批	Peer Relay 三态	第 0 批完成	能区分已发布、实际有会话、未发布
第 3 批	路径视图结构图	路径数据契约冻结	桌面/移动端无溢出，节点能力按登记区分，不把不适用画成故障
第 4 批	双节点链路诊断	探针执行源与目标边界已明确	只对真实执行的起终点对报告实测；其他组合显示未直接测量
第 5 批	按节点汇总视图	第 3、4 批完成	一台节点一行对照主机、TCP、UDP、Tailnet 路径和公网入口
第 6 批	控制面韧性只读评估	现有前置链路和 102 备用职责核实	给出是否需后续实施的方案与回退，不操作服务
第 7 批	发布、回退和用户验收	前六批测试通过且用户确认实施范围	生产回读、浏览器验收、回退材料齐全

每一批都必须先完成本地测试和只读回读，再进入下一批。未获得用户确认前，计划停在第 0 批之前，不执行生产动作。

✅ 验收标准

编号	要求
A1	结构图与诊断结果中不出现任何内部编号、集合名或状态码
A2	所有端口一律写成“协议加端口加功能”，不出现孤立数字
A3	双节点诊断明确标注实测或推断，推断不得伪装成实测
A4	Peer Relay 能区分已发布、有会话、未发布三种状态
A5	DERP 资格在常规探测节奏下仍能产出新鲜判定，不再长期 hold
A6	桌面与移动端结构图不出现文字遮挡与横向溢出
A7	RR 的公网 TCP 整段不可用与 Tailnet 隧道内 TCP 可用必须分开显示
A8	RR SSH 入口显示“需跳板”，不能提供公网直连作为推荐路径
A9	双节点诊断原因链必须说明“公网路径”或“隧道路径”，不能只给“TCP/UDP 不通”
A10	未直接测量的节点组合不能输出伪造的直连、Peer Relay 或 DERP 路线

🔁 回退方案

层	回退动作
界面	下线新标签页，保留实时分布图原状
接口	回退 API Gateway 上一完整镜像
判断口径	恢复原阈值与原 Peer Relay 判定，保留快照回读能力

⚠️ 未决项

未决项	现状	待确认
计划归属	本计划挂在 P21 下作为并行子计划	是否需要独立阶段编号
独立 443 检查频率	已按每 15 分钟一台、四台候选各约 60 分钟一轮实施，约新增 20 tests/小时	生产观察一个周期后复核额度与故障切换时延
内网节点是否做中转	目前只有四台 Edge 提供中转	是否在 102 上开启中转端口
控制面前置入口	已由 Edge 承担（mesh.yohan.fun 别名到 edge.yohan.fun）	不再新增 dog 入口，只评估 102 只读热备
RR 公网 TCP影响	公网 TCP 整段不可用，但 Tailnet 隧道内 TCP 正常	路径视图必须分开显示公网与隧道两条链路
计划启动	用户已于 2026-11-01 确认执行；代码、发布与生产回读完成	无
按节点统一汇总	已完成，见“按节点汇总”表	无