Clash 连接速度慢怎么排查:节点、线路与本地设置三层定位

Clash 节点列表显示 80ms，视频仍然缓冲；换了一个 180ms 的节点，下载反而更快。这并不矛盾：延迟测试、持续传输和应用加载测量的不是同一件事。排查时先确定慢在哪里，再依次检查节点、线路和本机，通常比连续修改 DNS、规则和 TUN 参数更容易找到原因。

一、区分延迟高、吞吐低与网页首开慢

Clash 类客户端中的“延迟”通常来自一次经节点访问测试地址的请求，并不等于 ICMP ping，也不直接代表可用带宽。测试地址、超时时间和连接复用都会影响结果。把测试地址从一个站点换到另一个站点，数字可能变化，但目标视频平台的体验未必改善。

建立可以重复的测速条件

1. 暂停云盘同步、游戏更新和其他设备的大文件下载；笔记本接电，先使用稳定的 Wi-Fi 或有线连接。
2. 固定同一台设备、同一个下载源和同一种连接方式，选择允许测试、体积足够的文件，连续传输至少 30 秒。
3. 每组测 3 次，记录中位数。不要只截取刚开始几秒的缓存峰值，也不要同时测速十几个节点。
4. 分别记录直连与代理结果。某些目标直连不可达，应改用可直连的对照站点，不能把连接失败直接算成零带宽。

注意单位：100 Mbps 的理论传输上限约为 12.5 MB/s，实际还要扣除协议开销。下载器显示 10 MB/s，并不意味着百兆宽带只能跑到十分之一。浏览器多连接下载与单连接下载也可能差很多，应分开记录。

二、第一层：确认节点质量与实际策略选择

先在客户端“连接”页面找到正在测试的域名，核对命中的规则、策略组和最终节点。规则模式下，切换界面上某个代理组，不一定影响当前请求；嵌套策略组也可能继续指向另一个自动选择组。已有连接通常不会因为切换选择而立即重建，测试前应停止下载并重新发起请求，必要时只关闭相关旧连接。

用三个节点做对照，不只挑最低延迟

• 同地区不同节点：帮助判断是否为单个节点拥塞，尽量选择不同入口或不同线路标识的节点。
• 不同地区节点：检查目标服务是否对某个出口地区或运营商互联路径不友好。
• 同节点不同时段：在白天与晚间各测一次；仅晚间明显下降，更像容量或互联拥塞，不应先修改本机 MTU。

例如，节点 A 测得 65ms、持续下载 1.2 MB/s，节点 B 测得 145ms、持续下载 8.0 MB/s，这组示例只能说明 B 对该次大文件传输更合适，不能推导 B 对所有游戏或网页都更好。请把表格里的测试地址、时间和节点一起保存，避免把不同条件的数字直接比较。

订阅更新解决的是配置和节点信息是否过期，不会直接提高线路容量。先确认订阅未过期、流量未耗尽、服务端没有限速提示，再手动更新一次。如果更新失败，保留仍能运行的配置，查看返回错误，不要反复删除订阅重建。

三、第二层：分开检查入口网络、出口线路和目标站点

一次代理连接至少涉及设备到节点入口、节点到目标站点两段路径。换节点同时改变了多项条件，因此“换完就快”还不足以确认根因。最有效的补充对照是：保持节点不变，把电脑网络从家庭宽带换成手机热点，然后重复同一个任务。

丢包测试要看终点，不只看中间跳

Windows 可用下面的命令观察一个公共 IP 的基础连通性。这里的地址只是网络探测目标，不是建议写入配置的 DNS，也不代表节点路径。开启 TUN 时探测是否经过内核取决于路由和 ICMP 支持；要建立直连基线，应先暂停 TUN 并确认系统路由已恢复。

ping -n 30 1.1.1.1
tracert -d 1.1.1.1

中间路由器可能限制 ICMP 回复，某一跳显示超时而终点正常，不能据此认定链路丢包。终点不回复也不必然说明网页不可用。若上传已跑满，下载确认包和网页请求会排队，可先将上传任务暂停复测；这类现象通常无需修改代理协议。

四、第三层：排除系统代理、TUN 与应用设置冲突

系统代理和 TUN 是不同的接管方式。系统代理主要服务于遵循系统代理设置的应用；TUN 通过虚拟网络接口接管符合路由条件的流量。两者同时开启不必然冲突，但在故障排查阶段，保留一种方式更容易确认流量到底从哪里走。

先只测试系统代理

1. 退出其他 VPN 和代理工具，关闭当前客户端的 TUN，保留系统代理。
2. Windows 11 打开「设置」→「网络和 Internet」→「代理」，核对手动代理或脚本设置是否与预期一致。macOS 打开「系统设置」→「网络」→ 当前网络 →「详细信息」→「代理」，检查是否残留其他工具的地址。
3. 确认客户端实际监听端口。下面示例使用本机 HTTP 或 mixed 端口 7890；这是常见示例值，不是所有客户端的固定默认值。
4. 用显式代理请求与浏览器结果对照。Windows PowerShell 使用 curl.exe，避免旧版环境中 curl 别名的行为差异。

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n" https://www.example.com/

这个小页面用于检查请求能否完成、首字节等待是否异常，不能测出最大下载带宽。通过 HTTP 代理请求时，time_connect 主要反映到本地代理的连接建立，不能当作远端节点延迟；time_starttransfer 则包含后续协商和服务端等待。macOS 或 Linux 可使用 curl，并把 NUL 改成 /dev/null。

再单独测试 TUN

关闭系统代理后开启 TUN，保持相同节点和目标，重新建立连接。如果仅 TUN 慢，检查客户端服务权限、虚拟接口、路由以及其他 VPN 残留；如果显式代理请求很快、浏览器很慢，优先排查浏览器代理扩展、安全 DNS和缓存，而不是重新购买节点。

游戏、语音和部分视频连接可能使用 UDP。HTTP 代理测试成功只证明相应 TCP 请求可用，不能证明 UDP 路径正常。需要同时确认应用被接管、节点协议支持相应转发、服务端允许 UDP，并在连接记录中核对实际流量。不要把关闭所有 UDP 当作通用提速方案。

五、DNS 与 MTU：有对应症状再调整

首开慢先查解析路径

如果页面第一次打开慢，刷新后正常，检查日志中是否反复出现解析超时，以及 DNS 上游是否可达。使用 mihomo 的 fake-ip 模式时，返回虚拟地址可以是正常行为，不应只因为看到 198.18.0.0/16 范围内的地址就判断解析错误。浏览器安全 DNS、操作系统解析和内核 DNS 可能走不同路径，需要结合实际接管方式判断。

• 保留一套已经可用的 DNS 配置做基线，不要一次塞入大量不熟悉的上游。
• 检查分流规则是否让 DNS 上游产生循环依赖，特别是需要先解析域名才能建立的代理连接。
• 修改 DNS 或 fake-ip 设置后，按客户端要求重载，关闭旧连接再测；Windows 可用 ipconfig /flushdns 清理系统解析缓存，但它不会清空所有应用和内核缓存。

大包卡住、TUN 独有异常再查 MTU

MTU 是链路允许的最大传输单元。封装开销或路径 MTU 探测受阻，可能造成小请求成功、大文件或部分 TLS 连接卡住。但 1500、1480、1400 都不是适合所有网络的固定答案，降低 MTU 也不会自动提高节点带宽。

Windows 可在命令提示符测试 IPv4 不分片报文。以太网 MTU 为 1500 时，1472 字节 ICMP 数据加上通常的 28 字节 IPv4 与 ICMP 头，合计 1500 字节。若失败，可尝试 1400 字节数据作对照：

ping -4 -f -l 1472 -n 4 1.1.1.1
ping -4 -f -l 1400 -n 4 1.1.1.1
netsh interface ipv4 show subinterfaces

目标可能屏蔽 ICMP，这两条 ping 也不一定覆盖代理隧道的实际路径，因此结果只是线索。确有 TUN 相关大包问题时，先记下当前 TUN MTU，仅在当前客户端或 mihomo 的 TUN 配置中暂改为 1400，重启相关连接复测；无改善就恢复。不要顺手修改所有物理网卡，也不要把这组 IPv4 测试公式套到 IPv6。

六、整理结果，避免反复盲调

完成三层对照后，通常已经能把问题缩小到一个范围。提交给服务提供方或客户端维护者的信息，应包含可重复步骤，而不是只说“速度很慢”。下面的清单足够形成一份有效记录：

• 运行环境：操作系统版本、客户端版本、内核名称与版本，是否开启 TUN，以及实际监听端口。
• 测试条件：日期时段、家庭宽带或手机热点、目标服务、单连接或多连接。
• 对照数字：同节点三次持续测速的中位数、切换节点前后结果、首字节等待时间。
• 流量路径：命中规则、最终策略节点、失败请求附近的必要日志，并移除认证信息。

如果当前客户端或内核长期没有维护，先备份订阅和自定义规则，再选择适合系统的维护中客户端。迁移后先使用最小配置完成连接，再逐项加回覆写、规则和 TUN 设置，避免把旧环境中的冲突原样带过去。基础操作可以对照Clash 配置教程，连接失败与测速超时也可查看延迟检测常见问题。