代理节点测速怎么选最快的节点？
简答：最快的节点不是延迟最低的节点，而是在你的目标地区、使用时间和具体业务下，延迟较低、丢包少、速度稳定且实际访问正常的节点。先确认测速流量确实经过代理，再做延迟初筛、吞吐复测和真实业务验收；至少记录多次结果，最后按用途选择主用节点，而不是照抄一次测速的峰值。本文只讲通用节点测速与选择，不提供任何具体服务商的价格、可用性或性能结论。
定义：代理节点测速，是通过健康检查、延迟测试、下载或上传测试以及实际业务访问，比较不同节点连接质量的过程。
先试这一步：确认测速没有走直连
很多“节点测速很快但网页仍然打不开”的问题，第一原因不是节点一定有故障，而是测速请求可能没有经过当前代理。浏览器启用代理、系统代理生效、客户端显示已连接，分别只能证明不同层级的状态，不能互相替代。
- 先选定一个节点。不要同时开启自动切换、多个代理组或其他网络工具，避免测试过程中出口发生变化。
- 访问一个能显示出口信息的页面。记录页面显示的公网出口、地区或网络运营商信息；关闭代理后再次访问，确认两次结果确实不同。若两次完全相同，先不要记录测速成绩。
- 再进行延迟或下载测试。客户端的延迟测试、命令行请求或测速工具，都要在同一个代理状态下完成。Clash Verge Rev 的公开隐私说明写明，用户发起的代理测试会通过所选代理向测试地址发送 HTTP 请求；这说明“测试请求是否经过代理”需要结合客户端实现确认，而不是只看界面上的数字。可查看项目公开说明。
停止条件：如果出口信息没有变化、客户端日志显示直连，或测试过程中节点自动切换，先修正代理模式和规则，再开始记录。浏览器能打开网页不等于测速一定走代理。
三轮测速流程：先排除，再复测，最后验收
第一轮：批量延迟测试，只用于初筛
在客户端的节点或代理组页面执行批量延迟测试，先剔除超时、连续失败和延迟明显偏高的节点。延迟测试通常是向指定测试地址发出健康检查请求，测得的是请求往返耗时，不是下载速度。mihomo 文档将代理组中的 url 定义为健康检查测试地址，并将 interval 定义为定时测试间隔；其 API 也将单节点测试结果定义为毫秒级延迟。可参考代理组配置文档和API 文档。
第一轮不要急着选最低数字。建议保留一组候选节点，例如延迟较低、没有超时、所在地区符合目标业务的节点。这里的“保留”只是编辑建议，不是客户端或官方规定的固定数量。
第二轮：统一条件测试下载、上传和重复性
对第一轮留下的节点使用同一个测速工具、同一个测速服务器和同一台设备。测速服务器位置会影响结果：距离、运营商互联和当时的拥塞都会改变速度，因此不要拿不同服务器的结果直接横向比较。
每个节点至少做多次测试，并记录中位数而不是只看最高峰值。可采用“连续测试几次、间隔几十秒、白天和晚高峰各测一次”的低风险方法；具体次数和间隔属于实操建议，不代表所有网络环境都适用。测试期间不要同时下载大型文件、开启云同步或切换 Wi-Fi 与有线网络。
记录以下项目：
- 延迟：适合判断交互响应和初步连通性，不能单独代表带宽。
- 下载速度：更接近视频播放、文件下载和网页资源加载表现，但会受到测速服务器和本地带宽上限影响。
- 上传速度：视频会议、远程办公、文件上传和直播场景更需要关注。
- 抖动：反映延迟波动。平均延迟不高但波动很大，实际交互仍可能卡顿。
- 丢包：表示部分数据没有按预期到达。丢包可能来自本地 Wi-Fi、运营商链路、节点出口或测试服务器，不能仅凭一次结果确定责任方。
- 晚高峰表现：用于识别只在某个时间段表现较好的节点。
第三轮：用真实业务验收，不用测速峰值下结论
最后让候选节点分别执行你真正要做的事情，例如打开常用网页、播放一段固定清晰度的视频、进行一次视频会议、上传一个非敏感的小文件，或访问工作中必须使用的服务。每次只改变节点，其他条件保持一致。
验收时观察：页面是否持续加载、视频是否频繁降画质、会议是否出现声音断续、文件是否中途停滞、连接是否会自动切换。真实业务验收只能说明该节点在这一次条件下的表现，不能推出长期稳定性，也不能替代后续复测。
节点记录表与综合评分：先按用途，再看总分
可以把测速结果整理成下面的表格。表中的“评分”不是某个平台的官方算法，而是一种方便个人比较的记录方法；如果你更重视稳定性，可以降低速度项权重，提高丢包、抖动和晚高峰项权重。
| 节点 | 延迟中位数 | 下载中位数 | 上传中位数 | 丢包/超时 | 晚高峰 | 实际业务 | 结论 |
|---|---|---|---|---|---|---|---|
| 节点 A | 记录多次中位数 | 记录多次中位数 | 记录多次中位数 | 记录失败次数 | 正常/变慢 | 网页、视频或办公结果 | 主用/备用/淘汰 |
| 节点 B | 记录多次中位数 | 记录多次中位数 | 记录多次中位数 | 记录失败次数 | 正常/变慢 | 网页、视频或办公结果 | 主用/备用/淘汰 |
如果需要一个简单的内部排序方法，可以先把每项转成 0 到 100 分，再按用途加权：
- 网页和 AI 交互：优先延迟、抖动、丢包和实际响应，速度只要达到可用水平即可。
- 视频播放：优先持续下载速度、晚高峰表现和丢包，不能只看瞬时峰值。
- 视频会议和跨境办公：优先上传、抖动、丢包和连续稳定性。
- 大文件下载：优先下载中位数、持续时间和晚高峰表现。
- 对实时交互敏感的业务：优先低波动和低丢包，不要单纯追求最低延迟。
更实用的选择规则是：先淘汰有超时或明显丢包的节点，再从剩余节点中选择与目标业务最匹配者。这通常比把所有指标简单相加更稳妥，因为一次严重失败可能比几项普通优势更影响使用。
自动选择和手动固定：什么时候用哪一种
支持健康检查的客户端通常可以建立自动测试组，也可以手动固定一个节点。mihomo 的 url-test 类型用于根据健康检查结果选择节点，interval 控制检查间隔，tolerance 表示节点切换容差；这些字段应以当前核心文档和客户端实际支持情况为准，可查看url-test 配置说明。
| 方式 | 适合场景 | 优点 | 注意事项 |
|---|---|---|---|
| 自动选择 | 网页浏览、一般访问、节点质量变化较明显 | 减少手动切换 | 测试地址不等于真实业务，节点可能因短时波动频繁变化 |
| 手动固定 | 视频会议、远程办公、固定出口或需要保持会话 | 连接路径更可控 | 要在白天和晚高峰重新验证，变慢后再切换 |
| 自动选择加备用节点 | 希望兼顾便利和可控性 | 平时自动，异常时可手动接管 | 要记录当前实际使用节点，避免误以为测试组等于固定节点 |
回滚方法：如果开启自动选择后网页反复断开，先切回原来的手动节点或默认代理组，暂停自动切换，再重新测试。不要一次修改测速地址、规则、DNS、TUN 和节点组，否则无法判断是哪项变化造成影响。
按现象分流：测速结果异常时先查哪一层
- 所有节点都超时：先检查本地网络、客户端核心是否运行、系统代理或 TUN 是否生效，再确认测试地址是否可访问。不要立即得出“所有节点失效”的结论。
- 延迟低但网页慢：重点检查下载速度、丢包、抖动、规则是否把目标网站直连，以及网页是否包含多个不同域名资源。
- 测速很快但视频卡：复测时固定视频清晰度和节点，观察持续下载能力、晚高峰表现和实际出口是否变化。
- 只有一个网站慢：先用同一节点访问其他网站，再检查该网站的规则命中、DNS 解析和服务端响应。单站点异常不能直接证明节点整体变慢。
- 节点不断自动切换：先临时固定节点，观察实际业务是否恢复；如果恢复，再检查自动组的测试地址、检查间隔和切换容差。
每次只改一项并保留原设置，能让排查结果更容易复现。测试流量也可能消耗本地宽带或服务额度，批量测速前应确认客户端和订阅服务的相关限制；无法核实的具体额度不要按猜测填写。
常见问题
代理节点测速是不是只看 Ping 越低越好？
不是。Ping 或延迟只反映测试请求的往返时间，不能代表下载、上传、丢包、抖动和晚高峰表现。应先用延迟做初筛，再用吞吐和真实业务复测。
为什么测速显示很快，实际看视频还是卡？
可能是测速服务器距离更近、测速只反映短时峰值、晚高峰拥塞、视频业务命中了不同规则，或实际连接发生了节点切换。建议固定节点、固定视频清晰度，在相同时间条件下重新测试。
节点测速时怎样确认没有走直连？
先固定一个节点，分别在代理开启和关闭时查看出口信息或地区结果；如果结果没有明显变化，再检查规则、系统代理或 TUN 状态。只有确认出口和请求路径变化后，测速结果才适合记录。
自动选择节点和手动选择哪个更快？
没有对所有网络都成立的固定答案。自动选择适合节点状态变化较频繁的一般场景，手动固定更适合会议、办公和需要保持会话的场景。最终应以同一时间、同一业务下的复测结果决定。
需要测速多少次才能选节点？
不要只看一次峰值。建议对候选节点进行多次重复测试，并至少覆盖日常使用时段和晚高峰；次数和时间间隔可按本地网络、流量限制和业务重要程度调整。