代理节点怎么选择速度快的？三轮测试筛出主用节点
简答：代理节点想选得快，先淘汰超时和不稳定节点，再在相同网络条件下比较延迟、持续吞吐、丢包和真实访问体验。最低延迟不等于网页、视频或下载速度最快，最终应按你的实际用途保留一个主用节点和一个备用节点。
定义：代理节点选择，是在固定设备、网络、测试地址和时间条件下，对多个节点进行连通性、延迟、持续速度、稳定性与实际业务体验对比，再选择最适合当前用途的节点。
先试这一步：三轮筛选表
本文是第三方使用指南，不代表任何客户端或节点服务商的官方说明。你可以先把节点名称、地区、延迟、测试结果和实际体验记在表格中，不要根据单次测速或名称直接下结论。
| 轮次 | 主要目标 | 操作 | 淘汰或保留标准 |
|---|---|---|---|
| 第一轮：可用性 | 排除明显不可用节点 | 在客户端逐个发起健康检查或访问同一个测试页面 | 连续超时、频繁失败、无法完成握手的节点先淘汰 |
| 第二轮：性能 | 比较延迟、速度和波动 | 同一设备、同一网络、相近时间重复测试至少数次 | 不要只看最低延迟，优先保留结果稳定、波动较小的节点 |
| 第三轮：真实体验 | 确认是否适合你的用途 | 用实际网页、视频、文件下载或会议任务验证 | 能稳定完成目标任务的节点，才进入主用候选 |
关键判据：测速请求必须确实经过所选代理节点。如果客户端处于规则模式，先确认目标域名命中了代理策略，而不是被 DIRECT 直连；如果使用 Mihomo 的 url-test 策略组，其官方示例说明该组会根据测试 URL 的结果选择延迟较低的节点，但这仍不等于真实下载或视频体验一定最好。Mihomo 官方配置示例 github.com
“速度快”到底看什么：按用途选择指标
代理节点的速度不是一个单独数字，至少要拆成连通性、响应延迟、持续吞吐、丢包、抖动和稳定性。网页首次打开通常更容易受到 DNS、TCP/TLS 建连和服务器响应时间影响；MDN 将 TTFB 定义为浏览器发起请求到收到第一个字节之间的时间，并指出其中可能包含 DNS、TCP 与 TLS 建立过程。MDN：Time to First Byte developer.mozilla.org
| 使用场景 | 优先观察 | 不要单独依据 |
|---|---|---|
| 网页浏览 | 首字节时间、页面打开成功率、连续访问稳定性 | 节点名称中的地区或单次 Ping |
| 视频播放 | 持续吞吐、缓冲情况、晚高峰稳定性 | 只看连接建立时的最低延迟 |
| 文件下载 | 持续下载速度、速度波动、长时间连接是否中断 | 短时间测速中的瞬时峰值 |
| 在线会议或语音 | 延迟、丢包、抖动和持续稳定性 | 只看下载速度 |
| 互动操作 | 响应延迟、丢包、连接成功率 | 只看理论带宽 |
如果需要在自有服务器或可控测试端之间测量链路吞吐，iPerf3 官方资料说明它可用于测量 IP 网络的最大可达带宽，并报告带宽、丢包等参数；但普通用户通常无法对公共代理节点直接运行这类测试，因此不要把某个 iPerf 结果套用到所有节点。iPerf 官方文档 iperf.fr
四步完成一次可复现的节点对比
- 固定测试条件。使用同一台设备、同一个客户端、同一个本地网络和同一组测试地址。测试时暂停云盘同步、系统更新和其他大流量任务；家庭宽带、移动热点、公共 Wi-Fi 应分别记录，不能混在一张排名表里。
- 第一轮只看能否稳定连通。逐个节点测试同一地址，记录成功、超时、连接被拒绝或中途断开。连续失败的节点先移出候选，不要因为它显示了很低的延迟就继续保留。
- 第二轮做重复测试。在相近时间对候选节点重复测试，记录每次延迟、持续速度、失败情况和波动。建议使用中位数或“成功次数/总次数”记录，而不是只保存最高速度。
- 第三轮做真实业务验收。用你真正需要的任务测试，例如连续打开多个网页、播放一段视频、下载较大的公开文件或进行一段会议通话。记录首屏等待、缓冲、断流和重连情况，再确定主用与备用节点。
成功判据：节点能够完成你的目标任务，测试结果在重复测试中没有明显失控，并且代理路径确实命中该节点。失败分支：如果所有节点都失败，先检查本地网络、客户端端口、系统代理、DNS 和配置是否生效；如果只有某个节点失败，再单独核对该节点参数或服务端状态。回滚方法：保留原先可用的节点或策略组，不要一次性删除全部候选；更换配置前先导出当前配置或记录原设置。
建议使用的评分记录模板
下面的评分不是行业统一标准，而是便于个人比较的记录方法。不要把分数理解为服务商排名，也不要跨不同网络环境直接比较。
| 节点 | 连通成功率 | 延迟中位数 | 速度中位数 | 波动/丢包 | 真实业务 | 结论 |
|---|---|---|---|---|---|---|
| 节点 A | __/__ | __ ms | __ Mbps | 低/中/高 | 网页/视频/下载/会议 | 主用/备用/淘汰 |
| 节点 B | __/__ | __ ms | __ Mbps | 低/中/高 | 网页/视频/下载/会议 | 主用/备用/淘汰 |
| 节点 C | __/__ | __ ms | __ Mbps | 低/中/高 | 网页/视频/下载/会议 | 主用/备用/淘汰 |
如果你主要浏览网页，可以提高对首屏响应和成功率的重视；如果主要下载或播放视频，则应提高对持续吞吐和长连接稳定性的重视；如果主要会议或语音，则应优先观察丢包、抖动和断线，而不是追求最高下载速度。
地区、出口 IP、倍率和协议怎么判断
- 地区标签：只能作为初筛信息，不能代替实测。节点标注的入口地区、服务器所在地区和最终出口 IP 可能不是同一个概念，实际使用前应在客户端或目标服务中核对出口位置。
- 出口 IP：如果某个网站、办公系统或 API 对地区敏感，应单独验证实际出口，而不是根据节点名称推断。
- 流量倍率：倍率影响资源消耗或套餐计算方式，具体规则必须以对应服务的已核实说明为准。没有明确资料时，不要据此推算实际速度。
- 协议兼容性：协议必须同时得到客户端、内核和节点配置支持。出现“节点能测速但业务失败”时，应检查协议参数、UDP/TCP 需求、TLS 设置和客户端版本适配，不要仅凭协议名称判断快慢。
测速结果很快，但实际使用很慢怎么办
- 确认测速地址和实际访问目标不是直连，检查规则命中情况与当前策略组。
- 分别测试网页首屏、持续下载和视频播放，判断是建连慢、吞吐不足还是长连接不稳定。
- 更换测试时间，尤其在本地网络繁忙时重新记录；同一节点的表现会受到本地网络、目标站点和时段影响。
- 检查 DNS、MTU、系统代理和客户端 TUN 设置是否改变了实际路径。每次只修改一项，并保留回滚设置。
- 如果只有一个网站或一个办公系统打不开，先比较其他目标是否正常，不要直接认定整个节点不可用。
四个常见问题
代理节点延迟最低，就是速度最快吗？
不一定。延迟主要反映请求往返或建连响应，下载和视频还需要观察持续吞吐、丢包、抖动与长连接稳定性。应以实际用途做第三轮验收。
应该优先选哪个地区的节点？
没有脱离用途和网络环境的固定答案。地区标签只能初筛，最终要结合目标服务的出口要求、真实访问成功率和重复测试结果判断。
为什么客户端自动选择的节点，实际体验不一定最好？
自动选择通常依赖特定测试地址和测试方法。例如 Mihomo 的 url-test 会依据测试 URL 选择延迟较低的节点，但该测试不一定覆盖你的网页、视频、下载或会议场景，因此仍应进行真实业务验收。
所有节点都超时，应该先换节点吗？
不建议立刻全部更换。先检查本地网络是否正常、客户端入站端口是否监听、系统代理是否指向正确端口、DNS 是否可解析，以及配置是否已生效；如果本地链路或配置有问题，换节点通常不能解决。
常见问题
代理节点延迟最低，就是速度最快吗？
不一定。延迟不能代表持续下载速度、视频缓冲表现或长连接稳定性，最终要按实际使用场景复测。
测速时怎样避免结果被直连影响？
确认客户端规则命中了代理策略，而不是 DIRECT；同时查看当前策略组、连接日志或请求路径，必要时用实际目标业务进行验收。
为什么自动选择的节点不一定最好用？
自动选择通常依据特定测试地址和单一指标，可能偏向低延迟节点，但未必代表你的网页、视频、下载或会议体验最佳。
所有节点都超时，应该先换节点吗？
先检查本地网络、客户端端口、系统代理、DNS 和配置是否生效，再判断是全部节点问题还是本机路径问题。
相关阅读
参考资料
- MDN：Time to First Byte
- MDN：Understanding latency
- Mihomo 官方配置示例：url-test 与健康检查
- iPerf 官方文档：带宽、丢包与网络测量（iperf.fr）