订阅链接导入报错解析失败？订阅失效的自查步骤

先区分下载失败、解析失败和配置校验失败

Clash 订阅导入不是单一操作。客户端先请求订阅地址，取得响应正文，再解析 YAML 或其他受支持的订阅格式，最后交给内核检查节点、策略组与规则。界面上同一句“导入失败”，可能对应完全不同的环节。先打开客户端的“日志”，记录出错时间和第一条明确错误，再进行修改。

Clash Verge Rev 等客户端的界面名称会随版本变化。通常从“订阅”页新增远程订阅、填写 URL 并导入；已有订阅则在对应卡片菜单中执行“更新”。排查时同时记录客户端版本与内核版本，不要只写“最新版”。旧版 Clash 内核、Clash Meta（现称 mihomo）与其他兼容实现支持的配置字段并不完全一致。

日志或现象	优先检查	下一步
`timeout`、`lookup`、TLS 错误	网络、DNS、证书	先取得有效响应，不急于修改 YAML
HTTP 401、403、404	授权、链接、服务端状态	核对账户后台和订阅入口
`yaml: line 12` 等行号提示	响应正文和 YAML 语法	检查报错行及前面数行
不支持的代理类型、策略组引用不存在	内核兼容性和配置结构	选择匹配格式并做内核测试
导入成功但节点为空	订阅内容、筛选条件、provider	检查节点来源是否实际加载

第一步：确认复制的是订阅地址，而不是网页地址

在服务商后台选择明确标注为 Clash、Clash Meta 或 mihomo 的订阅入口。账户登录页、套餐详情页和邀请链接都不是订阅地址。浏览器能打开一个页面，只能说明网页可访问，不能说明它能被内核作为配置读取。

重新复制完整 URL。检查开头是否为 https://，末尾是否被聊天软件截断，前后是否混入空格、换行或中文标点。优先使用后台的复制按钮。
保持查询参数原样。不要随意删除 token、key 等参数，也不要把整个 URL 再做一次百分号编码。参数名称以服务商实际提供的地址为准。
检查转义符。从 HTML 源码复制时，参数分隔符可能变成字面量 &。正常 URL 中多个查询参数通常用 & 分隔；应重新从原始入口复制，不要批量猜测替换令牌内容。
检查链接是否已重置。重置订阅令牌后，旧链接可能立即失效。更新客户端保存的 URL，而不只是反复点击旧条目的“更新”。

订阅地址通常具有账户凭据的性质。不要贴进公共在线 YAML 检查器、未知订阅转换站或公开工单。确需向服务商提交时，先描述错误类型与时间，再按其私密支持渠道提供必要信息。

第二步：检查 HTTP 状态码与实际返回内容

判断“订阅失效”，要同时看状态码和正文。HTTP 200 也可能返回登录页、风控页面或 JSON 错误说明；Content-Type: text/plain 也可能装着完全有效的 YAML。不能只凭文件扩展名、响应头或“下载成功”提示下结论。

在本机保存响应，先不自动跟随跳转

熟悉终端的用户可在 Bash 中执行以下命令。它会隐藏输入的订阅地址，将响应头与正文分别保存到当前目录。先进入仅自己可访问的工作目录；文件仍包含敏感信息，不要上传或同步到公共仓库。Windows 用户可使用具备 Bash 的环境，或在客户端日志中检查同类信息。

umask 077
read -r -s -p '输入订阅 URL：' SUB_URL
printf '\n'
curl --connect-timeout 10 --max-time 30 \
  --dump-header subscription-headers.txt \
  --output subscription-body.txt \
  --write-out 'HTTP %{http_code}\n' \
  "$SUB_URL"
unset SUB_URL

这里的 10 秒是连接超时，30 秒是整次请求上限，不是实测性能或客户端默认值。命令没有添加自动跳转参数：遇到 301、302、307、308 时，先在本机查看 Location 是否指向服务商认可的域名。跳转目标也可能包含令牌，不要直接分享响应头。命令行请求特征可能与客户端不同，因此它只用于对照，不代表客户端一定得到同样响应。

按状态码缩小范围

200：继续看正文。以 <!DOCTYPE html>、<html 开头，通常是网页，不是 Clash 配置。
204 或正文为零字节：没有可解析内容。核对链接和服务端生成状态，不要靠补一个 YAML 字段掩盖问题。
401、403：可能是令牌失效、权限不足、来源限制或风控；仅凭状态码不能认定账户到期。
404、410：检查旧入口是否已迁移或撤销，再从账户后台取得新地址。
429：停止连续重试；如果响应提供 Retry-After，按其要求等待。
500、502、503、504：优先考虑订阅生成服务或上游网关异常，记录时间后联系服务商。

正文若是以 vmess://、ss:// 等开头的节点列表，或是一整段 Base64 文本，说明选择的可能是通用订阅格式。是否能直接导入取决于客户端，不能将它当作完整 Clash YAML 使用。优先重新选择服务商提供的目标格式。

第三步：检查 YAML 缩进、字段类型与策略引用

响应确认是 YAML 后，再检查语法。YAML 使用空格表示层级，缩进不能混入 Tab。错误提示中的行号通常是解析器发现异常的位置，真正原因可能在上一行，例如引号未闭合、冒号后缺少空格，或复制时丢失了一段列表。

先看语法，再看配置含义

缩进：同一层级保持一致，常用每层 2 个空格。列表项前的 - 也必须处于正确层级。
特殊字符：名称或密码包含“冒号加空格”、# 等字符时应正确引用。用单引号包裹的字符串若含单引号，需要按 YAML 规则写成两个单引号。
字段类型：proxies 通常是节点列表，proxy-groups 是策略组列表，rules 是规则列表。能解析成 YAML，不代表字段类型符合内核要求。
引用名称：规则与策略组引用的节点、组名必须存在，且名称保持一致。不要只改节点名称而保留旧引用。

下面是用于隔离解析问题的最小直连配置。保存为独立测试文件，不要覆盖正式订阅。它不含代理节点，所有流量按直连处理；测试通过只说明这段基础配置能被接受，不代表订阅或代理线路恢复。

mixed-port: 7890
mode: rule
log-level: info
proxies: []
proxy-groups:
  - name: DIRECT-TEST
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,DIRECT-TEST

这里的 7890 是示例混合端口，不是所有客户端的固定默认值。端口冲突一般影响内核运行或监听，不是远程正文变成 HTML 的原因。只测试配置时，也不必先切换系统代理、启用 TUN 或修改 DNS。

使用实际内核做测试

如果本机已有 mihomo 可执行文件，可使用下面的命令检查保存的配置。命令应调用客户端实际使用的内核版本；另找一个较新内核通过测试，并不能证明旧内核也兼容。

mihomo -v
mihomo -t -f ./profile.yaml

-t 用于测试配置，-f 指定文件。完整配置若引用远程 provider，初始化或检查过程中仍可能涉及资源读取；应在可信配置和受控环境中操作。测试日志也可能包含节点名称、资源地址，不宜原样公开。

第四步：核对内核格式、provider 与客户端覆写

同为 YAML，也有“完整配置”和“节点提供器文件”的区别。用于 proxy-providers 的文件通常只提供 proxies 节点列表，不等于完整运行配置；它应由主配置中的 provider 引用。反过来，把包含策略组和规则的完整订阅填进只接受节点列表的入口，也可能失败。

核对目标内核。服务商若分别提供 Clash 与 Clash Meta/mihomo 入口，选择与本机实际内核一致的版本。出现不支持的代理类型或字段时，先核对支持情况，不要直接删掉安全或协议参数。
检查二次下载。主配置导入成功后，proxy-providers、rule-providers 可能还要下载资源。查看日志中失败的具体 URL 类型，区分主订阅失败和资源更新失败。
核对使用关系。使用 provider 的策略组需要通过 use 等受支持字段引用相应名称。筛选表达式若排除了全部节点，也会表现为组内没有可选节点。
隔离覆写逻辑。在新建测试条目中暂时不套用个人合并配置、脚本或扩展覆写。原始订阅正常而最终配置失败时，再逐项恢复覆写，定位被改坏的字段。

第五步：检查网络路径与账户状态

如果日志显示连接超时、DNS 解析失败或 TLS 证书异常，应回到请求阶段排查。浏览器可能使用扩展代理、缓存或已登录会话；客户端更新订阅则可能走另一条网络路径。两者结果不同，并不能直接证明链接真假。

对照直连与已有可用代理。若客户端提供订阅下载代理选项，分别测试并记录结果。避免让订阅更新依赖当前已经失效的节点；没有可用线路时，可用手机热点对照当前网络。
核对系统时间。日期或时区明显错误会影响证书验证。先同步时间，不要关闭 TLS 证书验证来绕过报错。
检查 DNS 与网络登录。酒店、校园或公共 Wi-Fi 的认证页可能拦截请求。先完成网络认证，再重试；不要因为看到 HTML 就立刻更改订阅格式。
查看服务商后台。确认套餐有效期、流量状态、订阅重置记录以及维护公告。流量耗尽后是返回错误还是仍保留节点，由服务商决定，不能一概而论。

若一个链接在多个网络上均返回相同的 403 或固定错误正文，而后台又显示授权异常，联系服务商通常比重装客户端更直接。若只有当前设备失败，优先比较本机时间、代理设置、客户端请求选项与内核版本。

恢复后复查：导入成功不等于节点可用

修复后先手动更新一次，确认日志不再出现下载或解析错误。随后检查节点数量、策略组成员和 provider 更新时间，再选择节点测试实际访问。延迟测试成功只说明对应测试请求成功，不能代替日常目标网站的连接验证。

保留一份已验证的配置备份，并记录恢复时使用的客户端与内核版本。
确认当前启用的是刚修复的订阅，而不是仍在运行的旧配置。
恢复原有自动更新计划，避免短时间反复请求触发限流。
清理本机临时响应文件；如果完整订阅地址曾公开泄露，在服务商后台重置令牌，再同步更新所有设备。

需要提交问题时，提供“发生时间、客户端版本、内核版本、HTTP 状态码、脱敏后的第一条错误、是否跨网络复现”即可。完整订阅 URL、原始节点密码和整份响应正文不应出现在公开讨论中。按“地址 → 响应 → 语法 → 内核 → 网络与账户”的顺序检查，通常能明确问题位于哪一层，再决定更新链接、修复配置还是等待服务端恢复。