代理测速怎么看节点速度？先读客户端延迟，再看下载速度
简答：节点速度不能只看下载 Mbps：先确认客户端测试请求确实经过节点，再看延迟、超时、抖动和满载表现，最后比较持续下载速度。相同条件下，稳定且失败少的节点通常比单次峰值更值得保留。
定义：代理节点测速，是在指定代理路径下请求测试地址或传输数据，用来比较节点的响应时间、稳定性和吞吐表现。
节点列表里先看什么：一张速查表
节点列表里一排 ms 数字，测速页面又显示 Mbps，很多人会不知道该选哪个。最快的判断顺序是：先确认测试路径，再看延迟和失败状态，最后比较下载速度。
| 显示结果 | 通常代表 | 怎么处理 |
|---|---|---|
| 延迟较低且多次接近 | 测试地址的响应较稳定 | 保留，再按实际用途复测 |
| 延迟数值忽高忽低 | 连接可能存在抖动或时段波动 | 连续测试并换时段观察 |
| Timeout、超时或未完成 | 在客户端设定的测试时间内没有得到有效响应 | 检查测试地址、规则、节点连通性和本地网络 |
| 低延迟但下载速度低 | 响应快，但持续传输能力有限 | 适合网页和交互，不代表适合大文件 |
| 下载速度高但延迟高 | 吞吐不错，但建立连接或交互响应可能较慢 | 优先考虑下载，会议和实时交互要复测 |
| 测速很快但实际网页慢 | 测速地址与目标网站的路径、规则或响应时间不同 | 检查目标域名是否直连，并查看 TTFB |
在 Mihomo 中，url-test 使用指定 URL 对代理组进行延迟测试，延迟单位为 ms；代理提供者的健康检查也有独立的 URL 和 timeout 字段。不同客户端的菜单和默认值可能不同，应以当前客户端文档和设置页为准。Mihomo Url-Test 文档 Mihomo Proxy-Providers 文档
客户端里的延迟，不等于普通 Ping
客户端节点列表中的延迟通常是通过所选节点请求一个测试 URL，再记录请求完成或收到响应所需的时间；它不是单纯向目标地址发送 ICMP Ping。测试地址、协议、DNS、TLS 建连和节点到测试服务器的路径，都会影响结果。因此，列表显示的 60 ms 只能说明“该客户端、该测试地址、该时刻”的响应表现，不能直接等同于所有网站都是 60 ms。
以 Mihomo 的配置说明为例，健康检查需要指定 health-check.url，并可设置以毫秒计的 health-check.timeout；url-test 也通过配置中的 URL 进行节点比较。若客户端显示 Timeout，优先理解为“这次测试没有在规定时间内完成”，不要直接断定节点永久失效。Mihomo 健康检查字段说明 Mihomo Url-Test 字段说明
如果客户端支持设置测试地址，可以使用设置页提供的地址；不要把示例地址原样替换到所有客户端中。测试地址应能返回客户端期望的状态，具体要求以客户端文档为准。Clash Verge Rev 的官方 FAQ 也记录过“测试界面显示超时但网站仍可访问”的排查场景，遇到这类情况应结合实际访问和客户端日志判断，状态以对应页面为准。Clash Verge Rev 官方 FAQ
先做一次可复现的代理测速
- 记录直连基线：关闭客户端代理，在同一设备、同一 Wi-Fi 或网线、同一测速页面测试一次，记录出口 IP、地区、延迟、抖动、上下行速度和是否失败。
- 确认代理路径：打开客户端并选择一个节点，重新打开测速页，对比出口 IP 或地区是否发生变化。如果客户端有连接面板，查看测速域名命中的规则和实际节点；如果规则模式不确定，可临时切换到全局模式测试，完成后恢复原设置。
- 只更换一个变量：保持设备、浏览器、测速页面、测试地址和网络连接不变，每次只更换节点。
- 先筛失败和波动：把持续超时、明显丢包、延迟大幅跳变或满载时响应明显恶化的节点放到候选列表后面。
- 再看带宽：在稳定节点中比较持续下载速度和上传速度，不要只选某一次出现最高峰值的节点。
- 分时段复测：至少记录不同时间段的结果，使用中位趋势或多数结果判断，不用单次最高速度代表长期表现。
Cloudflare 的测速说明将空载延迟与有下载、上传流量时的 loaded latency 分开测量，也同时观察抖动和丢包；这说明“空闲时延迟低”与“有负载时仍稳定”是两个不同问题。Cloudflare Speed Test 测试原理
延迟、抖动、满载延迟和速度分别怎么看
| 指标 | 单位或状态 | 主要反映 | 适合关注的场景 |
|---|---|---|---|
| 延迟 | ms | 请求响应所需时间 | 网页、远程办公、实时交互 |
| 抖动 | ms 或变化值 | 连续延迟是否稳定 | 会议、语音、实时操作 |
| 丢包 | 百分比 | 数据包是否未成功到达 | 会议、实时交互、长连接 |
| 满载延迟 | ms | 传输流量时的响应变化 | 视频、下载同时操作、会议 |
| 下载速度 | Mbps 或 MB/s | 持续接收数据的能力 | 视频、下载、同步 |
| 上传速度 | Mbps 或 MB/s | 持续发送数据的能力 | 会议、上传、云同步 |
| TTFB | ms | 请求开始到收到首个响应字节的时间 | 网页打开和接口响应 |
Mbps 与 MB/s 不是同一个单位。Mbps 使用 bit，MB/s 使用 Byte，理论换算可以写成：MB/s ≈ Mbps ÷ 8。例如 100 Mbps 理论上约等于 12.5 MB/s；如果下载软件显示 MiB/s，1 MiB 等于 1,048,576 字节，数值还会与十进制 MB/s 有差异。实际下载速度还会受协议开销、服务器限制、磁盘写入和并发连接影响。
TTFB 只代表开始收到响应的速度。它不等于完整文件下载完成时间。MDN 将 TTFB 解释为从请求开始到收到第一个响应字节之间的时间，因此网页“开始有反应很慢”与“后续下载速度慢”需要分别判断。MDN：Time to First Byte
测速工具之间不要直接混用结果。Cloudflare 说明，其测试会使用自身网络中的数据中心、特定测量方法和统计方式；不同工具的服务器位置、路径和计算方式不同，所以更适合在同一工具、同一条件下做横向比较。Cloudflare Speed Test 指标说明
带具体读数的示例：哪个节点更值得选
下面是示例，不是实测数据，也不是固定达标线。判断重点是同一轮测试中的相对表现和你的使用场景。
| 节点 | 延迟 | 抖动 | 下载速度 | 适合判断 |
|---|---|---|---|---|
| 节点 A | 60 ms | 25 ms | 200 Mbps | 峰值带宽高，但实时交互要继续观察稳定性 |
| 节点 B | 120 ms | 3 ms | 60 Mbps | 响应较慢但波动小，适合一般下载或对稳定性更重视的任务 |
如果主要是网页、远程办公或会议，节点 B 的低抖动可能比节点 A 的高峰值速度更有参考价值；如果主要是大文件下载，节点 A 的持续吞吐可能更有吸引力，但要确认满载延迟不会明显升高。若两个节点都能满足带宽需求，优先选多次测试失败少、波动小的节点。
| 用途 | 优先看 | 复测重点 |
|---|---|---|
| 网页和文档 | 延迟、TTFB、失败率 | 多个目标网站的实际打开时间 |
| 视频播放 | 持续下载速度、满载延迟 | 播放过程中是否反复缓冲 |
| 跨境办公和远程桌面 | 延迟、抖动、丢包 | 长时间连接是否中断 |
| 视频会议 | 抖动、丢包、上下行速度 | 开启摄像头和共享后是否恶化 |
| 大文件下载和同步 | 持续下载速度、失败率 | 长时间传输是否降速或重连 |
测速很快但实际不好用，按这几项排查
- 确认测速页没有直连：对比开关代理前后的出口 IP 或地区，并查看客户端规则命中情况。
- 换一个实际目标：测速服务器位置和目标网站位置不同，某个测试地址响应快，不代表所有网站都快。
- 检查 DNS 和规则：目标域名可能被分流为直连，或者 DNS 解析到不同地址，导致实际访问路径与测速路径不同。
- 观察满载延迟：测速开始后如果下载速度上升、延迟同时大幅增加，说明需要进一步区分节点拥塞、本地 Wi-Fi 或其他设备占用。
- 减少本地干扰：暂停后台下载、云同步和系统更新，尽量使用稳定 Wi-Fi 或网线，并保持测试设备不变。
- 把超时分开判断：如果所有节点都超时，先查测试地址、客户端核心、规则和本地网络；如果只有一个节点超时，再与同地区节点横向比较。
测速结果不能证明某节点长期最快，也不能单独证明所有网站的可用性、安全性或隐私表现。更准确的记录方式是：在某设备、某网络、某时间、某测试地址下，该节点的结果如何。
常见问题
代理测速时，为什么客户端显示低延迟，但网页打开仍然慢？
客户端延迟测试只针对指定测试地址。实际网页还会受到规则分流、DNS、TLS、目标服务器响应和页面资源数量影响。先对比出口 IP，再检查目标域名是否命中代理，并结合 TTFB 判断是开始响应慢还是后续下载慢。
节点列表里的 Timeout 是不是说明节点一定失效？
不一定。Timeout 表示本次测试没有在设定时间内得到有效响应，可能与测试地址、规则、客户端核心、本地网络或节点本身有关。可以先用相同条件测试其他节点，再单独访问实际目标，并查看客户端设置和日志。
选节点时应该优先看延迟还是下载速度？
网页、远程办公、会议和实时交互优先看延迟、抖动、丢包与满载延迟；视频、下载和同步再重点比较持续下载速度。没有一个指标能代表所有用途。
100 Mbps 为什么不是 100 MB/s？
Mbps 是兆比特每秒，MB/s 是兆字节每秒，理论上需要除以 8；100 Mbps 约等于 12.5 MB/s。实际还会受到协议开销、服务器限速、磁盘和网络波动影响。
同一个节点每次测速结果不同，应该相信哪个？
每次结果都只代表当时条件。固定设备、网络、测试地址和客户端设置，连续测试并记录中位趋势；再在不同时间段复测，不要用单次最高速度判断长期表现。
测速页显示很快，但客户端节点列表延迟很高，怎么判断？
两者可能测试了不同地址、不同路径或不同协议。先确认测速页经过所选节点，再检查客户端的测试 URL 和超时设置；如果仍不一致，应以实际使用目标和多轮复测结果为准。