你在客户端里撞见了 timeout 这个词。它可能挂在节点列表延迟一栏的末尾，也可能藏在日志里一长串报错的最后几个字。意思都一样，客户端给某次请求定了一个等待上限，过了上限对方还没回话，它就放弃。区别在于等的是哪一段。连接超时卡在你的设备和节点服务器之间，读取超时卡在连接已经建好、数据迟迟不来，测速超时卡在节点去访问测试地址那一圈。先认出是哪一种，再决定换节点、查本机，还是暂时不用管它。
三种超时在客户端里长什么样
mihomo、sing-box、Xray 这几个常见内核都用 Go 语言写成，日志里的报错大多沿用 Go 标准库的原始说法，所以不同客户端看到的字样很接近。按下表对一下你看到的那一行。
| 类型 | 常在哪里看到 | 常见字样 | 卡在哪一段 | 看到以后先做什么 |
|---|---|---|---|---|
| 连接超时 | 客户端的日志页 | dial、connect、i/o timeout | 你的设备到节点服务器 | 换同一份订阅里另一个地区的节点 |
| 读取超时 | 日志页，有时浏览器也会报 | read、i/o timeout、context deadline exceeded | 连接已建立，节点没在时限内回数据 | 刷新一次，再换节点对比 |
| 测速超时 | 节点列表的延迟一栏 | Timeout、红字“超时” | 节点到测试地址 | 选中这个节点，直接打开一个网页试 |
日志在哪看，各客户端位置不同。Clash Verge 左栏有一项就叫“日志”，Clash for Android 和 Clash Meta for Android 的首页下方也有“日志”入口，NekoRay 3.26 的主界面上直接带着一块日志区。
连接超时：设备到节点这一段没接上
日志里带 dial 或 connect，后面跟着 i/o timeout，说明客户端去连节点的地址和端口，在时限内没有得到对方的握手回应。数据还没出你的设备附近，就停住了。
常见的原因有三个。节点那台服务器停了或者被封了；你所在的网络拦住了那个端口；或者整份订阅都已经失效，所有节点一起连不上。排查按下面的顺序走。
- 先看是不是只有这一个节点这样。换同订阅里另一个地区的节点，日志不再出现 dial 超时，问题就在那个节点上，不用再查。
- 换了几个都一样，把设备切到手机热点再试。热点下能连上，说明刚才的网络拦了端口，这一段怎么在原网络里解决本站没走过。
- 热点下也全部连接超时，问题在订阅或本机，按本站问答里“梯子全部节点超时怎么办”那篇的顺序查到期日、流量和系统时间。
读取超时：接上了，数据没回来
日志里出现 read，或者出现 context deadline exceeded，说明连接已经建立，请求也发出去了，但节点在规定时间内没有把数据送回来。Go 的 context 包把“到了截止时间还没完成”统一报成这句话，所以它在各种内核里都会出现。
这一段出问题，原因比连接超时散。节点负载太高、节点去目标网站那一程很慢、目标网站本身响应慢，都会让数据迟到。本站的判断是，VMess 这类把时间写进校验的协议，本机时间偏差太大时，服务端不会正常回应，客户端这边可能报读取超时，也可能报 EOF。
处理顺序是先刷新一次，偶发的读取超时刷新就过去了。连续出现，换一个节点打开同一个网页，换了就好说明是原节点慢。换了也一样，再换一个网站试，只有某一个网站超时，多半是那个网站在节点所在地区响应慢。所有网站、所有节点都读取超时，先校一次系统时间。
测速超时：延迟栏的 Timeout 怎么来的
节点列表里的延迟数字，是客户端经过这个节点去请求一个测试地址，从发出到收到回应花的时间。mihomo 的文档里，代理组用 url 字段指定这个测试地址，用 timeout 字段指定等待上限，单位是毫秒。一圈走完没超过上限，显示数字；超过了，就显示 Timeout 或红字超时。
所以测速超时只说明一件事，节点到那个测试地址这一圈没在上限内走完。节点本身连不上会导致它，测试地址在节点那边打不开也会导致它。验证的办法很简单，选中这个节点，打开一个你常去的海外网页。网页能开，节点在工作，延迟栏的超时可以先不管；网页也打不开，回到上一节按连接超时的顺序查。
不同客户端对“超时”的设定不一样。本站在 iPhone 上走 Shadowrocket 教程时记下，它的订阅设置页有一栏超时，截图里填的是 15，指的是和远程主机建立连接的等待时间。Clash Party 的延迟栏则用颜色区分，绿色偏低，橙色偏高，红字表示超时。延迟数字只代表一次请求往返，测速口径见 本站的检测和测速方法。
什么时候这个答案不成立
- 闭源客户端。Shadowrocket、Quantumult X 这类客户端的日志写法本站没有核对，上面表里的字样主要来自用 Go 内核的开源客户端。
- 开了 TUN。TUN 接管整台设备的流量，关错顺序会让所有请求都超时，先按 梯子 TUN 模式的开关顺序 把它正常关一次。
- 路由器上的客户端。OpenClash 这类跑在路由器上的，超时可能来自路由器自己的 DNS 和防火墙设置，本站没有在路由器上走过这一段。
- 版本变化。报错字样和配置字段都可能随内核版本改名，以你手里的版本和 mihomo 文档的当前页面为准。
- 报错里出现的是 EOF 或 connection reset，这属于连接被对方关掉，和超时是两类情况，看下面第二个链接。
接下来去哪
- 所有节点都超时，单个换不出结果，看 梯子全部节点超时怎么办，按订阅、本机、机场的顺序排。
- 日志里写的是 EOF，看 梯子EOF错误怎么解决，从校时间开始一项项核对。
- 怀疑是客户端太旧或者内核不支持订阅里的协议，去 梯子客户端 按系统换一个当前还在更新的。
延伸问题
正文没展开、但和这个问题挨着的几条。点问题展开答案。
延迟栏显示 Timeout 的节点还能用吗
有可能能用。测速只走一个测试地址，那个地址在节点那边打不开，延迟栏也会显示超时。选中它，打开一个你常去的海外网页试一次，能打开就说明节点在工作，只是测试那一圈没走通。
超时上限能自己改吗
能改的客户端有。mihomo 的代理组配置里有 timeout 字段，单位是毫秒；Shadowrocket 的订阅设置页也有一栏超时。调大只是让客户端多等一会儿，节点本身不通的，调多大都还是超时。
参考
相关问答
- 梯子全部节点超时怎么办：先查订阅是否过期，再查本机梯子全部节点超时，先回机场面板看订阅是否过了到期日、流量条是否见底，多数情况出在这两项。
- 梯子EOF错误怎么解决：先校时间，再核对协议与端口梯子EOF错误的处理顺序是先校准系统时间，再更新订阅、核对协议和端口，前三步都过了才换节点和看机场。