代理测速怎么选节点？按用途筛出主用和备用节点
简答：代理测速选节点，不要只看最低延迟：先测直连基线，再用同一测速地址比较候选节点，最后按网页、视频、下载、游戏或会议的实际用途复测。最实用的做法是“客户端延迟初筛＋速度与稳定性复测＋真实业务验收”，并在白天和晚间分别记录结果。本文是第三方使用指南，不能替代具体服务商的官方说明。
定义：代理节点测速，是在相同设备、网络、测试地址和时间条件下，比较节点的响应时间、吞吐、丢包、抖动及真实业务表现，以选择更适合当前用途的节点。
先试这一步：建立直连基线，再测代理节点
先关闭代理或切换到直连，记录一次本地网络基线：下载速度、上传速度、延迟、丢包和抖动。随后保持设备、测速工具、测速服务器和网络接入方式不变，再逐个测试候选节点。这样才能判断变慢来自节点，还是本地宽带、无线网络或测速服务器。
- 在客户端确认当前模式确实是直连，完成一次测速并记录时间。
- 选择同一批候选节点，先使用客户端自带的延迟测试，淘汰超时、反复报错或明显异常的节点。
- 对剩余节点进行下载、上传和稳定性测试。测速指标不应只看下载速度；Cloudflare 的网络质量评估也同时关注延迟、丢包、下载、上传、负载延迟和抖动。参考 Cloudflare AIM 指标说明
- 最后打开你真正要使用的网站、视频、文件下载或会议应用，确认实际体验与测速结果一致。
可观察结果：如果直连本身就出现高延迟或丢包，先处理本地网络；如果直连正常而多个节点都失败，优先检查客户端模式、订阅状态、DNS或测速地址；如果只有个别节点失败，才把节点本身列为重点排查对象。
看懂测速结果：延迟低，不等于节点最快
| 指标 | 它主要反映什么 | 选节点时怎么用 |
|---|---|---|
| 延迟 | 建立连接或完成测试请求所需的响应时间 | 适合初筛响应快的节点，但不能单独代表下载速度 |
| 下载速度 | 接收数据的能力 | 视频、文件下载和大页面加载应重点观察 |
| 上传速度 | 发送数据的能力 | 上传文件、远程办公和视频会议更需要关注 |
| 丢包 | 数据包未成功到达或返回的比例 | 丢包会造成卡顿、重传和会议断续，通常比单次低延迟更值得警惕 |
| 抖动 | 延迟在多次测量中的波动 | 实时通信、游戏和远程桌面更怕抖动大 |
| 负载延迟 | 网络有下载或上传负载时的延迟 | 用于观察测速时网络是否一忙就明显变慢 |
客户端里的“延迟测试”通常是对指定地址进行健康检查，不等同于完整带宽测试。以 mihomo 文档为例，策略组延迟接口会返回节点到测试地址的延迟值，测试地址、超时时间和预期状态码都可能影响结果。参考 mihomo API 文档
因此，低延迟节点可能仍然下载慢，也可能在高负载时延迟迅速升高。相反，某个节点的初始延迟略高，但吞吐稳定、丢包少，反而更适合视频、文件或办公。
三轮筛选流程：从批量测速到真实业务验收
第一轮：客户端延迟初筛
在当前客户端的节点或策略组页面，使用同一个健康检查地址批量测试。保留能稳定返回结果的节点，淘汰持续 Timeout、Error 或多次测试均无响应的节点。不同客户端的菜单名称可能不同，具体入口以当前版本界面为准。
如果使用 mihomo 的 URL-Test 策略组，官方文档说明它会按照测试结果选择延迟较低的节点；健康检查地址和检测间隔属于配置项，不能把自动选择结果直接当成带宽排名。参考 mihomo URL-Test 配置说明
第二轮：统一条件下复测吞吐和稳定性
- 每个候选节点至少测试三次，尽量使用中位数而不是单次最高速度。
- 测试期间不要同时下载大型文件、运行云盘同步或开启其他网络加速工具。
- 记录测试时间、节点名称、测速地址、下载、上传、延迟、丢包、抖动和是否出现断流。
- 将白天和晚间分开记录。若某节点白天很快、晚间多次超时或负载延迟明显升高，不宜直接作为唯一主用节点。
第三轮：真实业务验收
按照你的主要用途选择验收项目：网页重点看首屏打开和多页面连续访问；视频重点看清晰度切换、缓冲和持续播放；下载重点看持续速度而不是峰值；会议重点看语音连续性、画面冻结和上传表现；游戏或远程桌面重点看延迟波动与丢包。真实业务必须在代理已经生效的前提下进行。
按用途选节点：不要用同一套标准解决所有问题
| 用途 | 优先指标 | 淘汰信号 |
|---|---|---|
| 网页浏览 | 连接成功率、首屏响应、延迟 | 频繁超时、部分页面打不开、DNS解析异常 |
| 视频播放 | 持续下载速度、负载延迟、稳定性 | 清晰度反复下降、缓冲、速度峰值高但很快回落 |
| 文件下载 | 持续下载速度、丢包、连接保持能力 | 速度波动大、下载中断、重新连接频繁 |
| 在线会议 | 上传速度、抖动、丢包、持续稳定性 | 语音断续、画面冻结、负载后延迟明显升高 |
| 游戏或远程桌面 | 延迟波动、丢包、响应一致性 | 瞬时延迟尖峰、操作回弹、周期性卡顿 |
| 跨境办公 | 目标业务可达性、上下行、长时间稳定性 | 办公系统登录失败、文件同步中断或特定域名无法访问 |
表格只是筛选顺序，不是绝对阈值。不同地区、运营商、目标网站和测试时间会改变结果，所以不建议把某个固定毫秒数或固定带宽当作所有用户的合格线。
异常分流：测速结果不对时先判断是哪一层
- 只有一个节点超时：先重新测试同一地址；仍失败时暂时排除该节点，并保留测试时间和错误提示。
- 所有节点都慢，但直连也慢：优先检查无线信号、路由器、后台下载和本地运营商线路。
- 客户端显示延迟正常，但网页打不开：检查系统代理、TUN或规则是否让目标流量走了 DIRECT；再核对 DNS 解析结果。
- 测速很快，真实业务很慢：换一个测试地址并进行持续下载或实际访问，排除测速服务器与目标网站线路差异。
- 白天正常、晚间变慢：进行双时段复测，比较中位数、失败次数和负载延迟，不要只保留白天峰值最高的节点。
- 代理显示已连接但出口未变化：关闭代理做一次对照，再打开代理访问 IP 检查页面；若结果不变，重点检查规则、系统代理和 TUN 接管状态。
完成测试后建议保留一个主用节点和一个备用节点，并记录最后一次复测时间。切换客户端、网络接入方式或订阅内容后，应重新验证，单次成功不能代表长期稳定。
可直接套用的节点记录表
建议用表格记录，而不是凭印象选择：
| 节点 | 测试时段 | 延迟中位数 | 下载中位数 | 上传中位数 | 丢包/抖动 | 真实业务 | 结论 |
|---|---|---|---|---|---|---|---|
| 候选节点 A | 白天/晚间 | 填写三次结果 | 填写三次结果 | 填写三次结果 | 填写结果 | 网页/视频/办公 | 主用/备用/淘汰 |
| 候选节点 B | 白天/晚间 | 填写三次结果 | 填写三次结果 | 填写三次结果 | 填写结果 | 网页/视频/办公 | 主用/备用/淘汰 |
最终排序建议按用途决定：实时业务优先稳定性、抖动和丢包；视频与下载优先持续吞吐；网页与办公则同时看可达性、响应时间和长时间连接表现。
补充说明：测速工具和客户端结果为什么会不同
网页测速通常会选择特定测速服务器，并通过较大数据量估算吞吐；客户端健康检查则更接近“这个节点能否快速完成一次连接测试”。两者测试对象、路径和负载不同，结果不一致并不一定表示某一方错误。
如果客户端支持健康检查地址、超时时间或预期状态码，应先确认这些字段是否被当前版本支持，再进行对比。官方 mihomo 文档列出了健康检查地址、间隔、超时和预期状态码等配置项，建议以当前客户端和内核文档为准，不要直接复制其他版本的配置。参考 mihomo 健康检查配置说明
常见问题
代理测速时，Ping 越低就越应该选吗？
不一定。Ping或客户端延迟主要适合做响应速度初筛，不能代表下载、上传、丢包、抖动和高负载表现。应至少结合三次复测和一次真实业务验收。
每个代理节点应该测速几次？
建议每个候选节点至少测试三次，并记录中位数；主用节点还应在白天和晚间各复测一次。若结果波动很大，应把稳定性和失败次数纳入判断，而不是取最高速度。
客户端显示节点延迟正常，但实际网页很慢怎么办？
先确认网页流量确实经过所选节点，再检查规则是否误走直连、DNS是否异常，以及测速地址与目标网站是否不在同一网络路径。随后用持续访问或文件下载做对照。
为什么同一个节点在不同测速网站上的速度不同？
测速服务器位置、连接协议、并发连接数、测试时间和目标路径可能不同。应固定工具、服务器和时间进行横向比较，不要把不同条件下的结果直接排名。
晚间速度变慢，应该换地区还是换节点？
先在同一时间段复测多个节点。如果只有某几个节点变慢，优先更换节点；如果所有节点和直连都变慢，应先排查本地网络或接入线路。没有复测证据时，不宜直接归因于某个地区。