当 Mesh node 或 client device offline、Mesh IP 无响应，或专用 subnet 之间的流量失败时，请使用本指南。标记为 Online 的参与者已连接到 Cloudflare。该状态不能确认服务或返回路径是否正常。
-
在 Cloudflare 仪表板中，转到 Networking > Mesh。检查源参与者和目标参与者的状态，并记录目标 Mesh IP。
前往 Mesh ↗ -
从源设备测试你已知在目标上监听的服务。例如，测试 TCP 端口
22上的 SSH。在 macOS 或 Linux 上，如果尚未安装nc，请安装它：nc -vz <DESTINATION-IP> 22Test-NetConnection <DESTINATION-IP> -Port 22 -
将
<DESTINATION-IP>替换为参与者的 Mesh IP，或 node 后面 host 的专用 IP。如果服务端口不是22，请使用你的服务端口。选择与失败测试相符的症状。
不要仅使用 ping 进行测试。即使 TCP 或 UDP 流量正常，它也需要 ICMP Gateway 代理。
offline 的参与者无法传输 Mesh 流量。请先检查其 Cloudflare One Client 连接：
-
在 Linux node 上运行：
warp-cli status -
如果输出未显示
Status update: Connected，请运行warp-cli connect，然后再次检查其状态。 -
如果仍无法连接，请验证 host 是否可以访问所需的 Cloudflare One Client IP 和端口。查看 client 诊断日志以查找注册或连接错误。
对于无法注册或连接的笔记本电脑或手机，请按照排查 Cloudflare One Client 问题操作。如果 container node 以普通 client device 的形式连接，请在在 container 中运行 Mesh中验证其 connector token 和持久注册状态。
与 Cloudflare 的连接正常，但流量可能会绕过 Mesh tunnel，或在到达服务之前被阻止：
- 确认两个参与者都注册在同一个 Cloudflare One 账户中，并使用目标的已分配 Mesh IP。检查所需的账户设置，包括唯一设备 IP，以及允许 Cloudflare One 流量到达已注册设备。
- 在源和目标上，检查应用的设备 profile。Mesh node 必须使用 Traffic and DNS 模式。在 Split Tunnels Include 模式下，包含
100.96.0.0/12。在 Exclude 模式下，确保该地址范围和100.64.0.0/10等 parent range 均未被排除。如果更改了默认设置，请使用自定义设备 IP 地址范围。 - 确认测试协议的 Gateway 代理已启用。ICMP 是可选的，但这些服务必须启用 TCP 或 UDP 代理。
- 确认目标服务监听 Mesh IP 或所有 interface，并且其 host firewall 允许源 Mesh IP 和端口。查看 Gateway 网络策略和网络日志，检查被阻止的请求。
仅绑定到 host 的独立本地网络 IP 的服务不会接受发往其 Mesh IP 的连接。如果 IP 有响应但应用程序失败，请先检查服务配置和端口，再更改 Mesh route。
能够通过 Mesh IP 访问 node 并不意味着可以访问其后面的 host。路由 subnet 还需要 CIDR route、forwarding 和返回路径：
-
在目标 node 的 Routes 选项卡上，确认 CIDR route 覆盖专用目标 IP 并指向该 node。
-
在源参与者上，确认其 Split Tunnels 设置通过 Cloudflare 路由目标 CIDR。如果源是另一个 node 后面的 host，请确认其 router 将目标 CIDR 发送到本地 node。
-
在目标 Linux node 上检查 IPv4 forwarding：
sysctl net.ipv4.ip_forward如果结果为
0，请按照使 IP forwarding 持久化操作。云虚拟机可能还需要提供商特定的 forwarding 设置。 -
在目标 node 上，检查 UFW、firewalld、nftables 或其他 host firewall 是否允许在 Cloudflare One Client 和本地网络 interface 之间转发流量。还要检查云 firewall 规则或 security group。
-
检查目标 host firewall 和返回 route。对于具有 Mesh IP 的源，请通过目标 node 路由 Mesh 设备 IP 地址范围。对于另一个专用 subnet 上的源，请通过目标 node 路由该远程 subnet。如果 node 是本地 default gateway，则不需要单独的 static return route。
Container node 可以使用 source NAT 代替返回到 Mesh IP client 的 route。更改 router 之前，请检查 container 设置。
site-to-site 流量需要在两个方向上进行相同配置。一个站点的 route 不会自动配置另一个站点：
- 确认每个 node 都将自己的本地 subnet 通告为 CIDR route。
- 确认每个 node 的有效 Split Tunnel 配置都通过 Cloudflare 发送前往另一个站点 subnet 的流量。
- 确认每个站点 router 都将远程 subnet 的流量发送到其本地 node IP。检查两个站点上响应的反向 route。
- 检查每个 node 在两个方向上的 forwarding firewall 规则。
- 从每个 node 后面的 host 测试一个监听服务。如果只有一个方向失败，请检查两个目标 firewall 和 Gateway 网络策略。
有关完整的双站点示例，请参阅使用 Cloudflare Mesh 连接两个专用网络。
CIDR routing 不会创建 DNS 记录。确认 hostname 解析到正确的专用 IP，并且 client 可以访问 DNS resolver。请先测试专用 IP，以区分 DNS 问题和网络路由问题。
对于 Mesh hostname route，还要确认 node 使用 MASQUE，并且 client 将 DNS 查询发送到 Cloudflare Gateway，而不是使用 Local Domain Fallback。根据你的 resolver 配置，按照 hostname route 的 DNS 说明操作。
封装可能导致较大的数据包超过可用路径的 maximum transmission unit (MTU)。如果较小的服务请求正常，但较大的响应停滞，请遵循 MTU 和数据包分片建议。
使用 Gateway 网络日志检查源、目标、端口和策略操作。如果失败尝试没有日志条目，请先检查 Split Tunnels 和 Gateway 流量日志设置，再更改策略。要诊断无法连接的 node，请收集 Cloudflare One Client 诊断日志。