Clash 网速慢怎么办：从节点、线路到本地设置的分层排查

Clash 网速慢，不一定是节点带宽不足。网页首次打开等待很久、视频开始播放后反复缓冲、下载速度持续偏低，可能分别对应域名解析、线路拥堵或本机流量接管问题。先区分症状，再按层检查，比同时改 DNS、节点和 TUN 参数更容易找到原因。

开始前：建立可重复的测速基线

先暂停云盘同步、系统更新和其他大文件下载，固定一台设备、一个网络、一个目标地址。使用规则模式时，还要在连接详情中确认目标实际命中了哪个规则、策略组和节点。没有经过预期节点的测试，不能用来判断该节点性能。

1. 记录环境：客户端版本、内核版本、操作系统版本、当前网络类型、节点名称，以及系统代理和 TUN 是否开启。内核版本可从客户端的关于页面或启动日志查找。
2. 固定策略：在客户端的代理或策略组页面手动选定一个节点，避免自动策略组在测试中途换线。若配置不允许手动固定，就记录每次连接实际选中的节点。
3. 分开测量：记录网页首次响应时间、持续下载速率和失败次数；每项重复 3 次，每轮间隔约 30 秒，不把单次峰值当作稳定速度。
4. 统一单位：100 Mbps 理论上约为 12.5 MB/s，实际还受协议开销影响。客户端显示的 MB/s 与宽带套餐标注的 Mbps 不能直接比较。

第一层：节点质量与实际吞吐

节点延迟不等于下载速度

客户端的延迟测试通常针对一个指定 URL 发起请求，反映的是这条探测路径的响应情况，并不等于持续传输能力。一个显示 60 ms 的节点，可能因为出口带宽共享而下载缓慢；显示 160 ms 的节点，也可能具有更稳定的持续吞吐。使用 url-test 的策略组同样不是自动带宽测速器。

先选择同一地区的 2 至 3 个节点，下载同一资源，每个节点测试 3 次。保持测速地址、并发数和测试时长一致。若只有单个节点明显偏慢，优先处理节点问题；若全部节点都慢，再检查它们是否共用入口或中转。

用明确的代理端口复测

桌面端可以用 curl 显式指定 HTTP 代理，排除命令行程序没有读取系统代理的问题。下面以已经确认监听的本地 HTTP 或 mixed 端口 7890为例；7890 不是所有客户端的默认值，必须先核对当前端口。命令使用公开测试端点下载约 10 MB 数据，会消耗相应流量。

# macOS / Linux；要求本机已提供 curl
curl --proxy http://127.0.0.1:7890 --output /dev/null --silent --show-error --max-time 60 --write-out 'connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s speed=%{speed_download}B/s\n' 'https://speed.cloudflare.com/__down?bytes=10000000'

# Windows PowerShell；显式调用 curl.exe
curl.exe --proxy http://127.0.0.1:7890 --output NUL --silent --show-error --max-time 60 --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s speed=%{speed_download}B/s\n" "https://speed.cloudflare.com/__down?bytes=10000000"

speed_download 的单位是字节每秒；例如输出 2500000 B/s，换算约为 2.5 MB/s。这只是读数示例，并非本站实测。短文件容易受到握手影响，结果只适合初步比较；还应使用实际受影响的网站复核，不能凭一个测速服务判断所有业务。

第二层：入口、中转与出口线路

不同节点名称不代表完全独立的网络路径。两个标注不同地区的节点，仍可能共用同一个接入入口或中转资源。如果多个节点在同一时间一起变慢，只更换地区可能没有效果。

用时间与网络做交叉对照

• 比较时间：例如在 10:00 与 21:00 测试同一节点、同一资源。若仅晚间持续下降，应优先怀疑高峰拥堵，而不是立即修改本地 DNS。
• 比较接入网络：同一设备分别连接家庭宽带与手机热点。测试热点前确认流量额度，并关闭后台下载。仅家庭网络异常时，再查路由器、运营商路径和 Wi-Fi。
• 比较入口：若服务提供方明确标出了不同入口或线路类型，可在相同目标地区下比较。不要把名称中的“专线”等字样直接当成性能结论。
• 比较目标：同一节点访问两个不同站点。只有一个站点慢时，还可能是目标 CDN、账户限速、出口地区或站点自身负载。

本机对节点服务器执行 ping，只能提供有限的可达性线索。部分服务器不回应 ICMP，部分中间路由器会降低 ICMP 响应优先级。中间一跳显示高丢包，而后续跳与最终目标正常，不能据此判定业务流量在该处同样丢包。需要结合实际 HTTPS 请求和持续传输结果判断。

若同一节点在两种接入网络下都慢，而另一条独立线路正常，可以暂时切换稳定线路，并向服务提供方提交测试时间、接入运营商、节点名称和结果。不要发送完整订阅地址、节点密码或含认证信息的配置。

第三层：DNS 与 TUN 本地设置

先区分解析等待与传输缓慢

DNS 异常常表现为首次访问等待、间歇性解析失败，或目标域名被解析到不合适的地址；它通常不能解释一条已经建立的下载连接长期只有很低速率。检查客户端日志中是否反复出现 DNS 超时、上游不可达或解析失败，再决定是否调整解析配置。

使用 mihomo 时，应查看最终生效配置中的 dns.enable、dns.enhanced-mode、dns.nameserver，以及启用 TUN 时的 tun.dns-hijack。这些是检查点，不是要求全部改成某个固定值。图形客户端可能通过覆写或合并配置生成运行文件，直接改订阅缓存文件可能在下次更新时失效。

• 检查上游可达性：加密 DNS 也需要可用的网络路径。若它依赖代理，而代理服务器域名又依赖同一条解析路径，可能形成启动依赖问题；应按内核文档区分普通域名与代理服务器域名的解析设置。
• 保留模式语义：fake-ip 返回用于映射的虚拟地址，不代表解析错误。不要看到 198.18.0.0/16 范围内的返回值就立即更换 DNS；实际地址池以生效配置为准。
• 确认浏览器行为：浏览器的安全 DNS 可能使用独立的 HTTPS 解析请求，不一定受传统 53 端口劫持影响。可临时关闭浏览器安全 DNS 做一次对照，测试后恢复原设置。
• 避免同时改多处：一次只调整一项解析来源，重新建立连接，再比较首次访问时间。不要同时修改系统、浏览器、路由器和客户端四处 DNS。

用系统代理与 TUN 做单变量对照

系统代理依赖应用支持并读取代理设置；TUN 通过虚拟网卡和路由接管流量，两者覆盖范围不同。选择一个明确支持 HTTP 代理的浏览器或使用前面的 curl 命令：先关闭 TUN，确认显式代理请求能工作，再测试 TUN 接管。测试时核对两次连接是否最终使用同一节点。

1. 保存当前配置，断开其他 VPN、游戏加速器或网络过滤工具，避免多套虚拟网卡同时争用路由。
2. 关闭 TUN，使用已确认的本地代理端口测试同一 HTTPS 资源，记录速度与错误。
3. 开启 TUN，用正常网络请求复测，并在连接详情确认流量已被接管；显式代理命令本身不能单独证明 TUN 工作正常。
4. 若只有 TUN 异常，再查权限、路由、DNS 接管及客户端日志，不要先更换全部节点。

第四层：系统负载与本地网络

检查设备是否已经达到资源上限

Windows 可按 Ctrl + Shift + Esc 打开任务管理器，在「进程」与「性能」查看 CPU、网络和磁盘；macOS 可打开「活动监视器」，查看「CPU」与「网络」。测试时观察客户端内核进程，而不是只看界面进程。若单个核心持续接近满载，总 CPU 使用率仍可能不高。

低性能路由器、旧手机或虚拟机更容易在加密传输、连接数量较多时遇到性能瓶颈。暂停多线程下载，再以单连接重测；若速率变化伴随 CPU 占用明显下降，应先减少并发或改用性能更合适的设备，而不是继续堆叠规则和功能。

排除 Wi-Fi、后台流量与端口冲突

• Wi-Fi：靠近路由器复测，条件允许时换网线。5 GHz 网络在信号较强时通常更适合大吞吐测试，但隔墙后的表现仍需实际比较。
• 后台任务：暂停网盘、备份、更新与游戏平台下载，检查上行是否被占满。上传拥堵也会影响网页响应和下载确认包。
• 本地监听：日志出现 address already in use 时先处理端口占用。Windows 可运行 netstat -ano | findstr :7890 查看相关连接和监听，再核对 PID；端口冲突属于启动或接管问题，不是节点限速。
• 安全软件：检查是否有 HTTPS 扫描、网络过滤或流量审计模块参与。只按软件文档对相关功能做短时对照，不要长期关闭防火墙，也不要添加覆盖全部程序的放行规则。

如果退出客户端后，原本能够直连的站点同样慢，应先解决本地网络问题。反过来，普通直连测速正常，也不能证明代理路径正常：两类流量经过的服务器和运营商互联路径可能不同。

收尾验证：确认改动有效并保留记录

完成一次调整后，重新建立测试连接。切换模式或策略组通常不意味着所有已有 TCP 长连接都会立即迁移；浏览器复用旧连接时，结果可能仍来自原节点。可停止当前下载后重新发起请求，必要时仅关闭目标连接，不必清空所有应用会话。

1. 复测相同条件：同一设备、网络、目标和测试方法下重复 3 次，比较中间水平与波动，不只比较最高速率。
2. 回到实际业务：确认原先卡顿的视频、网页或下载任务得到改善。测速端点变快而业务不变，说明还需检查该业务的分流、目标站或协议路径。
3. 只保留有效改动：无改善的 DNS、MTU、策略组参数及时恢复，避免下一次排查面对大量无法解释的差异。
4. 整理求助信息：记录发生时间、客户端与内核版本、网络类型、是否启用 TUN、两组对照结果和精简错误日志。日志分享前删除订阅地址、认证字段及个人访问记录。

排查 Clash 网速慢，最有效的顺序是先固定测试条件，再看节点吞吐、线路变化、本地 DNS 与 TUN，最后核对系统环境。延迟数字只是一条线索；能复现、能对照、能回退的测试，才足以支持下一步调整。配置字段和规则含义可继续查阅协议手册，基础连接问题可对照常见问题处理。