代理速度慢怎么排查？先分清本地、节点还是目标网站
简答：代理速度慢先不要盲目换节点：关闭代理做基线，再用同一目标连续对比直连、单节点、不同节点和不同时段，最后检查 DNS、分流、TUN、路由及并发。
定义：代理速度慢是指请求在延迟、连接建立、首字节、持续传输、丢包或超时中的一个或多个环节明显变差，不能只用一次测速结果判断。
先做这组对比：15分钟内判断慢在哪一段
本文为第三方使用指南，与相关项目及开发者无隶属关系。更新日期：2026年10月24日。先记录同一设备、同一目标、同一时间下的结果，不要同时更换客户端、节点、协议和 DNS，否则无法判断是哪一个变量产生影响。
| 现象 | 优先怀疑 | 先做的动作 | 判定思路 |
|---|---|---|---|
| 直连和代理都慢 | 本地网络、Wi-Fi、DNS或目标站点 | 关闭代理，连续访问同一目标 | 直连也慢时，不要先归因于节点 |
| 只有一个节点慢 | 单节点、出口或该节点路径 | 保持目标不变，换同地区节点 | 其他节点正常时，问题可能集中在单节点 |
| 所有节点都慢、直连正常 | 客户端模式、代理入口、线路或服务侧 | 检查系统代理、TUN、分流和 DNS | 多个节点在同一时段都异常，才考虑共同链路 |
| 只有一个网站慢 | 目标站点、CDN、出口策略或接口限流 | 换两个不同目标交叉测试 | 其他网站正常时，不宜直接判定代理整体变慢 |
命令行测试建议使用稳定、允许测试的目标域名；下面的 example.com 只是示例域名，请替换为你有权访问且实际变慢的目标。
第一步：关闭代理，建立本地网络基线
先完全关闭客户端的系统代理和 TUN，再用浏览器访问同一目标，或在命令行执行：curl -I -L --connect-timeout 10 --max-time 30 https://example.com/。这里的 example.com 请替换为实际目标。
如果需要拆分 DNS、TCP、TLS、首字节和总耗时，可执行：curl -sS -o /dev/null -L --connect-timeout 10 --max-time 30 -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total} code=%{http_code}\n" https://example.com/。根据 curl 官方命令文档，这些字段分别对应名称解析、TCP连接、TLS握手、收到首字节和完整操作耗时。
判定方法：连续执行至少3次，记录中位数。若 dns 明显高，先查 DNS；若 connect 或 tls 高，重点查代理入口、路由或握手；若 first_byte 高而前面正常，可能是目标站处理、出口策略或应用层等待；若 total 高但首字节正常，重点看持续传输、丢包、限速或下载端。
注意：HTTP 状态码不是测速值。RFC 9110 将 4xx 定义为客户端错误类、5xx 定义为服务器未能完成有效请求；因此出现 403、429、502、503 或 504 时，应先记录状态码和响应时间，不要把它们直接当成“线路速度慢”。
第二步：用同一目标对比节点、地区和时段
保持客户端、目标网站、测试设备和测试时间不变，只改变一个变量。建议按“直连→节点A→节点B→同地区节点→不同地区节点”的顺序测试，每个结果至少记录3次。记录表可以包含：时间、连接方式、节点地区、延迟、首字节、总耗时、状态码、是否超时、备注。
| 实验 | 只改变的变量 | 看什么 | 下一步 |
|---|---|---|---|
| A | 直连与代理 | 首字节、总耗时、失败率 | 直连慢则先排本地和目标站 |
| B | 同地区不同节点 | 节点间差异是否稳定 | 单节点异常时保留证据并更换节点 |
| C | 不同地区节点 | 延迟与首字节是否随出口变化 | 差异明显时检查出口位置与目标站响应 |
| D | 不同时段 | 高峰与非高峰的中位数、超时率 | 仅时段性变慢时记录时间窗口，不要只看单次测速 |
如果只是视频卡顿，要额外观察持续下载是否稳定；如果是网页首屏慢，优先看 DNS、连接和首字节；如果是接口超时，记录失败率、响应码、重试次数和并发量。不要把浏览器页面加载时间、单文件下载速度和 API 响应时间混为同一种指标。
第三步：检查客户端模式、分流、TUN和双重代理
确认流量是否真的经过预期代理。浏览器代理、系统代理和 TUN 的覆盖范围不同，可能出现“浏览器变慢但其他应用正常”或“浏览器正常、接口仍超时”的情况。
- 检查系统代理：确认代理地址、端口和协议与客户端当前监听设置一致；改完后关闭并重新打开测试应用。
- 检查分流规则：确认目标域名没有被误判为
DIRECT、错误策略组或不存在的策略组。使用规则模式时，同一目标应固定在同一策略下测试。 - 检查 TUN：如果开启 TUN，暂时关闭它做一次对照；如果关闭后恢复，重点排查路由、DNS 劫持、网卡优先级和 MTU，而不是继续换节点。
- 排除双重代理：检查浏览器扩展、系统代理、容器环境变量和应用自身代理设置，避免请求经过两层代理。
- 检查 IPv4 与 IPv6：在同一客户端中分别进行 IPv4 和 IPv6 对照；某一协议族失败或明显变慢时，再针对 DNS 和路由处理。
判断标准是：只改一个开关，连续测试同一目标至少3次；如果结果恢复，应记录“关闭了什么、哪类流量恢复、是否影响其他应用”，不要同时修改多个设置。
第四步：检查 DNS、路由和丢包
Windows 可先执行 ipconfig /all 查看地址、默认网关和 DNS，再用 nslookup example.com 检查名称解析；必要时执行 ipconfig /flushdns 清理本机 DNS 缓存。Microsoft 的 ipconfig 官方文档说明了 /all、/displaydns 和 /flushdns 的用途；Microsoft DNS 客户端排查文档也建议核对 IP、网关、DNS 服务器并使用 nslookup 测试解析。
Windows 可用 ping example.com 做基础连通性观察，再执行 tracert -d example.com 查看路径。Microsoft TRACERT 文档说明，TRACERT 通过不同 TTL 观察返回的中间路由；但某些路由器可能丢弃过期 TTL 报文，所以单个中间节点出现星号，不足以证明该节点就是故障点。
判定时看终点和连续多次结果：如果前几跳就持续超时且直连也异常，优先检查本地网络；如果只在代理模式下出现高延迟或超时，比较不同节点和不同协议；如果中间跳点高但终点稳定，不要仅凭中间跳点下结论。
第五步：按症状采取修复动作
- 延迟高：先确认目标是否固定，再比较同地区和不同地区节点；不要只看客户端显示的延迟，因为端到端请求还包含 DNS、连接、TLS 和目标站处理。
- 下载速度低：关闭后台下载和多余并发，使用同一文件或同一目标做连续对照；若首字节正常但后续传输慢，重点检查持续丢包、出口限速或目标站限速。
- 网页首屏慢：优先查看
time_namelookup、time_connect、time_appconnect和time_starttransfer，不要只用 ping 代替 HTTP 测试。 - 视频卡顿：分别测试网页加载和持续播放；降低并发下载，确认是否只有特定清晰度、特定时间段或特定目标卡顿。
- 接口超时：记录 HTTP 状态码、超时阶段和重试次数。429 表示请求过多，依据 RFC 6585 应降低请求频率并遵守可能返回的
Retry-After；403 表示服务器拒绝请求，重复发送相同请求通常不能解决权限或策略问题。 - 所有节点长期异常：保留同一目标、同一时间、多个节点的记录，再联系服务维护方核查；若无法稳定复现，不要把一次失败或一次测速写成线路结论。
记录模板：把“感觉变慢”变成可复核证据
可以复制下面字段到表格中：日期时间｜设备｜网络类型｜客户端模式｜目标域名｜直连/代理｜节点地区｜DNS耗时｜TCP连接耗时｜TLS耗时｜首字节耗时｜总耗时｜HTTP状态码｜超时次数｜备注。
建议至少保留三组对照：直连基线、一个稳定节点、一个待验证节点；每组连续3次以上，并记录中位数而不是只记录最快值。若要判断高峰影响，至少选择两个不同时间段重复同一组实验。没有统一目标、统一时间和重复次数时，只能说“本次观察变慢”，不能据此断言某条线路一定故障。
截至2026年10月24日，本文未对任何具体服务商、节点价格、可用性或测速排名作结论；具体服务状态应以相关服务方公开信息和实际复测为准。
常见问题
代理速度慢时，应该先换节点还是先关代理？
先关闭代理做本地基线，再用同一目标连续测试。直连也慢时，先查 Wi-Fi、DNS、设备和目标站；直连正常而单节点慢，再换同地区节点。
Ping 延迟正常，为什么网页还是加载慢？
Ping 只观察 ICMP 往返，不能代替完整 HTTP 请求。网页还可能慢在 DNS、TCP、TLS、首字节等待、重定向、目标站处理或持续传输，应使用 curl 的分阶段耗时字段复测。
多个节点同时变慢，是不是线路一定拥堵？
不能直接确定。共同变慢也可能来自本地网络、客户端模式、DNS、TUN、目标站或测试方法。应先做直连对照，再比较不同目标和不同时段。
出现 403 或 429 时，继续换节点有用吗？
未必。403 是服务器拒绝请求，429 通常与请求频率或限流有关。应先降低频率、检查认证和请求方式，并记录响应头及 Retry-After；不要把状态码直接当作带宽不足。
什么时候应该联系服务维护方？
当直连正常、多个节点和多个目标在同一时段持续异常，并且你已排除系统代理、TUN、DNS、双重代理和本地丢包时，整理记录表、时间、节点、目标和错误信息后再反馈。