network speed test 怎么测节点速度？延迟、下载和丢包这样看

更新于 2026-10-24 · glados.lat

简答：先在客户端逐个测试节点延迟，再保持同一设备和网络，用 Speedtest、FAST.com 或真实目标重复测速；节点速度不能只看一次下载峰值，还要结合丢包、抖动、TTFB 和早晚时段结果判断。

定义：节点测速是通过代理客户端或代理链路访问测试地址，分别观察节点延迟、实际吞吐、稳定性和目标网站响应，而不是只测本地宽带速度。

先试这一步：固定条件后再测节点

本文与 GLaDOS Network 及其开发者无隶属关系，仅提供通用网络排查方法。先不要急着比较节点名称或地区，先把测试条件固定下来，否则不同设备、不同 Wi-Fi、不同测速服务器会让结果失去可比性。

1. 固定一台设备，优先使用网线或信号稳定的 5GHz Wi-Fi；测试期间暂停系统更新、云盘同步、视频播放和其他设备的大文件下载。
2. 记录本地网络状态：先关闭代理，用 Speedtest 测一次本地宽带；再打开代理并固定同一个测速服务器。Speedtest 官方说明，测速结果取决于设备、浏览器、路由器和测试服务器，改变服务器会改变测试链路。《Assessing test results》、《Getting started》
3. 每个节点至少测三次，记录中位数，不要只记录最高下载速度。若三次结果波动很大，优先把它标记为“稳定性待复测”，不要直接认定为最快节点。
4. 测速会消耗流量，Speedtest 或大文件下载测试可能产生明显流量；测试前确认套餐余量，并避免连续对全部节点进行长时间下载。

最快判断：如果关闭代理时本地测速就已经异常，先排查 Wi-Fi、路由器或宽带，不要把本地问题归因于节点。

三层测速法：不要把四种速度混在一起

FAST.com 的结果主要估算当前互联网下载能力，展开详情后还能看到上传、未加载延迟和加载延迟；它通过访问 Netflix 服务器计算结果，因此更适合作为一种独立复测，不应与 Speedtest 的数值直接当作同一测试。《Internet Speed Test｜FAST.com》

Speedtest 官方说明，Ping 或延迟是设备发送请求后获得响应的反应时间，并会分别观察空闲、下载中和上传中的延迟。下载时延迟明显升高，通常说明满载时交互体验可能变差；这不能单独证明某个节点故障，但值得继续复测。《Getting started》

Clash、Clash Meta 或 Shadowrocket 中怎么测

不同客户端的按钮名称和页面布局会随版本变化，本文不把某个未核实版本的界面名称当作固定路径。通用操作是：打开节点或代理组列表，找到延迟测试、测速、URL Test、健康检查或类似功能；选择同一测试地址，对节点逐个测试；完成后把节点按延迟从低到高初筛，再进行下载测速。

1. 先确认客户端当前使用的代理模式确实会经过待测节点；如果规则把测试地址分流到 DIRECT，测到的只是本地网络。
2. 对所有候选节点使用同一个测试地址和超时时间。mihomo 官方支持通过代理组或指定代理的 delay API 测试，并返回毫秒级 delay；接口参数包括测试 URL 和 timeout。《APIs - mihomo docs》
3. 初筛时不要只选最低延迟。把节点分成“低延迟但速度未测”“延迟中等但下载稳定”“延迟高或超时”三类，避免因一次短请求误选节点。
4. 如果使用 mihomo 控制 API，可先确认配置中的 external-controller 地址和 secret，再执行下面的命令。示例中的地址、节点名和测试地址都要替换为你自己的值；不要把 secret 分享给他人。

curl -H "Authorization: Bearer YOUR_SECRET" "http://127.0.0.1:9090/proxies/YOUR_NODE_NAME/delay?url=https%3A%2F%2Fcp.cloudflare.com%2Fgenerate_204&timeout=5000"

返回结果重点看 delay：返回毫秒数表示测试请求完成的延迟；超时、连接失败或没有返回值时，先检查控制器地址、secret、节点是否已加载，以及测试 URL 是否可访问。mihomo 官方文档说明，指定代理的 delay 接口会返回新的延迟信息，超时时间单位为毫秒。《APIs - mihomo docs》

如果使用 URL Test 策略组，mihomo 官方配置示例使用健康检查 URL 和 interval 做主动检测；这类检测更适合自动选择，不等于完整下载测速。《Configuring example》

延迟、丢包、抖动、TTFB 和下载速度分别怎么看

• 延迟：通常以毫秒显示，反映一次请求往返所需时间。网页打开、远程办公和实时交互更依赖延迟与稳定性。
• 下载速度：反映测试服务器向设备发送数据时的吞吐。它受节点、出口线路、测速服务器、设备性能和并发连接影响，不代表所有网站都能达到同一速度。
• 丢包：表示部分数据包没有按预期到达或返回。少量短时异常不能直接下结论，应在同一条件下多次观察；持续丢包时，网页加载、远程桌面和语音通话都可能受到影响。
• 抖动：表示延迟变化程度。相同平均延迟下，抖动更大的节点通常更不稳定。Cloudflare 的网络质量指标也将延迟、丢包、下载、上传、负载延迟和抖动分开评估。《Aggregated Internet Measurement》
• TTFB：即收到第一个字节前所花时间。使用 curl 时，可通过 time_starttransfer 观察从请求开始到收到首字节的时间；它包含连接和服务器处理等阶段，不等于纯节点延迟。《curl - How To Use》

命令行复测时，使用一个体积适中的公开测试文件或你有权限访问的真实地址，并明确替换示例域名。下面命令只观察 HTTP 请求时间，不建议用它代替长时间带宽测试：

curl -x http://127.0.0.1:7890 -L -o /dev/null -s -w "code=%{http_code} connect=%{time_connect}s ttfb=%{time_starttransfer}s total=%{time_total}s speed=%{speed_download}B/s
" "https://example.com/test-file"

其中 127.0.0.1:7890 要替换为客户端的 HTTP 或 mixed-port，https://example.com/test-file 要替换为你有权访问的测试文件。判定时先看 code 是否为预期响应，再比较 ttfb、total 和 speed_download；如果返回错误码、重定向过多或文件极小，结果不适合比较速度。curl 官方文档列出了 time_connect、time_starttransfer、time_total 和 speed_download 等输出变量。《curl - How To Use》

按使用场景选节点：延迟优先还是下载优先

选择节点时，可以把“低延迟”和“高下载”分开记录。一个节点延迟较低但下载不稳定，未必适合视频或文件传输；另一个节点延迟略高但 TTFB 稳定，可能更适合网页和办公。这里的“适合”只能根据你的测试场景判断，不能由地区名称、线路标签或节点倍率直接推断。

早晚复测与异常排查顺序

单次测速只能说明当时的链路状态。建议至少在空闲时段和网络使用较多的时段各测一次，保持设备、测试服务器、代理模式和测试文件一致，并记录时间、节点、延迟、下载、上传、丢包、抖动、TTFB 和备注。

1. 先测本地：关闭代理运行 Speedtest。如果本地下载、上传或延迟已经异常，先处理 Wi-Fi、网线、路由器和后台占用。
2. 再核对代理路径：确认客户端没有把测速地址规则到 DIRECT，也没有误用系统代理、TUN 或其他代理叠加。
3. 再换测试端点：分别用 Speedtest、FAST.com 和真实目标测试。只有一个端点异常时，可能是测试服务器或目标站点差异。
4. 再看节点本身：比较多个节点的同一指标。如果全部节点都慢，更像本地网络、客户端配置或出口拥塞；只有一个节点异常时，先暂时停用并稍后复测。
5. 最后检查 DNS、MTU 和协议：如果表现为域名打不开、部分网站失败或长连接频繁中断，再进入 DNS、MTU、TUN 和规则排查，不要仅凭下载速度改配置。

如果测速结果在不同时间变化明显，应把结论写成“当前时段表现较好”而不是“始终最快”。这能避免把一次高峰或低谷结果误当作长期能力。

如何整理一张可复用的节点测速表

建议使用以下字段：测试时间、设备与网络、节点名称、测试服务器、客户端模式、延迟、下载、上传、丢包、抖动、TTFB、真实目标表现和备注。每次只改变一个变量，例如只更换节点，不同时更换设备、测试端点和代理模式。

最终选择可以采用简单规则：网页和办公优先选择 TTFB 稳定、延迟波动小且没有持续丢包的节点；视频和文件传输优先选择连续下载速度稳定的节点；远程桌面和会议优先选择抖动与丢包较低的节点。若两个节点表现接近，优先选在多个时段都能复现的那个，而不是只看某一次最高值。

常见问题

network speed test 测出来的是节点速度还是本地宽带速度？

关闭代理时主要测本地设备到测速服务器的链路；开启代理并确认测速地址经过节点后，结果才可用于观察代理链路。即使开启代理，设备、Wi-Fi、路由器和测速服务器仍会影响结果。

节点延迟低，为什么下载速度还是很慢？

延迟测试通常只是短请求，不能代表持续吞吐。下载速度还会受到出口拥塞、节点并发能力、测速服务器、设备性能和目标站点限制影响，应使用 Speedtest、FAST.com 和真实文件复测。

测速时应该看最低延迟还是最高下载？

取决于用途。网页、远程办公和远程桌面优先看延迟、TTFB、抖动和丢包；视频和大文件传输更看持续下载速度与稳定性。两者接近时，优先选择多个时段都能复现的节点。

为什么同一个节点每次测速结果不一样？

测试服务器、网络负载、Wi-Fi 状态、后台流量和时段都可能变化。固定设备和服务器，连续测试三次并记录中位数，再在不同时间段复测，比只看一次峰值更可靠。

curl 测速命令返回错误或没有速度值怎么办？

先检查客户端 HTTP 或 mixed-port 是否正确、代理是否正在运行、测试 URL 是否可访问，以及命令中的示例地址是否已经替换。再确认返回的 HTTP 状态码和 time_total；如果请求失败，先排查连接路径，不要把空结果当作节点速度。

测速会不会消耗很多流量？

会。长时间下载、上传或反复对大量节点测速都可能消耗明显流量。建议先用延迟测试做低流量初筛，再对少数候选节点做短时间下载和真实业务复测，并提前确认套餐余量。

相关阅读

• 连接问题排查指南
• 设备配置与网络设置
• 更多客户端与网络使用指南

参考资料

1. Getting started｜Ookla（s1.ooklaserver.org）
2. Assessing test results｜Ookla（s1.ooklaserver.org）
3. Internet Speed Test｜FAST.com（fast.com）
4. Aggregated Internet Measurement｜Cloudflare
5. APIs｜mihomo docs
6. Configuring example｜MetaCubeX mihomo
7. curl - How To Use（curl.se）