代理测速怎么测哪个节点速度快？
简答：想找速度快的代理节点，不要只按Ping排序。先关闭下载和云同步，记录直连基准；然后确认客户端流量确实经过代理，统一测试地址和时间，分别比较延迟、下载速度、上传速度、抖动、丢包与失败率；最后用实际网页、视频或文件下载复测，选择表现稳定的节点，而不是只看一次峰值。
定义：代理节点测速，是在相同设备、网络、测试地址和时间条件下，比较不同节点的响应、吞吐、稳定性与真实业务体验。
先用这张表判断：不同用途该看什么指标
本文为第三方使用指南，适用于支持节点延迟测试、代理切换或测速的客户端。Clash Verge Rev、v2rayN、Shadowrocket 等客户端的按钮名称可能不同，但筛选逻辑相同：先确认代理生效，再进行多指标对比。
| 使用场景 | 优先观察 | 不要单独依据 | 最终验证 |
|---|---|---|---|
| 网页浏览 | 延迟、连接成功率、首屏打开速度 | 一次Ping最低 | 连续打开几个常用网页 |
| 视频播放 | 下载吞吐、负载延迟、持续稳定性 | 瞬时峰值速度 | 播放视频并观察缓冲和清晰度切换 |
| 文件下载 | 持续下载速度、失败率、速度波动 | 客户端显示的单次速度 | 使用同一文件或同类资源下载 |
| 在线会议或语音 | 抖动、丢包、负载延迟 | 只看下载带宽 | 进行实际通话并观察断续情况 |
| 远程办公 | 连接成功率、延迟稳定性、上传速度 | 只看节点地区 | 访问办公系统并上传、下载小文件 |
Cloudflare 的网络质量资料将下载、上传、延迟、抖动和丢包分别作为网络质量指标；其中，单纯的下载带宽不能完整代表网页、视频会议或实时交互体验。可参考 Cloudflare 对网络质量指标的说明。
代理节点测速的最短操作流程
- 准备测试环境。暂停正在进行的下载、云盘同步、系统更新和视频播放，尽量固定使用同一台设备、同一个网络连接。若使用无线网络，测试期间不要频繁切换接入点。停止条件：如果直连网络本身已经明显波动，先处理本地网络，不要直接把问题归因于节点。
- 记录直连基准。关闭客户端代理或切换到直连，使用同一个测速工具记录下载、上传、延迟、抖动和丢包。Cloudflare 官方说明中，Speed Test 可用于观察下载、上传、延迟、抖动和丢包等结果；它更适合做网络基准，不等于某个代理节点的最终表现。参考 Cloudflare 测试网络速度文档。
- 确认测试流量确实经过代理。打开客户端的代理模式，选中待测节点，再检查出口IP或客户端日志是否发生变化。浏览器能打开网页，只能说明当前请求成功，不能证明所有应用都走了代理；系统代理、规则模式和TUN模式可能影响不同程序的流量路径。停止条件：如果无法确认流量经过节点，先不要记录速度结果。
- 先做客户端延迟测试。对候选节点使用同一个测试地址批量测试。延迟测试通常是通过代理请求测试地址并记录响应耗时，适合初步排除超时或明显无响应节点，但它主要反映连通性和响应速度，不能代表持续下载速度。以 Clash Verge Rev 为例，其项目代码显示延迟测试支持统一测试地址，也允许使用自定义测试地址；具体界面以当前版本为准，参考 Clash Verge Rev 项目代码。
- 对剩余节点做吞吐和真实业务复测。使用同一个测速工具、相近测试时间和相同测试区域，分别记录下载、上传和稳定性。再用实际网页、视频或文件下载做验收。每个节点至少重复测试2至3次，记录中位数或大致稳定区间，不要只保留一次最高值。若白天和晚间结果差异明显，应把晚间表现纳入主用节点判断。
推荐的记录字段为：节点名称、测试时间、测试工具、延迟、下载、上传、抖动、丢包、是否超时、真实业务结果和备注。这样可以区分“偶尔很快”和“长期可用”。
怎么从测速结果中选出主用节点
不要把所有指标简单相加，也不要预设一个适用于所有人的固定数值。更稳妥的做法是先按用途排序，再用失败率和波动情况淘汰节点。
- 第一轮：淘汰连通性差的节点。出现多次超时、无法建立连接、请求失败或明显丢包的节点，不进入下一轮。单次失败可能来自临时网络波动，因此应复测确认。
- 第二轮：按场景比较。网页优先看响应速度和打开成功率；视频与下载优先看持续下载表现；会议和语音优先看抖动、丢包以及负载下的延迟。不同用途可能会选出不同节点。
- 第三轮：观察波动。如果某节点第一次速度很高，后两次明显下降，或者白天正常、晚间频繁超时，应标记为不稳定，而不是直接选为主用。
- 第四轮：保留备用节点。至少保留一个在不同时间段表现较稳定的备用节点。备用节点不是测速最高的节点，而是当主用节点连接失败或明显变慢时，可以快速切换的节点。
Cloudflare 文档也将“负载下延迟”、抖动和丢包作为判断网络质量的重要维度；因此，下载速度高但负载延迟和丢包明显的节点，未必适合会议、远程桌面或实时应用。可参考 Cloudflare Speed Test 指标说明。
| 结果现象 | 可能含义 | 下一步 |
|---|---|---|
| 延迟低，但下载很慢 | 节点响应快，持续吞吐不足，或测试区域不匹配 | 统一测试区域并做固定文件下载 |
| 下载很高，但网页打开慢 | 连接建立、DNS、规则或单个目标站点存在差异 | 检查代理模式、DNS和真实网页打开时间 |
| 测速正常，视频仍缓冲 | 测速服务器与视频业务路径不同 | 用实际视频场景复测，观察持续吞吐 |
| 所有节点都慢 | 本地网络、系统代理、客户端核心或测试时段可能有问题 | 先重测直连，再检查客户端日志和代理模式 |
| 白天快、晚间慢 | 链路或节点在特定时段负载升高 | 把晚间结果纳入主用节点选择 |
测速时最容易出现的误判
- 把直连速度当成代理速度。测速网页打开了，不代表测速请求经过当前节点。必须先确认客户端模式、出口IP或日志。
- 把延迟当成网速。延迟是请求响应的时间，下载速度是数据传输能力，两者有关但不是同一指标。低延迟节点可能不适合大文件下载。
- 只测一次就下结论。测速结果会受到本地网络、测试服务器、时间段和节点负载影响，单次峰值只能作为线索。
- 混用不同测试条件。如果节点A用一个测试区域，节点B用另一个测试区域，结果不能直接横向比较。
- 忽略代理模式差异。规则模式可能只代理部分请求，全局模式或TUN模式的流量范围也可能不同。测试前应明确自己要验证的是浏览器、单个应用还是整台设备。
- 把浏览器可用当成全部应用可用。浏览器能访问网页，不代表会议软件、命令行、游戏或其他应用也使用了相同代理路径。
如果结果异常，先回滚到直连或上一次确认可用的配置，再逐项恢复代理模式、节点和DNS设置。这样可以判断问题来自节点、客户端配置还是本地网络。
一份可直接复制的测速记录模板
可以把下面字段复制到表格或备忘录中，每个节点填写一行：
| 节点 | 时间 | 延迟 | 下载 | 上传 | 抖动 | 丢包 | 是否超时 | 真实业务 | 结论 |
|---|---|---|---|---|---|---|---|---|---|
| 节点A | 上午/晚间 | 记录结果 | 记录结果 | 记录结果 | 记录结果 | 记录结果 | 是/否 | 网页/视频/下载 | 主用/备用/淘汰 |
| 节点B | 上午/晚间 | 记录结果 | 记录结果 | 记录结果 | 记录结果 | 记录结果 | 是/否 | 网页/视频/下载 | 主用/备用/淘汰 |
最终结论建议写成“适合什么场景”，例如“网页响应稳定”“下载速度较好但晚间波动”“适合备用，不适合长时间视频”，不要只写“最快”。
常见问题
代理测速时，Ping最低的节点就是最快吗？
不是。Ping或客户端延迟测试主要反映请求响应速度和连通性，不能代表持续下载、上传、视频播放或会议质量。应在相同条件下继续比较吞吐、抖动、丢包和真实业务表现。
为什么测速网站显示很快，但实际打开网页很慢？
可能是测速请求没有经过代理，也可能是测速服务器与目标网页的网络路径不同。先检查客户端代理模式和出口IP，再用实际网页测试，并确认DNS、规则和TUN设置没有把请求分流到直连。
代理节点测速应该测几次？
建议每个候选节点至少测试2至3次，并记录大致稳定区间或中位数；如果需要长期使用，还应在不同时间段复测。单次最高速度不适合作为唯一选择依据。
测速时应该使用哪个工具？
没有一个工具能覆盖所有场景。客户端延迟测试适合初筛；通用测速工具适合比较下载、上传和网络质量；固定文件下载与真实网页、视频测试适合最终验收。关键是保持测试地址、时间和设备条件一致。
所有节点都很慢，应该先换节点还是检查网络？
先测直连网络。如果直连也慢或抖动明显，应先检查本地Wi-Fi、路由器、带宽占用和系统网络；如果直连正常而所有节点都慢，再检查客户端代理模式、DNS、核心日志和测试时段。