代理速度慢可能让人抓狂：下载文件很慢、视频频繁缓冲、网页加载迟缓……但「慢」的原因可能来自完全不同的地方。系统化地定位瓶颈比盲目换节点更有效率，本文提供一套从「诊断」到「优化」的完整流程。
第一步：定位速度瓶颈的来源
代理连接的速度受三段因素影响，需要逐一排查：
本地设备 → [本地网络] → 代理节点 → [中转线路] → 目标服务器
段① 段② 段③
检查本地网络（段①）
测试方法：访问国内测速网站 https://www.speedtest.cn/（使用直连，不走代理）：
- 如果国内测速也很慢（< 20Mbps），问题在本地网络（路由器、网线、ISP）
- 如果国内测速正常（> 100Mbps），本地网络没问题，继续排查段②③
检查代理节点质量（段②）
测试方法：在 Clash Verge Rev 中，对不同节点进行延迟测试：
- 节点延迟 > 200ms 或频繁变动：中转线路质量差，换节点
- 节点延迟 < 100ms 且稳定，但速度仍然慢：可能是节点带宽饱和或目标服务器问题
进一步测试：连接一个延迟较低的节点后，访问 https://speed.cloudflare.com/，这个测速用的是 Cloudflare 的服务器，绕开了中国大陆的拥堵因素，可以较准确地反映节点带宽。
检查目标服务器（段③）
如果只有特定网站速度慢（如某个视频平台），但访问其他境外网站速度正常，问题可能在目标服务器本身，而非代理节点。
第二步：换用高质量节点
这是最直接的优化方法：
- 优先选择延迟低（< 100ms）的节点：在 Clash 代理页面运行测速，按延迟排序
- 在晚高峰期切换到专线节点：IPLC/IEPL 专线节点在高峰期不受公网拥堵影响，速度更稳定
- 选择离目标服务器近的节点：
- 访问 Google/YouTube 等美国服务：日本或新加坡节点（往往比美国节点速度更好，因为亚洲与美国西海岸之间的海缆带宽充足）
- 访问 Netflix 美区：必须使用美国节点
- 访问日本服务：日本节点
第三步：调整 MTU 设置
MTU（Maximum Transmission Unit，最大传输单元）是每次网络传输可以携带的最大数据量。MTU 设置不当会导致数据包被强制分片，显著降低传输效率。
在 VPN/代理场景下，由于代理协议会在数据包上添加额外的头部信息，MTU 通常需要略微降低：
Windows 查看当前 MTU：
# 查看所有网络接口的 MTU
netsh interface ipv4 show subinterfaces
# 以太网通常为 1500，Wi-Fi 通常为 1500
调整 MTU（如遇到速度异常慢或大文件传输问题）：
# 将以太网 MTU 改为 1400（需管理员权限）
netsh interface ipv4 set subinterface "以太网" mtu=1400 store=persistent
# 恢复默认
netsh interface ipv4 set subinterface "以太网" mtu=1500 store=persistent
通常情况下，Clash 会自动处理 MTU 问题，你不需要手动调整。只有在遇到特定的大文件传输速度异常问题时，才需要考虑这个选项。
第四步：更换协议
不同的代理协议在性能、混淆开销和抗干扰能力上有所不同：
| 协议 | 性能开销 | 适合场景 |
|---|---|---|
| Shadowsocks (SS) | 低 | 轻量，速度快，但混淆弱 |
| VMess | 中 | 功能完整，广泛支持 |
| VLESS | 低 | 比 VMess 更轻量，性能稍好 |
| VLESS + Reality | 低-中 | 安全性最高，TLS 伪装完美 |
| Trojan | 低 | 伪装成 HTTPS，性能良好 |
| Hysteria2 | 中（但抗丢包） | 高丢包环境下表现最好 |
选择建议：
- 如果网络环境正常（低丢包），VLESS + Reality 或 Trojan 通常是最佳平衡点
- 如果网络丢包严重（如某些学校或公司网络），Hysteria2 基于 QUIC/UDP，有内置的丢包恢复机制，在高丢包环境下速度反而比 TCP 协议更好
- 如果追求最大下载速度，Shadowsocks 的加密开销最小，在节点带宽充足时通常可以跑满
大多数机场的订阅会包含不同协议的节点，可以在 Clash 中尝试切换并测速对比。
第五步：检查并发连接数
如果你同时下载多个文件或打开大量标签页，Clash 的并发连接可能达到上限，导致整体变慢：
在 Clash Verge Rev 的「连接」页面，可以查看当前活跃连接数。如果连接数非常多（> 200），考虑：
- 减少同时下载的任务数
- 关闭不用的浏览器标签
排查速度慢的优先级建议
按以下优先级依次尝试，通常在前几步就能解决问题：
- ✅ 换延迟更低的节点（最快见效）
- ✅ 切换到专线节点（晚高峰期尤其有效）
- ✅ 尝试不同地区的节点（不同地区与目标服务器的路由不同）
- ✅ 检查本地网络（先排除本地瓶颈）
- 🔧 切换协议（如当前协议可能有干扰）
- 🔧 调整 MTU（针对特定场景）