先确认失败发生在哪一层
Clash 客户端里的“更新订阅”并不是单一步骤。点击更新后，客户端先读取配置中保存的订阅 URL，再通过网络请求取得远端内容，随后检查内容能否作为 Clash 配置解析，最后才会用新配置替换本地副本。任意一层失败，界面都可能只显示“更新失败”，但处理方法并不相同。
排查前先不要删除当前配置。大多数客户端会保留上一次成功下载的本地副本，即使远端暂时不可用，已加载的节点和规则通常仍能继续使用。直接删除配置会同时失去这份可用副本，反而增加恢复步骤。
用报错文字判断方向
| 界面提示或日志关键词 | 通常代表什么 | 优先检查 |
|---|---|---|
| timeout、deadline exceeded、i/o timeout | 请求在限定时间内没有完成 | 网络路径、DNS、代理更新开关 |
| 404、Not Found | 服务器找不到该订阅地址 | 链接是否过期、复制是否完整 |
| 401、403、Forbidden | 身份参数失效或请求被服务端拒绝 | 重新获取订阅、设备或频率限制 |
| connection refused | 目标端口拒绝连接，或更新请求错误地发给本地代理 | 7890、7891 等端口及代理设置 |
| unexpected EOF、connection reset | 传输过程中连接被关闭 | 网络稳定性、重复请求、服务端状态 |
| YAML、parse、unmarshal | 内容已下载，但格式无法解析 | 返回内容是否真的是 Clash YAML |
确认是“下载失败”还是“解析失败”
下载失败时，日志通常包含域名、连接、超时或 HTTP 状态码。解析失败则常见 YAML 行号、字段名、类型不匹配等信息。例如请求成功返回了一个登录页面，HTTP 状态可能仍是 200，但内容第一行是 HTML，客户端就会在解析阶段报错。
如果客户端支持查看配置文件，可打开刚下载的内容检查开头。标准 Clash 或 mihomo 配置通常包含 proxies、proxy-groups、rules 等字段；只有一段网页代码、错误提示或账号登录页，说明订阅地址返回的并不是可加载配置。
mixed-port: 7890
mode: rule
proxies:
- name: Example
type: ss
proxy-groups:
- name: PROXY
type: select
rules:
- MATCH,PROXY上面只是用于识别结构的简化示例，不应拿它替换真实订阅。不同服务提供的配置还会包含 DNS、规则集、健康检查和大量节点字段。
Clash 订阅更新超时的处理顺序
超时表示客户端没有在规定时间内得到完整响应。原因可能是订阅域名无法解析、直连路径不可达、代理节点失效，也可能是客户端启用了“使用代理更新”，但当前代理本身还没有建立可用连接。按固定顺序检查，通常比反复切换节点更快。
第一步：分别测试直连更新与代理更新
不同客户端的名称略有差异，常见入口是「设置」→「参数设置」→「订阅」或配置页面右上角的更新菜单。可查找“使用代理更新”“通过代理更新订阅”“Proxy Subscription Update”一类开关。
- 先关闭“使用代理更新”，保存后手动更新一次。这会让订阅请求优先走系统当前的直连网络。
- 如果仍然超时，再开启该开关，选择一个已确认可用的节点后重新更新。
- 两种方式不要连续快速切换，每次测试至少等待当前请求结束，并记录哪一种能成功。
直连失败而代理更新成功，通常说明订阅域名在当前网络下访问不稳定。直连成功而代理更新失败，则应检查节点、代理组选择和本地端口。两种方式都失败时，继续检查 URL、DNS 和服务端状态。
第二步：检查本地代理端口
不少 Clash 客户端默认使用混合端口 7890，HTTP 端口常见为 7890，SOCKS5 端口常见为 7891，但这些值可以被配置修改。若操作系统、浏览器或其他下载工具仍指向一个已经关闭的端口，订阅请求可能出现 connection refused。
- 在客户端「设置」→「网络设置」或「端口」中查看当前 Mixed Port、HTTP Port 与 SOCKS Port。
- 确认系统代理显示的主机通常为
127.0.0.1，端口与客户端实际监听值一致。 - 不要同时运行两个占用相同端口的 Clash 客户端。端口冲突时，后启动的客户端可能无法监听。
- 若刚修改端口，先关闭再开启系统代理，使操作系统重新写入正确地址。
第三步：排除 DNS 与网络切换问题
从公司网络切到手机热点、从 Wi-Fi 切到有线网络后，旧连接和 DNS 缓存可能暂时保留。先完全退出客户端，断开并重新连接网络，再启动客户端测试。仅关闭窗口不一定等于退出，需确认系统托盘或菜单栏中的进程已经结束。
如果日志显示 no such host、server misbehaving 或域名解析超时，应先确认普通网页能否打开。启用了 TUN 模式时，可暂时关闭 TUN，只保留普通系统代理后测试订阅更新；若关闭 TUN 后恢复，应检查 TUN 使用的 DNS 劫持、Fake-IP 范围与 nameserver 配置，而不是直接重装客户端。
出现 404、401 或 403 时怎么处理
HTTP 状态码说明请求已经到达服务器，因此重点不再是本地端口，而是订阅 URL 与服务端授权。404 多数是地址不存在，401 表示缺少有效身份信息，403 则表示服务器理解请求但拒绝提供内容。
404：订阅链接过期或复制不完整
订阅链接通常包含较长的路径与查询参数，例如令牌、客户端类型或配置格式。聊天软件换行、浏览器地址栏截断、复制时漏掉末尾字符，都会把有效地址变成 404。检查时不要只对比域名，应从 https:// 开始逐字符核对整条 URL。
- 回到订阅提供方的管理页面，重新复制用于 Clash 或 mihomo 的订阅地址。
- 在客户端配置列表中打开原配置的编辑菜单，替换 URL 后保存。
- 如果客户端不支持编辑 URL，新建一个远程配置并导入新链接。
- 新配置更新成功并能正常切换节点后，再删除失效的旧条目。
若重新复制后仍是 404，可在浏览器中直接打开链接观察结果。下载 YAML 文件或显示配置文本，说明地址可用；直接进入登录页、套餐页面或站点首页，则可能复制了管理页面地址，而不是订阅接口地址。
401 与 403：授权参数或访问限制
401 常见于令牌失效、账户状态变化或订阅地址被重置。403 除了授权问题，也可能来自请求频率、来源网络或设备数量限制。此类问题通常无法通过修改 Clash 的代理端口解决。
- 在服务页面重新生成订阅链接，避免继续使用历史收藏中的旧地址。
- 停止短时间内连续刷新。建议至少间隔 5 分钟后再进行一次测试。
- 检查账户有效期、流量状态以及服务方是否发布了接口维护通知。
- 若浏览器可以下载而客户端返回 403，尝试先关闭代理更新，排除出口地址被限制的情况。
- 若直连返回 403、代理更新正常，可保留代理更新，但应选择稳定的代理组而不是延迟波动较大的自动节点。
返回 200 仍失败：检查配置格式与内容
HTTP 200 只代表服务器成功返回了一段内容，不代表这段内容一定是 Clash 配置。网页错误页、Base64 节点列表、其他客户端专用格式都可能以 200 返回，随后在解析阶段失败。
识别常见解析报错
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 第一行附近出现 YAML 语法错误 | 返回 HTML、JSON 错误信息或内容被截断 | 查看原始响应，重新获取正确订阅地址 |
| 提示缺少 proxies 或 proxy-groups | 订阅不是完整 Clash 配置 | 选择 Clash、Clash Meta 或 mihomo 格式 |
| 提示 unknown field | 配置使用了当前内核不支持的新字段 | 更新客户端或切换兼容格式 |
| 提示 mapping values、bad indentation | YAML 缩进损坏或手动编辑有误 | 恢复远端原始配置，避免使用制表符缩进 |
| 下载内容只有一行编码文本 | 可能是通用 Base64 节点订阅 | 从服务页面选择 Clash 专用链接 |
mihomo 对规则集、代理提供者和 DNS 字段的支持范围比早期 Clash 内核更广。如果订阅明确标注为 mihomo 或 Clash Meta，而客户端仍使用较旧内核，可能出现字段无法识别。应优先在「设置」→「内核」或「关于」中确认内核类型与版本，再选择对应订阅格式。
不要为了消除报错而随意删除不认识的字段。某些字段负责规则提供者、DNS 分流或节点健康检查，删掉后即使配置能加载，也可能改变流量路径。更稳妥的办法是升级支持该格式的客户端，或让订阅服务生成兼容配置。
自动更新间隔怎么设置更合理
自动更新并不是越频繁越好。节点与规则通常不会按分钟变化，过短间隔会制造重复请求，也更容易遇到服务端频率限制。对个人设备而言，6 至 24 小时是更常见的范围。
| 使用场景 | 建议间隔 | 说明 |
|---|---|---|
| 日常个人电脑 | 12 小时 | 兼顾节点变更与请求频率 |
| 偶尔启动的笔记本 | 24 小时 | 启动后手动更新一次通常已足够 |
| 节点变化较频繁 | 6 小时 | 不建议继续缩短到几分钟 |
| 固定规则与自建节点 | 24 至 72 小时 | 配置变化少，可降低更新频率 |
| 正在排查故障 | 暂时关闭自动更新 | 避免自动任务覆盖日志和测试结果 |
在客户端中设置更新间隔
常见操作路径是进入「配置」或「订阅」页面，打开对应远程配置的编辑菜单，将自动更新间隔设为小时数。部分客户端使用秒为单位：6 小时是 21600 秒，12 小时是 43200 秒，24 小时是 86400 秒。若输入框明确标注分钟，则分别填写 360、720 或 1440，不要混用单位。
设置完成后，应观察下一次计划更新时间是否符合预期。有些客户端只在程序运行时执行定时更新，电脑关机期间不会补跑全部任务；重新启动后进行一次更新即可，不需要把间隔调到很短。
“使用代理更新”该一直开启吗
是否开启取决于订阅域名的实际可达性。直连长期稳定时，关闭代理更新更简单，也能避免当前节点失效导致订阅无法刷新。只有订阅地址必须经过代理或直连经常超时时，才适合保持开启。
- 直连更新稳定：关闭“使用代理更新”，自动间隔设为 12 或 24 小时。
- 直连超时、代理稳定：开启代理更新，并让更新流量经过稳定代理组。
- 经常更换网络：优先使用直连；失败时再手动切换代理更新。
- 当前所有节点不可用：关闭代理更新，避免请求被送入失效代理。
修复后如何确认配置真的生效
界面显示“更新成功”只说明新文件已经保存，还要确认客户端实际加载了它。有些客户端下载完成后会自动切换，有些则继续使用旧配置，需要手动选中新条目。
- 在配置列表查看“最后更新”时间，确认它与刚才的操作时间一致。
- 选中更新后的配置，等待内核完成重载。
- 进入代理页面，检查节点数量、代理组名称或规则是否出现预期变化。
- 对常用节点执行一次延迟测试。延迟数值只能说明测试地址可达，不等于所有网站都可访问。
- 保持“规则模式”，访问一个应直连和一个应代理的目标，确认分流结果。
- 查看运行日志，确认没有持续出现解析错误、DNS 循环或连接拒绝。
仍然失败时的最终检查清单
- 订阅 URL 是否从服务页面重新复制，且首尾没有空格、换行或缺失字符。
- 浏览器打开地址时，返回的是配置文本或下载文件，而不是登录页。
- 直连更新和代理更新是否分别测试过，而不是只反复尝试同一种路径。
- 系统代理端口是否与客户端实际监听端口一致，7890 或 7891 是否被其他程序占用。
- TUN 关闭后能否更新；若能，应继续检查 DNS 劫持和 TUN 堆栈设置。
- 订阅格式是否与 Clash、Clash Meta 或 mihomo 内核匹配。
- 自动更新间隔是否过短，是否因连续请求触发 403 或临时限制。
- 更新成功后是否手动选中了新配置，并确认内核完成重载。
订阅故障最有效的排查思路，是先按状态码区分网络、授权与格式问题，再比较直连和代理两条更新路径。超时优先查网络与代理开关，404 重新获取完整链接，401 或 403 检查授权和请求频率，解析错误则确认返回内容与内核格式。把自动更新设为 6 至 24 小时，并保留最近一次可用配置，通常能减少重复故障带来的影响。