代理节点怎么测速比较稳定性：一套可复现的判断方法
简答：代理节点不能只看客户端显示的 Ping。先确认测试流量确实经过代理，再用同一设备、同一目标和同一时段重复测试连接延迟、真实下载、失败率与晚高峰波动；最后按自己的用途保留主用和备用节点。
定义：代理节点稳定性，是节点在固定测试条件下持续完成连接和业务请求，并保持延迟、速度、丢包与失败率波动可接受的能力。
先试这一步：确认测到的是代理，不是直连网络
如果客户端没有真正接管流量，后面的延迟和下载结果都没有比较意义。先固定一台设备、一个网络环境和一个客户端配置；暂时不要同时切换 TUN、系统代理、规则模式和 DNS 设置。
- 检查客户端入口：确认当前选择的是目标节点或目标策略组，而不是直连、自动选择或故障转移组。
- 检查代理端口：如果使用 mihomo，先查看当前配置中的 HTTP、SOCKS 或 mixed 端口。mihomo 文档说明，mixed port 可同时接受 HTTP(S) 和 SOCKS5 代理连接，具体端口以当前配置为准。查看 mihomo 代理端口说明
- 检查实际请求：用浏览器访问一个可识别出口变化的页面，或用 curl 通过指定代理发起请求。不要只看客户端“已连接”状态。
- 判定条件：同一目标在“关闭代理”和“指定节点”两种状态下，应能观察到请求路径、响应时间或出口信息发生变化；若没有变化，先排查规则、端口和 TUN，再开始测速。
命令示例只使用本机代理端口，不包含真实账号或订阅信息：HTTP 代理可使用 curl -x http://127.0.0.1:端口 https://example.com -I；SOCKS5 可使用 curl --proxy socks5h://127.0.0.1:端口 https://example.com -I。curl 的连接计时、首字节时间和总耗时可通过 -w 输出，连接阶段也可以单独设置超时。查看 curl 官方参数说明
五步测速流程：从初筛到稳定性验收
- 第一轮：客户端延迟初筛。对所有候选节点使用同一个测试 URL 和相同超时设置，先淘汰超时、无法连接或连续失败的节点。mihomo API 文档显示，其代理延迟测试是对指定 URL 发起测试并返回延迟值；这类结果适合做初筛，不等于下载速度。查看 mihomo API 中的代理延迟测试说明
- 第二轮：连接和首字节测试。用 curl 通过同一个代理访问同一个 HTTPS 目标，记录连接耗时、首字节耗时和总耗时。连接耗时偏高，可能出现在 DNS、TCP、TLS 或代理建立连接阶段；首字节耗时偏高，则可能与远端响应、线路拥塞或节点负载有关。不要仅凭一个字段判断原因。
- 第三轮：真实下载复测。选择你经常使用且允许测试的固定文件或服务，先下载较短时间，再观察持续速度、速度波动和是否中途失败。测试文件、服务器和并发方式必须保持一致，否则结果不能直接横向比较。
- 第四轮：丢包与抖动观察。网页代理通常以 TCP 或 HTTPS 业务为主，客户端 Ping 不一定等于业务丢包。若你拥有自己的两端测试主机，可用 iperf 的 UDP 测试观察带宽、抖动和丢包；官方文档说明，UDP 报告可以显示 jitter 以及丢失数据报比例，而 TCP 本身不会直接向用户报告丢包。查看 iPerf 官方文档
- 第五轮：分时段验收。至少在普通时段和你最常使用的高负载时段各测一轮。若白天很快、晚间失败率明显上升，应记录为“时段敏感”，而不是简单标记为稳定节点。
每个节点建议重复测试多次，使用中位数观察典型表现，同时保留最大延迟、失败次数和速度最低值。这里的重复次数和淘汰线是便于普通用户执行的记录方法，不是所有线路都适用的行业统一标准；应根据你的网络、客户端和用途调整。
怎么读测速结果：低延迟不代表稳定
| 指标 | 能说明什么 | 不能单独说明什么 | 复测建议 |
|---|---|---|---|
| 客户端延迟或 Ping | 节点对测试目标的往返响应情况 | 不能直接代表下载速度、视频缓冲或网页完整打开速度 | 统一测试 URL，重复观察中位数和最大值 |
| 连接耗时 | 建立 DNS、TCP、TLS 或代理连接所需时间 | 不能说明连接建立后持续传输是否稳定 | 用 curl 输出计时字段，区分偶发超时和持续偏高 |
| 首字节时间 | 请求发出后收到第一部分响应的等待时间 | 不能等同于整文件下载完成时间 | 使用相同 URL、请求方式和代理端口比较 |
| 持续下载速度 | 在具体文件、服务器和时段下的实际吞吐 | 不能代表所有网站、协议和时段 | 记录开始速度、稳定速度、最低速度和是否中断 |
| 失败率 | 多次连接或请求中未完成的比例 | 不能单独定位是节点、DNS、本地网络还是目标站问题 | 同时做关闭代理的对照测试，并记录错误类型 |
| 抖动与丢包 | 传输时延变化和数据报丢失情况 | 不能直接推导网页体验或所有 TCP 业务结果 | 对实时会议、语音或游戏等场景单独测试 |
浏览器也能提供更细的资源加载时间。MDN 的 Resource Timing 文档列出了 DNS、连接、请求、响应开始和响应结束等时间点；但跨域资源可能因服务器没有提供 Timing-Allow-Origin 而隐藏部分字段，因此浏览器开发者工具中的数据不一定完整。查看 MDN Resource Timing 说明
按使用场景排序：不要用同一标准选所有节点
| 使用场景 | 优先指标 | 复测重点 |
|---|---|---|
| 网页浏览 | 连接成功率、首字节时间、页面资源加载 | 连续打开多个页面，观察是否出现单域名失败 |
| 视频播放 | 持续吞吐、速度波动、长连接稳定性 | 观察开始缓冲、播放中降速和中途重连 |
| 大文件下载 | 持续速度、最低速度、总耗时 | 固定文件和下载服务器，不要混用多个测速站 |
| AI 对话或远程办公 | 首字节时间、失败率、长连接保持时间 | 重复发送短请求和较长请求，分别记录结果 |
| 会议、语音或实时业务 | 丢包、抖动、突发延迟 | 优先使用实际应用或可控两端测试，不只看 HTTP 速度 |
如果一个节点下载速度高但经常连接失败，它不一定适合日常使用；如果节点延迟略高但首字节稳定、失败率低，反而可能更适合网页、办公或长连接场景。
可直接复制的记录表与排序方法
建议为每个节点建立一行记录，字段包括：测试日期、测试时段、设备、接入网络、客户端模式、节点名称、测试 URL、测试次数、成功次数、延迟中位数、最大延迟、连接耗时、首字节时间、下载速度中位数、最低速度、失败原因、备注。
可以先用一个透明的自定义评分帮助排序：综合分 = 连接成功率 × 40% + 延迟稳定性 × 20% + 持续速度 × 20% + 业务验收 × 20%。其中各项先在你自己的候选节点中换算为 0 到 100 分，权重只是便于比较的示例，不是通用行业标准。会议、实时交互等场景可提高丢包和抖动权重；大文件下载则提高持续速度权重。
- 主用节点：多次测试成功，业务验收通过，普通时段和常用高峰时段没有明显失效。
- 备用节点：整体可用，但某个时段、某类业务或某项指标波动较大。
- 暂不采用：反复超时、失败原因不明，或必须频繁切换模式才能完成测试。
不要把一次测速结果保存成永久结论。线路、远端目标、家庭网络、运营商路由和客户端规则都可能变化；下一次出现“速度变慢”时，先用同一记录表复测，判断变化发生在本地网络、节点、目标站还是测试方法。
异常分流：结果不稳定时先查哪里
- 所有节点都慢：先关闭代理测试本地网络，再检查 Wi-Fi、系统网络、DNS、TUN 或系统代理是否重复接管。
- 只有一个节点慢：用相同 URL 和时段对比其他节点；若其他节点正常，优先记录该节点的失败率和持续速度，不要只看 Ping。
- 客户端显示低延迟但网页慢：检查延迟测试 URL 与实际访问目标是否不同，并用 curl 或浏览器开发者工具查看连接耗时、首字节和总耗时。
- 下载很快但会议卡顿：补测丢包、抖动和长连接，不要用单次下载速度替代实时业务验收。
- 只有晚间变慢：安排相同目标的分时段复测，记录峰值时段失败率和最低速度；不要把单次晚间结果直接推广到全天。
- 更换配置后结果异常：先备份原配置，再一次只改一个变量，例如代理模式、DNS 或 MTU；复测无改善时恢复备份，避免多个改动叠加后无法定位。
资料核验日期与使用边界
资料核验日期：2026-11-02。本文给出的指标解释和测试流程用于网络诊断与节点横向比较，不代表任何节点、线路或服务在所有地区、设备和时段都能达到固定表现。客户端菜单、端口和 API 权限可能随当前版本或配置变化，操作时以实际界面和官方文档为准。
本站是第三方使用指南站，不是相关网络服务或客户端的官网。涉及具体服务的价格、状态、线路数量和可用性，本文未作判断。
常见问题
代理节点测速时，Ping 越低是不是越稳定？
不是。Ping 或客户端延迟主要反映某个测试目标的往返响应，不能直接代表真实下载、网页首字节、长连接或晚高峰表现。至少还要复测成功率、首字节时间、持续速度和时段波动。
为什么客户端显示延迟很低，但打开网页仍然很慢？
常见原因是延迟测试目标与实际网页不同，或者 DNS、TLS、规则分流、远端响应和节点负载拖慢了后续请求。可用 curl 通过指定代理查看连接耗时、首字节时间和总耗时，再与关闭代理的结果对照。
每个代理节点测速几次比较合适？
普通横向比较可以先做多次重复测试，再使用中位数、最大值和失败次数判断；不要只记录一次峰值。若要判断长期稳定性，还应在普通时段和常用高峰时段复测。具体次数应根据网络成本和使用场景调整。
下载速度高但丢包或抖动明显，应该选它吗？
取决于用途。大文件下载可能更看重持续吞吐，而会议、语音、游戏或其他实时业务通常更需要低丢包和低抖动。应使用与你的实际场景相同的业务验收，不要用单一速度指标替代全部判断。
测速前需要打开 TUN 模式吗？
不一定。是否打开 TUN 取决于你要测试的实际使用方式。关键是明确当前流量由哪个模式接管，并确认请求确实通过目标节点；如果同时启用系统代理、TUN 和其他网络工具，可能造成重复接管或误测。
相关阅读
参考资料
- mihomo 官方文档：代理端口
- mihomo 官方文档：API 与代理延迟测试
- curl 官方文档：命令行参数与计时字段（curl.se）
- iPerf 官方文档：带宽、抖动与丢包测试（iperf.fr）
- MDN：PerformanceResourceTiming 资源计时接口