先判断失败发生在哪一步
客户端里的“更新订阅”不是单一动作。它至少包含域名解析、建立连接、发送 HTTP 请求、接收响应、解析配置、写入本地文件和重新载入内核几个阶段。界面只显示“更新失败”时，需要先从日志或响应内容确认具体阶段。直接重复点击通常不会改变结果，还可能触发订阅服务的频率限制。
常见桌面客户端会把订阅放在“配置”“订阅”或“Profiles”页面。以采用 mihomo 内核的客户端为例，可以先进入「配置」→「订阅」，对目标配置执行一次手动更新，再到「日志」页面查看同一时间产生的记录。若客户端提供日志级别，在排查期间选用 Info；只有错误信息过少时才临时切到 Debug。
| 日志或现象 | 通常对应的阶段 | 优先检查项 |
|---|---|---|
no such host、域名解析失败 |
DNS 解析 | DNS 设置、网络连接、订阅域名是否仍有效 |
timeout、连接超时 |
建立连接或等待响应 | 直连与代理路径、防火墙、服务端状态 |
401 或 403 |
服务端鉴权 | 令牌、链接有效期、User-Agent 与访问限制 |
404 或 410 |
订阅地址失效 | 重新取得完整订阅链接 |
| YAML、Base64 或字段解析错误 | 配置解析 | 响应格式、转换类型、客户端兼容性 |
| 下载成功但配置未变化 | 保存或重新载入 | 本地缓存、当前启用配置、文件写入权限 |
区分订阅下载和节点连通性
订阅更新成功，只表示客户端取得并解析了配置，不代表其中的代理节点一定可连接。反过来，现有节点能够使用，也不代表订阅地址仍然有效。本地配置可能是数天前保存的缓存，节点还能工作，而原订阅令牌已经过期。
- 更新失败但旧节点可用：重点检查订阅地址、鉴权和更新路径。
- 更新成功但全部节点超时：重点检查节点参数、网络限制和系统时间。
- 节点数量变成 0：先检查服务端返回内容，不要只看 HTTP 状态码。
- 配置下载后无法启用：检查 YAML 语法、字段兼容性和内核版本。
订阅链接过期、截断与鉴权失败
订阅地址通常包含访问令牌。令牌被重置、套餐状态变化、链接设置了有效期，或者服务端迁移路径后，旧地址就可能返回 401、403、404 或 410。部分服务会返回状态码 200，但正文其实是登录页面或一段 JSON 错误信息，所以“下载完成”仍可能在解析阶段失败。
确认复制的是完整链接
长链接经过聊天软件、二维码识别或手动换行后，容易丢失末尾字符。还要留意查询参数中的 &：从网页复制时应取得浏览器地址栏中的真实链接，而不是把 HTML 中显示的转义文本原样写入客户端。链接前后也不应带空格、中文引号或换行。
- 回到订阅服务的管理页面，重新复制 Clash 或 mihomo 对应的订阅地址。
- 在客户端中新建一条临时订阅，不急着删除旧配置。
- 执行手动更新，对比节点数量、策略组名称和更新时间。
- 确认新配置可载入后，再停用已失效的旧订阅。
订阅链接相当于访问凭据，不适合贴到公开日志、截图或在线 YAML 检查网站。需要提供错误信息时，可以保留域名与状态码，但应遮去路径中的令牌和查询参数。
用命令行查看状态码与响应类型
浏览器可能自动跳转到登录页，也可能使用与 Clash 不同的请求头。命令行测试更容易看到状态码和响应头。Windows 可在 PowerShell 中调用 curl.exe，macOS 与 Linux 可直接使用 curl。下面使用保留域名演示，不包含真实订阅凭据。
curl -I -L --max-time 15 "https://sub.example.com/clash/demo-token"
curl -L --max-time 15 -o subscription.yaml "https://sub.example.com/clash/demo-token"-I 只请求响应头，但少数订阅服务器不接受 HEAD 请求。如果第一条命令返回 405，应以第二条实际 GET 请求为准。下载完成后先查看文件开头：HTML 常以 <!doctype html> 或 <html 开始，JSON 错误常以花括号开始，Clash YAML 则通常能看到 proxies:、proxy-groups:、rules: 等字段。
User-Agent 校验与格式不兼容
部分订阅服务会根据 User-Agent 返回不同格式，或只允许特定客户端标识。浏览器访问正常而客户端更新返回 403，或者同一个地址在不同客户端得到不同内容，就需要检查 UA。常见标识包括 clash、Clash.Meta 和客户端自身名称，但服务端接受哪一种取决于其配置，不能靠不断随机更换来判断。
先在订阅服务说明中确认推荐 UA。若客户端提供设置项，可在「设置」→「参数设置」或订阅编辑窗口中查找“User-Agent”“订阅请求头”一类选项。菜单名称会随客户端版本变化；没有该选项时，不应直接修改核心配置来猜测，因为主配置中的代理规则并不等于订阅管理器的 HTTP 请求头。
curl -L --max-time 15 \
-A "Clash.Meta" \
-o subscription.yaml \
"https://sub.example.com/clash/demo-token"如果默认请求返回 403，而使用服务方明确要求的 UA 后得到 200 和有效 YAML，可以把问题定位为请求头校验。若两种请求都返回相同错误，则继续检查令牌、来源 IP、请求频率和服务状态。
Base64 节点列表与 Clash YAML 不是同一种格式
通用订阅可能是一段 Base64 文本，解码后包含多行 URI；Clash 配置则通常是结构化 YAML。客户端若只接受 Clash YAML，导入通用订阅就可能出现“缺少 proxies”“无法解析配置”或节点数量为 0。此时应在服务端选择 Clash、Clash Meta 或 mihomo 输出类型，而不是手动给文件改扩展名。
mihomo 对 Clash 配置保持较广兼容，但扩展字段并不一定被旧版 Clash 内核识别。例如某些新协议参数、规则提供器选项和 DNS 字段在旧内核中会报未知字段或载入失败。遇到这种情况，应先查看客户端的内核版本，再选择匹配的订阅模板。更新图形客户端不一定会自动切换内核，内核版本需要在「设置」→「内核」或“关于”页面单独确认。
YAML 能打开，仍可能无法载入
- 同一层级缩进必须一致，不能混用 Tab 与空格。
- 策略组引用的节点或提供器名称必须存在。
rules中使用的目标策略组必须已经定义。- 端口应为有效整数，不能被引号、中文符号或注释破坏。
- 服务端若返回空文件，客户端可能保留旧配置，也可能报告解析结束但没有节点。
订阅本身由服务端生成时，通常不建议在下载文件上长期手改。下一次自动更新会覆盖改动。需要保留本地 DNS、TUN 或规则设置时，应优先使用客户端提供的覆写、合并配置或脚本功能，并在每次客户端升级后确认合并结果。
更新时走直连还是走代理
订阅请求走哪条路径，是最容易被忽略的变量。订阅域名可以直接访问时，使用直连最简单，也不会依赖现有节点。订阅域名只能经代理访问时，则需要启用客户端的“通过代理更新”选项，或者让客户端的更新器使用当前代理。不同客户端对这一选项的实现不同，有的使用系统代理，有的直接调用当前内核端口。
优先采用可启动的更新路径
如果订阅更新必须依靠订阅里的节点，就会形成启动依赖：本地没有可用旧节点时，无法连接订阅服务器；无法更新订阅，又拿不到新节点。更稳妥的做法是保留最近一次可用配置，并避免在更新失败时清空本地文件。
| 网络条件 | 推荐更新路径 | 原因 |
|---|---|---|
| 订阅域名可直接访问 | 直连 | 减少对当前节点和代理端口的依赖 |
| 直连超时，当前代理可访问 | 通过代理更新 | 绕开本地网络到订阅站点的连接问题 |
| 代理开启后反而更新失败 | 临时切回直连测试 | 排除节点故障、规则误分流和代理认证问题 |
| 新设备尚无可用配置 | 使用服务方可直连入口 | 避免依赖尚未建立的代理连接 |
需要注意，订阅管理请求未必经过 Clash 规则。某些客户端在自身进程中直接下载订阅，另一些客户端会把请求送到本地 mixed-port。即使规则里写了订阅域名走 DIRECT，也不能保证客户端更新器一定采用该规则。应以客户端文档、更新设置和日志中的实际连接路径为准。
检查本地端口与系统代理
常见配置会把 mixed-port 设为 7890，外部控制端口设为 9090，但这些只是常见值，不是固定要求。7890 被其他进程占用时，系统代理仍可能指向旧端口，浏览器和订阅更新器就会连接失败。先在客户端“常规”或“网络”页面确认当前 HTTP、SOCKS 和 mixed 端口，再核对操作系统代理地址是否一致。
TUN 模式覆盖范围通常比系统代理更广，但开启 TUN 并不能修复失效链接、错误 UA 或 YAML 格式问题。若只在 TUN 开启时更新失败，可临时关闭 TUN，保留系统代理后测试一次；再检查 DNS 劫持、路由排除项和订阅域名是否被错误送入不可用策略组。
自动更新间隔怎么设置
自动更新不是越频繁越好。节点与策略变化不频繁的订阅，每 6 小时更新一次通常足够；以秒为单位时是 21600。变化较快且服务端允许高频请求的订阅，可以设为 1 小时，即 3600 秒。每天更新一次则是 86400 秒。低于 15 分钟的频率容易产生不必要请求，也可能触发 429 限流。
| 使用情况 | 建议间隔 | 秒数 |
|---|---|---|
| 普通个人使用，节点变化较少 | 6 小时 | 21600 |
| 节点经常调整，服务端允许频繁刷新 | 1 小时 | 3600 |
| 配置长期稳定，只需定期同步 | 24 小时 | 86400 |
| 临时排查期间 | 关闭自动更新，改用手动 | 避免错误请求反复触发 |
图形客户端通常会在订阅编辑窗口提供更新间隔，单位可能是小时、分钟或秒。修改前先看字段说明，不要把 3600 填进以“小时”为单位的输入框。部分客户端只在程序运行期间计时；设备休眠后，下一次更新可能在唤醒时立即执行。
mihomo 的 proxy-provider 更新示例
如果配置使用 proxy-providers，可以给每个提供器设置独立的 interval。该值的单位是秒。下面的例子每 6 小时拉取一次提供器文件，并每 10 分钟执行一次健康检查。健康检查与订阅更新是两套计时，不能互相替代。
proxy-providers:
service-a:
type: http
url: "https://sub.example.com/provider/demo-token"
path: ./providers/service-a.yaml
interval: 21600
health-check:
enable: true
url: "https://www.gstatic.com/generate_204"
interval: 600interval: 21600 控制远程提供器文件的刷新周期；health-check.interval: 600 只控制节点可用性检测。把健康检查设为 600 秒，不会让订阅每 10 分钟重新下载。反过来，订阅更新成功也不会证明每个节点都通过健康检查。
按顺序完成一次完整排查
订阅故障适合从外到内处理：先确认链接和服务端响应，再检查请求头与网络路径，最后处理格式和本地载入。这样可以避免在链接已经失效时反复修改 DNS、TUN 和规则。
- 记录错误时间。手动更新一次，立即查看日志中的状态码、域名、超时或解析错误。
- 确认链接完整。从服务端重新复制 Clash 或 mihomo 类型链接，在客户端中新建临时订阅。
- 测试直连响应。关闭“通过代理更新”后尝试一次，记录结果。
- 测试代理响应。恢复一个已知可用节点，启用“通过代理更新”再尝试一次。
- 核对 User-Agent。仅使用服务端明确支持的标识，对比 403、200 和响应正文。
- 检查内容格式。确认响应不是 HTML、错误 JSON、空文件或不兼容的 Base64 列表。
- 核对内核与字段。查看 mihomo 或 Clash 内核版本，定位未知字段、策略组引用和 YAML 缩进问题。
- 重新载入配置。确认新文件保存成功，并在配置页明确选中更新后的条目。
- 恢复合理间隔。普通场景设为 6 小时，频繁变化场景设为 1 小时，并观察是否出现 429。
更新成功后的验证
更新完成后，不要只看绿色提示。先记录节点总数和策略组名称，再选取一个节点执行延迟测试。随后访问一个适合验证出口地址的页面，并在 Clash 连接记录中确认请求命中了预期策略。若客户端显示更新成功，但节点列表和文件修改时间都没有变化，应检查是否更新了未启用的订阅条目。
如果自动更新偶尔失败、手动更新立即成功，常见原因包括设备刚从休眠恢复、网络尚未就绪、代理内核启动晚于订阅任务，或服务端短时限流。可以适当延长更新间隔，并保留失败日志。若每次都在固定网络环境失败，则应重点比较直连、系统代理与 TUN 三种路径，而不是继续缩短刷新周期。
最终稳定状态应满足四点：订阅链接有效，更新请求路径明确，返回内容与当前内核兼容，自动刷新频率符合服务端限制。把这四项分别确认后，订阅更新失败通常能够定位到具体一层，不需要重装客户端或清空全部配置。