Clash 节点超时、无法连接怎么办：从订阅到 DNS 的逐项排查顺序

先区分测速超时与实际连接失败

Clash 客户端显示“Timeout”，通常表示在规定时间内没有完成一次测试请求。它不等于服务器必然离线：测试地址不可达、DNS 查询失败、节点认证失效，都可能产生相似结果。反过来，测速显示延迟，也只说明当时的测试请求成功，不代表所有网站、UDP 流量和应用都能正常访问。

排查的目标是找出失败发生在哪一段：配置获取、本地监听、域名解析、节点握手，还是规则选择。先保存当前配置与日志，再固定一个节点、一个目标网站和一种接入方式，避免同时更新订阅、改 DNS、开 TUN 后无法判断哪个改动有效。

建立最小测试记录

• 环境：记录操作系统、Clash 客户端版本、内核版本，以及使用 Wi-Fi、移动网络还是有线网络。界面版本和 mihomo 内核版本分别记录。
• 配置：记录当前 Profile 名称、订阅最后成功更新时间、代理模式和策略组选中的节点。
• 现象：区分“全部节点超时”“只有一个节点失败”“测速成功但浏览器失败”“浏览器正常但某个应用失败”。
• 时间：例如在 14:30:00 发起请求，随后截取对应的 30 秒日志。这是记录格式，不是预设的测试结果。

第一步：确认订阅有效且配置已生效

订阅链接是配置来源，不是节点连接本身。订阅更新成功与节点可用之间没有直接等号：获取到的配置可能包含已经过期的账号信息，或者提供方正在维护线路。先打开 Clash 客户端的配置列表，确认当前启用的 Profile，再对这一份配置执行更新，检查结果和更新时间。

1. 检查账号状态。到订阅提供方的账户页面确认有效期、剩余流量和设备限制。流量耗尽或账号停用时，本地调整端口通常没有作用。
2. 检查订阅响应。HTTP 401 或 403 通常涉及授权或访问策略，404 可能是地址失效，429 表示请求受限。若返回的是登录页面而不是配置内容，不能把它作为 YAML 导入。
3. 检查加载结果。更新后确认节点列表发生了预期变化，并查看是否出现 YAML 语法错误、未知字段或不支持的协议提示。有些 Clash 客户端在更新失败时会继续保留旧配置。
4. 检查最终生效配置。配置合并、覆写与脚本可能改变端口、DNS 或规则。后续排查应以实际加载结果为准，而不只看订阅原文。

全部失败与单个失败的分支

只有单个节点失败，先选同一策略组内的另一个节点复测，再检查原节点的服务器地址、端口和认证信息。全部节点都失败，优先排查共同依赖：本机网络、系统时间、DNS 和本地内核。若不同节点实际使用同一个服务器域名，它们也可能受到同一解析故障影响。

远程规则集和代理集合可能由 rule-providers、proxy-providers 单独获取。主订阅成功更新，不代表这些资源也下载成功。查看日志中的资源下载错误；尤其注意资源获取需要代理、但启动时又没有可用代理的依赖问题。

第二步：校准系统时间并验证基础网络

系统日期明显偏差会让 TLS 证书有效期判断失败，也可能影响依赖时间的认证流程。这类错误有时出现在节点握手阶段，有时出现在订阅下载阶段。先确认年月日和实际时间，而不是仅检查任务栏显示的小时。

• Windows 11：进入「设置」→「时间和语言」→「日期和时间」，启用「自动设置时间」，然后在「同步时钟」区域执行「立即同步」。
• macOS：进入「系统设置」→「通用」→「日期与时间」，启用自动设置日期与时间；系统版本不同，标签可能略有差异。
• Linux：使用 timedatectl status 查看时间与同步状态；在使用 systemd 且支持时间同步的系统上，可用 sudo timedatectl set-ntp true 启用同步。

暂停 Clash 客户端的系统代理和 TUN，再访问一个在当前网络允许直接访问的网站，确认基础联网正常。公共 Wi-Fi 若要求网页登录，应先完成认证。基础网络尚未连通时，继续修改代理规则只会增加干扰。

更换网络作为对照

在同一设备、同一配置下，分别用原网络和手机热点测试。如果只在原网络失败，问题更可能与该网络的 DNS、出口限制或防火墙有关；如果两个网络都失败，再检查设备与配置。这个对照只能缩小范围，不能直接证明某一种封锁机制。

ping 无响应不能单独作为节点离线的证据，服务器可能不响应 ICMP。节点通过 TCP、UDP 或其他传输工作，应结合实际协议的连接日志判断。

第三步：检查代理端口与接入路径

浏览器无法连接本地代理，与远端节点超时是两类问题。前者常见于内核未启动、监听端口被占用、系统代理仍指向旧端口。打开当前生效配置，找到 mixed-port，或分别查看 port 与 socks-port。以下以混合端口 7890 为例；它只是示例值，必须替换成实际监听端口。

查看监听进程

Windows 在 PowerShell 中执行以下命令；根据输出中的 OwningProcess 查询进程，判断监听者是否为预期的内核。

Get-NetTCPConnection -LocalPort 7890 -State Listen
Get-Process -Id (Get-NetTCPConnection -LocalPort 7890 -State Listen).OwningProcess

macOS 可用 lsof，Linux 可用 ss；权限不足时可能看不到进程信息。

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7890'

没有监听结果时，先查看内核启动日志。若出现 address already in use，退出占用同一端口的旧实例，或修改当前 Clash 客户端的监听端口。不要直接结束陌生系统进程；先确认它的名称和来源。修改后还要同步检查系统代理地址，否则浏览器可能继续连接旧端口。

显式代理测试：绕开系统代理开关

下面的命令直接指定本地 HTTP 代理，用于判断监听端口、代理转发和目标请求能否连通。Windows 建议使用 curl.exe，避免某些 PowerShell 环境将 curl 解释为其他命令；macOS、Linux 可将命令名换为 curl。

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

• 立即拒绝连接：重点检查本地监听地址、端口和内核状态，而不是先更换节点。
• 收到 HTTP 响应：说明这一次请求完成了。若浏览器仍失败，检查系统代理、浏览器代理设置或扩展。
• 等待后超时：查看同一时间的日志，区分节点服务器连接失败、TLS 握手失败和目标网站响应超时。

这里的 10 秒是连接阶段上限，20 秒是总请求上限，不是延迟测量值。测试还受当前规则影响：若目标命中 DIRECT，只能证明直连路径可用。要验证指定节点，应临时选择对应策略并核对连接记录，完成后恢复原模式。

第四步：沿实际 DNS 路径检查解析

DNS 故障至少要区分两件事：节点服务器域名能否解析，以及目标网站域名能否解析。前者失败时，节点连接本身无法建立；后者失败时，节点可能测速正常，但特定网站无法访问。日志中的 no such host、DNS 查询超时和解析器连接失败，比界面的统一“超时”提示更有定位价值。

先检查系统解析，再检查内核解析

# Windows PowerShell：检查系统 DNS 返回
Resolve-DnsName example.com

# 常见桌面系统可用的基础查询
nslookup example.com

将示例域名替换为日志里真正失败的域名。系统查询成功，不代表 Clash 客户端内核使用的解析器也成功；当内核启用自己的 DNS、TUN 接管 DNS 或应用使用加密 DNS 时，解析路径可能不同。应对照有效配置中的 dns.enable、nameserver 和日志逐项确认。

上述字段的支持范围与行为取决于内核版本，修改前查阅对应版本文档。不要把某份 mihomo 配置直接套给不支持这些字段的旧内核。也不要一次填入多个公共 DNS 后就认定问题解决；解析器可达性、分流策略和引导解析都需要验证。

Fake-IP 地址不是节点服务器地址

启用 Fake-IP 时，解析可能返回配置的映射地址范围，例如 198.18.0.0/16。这是用于关联域名与连接的内部映射，看到这样的地址不等于 DNS 被污染。关键是后续连接是否回到同一个内核并正确恢复域名。

若切换 DNS 模式后，应用仍使用旧缓存，先重新启动受影响应用，再按系统方式清理 DNS 缓存。Windows 可执行 ipconfig /flushdns，但这不会自动清除浏览器自身缓存或内核映射。对于确实不兼容 Fake-IP 的局域网服务，可依据日志配置有针对性的 fake-ip-filter，不必先把全部域名改为绕过。

第五步：核对规则命中与策略组选择

节点有延迟但网页打不开，常见原因是请求没有使用预期节点。规则模式按配置顺序匹配；域名规则、IP 规则、进程规则和最终兜底规则，可能把不同请求送到不同策略。查看 Clash 客户端的连接记录，至少核对目标域名、命中规则、最终策略链，以及实际出站节点。

1. 固定一个节点。在手动选择策略组中选定节点，避免自动测速组在排查中切换出口。
2. 重建连接。关闭旧标签页或重新启动应用后复测。既有长连接不一定随策略切换立即改用新节点。
3. 确认 DIRECT 与 REJECT。请求命中直连或拒绝策略时，更换代理节点不会改变结果，应先检查对应规则。
4. 短时对照全局模式。确认全局策略也选中了待测节点。若全局可用、规则模式失败，重点检查规则与策略组；测试结束恢复规则模式。

全局模式也不会自动接管所有应用。只启用系统代理时，不遵循系统代理的应用仍可能直连。若显式代理命令正常而某个游戏、命令行程序或即时通信应用失败，应先判断它是否支持 HTTP/SOCKS 代理，再决定是否使用 TUN。

TUN 与 UDP 单独验证

TUN 将系统 IP 流量交给虚拟网络接口处理，需要相应权限、路由和 DNS 接管配置。浏览器可用而 TUN 不可用时，检查服务安装状态、管理员权限、虚拟接口以及其他 VPN 的路由冲突；不要把所有故障归为节点失效。

网页 HTTPS 测试主要验证 TCP 路径，不能证明 UDP 可用。游戏、语音与部分 QUIC 连接还依赖节点协议支持、服务器转发能力和本地网络条件。应分别测试相关应用，并检查 UDP 日志；单纯把配置中的 UDP 开关设为启用，不会让不支持的服务端获得 UDP 转发能力。

最后：用日志定位握手与服务端故障

订阅、时间、端口、DNS 和规则都检查过后，才进入节点握手与服务端排查。可暂时把日志级别调整为 debug，复现一次后恢复常用级别。不同 Clash 客户端的入口不同，先从日志页面查找导出功能，不必猜测某个固定目录。

需要服务端配合的字段，如端口、密码、UUID、SNI、WebSocket 路径和 Reality 参数，应以订阅提供方的有效配置为准。随意修改其中一个字段可能让原本可用的节点无法握手。若只有一个节点在两个网络下都稳定失败，而其他节点正常，可先切换可用节点，再向提供方反馈故障。

提交问题时保留四项证据

• 系统、Clash 客户端与内核的具体版本，以及故障开始时间。
• 全部失败还是部分失败，系统代理与 TUN 哪种方式出现问题。
• 显式代理测试结果、规则命中结果，以及更换网络后的对照结果。
• 围绕一次失败请求的脱敏日志，不仅是一张“Timeout”截图。

需要重新梳理导入与接入步骤，可查看使用文档；涉及 DNS、规则和 TUN 参数时，继续查阅配置进阶。保持一次只改一项，并保存可恢复的配置，比反复重装更有利于定位问题。