是机场问题还是我的问题：用三次对照分清责任边界
连接坏了，第一个念头往往是"这家不行了"。但在实际排查里，被归咎于服务端的故障有相当一部分出在本地——系统时间偏差、代理残留、订阅地址过期、客户端内核版本太旧。这些问题换十家服务也不会好。
这篇文章给出一套十分钟内能跑完的判断流程：三次对照划定范围，分层证据锁定责任。结论不依赖感觉，依赖你自己跑出来的数据。
三十秒版本
按顺序做三次对照，每次只改一个变量：
| 对照 | 怎么做 | 恢复了说明 |
|---|---|---|
| 换网络 | 切到手机热点，重试同一操作 | 原网络的出口或策略有问题 |
| 换节点 | 换一个不同地区的节点 | 原节点或其线路有问题 |
| 关代理直连 | 关掉客户端，直接访问任意网站 | 基础网络本身就断了 |
三次都不恢复，问题在你的本地环境（配置、系统、客户端），不在服务端。
这三步能覆盖大部分场景。想拿到能发给客服的证据，继续往下看。
为什么"感觉"靠不住
三个认知陷阱，每个都会让人误判：
一、网络故障是间歇的。 你重试三次都失败就下结论"坏了"，但同一时刻可能有另一条路径是通的。人对间歇性故障的直觉极差——我们倾向于把连续两次失败读作"必然失败"。
二、症状会伪装。 系统时间偏差会让所有节点的 TLS 握手统一失败，表现和"服务商全线崩了"一模一样。代理残留会让整台电脑断网，看起来更像是服务端的问题。两者都在你这一侧。
三、最近改动的东西最可疑，但最不容易被想起。 昨天升级了客户端、前天系统更新过、上周改了 DNS——这些都比"服务商今天出故障了"概率更高，却很少被第一时间怀疑。
对照实验能绕开这三个陷阱：它不问"是不是坏了"，只问"改变哪个变量之后行为变了"。
分层证据：失败在哪一层就归谁
一次连接要经过四段路：域名解析、TCP 建连、TLS 握手、应用层对话。ConnProof 的分层检测会告诉你卡在哪一段，而每一段的失败有各自的归属倾向：
connproof diagnose 节点域名 --port 节点端口| 失败层 | 典型错误码 | 更可能是谁的问题 |
|---|---|---|
| DNS 解析 | DNS-001、DNS-002 | 本地网络或 DNS 配置 |
| TCP 建连超时 | TCP-001 | 链路或出口策略 |
| TCP 被拒绝 | TCP-002 | 服务端（端口无服务） |
| TLS 握手超时 | TLS-002 | 链路干扰 |
| TLS 证书校验失败 | TLS-001 | 优先查本地系统时间 |
| 订阅返回 5xx | HTTP-003 | 服务端 |
| 订阅返回空 | SUB-002 | 服务端（常为账号状态） |
注意 TLS-001 那一行：证书校验失败最常见的原因不是服务端证书坏了，而是你的系统时间不准。这是"看起来像服务端问题，实际是本地问题"的典型代表，也是为什么下面的自查要把时间放在前面。
三次对照的完整版
对照一：换网络（判断链路）
在手机热点下重跑同一条检测。
connproof diagnose 节点域名 --port 节点端口- 热点下成功，原网络失败 → 原网络的出口对这条链路有干扰或阻断。这不是服务商的错，但服务商可能有其他线路能绕开，值得反馈；
- 两边都失败 → 排除本地网络，继续对照二。
对照二：换节点（判断单点还是全局）
在客户端里切到另一个地区的节点，重跑检测。
- 换了就好 → 原节点或它的线路有问题，属于服务端范畴，可以反馈让他们查；
- 换了还是不行 → 不是单个节点的问题，继续对照三。
对照三：关代理直连（判断基础网络与本地环境）
完全退出代理客户端，浏览器直接打开任意常用网站。
- 直连也打不开 → 基础网络断了，或者当前网络需要门户认证（酒店、校园网常见）。先修网；
- 直连正常 → 基础网络健康，问题在客户端或本地配置。跑一次本机体检：
connproof doctor重点看三项：系统时间、系统代理指向与端口监听是否一致、默认路由是否存在。
三次对照的真值表
| 换网络 | 换节点 | 直连 | 结论 |
|---|---|---|---|
| 恢复 | — | — | 原网络链路问题（可反馈，但换服务未必解决） |
| 不恢复 | 恢复 | — | 单节点/线路问题（服务端，可反馈） |
| 不恢复 | 不恢复 | 失败 | 基础网络或门户认证（本地） |
| 不恢复 | 不恢复 | 正常 | 本地配置或客户端（本地，见下节） |
只有第二行是明确的服务端责任。第四行——三次对照都指向本地——恰恰是最容易被误判成"服务商不行"的那一种。
五个最常被误判的本地问题
按发生频率排序。每一个都会表现得像"服务全线崩溃"：
1. 系统时间偏差。 主板电池没电的旧电脑、恢复出厂的手机、快照回滚的虚拟机，时间能漂走几小时到几年。后果是所有加密握手统一失败。校准后大量"证书错误"当场消失。→ TLS-001
2. 系统代理残留。 客户端崩溃或被强制结束时来不及恢复系统代理，留下一个指向空端口的设置。症状极具迷惑性：浏览器全部打不开，但不吃系统代理的程序反而正常。→ PROXY-002
3. 订阅地址过期。 服务方轮换了 token，你的客户端还在用旧地址。节点列表整体失效，看起来就是"所有节点都挂了"。→ SUB-001
4. 客户端内核版本过旧。 订阅里出现了内核不认识的协议字段，内核在启动第一步就退出。界面看着正常开着，本地端口却根本没在监听。→ PROXY-003
5. 系统级 DNS 设置干扰。 手机上的"私人 DNS"、电脑上手工配置的静态 DNS，会绕过客户端的解析处理，产生"部分域名不通"的怪象。→ DNS-001
跑一次 connproof doctor 能一次性覆盖其中的第 1、2、4、5 项。
三个确凿指向服务端的信号
反过来，出现下面任意一条，责任基本可以判给服务端：
信号一：多地区节点同时失败，而本地一切正常。 分布在不同机房、不同线路的节点不可能恰好一起坏。前提是 doctor 全绿——否则先看上一节。→ CLIENT-002
信号二：订阅地址持续返回 5xx，或账号状态正常却返回空内容。 这是服务端自己承认的错误，网络层完全无辜（DNS、TLS 都通过了）。→ HTTP-003、SUB-002
信号三：隧道建立成功但流量出不去。 客户端显示已连接，connproof diagnose 显示节点的 DNS/TCP/TLS 三层健康，但实际访问全部超时——说明节点活着而它的出口废了。→ CLIENT-001
完整命令序列
十分钟能跑完，产出的是可以直接发给客服的证据：
connproof doctorconnproof diagnose 节点域名 --port 节点端口 --format markdown --output diag.mdconnproof subscription "订阅地址" --format markdown --output sub.md报告默认脱敏，订阅地址的查询参数、Token、用户目录都会被移除——可以比较放心地转发。发送前的复查要点见脱敏说明，报告怎么读见如何阅读报告。
拿到结论之后
判给本地：按对应错误码的文档处理。这类问题修好之后是彻底解决，而不是换个地方重新踩坑。
判给服务端：把三元组交给客服——具体错误码 + 精确时间 + 出口地区。服务端日志正是按这三个键检索的。组织反馈的模板见向客服提供哪些信息。
判给链路：这是最尴尬的一类——不是你的错，也不完全是服务商的错。可行的动作是换网络出口、请服务方提供其他线路，或接受在特定网络下体验受限。
确认是服务端且长期不修——这时候换服务才是理性选择，而不是第一反应。判断标准与换之前该确认的事，见下面这一页。