外观
丢包率测试方法与解读
丢包率是在一次测量中发出的探测包里没有收到响应的比例，测法是向固定目标发送足够多的探测包并记录丢失数量，同时在晚高峰与非高峰分别重复。
至于“多少算正常”，不存在适用于所有场景的统一数值：要对照你自己的本地基线、看丢包是持续还是突发、再结合用途判断。本站当前没有任何品牌的实测数据，本文只讲方法与解读原则。
先说一个容易被忽略的前提：丢包不是“节点好坏”的单一指标。它可能发生在你的无线网络、宽带接入、跨境链路，也可能是目标设备故意不响应探测。找到丢包发生的位置，比得到一个百分比更有价值。
核心结论与适用条件
- 如果你想知道丢包率“多少算正常”，那么先测本地基线：不开代理时对同类目标的丢包情况。代理链路的结果要和这个基线对照，而不是和一个来历不明的数字对照。
- 如果丢包偶尔出现且很快消失，那么多半是突发性的短时拥塞或无线干扰，对网页浏览影响有限，但对语音通话、实时游戏可能有明显感受。
- 如果丢包在晚高峰持续偏高、非高峰却消失，那么更像是拥塞型丢包，问题与时段强相关，需要按晚高峰采样的安排方式分开记录。
- 如果逐跳测试显示中间某一跳丢包很高、但后续跳数一切正常，那么这通常是该路由设备对探测包限速响应的假象，不是真实丢包。
- 如果你只用 ICMP 探测得出丢包率，那么要意识到 ICMP 可能被限速或被优先级降低，结论需要用 TCP 或应用层的观察交叉验证。
本文的立场与站内其他方法文章一致：不给阈值数字，不排名，不推荐任何品牌或工具。品牌之间的比较目前只使用 Vendor Data 字段。
什么是丢包，它发生在哪里
网络按“包”传输数据。一个包在途中被丢弃、没有到达目的地，或者到达了但响应没有回来，就记为一次丢包。丢包率就是丢失的包占发出包总数的比例。公式只有一个：丢失数除以发送数。
示例口径：假设发出了若干个探测包，其中丢失了一小部分，丢包率就是丢失个数除以发出个数。这里不使用任何真实数字，因为丢包率的含义取决于样本总数与场景。
丢包发生的位置
| 发生位置 | 典型成因 | 现象特点 | 能否从本地判断 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|
| 本地无线网络 | 信号弱、干扰、距离路由器远 | 与你的位置、设备和同频设备数量相关；不开代理也会丢 | 能，基线测试即可暴露 | 通用技术资料 | 2026-10-18 |
| 本地路由与宽带接入 | 设备过载、线路质量、运营商接入侧拥塞 | 同一时段所有目标都受影响 | 能，对多个国内目标测基线 | 通用技术资料 | 2026-10-18 |
| 运营商骨干与出口 | 高峰时段链路饱和 | 晚高峰上升，非高峰缓解 | 部分能，逐跳测试可提示位置 | 通用技术资料 | 2026-10-18 |
| 跨境链路 | 带宽紧张、路由策略变化 | 与时段和路径相关，某些线路更明显 | 间接，需对比不同节点 | 通用技术资料 | 2026-10-18 |
| 节点或落地侧 | 服务器过载、限速策略、网络波动 | 只影响某个节点或某个地区 | 间接，换节点对比 | 通用技术资料 | 2026-10-18 |
| 目标设备 | 故意忽略或限速响应探测 | 探测显示丢包，实际访问正常 | 能，换目标或换协议验证 | 通用技术资料 | 2026-10-18 |
这张表的用法：当你看到丢包，先想它可能在哪一段。本地段可以靠基线排除，跨境段与节点段则靠“不同节点、不同时段”的对比缩小范围。线路类型对丢包的波动特征有影响，背景可参考线路结构与波动的关系。
为什么拥塞会造成丢包
路由设备的输出端口有队列，包到达速度超过转发速度时，包先排队；队列满了，新来的包被丢弃。这是互联网上丢包最常见的原因。传输层协议会把丢包当作拥塞信号，自动降低发送速率。所以丢包既是链路状态的体现，也直接压低了单连接的吞吐。
这一点对理解“为什么丢包不高，下载却不快”很重要：对依赖重传的连接来说，少量丢包就足以让窗口频繁收缩。反过来，对于视频通话这类实时应用，重传来不及，丢包直接表现为声音断续、画面卡顿。同一个丢包率，对不同用途的影响程度完全不同。
如何测丢包率：四种方法
没有哪种方法能单独给出完整答案，常用的是按顺序组合。
| 方法 | 测量对象 | 优点 | 局限 | 适合回答的问题 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|
| 固定目标连续探测 | 终端到目标的 ICMP 往返 | 简单直观，易于重复 | 目标或中间设备可能限速响应 | 到这个目标是否有明显丢包 | 通用技术资料 | 2026-10-18 |
| 逐跳路径测试 | 沿途每一跳的响应 | 可以提示丢包出现在哪一段 | 中间节点对探测限速会造成假象 | 丢包大致发生在路径的哪里 | 通用技术资料 | 2026-10-18 |
| TCP 层观察 | 重传、连接超时等迹象 | 更接近应用实际受影响情况 | 需要工具支持，解读门槛较高 | 应用是否真的受到丢包影响 | 通用技术资料 | 2026-10-18 |
| 应用场景实测 | 语音通话、视频、实时交互的表现 | 贴近真实体验 | 主观，难量化，受应用自身适应策略影响 | 实际用起来是否可接受 | 通用技术资料 | 2026-10-18 |
固定目标连续探测
最基础的做法是对一个稳定的目标连续发送探测包，统计响应情况。设计时有几个要点：
- 样本数量要足够：探测包太少，一两个丢失就会让百分比大幅跳动。数量越多，结果越稳定，但也越耗时。具体数量取决于你想要多精细的分辨率，本文不给固定值，建议在记录里写明实际数量。
- 间隔要合理：发送间隔太短，可能触发目标或中间设备的速率限制；太长则一次测量耗时过长。需要在两者之间取舍并写进记录。
- 目标要固定：每次测量使用同一个目标，至少在一组需要比较的测量里保持一致，否则目标本身的差异会混进结果。
- 同时记录延迟：探测包返回的往返时间可以顺带记录，观察延迟的波动（抖动）与丢包是否同时出现，它们常常是同一问题的两个侧面，延迟本身的类型见延迟指标的类型与读法。
要注意的是，用 ICMP 探测经过代理的路径本身存在争议：很多代理场景下，ICMP 包并不是被代理转发的，你得到的结果可能反映的是到节点入口的路径，而不是经过代理到目标的路径。所以对代理链路的丢包，ICMP 结果必须谨慎解读，下文会讲交叉验证。
逐跳路径测试
逐跳测试会沿路径依次测每一跳的响应，帮助定位丢包出现在哪一段。它的解读有一个经典陷阱：某一跳显示高丢包，但后面的跳数都正常，这几乎总是该设备对探测响应做了限速或降低优先级，而不是真的丢了转发的数据。
判断真实丢包的原则是：丢包应该“向后传递”。如果从某一跳开始，往后每一跳都显示丢包并且程度相近，那才是该位置之后的真实问题；如果只有中间某一跳孤立地高，后面恢复正常，那是假象。这个判读规则只依赖路径测试的基本原理，不需要具体数值。
TCP 层与应用层观察
比起 ICMP 探测，更接近实际体验的是观察传输层与应用层的现象：下载速率曲线出现周期性下滑、连接偶尔超时重连、网页部分资源加载失败又自动重试。这些现象与丢包之间的关系是间接的，但它们说明的是“丢包已经影响到你的应用”这个事实，比探测百分比更贴近决策需求。
具体到测量工具，不同软件对重传、往返时间的输出各不相同，本文不点名，读者可以在所用工具的说明中查找“重传”“重新发送”之类的统计项。工具之间的差异与误差来源见测速工具的类型与误差来源。
应用场景实测
对大多数读者，最终判断标准是实际使用感受：语音通话是否断续，视频是否频繁缓冲，实时交互是否跳帧。这类测试没有精确数字，但可以记录为“某时间、某节点、某应用，是否出现可感知的卡顿”。把主观感受与前面的客观记录配合，能帮助你理解哪种程度的丢包对你的使用已经构成问题。
决策树：看到丢包后怎么排查
Decision Path
丢包排查路径
text
发现丢包 / 连接卡顿
│
├─ 不开代理，对国内与境外目标测基线，也有丢包吗？
│ ├─ 是 → 问题在本地网络
│ │ ├─ 换有线连接是否缓解？ → 是：无线问题
│ │ └─ 否 → 路由器 / 宽带接入 / 运营商
│ └─ 否 → 继续
│
├─ 开代理后是否只在某些节点丢包？
│ ├─ 是 → 节点或线路问题 → 换节点对比，记录落地地区
│ └─ 否（所有节点都丢）→ 继续
│
├─ 丢包是否随时段变化？
│ ├─ 晚高峰高、非高峰低 → 拥塞型 → 按两个时段分开记录
│ └─ 全天持续 → 线路或策略问题 → 联系服务方并保留记录
│
├─ 逐跳测试中丢包是否向后传递？
│ ├─ 否（孤立一跳）→ 探测限速假象，忽略
│ └─ 是 → 以该跳之后为问题位置
│
└─ 换用 TCP 或应用层观察交叉验证
├─ 应用无感 → 探测限速或目标不响应
└─ 应用受影响 → 记录时间、节点、现象，作为条件化结论多少算正常：一套判读框架而不是一个阈值
读者最想要的是一个数字：低于它算正常，高于它算有问题。本站不给，原因有三。第一，丢包率的含义依赖样本数量、探测协议和目标类型，脱离这些条件的阈值没有意义。第二，不同用途的容忍度差异很大，浏览网页能容忍的丢包，对语音通话和实时游戏可能已经难以接受。第三，任何一个固定数字都会被读者当作评价品牌的标准，而本站没有符合口径的测量来支撑这种评价。
替代的做法是一套四步判读。
- 对照基线：代理链路的丢包，要和同时段不开代理的本地基线比较。如果基线已经有可观的丢包，说明问题大部分来自本地，代理的结果不能归咎于线路。
- 看持续性与形态：均匀分布的低水平丢包，与短时间内成团出现的突发丢包，对应用影响不同。突发丢包让连接看起来“偶尔卡一下”，均匀丢包则让吞吐持续被压低。记录时不仅记百分比，也记它是均匀还是成团。
- 看是否与时段相关：与晚高峰相关的丢包，说明是拥塞性质，换时段使用也许就能回避；与时段无关的持续丢包，更可能是线路或策略问题。
- 对照用途：把测到的现象放进你的真实用途里判断。你的用途是以文本为主的网页和聊天，还是实时语音与视频，决定了同样的丢包是否构成问题。
按这个框架，“多少算正常”变成了“相对于我的基线，在我的时段，对我的用途，是否可以接受”。这个答案是条件化的，而且只对你自己的环境成立。
丢包与延迟、下载的关系
三项指标之间有因果联系，但不是简单的线性关系。丢包会触发重传，使吞吐下降、延迟上升；延迟高的链路在丢包后恢复得更慢；下载速率低时，既可能是丢包造成的，也可能是带宽本身有限。单看任何一项都可能误判，所以本站的测速报告始终同时记录三项。读报告时可以参考测速报告的阅读顺序，了解三项之间怎样互相印证。
样本设计：让丢包数据可比较
丢包是波动性很强的指标，单次测量几乎没有解读价值。下面是让数据可比较的设计要点。
| 指标 | 做法 | 单位 | 统计口径 | 目的 | 记录内容 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|---|
| 时段 | 晚高峰与非高峰各安排多次 | 时段 | 本站推算的测试设计口径，非实测 | 区分拥塞与持续问题 | 每次的日期与时刻 | 本站口径 | 2026-10-18 |
| 重复 | 同一条件至少三次，分布在不同日期 | 次 | 本站推算的测试设计口径，非实测 | 降低偶然性 | 每次的原始结果，不做剔除 | 本站口径 | 2026-10-18 |
| 节点 | 至少两个不同落地地区 | 个 | 本站推算的测试设计口径，非实测 | 区分节点与品牌差异 | 节点名称与落地地区 | 本站口径 | 2026-10-18 |
| 基线 | 测量前后各一次不开代理的结果 | 次 | 本站推算的测试设计口径，非实测 | 排除本地因素 | 目标、协议、结果 | 本站口径 | 2026-10-18 |
| 探测参数 | 探测协议、包数量、间隔固定 | 包、秒 | 通用技术定义 | 保证可比性 | 参数写进表头 | 本站口径 | 2026-10-18 |
| 分布而非平均 | 记录范围、中位数与最差值 | % | 通用技术定义，丢包率以百分比表示 | 反映波动 | 全部样本 | 本站口径 | 2026-10-18 |
关于如何整理多次样本并解读它们的离散程度，参见波动与分布的读法。需要提醒的是：测丢包本身会产生流量，对小流量套餐用户，探测包数量不宜过大，且应避免长时间连续探测。
不同用途对丢包的敏感度
同样的丢包，落在不同应用上的后果差别很大。下表只描述通用机制，不含任何数值。
| 用途 | 对丢包的反应机制 | 可感知的现象 | 排查时优先看什么 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|
| 网页浏览与文本类应用 | 依赖重传，丢失的包会补发，主要增加等待时间 | 个别资源加载变慢或需要刷新 | 延迟波动与重传 | 通用技术资料 | 2026-10-18 |
| 大文件下载 | 丢包使窗口收缩，吞吐下降 | 速率曲线周期性下滑 | 丢包与延迟的组合 | 通用技术资料 | 2026-10-18 |
| 流媒体点播 | 依赖缓冲区，短时丢包可被缓冲吸收 | 缓冲时间变长，清晰度自动下调 | 持续性而非瞬时值 | 通用技术资料 | 2026-10-18 |
| 语音与视频通话 | 实时性强，重传往往来不及 | 声音断续、画面卡顿 | 突发丢包与抖动 | 通用技术资料 | 2026-10-18 |
| 实时交互与游戏 | 对延迟和丢包都敏感 | 操作延后、画面跳变 | 抖动与突发丢包 | 通用技术资料 | 2026-10-18 |
读这张表的方法是反向使用：先确定你的主要用途，再决定该盯哪种形态的丢包。以文本为主的用户，关注点是整体是否可用；经常实时通话的用户，应更关注突发丢包与抖动，并且要在自己真实使用的时段采样。涉及流媒体或 AI 工具的使用场景时，品牌资料显示覆盖相关使用场景，具体可用性、解锁状态及节点表现可能随 IP、地区和平台策略变化，建议以最新实际测试结果为准，丢包数据只能说明链路连续性，不能替代这类条件化检测，其口径见可用性检测的口径。
如何书写一份丢包记录
丢包记录的价值取决于是否完整。建议每条记录至少回答七个问题：什么时间测的，处于哪个时段；测的是哪个节点，落地在哪里；用的是什么协议的探测，发了多少个包，间隔多长；目标是什么；本地基线是多少；丢包是均匀还是突发；当时有没有同步观察到延迟波动或应用层现象。
示例口径：下面是一条纯假设的记录写法，仅用来演示格式，数字部分用占位词表示。“某日晚高峰，节点甲，探测协议乙，发送若干个包，丢失若干个，形态为成团出现，同时本地基线无明显丢失，应用层观察到通话断续。”这条记录没有给出任何数值，因为真实数值只能来自读者自己的测量。它的价值在于七个问题都有了回答，之后别人才有机会复现。
写记录时还有三个习惯值得保持。第一，保留所有样本，包括看起来异常的，不要私自剔除，确需剔除时写明理由。第二，不要把不同探测协议的结果放进同一列求平均。第三，每次结论都带上条件，例如“在该时段、该节点、该探测方式下观察到”，避免把条件化结果写成对线路的长期判断。
知识图谱：丢包率测试
实体定义
丢包率：在一次测量中，已发送的探测包里没有收到对应响应的比例。它的值依赖探测协议、包数量、间隔、目标和时段，不能脱离这些条件独立引用。
相关概念
- 抖动：往返时间的变化程度，常与丢包同时出现。
- 拥塞丢包：队列溢出引起的丢弃，随时段变化。
- 探测限速：设备故意降低对探测包的响应，造成假性丢包。
- 重传：传输层对丢失数据的补发，会拉低吞吐。
- 本地基线：不开代理时的测量，是排除本地因素的参照。
- 突发丢包与均匀丢包：丢失在时间上的分布形态。
技术参数
丢包记录应包含：丢包率（%，注明探测协议）、探测包数量、发送间隔、目标、测试时间与时段、节点与落地地区、本地基线、丢包形态（均匀或突发）。缺失项一律写“待核实”。
适用场景
- 视频通话或实时应用卡顿时，判断是否由丢包引起。
- 晚高峰体验变差时，区分拥塞与其他原因。
- 在选购前的试用期，对候选节点做统一口径的比较。
- 阅读他人给出的丢包数字时，核对其口径是否完整。
对比依据
本站对品牌的比较只使用 Vendor Data 字段，不使用未经口径验证的丢包数字。比较方法与边界见横向对比页的口径说明。
常见问题指向
关于定义与成因的问题见“什么是丢包”；关于测法的问题见“如何测丢包率”；关于阈值的问题见“多少算正常”；关于样本设计的问题见“样本设计”。
方案关联：与测试方案的衔接
丢包测试不对应某个具体品牌，它是测试方案里的一环。在本站的整体测试方案里，丢包与延迟、下载构成三项指标，与时段采样、节点覆盖、本地基线一起使用，完整步骤见测试协议的整体步骤。如果你手头有候选品牌，可以先在品牌库中核对各候选品牌的资料与状态标注，再用上述方法自行测量；决定测不测、测哪些的流程，在选型核对清单中有说明。
当前状态如下表，仅作为事实陈述：
| 项目 | 状态 | 说明 | 数据来源 | 更新时间 |
|---|---|---|---|---|
| 17 个品牌的丢包字段 | Not Tested | 本站尚未按公开口径完成任何测量 | 本站口径 | 2026-10-18 |
| 品牌资料中的线路、协议、流量字段 | Vendor Data | 来自品牌公开资料，未经本站验证 | 品牌公开资料/用户提供清单 | 2026-10-18 |
| 本文的示例 | 示例口径 | 均为假设，不代表任何品牌 | 本站口径 | 2026-10-18 |
报告格式如下，当前没有实测数据，数值列显示待核实：
Performance Monitoring Report
含丢包列的测速报告格式（当前无实测数据）
| 测试时间 | 时段 | 节点 | 延迟 | 下载 | 丢包 | 数据状态 |
|---|---|---|---|---|---|---|
| 待核实 | 晚高峰（20:00–23:00） | 待核实 | 待核实 | 待核实 | 待核实 | Not Tested |
优点、限制与风险提示
优点
- 把丢包拆成位置、成因、测法、判读四个层次，读者可以逐层排查。
- 不给阈值，避免读者把一个脱离条件的数字当作评价标准。
- 强调基线、时段与分布，使自测结果可复现、可比较。
- 对逐跳测试的假象与 ICMP 局限给出明确提醒，减少常见误判。
限制
- 本文无法回答某个品牌的丢包率，因为当前没有 Measured Data。
- 丢包测试依赖读者自行执行，执行不完整时结果仍不可比。
- ICMP 探测在代理场景下的含义有限，需要配合应用层观察。
- 中间设备的策略读者无法观测，只能通过多次采样和多节点对比间接判断。
风险提示
- 用单次、单时段的丢包数字下结论，容易把偶发现象当成线路问题。
- 对第三方目标高频连续探测，可能触发对方的速率限制，应控制频率和时长。
- 小流量套餐上长时间连续探测会消耗额度，需要控制样本数量。
- 把探测限速造成的假象当作真实丢包，会导致错误地更换节点或服务。
- 本文的方法说明不构成对任何品牌或工具的推荐。
常见问题
如何测丢包率？
向一个固定目标连续发送足够多的探测包，统计没有收到响应的比例，并在晚高峰与非高峰分别重复多次。同时要先测不开代理的本地基线，记录探测协议、包数量、间隔和目标。单次测量几乎没有解读价值，应保留全部原始样本。
丢包率多少算正常？
不存在适用于所有场景的统一数值。判读时先对照同时段的本地基线，再看丢包是持续还是突发、是否随时段变化，最后结合用途判断，浏览网页与语音通话的容忍度差别很大。本站不给固定阈值，也不据此评价任何品牌。
丢包发生在哪些位置？
可能发生在本地无线网络、本地路由与宽带接入、运营商骨干与出口、跨境链路、节点或落地侧，也可能只是目标设备对探测限速响应。本地段可靠基线排除，其余段靠不同节点、不同时段的对比逐步缩小范围。
为什么拥塞会造成丢包？
路由设备的输出队列有限，包到达速度超过转发速度时先排队，队列满后新到的包被丢弃。传输层把丢包当作拥塞信号并主动降速，所以丢包既反映链路状态，也直接压低单连接吞吐。晚高峰这类现象通常更明显。
逐跳测试里某一跳丢包很高，是不是那里出了问题？
不一定。如果只有孤立的一跳显示高丢包，而后面的跳数恢复正常，通常是该设备对探测包限速或降低优先级造成的假象。真实丢包应当向后传递：从某一跳开始往后各跳都出现相近程度的丢包，才说明问题在该位置之后。
用 ICMP 测代理链路的丢包可靠吗？
可靠性有限。很多代理场景下 ICMP 包并不经代理转发，结果可能只反映到节点入口的路径；ICMP 本身还可能被中间设备限速。建议配合 TCP 层或应用层观察交叉验证，并在记录里注明探测协议。
丢包为什么会让下载变慢？
传输层协议把丢包当作拥塞信号，会缩小发送窗口并重传丢失的数据，吞吐因此下降，延迟也可能上升。往返时间越长的链路，丢包后恢复越慢。所以下载慢时，应同时查看丢包和延迟，判断原因是丢包还是带宽本身有限。
突发丢包和均匀丢包有什么区别？
均匀丢包在时间上分布平均，会持续压低吞吐；突发丢包在短时间内成团出现，表现为偶尔卡一下。两者对应用的影响不同，实时语音和视频对突发丢包尤其敏感。记录时除了百分比，也应记下丢包的形态。
小流量套餐测丢包要注意什么？
探测会产生流量，应控制探测包数量，避免长时间连续探测，把额度留给真正的使用。可以先用少量探测完成基线对比，只在需要确认的节点上增加样本。套餐流量规则以品牌官网为准，本站资料缺失的写待核实。
本站现在有各品牌的丢包数据吗？
没有。17 个品牌的丢包字段均为 Not Tested，本站尚未按公开口径完成任何测量，也不提供推测值。品牌资料中的线路、协议、流量等字段是 Vendor Data，未经本站验证。本文只公布方法，供读者自行复现。
下一步
建议的顺序：先测一次本地基线，再选定一个节点按晚高峰与非高峰各测几次，最后用决策树判断问题位置。需要整体框架时，回到测试方法与数据说明总览；想了解为什么很多宣传数字缺少可比性，可以看品牌自述数据的解读方式；想知道状态标签怎样使用，可以看状态标签的使用规则。
Cluster · method
测试方法
- 本站测速方法：时段、节点、工具与样本本站计划如何进行测速，口径是什么？
- 延迟指标：ICMP、TCP 与 HTTP 延迟的区别不同延迟测试方式测的是什么？
- 下载测速工具对比与误差来源常用测速工具的结果为什么不一致？
- 丢包率测试方法与解读如何测丢包率，多少算正常？
- 晚高峰采样：为什么单次测速不够为什么需要多次、分时段测速？
- 服务可用性测试：AI 与流媒体的检测口径AI 和流媒体的可用性应该怎么测？
- 数据状态标签说明：从 Operational 到 Measured Data本站的数据状态标签分别代表什么？
信息来源与更新日期
- 信息来源：通用技术资料（网络丢包成因、探测方法的通用原理）；品牌字段来自品牌公开资料/用户提供清单。
- 数据状态：全部品牌字段为 Vendor Data，测速与丢包为 Not Tested，本文不含任何实测数值；文中示例为示例口径，属假设。
- 数据核实日期：2026-10-18
- 最近更新时间：2026-10-18
- 本文不包含用户评价、亲自使用经历或测速截图。