Clash 显示连接超时怎么办?Timeout 常见原因与排查顺序
节点显示 Timeout 并不等于订阅失效,先区分单节点故障与全部节点共同故障。
不堆参数、不靠猜。按网络、订阅、DNS、规则和客户端逐层排查,把每个问题拆成可以验证的步骤。
每 7 天自动切换一组 10 篇;旧文章保持发布,不为了“新鲜度”下线。
节点显示 Timeout 并不等于订阅失效,先区分单节点故障与全部节点共同故障。
订阅更新失败要先分清地址错误、Timeout、403、5xx 和 DNS 解析异常。
客户端有实时流量并不能证明 DNS、TLS、规则和目标网站链路全部正常。
首页能打开、视频却黑屏或一直转圈,通常要重点看媒体链路、DNS、QUIC、丢包和节点质量。
DNS 把域名转换成 IP,解析结果错误时,后续连接会直接去错地址。
Fake-IP 会给应用返回一个虚拟地址,再由客户端把它映射回原始域名并执行规则。
只有部分国内站异常时,问题往往在规则命中、DNS、TUN 或局域网绕过,而不是节点全部失效。
同一设备同一节点只改变接入网络,结果不同,是定位 DNS、IPv6、路由器和运营商链路的重要线索。
延迟、带宽、丢包和抖动是不同指标,30ms 节点并不保证高清视频一定比 70ms 节点顺畅。
所有节点同时异常时,优先排查它们共同依赖的网络、订阅、DNS、系统时间和客户端。
共 60 篇
Ping 只覆盖很小一部分链路特征,网页还需要 DNS、握手、服务器响应和资源加载。
把网络问题当成实验:固定设备与配置,只改变一个条件,才能找到因果。
重装应是最后手段,订阅、DNS、节点和网络故障通常不会因为重装自动消失。
一张可收藏的快速检查表,从基础网络到日志按顺序缩小问题范围。
分流按域名、IP、应用等条件把连接交给 DIRECT、代理或不同策略组。
会看 timeout、HTTP 状态码、TLS、DNS 和规则命中后,排障会快很多。
局域网资源通常应保持本地访问,TUN 或规则配置不当时可能被错误送往代理。
HTTP/3 基于 QUIC/UDP,某些网络下可能与 TCP 路径表现不同。
多个客户端同时运行会争用本地端口、系统代理、DNS 和虚拟网卡。
二维码可能包含订阅 URL、单节点 URI 或普通网页地址,扫描后应先确认来源。
DNS 查询路径和网站实际连接路径可以不同,多套 DNS 同时存在会让结果更复杂。
SNI 让同一 IP 上的服务器在 TLS 握手时知道客户端想访问哪个域名并选择正确证书。
TCP 强调可靠有序,UDP 更轻量低延迟,网页、视频、游戏依赖程度不同。
WebSocket 从 HTTP 握手升级成长连接,适合实时双向通信。
实时语音、会议和游戏更怕延迟忽高忽低和持续丢包。
代理与 VPN 都能改变流量路径,但实现层次、覆盖范围和分流能力并不完全相同。
公共网络的主要风险包括假热点、弱隔离和不可信本地网络,基础安全习惯仍然最重要。
测速应区分本地宽带、代理线路和真实目标网站,并在不同时间重复。
物理距离会影响理论延迟,但互联网不是直线,路由和运营商互联常更重要。
很多订阅 URL 本身就包含账号识别 token,应像密码一样谨慎处理。
日志里的 certificate、handshake、TLS alert 都发生在应用数据传输前的安全协商阶段。
WebSocket 先通过 HTTP 握手升级成长连接,路径或代理头错误都会让升级失败。
同机其他应用正常、浏览器异常时,代理核心可能是好的,问题更接近浏览器设置。
应用可能不遵循系统代理,或使用独立代理、UDP、自带 DNS,需要 TUN 才能接管。
游戏对延迟波动和 UDP 丢包很敏感,稳定 70ms 可能比 30-180ms 跳动更好。
睡眠会让网卡、IP 和虚拟网络状态变化,唤醒后旧路由与连接可能没有完全恢复。
文字、头像、图片和视频经常来自不同域名或 CDN,因此只坏资源加载很常见。
视频更依赖持续吞吐和低丢包,峰值再高也可能因为频繁掉速而卡顿。
403 表示服务器收到请求但拒绝访问,排查重点与 Timeout 完全不同。
502 通常表示网关无法正常从上游取得响应,更偏向服务端链路故障。
系统、浏览器、代理客户端、路由器和上游 DNS 都可能缓存域名结果。
某些客户端可让 DoH 不使用 HTTP/3,主要用于特定网络对 QUIC/UDP 兼容不佳时做对照。
DoH 把 DNS 查询放进 HTTPS 中传输,主要改变的是 DNS 的传输方式。
理解每一层 DNS 的职责,比复制一份堆满地址的“万能配置”更重要。
让 DNS 查询与规则联动可以提高路径一致性,但也会增加代理依赖和排查复杂度。
当局域网、游戏或特殊应用与 Fake-IP 不兼容时,可以只对明确异常域名做排除。
不同 Clash/Mihomo 分支对参数支持可能变化,陌生字段应先确认当前内核版本。
先把主解析路径做稳定,再考虑 fallback;过多 DNS 会让结果更难解释。
双栈意味着 A/AAAA 两条可能路径,IPv6 路由不完整时会出现部分站点首开慢或连接失败。
自有域名出现旧 IP、随机 IP 或错误地址时,应从权威记录一路查到本机覆盖。
Android 上常见问题往往来自 VPN 权限、后台限制和系统省电,而不只是节点。
从可信来源安装客户端,导入订阅后先确认配置能更新,再考虑 Rule、Global 和 TUN。
三种模式决定流量如何选择直连或代理,日常通常优先 Rule。
TUN 通过虚拟网络接口接管更多流量,覆盖面比系统代理广,但故障面也更大。
Windows 新手应先用最小默认配置验证订阅和节点,再逐步开启 TUN 或高级 DNS。
iPhone 上先把订阅添加和更新做好,再讨论节点与策略;更新失败要先测试链接本身。
macOS 上要特别注意系统代理、网络扩展权限、TUN 和多个客户端互相覆盖。
更新订阅前先备份本地覆写与自定义规则,明确客户端是否会覆盖本地配置。
节点选择要综合地区、持续速度、丢包、晚高峰和真实业务,而不是只看延迟。
系统代理简单、影响范围小;TUN 接管更广,适合不遵循系统代理的程序。
Fake-IP 会给应用返回一个虚拟地址,再由客户端把它映射回原始域名并执行规则。
节点显示 Timeout 并不等于订阅失效,先区分单节点故障与全部节点共同故障。
DNS 把域名转换成 IP,解析结果错误时,后续连接会直接去错地址。
同一设备同一节点只改变接入网络,结果不同,是定位 DNS、IPv6、路由器和运营商链路的重要线索。
首页能打开、视频却黑屏或一直转圈,通常要重点看媒体链路、DNS、QUIC、丢包和节点质量。
只有部分国内站异常时,问题往往在规则命中、DNS、TUN 或局域网绕过,而不是节点全部失效。
所有节点同时异常时,优先排查它们共同依赖的网络、订阅、DNS、系统时间和客户端。
延迟、带宽、丢包和抖动是不同指标,30ms 节点并不保证高清视频一定比 70ms 节点顺畅。
客户端有实时流量并不能证明 DNS、TLS、规则和目标网站链路全部正常。
订阅更新失败要先分清地址错误、Timeout、403、5xx 和 DNS 解析异常。
换节点、换网络、改 DNS、开 TUN、改规则不要同时进行。记录每一步前后的结果,才能真正定位原因。
每周 10 篇是发布/精选节奏,不是简单换日期制造新鲜。