先对齐现象：订阅失败常见长什么样

在 OpenWrt 上通过 OpenClash 使用 路由器 Clash（底层多为 Mihomo / Clash Meta 内核）时，「订阅更新失败」在界面上可能表现为：长时间转圈后超时、提示无法下载、HTTP 4xx/5xx、TLS/certificate 相关报错，或下载成功但提示 YAML 解析失败、节点数量为 0。不同文案对应的根因并不相同；若跳过现象直接改节点，往往会把环境问题误判成规则问题。

建议你先记录三类信息：报错原文、订阅地址的协议（http 还是 https）、以及失败是「仅某一组订阅」还是「全部订阅」。这三点能把排查范围从「整台路由」缩小到「某一链路」。

推荐排查顺序：先资源与时间，再 URL 与 DNS，最后看绕行

路由器上的失败有一个特点：本机发起的下载与局域网客户端上网走的路径不一定一致。OpenClash 更新订阅时，请求通常发自路由本机；若你把「本机流量」也送进了需要订阅才能通的代理里，就可能出现鸡生蛋式的环路。反过来，若仅是内存或时间这种底层条件不满足，改再多规则也无济于事。

因此本文采用的顺序是：（1）内存与存储 → （2）系统时间与 TLS → （3）订阅 URL 可达性与 DNS → （4）本机是否应绕行代理 → （5）内核与订阅格式。你可以把每一步当作「过关」：上一关未排除前，不必急着进入下一关。

第一步：内存、临时目录与闪存写入

许多 x86/ARM 软路由看似性能不错，但 OpenWrt 默认根文件系统往往较小，且运行在内存里的 /tmp 空间有限。订阅下载后需要解压、合并、再写入配置；若 可用内存过低 或 /tmp 满，进程可能被内核杀掉或写入半截文件，最终在 UI 上只显示一个笼统的「更新失败」。

操作建议：在 SSH 中查看 free -m 与 df -h /tmp，关注可用内存是否长期个位数（MB 级）、以及 /tmp 是否逼近 100%。若你刚启用大量第三方插件或日志级别过高，也可能让内存碎片加剧。临时缓解包括：关闭不必要插件、降低日志、把订阅拆成更小的分组、或在硬件允许时加装 swap（需自行评估磨损与性能）。

另一类问题是闪存写入失败：极端情况下配置写到 overlay 时空间耗尽，会导致「看似下载成功但落盘失败」。用 df -h /overlay 看剩余空间，清理软件包缓存与旧备份同样是基础运维动作。

第二步：系统时间、证书与 HTTPS 订阅

绝大多数订阅链接是 HTTPS。TLS 校验依赖系统时间；若路由器从未同步 NTP，或时区设置错误导致时间偏到几年前/几年后，你会看到握手失败、证书未生效等报错，进而被 OpenClash 汇总成「订阅更新失败」。这在断电久未启动、离线配置、或手动关掉时间同步时尤为常见。

操作建议：确认 OpenWrt「系统 → 时间同步」可用，时区与城市设置正确；用 date 与可信站点对比误差。若必须使用纯离线环境，至少要保证时间落在证书有效期内。对 HTTP 明文订阅虽可绕过 TLS，但会带来中间人篡改风险，不建议作为长期方案。

若时间正常仍报证书相关错误，再检查是否安装了缺失的 CA 包、是否做过「精简固件」把证书链删过头，以及订阅站是否使用了不被信任的自签证书——这类问题与「代理规则」无关，需要从系统信任链入手。

第三步：订阅 URL、运营商网络与 DNS 解析

在 PC 上能打开的订阅链接，在路由器上未必能打开：原因包括 运营商对特定域名的干扰、IPv6/IPv4 路径不一致、或 DNS 返回了污染地址。路由器默认走本地 DNS（如运营商自动分配）时，解析结果可能与你在电脑上使用 DoH 时完全不同。

在 SSH 里对订阅域名做对照：nslookup 你的订阅域名 或使用 dig（若已安装），观察解析是否异常。再使用 curl -vI '订阅URL' 看 TCP/TLS 是否建立、重定向是否指向了打不开的地址。注意不要把带敏感参数的完整订阅 URL 粘贴到公共论坛；自查时可在本地终端操作并打码 token。

若你使用国内与海外分流，需特别留意：订阅域名究竟应该直连还是走代理。对「墙外才能访问的订阅站」，路由器本机直连失败是正常现象；此时应把对应域名规则放到正确的策略组，并确保本机流量也能走通该策略（见下一节）。关于 DNS 与分流如何对齐，可延伸阅读《Clash DNS 防泄漏配置指南》中的思路，把「解析结果」与「规则意图」画在同一张地图上。

第四步：本机流量、绕行（Bypass）与更新时的策略

OpenClash 常见选项会区分「局域网客户端」与「路由器本机」流量。订阅更新由本机发起，若本机默认走代理，而代理又依赖这份订阅才能工作，就会形成更新依赖代理、代理依赖订阅的环路。界面可能只显示超时，不会自动告诉你「环路」。

排查时优先确认：是否为本机或「核心组件」配置了直连/绕行，订阅相关域名是否在更新阶段被错误地送进了尚未就绪的策略组。不同版本菜单位置略有差异，但思路一致：让「拉取订阅」这条链路在逻辑上先于「使用节点」。

若你使用 TUN/Redir 等全量接管模式，也要检查是否有把「本机管理端口」「DNS」「订阅域名」误纳入了过宽的全局规则。此类问题与桌面端 Clash 类似，但路由器上更容易被忽略，因为用户习惯先关注局域网设备能否上网。关于根据日志判断端口、节点与超时，可参考《Clash 日志排查：端口、节点与超时》的方法论，在 OpenClash 日志界面中找对应时间段的记录。

第五步：下载成功却解析失败时，看格式与内核版本

有时订阅「下载成功」但节点数为 0，或提示 YAML 错误：这可能是服务商返回了 HTML 登录页/风控页、Base64 内容损坏、或包含了当前 Mihomo 版本不支持的字段。先用浏览器或 curl 看响应体前几行，确认是不是 Clash 配置而不是网页。

内核大版本迭代会调整字段支持情况；若你从旧版 OpenClash 升级后批量失败，先阅读《Clash Meta（Mihomo）升级完整指南》，核对废弃字段与配置迁移，再判断是否需要调整订阅转换参数或更换上游格式。

可打印的简短清单（便于对照）

将下列项逐项打勾，比反复重装插件更有效：内存与 /tmp 是否充足；系统时间是否准确；订阅 URL 在路由本机 curl 是否可访问；DNS 解析是否合理；本机更新订阅时是否绕行代理、避免环路；下载内容是否为有效配置而非网页；内核版本与字段是否匹配。

合规与边界

本文仅讨论在合法授权的网络环境中，对开源代理组件进行故障排查的一般技术思路，不构成对任何地区法律法规的规避建议。请在你所在地法律允许的范围内使用相关技术，并尊重服务提供商条款与他人权益。

小结

OpenWrt OpenClash 场景下的 订阅更新失败，多数是「路由器本机环境 + 拉取链路」问题，而不是单纯「换个节点就好」。按内存与时间、URL 与 DNS、再绕行策略的顺序排查，可以快速把问题定位到可修复的层级。

桌面与移动端的 Clash 客户端在分流模板、DNS 与升级节奏上往往更省心；若你希望在电脑或手机上获得与 Mihomo 同步迭代的体验，也可先通过本站下载页获取对应系统客户端，在本地验证订阅与规则无误后，再回到路由器侧比对差异。→ 立即免费下载 Clash，开启流畅上网新体验