Clash 节点超时与连接失败：从订阅到出口的逐层排查顺序

先区分：测速超时、代理连接失败与网站失败

Clash 显示节点超时，不等于节点服务器已经停机。延迟测试通常需要通过节点请求一个测试地址，结果同时依赖本地网络、节点连接、代理握手、出口解析和测试网站。任意一环失败，都可能显示超时。应先确认失败发生在哪一层，再改对应字段，而不是连续更换 DNS、端口和内核。

Clash 是内核与配置生态的统称，客户端负责界面、订阅管理和系统代理等操作；Clash Meta 后续使用 mihomo 名称。不同客户端的菜单位置、配置合并方式和内核能力并不完全相同。排查时以当前运行内核的日志和生效配置为准，不能只看订阅文件里写了什么。

第一层：确认订阅更新成功且配置已经启用

先验证客户端确实加载了新配置，再判断节点是否可用。订阅更新成功、配置解析成功和切换到该配置是三个不同动作。远程订阅更新失败时，客户端可能继续使用本地缓存，因此列表里有节点不代表本次更新成功。

1. 检查更新时间与更新结果。在当前客户端的订阅或配置列表中找到正在使用的条目，执行一次更新，记录 HTTP 状态码或错误信息。不同客户端菜单名称不同，不要把自动更新间隔当成最近一次成功时间。
2. 确认返回内容是配置。HTTP 200 仅代表请求成功；登录页、流量用尽提示页也可能返回 200。若日志提示 YAML 解析失败，应先检查内容类型，而不是删除缩进碰碰运气。
3. 确认配置被选中并重载。切换后检查策略组是否出现预期节点，查看日志有没有未知字段、缺少代理组、重复名称或不支持的代理类型。
4. 区分主配置与节点提供器。使用 proxy-providers 的配置还有独立的节点拉取过程；主配置更新完成，并不证明提供器也拉取成功。

订阅下载本身依赖代理怎么办？

若旧节点失效，而订阅更新又被设置为经过旧节点，就可能形成更新依赖。先确认订阅域名在当前网络能否直连；客户端若提供订阅更新代理选项，可临时切换到已验证可用的路径。主配置里的 proxy-providers 拉取和客户端自身的订阅下载可能使用不同机制，应分别看日志。

不要把含令牌的订阅链接粘贴到公共检测网站。需要求助时，只提供状态码、脱敏后的错误及更新时间；完整订阅地址通常等同于访问凭据。

第二层：检查本地网络与网络切换差异

如果全部节点突然同时失败，先检查它们共享的本地链路。暂停系统代理与 TUN，再访问当前网络原本就能直连的网页；若连基础网络也不可用，应先处理 Wi-Fi、网线、认证门户或路由器问题。测试结束后恢复需要的代理设置。

• 检查联网认证：酒店、校园或公共 Wi-Fi 可能需要先完成浏览器登录。代理开启时，认证页面可能无法正常跳转。
• 检查系统时间：日期、时区或时钟明显错误可能导致证书有效期验证失败。开启系统自动校时后再测试 TLS 类节点。
• 临时切换手机热点：保持同一台设备、同一份配置、同一节点，只更换网络。如果热点可用而原网络失败，优先调查原网络的 DNS、出站策略或 IPv6 路径。
• 排除重复接管：暂时退出其他 VPN、代理客户端或流量过滤工具，避免多个工具同时修改路由。不要为了排查长期关闭系统防火墙。

热点测试只能缩小范围，不能单独证明运营商封锁。手机网络与固定宽带可能使用不同的解析结果、IPv4/IPv6 出口和路由。记录两次测试的差异，比反复点击延迟测试更有价值。

第三层：检查监听端口与应用是否进入内核

先确认本地代理入口可用，再检查远端节点。端口被占用、内核启动失败或系统代理指向旧端口，都会让应用表现为“代理连不上”。下面是本机入口字段示例，只用于说明监听关系，不能单独作为包含节点的完整配置。

# 合并到当前配置的顶层；不要重复声明同名键。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port 同时接受 HTTP 和 SOCKS 代理连接；7890 是本例使用的端口。external-controller 是控制接口，不是浏览器代理入口，不能把常见控制端口 9090 填进应用的 HTTP 代理设置。

确认哪个进程占用了 7890

Windows 可在 PowerShell 中查看监听记录，再根据返回的进程编号确认所属程序：

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

macOS 可使用系统中的 lsof；Linux 可使用 ss。查看进程详情时可能需要相应权限：

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

# Linux
ss -lntp 'sport = :7890'

如果占用者是另一个代理实例，应先确认哪个实例正在提供服务，再停止重复进程或修改端口。端口修改后，还要同步更新系统代理与应用设置。日志出现 address already in use 时，优先处理监听冲突，不必先换节点。

绕开系统代理设置，显式测试本地入口

curl --noproxy "" -x http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://example.com/

Windows PowerShell 中建议将上面的 curl 写为 curl.exe，避免部分环境中的同名别名。--noproxy "" 用于清除本次请求的代理绕过列表；5 秒限制连接等待，15 秒限制请求总时长。

如果提示无法连接 127.0.0.1:7890，优先检查内核和监听端口。如果收到 200、301 等 HTTP 响应，说明本次请求获得了响应，但仍应在连接日志中确认最终策略：规则可能让它走了 DIRECT，不能仅凭响应码认定代理节点可用。

第四层：区分节点域名解析与目标域名解析

DNS 排查要先问“哪个域名解析失败”。节点的 server 若填写域名，内核连接节点前需要解析它；访问目标网站时，还可能涉及另一轮解析。节点地址解析失败与网站域名解析失败，不能用同一条结论概括。

• 节点域名失败：日志可能包含 lookup、no such host 或解析超时。先用系统工具查询节点域名，记录是否返回 A、AAAA 记录，再比对内核实际日志。
• 目标域名失败：节点握手可能已成功，但后续请求仍因解析失败中断。检查失败发生在本地、内核 DNS 还是服务端出口。
• 只有 IPv6 路径异常：关注日志实际连接的是 IPv4 还是 IPv6 地址。系统查询成功不等于该地址族的链路畅通，也不代表内核使用了相同解析器。

下面展示 mihomo 中节点域名使用独立解析器的字段关系，要求当前内核支持对应字段。此片段不是通用 DNS 推荐配置；应合并进已有的 dns 映射，不要在同一层再写第二个 dns。

dns:
  enable: true
  nameserver:
    - 1.1.1.1
  proxy-server-nameserver:
    - 1.1.1.1

proxy-server-nameserver 用于解析代理节点域名。示例中的解析器地址不保证在当前网络可达，应选用已验证可达的解析器。已有 DoH、Fake-IP 或按域名分配解析器的配置时，应保留原有结构，只修改与故障直接相关的部分。

第五层：对照协议参数与内核支持范围

同一个地址和端口能建立 TCP 连接，不代表代理协议握手能完成。如果本地入口正常、节点地址也能解析，却只有某类节点失败，应检查协议支持和服务端参数。旧版 Clash 内核与 mihomo 的协议范围不同，客户端界面里能显示节点名称，也不等于当前运行内核能使用该协议。

优先重新获取服务方针对当前内核提供的配置，不要凭节点名称推断协议，也不要手动删掉看不懂的参数。若使用订阅转换，检查转换目标是否与实际内核相符；不兼容的转换可能丢失传输或认证字段。

TCP 可达性测试只能回答一部分问题

Windows 的 Test-NetConnection 可检查指定地址和端口的 TCP 建连。把 -ComputerName 后的值换成配置中的真实节点域名，把 -Port 后的值换成实际端口即可。不要把这样的 TCP 测试结果用于证明 Hysteria2 等基于 UDP 的协议可用。

即使 TCP 测试通过，也只表示该端口在当时能够建立连接；密码、TLS 和代理传输仍可能失败。反过来，节点不响应 ICMP 也很常见，单独的 ping 丢包不能证明代理服务不可用。

第六层：判断服务端故障、出口限制与测速目标异常

只有在前面各层基本确认后，才把重点放到服务端和出口。此时应把“同节点不同目标”与“同目标不同节点”交叉测试，而不是仅反复测试一个延迟地址。

1. 同一节点测试两个目标。如果普通网页可访问，只有延迟测试失败，检查客户端配置的测试 URL、响应要求和超时阈值。测速目标故障不等于节点失效。
2. 同一目标换另一个节点。如果只有一个出口失败，可能是该出口到目标的路由、目标风控或服务端解析异常。
3. 查看账户状态。核对有效期、流量余额、在线设备限制，以及服务方维护通知。订阅仍能下载，不代表代理账户仍有可用额度。
4. 向服务方提交脱敏证据。提供故障时间和时区、节点标识、内核版本、错误类型、换网结果及目标域名，不提交密码、UUID、完整订阅链接或完整配置。

connection refused 通常表示连接收到明确拒绝，常见于端口没有服务监听或中间设备主动拒绝；i/o timeout 表示某次网络操作未在期限内完成，需结合日志判断发生在连接、握手还是读写阶段；EOF 表示数据流结束，本身并不能确定是认证失败还是远端主动断开。

如果节点能打开普通网站，但某个平台返回 403、验证码或地区限制，应按目标网站与出口的关系处理。此时单纯增加连接超时不会解决应用层限制，也不应把它归为本地端口故障。

恢复验证：确认实际流量走了预期策略

排查结束的标准是实际请求成功且路径符合预期，不是延迟数字变绿。在规则模式下，客户端会按规则选择策略；节点测试往往直接测试指定节点，两者的流量路径可能不同。应在连接页面或运行日志中确认目标域名、命中规则和最终使用的节点。

• 浏览器失败、显式代理请求成功：检查系统代理端口、浏览器自己的代理设置、扩展接管和绕过列表。已有连接可能复用旧路径，可关闭相关连接后重新请求。
• 浏览器正常、终端失败：终端工具不一定读取系统代理。可先用本文的 curl -x 显式代理方式验证，再决定是否设置该工具支持的代理环境变量。
• 需要接管更多应用：TUN 可以处理部分不读取系统代理的流量，但仍依赖权限、路由和 DNS 配置。启用 TUN 不会修复过期订阅、错误密码或失效节点。
• 临时调整过日志级别：完成排查后将 log-level 恢复为日常使用的 info 或原设置，避免长期保留大量包含访问目标的信息。