如何测试代理节点速度和延迟
简答：测试代理节点时，先用客户端对多个节点执行同一健康检查，再通过代理运行 curl 或网页测速验证实际链路，最后结合延迟、下载速度、抖动、丢包和多次复测结果选择节点。普通 ping 不能单独代表代理体验。
定义：代理节点延迟是请求经过代理链路访问测试目标并获得响应所需的时间，通常以毫秒（ms）表示；节点速度主要指代理链路的下载和上传吞吐量。
一、先分清延迟、速度、抖动和丢包
“延迟低”不等于“速度快”。客户端中的延迟测试通常是通过节点请求一个健康检查地址，主要反映响应时间；网页加载、视频播放和文件下载还会受到节点带宽、线路拥塞、测试服务器、本地网络和规则分流影响。
| 指标 | 代表什么 | 适合判断什么 |
|---|---|---|
| 延迟 | 请求到达测试目标并得到响应所需的时间，单位通常为 ms | 网页响应、连接建立和实时交互的即时性 |
| 下载速度 | 单位时间内接收数据的速率，常见单位为 Mbps 或 MB/s | 视频播放、文件下载和大页面加载 |
| 上传速度 | 单位时间内发送数据的速率 | 上传文件、视频会议和云端同步 |
| 抖动 | 连续测试时延迟的波动程度 | 语音、视频会议和其他实时应用的稳定性 |
| 丢包 | 数据包或请求没有成功到达或返回的比例 | 卡顿、重传、连接中断和网页加载失败 |
Cloudflare 的网络质量说明将延迟、丢包、下载、上传、负载延迟和抖动作为综合判断网络质量的指标。因此，选择节点时不要只看一个延迟数字，也不要把一次测速峰值当成长期表现。
二、用客户端批量测试节点延迟
- 固定测试条件。使用同一台设备、同一个网络、同一个代理模式和同一个测试地址。测速前暂停云盘同步、大文件下载和视频播放，避免本地带宽成为瓶颈。
- 准备健康检查地址。可以使用完整的
http://cp.cloudflare.com/generate_204或https://www.gstatic.com/generate_204。测试地址应保持一致；不同地址的服务器位置和网络路径不同，结果不能直接混合比较。 - 确认流量确实经过目标节点。在 Clash Verge Rev、Mihomo、v2rayN 等客户端中，进入代理节点或代理组页面，使用界面显示的“延迟测试”“测试延迟”“测速”或类似按钮。不同版本的按钮名称和位置可能不同，应以当前客户端界面为准。
- 先批量筛选，再重复测试。第一轮对多个节点测试，记录成功、超时和延迟；第二轮只测试候选节点，尽量保持网络和测试地址不变。建议把测试时间、节点名称、延迟和备注保存下来。
- 再做真实访问验证。选出候选节点后，通过浏览器打开实际需要访问的网站，或下载一个体积适中的公开文件，观察首屏响应、持续速度和是否断流。
Clash Verge Rev 的项目说明显示，其节点或代理组延迟测试会通过代理向 http://cp.cloudflare.com/generate_204 发起请求，也可以使用配置中的测试地址。这个结果更接近“经由节点访问测试目标”的延迟，但仍不能代替持续下载测试。Clash Verge Rev 项目说明
如果使用 v2rayN，优先使用客户端自己的“真连接延迟”或速度测试功能。项目讨论中说明，相关测试是通过服务器访问目标，而不是简单测本机到服务器的 ICMP 延迟。v2rayN 项目讨论
三、用网页测速检查实际带宽
客户端延迟测试一般只请求很小的响应，无法说明节点的持续下载速度。要检查带宽和负载表现，可以在选定节点后打开Cloudflare Speed Test，并按照相同条件逐个切换节点。
- 先在客户端选择一个节点，确认系统代理或 TUN 模式已经生效。
- 打开测速页面，等待测试完成，记录下载、上传、空闲延迟、负载下延迟、抖动和丢包等结果。
- 切换到下一个节点，使用同一设备、同一网络和同一测速页面重复测试。
- 对第一轮表现较好的节点再测一次，避免把瞬时空闲或短暂拥塞误判为长期速度。
- 根据实际用途筛选：网页浏览优先看延迟和成功率；视频播放优先看持续下载速度和负载下延迟；实时通信重点看抖动、丢包和延迟波动。
Cloudflare 官方测速说明指出，Cloudflare 提供的网络测速可以观察下载、上传、丢包和 ping 等结果。测速服务器位置、并发连接数、测试协议和本地网络都会影响结果，所以不要把不同网站、不同时间的数字直接横向比较。
四、用 curl 直接测试代理链路
命令行测试的好处是可以明确指定本地 HTTP 或 SOCKS 代理，并输出连接时间、首字节时间、总耗时和平均下载速度。下面示例使用 SOCKS5，并让代理解析目标域名；curl 官方文档将 socks5h:// 定义为由 SOCKS5 代理解析主机名。
macOS、Linux 或安装了 curl 的环境：
curl --proxy "socks5h://127.0.0.1:10808" --output /dev/null --silent --show-error --max-time 15 --write-out "http_code=%{http_code}\ntime_connect=%{time_connect}s\ntime_starttransfer=%{time_starttransfer}s\ntime_total=%{time_total}s\nspeed_download=%{speed_download}B/s\n" "https://cp.cloudflare.com/generate_204"
Windows PowerShell：
curl.exe --proxy "socks5h://127.0.0.1:10808" --output NUL --silent --show-error --max-time 15 --write-out "http_code=%{http_code}`ntime_connect=%{time_connect}s`ntime_starttransfer=%{time_starttransfer}s`ntime_total=%{time_total}s`nspeed_download=%{speed_download}B/s`n" "https://cp.cloudflare.com/generate_204"
127.0.0.1:10808只是示例端口，应替换为客户端实际的 SOCKS 入站端口。- 如果使用 HTTP 代理，将前面的地址改为类似
http://127.0.0.1:7890，端口仍以客户端设置为准。 time_connect主要反映连接建立阶段，time_starttransfer表示收到首字节前的时间，time_total是请求总耗时，speed_download是本次传输的平均下载速度。- 多次执行同一命令并记录结果，再切换节点复测。只执行一次不能说明节点的长期稳定性。
curl 官方文档说明，--proxy支持 HTTP、HTTPS、SOCKS4、SOCKS5 等代理协议，--write-out可以输出连接时间和下载速度等字段。curl 官方命令行文档
五、Mihomo 中测试单节点和策略组
如果使用 Mihomo，可以通过外部控制 API 测试单个代理，也可以测试策略组中的多个节点。先检查配置中的 API 监听地址和密钥：
external-controller: 127.0.0.1:9090
secret: "你的密钥"
Mihomo 全局配置文档说明，external-controller是 REST API 的监听地址，secret是 API 访问密钥。不要把监听地址改为公网可访问，也不要把真实密钥发布到截图、日志或文章中。
测试单个代理时，将代理名称进行 URL 编码后执行：
curl -H "Authorization: Bearer 你的密钥" "http://127.0.0.1:9090/proxies/节点名称/delay?url=https%3A%2F%2Fcp.cloudflare.com%2Fgenerate_204&timeout=5000"
测试策略组内的节点时，使用策略组接口：
curl -H "Authorization: Bearer 你的密钥" "http://127.0.0.1:9090/group/策略组名称/delay?url=https%3A%2F%2Fcp.cloudflare.com%2Fgenerate_204&timeout=5000"
单节点接口会返回类似 {"delay":123} 的延迟结果；策略组接口会返回节点名称与延迟的对应关系。节点名称、策略组名称和测试地址中的特殊字符必须正确编码。完整字段、鉴权方式和接口路径以Mihomo API 文档为准。
六、ping、tracert 和 TUN 模式为什么不能单独作为结论
ping和tracert或traceroute适合检查基础网络连通性和路径，但普通 ICMP 测试不一定经过代理节点，也不一定模拟浏览器的 HTTP 或 HTTPS 请求。因此，看到 ping 延迟很低，不能直接得出网页访问也会很快的结论。
启用 TUN 模式时尤其要注意测试工具是否经过 TUN。v2rayN 项目记录过一种情况：开启 TUN 并清除系统代理后，客户端自身的真连接延迟测试可能因为没有使用本地代理入口而返回 -1，但浏览器流量仍可能正常经过 TUN。v2rayN 项目问题说明
- 先关闭 TUN，使用客户端提供的本地 HTTP 或 SOCKS 端口做 curl 测试。
- 再开启 TUN，确认系统代理、TUN 路由和客户端自身测试方式没有冲突。
- 如果客户端显示超时但浏览器可以访问，分别检查测试地址、代理入口和日志，不要仅凭一次延迟结果判断节点失效。
- 如果所有节点同时变慢，先检查 Wi-Fi、路由器、本地带宽、DNS 和网络拥塞；如果只有一个节点持续失败，再重点检查该节点或规则分流。
七、如何根据测试结果选择节点
| 用途 | 重点观察 | 选择方法 |
|---|---|---|
| 普通网页浏览 | 延迟、请求成功率、页面打开稳定性 | 从成功节点中选择多次延迟较稳定者 |
| 视频播放 | 持续下载速度、负载下延迟、丢包 | 优先选择持续速度稳定且少断流的节点 |
| 实时语音或视频会议 | 抖动、丢包、延迟波动 | 不要只看下载峰值，优先选择波动较小者 |
| 大文件下载 | 平均下载速度、断流和长时间稳定性 | 连续下载一段时间后再判断，不看瞬时速度 |
不存在适用于所有用户和所有用途的固定合格延迟。更可靠的流程是：同一条件下批量测试，筛掉超时和明显波动的节点；对候选节点做第二轮客户端测试和 curl 测试；最后用实际访问、播放或下载验证。建议记录“测试时间、网络类型、客户端、节点、测试地址、延迟、总耗时、下载速度、抖动、丢包和备注”，便于区分临时拥塞与持续问题。
常见问题
代理节点延迟越低就一定越快吗？
不一定。延迟主要反映请求响应时间，下载速度还会受到节点带宽、拥塞、并发连接、测速服务器和本地网络影响。应同时观察持续下载速度、抖动、丢包和实际访问表现。
为什么客户端显示延迟很低，但打开网页仍然很慢？
客户端可能只测试了一个很小的健康检查请求，网页访问还会受到 DNS、规则分流、TLS、目标网站距离、节点负载和本地网络影响。可以用指定代理的 curl 命令测试完整 HTTP 或 HTTPS 请求。
可以直接用 ping 测试代理节点吗？
只能作为基础网络参考。普通 ping 通常测试 ICMP 路径，不一定经过代理，也不能模拟网页请求。应优先使用客户端延迟测试、Mihomo API 或通过本地 HTTP/SOCKS 端口运行 curl。
测速时应该测试几次？
建议先对多个节点做一轮筛选，再对候选节点进行第二轮复测。两轮测试尽量使用相同网络、相同测试地址和相近时间，并结合实际打开网页或下载文件的表现。
开启 TUN 后延迟测试显示超时或 -1，怎么办？
先确认客户端自身测试是否使用了本地代理端口，再分别关闭和开启 TUN 复测。若浏览器能正常访问而客户端测试失败，重点检查 TUN 对客户端自身流量的处理、系统代理状态、测试地址和日志，不要只根据 -1 判断节点不可用。