「节点全红」和「Network Error」是两条最没信息量的报错：前者是客户端做完全部节点的探测后给的结论，后者是浏览器把跨域请求失败的原因全部吞掉之后的占位符。它们都不指认根因。真正能指认根因的，是内核日志里那行 dial、是 curl 的退出码、是 ERR_TUNNEL_CONNECTION_FAILED 这种具体的 net 错误名。这篇按「你看到的文案」倒着查：一条文案对应一组成因，每个成因只给一个 30 秒内能做完的验证动作。日常用自由猫这类自带客户端的机场时，客户端日志和内核日志经常混在一起，先把「谁打印的」分清，能省掉大半折腾。
一、先分清文案是谁打印的：四层归属法
同一个故障，四层会给出四种文案，而且互相矛盾。判错层，就会一直在错的层里改配置。
| 层 | 典型文案 | 它确切说明了什么 | 它没有说明什么 |
|---|---|---|---|
| ① 客户端 GUI | 「节点全部不可用」「连接失败」「Network Error」 | GUI 自己的一次探测/一次请求失败了 | 失败在 DNS、TCP、TLS 还是目标站 |
| ② 内核日志 | [TCP] dial G ... error: connect: connection refused | 内核在哪一步 dial、用的哪个策略组、错误原文 | 出口之后的服务器是不是也在限速 |
| ③ 系统 / 浏览器 | ERR_TUNNEL_CONNECTION_FAILED、ERR_NAME_NOT_RESOLVED | 浏览器到代理端口这一段发生了什么 | 代理到目标站之间发生了什么 |
| ④ 目标站 | HTTP 403 / 1015、unsupported_country_region_territory | 目标站对出口 IP的判定 | 链路质量、协议是否被识别 |
归属法只有一条用法：从下往上看，谁给出了更具体的词，就从谁开始查。GUI 说「全部失败」没有价值，内核日志说 connect: connection refused 有，浏览器说 ERR_TUNNEL_CONNECTION_FAILED 也有——后者直接指向「CONNECT 隧道没建起来」，也就是内核到节点的 dial 阶段，而不是证书问题。
还有一条容易被忽略：客户端显示的错误，往往是根因的下游表现。实测里最能说明问题的一组：把策略组切到一个端口未监听的节点，内核日志写的是 dial tcp 127.0.0.1:7899: connect: connection refused，而同时用 curl 走客户端混合端口拿到的却是 SSL_ERROR_SYSCALL——一个 TCP 层的拒绝，被上层包装成了 TLS 层的错误。只盯着 SSL_ERROR_SYSCALL 去查证书，方向就全错了。
如果你手上的故障已经跨了好几个客户端、好几个机场，那它多半不是单点问题。先按客户端故障排查的五层定位模型把范围压到一层，再回到这篇按文案反查——两篇的分工是：那篇讲「先分层」，这篇讲「层内怎么对号」。
二、12 种成因总表：一条文案对应一个动作
下表把常见文案按「成因编号」排开。编号在后面的章节里逐一展开，每个都给可复现的原始输出，方便你对着自己机器上的字串比对。
| # | 你会看到的文案（原文） | 打印者 | 成因 | 30 秒验证 |
|---|---|---|---|---|
| 1 | unsupport proxy type: xxx / unknown method: xxx / proxy [xxx] not found | 内核启动校验 | 配置里的类型、加密方式或策略名，这个版本的内核不认识 | 内核 -t -f 配置 做一次纯校验 |
| 2 | bind: address already in use | 内核启动 | 代理端口被别的进程占了（内核却不退出） | ss -lntp | grep 端口 |
| 3 | connect: connection refused | 内核 dial | 节点端口没开 / 服务没起 / 防火墙 REJECT | 同 IP 同端口换一个已知开放的端口试 |
| 4 | i/o timeout / connect: no route to host | 内核 dial | IP 被黑洞、路由不可达、机房侧丢弃 | 对 RFC 5737 保留地址做对照探针 |
| 5 | lookup xxx: no such host / Could not resolve host | 内核 DNS / curl | 节点域名废了、只在特定 DNS 下可解、本地被污染 | dig +short @1.1.1.1 域名 与本地解析对比 |
| 6 | Connection reset by peer | 内核 / curl | 链路上有设备主动发 RST（GFW、运营商、机房 ACL） | 看断开时刻：握手后 1-3 秒内被断 |
| 7 | Empty reply from server / EOF | 内核 / curl | 对端 accept 后立刻关闭，或 fallback 没配 | 换一个 SNI/伪装域名再试同一节点 |
| 8 | wrong version number / SSL_ERROR_SYSCALL | TLS 库 | TLS 打到了明文端口，或传输层/端口写错 | 用 openssl s_client 直连该端口看是否回 TLS |
| 9 | certificate has expired / self-signed certificate / no alternative certificate subject name matches | TLS 库 | 证书本身的问题：过期、自签、SNI 与证书不符 | openssl s_client -servername 域名 看链 |
| 10 | CONNECT tunnel failed, response 407（或 403） | 本地/上游代理 | 上游代理要认证、被限流，或端口不是代理协议 | 带账号再试，或换 socks5h 直连 |
| 11 | ERR_TUNNEL_CONNECTION_FAILED / ERR_PROXY_CONNECTION_FAILED / ERR_NAME_NOT_RESOLVED / ERR_HTTP2_PROTOCOL_ERROR | 浏览器 | 浏览器到本地代理这一段断了，或 TUN 下 DNS 没接管 | 同一条 URL 用 curl 走同端口复现 |
| 12 | Network Error、HTTP 403 / 1015、unsupported_country_region_territory | 网页 JS / 目标站 | 代理已经通了，是目标站按出口 IP 拒了你 | 访问 ipinfo.io 看出口 ASN 与归属 |
先记住一个区分，后面每一节都会回到它：成因 1-2 是「内核没准备好」，3-7 是「到节点的链路不通」，8-10 是「通了但握不上手」，11-12 是「代理这一段已经成了，问题在出口之后」。四组的处置手法完全不同：第一组改配置，第二组换节点或查域名，第三组查协议与证书，第四组换出口。
三、第一组：内核没起来（成因 1-2）
成因 1：内核不认识配置里的东西
订阅转换器、机场面板、别人发的配置，这三处的产物经常和本机内核版本对不上。内核在 启动校验阶段就会拒绝，报错里带行号或下标，定位很快。用 Mihomo Meta v1.19.32 实测三种，原始输出如下（-t 只校验不启动）：
$ mihomo -t -f bad-cipher.yaml
level=error msg="proxy 0: ss 192.0.2.1:8388 cipher: aes-256-notreal initialize error: unknown method: aes-256-notreal"
configuration file /tmp/errtest/c2.yaml test failed
$ mihomo -t -f bad-type.yaml
level=error msg="proxy 0: unsupport proxy type: vless-notreal"
$ mihomo -t -f bad-rule.yaml
level=error msg="rules[0] [DOMAIN-SUFFIX,google.com,不存在的策略] error: proxy [不存在的策略] not found"三条信息量都很大：proxy 0 是第一项，rules[0] 是第一条规则，错误原文直接点名 unknown method（加密方式不在支持表）与 unsupport proxy type（类型不认识）。注意第二个是内核自己的拼写（unsupport 少一个 ed），搜日志时不要按标准英文去搜。
为什么这一组值得单独列：它的表现常常是「客户端里节点列表一片空白」或者「策略组里只剩 DIRECT」，而不是红点。用户会以为订阅没拉到，其实是拉到之后被内核丢掉了几项。先跑一次 -t 校验，比在 GUI 里反复重订阅快得多。
成因 2：端口没绑上，但内核还在跑
这条最阴。实测：先让另一个进程占住 17892 端口，再用同一端口启动内核，日志是
level=info msg="RESTful API listening at: 127.0.0.1:19091"
level=error msg="Start Mixed(http+socks) server error: listen tcp 127.0.0.1:17892: bind: address already in use"
level=info msg="Start initial compatible provider default"关键在最后两行：报完 bind 错误之后，进程没有退出，退出码是 0，API 端口正常监听，策略组正常初始化。也就是说 GUI 会显示「运行中」，你看得到节点列表、点得动切换，但代理端口根本不属于它。浏览器此时若配了 17892，实际连的是占住端口的那个进程（可能是上次没退干净的旧实例）——于是所有网站都打不开，而日志里一粒红字都没有后续。
验证只要一条：ss -lntp | grep 17892，看 PID 是不是你刚启动的内核。不是，就说明有两个实例在抢端口；pgrep -af mihomo 清掉旧的再起。
四、第二组：到节点的链路不通（成因 3-7）
成因 3：connection refused —— 对方明确拒绝
内核日志的实际格式（Mihomo v1.19.32，策略组 G 选中 refused 节点）：
level=warning msg="[TCP] dial G (match DomainSuffix/example.com) 127.0.0.1:57546 --> example.com:443 error: 127.0.0.1:7899 connect error: dial tcp 127.0.0.1:7899: connect: connection refused"这行把四件事一次讲完：命中的规则（DomainSuffix/example.com）、用的策略组（G）、真正拨号的目标（127.0.0.1:7899，注意不是 example.com:443）、以及 Go 的原始错误。看到 connection refused 就不要再查证书、查 DNS 了——对方的 TCP 栈回了 RST，端口上没有监听。常见原因是端口写错（把 443 写成 8443）、服务端进程没起、防火墙策略是 REJECT 而不是 DROP。
和成因 4 的区别值得背下来：refused = 有回应但拒绝；timeout = 没有回应。前者说明网络通、端口关；后者说明包被吞了，可能根本不是节点的问题。
成因 4：i/o timeout / no route to host —— 包被吞了
实测用 RFC 5737 的保留地址做探针：curl -m 5 https://192.0.2.1 返回 curl: (28) Connection timed out after 5002 milliseconds。这个地址按标准不可能有人应答，所以它必须超时——如果你的测试台架对这个地址也能「连上」，那台架测的不是网络，是它自己。这一条是所有网络排障的前置自检。
节点超时的两类原因要分开：一类是 IP 段被整体黑洞（包出去没有回音，表现为稳定的 100% 丢包）；另一类是服务端过载或限速到握手都完不成（表现为时快时慢、偶尔能通）。判别方法是同 IP 换端口、换个时间段各测三次，前者恒定、后者抖动。
成因 5：no such host —— 域名这一层就废了
curl 的原文是 curl: (6) Could not resolve host: this-host-does-not-exist-abcxyz.example，内核里对应 Go 的 lookup xxx: no such host。这一组在机场场景里出现的频率被严重低估，原因有三个：
- 机场换了订阅/节点域名，旧配置里的域名已经下线。节点还在，域名解析不出来了——症状是「部分节点红、部分正常」，因为新旧域名混在一份订阅里。
- 节点域名只在特定 DNS 下可解。有的服务商用内部 DNS 或分区域解析，你的本地 DNS 拿到的是空答案。验证：
dig +short @1.1.1.1 节点域名与dig +short 节点域名对比，两者不一致就属于这类。 - 本地 DNS 被污染或劫持。返回一个不属于该服务商的地址，表现是解析「成功」但连不上——这时候报错会走到成因 4 或 6，而不是 no such host，所以别只按字面查。
这也是选机场时值得看「域名与订阅是否长期稳定」的原因之一：频繁换域名的服务商，你的旧配置会在某天早上集体变红。像瑶瑶领先这种订阅走标准 Clash 格式、域名不常变的，至少不会让你在「域名失效」和「节点被墙」之间反复猜。真遇到订阅域名整体不通、节点列表被清空这类事故，处置顺序在订阅链接应急手册里写得比较细，不要在这里盲目重置链接。
成因 6：Connection reset by peer —— 有人替你按了挂断
实测用一个发 RST 的最小服务端（SO_LINGER 设为 on/0 后立即 close）复现，curl 原文：
$ LC_ALL=C curl -sS -m 5 http://127.0.0.1:18082/
curl: (56) Recv failure: Connection reset by peer顺便记一个坑：不设 LC_ALL=C 时，同一条错误在中文 locale 下显示为「连接被对方重置」。curl 的文案是本地化的，写脚本抓错误时要么固定 locale，要么直接判退出码 56，别去 grep 中文。
RST 的判别价值在时间维度：正常的服务端异常关闭一般发生在请求处理之后，而被中间设备干预的 RST 往往出现在握手完成后的 1-3 秒内，而且同一个目标反复重试都是同样的间隔。如果你看到「刚连上就断、每次都一样快」，就不用怀疑密码或加密方式了，那是链路上的主动干预。
成因 7：Empty reply from server —— 连上了，但对面一句话不说
实测一个 accept 后立刻 close 的服务端：curl: (52) Empty reply from server。在代理场景里，这一条通常出现在三种情况：服务端的 fallback 没配好（非代理流量进来后无处可去，直接断开）；SNI 与伪装域名不匹配被服务端主动丢弃；或者中间设备只放行了 TCP 握手，之后不再转发任何数据。
第三个情况和成因 6 很像，区别在于有没有 RST：收到 RST 是 56，什么都没收到是 52。判据是 ss -ti 看连接最终状态，或者干脆在客户端开 debug 日志看是否读到了 0 字节。
五、第三组：通了但握不上手（成因 8-10）
成因 8：wrong version number —— TLS 打到了明文端口
实测：对着一台只会回 HTTP 明文的服务端发起 https 请求，TLS 库的原文是
$ curl -sS -m 5 https://127.0.0.1:18443
curl: (35) OpenSSL/3.0.13: error:0A00010B:SSL routines::wrong version numberwrong version number 的直译是「版本号不对」，实际含义是：客户端发了 ClientHello，对面回的字节不像 TLS 记录。所以它几乎总是配置问题——把 TLS 打到了明文端口、把 ws 打到了 wss 端口、把 REALITY 的端口写成了普通 vless 端口。这一条不该让你去动证书。
同一类里还有一个更迷惑的：SSL_ERROR_SYSCALL。前面提过，它可能只是 dial 被拒在上层的表现。区分动作很简单：先确认 dial 阶段有没有日志。内核日志里已经有 connection refused 或 i/o timeout，那么 SSL_ERROR_SYSCALL 就是下游症状；内核日志里一片安静，才轮到查 TLS 本身。
做协议对照时，一次只动一个变量：换端口不换协议、换协议不换入口、换节点不换协议。SS-ID 这类纯 IEPL 线路的服务商好处就在这里——线路单一、协议标准，出问题时能直接把「协议层」和「线路层」分开验证，不用在十几种协议组合里试。
成因 9：证书三连 —— 过期、自签、名字不符
三条文案都实测过，含义完全不同：
$ curl -sS https://expired.badssl.com
curl: (60) SSL certificate problem: certificate has expired
$ curl -sS https://self-signed.badssl.com
curl: (60) SSL certificate problem: self-signed certificate
$ curl -sS https://wrong.host.badssl.com
curl: (60) SSL: no alternative certificate subject name matches target host name 'wrong.host.badssl.com'| 文案 | 确切含义 | 代理链路里的常见来源 |
|---|---|---|
certificate has expired | 证书的 notAfter 已过 | 服务端证书没续期；或本机时间错到未来 |
self-signed certificate | 证书链的签发者不在信任库里 | 服务端压根没配正式证书；CDN 回源用了自签；企业/校园网做了中间人 |
no alternative certificate subject name matches | SNI 送的域名不在证书的 SAN 里 | 伪装域名写错、CDN 回源域名与证书不一致 |
要注意第三种：它的报错文本里会把你请求的域名一起打出来，对着看就知道是「你要的域名」和「证书给的域名」谁不对。这一条在 CDN 中转场景里最常见——回源域名没写对，证书是对的，但名字对不上。
成因 10：CONNECT tunnel failed —— 隧道没建起来
实测：让一个本地服务对 CONNECT 请求回 407，curl 走它访问 https 站点：
$ curl -sS -m 5 -x http://127.0.0.1:18080 https://example.com
curl: (56) CONNECT tunnel failed, response 407这一条的判读极快：HTTP 代理在 CONNECT 阶段就给了非 200，后面的 TLS 和证书一点关系都没有。407 是要认证（账号密码没填、填错、或订阅里的认证信息过期），403 是策略拒绝（IP 不在白名单、套餐到期、并发超限）。另外还有一种伪装成这一类的情况：端口上跑的根本不是代理协议（比如把 web 端口填成了代理端口），那时你拿到的可能是一个 400 或者一个 HTML 页面。
六、第四组：代理这一段成了，问题在出口之后（成因 11-12）
成因 11：浏览器层错误码 —— 它比 GUI 更精确
Chromium 的 net 错误名是排障里信息密度最高的东西，因为它区分到了具体动作。对照 curl 的退出码看，同一件事说法不同：
| 浏览器错误名 | 对应 curl 退出码 | 含义 |
|---|---|---|
ERR_PROXY_CONNECTION_FAILED | 7 | 连不上本地代理端口（内核没起、端口不对） |
ERR_TUNNEL_CONNECTION_FAILED | 56 | CONNECT 被拒或隧道没建起来 |
ERR_CONNECTION_REFUSED | 7 | 目标端口拒绝（TUN 模式下直连被拒） |
ERR_CONNECTION_TIMED_OUT | 28 | 包被吞，没有回应 |
ERR_CONNECTION_RESET | 56 | 收到 RST |
ERR_EMPTY_RESPONSE | 52 | 连上但零字节 |
ERR_NAME_NOT_RESOLVED | 6 | DNS 没解析出来（TUN 下常见：DNS 没被内核接管） |
ERR_SSL_PROTOCOL_ERROR | 35 | TLS 层报文不对（对应成因 8） |
ERR_CERT_DATE_INVALID / ERR_CERT_AUTHORITY_INVALID / ERR_CERT_COMMON_NAME_INVALID | 60 | 证书过期 / 不受信 / 名字不符（对应成因 9 的三条） |
ERR_HTTP2_PROTOCOL_ERROR | — | HTTP/2 帧被破坏，常见于 MTU 黑洞或中间设备改写 |
ERR_HTTP2_PROTOCOL_ERROR 值得单独说：它既不是连不上也不是证书问题，而是「连上了、握手也成了，但 HTTP/2 的帧损坏」。代理链路上最常见的原因是 MTU——大包过不去，小包能过，于是首页能开、图片和视频全废。判别动作是把 MTU 往下调一档或临时关掉 HTTP/2 再试。这个故障的坑在于症状漂移：同一台机器上有的站正常有的站崩，很容易被当成「机场某些节点坏了」。
另一条经验：浏览器报错能复现的，一定要用 curl 复现一次。curl -x 本地端口 -v 的输出里既有 CONNECT 的响应，也有 TLS 的细节，比浏览器那一行黑话清楚一个量级。反过来，如果是网页 JS 里报 Network Error（axios / fetch 抛的那种），浏览器压根不给原因——跨域策略把它吞了。这时唯一的办法是开 DevTools 的 Network 面板看那条请求的 status 是不是 (failed)，再用同样的 URL 走 curl。
成因 12：Network Error 之后，目标站其实在拒你
这一组最容易被误判成「节点坏了」，因为它在客户端里也表现为「打不开」。但判据很清楚：别的站能开，只有特定几个站打不开，而且这几个站都属于风控敏感类（AI 服务、流媒体、电商后台、支付网关）。典型文案有三种：网页 JS 层的 Network Error、Cloudflare 的 403 / 1015（rate limited）、以及 OpenAI 的 unsupported_country_region_territory。
它们的共同点是：链路是通的，被拒的是出口 IP 的「属性」。机房 IP、被大量用户共用的出口、被标记过的 ASN，都会被直接判定为高风险。同一台机器换一个节点就好、换回来又坏，就是这个原因。这也是为什么做跨境多账号、流媒体解锁这类场景时，出口 IP 的归属比线路的延迟更重要——仙路湾这类提供住宅/原生 IP 的服务，解决的正是「通不通」之外的这一层。
验证动作一条就够：访问 ipinfo.io 或 ipinfo.io/<ip>/json，看 org 字段是住宅宽带还是 hosting。是 hosting，那目标站拒你的理由就成立，不用再去调客户端。
七、十分钟三层对照流程
12 种成因落到操作上，其实就是三个判断题，按顺序做，不要跳。
| 步骤 | 动作 | 结果 → 结论 |
|---|---|---|
| ① 端口 | ss -lntp | grep 端口 + curl -m 5 -x http://127.0.0.1:端口 http://www.gstatic.com/generate_204 | 连不上 → 成因 2 或 11（内核没起/端口不对） 204 → 进 ② |
| ② 直连对照 | 去掉代理，curl -m 5 https://目标站 | 直连也失败 → 问题在本地网络或目标站，不在代理（成因 4/12） 直连正常 → 进 ③ |
| ③ 节点 | 看内核日志有没有 [TCP] dial 行，并读那行的 error | 有 error → 按成因 3-10 对号 无 dial 行 → 规则没命中，查规则与策略组（成因 1） |
三个步骤之外只有一条纪律：一次只动一个变量。换节点、换协议、换端口、换入口（直连/中转/CDN）四件事同时改，就算好了你也不知道是哪一步修好的，下次还会复发。真正做对照时，用「同一目标 + 同一端口 + 同一协议」只换节点，或者「同一节点 + 同一端口」只换协议。如果你手上同时有多个机场订阅、想让客户端在某个节点故障时自动切走而不是等你发现红点，那套做法在多机场策略组与故障转移配置里——那是「预防」，这篇是「事后对号」。
八、把这 10 条报错造出来：可复现的台架（成因 1-10）
排障文章最容易犯的错，是给你一堆看着像真的报错文案。下面这套台架是我这次实际跑的，任何人都能在自己的机器上重放，输出对得上才说明判读方法成立。工具：curl 8.5.0、Mihomo Meta v1.19.32。
第 0 步：先证明台架不会「全部成功」。用 RFC 5737 的保留地址做控制探针，这两个地址按标准不可能是任何真实服务：
$ curl -m 5 https://192.0.2.1
curl: (28) Connection timed out after 5002 milliseconds
$ curl -m 5 https://198.51.100.7
curl: (28) Connection timed out after 5002 milliseconds第 1 步：配置校验（造成因 1 的三条）。把 cipher 写成一个不存在的方法、把 type 写成不存在的协议、把规则指向不存在的策略名，各跑一次 -t，就得到第三节那三条输出。
第 2 步：端口占用（造成因 2）。用一个 python 进程先 bind 住端口，再启动内核，看日志里的 bind: address already in use，同时确认进程没有退出——echo $? 是 0。
第 3 步：五种链路故障的最小服务端（造成因 3、6、7、8、10）。核心只有五行代码的思路：
# refused：什么都不监听（端口空着）
# reset：accept 后设 SO_LINGER(1,0) 再 close，内核会发 RST
c.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack('ii', 1, 0)); c.close()
# empty：accept 后直接 close（不发 RST）
# plain：accept 后回一行 HTTP/1.1 400，用来冒充「明文端口」
# 407：对 CONNECT 回 HTTP/1.1 407 Proxy Authentication Required第 4 步：节点侧（造「全红」）。把节点的 server 指向 192.0.2.1，通过内核的延迟测试接口探测，实测三种返回：
GET /proxies/deadnode/delay?timeout=3000&url=http://www.gstatic.com/generate_204
{"message":"Timeout"}
GET /proxies/refused/delay?timeout=3000&url=http://www.gstatic.com/generate_204
{"message":"An error occurred in the delay test"}
GET /proxies/DIRECT/delay?timeout=3000&url=http://www.gstatic.com/generate_204
{"delay":38}这三行是「全红」的真相：不可达给 Timeout，被拒给一句通用的 An error occurred in the delay test。客户端把两者都画成红点，所以红点里没有任何根因。DIRECT 拿到 38ms 是台架自检——如果连 DIRECT 都 Timeout，那说明本机出网就有问题，此时任何节点结论都不成立。
第 5 步：locale。同一条错误在中文环境显示为「连接被对方重置」，英文环境是 Connection reset by peer。批量脚本里加 LC_ALL=C，或者直接判退出码（6/7/28/35/52/56/60），别 grep 文案。
把上面五步的结果并排放在一起，就是一张「成因 ↔ 复现方式 ↔ 实际原文」的对照表。这张表比任何口诀都可靠，因为它每一行都有机器输出兜底：
| 成因 | 怎么造出来 | 实际拿到的原文 |
|---|---|---|
| 1 类型/加密不认识 | 写一个不存在的 type、不存在的 cipher、指向不存在的策略名 | unsupport proxy type: vless-notreal / unknown method: aes-256-notreal / proxy [不存在的策略] not found |
| 2 端口被占 | 先用另一个进程 bind 住同一端口，再起内核 | Start Mixed(http+socks) server error: listen tcp 127.0.0.1:17892: bind: address already in use，进程退出码 0 |
| 3 拒绝连接 | 策略组指向一个没人监听的本地端口 | dial tcp 127.0.0.1:7899: connect: connection refused |
| 4 超时 | 目标设为 RFC 5737 保留地址 192.0.2.1 | Connection timed out after 5002 milliseconds |
| 5 域名不存在 | 访问一个未注册的域名 | Could not resolve host: this-host-does-not-exist-abcxyz.example |
| 6 RST | 服务端 SO_LINGER(1,0) 后立刻 close | curl: (56) Recv failure: Connection reset by peer |
| 7 空回复 | 服务端 accept 后直接 close，不发 RST | curl: (52) Empty reply from server |
| 8 明文端口 | 对着只会回 HTTP 的端口发 https 请求 | error:0A00010B:SSL routines::wrong version number |
| 9 证书三连 | 访问过期 / 自签 / 域名不符的三个测试站 | certificate has expired / self-signed certificate / no alternative certificate subject name matches |
| 10 CONNECT 拒绝 | 假代理对 CONNECT 回 407 | curl: (56) CONNECT tunnel failed, response 407 |
成因 11 和 12 没有放进这张表，原因得说清楚：前者要真实浏览器才会打印 ERR_* 名字，后者要真实目标站才会给出 403 或地区限制——它们没法在本地台架上「造」出来，所以上面两节给的是判据与映射关系，不是实测原文。这条界线值得所有写排障文的人守住：能重放的写成实测，不能重放的只写判据，别把「我看过别人这么说」包装成「我测过」。
台架本身也有一个自检顺序：先测 RFC 5737（必须超时），再测 DIRECT 出口（必须有延迟数字），最后才测故障节点。跳过前两步，你拿到的「全部超时」可能只是本机没网——那是最常见的一次误判，而且它会让后面所有的结论都失效。
九、六个最常见的误判
- 文案一样，就当原因一样。实测里
SSL_ERROR_SYSCALL既可能来自 dial 被拒，也可能来自链路上被断开。文案相同只说明「上层动作失败」，原因要看内核对dial那一步的记载。 - 全红就当机场跑路。先做 DIRECT 对照：如果直连
generate_204也不通，问题在本机网络；如果本机正常而全部节点红，再看订阅是否过期、域名是否失效，最后才怀疑服务商。 - 用 ping 判断节点死活。ICMP 是最容易被丢弃的协议，很多服务器直接不回 ping 但 443 完全正常。判据要用 TCP：
curl -m 5 -x走代理，或者对端口做一次握手。 - 证书过期就调本机时间。本机时间错到未来确实会这样，但更多时候是服务端真的没续期。先看
openssl s_client里的 notAfter，再核本机date。 - 只换节点，不换协议。如果同一入口、同一协议的多个节点同时全红，那是协议特征被针对，换节点无效。这时要换的是入口或传输方式。
- 把延迟测试的 Timeout 当带宽问题。延迟测试通常是一个很小的 HTTP 请求，它测的是「能不能在 3 秒内完成一次往返」，和吞吐没有关系。晚高峰掉速但延迟测试全绿，是完全正常的组合。
十、八个高频问题
Q1：客户端能测出延迟，但浏览器就是打不开？ 延迟测试走的是客户端自己的出口，浏览器走的是系统代理或 TUN。两者不一致时，先查系统代理设置是否指到了别的端口，再查 TUN 是否真的接管了路由（ip route 里有没有那张虚拟网卡）。
Q2：只有 Chrome 报错，别的浏览器正常？ 优先怀疑 Chrome 自带的 DoH（安全 DNS）绕过了系统 DNS，以及 QUIC——Chrome 会尝试 UDP 443，被阻断时报 ERR_QUIC_PROTOCOL_ERROR，而其他浏览器走 TCP 就没事。
Q3：手机上全部节点红，电脑上正常？ 先在手机上确认能打开 ipinfo.io 之外的任意国内站，排除 Wi-Fi 本身；再检查是否开启了「仅 Wi-Fi 代理」而当前在蜂窝网络；最后看省电策略有没有把客户端冻结（这类问题在手机息屏掉线那篇里拆得更细）。
Q4：日志里全是 dial 错误，但节点在别人机器上能用？ 出口不同。你的 ISP 到该 IP 的路径可能被针对性阻断，这不是节点故障。用 traceroute 看在哪一跳开始丢，再决定换节点还是换入口。
Q5：unsupport proxy type 一定是我配置写错了？ 不一定。订阅转换器可能吐出了新协议，而你的内核版本太旧。先升级内核，再校验配置——顺序反了会白改一遍配置。
Q6：为什么 -t 校验通过，实际运行还是不通？ -t 只校验语法与引用，不建立任何连接。它能抓到成因 1，抓不到 3-12。校验通过只说明「配置能被读进来」。
Q7：换机场能解决全部红点吗？ 能解决「服务商侧故障」，不能解决「链路上针对协议/入口的阻断」。判断方法还是三步对照：本机 → 目标站 → 节点，哪一步先坏，就在哪一步修。
Q8：报错文案我该记哪些？ 记数字，不记句子。curl 的 6/7/28/35/52/56/60、浏览器的 ERR_* 名、内核日志里的 error: 后半段，这三样在任何语言、任何客户端版本下都不变。
十一、一页速查卡
| 你看到的 | 先查这里 | 最可能的结论 |
|---|---|---|
unsupport proxy type / unknown method / proxy [...] not found | 内核 -t 校验 | 类型/加密/策略名与内核版本不匹配 |
bind: address already in use | ss -lntp | 旧实例占着端口，GUI 显示运行是假象 |
connection refused | 节点端口与服务状态 | 端口关 / 服务没起 / 防火墙 REJECT |
i/o timeout / no route to host | 同 IP 换端口、换时段 | IP 被黑洞或路由不可达 |
no such host | dig @1.1.1.1 对比本地 | 节点域名失效或被污染 |
Connection reset by peer | 断开的时间点 | 链路中间设备主动干预 |
Empty reply from server | SNI / fallback | 服务端配置缺陷或对端零字节关闭 |
wrong version number | 端口对应的传输层 | TLS 打到了明文端口 |
| 证书三类文案 | openssl s_client | 过期 / 自签 / SNI 名字不符 |
CONNECT tunnel failed, response 407 | 认证与套餐状态 | 上游代理要认证或被策略拒绝 |
ERR_TUNNEL_CONNECTION_FAILED 等 ERR_* | curl 走同端口复现 | 浏览器到本地代理这一段断了 |
Network Error / 403 / unsupported_country... | ipinfo.io 看出口 ASN | 链路通，出口 IP 属性被拒 |
如果只记一句话：红点是没有信息的结论，日志里的 error: 后半段才是指纹。把「谁打印的」认对，比记住任何一条具体文案都管用——客户端的文案会随版本和语言变，内核的错误串和 curl 的退出码不会。
推荐阅读
- 软路由侧的科学上网故障排查——同样的报错，发生在路由器上时要看的地方完全不同。
- 同一份订阅换四款客户端：类型名映射与丢节点——解释为什么同一个节点在 A 客户端能用、在 B 客户端直接消失。
- TLS 指纹与 JA3/JA4 伪装原理——想弄清「证书没问题但握手总失败」的那一层。