梯子速度慢、晚上卡顿怎么办？分步骤定位原因

第一步：先给“慢”分个类

“慢”只是一种感受，背后可能是延迟高、带宽不够、丢包严重，也可能是流量根本没走对线路。这几个指标的含义和区别，见延迟、抖动、丢包与带宽的概念解析，本文不再展开。如果不是“慢”，而是显示已连接却完全打不开网页，请改看代理已连接但打不开网页的排查。动手之前，先对照下表找到最接近的症状：

分类的意义在于缩小范围：同样是“慢”，国内网站一起慢和只有晚上慢，排查方向几乎完全不同。

第二步：关掉代理，测一次本地基准

所有判断都需要一个参照物。先关闭代理（退出客户端，或者关闭系统代理和 TUN），用常见的国内测速服务测一次宽带，记下下载、上传和延迟：

• 本地基准就很低：问题在宽带或家里的网络，换节点没有用；
• 本地基准正常：问题更可能在代理链路上，继续往下排查。

Wi-Fi 是最常见的“隐形瓶颈”。信号穿墙、距离远、2.4 GHz 频段干扰多，都会让速度和稳定性大打折扣。有条件的话，用网线直连或靠近路由器再测一次。也可以测一下到路由器本身的往返时间，判断无线连接是否稳定。Windows 的网关地址可以在 ipconfig 输出的“默认网关”中查到，macOS 可以在系统设置的网络详细信息中查看路由器地址，下面以 192.168.1.1 为例：

# Windows PowerShell：连续测试 20 次到路由器的往返，留意耗时是否忽高忽低、是否有失败
Test-Connection -ComputerName 192.168.1.1 -Count 20

# macOS / Linux
ping -c 20 192.168.1.1

局域网内到路由器的延迟通常只有几毫秒。如果经常跳到几十甚至上百毫秒，或者出现超时，先解决 Wi-Fi 问题再谈节点。另外确认家里没有其他设备在大量下载、上传或同步网盘。

第三步：对比白天与晚高峰

用同一个节点、同一种测试方法，在上午或下午测一次，在晚上 20:00–23:00 之间再测一次：

• 白天快、晚上慢，而晚上的本地基准没有明显下降：大概率是线路或入口在高峰期拥塞，或者节点超售；
• 晚上本地基准也一起下降：宽带运营商自身在高峰期拥塞，与代理关系不大；
• 白天和晚上一样慢：回到第二步，或者继续看第四步和第六步。

单天的对比只能看出趋势。更可靠的做法是连续几天在相同时段测同一个节点，把时间、节点和实测速度记下来：如果每天同一时段都变慢，基本可以确定是高峰期拥塞；如果只是偶尔一天变慢，可能是临时故障或维护。判断一个服务长期是否稳定的更多方法，见验证梯子稳定性的方法。

第四步：换不同线路和地区的节点对比

只在同一组相似的节点里来回切换，很难看出问题出在哪里。建议按两个维度对比：

1. 同一地区、不同线路类型：例如同为香港，分别测标注为直连、中转和专线的节点（名称写法以服务商为准）。如果专线节点晚上依然平稳，说明拥塞主要发生在公网国际出口一段。三种线路的数据路径与晚高峰表现，见直连、中转与专线的对比。
2. 不同地区：例如香港、日本、新加坡、美国各选一个。距离越远延迟越高，单条连接的速度也越容易受影响，这是物理限制，不一定是故障。

如果同一入口的多个节点总是一起变慢，问题多半在入口带宽；如果所有节点都慢，而本地基准正常，就要怀疑客户端设置或服务的整体负载。

第五步：用 curl 经本地端口实测下载速度

测速网站有一个容易被忽略的问题：它可能被分流规则判定为直连，测到的是你的宽带而不是节点。经本地代理端口发出的 curl 请求同样要经过分流规则，所以测试前先临时切换到全局模式，并在全局模式下选好要测的节点；或者保持规则模式，在“连接”页面确认测速域名走了你选的节点，这样才能确保测到的是当前节点。用全局模式测完后，记得切回规则模式。

下面以 Cloudflare 测速页面所用的下载地址为例，参数 bytes 表示文件大小，这里约为 100 MB。这个地址并非正式公开的接口，可能调整或限制访问频率，也可以换成其他可靠的大文件地址。端口 7897 请换成客户端设置中显示的端口，Clash 系客户端常见 7890 或 7897：

# macOS / Linux：输出为平均下载速度，单位是字节每秒；-sS 表示不显示进度，出错时显示报错
curl -x http://127.0.0.1:7897 -o /dev/null -sS -w "%{speed_download}\n" "https://speed.cloudflare.com/__down?bytes=100000000"

# Windows PowerShell：使用 curl.exe，避免调用同名的 Invoke-WebRequest 别名
curl.exe -x http://127.0.0.1:7897 -o NUL -sS -w "%{speed_download}\n" "https://speed.cloudflare.com/__down?bytes=100000000"

speed_download 的单位是字节每秒，换算成 Mbps 需要乘以 8 再除以 1,000,000。例如输出 2500000，约等于 20 Mbps。

如果同时出现 Failed to connect 等报错、输出为 0，说明连接本身失败而不是速度慢，请改看代理已连接但打不开网页的排查。

使用时注意三点：

• curl 只用一条连接，结果通常低于多线程的测速网站，适合在节点之间横向比较，而不是拿去和宽带标称值比较；
• 每次测试会消耗约 100 MB 套餐流量，节点有倍率时按倍率扣除，不必频繁测试；
• 同一节点连续测两三次，取中间的数值，减少偶然波动的影响。

第六步：检查客户端一侧的因素

如果本地基准正常、各个节点都慢，或者一开代理连国内网站都变慢，重点检查以下几项：

• 全局模式或规则不当：全局模式会让国内流量也绕道境外，规则缺失也会让部分国内网站走代理。日常应使用规则模式（含义见常用术语），全局模式只在排查时临时使用。
• DNS 解析慢：表现为网页第一次打开要等好几秒，刷新后变快。上游 DNS 不可达或响应慢时常见这种情况。可以先清空系统 DNS 缓存（Windows 运行 ipconfig /flushdns），再确认客户端的 DNS 功能已启用、上游 DNS 地址可达；DNS 异常的其他表现也列在问题排查速查表中。
• 内核版本过旧：旧内核对新协议的支持和性能优化可能不足，升级客户端或内核后再测一次。
• TUN 模式的开销：TUN 要在虚拟网卡上处理所有流量，在性能较弱的电脑、手机或路由器上，CPU 可能成为瓶颈。只需要浏览器走代理时，可以改用系统代理做对比；在路由器上运行代理时，留意 CPU 占用是否长期接近满载。
• 后台占用：网盘同步、系统更新、下载工具走了代理，会挤占节点带宽，也会消耗套餐流量。可以在客户端的连接页面查看哪些连接在大量传输。
• 自动选择频繁切换：url-test 类代理组会定期测速并切换到延迟最低的节点，容差设得太小时可能频繁切换，导致长连接中断、体验忽好忽坏。

第七步：排除 UDP 和 QUIC 被限速

Hysteria2、TUIC 等协议基于 QUIC，运行在 UDP 上。部分运营商或网络环境会对大流量 UDP 限速或降低优先级，晚高峰往往更明显，但各地情况差异很大，没有统一规律。典型表现是：这类节点白天很快，晚上骤降甚至断开，而同一时段 Trojan、VLESS 等 TCP 类节点相对平稳。

排查方法很直接：晚高峰时，分别对一个 UDP 类节点和一个 TCP 类节点做第五步的测试。差异明显的话，晚上优先使用 TCP 类节点即可。另外，Hysteria2 节点配置中的上下行带宽值（例如 mihomo 节点中的 up、down 字段）应尽量接近你的真实宽带，填得过高可能加重拥塞和丢包，具体以 Hysteria 2 官方文档和服务商的说明为准。

第八步：整理数据，联系服务商

前面几步做完后，如果问题集中在服务端，例如只在晚高峰、多个节点一起变慢，而本地基准正常，可以整理以下信息提交工单：

1. 问题出现的时间段，以及是否每天都会出现；
2. 所在地区和宽带运营商，是否为校园网或公司网络；
3. 受影响的节点名称，以及表现正常的节点名称；
4. 本地基准速度，以及第五步测出的实际下载速度；
5. 客户端名称与版本，使用的是系统代理还是 TUN 模式。

截图时记得遮挡订阅链接。如果晚高峰拥塞长期得不到改善，说明当前服务的线路容量可能不适合你的使用时段，可以对照机场榜单的分项排行中的晚高峰数据重新比较。榜单数据同样只代表特定时间和网络环境下的表现，最终仍以你自己在高峰时段的实测为准。