Clash 节点超时、测速失败怎么办:从订阅更新到 DNS 的排查顺序

先分清：测速失败、节点不通与规则未命中

不要一看到 timeout 就重装客户端。测速结果只说明：内核未在指定时间内，通过选定节点完成对测试地址的请求。测试地址不可达、节点连接失败、DNS 解析异常，都可能得到相同的超时结果。先判断失败范围，再动配置。

保留一个可对照的现场

1. 记下客户端版本、内核名称与版本、当前配置名称，以及故障发生时间。
2. 保存配置副本。截图记录当前代理模式、策略组选择、系统代理和 TUN 开关。
3. 挑选一个节点、一个测试地址和一个实际网页，后续每次只修改一个设置。
4. 打开客户端的「日志」和「连接」页面。不同客户端入口名称可能不同，以实际界面为准。

测速单位通常是毫秒，表示该次测试请求的耗时，不是下载带宽。把超时阈值从 3000 毫秒临时改为 10000 毫秒，可以判断请求是否只是建立较慢；这两个数值是诊断设置示例，不代表实测性能，也不能修复失效节点。

第一步：确认订阅有效，且新配置已启用

先进入客户端的「订阅」或「配置」页面，执行一次手动更新。确认更新完成时间发生变化，再检查当前启用的配置是不是刚更新的那一份。列表里存在新配置，不等于内核已经加载它。

根据更新结果分支处理

• 返回 401 或 403：检查订阅地址是否完整、访问令牌是否更换，以及订阅账户状态。具体含义以服务端提示为准。
• 返回 404：核对路径是否过期，重新从原订阅管理页面复制地址，避免使用旧书签。
• 返回 200 但导入失败：查看响应是否实际为登录页或错误网页。HTTP 请求成功，不等于返回了可用配置。
• 提示 YAML 解析错误：检查缩进、字段格式和客户端支持的订阅格式。不要把单个节点链接直接当作完整配置文件加载。
• 下载订阅时超时：检查更新请求是否依赖当前失效的代理。若客户端提供订阅更新代理选项，可临时切换请求方式后重试。

更新后还要核对节点名称、数量与策略组成员是否符合预期。服务端可能替换节点地址，本地覆盖规则也可能把新节点过滤掉。若配置显示加载失败，应先解决加载错误，不要继续反复点击测速。

第二步：校准系统时间，排除基础网络故障

确认设备能正常联网，再检查系统日期、时间与自动同步状态。证书校验依赖准确时间，部分认证机制也对时间偏差敏感。时区显示不同不一定是故障，关键是系统实际时间是否准确。

• Windows：打开「设置」→「时间和语言」→「日期和时间」，检查「自动设置时间」，再执行「立即同步」。
• macOS：打开「系统设置」→「通用」→「日期与时间」，检查自动设置日期与时间的选项。
• 安卓：进入系统设置中的「日期和时间」，启用自动设置时间；菜单位置随系统版本和设备而异。

如果日志出现 certificate has expired 或 certificate is not yet valid，先核对本机时间，再检查服务端证书有效期。不要直接关闭证书验证来绕过报错，那会隐藏真正的问题并降低连接安全性。

用网络切换判断故障边界

保持同一节点和配置，把电脑从当前网络切换到手机热点再测一次。如果热点可用而原网络不可用，应优先检查原网络的访问限制、认证页面与路由器设置。若两个网络都失败，再继续检查本机与节点。网络切换只能缩小范围，不能单凭一次结果断定服务器故障。

第三步：检查内核运行、端口占用与系统代理

确认客户端界面显示内核运行正常。图形窗口已打开，不代表 mihomo 已成功启动。日志中的 address already in use 通常表示监听地址或端口被占用；应先处理启动错误，再测试节点。

核对实际监听端口

mixed-port 同时提供 HTTP 与 SOCKS5 代理入口。下面以本机混合端口 7890 为例；实际端口应从客户端设置或当前生效配置读取，不要把示例值当作所有客户端的默认值。

# 配置片段示例，不是完整配置
mixed-port: 7890
allow-lan: false

在 Windows 命令提示符中检查监听情况：

netstat -ano | findstr LISTENING | findstr :7890

在 macOS 或具备相应工具的 Linux 系统中检查：

lsof -nP -iTCP:7890 -sTCP:LISTEN

若端口被其他进程占用，先通过进程编号确认程序身份，再正常退出不需要的程序，或为 Clash 修改端口。不要直接结束未知系统进程。修改后，还要同步更新应用手动填写的代理地址。

区分本地代理入口与远端节点

在 Windows 中，可用以下命令显式经过本地 HTTP 代理发起请求。测试地址仅用于说明命令结构，请换成你确认可访问的 HTTPS 地址进行对照。

curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

在 macOS 或 Linux 中，把命令开头的 curl.exe 改为 curl。如果立即提示无法连接 127.0.0.1:7890，优先检查本地监听与端口。如果请求已进入内核，再结合连接面板确认最终走了哪个策略和节点。显式设置代理只证明请求进入代理入口，不保证规则一定选择远端代理。

显式代理测试可用、浏览器却不可用时，再检查客户端「系统代理」开关、浏览器独立代理设置，以及其他网络工具是否覆盖系统代理。TUN 模式还涉及服务权限和路由，不宜在这一阶段与系统代理一起反复切换。

第四步：按服务器域名与目标域名分别检查 DNS

DNS 故障至少要分两处看：一处是把节点的服务器域名解析成地址，另一处是解析准备访问的网站域名。前者失败，代理连接可能根本没有建立；后者失败，则可能出现节点测速正常、特定网页打不开的情况。

先检查节点服务器域名

从当前配置查看节点的 server 字段。若是域名，可用 nslookup 或 Resolve-DnsName 检查系统解析结果。命令中应填写真实服务器域名，不要把订阅链接或带路径的网址整段填进去。

• 系统解析失败、客户端也报解析错误：先检查本机 DNS 与网络连通性。
• 系统解析正常、客户端解析失败：检查内核使用的 DNS 上游及其访问方式，两者未必使用同一条解析路径。
• 配置了加密 DNS：确认其端点本身能够访问，并注意端点域名也可能需要引导解析。
• 使用 mihomo：检查适用版本中的 proxy-server-nameserver 设置；它用于指定代理服务器域名的解析上游，具体支持情况以当前内核配置文档为准。

再检查 Fake-IP 与应用缓存

在 Fake-IP 模式下，DNS 返回合成地址可能是正常行为。常见配置使用 198.18.0.0/16 范围，看到这类地址不能直接认定解析错误。要结合内核连接记录，确认应用请求是否被正确接管，以及域名映射是否仍然有效。

浏览器的安全 DNS、应用内置解析与系统 DNS 可能走不同路径。如果只有某个应用异常，先检查该应用的 DNS 设置，而不是立即重写整份配置。临时关闭应用自定义解析用于对照后，记下结果，再决定长期设置。

每次只调整一个 DNS 选项，重新加载配置后关闭并重新打开测试应用。Windows 可使用 ipconfig /flushdns 清理系统 DNS 缓存，但它不会自动清空浏览器自己的缓存，也不会替代内核的缓存管理。若切换 Fake-IP 与其他模式，旧连接和旧映射也需要一并留意。

第五步：逐项核对协议参数与传输条件

只剩个别节点失败时，重点核对这些节点本身。先从订阅源重新更新，避免手动拼接参数。Clash 图形客户端与内核不是同一层：界面能显示某种节点类型，不代表当前运行的内核版本一定支持该类型或全部字段。

基于 QUIC 的节点传输通常依赖 UDP。若当前网络限制了 UDP，修改本地 HTTP 代理端口不能解决远端传输问题。可换网络对照，或测试服务端提供的另一种传输类型。普通 TCP 端口连通测试也不能证明 UDP 节点可用。

即使 TCP 连接成功，也只是说明连接建立到某个监听端口。认证失败、TLS 握手错误、传输路径不匹配，仍然会让代理不可用。不要把「端口能连」当作整个协议工作正常的结论。

最后验证：结合规则、日志与实际请求收敛问题

修复后不要只看测速颜色。打开一个实际网页，在连接面板确认目标域名、命中规则、策略组和最终节点。规则模式可能把测试网页分配为 DIRECT，此时网页能打开不能证明选中的代理节点可用。

用日志定位失败阶段

• connection refused：目标明确拒绝了连接。检查地址、端口和服务是否监听。
• i/o timeout：请求在某阶段未及时完成。结合前后日志判断是解析、连接还是握手超时。
• no such host：优先检查域名拼写与解析链路。
• authentication failed：核对认证参数和账户状态，不要继续只换 DNS。
• unsupported proxy type：检查配置类型与内核兼容性，先解决加载问题。

确需临时提高日志级别时，只记录一次可复现操作，随后恢复日常级别。排查结束后恢复临时更改的测试地址、代理模式和应用 DNS 设置，保留真正有效的修改，避免把诊断状态当成长期配置。

提交问题时保留这些信息

提供客户端与内核版本、操作系统、失败范围、网络切换结果、报错时间，以及脱敏后的相关日志片段。说明订阅能否更新、本地端口是否监听、请求是否进入内核。按这套顺序记录，比一句「节点全红」更容易判断问题属于本机设置、解析路径还是节点服务。

排查顺序可以压缩为一条线：订阅确实更新并启用 → 时间与网络正常 → 内核启动且端口可用 → DNS 路径成立 → 协议参数匹配 → 实际请求命中预期节点。在哪一步出现可重复的失败，就先停在那一步处理。