先分清：是「节点列表没更新」，还是「测速探针全失败」
不少用户把订阅刷新正常和延迟测试全场能通过混成一件事。Clash 一类客户端里，「测速」「延迟检测」往往是对每个出站地址做一次短连接或 ICMP 式探测：只要本地到节点 IP 的路径上任意一环握手慢、被拦、或解析出的目标根本不对，你在界面上就会看到Clash 测速全红、数字长期缺席，或进度条一直转圈。这与「点了更新但节点名不变」的缓存 / 配置档错位不是同一条路——后者列表可能仍是旧的；前者则是列表已在，但探针层集体超时。
若你主要怀疑订阅没拉到新内容，请先对照 Clash 订阅刷新后节点没变 一文做「远端是否变化、URL 是否一致、是否更新对了档案」那条线。本文假设你已经能展开节点列表，但节点超时或测速列全军覆没，从 DNS、IPv6 与订阅链接在 Windows 上是否可达往下拆。
测速在测什么：为什么「能上网」仍可能「全超时」
浏览器能打开部分网页，并不代表 Clash 对每个节点做的探测一定成功。常见差异包括：浏览器走了系统代理或扩展，而测速由内核直接连节点；你当前策略组锁在某一节点，测速却逐枚尝试订阅里全部地址；以及 fake-ip 模式下，解析与真实握手发生在不同阶段——任何一步与规则、DNS 或 TUN 路由不一致，都会表现为「只有测速坏」。因此不要把单个网站能否打开当作唯一证据，要把解析结果、出口与探针目标 IP放在一起看。
另一点是超时阈值：机场节点地理分散时，部分线路本身 RTT 高，若客户端或内核把超时写得过短，也会出现「几乎全红」的夸张界面。可先尝试在允许的前提下仅对几枚已知稳定的节点手动测速或改换客户端里与测速相关的间隔设置（视你所用的 Clash 衍生版而定），再判断是「真的不可达」还是「阈值过严」。
第一步：查 DNS — 系统、Clash 与「泄漏」感知的交界
DNS 出问题是 Windows 上最让人困惑的一类：用户体感像「Clash 测速全红」，本质是解析交给了一个慢或被污染的递归，或Clash 配置的 DNS 段与系统网卡不一致，导致节点域名先被解析成不可路由的地址，再进入超时。
建议按下面顺序快速取证：① 打开「设置 → 网络和 Internet」查看当前活动连接使用的 DNS，临时改成运营商无关的公共 DNS（例如你在合规环境下允许使用的国内外公共解析），断开重连后再进客户端测速。② 在 Clash / Verge 的日志或连接视图里看订阅域名、节点域名实际解析到的 IP 是否符合预期；若全程只看到 198.18.x.x 一类保留段，要立刻对照你是否启用了 fake-ip 以及 redir-host / 嗅探相关配置，必要时阅读 fake-ip 与 DNS 一致性 一文，避免「解析对了、握手却找错主机」。
「DNS 泄漏」在中文社区常被泛化使用：严格来说，要区分浏览器侧 DoH、系统解析与内核出站前的解析各自走哪条出口。排查时不必先下结论，只要把三次解析路径对齐——系统、Clash dns: 块、以及测速发生时内核选用的是否为同一逻辑即可。
第二步：IPv6 — 双栈下「抢解析」与半断链
Windows 默认常处于 IPv4 + IPv6 双栈。若你的路由器或上游对 IPv6 只做「半开通」——能拿到地址，但出境 UDP/某些 TCP 路径不通——应用可能优先尝试 IPv6，在超时后才回退 IPv4，于是你在 Clash 里看到的就是大面积节点超时，而换一个只走 IPv4 的网络又立刻正常。
排查可以非常务实：临时禁用当前网卡的 IPv6（适配器属性里取消 IPv6 勾选，或用管理员权限按需调整），重启网卡后再跑一轮测速。若红色瞬间消失，说明你要处理的是双栈优先级或上游 IPv6 质量，而不是单纯「机场全挂」。长期方案可以是：在路由器侧修好 IPv6 出口，或在系统路由层明确策略；短期为了确认问题，关 IPv6 是最省时间的对照实验。
注意这与「纯 IPv4 机场」也兼容：双栈环境下，解析器可能仍返回 AAAA 记录，客户端若优先走 AAAA，就会在「根本没有 IPv6 业务」的幻觉里反复超时。于是「关 IPv6」在排障清单里常年占一位，不是旧闻，而是握手层血案高发点。
第三步：订阅链接无法更新 — 在浏览器里复现「拉不拉得到」
若不仅测速红，连订阅更新也频繁失败，要先证明：同一台 Windows 上，用浏览器或命令行能否直连打开订阅 URL（或返回的文件体积是否合理）。若浏览器在关闭系统代理时就能秒开，而一开 Clash 反而失败，很像订阅域名被送进代理，代理又依赖这份订阅才能通——典型环路。
处理思路是把面板、订阅主机名在规则里置顶为 DIRECT，更新时暂时关闭 TUN，或换一份不含复杂规则的配置做「裸拉订阅」。更细的 URL 与多订阅管理见 订阅链接与多订阅。若直连也拉不动，要回到运营商网络、上级防火墙、或订阅证书是否被中间人拦截——这类问题不属于 Clash 内部设置，但会原样反映在「测速全挂」上，因为节点根本没进来。
Windows 上可执行操作小结：换 DNS、关 IPv6、对齐系统代理
把上面几步压缩成桌面用户可执行清单：① 网卡 IPv4 DNS 改为可信公共 DNS，刷新 DHCP 或重连 Wi‑Fi。② 对当前连接临时关闭 IPv6，确认测速是否恢复。③ 在「代理关 / 代理开」两种状态下分别用浏览器访问订阅链接，记录差异。④ 确认 Clash 写入的系统代理端口与内核 mixed-port 一致，避免测速走了空端口；端口占用类问题可参考 7890 / mixed-port 占用 一文。
使用 Clash Verge Rev 的用户若权限或安装路径异常，也可先对照 Verge Windows 安装，确保内核能以预期权限改写系统代理与路由；否则会出现「界面显示已开代理、测速却仍直连失败的分裂现象」。
第四步：用日志印证 — 规则命中、握手与真实失败原因
当 DNS 与 IPv6 都过关后，若仍Clash 测速全红，请打开连接日志，看失败是挂在 DNS、TCP 握手、还是TLS。若大量节点同时 TLS 失败，可能是本地时间偏差、部分国产化安全软件截 HTTPS，或出口对 SNI 的干扰——需要把样本节点名与报错码记下来，对照机场公告，而不是反复点测速。
规则层面，确认没有把整个「测速目标 IP 段」误送进一条不可用的策略组；也没有在 GLOBAL 或 MATCH 之前插入过于激进的屏蔽。更系统的日志读法见 连接日志与规则命中。把日志里的一两条典型失败链路与本机网络对照，比盲试节点更有效。
收尾清单（建议按顺序勾）
① 确认不是「订阅缓存」类问题（列表是否真的刷新）。② 改 DNS 并重连网络后再测速。③ 临时关 IPv6 做对照。④ 浏览器直连 / 经代理 两种方式验证订阅 URL。⑤ 排除订阅域名走代理导致的环路。⑥ 看日志区分 DNS、TCP 与 TLS 失败。⑦ 核对 mixed-port 与系统代理一致、无端口冲突。
把这套流程固定下来，多数「节点超时」会在前十分钟内露出真凶：要么是解析与双栈，要么是订阅与规则路径，而不是泛泛的「客户端坏了」。当你需要稳定分发渠道与版本说明时，建议优先从本站 Clash 客户端下载页 获取与当前系统匹配的构建；开源仓库适合查阅协议与提交记录，日常安装不必强依赖外站直链。相比在同一误区里反复重装，先完成 DNS 与 IPv6 的对照实验，往往能一次性省下大量时间。→ 立即免费下载 Clash，开启流畅上网新体验