Clash 网速慢
分层排查

先区分：连接慢、下载慢还是局部站点慢

Clash 面板里的延迟数字，只反映一次指定地址的探测结果。它不等于下载带宽，也不能代表所有网站的访问质量。一个显示 80 ms 的节点，可能因为出口拥塞只能跑到很低的速度；另一个显示 180 ms 的节点，持续下载反而更稳定。先描述症状，再决定要查什么。

测试前暂停云盘同步、游戏平台更新和其他大流量任务。固定一台设备、一个接入网络和一个目标地址，每组至少测 3 次。记录时间段、规则模式、实际节点、下载速度与错误信息；测速时连续切换节点，会让不同连接走不同出口，结果难以比较。

第一层：确认本地监听与真实流量路径

不要把示例端口当成当前端口

打开客户端的端口设置，确认当前 HTTP、SOCKS 或混合端口。常见示例是 7890，但有些客户端使用其他数值。HTTP 端口不能直接当 SOCKS 端口使用；mixed-port 才是在同一监听端口接受 HTTP 与 SOCKS 代理请求。

下面是用于说明监听关系的 mihomo 配置片段，不是包含节点、策略组和规则的完整订阅。图形客户端可能会生成运行配置，应先在客户端设置中修改，避免订阅更新后覆盖手工改动。

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

• mixed-port: 7890：本机应用可连接 127.0.0.1:7890 使用代理。
• allow-lan: false：不向局域网开放代理入口；排查本机速度时不需要开启它。
• mode: rule：由规则选择策略，并不表示所有连接都走代理。
• log-level: info：保留常规排查信息，避免长期使用大量调试日志。

先做一次显式代理请求

Windows PowerShell 使用 curl.exe，避免某些环境把 curl 解释为其他命令。以下请求只检查 HTTP 代理入口与 HTTPS 隧道能否工作，不用于测量大文件速度。若实际端口不是 7890，先替换命令中的端口。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -I https://example.com/

macOS、Linux 可将命令中的 curl.exe 改为 curl。同时在客户端的「连接」页面筛选 example.com，确认它匹配的规则、策略组和最终出口。显式指定本地代理，只能证明请求进入内核；规则仍可能把目标分配给 DIRECT。

若提示无法连接本地端口，先检查内核是否启动、端口是否被占用，而不是更换远端节点。Windows 可运行下列命令查看监听及 PID；没有输出通常表示该端口没有 TCP 监听。出现 PID 后，在任务管理器「详细信息」中核对所属进程。

netstat -ano | findstr LISTENING | findstr :7890

第二层：验证节点负载与策略组选择

节点名称通常只是提供方的标注，不足以证明实际物理位置或传输线路。排查时先固定策略组中的具体节点，再观察连接详情。若测试组使用 url-test、fallback 或 load-balance，新连接可能自动切换或分配出口，不能简单把策略组名称当成固定节点。

1. 在当前命中的策略组内选定节点 A。若是自动组，可临时使用已有的手动选择组；先备份配置，不要直接覆盖整个订阅。
2. 关闭原来的下载任务，重新发起连接。切换节点通常不会把已经建立的 TCP 连接迁移到新出口。
3. 对同一个下载源测 3 次，每次观察约 30 秒；记录稳定阶段速度，不只记录启动峰值。
4. 用节点 B 重复相同步骤。优先选择与 A 不同线路或不同提供方的节点，而不是只换一个相似名称。
5. 在另一个时间段复测。晚间慢、白天正常，是容量或路径拥塞的线索，但还不能单独证明服务器负载过高。

如何判断“节点慢”而非“测试源慢”

若节点 A 访问两个独立下载源都慢，而 B 在同一设备和网络下都正常，可以优先怀疑 A 的入口、出口或资源限制。若所有节点只对一个下载源慢，更应检查该站点的单连接限速、账号限制和 CDN 调度。公共测速站的多连接成绩，也不能直接替代浏览器单文件下载速度。

第三层：把本地网络与远端线路拆开

“直连正常、代理慢”仍然有多种可能：本地运营商到节点入口的路径拥塞、节点出口到目标站点质量较差，或者代理协议对应的连接受到限制。用同一台设备切换接入网络，是区分这些因素的有效办法。

Windows 可先用 ipconfig 查看当前默认网关，再对实际网关地址执行 ping -n 30；macOS、Linux 可用 ping -c 30。不要把示例网关地址直接当成自己的路由器地址。空闲时局域网延迟也明显波动，或出现持续丢包，应先处理 Wi-Fi 信道、距离、网线和路由器负载。

对节点入口做 Ping 或路由跟踪只能作为旁证。部分服务器不响应 ICMP，中间路由器也可能限制探测报文；某一跳显示丢包，而后续跳和最终目标正常，并不代表转发数据真的丢失。不要仅凭一张路由跟踪图就断定节点故障。

只在上传或下载时变慢

如果空闲正常，上传文件后网页和语音一起卡顿，可能是上行占满导致排队。先把上传任务限制到可用上行带宽的约 80%～90%，再重复测试。这个范围是排查起点，不是固定最优值；支持队列管理的路由器还可进一步调整。不要同时改客户端、路由器和节点，否则难以定位是哪一步改善了结果。

用 curl 分开看等待时间与传输速度

对一个允许下载、大小已知且足够持续传输的 HTTPS 文件进行测试，比反复刷新网页更容易比较。避免用几 KB 的页面推算带宽，也不要选择需要浏览器登录、验证码或短时签名的地址。以下命令适用于 macOS、Linux 的常见 shell，交互输入你已确认的下载地址，不会把文件保存到磁盘。

printf '输入测试文件的 HTTPS 地址：'
IFS= read -r test_url
curl --noproxy "" \
  --proxy http://127.0.0.1:7890 \
  --location \
  --connect-timeout 10 \
  --max-time 30 \
  --output /dev/null \
  --write-out '\nhttp=%{http_code}\nfirst_byte=%{time_starttransfer}s\ntotal=%{time_total}s\nbytes=%{size_download}\nspeed=%{speed_download} B/s\n' \
  "$test_url"

• http：先确认是正常内容响应，而非 403、429 或错误页面。206 可能是服务器返回的部分内容。
• first_byte：从请求开始到收到首字节的时间，包含前面的连接与握手过程，不是单独的 DNS 耗时。
• total：本次请求总时间。重定向、服务器等待和实际传输都会影响它。
• speed：本次传输报告的平均下载字节数/秒；应与有效内容大小和测试时长一起看。

大文件未在 30 秒内传完时，命令可能以超时错误退出，这是 --max-time 30 的预期限制；应结合已下载字节数判断，而不是把所有超时都当成链路中断。若测试文件几秒就传完，应选更大的文件，或明确记录这只是短样本。

使用 HTTP 代理访问 HTTPS 目标时，目标域名的解析通常由代理链路处理。curl 的本地 DNS 计时不能直接代表 mihomo 内部的目标解析耗时。首字节慢时，要结合内核日志、规则命中和实际 DNS 配置分析，不能只看一个计时字段。

本地设置：系统代理、TUN 与 DNS 分别验证

先用一种接管方式建立基线

系统代理主要影响读取系统设置的应用。终端、部分游戏和自带网络栈的软件可能不跟随它。TUN 则通过虚拟网卡与路由接管符合条件的 IP 流量，但仍受规则、排除项、权限和平台实现影响，不等于所有连接都走远端代理。

1. 暂停其他 VPN、加速器与代理软件。检查是否存在重复的系统代理或虚拟网卡接管。
2. 先关闭 TUN，用前面的 curl 显式代理命令建立基线；此时不依赖应用读取系统代理。
3. 再启用系统代理，检查浏览器。Windows 11 可在「设置」→「网络和 Internet」→「代理」核对系统项，并检查浏览器代理扩展是否覆盖它。
4. 需要接管不支持代理的应用时再开启 TUN，确认客户端服务已安装、权限已授权，并用新连接比较。

如果只有 TUN 开启后速度下降，应重点查看路由冲突、DNS 劫持配置和虚拟网卡状态。不要首先调整 MTU。只有出现“小请求正常，大响应或特定连接反复卡住”等可重复现象，并排除其他因素后，才适合进一步检查路径 MTU；调整前记录原值，每次只改一项。

DNS 不用“越多越快”的思路配置

mihomo 的 dns.nameserver、dns.proxy-server-nameserver 和 dns.nameserver-policy 处理的对象不同。节点服务器域名的解析与目标网站域名的解析也不是一回事。修改时应以当前内核文档和订阅设计为准，避免让解析节点所需的 DNS 又依赖尚未建立的代理链路。

使用 fake-ip 时，客户端获得映射地址可能是正常机制，不能把它直接判断为解析错误。若只是少数应用不兼容，可针对相关域名评估 fake-ip-filter，而不是立即关闭整个 DNS 模块。IPv6 也应通过有、无 IPv6 路径的对照测试定位，不建议把关闭 IPv6 当成所有慢速问题的通用答案。

配置无法加载时先读取内核错误，再谈测速。使用 mihomo 命令行的用户，可在配置所在目录执行下列检查；图形客户端则使用自身提供的配置检查与日志入口。语法通过只代表配置可解析，并不保证节点可用或规则符合预期。

mihomo -t -f config.yaml

收尾：用最少的改动形成可复现结论

一轮有效排查，应能说明“哪个条件变化后，哪个指标随之变化”。例如：同一设备、同一节点、同一文件，在家庭宽带慢、手机热点正常，优先追查接入网络到节点入口；同一网络下节点 A 对两个目标都慢、节点 B 正常，优先联系提供方检查 A 的线路与资源。

• 仅浏览器慢：检查扩展代理、站点缓存和该站点实际命中的规则，不必先重装整个客户端。
• 所有节点都慢：确认直连基线、本地监听、后台占用与其他网络软件，随后再检查共同的服务商限制。
• 只有自动策略组慢：固定节点复测，检查探测地址、切换行为与新连接的实际出口。
• 更新订阅后变慢：比较策略组、规则顺序和节点变化，保留备份；不要只比较订阅文件大小。
• 需要他人协助：提供系统版本、客户端版本、内核版本、时间段、接入网络、复现步骤和脱敏日志。