节点延迟和丢包怎么测？一套可复制的测试与排查方法

更新于 2026-10-27 · yizhihongxing.shop

简答：先断开代理测试本地网络，再用 ping 或 pathping/traceroute 观察路径，最后通过代理执行 curl 验证真实业务。单次 ping 不足以判断节点质量，至少记录多个时间段的延迟、波动、丢包和实际请求结果。

定义：节点延迟是数据往返所需时间，丢包是发出的测试包没有收到回应，抖动则是连续延迟的波动程度。

三步速查：先判断问题在哪一段

本文是第三方使用指南，不代表任何客户端、线路或服务的官方说明。你可以按下面的决策卡快速开始：

本地网络：先断开代理，用 ping 192.168.1.1 -n 20 测试路由器；如果本地就有超时或波动，先检查 Wi-Fi、网线、路由器和宽带。
路径与节点入口：用 Windows 的 pathping，或 macOS/Linux 的 traceroute、mtr 查看中间路径。Windows 官方说明中，pathping 会持续向各跳发送测试包并计算延迟与丢包。查看 Microsoft pathping 文档
真实业务：开启代理后，用 curl 通过本地代理请求同一个 HTTPS 地址，再结合网页、视频会议或长连接实际表现判断。

最短结论是：先测本地，再测路径，最后测代理后的真实请求；不要只看客户端延迟排序。

先分清四种“延迟”测试对象

测试方式	实际测到什么	适合回答的问题	不能直接说明什么
客户端延迟测试	客户端使用自身探测方式连接测试目标	多个节点谁更容易建立探测连接	不等于完整网页、会议或下载体验
ping 节点 IP	本机到目标 IP 的 ICMP 往返时间	目标是否回应 ICMP、直连路径是否稳定	不能证明代理协议端口可用
tracert、traceroute、mtr、pathping	沿途路由、各跳回应时间和部分丢包现象	问题可能出现在本地、运营商或某段路径吗	中间路由不回应不一定代表转发流量丢失
通过代理的 curl	本地代理到目标网站的实际 HTTP/HTTPS 请求	代理端口、DNS、TLS 和真实请求是否正常	一次请求不能代表全天稳定性

ping 使用 ICMP 回显请求并统计往返时间；Linux 文档还说明其结果会给出丢包和 RTT 统计。Windows ping 文档与 Linux ping 文档可作为命令参数依据。

Windows：用 ping、tracert 和 pathping 分层测试

1. 测本地路由器

打开“命令提示符”，先执行：

ping 192.168.1.1 -n 20

把地址替换为你的路由器网关地址。可以在 Windows 的网络连接详情中查看默认网关。记录发送数量、接收数量、丢失百分比和最小/最大/平均时间。如果这里已经出现大量超时，先不要把问题归因于节点。

2. 测目标地址

如果你有节点的服务器域名或 IP，可执行：

ping 节点域名 -n 30

Windows 的 ping 默认只发送少量请求，使用 -n 可以指定数量。需要注意，目标可能不回应 ICMP，因此“请求超时”只能说明 ICMP 测试没有收到回应，不等于代理端口一定不可用。

3. 查看路径

tracert /d 节点域名

/d 可避免反向解析中间地址名称，通常更适合快速观察路径。Microsoft 文档说明，tracert 通过逐步增加 TTL 来发现路径；某些路由器不返回超时报文时，输出会出现星号。查看 Microsoft tracert 文档

4. 需要统计丢包时使用 pathping

pathping /n /q 30 节点域名

它会先发现路径，再向沿途路由持续发送测试包并计算统计结果。命令需要等待一段时间，结束后重点查看“Source to Here”和“This Node/Link”两类数据。某个中间路由自身显示丢包，但后续链路和最终目标没有继续增加丢包时，不能仅凭该行判定转发流量受损；官方示例也区分了“路由器自身不回应”和“链路转发丢包”。查看 pathping 结果说明

macOS 与 Linux：用 ping、traceroute 和 mtr

macOS/Linux 的基础命令

在终端执行：

ping -c 30 节点域名

traceroute -m 30 节点域名

Linux 的 ping 使用 ICMP ECHO_REQUEST 获取回应，并在结束时输出丢包和 RTT 统计；traceroute 则通过逐步增加 TTL 追踪到目标的路径。查看 Linux ping 文档与查看 Linux traceroute 文档

需要连续观察时使用 mtr

Linux 或 macOS 安装了 mtr 后，可以执行：

mtr -rwzc 30 节点域名

其中参数写法可能随系统版本变化，先运行 mtr --help 确认。mtr 将 ping 与 traceroute 的功能结合起来，持续输出各跳统计；但其官方说明也提醒，中间路由可能不回应或限制 ICMP，因此某一跳出现丢包而后续跳恢复时，不应直接判定该跳就是故障点。查看 mtr 官方仓库说明

macOS 网络异常的辅助做法

如果怀疑是本机网络配置变化，可以在 macOS 中新建一个网络位置，将当前设置与测试设置分开，测试结束后切回原位置。Apple 将网络位置列为排查连接问题和快速切换网络设置的方式。查看 Apple 网络位置说明

ping 不通怎么办：改测 TCP 或真实代理请求

节点不回应 ICMP，常见解释包括目标或中间设备过滤 ICMP、探测方式与真实业务不同，或者目标确实不可达。因此应把“ICMP 测试失败”和“代理连接失败”分开判断。

Windows 测 TCP 端口

如果你使用 Microsoft Sysinternals 的 PsPing，可以用 TCP 模式测试指定端口：

psping -n 20 节点域名:端口

PsPing 官方说明同时支持 ICMP ping、TCP ping、延迟和带宽测量；使用前应从 Microsoft 官方页面获取工具，并先执行 psping -? 查看当前版本参数。查看 PsPing 官方文档

通过本地代理测试 HTTPS 请求

假设本地代理监听地址为 127.0.0.1:7890，Windows 命令提示符可使用：

curl -x http://127.0.0.1:7890 -o NUL -s -w "连接:%{time_connect} 总计:%{time_total} HTTP:%{http_code}\n" https://example.com/

macOS/Linux 可将 NUL 改为 /dev/null：

curl -x http://127.0.0.1:7890 -o /dev/null -s -w "连接:%{time_connect} 总计:%{time_total} HTTP:%{http_code}\n" https://example.com/

如果本地代理是 SOCKS5，按 curl 文档使用相应协议前缀，例如 -x socks5h://127.0.0.1:1080。curl 的 -x/--proxy 选项用于指定代理，支持 HTTP、HTTPS、SOCKS 等协议形式。查看 curl 官方手册

这个测试更接近“网页是否能打开、TLS 是否能完成、代理是否能把请求送到目标”的真实场景，但它仍然只代表当前目标、当前时刻和当前请求大小。

如何计算与记录延迟、抖动和丢包

建议每个节点至少记录三类时间段：白天、晚高峰、深夜。每个时间段使用相同设备、相同网络、相同目标和相同测试次数，避免把测试条件变化误认为线路差异。

字段	记录方法	用途
丢包率	未收到回应的数量 ÷ 发送数量 × 100%	观察是否存在持续或突发丢包
平均延迟	读取命令输出的平均 RTT	比较总体响应速度
波动范围	最大 RTT − 最小 RTT，或观察标准差/mdev	判断延迟是否忽高忽低
真实请求耗时	记录 curl 的连接时间、总耗时和 HTTP 状态	验证代理后的实际访问

“抖动”通常指连续数据包之间的延迟变化；IETF 将其作为 delay variation 相关指标讨论。查看 IETF 网络测量术语。实际比较时，不要只看最低延迟：如果平均值相近，但一条线路波动和丢包明显更多，网页加载、会议、流式输出和长连接更容易出现卡顿或中断。

结果怎么判断：不要套用一个固定“正常值”

延迟和丢包是否可接受，取决于使用场景和测试对象。下面用条件化方法判断：

网页与普通接口：优先看代理后的请求是否稳定完成，偶尔的单个 ICMP 超时不能单独下结论。
视频会议与语音：重点看连续延迟波动、突发丢包和长时间稳定性，而不是只看一次最低延迟。
实时互动或游戏：更关注持续 RTT、抖动和突发丢包；如果 ping 平均值不高但波动很大，体验仍可能不稳定。
视频播放或大文件：延迟只是建立连接的因素，还要用实际请求或下载观察吞吐和中断情况；本文不对具体速度作保证。
AI 工具或长连接：进行较长时间的实际交互，记录是否出现连接重置、流式输出中断或重复重连。

如果只有中间某一跳显示丢包，而后续跳和最终目标没有同步增加，先不要更换线路；如果从本地网关开始就异常，优先处理 Wi-Fi、路由器或宽带问题；如果本地正常、路径后段和代理请求同时异常，再进一步比较其他节点或联系线路提供方。

失败分流、校验与撤销方法

所有节点都慢：关闭代理，重复本地网关测试；再用另一种网络或网线对照，排除 Wi-Fi、路由器和宽带因素。
只有一个节点异常：分别测试节点域名和 IP；域名异常而 IP 正常，优先检查 DNS。两者都无法通过代理请求，则记录端口、时间和命令结果。
ping 不通但代理能用：保留该结果，改用 TCP 端口和 curl 验证，不要仅凭 ICMP 结论否定节点。
pathping 或 mtr 中间跳丢包：查看后续跳是否持续丢包；中间设备可能只是限制诊断报文。
测试配置影响正常上网：撤销临时 DNS、代理、网络位置或路由改动，恢复原客户端配置；命令测试本身通常不需要修改系统网络设置。

最终记录至少包含：测试日期为 2026-10-27 或实际测试日期、设备、网络类型、节点标识、测试目标、命令、发送数量、平均 RTT、波动范围、丢包率、代理请求结果和时间段。这样才适合横向比较。

常见问题

节点 ping 不通，是不是节点不能用？

不一定。ping 测的是 ICMP，目标或中间设备可能过滤它。继续用 TCP 端口测试，或开启客户端后用 curl 通过本地代理请求 HTTPS 地址。

测节点延迟应该用客户端测试还是 ping？

两者用途不同。客户端测试适合比较探测结果，ping 适合观察 ICMP 路径；最终是否好用，还要用代理后的真实请求和实际业务验证。

为什么 tracert 中间几跳显示星号？

星号只表示该跳在超时时间内没有返回诊断报文。若后续跳和最终目标仍能回应，不能仅凭这一行认定发生了转发丢包。

测试多少次才比较有参考价值？

不要只测一次。基础比较可先发 20 至 30 次；需要观察稳定性时，在白天、晚高峰和深夜使用相同参数重复测试，并记录平均值、波动和丢包。

Windows 上应该优先用 tracert 还是 pathping？

只想快速看路径用 tracert；想观察多次采样后的各跳延迟和丢包现象，用 pathping。pathping 需要等待统计完成，结果不要在刚开始输出时就下结论。

curl 通过代理测试时，127.0.0.1:7890 要怎么改？

把它改成客户端实际监听的本地代理地址和端口；如果客户端提供 SOCKS5 端口，则使用类似 <code>-x socks5h://127.0.0.1:1080</code> 的写法。