Clash 订阅拉取失败？Windows 下对照日志排查 TLS 与 DNS（附修复步骤）

1. 典型现象：为什么「浏览器能开」不等于「内核能拉」

浏览器访问订阅 URL 时，往往沿用你在 Windows 里设置的系统代理，或浏览器自己的代理插件，出口路径与 Clash 内核进程独立。而 Clash 订阅更新失败时，请求通常由内核或 GUI 包装的内核发起，遵循的是 config.yaml里的 DNS 模块、路由规则与出站策略。于是会出现「Edge 秒开、客户端一直转圈」——这不是玄学，而是两条不同的网络栈路径。

另一个常见误区是把「能打开网页」等同于「TLS 一定健康」。某些杀软或企业网关会对 HTTPS 做中间人解密，浏览器已信任其根证书，但 Clash 作为独立进程仍按系统信任库校验，表现为证书校验失败或握手异常。反过来，若订阅站使用国内 CDN 而你的节点地区不合适，浏览器若走了直连、内核却走了高延迟代理，也会出现一侧成功一侧超时。

因此排错的第一步，是固定复现动作：在客户端里点一次「更新订阅」，同时打开内核日志（或 GUI 的日志面板），记下完整报错行。下文所有判断都围绕这几类关键词展开：resolve、dial、TLS、certificate、timeout、i/o timeout等。

2. 日志怎么开：订阅拉取在 mihomo 里对应什么请求

在 mihomo系内核中，订阅更新本质是对订阅 URL 发起一次（或多次）HTTPS GET。日志里通常会打印目标主机名、解析到的 IP、选用的策略组与出站接口。请先在 GUI 中将日志级别调到 info或 debug（不同客户端菜单位置不同，但都会映射到内核的 log-level），再触发更新，避免对着空白面板猜。

若日志里完全没有订阅域名的记录，优先怀疑：客户端没有真正把请求交给内核、订阅地址被剪贴板截断、或更新按钮触发了缓存逻辑。可尝试删除订阅后重新粘贴 URL，并确认没有多余空格与不可见字符。若日志里出现了域名但立刻失败，继续按下一节的类型归类。

需要区分「策略组测速」与「订阅下载」：前者访问的是各节点自带的测速 URL，后者访问的是你配置的 subscription地址。把两类日志混读容易误判为「节点全红所以订阅也挂」。若你正在调 url-test与 fallback，可对照站内 策略组 url-test 与 fallback一文，避免把测速失败当成订阅 TLS 问题。

3. DNS 解析类：从日志到 nameserver 与 Fake-IP

当日志出现 couldn't find address、no such host、lookup failed或长时间停在解析阶段，应归类为DNS 解析问题。此时浏览器仍可能正常，因为浏览器可能使用 DoH、路由器 DNS 或系统缓存，而 Clash 的 dns段落指定了另一组 nameserver，在 TUN 或 redir-host模式下还会与 Fake-IP交互，路径更复杂。

实务上可先做最小化验证：在 PowerShell 中对该订阅域名执行 nslookup 你的订阅域名，观察是否返回预期记录。若系统解析正常而内核仍失败，检查 dns.nameserver是否指向了被墙或公司内网拦截的地址；必要时为订阅域名配置 nameserver-policy，让解析走可信 DoH/DoT。若你启用了 Fake-IP，请确认 fake-ip-filter是否包含订阅主机名，避免内核拿到「假地址」去建连。更系统的 DNS 与分流关系可参考 DeepSeek 分流与 DNS 专文中的思路，把「解析」与「出站」拆开思考。

Windows 上还要注意 多网卡与虚拟网卡：装了 TUN、虚拟机或公司 VPN 后，默认路由与 DNS 劫持顺序可能变化，导致 Clash 的 DNS 出口与浏览器不一致。临时关闭 VPN 对比一次日志，常常能快速缩小范围。

4. TLS 与证书：握手失败、x509、时间漂移与杀软扫描

日志若含 TLS handshake、x509、certificate signed by unknown authority或 hostname mismatch，说明 TCP 已通但TLS 层校验失败。先核对 Windows 系统时间与时区：时间漂移过大会让证书被视为未生效或已过期，表现为莫名其妙的握手失败。

其次排查HTTPS 扫描类安全软件。若企业环境或杀软对出站 HTTPS 做解密，需要在对应软件中为 Clash 进程放行，或导入其根证书到系统信任库——这比在配置里盲目打开 skip-cert-verify更安全。后者虽能绕过校验，但会把中间人风险静默放大，仅建议在可信内网测试环境短期使用。

若订阅商使用自签名或链不完整的证书，浏览器可能因 HSTS 或内置例外而「看起来能用」，内核仍严格失败。此时应联系订阅提供方修复证书链，而不是长期关闭校验。若错误信息明确写出 SNI 或 ALPN 相关字段，还要确认是否被本地 hosts 或分流规则改写了目标。

5. 超时与代理回环：规则把订阅域名送进节点

当日志出现 i/o timeout、context deadline exceeded或长时间卡在 dial tcp，要先判断是真连不上还是走了错误出站。最典型的坑是：全局规则或 GEO 规则把订阅域名也送进了需要代理才能访问的节点，而节点本身尚未就绪，形成「拉订阅依赖代理、代理依赖订阅」的死锁。

修复思路是让订阅主机名显式直连（DIRECT），或放在独立的 DIRECT策略组之前匹配。示例（域名请替换为实际订阅主机）：

# Put subscription host BEFORE broad proxy rules
rules:
  - DOMAIN,sub.example.com,DIRECT
  - MATCH,PROXY

若订阅托管在 GitHub Raw、Cloudflare Workers 等对地区敏感的平台上，还要对照你当前节点的地理位置：直连能访问不代表「从日本节点访问同一 URL」也能通。日志里若显示选中了某个延迟很高的出站，可临时手动切到延迟低的节点再试更新，验证是否为出口质量问题。

另一种超时来自本机防火墙或第三方套件拦截了 Clash 进程的外连。Windows 安全中心中可检查「专用网络」与「公用网络」配置文件是否对 Clash 可执行文件放行。与「局域网共享 mixed-port 入站」不同，订阅拉取主要是出站，若你刚为 mixed-port加过入站规则仍失败，不要混淆两类方向；局域网共享细节见 allow-lan 与防火墙专文。

6. mixed-port、系统代理与「谁在发起订阅请求」

mixed-port表示在同一 TCP 端口上同时接受 HTTP 与 SOCKS 风格的入站，是多数桌面 GUI 的默认入口。它解决的是「本机应用如何把流量送进 Clash」，而不是「订阅 URL 一定从该端口出去」。订阅更新请求通常由内核直接外拨，不经过你在浏览器里填的 127.0.0.1:7890。

但当 GUI 或脚本错误地把「系统代理环境变量」指向了尚未就绪的本地端口，或把内核嵌套在另一个需要代理才能联网的容器里，仍会出现间接依赖 mixed-port的现象。排错时可在关闭「系统代理」开关后重试订阅更新：若关闭后立刻恢复，说明之前存在代理链路与规则组合问题，而不是订阅站宕机。

若你希望整体理解端口、TUN 与系统代理的关系，可把本文与 Clash 使用教程一起阅读：先把「入站 mixed」「出站节点」「DNS 模块」三块黑板分开，再叠加上 Windows 的全局代理与路由表，就不容易在日志里迷路。

7. 对照表与可勾选清单

下表汇总日志关键词与优先动作，建议打印或在第二屏幕对照操作。