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

Clash 客户端里的“超时”，通常表示某次请求没有在规定时间内完成，并不直接等于订阅失效。延迟测试会通过指定节点访问测试地址；节点握手、域名解析、测试站点响应，其中任一环节失败，都可能显示超时。Clash 是客户端生态中的通用称呼，具体界面与功能取决于客户端和正在运行的内核，mihomo 也常见于使用 Clash Meta 名称的配置说明中。

先记录故障边界：是所有节点测速失败，还是只有一个策略组失败；是测速失败但网页能打开，还是所有代理请求都失败；是刚更新配置后出现，还是切换 Wi-Fi 后出现。保留这些信息，比连续点几十次测速更有用。

  1. 暂停批量测速，手动选择一个节点；若使用规则模式，确认目标请求确实命中该节点所在的策略组。
  2. 打开客户端的“连接”和“日志”页面，再访问一个已知可用的 HTTPS 页面，记录同一时刻的目标地址、命中规则与错误。
  3. 若网页可用而测速全部失败，优先检查测试地址、测试超时与并发量，不要先重装客户端。

第一步：确认本地网络与订阅状态

先排除登录认证与网络切换

暂时关闭系统代理与 TUN，确认普通直连网站能够访问。酒店、校园和公共 Wi-Fi 可能要求先完成网页认证；认证前，即便无线图标正常，节点连接也可能统一失败。手机热点可作为对照：保持相同配置、相同节点、相同目标，仅切换接入网络。如果热点可用而原网络不可用，应继续检查原网络的 DNS、出口限制或路由设备。

订阅更新成功，不代表服务仍然可用

  • 账户状态：在服务提供方页面确认到期时间、剩余流量、设备或并发连接限制，注意页面时间使用的时区。
  • 更新结果：检查订阅更新记录与节点数量。HTTP 401、403 往往涉及凭据或访问限制，429 表示请求可能受到频率限制；具体原因仍需结合服务端提示。
  • 配置是否加载：下载成功只是拿到文件，还需确认当前启用的是新配置，且内核没有因为字段错误拒绝加载。
  • 节点来源：多个地区的节点可能共用一个入口域名。“全部超时”也可能是同一个入口故障，而非每台服务器同时损坏。

如果订阅更新本身需要代理，失效线路可能造成更新循环失败。可在服务提供方支持的网络环境中更新，或使用其提供的本地配置导入方式。订阅 URL 通常包含访问凭据，不要粘贴到公开测速站、转换服务或讨论区。

第二步：校准系统时间，检查握手条件

TLS 证书有效期检查以及部分协议的认证机制依赖系统时钟。设备休眠后时钟异常、手动设置了错误日期，都会让多个节点同时失败。不要只看任务栏上的小时和分钟：应同时检查日期、年份、时区和自动同步结果。

  • Windows 11：进入「设置」→「时间和语言」→「日期和时间」，开启“自动设置时间”，检查时区并点击“立即同步”。
  • macOS：进入「系统设置」→「通用」→「日期与时间」，启用自动设置日期与时间；系统版本不同，选项文字可能略有差异。
  • Linux：执行 timedatectl status，查看系统时钟同步状态；使用 systemd 的系统可按本机管理规范启用时间同步服务。

例如，日志出现 x509: certificate has expired or is not yet valid，先将系统时间与可信时间来源对照。校时后仍然出现相同错误，才继续检查服务端证书。不要通过关闭证书验证来掩盖问题；skip-cert-verify 也不能修复错误密码、不可达端口或不匹配的协议参数。

第三步：检查内核启动与端口占用

节点列表能显示，不等于代理内核已经正常运行。图形界面可能读取到了配置，但内核在启动时因端口占用而退出。先在客户端日志中查找启动失败、配置解析错误及 address already in use，再核对实际监听端口。

下面以本地混合代理端口 7890 为例；这是示例值，不是所有客户端的固定设置。请先在客户端端口设置或生效配置中读取 mixed-port、port、socks-port。控制接口有时使用 9090，它用于管理内核，不应填进浏览器的 HTTP 代理端口。

查看谁占用了 7890

Windows 可在 PowerShell 中查看监听地址和进程 ID，再查询对应程序：

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

Get-Process -Id 1234

第二条命令中的 1234 仅用于演示，应替换为第一条命令实际返回的进程 ID。macOS 与常见 Linux 系统可使用：

lsof -nP -iTCP:7890 -sTCP:LISTEN

如果监听者是另一款代理客户端，先正常退出另一款软件，再启动当前客户端；不要直接结束不认识的系统进程。如果改用 7891，应用中的手动代理设置也必须同步修改。日常仅供本机使用时，保持回环地址监听即可，不必为了排查而启用局域网访问。

第四步：用显式代理请求缩小范围

暂时关闭 TUN，并手动选定一个节点。通过指定本地代理地址发送请求，可以绕开“应用是否遵循系统代理”的不确定性，但请求仍然受到内核当前模式与规则的影响。测试时打开连接面板，确认流量没有被规则分到 DIRECT。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 5 --max-time 15 \
  --output /dev/null --write-out "%{http_code}\n" \
  https://cp.cloudflare.com/generate_204

这条命令适用于 macOS 或 Linux shell。Windows PowerShell 可使用下面的一行命令，明确调用 curl.exe：

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 --output NUL --write-out "%{http_code}\n" https://cp.cloudflare.com/generate_204
  • 返回 204：说明这一次通过本地代理访问该目标成功，仍需在连接面板确认实际策略与出口。
  • 立即连接拒绝：先检查本地端口、监听地址与内核进程。若本地连接已建立，拒绝也可能来自后续远端连接，应结合日志定位。
  • 等待后超时：检查远端连接、DNS、握手与测试目标，不要仅凭 curl 的结果判定具体协议故障。

测试地址也可能被特定线路限制，因此应再用另一个已知可用的 HTTPS 目标交叉验证。若测试超时设为 1000 毫秒，可临时提高到 5000 毫秒并顺序测试两次；这是排查示例，不是统一推荐值。提高超时只会增加等待时间，不会修复认证错误或失效入口。

第五步：按日志关键词定位 DNS、认证与协议

将日志级别临时调到 info，信息不足时再使用 debug。仅复现一次请求，按时间筛选相关记录。排查结束后恢复原级别，避免持续产生大量日志。分享日志前移除订阅地址、密码、令牌及其他账户信息。

日志线索 优先检查 下一步操作
lookup、no such host 节点入口域名或目标域名解析失败 区分正在解析哪个域名，检查 DNS 上游是否可达以及节点域名是否仍有效。
i/o timeout、context deadline exceeded 连接或请求超过时限 结合前后日志区分 DNS、TCP、TLS 等阶段，再切换网络作对照。
connection refused 目标地址端口未接受连接 核对拒绝发生在本地还是远端，检查端口填写与服务状态。
authentication failed 认证信息或协议参数不匹配 更新原始订阅，核对凭据，不要仅手动修改节点显示名称。
TLS handshake、x509 时间、证书、SNI 或握手链路 先校时，再核对配置中的服务器名称及服务端要求。
unsupported、unknown proxy type 内核不支持协议或配置字段 确认实际运行的内核类型与版本，使用与订阅匹配的客户端。

入口解析与目标解析不是同一件事

节点服务器域名必须先被正确解析，内核才能连接入口；浏览器访问的网站域名则属于后续目标解析。两者可能走不同的解析路径。若节点入口解析已经失败，反复调整网站分流规则通常没有帮助。可以用 nslookup 查询自己的入口域名，但系统查询成功也不能证明内核的 DNS 配置正常。

mihomo 的 DNS 设置可能涉及 nameserver、default-nameserver 与 proxy-server-nameserver，具体支持范围以正在使用的内核文档为准。不要把全部 DNS 请求强行送进一个尚未连通的代理，从而制造解析与连接互相依赖的循环。

协议参数应成组核对

旧 Clash 内核不能直接按 mihomo 的功能范围理解。配置含有 Hysteria2 等协议时，应确认运行内核支持它。基于 UDP 的传输还可能受到当前网络限制：若 TCP 类节点可用而此类节点统一失败，热点对照比盲目修改密码更有诊断价值。服务器端口、认证、SNI、传输方式等应以原始订阅为准，转换配置可能遗漏字段。

第六步：基础代理恢复后，再排查 TUN 与规则

如果显式代理请求已经成功，只有开启 TUN 后失败，问题应转向路由、权限、DNS 接管与其他虚拟网卡。TUN 接管的是系统网络流量，不是提升节点可达性的开关。它不能让过期账户恢复，也不能修复服务器错误端口。

  1. 退出其他 VPN、代理客户端与可能改写路由的软件，避免多个接管组件同时工作。
  2. 按客户端要求确认服务模式或系统权限，再单独开启 TUN，保留连接日志。
  3. 检查 DNS 请求是否被正确接管，以及代理服务器自身的连接是否错误地再次进入隧道。
  4. 若只在 TUN 下访问部分 HTTPS 站点卡住，再考虑路径 MTU 等问题；记录原值后单项测试，不要将 MTU 调整当成全部超时的首选方案。

规则模式下还要确认实际策略组选择。一个 select 组可能选中了另一个自动策略组，而自动组仍在使用旧的测试结果。直接选择一个具体节点并查看连接链路，能够减少嵌套组带来的歧义。临时使用全局模式也可作对照，但测试结束后应恢复原模式，避免改变其他应用的流量路径。

排查结果记录与恢复顺序

当故障仍未解决，提交“全部超时”四个字通常不足以定位。整理下面这组信息，既方便向服务提供方确认入口状态，也便于客户端维护者判断是否为内核或系统接管问题。

  • 操作系统版本、客户端版本、实际内核名称与版本，均从本机“关于”或启动日志读取。
  • 故障开始时间，以及此前是否更新订阅、升级系统、切换网络或开启 TUN。
  • 相同节点在原网络与手机热点下的结果，以及显式代理请求的返回情况。
  • 一段包含错误前后文的脱敏日志，注明目标请求时间、是否使用 TUN、实际命中的策略组。

恢复时先让一个节点通过显式代理完成请求，再验证系统代理，最后开启确有需要的 TUN 和自动策略组。按照“本地网络与账户 → 系统时间 → 内核与端口 → DNS 和握手 → 接管与规则”的顺序推进，能够将入口故障、测试误报与本机配置问题分开处理。需要重新选择兼容客户端时，可查看Clash 客户端下载中心；具体导入与基础设置见使用文档。