先确认失败发生在哪一层
Clash 客户端更新订阅时,会先访问订阅地址,接收服务端返回的内容,再把内容解析成配置文件。最后一步才是载入代理节点、规则和 DNS 设置。界面上相同的“更新失败”,可能对应连接超时、HTTP 状态异常、响应内容错误或 YAML 解析失败。
排查时不要先删除当前配置。应保留仍能使用的配置副本,再查看更新提示和运行日志。部分客户端会把下载错误显示在订阅卡片旁,另一些客户端只在日志中记录完整原因。常见入口是「订阅」→「配置卡片」→「更新」,日志入口通常是「设置」→「日志」或「日志」→「内核日志」。
| 界面或日志提示 | 通常对应的环节 | 优先检查项 |
|---|---|---|
| timeout、deadline exceeded | 建立连接或等待响应超时 | 网络路径、系统代理、DNS、服务端负载 |
| 404 Not Found | 订阅路径不存在 | 地址是否完整、令牌是否失效、套餐是否重置 |
| 401 或 403 | 鉴权被拒绝 | 令牌、账户状态、请求频率和来源限制 |
| unexpected end、EOF | 响应被中断或文件不完整 | 网络波动、网关限制、服务端生成任务 |
| yaml、parse、unmarshal | 配置解析失败 | 返回内容格式、缩进、字段类型和客户端兼容性 |
| 更新成功但节点为 0 | 内容有效但没有可载入代理 | 订阅类型、账户可用节点、转换模板 |
订阅拉取超时的逐层排查
第一步:判断订阅域名是否可达
超时不等于节点失效。订阅下载和代理节点连接是两条不同链路:前者访问订阅服务域名,后者连接配置中的代理服务器。即使现有节点可以访问网页,订阅域名仍可能因 DNS、路由或服务端故障而无法连接。
- 记录失败时间,连续手动更新两次,两次之间间隔 60 秒,排除短暂抖动。
- 切换一次网络,例如从家庭宽带切到移动热点,重新更新。
- 分别测试关闭系统代理和保持当前代理两种状态。某些订阅域名需要直连,另一些网络环境则需要通过现有代理访问。
- 检查设备日期、时间与时区。时间偏差较大时,TLS 连接可能在下载前终止。
- 查看日志中的目标域名和错误阶段。DNS 查询超时与 TCP 连接超时需要分开处理。
如果关闭系统代理后能够更新,应检查订阅域名是否被错误分配给不可用节点。可在规则中为该域名设置直连,也可以在更新期间临时选择 DIRECT。若只有开启代理才能更新,则应保留一个稳定配置作为更新通道,不要在新配置验证完成前覆盖它。
第二步:区分 DNS 超时和连接超时
日志出现“no such host”“DNS lookup failed”或“i/o timeout”并指向 DNS 时,先检查 Clash 的 DNS 模块。使用 mihomo 内核时,还要留意 nameserver、proxy-server-nameserver 与 nameserver-policy 的分工。代理服务器域名无法解析时,订阅下载和节点连接都可能受影响。
- 临时关闭 TUN 模式后重试,用于判断流量是否在 TUN、系统代理和本机 DNS 之间形成回环。
- 确认本地监听端口没有冲突。常见 mixed-port 为 7890,HTTP 端口常见为 7890,SOCKS 端口常见为 7891,实际值以当前配置为准。
- 若系统中同时运行抓包工具、另一套代理客户端或 VPN,先完全退出其中一个,再重启 Clash 内核。
- 修改 DNS 配置后执行一次内核重启,只切换代理组通常不会重建全部 DNS 状态。
第三步:适当调整下载等待时间
客户端提供订阅超时设置时,可把 10 秒临时提高到 30 秒进行验证。超过 30 秒仍持续失败,继续增加到数分钟通常不能解决路径故障。较合理的测试参数是连接等待 10 秒、总下载时间 30 秒,并允许跟随 HTTP 重定向。
桌面系统可以用命令查看响应状态。先在终端执行 read -s SUB_URL 并粘贴订阅地址,按回车后再执行下列命令。这样可减少令牌直接留在命令历史中的机会。
curl -L \
--connect-timeout 10 \
--max-time 30 \
-D headers.txt \
-o profile.yaml \
"$SUB_URL"
wc -c profile.yaml
head -n 8 headers.txt退出码为 0 只代表下载过程完成,不代表内容一定是 Clash 配置。继续检查 HTTP 状态、文件大小和内容类型。正常配置通常至少包含 proxies、proxy-providers、proxy-groups 或 rules 中的一部分。
返回 404、401 或 403 时怎么处理
404:地址路径或订阅令牌已经变化
404 表示服务器可以访问,但当前路径不存在。最常见原因是复制时漏掉查询参数、订阅令牌被重置、旧地址停止提供,或者地址中包含的特殊字符被聊天软件截断。不要只比较域名,需要从协议开头到最后一个字符完整比较。
- 回到订阅服务的控制面板,重新复制适用于 Clash 或 Clash Meta 的订阅地址。
- 删除客户端中的失败条目后重新粘贴,避免旧条目仍引用缓存地址。
- 确认地址前后没有空格、换行和中文引号。
- 如果服务端刚执行令牌重置,旧地址应视为失效,所有设备都要更新。
- 等待 2 至 5 分钟再试,部分服务需要重新生成配置或同步边缘缓存。
浏览器打开地址后显示下载并不代表客户端一定会成功。有些服务会根据 User-Agent 返回不同格式,也可能要求特定请求头。反过来,浏览器显示网页也不等于订阅失效,因为服务端可能把普通浏览器请求导向说明页面。应以客户端日志中的状态码和实际响应内容为准。
401 与 403:鉴权或访问策略拒绝
401 通常表示令牌无效或缺失,403 则可能表示账户状态、来源地址、访问频率或服务端策略不允许当前请求。先登录服务面板确认账户与订阅状态,再重新生成地址。若短时间内连续点击更新数十次,服务端可能触发限流,此时应停止请求 10 至 30 分钟。
下载成功但内容为空或无法解析
先检查返回的是 YAML、Base64 还是 HTML
客户端收到 HTTP 200 后仍可能更新失败。服务端可能返回登录页、错误说明、空文件、通用 Base64 节点列表,或者当前客户端不支持的字段。若下载文件只有几十字节,或者开头出现 <!DOCTYPE html>、<html>,说明拿到的不是配置文件。
Clash 配置通常采用 YAML。节点既可以直接写在 proxies 下,也可以通过 proxy-providers 引用远程提供者。只包含其他客户端格式链接的文本,不能直接当作完整 Clash 配置载入。服务端面板存在客户端类型选项时,应选择与内核匹配的 Clash 或 mihomo 格式。
检查 YAML 缩进和字段类型
YAML 使用空格表示层级,不能把同一层级混用制表符。常见错误包括端口被写成非数字文本、代理组引用了不存在的节点、规则提供者缺少 behavior,以及旧内核无法识别新字段。更新客户端和 mihomo 内核后再次载入,可以排除版本过旧造成的兼容问题。
proxy-providers:
remote-main:
type: http
url: "https://sub.example.net/client/REDACTED"
path: ./providers/remote-main.yaml
interval: 21600
health-check:
enable: true
interval: 600
url: "https://www.gstatic.com/generate_204"上例中的 interval: 21600 表示每 21600 秒更新一次提供者,即 6 小时。健康检查的 interval: 600 表示每 10 分钟测试一次节点可用性。两者用途不同:健康检查不会重新下载订阅,订阅更新也不会替代持续的节点检测。
更新成功但节点数量为零
节点为零时先查看原始响应,确认服务端是否确实返回代理条目。账户到期、流量用尽、地区筛选结果为空或转换模板错误,都可能生成结构有效但没有节点的配置。如果配置只包含规则和代理组,却没有 proxies 或可用的 proxy-providers,客户端无法凭空生成节点。
还要确认代理组的引用关系。配置中已有节点,但代理组的 use 指向错误的 provider 名称时,界面也可能显示空组。名称区分大小写,例如 remote-main 与 Remote-Main 应视为不同标识。
自动更新间隔应该设置多久
自动更新不是越频繁越好。订阅内容通常不会以分钟为单位变化,高频请求会增加服务端压力,也容易触发限流。对个人设备而言,6 至 24 小时是更稳定的范围。临时等待服务端修复时,应手动更新一次,而不是把周期改成 60 秒。
| 使用场景 | 建议间隔 | 秒数 |
|---|---|---|
| 节点变化较频繁的日常设备 | 6 小时 | 21600 |
| 普通桌面与手机 | 12 小时 | 43200 |
| 长期稳定的家庭设备 | 24 小时 | 86400 |
| 临时排障 | 关闭自动重试,按需手动更新 | 不适用 |
图形客户端中的设置位置
不同客户端对“配置”和“订阅”的命名并不统一。常见操作路径是「订阅」→「选择配置」→「编辑」→「更新间隔」,或「配置」→「订阅卡片菜单」→「自动更新」。有些客户端按小时填写,输入 6 代表 6 小时;另一些客户端按分钟填写,6 小时应输入 360。保存前必须查看输入框后的单位。
Clash Verge Rev 一类 mihomo 图形客户端通常把远程配置集中在「订阅」页面。修改更新间隔后,先保存订阅设置,再手动更新一次并观察更新时间。旧版 Clash for Windows 的菜单名称与新客户端不同,应在 Profiles 页面检查远程配置条目及其更新选项。若界面没有间隔设置,不要直接假设后台会自动更新。
mihomo 配置中的两个 interval
手写配置时,最容易混淆的是提供者更新周期与健康检查周期。proxy-providers 条目下的顶层 interval 控制远程文件重新下载;嵌套在 health-check 下的 interval 控制连通性测试。前者适合 21600 至 86400 秒,后者常见为 300 至 900 秒。
健康检查过于频繁会产生额外连接。拥有大量节点时,每 30 秒检测一次可能造成瞬时并发和电量消耗。移动设备可把健康检查设为 600 秒或更长,并只对实际使用的 provider 开启。订阅更新失败时,调整健康检查间隔不会解决下载问题。
TUN 模式、系统代理与订阅更新的关系
开启 TUN 后,客户端可以接管更多系统流量,但订阅请求仍可能由图形界面进程或内核发起。不同客户端的实现不同,请求不一定遵循当前代理组。出现“浏览器能打开,客户端更新超时”时,应重点检查界面进程是否走系统代理、订阅域名是否命中规则,以及 TUN 路由是否发生循环。
- 关闭 TUN,保留系统代理,测试一次更新。
- 关闭系统代理,只保留 TUN,测试一次更新。
- 两者都关闭,让订阅请求直连,测试一次更新。
- 恢复原设置后重启内核,确认日志中没有端口占用或路由安装失败。
上述测试每次只改变一个变量。若同时修改 DNS、代理模式、TUN 和订阅地址,即使更新恢复也无法判断真正原因。测试期间可以保持规则模式,并为订阅域名单独设置 DIRECT 或指定稳定代理组。
一套可重复执行的排查顺序
- 保留旧配置:先导出仍可用的配置,不要直接覆盖。
- 读取完整错误:记录状态码、目标域名、发生时间和日志关键词。
- 检查地址:重新复制订阅 URL,排除空格、截断和过期令牌。
- 切换网络:分别用当前网络与移动热点测试。
- 切换请求路径:依次测试直连、系统代理和 TUN 状态。
- 查看响应:确认 HTTP 状态、文件大小以及是否为 YAML 内容。
- 验证配置:检查 proxies、proxy-providers、代理组引用和 YAML 缩进。
- 核对内核:更新到客户端支持的 mihomo 内核版本后重新载入。
- 设置合理周期:日常使用设为 6、12 或 24 小时,避免分钟级更新。
- 最后联系服务端:提供失败时间、状态码和已脱敏日志,不要发送完整订阅令牌。
恢复更新后还要检查什么
订阅显示更新成功后,先确认更新时间、节点数量和代理组是否符合预期,再切换到新配置。选择一个节点执行延迟测试,随后访问常用站点验证规则分流。若节点存在但所有连接失败,问题已经从“订阅下载”转移到“节点连接”,应查看连接日志而不是继续重复更新订阅。
最后把自动更新周期恢复到合理值。排障期间设置的短周期应及时取消,避免后台持续请求。桌面客户端可观察 24 小时内是否按计划更新一次;移动系统可能限制后台任务,因此自动更新时间会受省电策略和系统调度影响,必要时在打开客户端后手动更新。
完整的判断链路是:地址有效、网络可达、响应内容正确、配置能够解析、代理组引用有效、节点可以连接。沿这六步逐层确认,比反复删除客户端或连续点击更新更容易定位问题。