代理节点是什么，节点全部超时我先翻日志找四个关键字

一个节点在我电脑里是七八行字

代理节点是客户端里的一条出站配置，七八行字，写着入口服务器的地址、端口、协议、账号凭据和 TLS 要用的几个参数。客户端照着这几行去连入口，入口再把流量送到海外的出口。一个节点对应一条配置，对应的机器不一定只有一台，也不一定只归它一个用。2026 年 6 月我给星岛梦（StarDream）做测速和解锁检测，订阅里 60 到 70 个节点，记到的出口组织只有 3 家。飞猫云 07-08 那轮 49 个节点，出口也以一家为主。几十个名字，后面是少数几个出口，这是常态。

这七八行字长什么样，拿 mihomo 内核的写法看最直观。它的文档把 name、type、server、port 列为必填，name 不能重复，server 可以是域名也可以是 IP ^[1]。VLESS 节点再加一个 uuid，开了 tls 的还有 servername 和 skip-cert-verify 两项，servername 留空时客户端拿 server 里的地址去填 ^[2]。节点以分享链接的样子出现时，协议名、凭据、地址和端口排在前面，问号后面是传输和 TLS 参数，井号后面那一段只是描述文字 ^[3]。

“香港 01”这个名字和香港没有必然关系。它是运营方手写的标签，协议里没有任何字段要求名字和落地地区对得上。无忧 07-18 那轮，有一个名字里带香港的节点，YouTube 一栏认出来的地区代码是 CN。名字末尾的 0.5x、2x 同样是手写的，面板记账时才把上传下载的字节乘以这个倍率 ^[4]。

入口和出口分开看，还能解释为什么会几十个节点一起超时。灵动云的资料里我记过一条观察，它入口地址的域名前缀和另外五家一样，是不是同一个运营方，我没有确认。入口往往是一个域名、一两个 IP，几十个节点共用。入口那条路一断，所有节点一起超时，出口那边可能什么事都没有。

更新一次订阅，客户端拿回来的东西我只盯四样

订阅链接本身只是个网址，客户端到点去取一次，取回来的就是上面那种配置的清单。清单之外还跟着几个响应头，参数不少，我只盯四样。

第一样是 subscription-userinfo。我读过的 Xboard 面板源码里，给 Clash 系客户端的这个响应头写成 upload、download、total、expire 四个数，前三个是字节，最后一个是到期时间戳 ^[5]。客户端顶上那两行已用流量和到期日，来源就是它。面板没发这个头，客户端就显示不出来，和节点好坏无关。

第二样，profile-update-interval。同一份源码把它写成 24 ^[5]，我理解为小时，客户端据此每天自动更新一次，手动更新不受这个数限制。

节点数是第三样。星岛梦的订阅我在 06-17 拿到 60 个，06-27 拿到 70 个，07-18 拿到 65 个，三次三个数。更新以后节点多了少了都正常，名字对不上的节点消失，多半是运营方换了入口或者改了名。

第四样最容易被当成节点，它是混在清单里的文字行。Xboard 有一个开关，打开以后会在清单最前面插进剩余流量、套餐到期、距离下次重置还剩多少天这三行，参数复制第一个真实节点，只把名字换成文字 ^[6]。有节点被过滤掉时，它还会插一行“过滤掉多少条线路” ^[6]。这几行拿来测延迟没有意义，看到它们，去面板上核对数字就行。我测过的 8 家各用什么面板软件，我没有逐家核过，Xboard 只是我能读到源码的一种。

全部超时，在我 8 家的记录里一次没出现过

“超时”和“慢”在日志里是两种字样。延迟测试给每个节点一个期限，mihomo 里这个期限叫 timeout，单位毫秒，期限内没拿到回应就记超时 ^[7]。拿到了回应，速度只有几 KB/s，那叫慢，日志里不会有 timeout 字样。

八轮里最差的是星岛梦 07-18 那一轮，65 个节点 11 个为 0，占 17%。其余七轮要么一行都没记到，要么只有一两行。八家、每轮 49 到 65 个节点，没有哪一轮几十个节点一起失联。客户端列表整页标红的时候，我不会先怀疑机场把所有机器关了，先怀疑入口那一条路和我自己的网络。八家各一轮，样本就这么大。

还有两组数能说明“连通”和“有速度”是两回事。跨界 07-19 那轮 50 个节点全部连通，台湾组的最低值仍然是 0。灵猫同一轮里香港 15 个节点跑在 428.71 到 545.80 MB/s，美国 10 个节点只有 7.74 到 12.95 MB/s，差了几十倍，可美国这 10 个一个都没超时。

日志在哪看。mihomo 的 log-level 分 silent、error、warning、info、debug 五档 ^[8]，排错的时候我用 info，看不出名堂再切 debug。客户端的日志页放的就是内核输出，下面四个关键字都在这一页里找。

关键字一，dial 后面跟着 i/o timeout

mihomo 和 Xray 这两个常见内核都是 Go 写的，连接出错的那行字是 Go 的 net 包拼出来的。格式固定，操作名、网络类型、对端地址，冒号后面是原因 ^[9]。dial tcp 1.2.3.4:443: i/o timeout 这一行，读法是去拨 TCP，对端是 1.2.3.4 的 443 端口，原因是读写超时。i/o timeout 在 Go 里专指等过了期限 ^[9][10]，对面没在规定时间内应答，连接没建起来。

这一行铺满所有节点时，我按三步查。第一步换网络。用手机热点带电脑上网，延迟再测一遍。热点下能通，问题在原来的宽带到入口之间，和节点无关。第二步看入口地址。订阅里 server 一栏是域名的，几十个节点往往指向同一两个 IP。mihomo 有个 tcp-concurrent 开关，打开后用解析出来的全部 IP 同时去连，哪个先成功用哪个 ^[8]。域名解析出两个 IP、其中一个已经被拦，这个开关能让另一个顶上。ip-version 一项也决定域名用哪个 IP 去连 ^[1]。

第三步看账号。这一步我是读 Xboard 源码推出来的，没有实际复现。它的订阅接口只检查账号没被封、套餐额度大于 0、没过期 ^[11]，流量用完的账号照样能把订阅更新下来。给各节点下发的可用用户名单，却只包括已用量小于额度的用户 ^[11]。于是会有这样一种状态，订阅更新正常，节点全部超时，登录面板一看，流量用完了。这种情况 TCP 多半能通，节点不认凭据，延迟测试在期限内等不到回应。流量用完以后节点那头是直接断开还是不回包，各家实现不同，我没有逐家试。

关键字二，tls 后面那半句才是重点

tls 这个词出现在日志里，说明 TCP 已经通了，卡在握手。Go 的 crypto/tls 包把原因写在 tls 后面的那半句，我从源码里挑了三种 ^[12]。

tls: first record does not look like a TLS handshake，对面回的第一段数据不是 TLS，多半是端口写错了，或者那个端口本来就不走 TLS，配置里却开了 tls。核对面板上这个节点的端口和 tls 开关，和客户端里的逐项比。

remote error: tls: handshake failure，remote error 是 Go 给对端发来的警报加的前缀，后面是警报内容 ^[12]。同一类还有 unrecognized name 和 protocol version not supported。unrecognized name 常常是 servername 对不上，Xray 文档要求 serverName 必须包含在服务端证书的 SAN 里 ^[13]，mihomo 在 servername 留空时拿 server 地址去填 ^[2]，节点用了一个和入口地址不同的证书名，这一项就得填对。我的做法是不手改，回面板重新复制一次订阅地址导入。

tls: failed to verify certificate: x509: certificate has expired or is not yet valid，证书过期或者还没生效 ^[12][14]。先看系统时间。电脑时间差了几个月，所有节点的证书会一起“过期”。系统时间和流量用完这两件事，都会让几十个节点一起失联，我排查时把它们放在前面。时间没错，再看 x509 后面那句，signed by unknown authority 说明证书不是公共机构签的，这时候 skip-cert-verify 这个开关很诱人。Xray 对同类选项 allowInsecure 的说明是，打开以后不再检查远端证书的有效性，不应在实际场景里选 true，否则可能遭受中间人攻击，这个选项还标了弃用 ^[13]。订阅里机场自己写了 skip-cert-verify，那是它的选择，我不改。要我自己手动加上才能通的，我先问机场。

顺带一句，Clash Verge Rev 导入订阅时有个“允许无效证书（危险）”的选项，文档说用订阅链接配置的方式仍报 client error(Connect) 时可以勾上重试 ^[15]。那管的是下载订阅本身的证书核验，和节点的 skip-cert-verify 是两件事。

关键字三，403 要看是哪个窗口报的

403 是 HTTP 状态码。RFC 9110 的定义是服务器理解了请求但拒绝执行，拒绝的原因可以和凭据无关 ^[16]。排错时它在两个窗口出现，意思完全不同。

第一个窗口是更新订阅的那一下。Xboard 的订阅接口在账号被封、套餐额度为 0 或者已过期时，返回 403 和一个空正文 ^[6]。客户端拿到空内容，有的报更新失败，有的直接把列表清空，“更新订阅以后节点全没了”常见的来路之一就是它。处理办法只有登录面板，看到期日和套餐状态。这个判断用的是额度大小，流量用完但没过期，在 Xboard 这里不会 403，列表照旧，只是节点连不上，回到上一节的第三步。

第二个窗口是浏览器。延迟测试全绿，打开某个网站却是 403，这是网站拒绝了出口 IP，多半是那家网站对机房 IP 段或者访问太频繁的 IP 设了门槛。换一个地区的节点，大多数时候就过去了。它和节点超时没有关系，日志里也不会有 timeout。类似的还有内容地区认错，06-27 我给星岛梦做检测时，新加坡 10 行、台湾 9 行的 YouTube 地区显示 CN，页面能打开，只是内容对不上出口所在的地方。

关键字四，DNS 有两处，先查离我近的那处

dial tcp: lookup entry.example.com: no such host，这是第一处。no such host 是 Go 的 net 包在域名查不到记录时给的原话 ^[9]，这里查不到的是入口域名。客户端连入口之前要先把域名变成 IP，这一步走的是本机或者客户端自己配的解析器。所有节点共用一个入口域名时，这一行会铺满整页日志。查法是在终端里用 nslookup 查这个域名，换一个公共解析服务器再查一次。两次都空，域名可能真的失效了，去面板重新拿订阅。一次有一次没有，就是解析器的事。

mihomo 给这一步留了专门的位置。它的 DNS 配置里有一项 proxy-server-nameserver，文档说它只管代理节点域名的解析，不填就沿用 nameserver-policy、nameserver 和 fallback 的设置 ^[17]。default-nameserver 必须填 IP，用来解析 DNS 服务器自己的域名 ^[17]。把入口域名的解析交给一个干净的解析器，这一处就不会再出事。

第二处离我远一点，是通过节点访问网站时的解析。mihomo 的 enhanced-mode 有 fake-ip 和 redir-host 两种，默认 redir-host，fallback 一栏文档写着一般用境外 DNS，保证结果可信 ^[17]。这一处出问题的症状是延迟测试正常、节点能连，网页却打不开，或者打开的是错的地区版本。它不属于“全部超时”，日志里也不会有 dial timeout，看到这种症状就不要在节点上找原因了。

四个字都没有，日志是干净的

日志里一行报错都没有，列表却全是超时，先怀疑日志本身。log-level 设成 silent 时内核什么都不输出 ^[8]，改成 info 再测。

再看延迟测试的参数。策略组和代理集合都可以配 url、interval、timeout、lazy 几项，url 是健康检查测试地址，interval 单位秒，timeout 单位毫秒，lazy 默认为 true，没选中的策略组不做测试，expected-status 默认为星号，表示对返回状态不做要求 ^[7][18]。测试地址本身在当前网络下打不开，所有节点都会被记成超时，换一个地址测一次就能排除。超时毫秒数定得太短，跨洋节点握手慢一点就被判超时，放宽到几千毫秒再看。max-failed-times 默认是 5，连续失败超过这个数才触发一次强制检查 ^[7]，列表上的红色有时候比实际情况来得晚。

最后一种干净日志，节点都通，只是流量没交给客户端。延迟测试是客户端自己发的请求，走得通。浏览器走的是系统代理或者 TUN，没开就直接出门了，海外网站打不开，客户端日志里却什么都不会有。反过来，系统代理开着、客户端却没在听，浏览器会报“代理服务器可能有问题或者地址不对”，那一句我在 /proxy/errors/ 里单独写了。灵动云 07-20 那轮 60 个节点速度最低也有 17 MB/s，HTTPS 延迟却在 757 到 2758 毫秒之间，慢成这样也没有一行超时。

这一页的报错原文我是 2026-10-29 对着 Go 标准库源码、mihomo 与 Xray 的文档核的，内核更新以后字样会变，下一次核对定在 2026 年 11 月底。