ConnProof

network is unreachable：网络不可达的路由与接口检查 ​

TCP-004network is unreachable严重程度 High
一句话结论

本机路由表里找不到能到达目标网络的路径，数据包在离开你的电脑之前就被内核拒绝了。最可能是默认路由丢失或尝试走了不存在的 IPv6 路由；第一步是运行 doctor 查看默认路由与网络接口摘要。

适用环境WindowsmacOSLinuxAndroidiOS
适用客户端通用客户端
最后验证：2026-07-28规则版本：v1内容更新：2026-07-28

结论 ​

这条错误与超时、拒绝有一个根本区别：它不是网络另一端的回应，而是你自己的操作系统在本地直接给出的裁决。内核翻遍路由表，找不到任何一条能把数据包送向目标网络的路径，于是连尝试都不尝试。因此排查完全在本机进行——路由表、网络接口、还有那些声称管理过路由的软件（VPN、虚拟机、容器工具）。

适用环境 ​

  • 全部平台
  • 高发场景：VPN/代理软件异常退出后、系统睡眠唤醒后、双栈网络中的 IPv6 目标

一分钟快速判断 ​

  1. 看网络图标：Wi-Fi 断了、网线松了、拨号掉线——最朴素的原因占了相当比例，先排除；
  2. 运行 connproof doctor，看"默认路由"与"网络接口摘要"两项；
  3. 回忆最近十分钟：是否退出过 VPN、关闭过虚拟机、或从睡眠唤醒？这三件事都以擅长弄乱路由表著称。

这条错误代表什么 ​

路由表是内核的"寄件指南"：每个目标网段对应一个出口（网卡 + 网关）。“网络不可达"表示查表落空，常见的落空方式有三种：

  • 默认路由（0.0.0.0/0）缺失：指南的"其他所有地址"条目没了，一切非局域网目标都不可达；
  • IPv6 路由缺失：目标解析出了 IPv6 地址，系统尝试走 IPv6，而本机只有 IPv4 路由。这是双栈时代最常见的变体——报错看着吓人，其实换回 IPv4 就好；
  • 残留路由指向已消失的接口：VPN 建立的虚拟网卡没了，它注册的路由条目还在，指向一个不存在的网关。

ConnProof 如何判断 ​

connproof doctor

相关证据：活动网络接口数量与名称、IPv4 默认路由是否存在。再做地址族对照：

connproof tcp 目标主机 --port 443 --ipv4
connproof tcp 目标主机 --port 443 --ipv6

IPv4 成功而 IPv6 报不可达 → 确认为 IPv6 路由缺失，属于配置现实而非故障，让应用优先 IPv4 即可。两个地址族都不可达且默认路由缺失 → 本机路由表损坏，按下面平台步骤修复。

最常见原因 ​

  1. 物理连接断开：网线、Wi-Fi、拨号；
  2. VPN/代理软件异常退出：清理路由不完整，留下断头路由或删掉了默认路由；
  3. IPv6 目标 + 无 IPv6 路由：双栈解析下系统优先尝试 IPv6；
  4. 虚拟化软件的网络驱动残留：虚拟网卡驱动异常时可能劫持或破坏路由表；
  5. 睡眠唤醒后的网络栈未恢复：接口起来了，路由还没重建。

Windows 排查步骤 ​

  1. connproof doctor 确认默认路由缺失；
  2. 最快修复：禁用再启用网卡（设置 → 网络 → 高级网络设置），触发 DHCP 重新下发网关；
  3. 无效则管理员命令行 route print -4 检查 0.0.0.0 条目；netsh int ip reset 后重启是路由表损坏的兜底方案；
  4. 检查隐藏元凶：设备管理器 → 网络适配器中，已卸载软件残留的虚拟网卡（TAP/TUN 一类）逐个禁用测试。

macOS 排查步骤 ​

  1. doctor 确认；
  2. 关开 Wi-Fi 或拔插网线触发路由重建；
  3. netstat -rn | head -20 查 default 条目——多条 default 指向不同接口时，服务顺序（系统设置 → 网络 → … → 设定服务顺序）决定优先级，把正常接口拖到最上；
  4. 睡眠唤醒后频发的，更新系统与网卡驱动通常能改善。

手机端排查步骤 ​

  • 开关飞行模式：等效于整个网络栈重启，能修复绝大多数手机端路由异常；
  • 依然不行则重启设备；
  • 只有特定应用报不可达而浏览器正常 → 该应用强制 IPv6 或绑定了失效接口，查它的设置或等它更新。

TUN 模式客户端的特殊情形 ​

使用 TUN/虚拟网卡模式的代理客户端时，这条错误有一个专属变体：客户端启动时会创建虚拟网卡并把默认路由指向它，让全部流量先进隧道。此时如果客户端的核心进程卡死或隧道断开，路由还指向虚拟网卡，虚拟网卡后面却没有活着的隧道——系统层面表现为部分或全部目标不可达。判断方法：connproof doctor 的接口摘要里看到名称含 TUN/TAP/utun 的接口仍然存在，而此时代理客户端已经不工作。处理顺序：先在客户端里正常关闭 TUN 模式（让它自己清理路由），客户端已经无响应时再强制结束进程；若强杀后路由未恢复，按上文各平台步骤重建路由或重启系统。养成"先关模式再退程序"的习惯能避免绝大多数这类残留。

如何区分本地问题和节点问题 ​

这条错误由本机内核发出，必然是本地问题。唯一需要区分的是"哪一层本地"：

证据结论
默认路由缺失本机路由表（修网卡/路由）
仅 IPv6 不可达地址族配置（优先 IPv4）
仅代理客户端报错、直连正常客户端的 TUN 路由配置
所有设备都不可达路由器/宽带侧（重启路由器）

仍未解决时收集什么信息 ​

  • ConnProof 错误码（TCP-004）与 doctor 脱敏输出；
  • 操作系统版本；
  • 触发前的操作（退出了什么软件、是否睡眠唤醒）；
  • IPv4/IPv6 对照结果。

禁止提交：完整订阅链接、密码、验证码、私钥、Token。

重新运行检测 ​

connproof doctor

修复后"默认路由"应显示存在，随后的 connproof tcp 检测应能正常建连或得到网络侧的真实回应。

相关文档 ​

更新记录 ​

  • 2026-07-28：规则 v1 发布，收录三类路由落空场景与平台修复步骤。