client connected but no internet：显示已连接却无法上网
CLIENT-001
client connected but no internet严重程度 High一句话结论
客户端只是成功连上了节点，不代表节点后面的路是通的。最可能是节点出口故障或代理模式下的 DNS 解析失败；第一步是切换一个不同地区的节点做对比。
适用环境WindowsmacOSLinuxAndroidiOS
适用客户端通用客户端
最后验证：2026-07-28规则版本：v1内容更新：2026-07-28
结论
“已连接”这三个字的真实含义比大多数人以为的窄得多：它通常只表示你的设备与节点服务器之间的隧道建立成功。而一次成功的网页访问还需要后面三段全部正常——节点能解析目标域名、节点的出口能到达目标网站、响应能原路返回。这条报错的本质是：第一段通了，后面某一段断了。排查的核心就是定位断在哪一段。
适用环境
- 全部桌面与移动平台
- 所有显示"已连接/运行中"状态的代理客户端
一分钟快速判断
- 换一个不同地区的节点。恢复 → 原节点出口故障，结案；仍不通 → 继续；
- 访问 IP 直达目标：在浏览器打开一个纯 IP 的测试地址（如你的服务商提供的 IP 测试页）。IP 能通而域名不通 → DNS 问题，跳到 DNS 一节；
- 看是不是只有部分应用不通。浏览器通、某应用不通 → 这是另一条错误，转 browser works but application fails。
这条错误代表什么
把一次代理访问拆成四段：设备→节点（隧道）、节点解析域名（远程 DNS）、节点→目标（出口线路）、目标→节点→设备（回程）。客户端状态栏里的"已连接"只覆盖第一段。最容易断的是第二段和第三段：
- 远程 DNS 失败：代理模式下域名通常由节点侧解析，节点的 DNS 出问题时，你这边的表现就是"连着但什么都打不开"，而且往往是所有域名一起失败；
- 出口故障：节点服务器本身健康（隧道能建立），但它的上游线路或出口 IP 被目标网络屏蔽、或流量耗尽被限速到不可用。
ConnProof 如何判断
保持客户端连接状态，运行：
connproof diagnose 常用网站域名对照证据：
| 证据组合 | 指向 |
|---|---|
| DNS 失败、TCP/TLS 跳过 | 代理链路上的 DNS 解析问题 |
| DNS 成功、TCP 超时 | 出口不通或分流规则把流量引入了黑洞 |
| 全部通过但浏览器仍不通 | 浏览器自身代理设置或缓存问题 |
再运行 connproof doctor 确认系统代理确实指向客户端监听的端口——"已连接但系统代理没接上"也会造成类似表现（那属于 PROXY-002 的变体）。
最常见原因
- 节点出口故障或被目标屏蔽：隧道正常、出口废了。换节点立即恢复是其特征；
- 代理模式下的 DNS 配置问题：客户端 DNS 设置为本地解析但本地解析被污染，或远程解析服务失效；
- 流量/配额耗尽：部分服务在超量后不断连而是限速到接近于零，表现为"连着但巨慢/超时"；
- 分流规则错误：自定义规则把目标域名指向了 DIRECT 而当前网络直连不了它，或指向了已失效的节点组；
- 系统代理未正确接管：客户端认为自己在服务，流量实际没走它。
Windows 排查步骤
- 换节点对比（最快的一步，别省略）；
connproof diagnose <常用域名>拿分层证据；- 若 DNS 层失败：在客户端设置里切换 DNS 模式（本地解析 ↔ 远程解析）后复测；
connproof doctor核对系统代理指向与客户端监听端口是否一致；- 登录服务方面板看流量余额——超量限速的提示往往只在面板里。
macOS 排查步骤
- 同样先换节点、跑 diagnose；
- macOS 的增强模式/TUN 模式客户端检查虚拟网卡是否创建成功（
connproof doctor的网络接口摘要里应能看到）； - 浏览器单独不通时，检查浏览器自身的代理扩展是否与系统代理叠加冲突。
手机端排查步骤
- 换节点、开关飞行模式（强制重建网络栈）各试一次；
- iOS 客户端在系统 VPN 状态图标存在的前提下不通，多为节点侧问题；图标消失说明隧道根本没建立，回到客户端重连；
- Android 部分系统的"私人 DNS"（DoT）设置会绕过代理的 DNS 处理，排查期间将其设为"自动"或关闭后复测。
如何区分本地问题和节点问题
| 证据 | 更可能是 |
|---|---|
| 换节点恢复 | 原节点出口 |
| 所有节点都"连着但不通" | 本地 DNS/系统代理/分流配置 |
| IP 通而域名不通 | DNS 链路 |
| 面板显示流量超限 | 配额（服务方规则，非故障） |
| diagnose 全通但浏览器不通 | 浏览器/应用自身设置 |
"连着但特别慢"算不算这条错误
介于"通"与"不通"之间还有一个灰色地带：页面能打开一半、图片加载不出、视频反复缓冲。它与本页错误共享大部分排查路径，但证据解读略有不同：diagnose 三层全部通过而体验极差，通常指向节点带宽拥塞或流量限速，而不是链路断裂。这种情况下换节点对比依然是第一手段；如果所有节点都慢，检查服务方面板的流量余额与限速说明，并留意本地网络本身的上传是否被其他应用（网盘同步、系统更新）占满——上行拥塞会让代理连接的表现雪上加霜。把"慢"与"不通"区分开上报，能让服务方少走一半弯路。
仍未解决时收集什么信息
- ConnProof 错误码（CLIENT-001）与脱敏报告（diagnose + doctor）；
- 客户端名称和版本、操作系统版本；
- 换节点对比结果；
- 失败检测层级与问题发生时间。
禁止提交：完整订阅链接、密码、验证码、私钥、Token。
重新运行检测
connproof diagnose 常用网站域名 --format markdown --output diag.md修复后 DNS、TCP、TLS 三层应全部通过，浏览器访问恢复。
相关文档
更新记录
- 2026-07-28：规则 v1 发布，建立"四段链路"分析框架。