先判断失败发生在哪一层
Clash 客户端里的“更新失败”不是单一故障。一次远程订阅更新通常要经过域名解析、TCP 与 TLS 连接、HTTP 请求、内容下载、配置解析、内核校验和配置切换。界面只显示一个失败提示时，应先确认具体停在哪一步，而不是连续点击更新。
最有价值的判断依据是客户端日志、HTTP 状态码和下载内容。先记录失败时间，再打开日志页面，在同一分钟内查找包含订阅域名、timeout、certificate、401、403、404、parse 或 yaml 的条目。不同阶段对应的处理方向并不相同。
| 观察结果 | 故障阶段 | 优先检查项 |
|---|---|---|
| 域名解析失败、找不到主机 | DNS | 系统 DNS、TUN DNS、域名拼写与本地网络 |
| 连接超时或连接被重置 | 网络连接 | 直连可达性、代理路径、防火墙与 IPv6 |
| HTTP 401、403、404 或 410 | 服务器响应 | 令牌、订阅有效期、访问频率与链接是否完整 |
| 下载成功但提示 YAML 错误 | 配置解析 | 返回内容、缩进、字段兼容与内核版本 |
| 显示更新成功但节点未变化 | 配置切换 | 当前启用配置、缓存、重载状态与旧连接 |
链接过期、请求被拦与服务器响应异常
确认链接没有在复制时损坏
订阅地址可能因为换行、末尾空格、聊天软件截断或 HTML 转义而失效。常见现象是地址只复制到第一个 & 之前，或者末尾令牌少了数个字符。应从订阅服务的管理页面重新复制完整 URL，再覆盖客户端中的旧地址，不要手工拼接令牌。
HTTP 状态码可以快速缩小范围。401 通常表示凭据或令牌不再有效；403 可能与访问策略、频率限制或来源网络有关；404 表示路径不存在；410 常用于明确告知资源已经失效；429 表示短时间请求过多。遇到 429 后继续高频刷新，通常只会延长限制时间。
在终端单独测试 HTTP 请求
桌面系统可以用 curl 把网络下载和客户端解析分开测试。先把订阅地址保存到当前终端的环境变量，再执行以下命令。命令设置 10 秒连接超时、30 秒总超时，并跟随 HTTP 重定向。
export SUB_URL='完整订阅地址'
curl -L \
--connect-timeout 10 \
--max-time 30 \
-D response-headers.txt \
-o profile.yaml \
"$SUB_URL"检查 response-headers.txt 中最终状态码，再查看 profile.yaml 的开头。标准 Clash 或 Mihomo 配置通常能看到 proxies:、proxy-groups:、rules: 等 YAML 字段。若内容以 <html 开头，实际下载到的是登录页、验证页或错误页；若返回 JSON 错误对象，也不能作为配置直接导入。
有些服务返回 Base64 编码的通用订阅，而客户端入口只接受 Clash YAML。此时网络请求虽然成功，解析仍会失败。应在服务端选择 Clash、Clash Meta 或 Mihomo 对应格式，而不是仅修改文件扩展名。
检查系统时间与 TLS 连接
设备时间偏差会影响 HTTPS 证书验证。若日志出现 certificate has expired、not yet valid 或握手失败，先启用系统自动校时。Windows 可在「设置」→「时间和语言」→「日期和时间」中开启自动设置时间；macOS 可在「系统设置」→「通用」→「日期与时间」中开启自动设定。
如果浏览器可以打开订阅地址，而客户端始终超时，还要比较两者使用的网络路径。浏览器可能正在使用系统代理，客户端更新器却采用直连；也可能正好相反。这个差异是“浏览器能开、Clash 更新失败”的常见原因。
代理环路、TUN 模式与 DNS 路径排查
订阅更新请求需要一条可用的启动路径。如果更新器依赖当前代理，而当前配置里的节点已经全部失效，就会形成启动依赖：必须先更新才能恢复节点，但更新请求又必须经过这些节点。另一种环路发生在客户端进程发出的请求被系统代理或 TUN 再次送回自身，日志可能连续出现相同域名连接、连接拒绝或超时。
用直连测试打破启动依赖
- 记录当前配置与模式，暂时关闭 TUN 模式。
- 关闭系统代理，确认浏览器或终端可以直接访问普通网站。
- 在客户端中对目标订阅执行一次手动更新。
- 更新成功后重新启用系统代理或 TUN，并恢复原有规则模式。
如果订阅域名必须经过代理才能访问，则需要保留一条已知可用的启动线路。可先切换到仍然可连接的本地配置，再更新远程配置。不要删除最后一份可用配置后再测试远程订阅。
核对本地端口和系统代理
常见桌面配置会把 HTTP 或 mixed 监听端口设为 7890，旧式分离配置可能使用 HTTP 7890 与 SOCKS 7891，外部控制端口常见为 9090。这些数值可以修改，因此应以当前客户端「设置」或「端口」页面显示的实际值为准。
系统代理若指向 127.0.0.1:7890，但内核没有运行或 mixed-port 已改为其他数值，所有经过系统代理的更新请求都会失败。先确认内核状态为运行，再检查端口是否正在监听。端口冲突日志通常包含 address already in use。
确认订阅域名的 DNS 结果
开启 TUN 与 fake-ip 后，应用看到的地址可能来自 fake-ip 地址池，这是正常的转发机制；但客户端自身的更新器仍需完成真实域名解析。若日志显示 DNS 超时，可临时关闭 TUN 后复测，以区分系统 DNS 与 Mihomo DNS 路径。
还应检查 IPv6。部分网络能够返回 AAAA 记录，却没有稳定的 IPv6 出口，表现为先等待约 10 至 30 秒再超时。可在系统层临时禁用该网络接口的 IPv6，或调整客户端 DNS 与连接策略后复测。只有在测试结果明确指向 IPv6 时才应长期修改，避免把其他故障一并掩盖。
下载成功但解析失败的处理顺序
当日志已经出现 HTTP 200，问题重点应从网络切换到内容。先检查下载文件是不是预期配置，再检查 YAML 语法，最后检查字段是否被当前内核支持。把三个阶段混在一起处理，容易反复修改 DNS 和代理设置，却始终没有触及解析错误。
先验证 YAML 基础结构
YAML 对缩进敏感，Tab 字符、列表层级错误、未闭合引号都可能导致配置拒绝加载。使用 Mihomo 命令行时，可以在不启动代理监听的情况下测试配置：
mihomo -t -f profile.yaml测试通过通常会给出配置校验成功信息；失败时会指出字段或行号。若配置由远程订阅自动生成，不建议直接在本地修补每次都会被覆盖的文件，应回到订阅格式设置或转换规则中处理。
区分完整配置与代理提供器
完整远程配置通常包含端口、DNS、代理组和规则，可作为客户端配置直接启用。proxy-providers 则是在主配置中引用独立节点集合，两者的更新机制不同。把只含节点列表的 provider 文件直接当完整配置导入，可能缺少 proxy-groups 和 rules；反过来，把完整配置填入 provider 地址也会因结构不符而失败。
在 Mihomo 配置中，provider 的 interval 单位是秒。例如下面的 21600 表示每 6 小时检查一次。它只控制该 provider，不等于图形客户端对整份远程配置设置的更新间隔。
proxy-providers:
remote-nodes:
type: http
url: "https://example.net/subscription/token-value"
path: ./providers/remote-nodes.yaml
interval: 21600
health-check:
enable: true
url: "https://www.gstatic.com/generate_204"
interval: 600字段兼容需要结合内核版本
订阅服务可能新增 Mihomo 字段，而客户端仍携带较旧内核；也可能输出旧 Clash 字段，与当前严格校验规则不一致。先在客户端的「关于」或「内核」页面确认实际 Mihomo 版本，再查看解析日志指出的字段。更新图形界面不一定同步更新内核，执行后应再次确认内核版本号。
如果旧配置能够载入、新配置从某一天起统一报错，优先比较服务端生成格式是否变化。若只有一个节点导致整份配置失败，可根据日志定位该节点使用的协议与字段，再让订阅服务重新生成兼容格式。
各客户端自动更新间隔怎么设置
不同客户端对“自动更新”的命名略有差异。以下路径按 Clash Verge Rev 2.3.x、Clash Meta for Android 2.11.x 与 FlClash 0.8.x 的常见界面记录；小版本调整后，按钮可能移动，但设置对象都应是远程配置本身，而不是节点健康检查。
| 客户端 | 设置路径 | 常用间隔 |
|---|---|---|
| Clash Verge Rev 2.3.x | 「订阅」→目标配置卡片→「编辑」→「自动更新间隔」 | 720 或 1440 分钟 |
| Clash Meta for Android 2.11.x | 「配置」→目标远程配置右侧菜单→「编辑」→「自动更新」 | 12 或 24 小时 |
| FlClash 0.8.x | 「配置」→目标远程配置→「编辑」→「自动更新间隔」 | 720 或 1440 分钟 |
| Mihomo proxy-provider | 主配置→proxy-providers→目标 provider→interval |
21600 或 43200 秒 |
日常使用推荐 12 至 24 小时
节点与规则变化不频繁时，1440 分钟一次足够覆盖日常更新，也能减少服务端请求。服务方每天多次调整节点时，可改为 720 分钟。只有明确需要较快同步时才建议使用 360 分钟；设置成 5 分钟或 10 分钟通常没有必要，还可能触发 HTTP 429。
移动端还受系统后台策略影响。Android 的省电限制可能暂停后台任务，iOS 也不会保证客户端在退出后按分钟准时执行。因此“设置为 12 小时”表示客户端获得运行机会时按该周期检查，不代表系统一定会在准确时刻唤醒应用。重要更新应在前台打开客户端后手动执行一次。
不要混淆订阅更新和健康检查
订阅更新负责下载节点、策略组和规则内容；健康检查负责向测试 URL 发起请求，判断已有节点是否可用。把健康检查设为 600 秒，并不会每 10 分钟下载一次订阅。反过来，订阅每天更新一次，也不妨碍节点每 10 分钟进行一次可用性检测。
对于含 100 个节点的 provider，过短的健康检查周期会产生大量并发请求。可以从 600 秒或 900 秒开始，根据设备功耗和节点数量调整。延迟测试 URL 应返回轻量响应，且需能代表实际出口连通性。
手动强制更新的正确步骤
强制更新的目标是得到一份新配置并确认它已经被加载，而不是只看到进度图标转动。下面的顺序可以同时避免并发请求、缓存误判和旧连接干扰。
- 打开客户端日志，记录当前配置名称、更新时间与内核状态。
- 停止正在进行的重复更新，只点击目标配置的更新按钮一次。
- 等待请求完成，确认日志中的最终 HTTP 状态和解析结果。
- 检查配置卡片的更新时间是否改变，节点数量或策略组是否符合预期。
- 明确选中新配置，并执行「重载配置」或重新启动内核。
- 重新选择策略组节点，关闭需要验证的应用连接后再打开。
- 访问连接测试页面或查看连接日志，确认新连接命中了预期规则和出口。
如果更新成功但节点列表不变，先比较服务端内容是否真的变化。HTTP 缓存可能返回 304 Not Modified，这表示客户端持有的版本仍被认为有效，并非网络失败。若服务端已经变更但客户端持续使用旧内容，可删除该远程配置后重新导入；操作前应保存本地覆写、策略组选择和自定义规则。
切换配置不会自动迁移所有现有 TCP 或 UDP 会话。浏览器长连接、下载任务和即时通信连接可能继续使用原出口。验证时应关闭对应应用连接，必要时重启应用，而不是只刷新同一条长连接。
仍然失败时保留哪些诊断信息
经过上述排查仍无法更新时，应整理一份最小诊断记录：客户端名称和版本、Mihomo 内核版本、操作系统版本、失败时间、HTTP 状态码、错误日志前后各 10 行、是否开启 TUN、系统代理地址、监听端口，以及直连和代理两种路径的测试结果。
订阅地址只保留域名，令牌和查询参数应遮盖。配置文件也要检查是否包含认证信息。若问题只在特定网络出现，可补充家庭宽带、移动数据或公司网络的对照结果；若切换网络后立即恢复，排查重点应放在 DNS、IPv6、访问策略和本地网关，而不是反复重装客户端。
完整的诊断顺序可以概括为：先看日志确定阶段，再测试 URL 可达性，然后检查返回内容与 YAML，最后处理内核兼容、自动更新间隔和配置重载。这个顺序能把“订阅失效”“下载失败”“解析失败”和“配置未切换”分成不同问题，减少无关改动。