1 先分清：403、超时与「0 节点」不是同一种故障
Mihomo 订阅拉取失败时，日志或界面常见三类信号：HTTP 403（或 401、451 等明确拒绝码）、TLS/连接超时、以及「请求看似成功但0 节点」。第一类几乎总是源站或边缘策略在拒绝当前这次 HTTP 请求；第二类要查网络路径、DNS、系统时间、中间人设备；第三类则往往是正文并不是合法 Clash 配置——例如被重定向到门户登录页、返回 gzip 二进制却被当成纯文本解析、或 Base64/SSR 列表与当前解析器预期不符。
若你正在处理的是「非原生 YAML」的机场订阅，需要先做格式转换或确认客户端是否支持该封装，可参考《订阅转换完全指南：把 SS/V2Ray/Trojan 机场链接转成 Clash YAML》。本文假设你已有可用直链，重点放在「同一链接在浏览器能打开、在 Mihomo 里却 403 或空列表」的拉取层差异。若你关心的是订阅更新后如何保留本地覆写，请另读《Clash 订阅覆写入门：用 mixin 改节点备注并追加规则》——那边解决的是合并策略，而不是 HTTP 握手本身。
2 User-Agent 与自定义请求头：最常见的 403 诱因
大量机场订阅与面板在边缘层做了反爬或防盗链：只允许特定 User-Agent（例如模拟 Clash、Quantumult、浏览器或面板文档里写明的字符串），或对空 UA、默认 UA 直接返回 HTTP 403。Mihomo 作为 Clash.Meta 系实现，默认 UA 可能与服务商文档要求不一致；某些 CDN 还会校验 Referer 是否来自自家域名。
你可以怎么做
- 先查服务商文档或工单回复里是否写明「必须带某某 UA / Referer」。
- 在配置里为对应
proxy-providers或订阅拉取项添加header映射（见下文 YAML 小节），逐项试文档推荐 UA、常见浏览器 UA、以及「留空由内核默认」的对照。 - 若仅更换 UA 就从 403 变为 200，即可认定问题在请求头策略，而非节点本身失效。
3 短链、302/301 与「最终 URL」不一致
很多订阅以短链分发：第一次返回 302 Found，Location 指向真正的存储桶或另一域名。若某一跳要求浏览器 Cookie、或只在跟随首次 GET 时下发令牌，而 Mihomo/HTTP 客户端未保存 Cookie，就可能落在错误落地页上——表面「更新成功」，解析却是 HTML，于是出现0 节点。
另一类情况是重定向次数过多或跳转到 http 被策略拦截：中间链路在运营商或本地防火墙被改写，最终拿到的是运营门户页而不是订阅正文。此时应在与 Mihomo 相同网络下用 curl -IL（见后文）打印完整链，确认最后一跳的 URL、状态码与 Content-Type。
4 TLS、SNI、系统时间与内容编码
当错误不是 403 而是握手失败时，常见原因包括：系统时间漂移导致证书校验失败、公司网络里的HTTPS 检查替换了证书、或某些地区对特定 SNI 的干扰。Mihomo 侧可配合 跳过证书校验类选项（仅建议在可信内网排障时短暂使用），长期仍应修复时间或信任链。
若响应头声明 Content-Encoding: gzip，而某层代理错误地解压又重复声明编码，可能造成乱码；反过来，若正文是 gzip 二进制却被当作 UTF-8 文本去解析，也会表现为「没有 proxies」。这类问题用十六进制或 curl --compressed 对比最直观。
5 CDN、WAF、Geo 与「直连环境」对照
同一订阅在家宽报 403，换手机蜂窝正常，或反之——多半与出口 IP 信誉、GeoIP、ASN 黑名单有关。部分 WAF 还会对数据中心 IP（常见于 VPS 上跑的 Mihomo）与普通住宅 IP 区别对待。若你必须在 VPS 上拉订阅，可尝试服务商提供的「服务器专用订阅域名」或让面板将你的 VPS IP 加入白名单。
若本地已开系统代理或 TUN，注意拉取订阅这一跳是否也走了代理：有些面板禁止「经由另一代理访问订阅」，会返回 403；也有场景是代理链导致出口 IP 频繁变化触发风控。可在客户端里为订阅域名配置 DIRECT 规则做 A/B 测试。关于 Linux/路由器上长期跑 Mihomo 的基础布局，可对照《Linux 安装 Mihomo 并开机自启》中的网络与日志思路。
6 Mihomo 里为订阅补充 header 的写法示例
下列片段演示在 proxy-providers 上附加 User-Agent（字段名以你实际版本文档为准；核心是 header 键与 HTTP 头一一对应）：
proxy-providers:
my-airport:
type: http
url: "https://example.com/subscribe?token=REDACTED"
path: ./providers/my-airport.yaml
interval: 3600
header:
User-Agent: "ClashForWindows/0.20.39"
# Referer: "https://example.com/"图形客户端通常在「订阅高级设置」里提供等价选项。改完后务必手动更新一次并查看日志里该 provider 的 HTTP 状态与下载体积：体积过小（几百字节）却声称成功时，优先怀疑是 HTML 错误页。
7 用 curl 做「与 Mihomo 同条件」对照
在出现 403 或 0 节点时，用同一台机器、同一网络执行下面两类命令，能快速判断问题在服务端还是在解析器：
# Print redirect chain and response headers
curl -IL "https://your-subscription-url"
# Fetch body with gzip handled; swap User-Agent to match provider docs
curl -sS -L --compressed \
-A "ClashForWindows/0.20.39" \
-o /tmp/sub.txt \
"https://your-subscription-url"
head -c 400 /tmp/sub.txt
若 curl 同样 403，则 Mihomo 无需背锅，应联系服务商或换网络/IP；若 curl 200 且正文以 proxies: 或合法节点列表开头，而 Mihomo 仍空，再查客户端是否指向了另一份缓存文件、或存在 mixin/patch 把 providers 清空。外部控制器与面板仅负责展示，根因仍在拉取与合并逻辑，可参考《Mihomo 外部控制器与 Yacd 面板》做远程核对。
8 总结与延伸
处理 Mihomo 订阅拉取相关的 HTTP 403 与 0 节点，可记一条简短顺序：用 curl 复现 → 看重定向链与最终 Content-Type → 试User-Agent / Referer → 排除 TLS 与时间 → 对照出口 IP 与是否二次代理。与《订阅转换》《mixin 覆写》搭配使用时，把「格式与合并」交给那两篇，把「HTTP 层拒访」交给本篇，能少做很多无效重写规则。
相比只在界面里反复点更新，先把拉取层证据固定下来，排障会快一个数量级。若你希望在桌面端用成熟 GUI 管理多订阅与 TUN，可优先从本站下载页获取各平台安装包；图形界面里改 UA 往往比手写 YAML 更省事，但底层仍是同一套 HTTP 语义。
整体体验上，稳定、可验证的订阅链路比堆砌规则更重要：请求头对齐、重定向透明、TLS 正常时，Mihomo 才能发挥 Meta 内核在分流与协议上的优势。
