先确认失败发生在下载、解析还是应用阶段
Clash 手机端的“更新失败”不是一种固定故障。一次订阅更新通常要经过请求地址、下载响应、解析配置、保存文件和应用配置几个环节。节点还能连接，不代表订阅地址仍然有效；订阅下载成功，也不代表新配置能够被当前内核加载。先定位阶段，才需要决定是更换链接、调整网络，还是处理配置兼容性。
- 保留现有可用配置。记录当前配置名称、上次更新时间和客户端名称。若客户端支持导出，先在本机保存副本；副本可能包含节点密码，应放在受保护的位置。
- 手动更新一次。进入订阅或配置列表，对目标条目执行“更新”，记录完整错误提示。不要同时反复刷新全部订阅。
- 查看同一时间的日志。把失败时间精确到分钟，区分 HTTP 状态码、连接超时、TLS 证书错误和 YAML 解析错误。
- 每次只改一个条件。例如仅切换 Wi-Fi 与移动网络，或仅切换更新请求的代理方式，再对比结果。
| 提示或现象 | 优先检查 | 下一步 |
|---|---|---|
401 / 403 | 令牌、账号状态、访问限制 | 在订阅服务后台确认地址与授权 |
404 / 410 | 接口地址是否迁移或停用 | 重新复制后台提供的订阅入口 |
429 | 短时间请求过多 | 停止连续刷新，遵循服务端等待时间 |
5xx | 服务端或上游异常 | 保留旧配置，稍后重试 |
timeout / lookup | 连接路径或域名解析 | 换网络并核对请求是否走代理 |
yaml / unmarshal | 响应内容与配置格式 | 确认下载的不是网页或其他客户端格式 |
状态码只是线索，不是最终结论。例如 403 也可能由网站防护策略触发，并不必然意味着订阅到期。应结合订阅后台、客户端日志和服务方公告判断。
订阅链接失效：核对令牌、有效期与返回内容
从服务后台重新复制，不从聊天记录拼接
订阅 URL 常带有账号专属令牌。重置订阅地址、修改安全设置或服务迁移，都可能让旧地址失效。复制时应保留完整查询参数，检查是否带入末尾空格、换行、中文标点，以及聊天软件显示出来的截断文本。链接中的 & 用于分隔参数，不应在地址输入框里被误写成 HTML 实体文本。
先在服务后台检查套餐有效期、剩余流量和订阅状态，再使用后台当前提供的地址更新原条目。如果客户端没有编辑地址的入口，可新建一个订阅条目测试，成功后再处理旧条目，避免先删除唯一可用的配置。
HTTP 200 也可能返回错误内容
服务器返回 200，仅说明请求获得了响应。实际内容可能是登录页、验证页、套餐到期提示，或者只有一行错误消息。若解析错误附近出现 <html>、<!DOCTYPE，应先检查地址与访问限制，而不是调整 YAML 缩进。
格式不兼容：区分完整配置与节点订阅
“支持订阅”不表示所有客户端都能读取同一种响应。常见内容包括完整 Clash YAML、节点提供者文件、URI 列表以及经过 Base64 编码的节点集合。完整配置通常包含 proxies、proxy-groups、rules 等字段；节点提供者文件则主要提供节点，不一定包含策略组与分流规则。
- 整份配置导入：应选服务后台明确标注适配 Clash 或当前内核的格式。不要将仅适用于其他客户端的订阅地址直接当作完整配置。
- 节点提供者加载：
proxy-providers下载的是提供者内容，其结构与完整配置不同。把两者放错入口，可能出现字段缺失或解析失败。 - Meta / mihomo 功能：某些协议、规则字段和 DNS 选项需要相应内核支持。Clash 原版、Clash Meta / mihomo 及不同图形客户端的支持范围并不完全相同。
排查时可在客户端“关于”或内核信息页面查看实际使用的内核，再对照配置来源的说明。应用名称里出现 Clash，不能单独证明它支持某个新字段。若日志明确指出未知协议或不支持的字段，应更换服务方提供的兼容格式，或使用支持该功能的客户端，而不是逐行删除配置碰碰运气。
错误行号只用于定位，不一定指向根因
YAML 依赖缩进，不能用 Tab 随意替代空格。错误可能在日志标出的行，也可能来自前一行未闭合的引号或括号。对于远程订阅，优先向提供方确认原始内容；手机端直接编辑下载文件，往往会在下次更新时被覆盖。本地定制应使用客户端支持的覆写或合并入口，相关概念可参阅技术参考。
更新请求未走代理：节点可用与订阅可达是两件事
手机客户端可能由应用自身下载整份订阅，也可能由内核下载远程提供者。两类请求的网络路径不一定相同。浏览器能打开服务后台，只能证明浏览器当前的访问路径可用，不能证明客户端的订阅请求也走了相同出口。
用两条网络路径做对照
- 保持旧配置，确认当前选中的节点确实能访问网络，而不是只看 VPN 图标是否亮起。
- 在订阅编辑页或更新设置中查找“通过代理更新”“更新代理”等选项；实际名称以客户端为准，不能把某款客户端的菜单路径套用到所有手机端。
- 若该选项存在，分别用直连与代理各手动更新一次，记录结果。仅代理成功时，再把该订阅的更新方式固定为代理。
- 若两种方式都失败，切换 Wi-Fi 与移动网络复测。不要同时改 DNS、节点和订阅格式，否则难以判断哪项改动有效。
切换到全局模式不一定会改变订阅下载的路径，因为下载动作可能绕过内核，由应用直接发起。相反，配置中的 proxy-providers 在支持相应字段的 mihomo 中可以指定下载所用的 proxy；这个设置只作用于对应提供者，不会自动改写客户端整份配置的更新方式。
手机上的 VPN 权限、TUN 接管和应用排除列表也可能影响请求路径。特别是在排除了客户端自身或启用了分应用代理时，不应仅凭其他应用联网正常就排除网络问题。若日志是 no such host，先检查域名解析；若是连接超时，再检查线路、代理出口与服务器可达性。
证书校验失败：先校准时间，再检查网络环境
x509: certificate has expired or is not yet valid、主机名不匹配和证书链不受信任，都属于 TLS 验证问题。它们与 YAML 解析不是同一阶段，也不应靠修改节点密码解决。
- 打开系统自动时间。安卓通常在系统设置的“日期和时间”中启用自动设置；iOS 可在“设置”→“通用”→“日期与时间”中检查“自动设置”。日期偏差可能让有效证书被判定为过期或尚未生效。
- 检查公共 Wi-Fi 登录。酒店或校园网络可能要求先完成网页认证。先完成该网络的正常登录，再重新发起订阅请求。
- 换网络复测。若只有某个 Wi-Fi 失败，检查该网络是否存在 HTTPS 检查或域名重定向。不要随意安装来源不明的根证书。
- 联系服务方检查域名证书。若多个网络均出现相同的过期或主机名错误，应由服务方修复证书部署，或提供已正确配置的订阅入口。
配置中的节点参数 skip-cert-verify 通常针对节点连接的证书验证，不等同于订阅下载的 TLS 设置。不要为了消除订阅错误提示而批量修改节点参数，也不要把 HTTP 明文地址当作长期替代方案，订阅响应本身就可能包含访问凭据。
自动更新间隔：先分清两个定时器
客户端的“订阅自动更新”通常更新整份远程配置；内核中 proxy-providers 的 interval 则控制某个节点提供者的刷新。两者可以同时存在，但不能互相替代。另一个容易混淆的字段是 health-check.interval：它控制健康检查频率，不负责重新下载节点列表。
| 更新对象 | 设置位置 | 建议起点 |
|---|---|---|
| 完整远程配置 | 客户端的订阅编辑或更新设置 | 24 小时，按服务方要求调整 |
| HTTP 节点提供者 | proxy-providers 下对应条目 | interval: 86400 |
| HTTP 规则提供者 | rule-providers 下对应条目 | 按规则源发布频率设置 |
| 节点健康检查 | health-check 相关设置 | 单独评估，不作为订阅更新间隔 |
整份配置：从每天一次开始
对于节点变动不频繁的订阅，24 小时可作为设置起点；确有较频繁变更需求时，可考虑 6～12 小时，同时遵循服务方的限流要求。这是配置建议，不是所有服务的统一标准。若服务端返回 429 并提供 Retry-After，应优先遵循该等待时间，避免每隔几秒点击刷新。
设置时先确认输入单位。24 小时等于 1440 分钟，也等于 86400 秒。客户端界面可能使用分钟或小时，内核提供者的 interval 使用秒，不能直接把同一个数字照抄到不同位置。数值 0 的含义也应以客户端说明为准，不要默认它代表“立即更新”。
提供者：只修改已有条目的更新字段
如果使用 mihomo 的 HTTP 节点提供者，并需要每天更新一次，可在已有提供者条目中设置下面这一行。它是字段示例，不是可单独导入的完整配置；应保留原有名称、地址、路径及其他必要设置。
# 位于已有 proxy-providers 条目的下一级，单位为秒
interval: 86400修改后先验证配置能加载，再观察日志中的提供者更新时间。不要把这一行直接放到配置顶层，期待它控制整个客户端的远程订阅。若使用的是本地文件型提供者，也不能把 HTTP 定时下载的行为直接套用过去。
手机锁屏后不更新：检查调度限制与成功时间
自动更新间隔通常表示客户端或内核尝试调度更新的周期，不保证手机在精确时刻执行。安卓省电策略、厂商后台限制、网络断开，以及 iOS 对后台任务和网络扩展的限制，都可能推迟更新。VPN 图标仍在，也不一定代表负责下载配置的应用界面进程正在运行。
- 安卓：在系统的应用电池设置中检查是否限制该客户端后台活动。不同厂商的“允许后台运行”“自启动”选项位置不同，应按设备实际菜单操作，并留意放宽限制后的耗电影响。
- iOS：以所用客户端提供的后台能力为准。普通应用的定时任务不能当作常驻服务理解，必要时打开客户端手动确认更新结果。
- 两类系统都要检查：客户端是否允许移动网络更新，当前网络是否计费受限，以及页面显示的是“最后尝试时间”还是“最后成功时间”。
完成设置后，先在前台手动更新一次，确认新配置已经保存并能加载。再经过一个设定周期检查成功时间，而不是只看自动更新开关是否开启。重启手机后，也应确认配置仍被选中、VPN 权限有效，且自动更新设置没有被系统恢复或清理。
提交反馈前的最小排查记录
持续失败时，把问题整理成可复现的记录，比反复删除重装更有效。清理应用数据可能同时移除订阅、覆写与策略组选择，应放在已经备份且其他排查无效之后考虑。
- 记录客户端名称、应用版本、实际内核信息和手机系统版本。
- 记录失败时间、使用 Wi-Fi 还是移动网络，以及请求采用直连还是代理。
- 保留经过脱敏的完整错误行，例如 HTTP 状态码、TLS 错误或配置解析行号。
- 说明手动更新是否成功、整份配置还是提供者失败，以及旧配置是否仍可使用。
- 向订阅服务方反馈地址授权与响应问题；向客户端维护方反馈可复现的下载、解析或调度异常。
最终应同时确认三件事：订阅下载成功、新配置加载成功、实际连接正常。只有更新时间变化，而配置无法应用，仍不能算排查完成。手机端初次配置与权限检查可继续查看安装与使用教程。