Clash 网速慢怎么排查:节点、线路到本地设置的三层定位法

先固定测试条件，区分延迟与吞吐量

Clash 节点旁的延迟数字，只能说明一次探测请求的耗时。它不能代表持续下载速度，也不能保证视频平台、代码仓库和网页使用相同线路。出现“延迟 80 毫秒，下载只有 200 KB/s”时，先记录实际连接，再决定修改哪一层。

本文的 TUN 配置以使用 mihomo 内核的客户端为讨论对象。传统 Clash 内核与不同客户端提供的选项并不完全一致。开始前，在客户端的“关于”或“内核”页面记录客户端名称、版本、内核版本，以及当前配置名称，避免把其他内核的字段直接复制进来。

建立一组可复现的基线

1. 暂停网盘同步、系统更新和其他大文件下载。电脑尽量接网线；使用 Wi-Fi 时固定位置与频段。
2. 选择一个稳定的直连站点和一个需要代理的目标。使用相同文件、相同测试时长，不要每轮更换测速服务器。
3. 保持规则模式与策略组不变，手动选定节点。每个条件测 3 次，每次持续 30 秒，记录中位数。
4. 记录开始加载耗时、稳定下载速度、是否中断，以及连接面板显示的规则、策略组和最终节点。

以下表格是记录方式示例，不是对具体服务的实测结论。真实排查时，应填写同一台设备、同一测试资源得到的结果。

第一层：确认节点与实际出站

先看连接面板，再切换节点

在客户端的“连接”面板找到正在下载的请求。核对目标域名、匹配规则、策略链和出站节点。只修改策略组中的节点，不一定会改变已建立连接的出口；浏览器长连接、视频连接和下载任务可能继续使用旧连接。

每轮切换后，停止并重新发起测试任务。需要时只关闭该测试对应的连接，不要在远程桌面或会议进行中清空全部连接。若面板显示 DIRECT，当前问题并不是所选代理节点的吞吐量问题，应先检查规则命中。

• 单个节点慢：在同一策略组内比较 2～3 个节点。仅一个节点持续低速，优先怀疑该节点负载、限速或出口质量。
• 自动组反复切换：临时使用手动选择组完成测试。url-test 主要按探测延迟选择节点，不等同于带宽测试。
• 只有一个站点慢：换一个目标资源复测。站点限速、CDN 调度和节点出口到目标站的互联都可能影响速度。

规则模式与全局模式只做短时对照

如果怀疑目标被错误直连，可以短时切到全局模式，并明确选择 GLOBAL 的出站，再重建测试连接。若全局模式恢复正常，而规则模式仍慢，回到规则模式检查域名规则、规则集更新和策略组指向。全局模式并不会提升节点本身的带宽，也不保证未进入客户端的流量被接管。

不要为了测速立刻改写订阅中的全部规则。先记录命中的规则，再用客户端支持的本地覆写修正目标域名。直接编辑订阅生成文件，可能在下次更新时被覆盖。

第二层：对照接入网络与远端线路

节点名称中的地区通常不能说明完整传输路径。连接可能先经过入口服务器或中转，再从另一个出口访问目标。客户端连接面板能确认选用了哪个出站，但未必能展示服务端的全部中转链路。

用交叉测试缩小故障范围

1. 同一网络换节点：家庭网络固定，只切换节点。如果某一组入口都慢，而其他入口正常，记录这些节点的共同特征。
2. 同一节点换网络：保持节点与目标不变，从家庭宽带换成手机热点。先暂停大流量任务，控制移动数据消耗。
3. 同一组合换时间：分别在非高峰时段与晚间复测。只在晚间出现的下降，更值得关注接入网、入口或中转拥塞。

如果节点 A 在家庭网络慢、在热点快，而节点 B 在两者都正常，更接近“家庭网络到 A 的路径问题”，不能据此认定 A 的服务器带宽不足。如果所有节点在两种网络都慢，但直连下载正常，再检查客户端、本机代理链或测试目标的限制。

Ping、路由追踪与下载速度分别看

对代理入口执行 Ping 或路由追踪，只能提供部分网络线索。中间路由器可能限制 ICMP 回复；某一跳显示丢包，而后续终点没有同等丢包，通常不能直接判定该跳正在丢弃转发流量。普通路由追踪也无法展开加密代理连接内部的服务端中转路径。

提交线路问题时，附上时间与时区、接入运营商、节点名称、目标域名、三轮测试结果和网络切换结果。不要只提交一张延迟列表。分享日志前删除订阅地址、令牌、节点密码及个人访问记录。

第三层：隔离系统代理、TUN 与本机冲突

先确认本地监听端口

系统代理通常把遵循系统设置的应用交给本地 HTTP 代理；TUN 则通过虚拟网卡与路由接管流量。两者可以在特定配置下同时工作，但排查时应分开测试，避免同时改变入口和路由。下面以实际配置中存在 mixed-port: 7890 为例，7890 不是所有客户端的固定端口。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

在 Windows PowerShell 中运行下列命令，先确认端口有监听，再显式指定代理发起请求。这个请求用于检查路径和响应时间，不用于测量大文件带宽。

Get-NetTCPConnection -LocalPort 7890 -State Listen

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

将命令端口与客户端实际端口保持一致。这里的 time_connect 主要反映连接本地代理的耗时，不能当作节点往返延迟；time_starttransfer 包含后续代理协商、TLS 与服务端响应等阶段。应比较相同请求的变化，而不是把某个字段简单归因于 DNS。

按系统代理、TUN 的顺序做 A/B 测试

1. 关闭 TUN，只开启系统代理，用明确支持 HTTP 代理的浏览器或上述命令测试。
2. 记录结果后关闭系统代理，开启 TUN，重新建立相同目标的连接，并确认连接面板确实出现该请求。
3. 若只有 TUN 慢，检查是否同时启用了其他 VPN、加速器或虚拟网卡工具。逐项暂停后复测，不要同时关闭多项安全功能。
4. 若 TUN 无法启动，先处理服务权限、虚拟网卡或路由创建错误。启动失败与吞吐量偏低是两类问题。

mihomo 的 TUN 栈选项包括 system、gvisor 和 mixed，可用性和行为受平台及内核版本影响。mixed 通常组合 system TCP 与 gVisor UDP。没有适用于所有设备的“最快栈”；每次只改一个选项，重启相关内核后用相同任务复测。

DNS 与 UDP：区分打开慢、下载慢和视频卡顿

首次打开慢，优先观察解析

如果首次访问停顿数秒，刷新后立即恢复，但文件下载开始后速度正常，应优先检查解析超时和连接建立阶段。观察日志是否持续出现 DNS 超时，以及目标域名是否被不同解析器返回到差异很大的 CDN 地址。浏览器缓存、连接复用也会造成“第二次更快”，不能只凭这一现象确定 DNS 故障。

enhanced-mode: fake-ip 通过虚拟地址映射辅助域名识别，不会直接增加节点带宽。nameserver-policy 用来为指定域名选择解析器，也不是出站策略组。调整时需要同时确认解析器能否访问、返回地址是否适合当前出口，以及 DNS 请求的实际路由。

• 浏览器的安全 DNS 可能走自己的 DoH 通道，绕过系统 DNS。诊断时记录其状态，必要时短时关闭作对照，完成后恢复。
• TUN 的 dns-hijack 常用于接管传统 53 端口请求，不能据此认定全部 DoH、DoT 流量都被接管。
• 切换 fake-ip 与真实地址解析模式后，按客户端支持的方式清理相关 DNS 缓存并重建测试连接，避免旧地址继续影响结果。

视频卡顿，检查 UDP 与 QUIC

网页下载正常，但视频、语音或游戏异常时，要单独检查 UDP。浏览器可能使用基于 UDP 的 QUIC，节点及服务端也需要支持对应转发路径。用客户端连接面板确认是否出现 UDP 请求，再通过客户端或浏览器支持的方式短时停用 QUIC作对照，观察回退到 TCP 后的变化。

如果回退后恢复，只能说明 UDP 路径值得进一步检查，不能推出所有 UDP 都应长期阻断。同样，不要把关闭 IPv6 当作通用提速办法。先确认 AAAA 解析结果、IPv6 默认路由和代理接管是否一致，再决定是否临时限制地址族测试。

按证据收敛结论，保留可回滚配置

完成三层对照后，把问题归到最小范围。以下对应关系用于决定下一步，不替代服务端或网络侧的进一步诊断。

保留原配置或导出备份，记录每次修改的字段、时间和结果。若问题由某项更新引入，先恢复该项设置验证，再考虑更新客户端或内核。处理完成后恢复日常使用的规则模式、必要的安全设置与日志级别，避免让临时测试配置长期运行。