外观
本站测速方法：时段、节点、工具与样本
本站计划按一套固定协议做机场测速：先记录本地基线，再在晚高峰与非高峰分别对多个节点多次采样，用可导出原始数值的公开工具测延迟、下载、丢包三项指标，并完整记录环境。当前没有任何品牌完成测量，全部为 Not Tested，本页只描述方法。
核心结论与适用条件
测速最容易出问题的地方不是工具，而是口径。同一个节点，换一个时段、换一台设备、换一个测速服务器，数字都会不同。所以本站先公布协议，再谈数据。下面几条结论都带有适用条件。
- 如果你想知道本站怎么测，那么看本页的六个环节：目的、环境、时段、节点、工具、样本。它们是一个整体，缺一项都不能称为完整协议。
- 如果你想知道某个品牌有多快，那么本站目前给不出答案。17 个品牌的测速字段全部为 Not Tested，品牌资料里的带宽、节点数等表述属于 Vendor Data，不能当作测量结果。
- 如果你准备自己测，那么可以直接照本页的流程做，关键是三件事：先测本地基线、两个时段分开采样、每个节点多次重复。
- 如果你只想快速判断一份别人发的测速结果，那么先看它有没有时间、时段、节点、工具和基线，再看数字。可参考如何系统地阅读一份测速报告。
- 如果你想了解标签含义，那么看七个数据状态标签的定义与使用条件，它规定了 Measured Data 与 Not Tested 何时出现。
适用边界也要说清：本协议面向普通读者可复现的场景，不涉及运营商级别的专业测量，也不包含对任何服务可用性的承诺。协议的作用是让不同人、不同日期得到的结果有机会互相对照，而不是给出一个绝对正确的数字。
测速协议总览：六个环节如何衔接
很多测速文章只说“我测了一下，速度多少”，读者既不知道在什么条件下测的，也无法复核。本站协议把一次测速拆成六个环节，每个环节都要产出可记录的内容。
| 环节 | 要回答的问题 | 必须产出的记录 | 缺失时的后果 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|
| 测试目的与假设 | 这次测量要验证什么 | 一句话的问题陈述 | 事后挑选数字 | 本站口径 | 2026-10-18 |
| 环境与基线 | 本地网络的上限在哪里 | 日期、地点、运营商、接入方式、设备、不开代理的基线 | 无法区分本地瓶颈与线路问题 | 本站口径 | 2026-10-18 |
| 时段安排 | 什么时候测 | 晚高峰与非高峰的时间窗口 | 高峰与非高峰混在一起 | 本站口径 | 2026-10-18 |
| 节点抽样 | 测哪几条线路 | 节点名称、入口与落地信息（缺失写待核实） | 把单节点结论当成品牌结论 | 本站口径 | 2026-10-18 |
| 工具与指标 | 用什么测、测什么 | 工具名称、指标类型、测速服务器位置 | 不同来源的数字无法对照 | 本站口径 | 2026-10-18 |
| 样本与记录 | 测几次、怎么存 | 每次原始数值、剔除理由、数据状态 | 平均值掩盖波动 | 本站口径 | 2026-10-18 |
六个环节的顺序有依据：先有目的，才知道要记录什么环境；先有基线，才能解读后面的数字；先定时段与节点，才能设计样本数量；最后才选工具。很多人把顺序反过来，先打开一个测速网站点一下，再回头找解释，这时已经丢失了大量信息。
测试目的与假设：先写问题，再动手测
协议的第一步是写下一句话的问题。例如“同一节点在晚高峰的下载表现是否比非高峰差”，或者“两个不同落地地区的节点在同一时段的延迟是否有明显差别”。这样做的好处有三点。
第一，决定采样设计。要比较两个时段，就必须保证两个时段的样本数量相当、日期分布相当；要比较两个节点，就必须在相近时间窗口里交替测量，而不是先测完一个再测另一个。
第二，防止事后挑选。如果测完才决定“这次想说明什么”，很容易只展示对结论有利的那部分。先写问题，数据就有了固定的出口。
第三，让读者知道这组数据只回答了什么、没有回答什么。一份回答“晚高峰是否更差”的数据，不能被拿去当作“这个品牌适合看视频”的证据。后者需要另一套测量设计。
本站在未来发布 Measured Data 时，会在每份数据旁写明它对应的问题陈述。当前没有数据，所以这里只描述做法。
环境与本地基线：先量出天花板
测速结果由三段链路共同决定：本地网络、跨境线路、对端服务器。读者最能控制的是第一段，也最容易忽略第一段。
环境记录清单
每次测量开始前，记录以下信息：
- 日期与时刻，精确到分钟，并写明时区。
- 所在城市与运营商，接入方式是有线还是 Wi-Fi，若是 Wi-Fi，记录大致与路由器的距离。
- 设备型号与操作系统。
- 客户端名称、使用的协议、是否开启了分流规则或自动选择。
- 同一网络下是否有其他设备正在大流量使用。
这些信息看起来琐碎，但它们是排除干扰的依据。比如，同一时段家里有人在看高清视频或做系统更新，测出的下载数字就会偏低，这与线路无关。
本地基线怎么测
基线指在不开启代理的状态下，对同一类目标测量延迟、下载和丢包。建议对一个国内目标和一个境外目标各测三次，并在整轮测试前后各记录一次。前后两次基线如果差别明显，说明测试期间本地网络本身在波动，那么这一轮结果要谨慎对待，必要时重做。
基线的意义在于给后续数字画一条天花板。代理测出的下载速度不可能稳定超过本地宽带的实际上限；如果某次读数看起来“接近或超过”基线，要优先怀疑是缓存、测速服务器就近分流或者测量方法本身的问题，而不是线路特别强。关于本地网络对结果的具体影响，可以继续阅读本地网络如何影响测速读数。
示例口径：假设某位读者先在不开代理时测得一组本地基线，再开启代理测同一类目标，那么他应当把两组数字放在同一张表里，分别标注“基线”和“代理”，并用同样的指标顺序排列。这里没有给出任何数值，因为数值取决于读者自己的网络。
时段安排：晚高峰与非高峰分开
时段是测速里影响最大的变量之一。本站把时段分为两类，并要求分开记录。
| 指标 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|
| 晚高峰窗口 | 时间段 | 20:00–23:00（北京时间） | 本站口径 | 2026-10-18 |
| 非高峰窗口 | 时间段 | 晚高峰以外，建议选工作日上午或凌晨 | 本站口径 | 2026-10-18 |
| 每时段最少样本 | 次 | 每个节点每个时段不少于三次 | 本站口径 | 2026-10-18 |
| 日期覆盖 | 天 | 工作日与周末各至少一天 | 本站口径 | 2026-10-18 |
| 同轮间隔 | 分钟 | 同一节点相邻两次之间留出间隔，具体由测试者记录 | 本站口径 | 2026-10-18 |
为什么选 20:00 到 23:00
这个窗口是国内家庭宽带与移动网络使用量通常较高的时间，视频、游戏、社交同时占用带宽，跨境出口更容易出现排队。选择这段时间采样，得到的结果更接近最不利的情况。非高峰作为对照，用来回答“线路平时是什么样”。
需要强调的是，这个窗口是本站的口径，不是对所有地区、所有运营商都成立的普遍规律。不同城市的高峰时间可能略有差异，读者如果发现自己所在地区的拥堵时间明显不同，可以调整窗口，但必须在记录里写明，并保持前后一致。
不要把两个时段求平均
把晚高峰和非高峰的数字合并求平均，是最常见的错误。合并后的数字既不代表高峰，也不代表平时，没有任何场景对应它。正确做法是两个时段各自列出样本、各自看范围和中位数，再并排比较。
同一轮里交替测量
如果要比较两个节点，建议在同一个时间窗口内交替测量：测节点甲，再测节点乙，再回到节点甲。这样两个节点面对的是相近的网络状况。如果先花一小时测完节点甲，再花一小时测节点乙，两者的差异里就混入了时间变化。
节点抽样：不要用一个节点代表一个品牌
机场是一个由多条线路构成的服务。品牌资料通常会提到线路类型、协议等信息，但具体到某个节点的入口城市、落地地区和运营状态，本站没有可核实的数据，统一写待核实。
抽样原则
- 至少覆盖两个不同落地地区的节点，这样才能区分差异来自节点还是来自品牌。
- 如果品牌提供了不同类型的线路，各选一条，并在记录里写明类型。
- 记录节点名称时，使用客户端里显示的原名，不要自己重新命名。
- 若节点在测试期间被品牌调整或下线，记录日期并说明，不要悄悄替换为另一个节点。
入口与落地信息
很多读者关心节点的入口和落地，但这类信息通常需要品牌公开说明或读者自行探测。本站不会凭印象写入口城市或落地地区，品牌资料缺失时一律写待核实。读者自己测试时，可以在记录里留出这两列，能确认就填，不能确认就空着标注“未确认”。
单节点结论的写法
如果只测了一个节点，结论必须限定在这个节点上，例如“该节点在所记录的时段表现如何”，而不是“该品牌如何”。这是协议里最容易被忽略的一条。品牌维度的结论，至少需要多个节点、多个时段的样本支撑，并且仍然要标注适用范围。
工具与指标：测什么、用什么测
本页不点名具体工具，也不写版本号，原因是工具更新会改变测量方式，写出来很快就过期。选择工具时遵循三条原则。
| 原则 | 含义 | 不满足时的风险 | 数据来源 | 更新时间 |
|---|---|---|---|---|
| 公开可获得 | 任何读者都能获取同类工具复现 | 结果只能由少数人验证 | 本站口径 | 2026-10-18 |
| 能导出原始数值 | 不只是一张截图，而是可记录的数字 | 无法做分布分析，也无法复核 | 本站口径 | 2026-10-18 |
| 测速服务器位置可记录 | 知道数据是和哪里的服务器交换的 | 不同服务器之间的数字不可比 | 本站口径 | 2026-10-18 |
三项核心指标
延迟、下载、丢包是协议的核心指标。延迟回答一次往返要多久，下载回答单位时间能传多少数据，丢包回答多大比例的数据包没有到达。三者要同时记录，因为它们互相解释：丢包偏高时，延迟与下载的平均值意义下降；延迟偏高时，即使下载读数不低，网页和交互体验也会显得迟钝。
延迟本身还分好几种，ICMP、TCP、HTTP 测的并不是同一件事，各自对应不同的链路层次。这是一个独立话题，详见ICMP、TCP 与 HTTP 延迟的区别。丢包的测量与解读同样有细节，可以参考丢包专题。
测速服务器的位置
同样的节点，对不同位置的测速服务器测出的结果可能不同。记录服务器的大致位置，并在整轮测试里保持一致。如果在测试中途换了服务器，应当视为新的一轮，而不是同一组样本。
客户端设置要固定
测速前确认客户端处于固定节点状态：关闭自动选择、关闭负载均衡，检查分流规则不会让测速目标走直连。否则你以为测的是某个节点，实际流量可能走了别的出口。手机与桌面的固定方法不同，可参考桌面端客户端的节点固定与规则检查和手机端客户端的对应设置，具体选项名称随客户端而异，请在设置中查找相关选项。
样本与记录：怎样的数据才算数据
样本数量
本站口径是每个节点在每个时段至少三次样本，分布在不同日期。三次是下限，不是可靠性的保证。样本越少，越不能写成肯定性的结论；三次样本只能支持“初步观察”这类表述。
记录格式
每次样本记录一行，字段如下：
| 字段 | 说明 | 数据来源 | 更新时间 |
|---|---|---|---|
| 测试时间 | 日期与时刻 | 测试者记录 | 2026-10-18 |
| 时段 | 晚高峰或非高峰 | 测试者记录 | 2026-10-18 |
| 节点 | 客户端显示的节点名 | 测试者记录 | 2026-10-18 |
| 工具 | 使用的工具名称 | 测试者记录 | 2026-10-18 |
| 测速服务器 | 大致位置 | 测试者记录 | 2026-10-18 |
| 延迟类型与数值 | ICMP、TCP 或 HTTP | 测试者记录 | 2026-10-18 |
| 下载 | 固定时长平均速率 | 测试者记录 | 2026-10-18 |
| 丢包 | 探测包未返回比例 | 测试者记录 | 2026-10-18 |
| 数据状态 | Measured Data 或 Not Tested | 本站规则 | 2026-10-18 |
这张表只是字段说明，没有任何实际数值。下面是本站报告组件的格式展示，数值列同样显示待核实。
Performance Monitoring Report
测速报告格式示例（当前无实测数据）
| 测试时间 | 时段 | 节点 | 延迟 | 下载 | 丢包 | 数据状态 |
|---|---|---|---|---|---|---|
| 待核实 | 晚高峰（20:00–23:00） | 待核实 | 待核实 | 待核实 | 待核实 | Not Tested |
剔除样本的规则
允许剔除样本，但必须写明理由并保留原始记录。合理的理由包括：测试中途本地网络明显切换、客户端崩溃、测速服务器无响应。不合理的理由是“数字太差”。如果节点在某次测试中连不上，应记为 Unavailable，而不是当作没测过。不可用的次数本身就是对读者有价值的信息。
看分布，不只看平均值
记录原始样本后，再看范围、中位数与最差值。两个节点的平均值可能相同，但一个始终平稳，另一个有一半时间几乎不可用。关于如何读分布，可继续阅读样本方差与分布的读法。
常见误区与协议如何应对
测速协议的价值，很大程度上体现在它能挡住哪些常见误区。下面逐一列出，并说明协议里对应的规则。
误区一：测一次就够了
单次测量只能说明那一刻的状况。网络状况每分钟都在变化，一次读数偏高或偏低都可能是偶然。协议要求每个时段至少三次、分布在不同日期，目的就是让偶然因素有机会被看见。三次仍然不多，所以协议同时要求把结论写成“初步观察”，而不是定论。
误区二：数字越高越能说明问题
一个很高的下载读数，可能来自就近的测速服务器、缓存命中，或者测试时长太短、尚未进入持续传输阶段。协议要求注明服务器位置、固定测试时长，并与本地基线对照。读数接近本地上限时，更应该怀疑方法，而不是庆祝结果。
误区三：延迟低就等于体验好
延迟只回答往返时间，不回答能传多少，也不回答是否经常丢包。一个延迟很低但丢包频繁的节点，在视频通话和在线会议里会反复卡顿。协议要求三项指标一起记录，就是为了避免只盯着一项下结论。
误区四：别人的数字可以直接拿来比
两份数字能比较的前提，是时间、时段、节点类型、工具、服务器位置大致一致。其中任何一项不同，都要先说明差异再比较。当协议要求每行记录都带上这些字段时，读者才能判断两份数据到底能不能放在一起。
误区五：测速能代替可用性检测
测速回答“有多快”，可用性检测回答“能不能完成某个操作”。两者的测量对象不同，不能互相替代。品牌资料显示覆盖相关使用场景，具体可用性、解锁状态及节点表现可能随 IP、地区和平台策略变化，建议以最新实际测试结果为准。可用性检测的口径在可用性检测专题里单独讨论。
示例口径：一份假设的记录是怎样组织的
为了说明记录该怎么写，这里给出一个明显假设化的示例口径。示例中没有任何数值，所有“待填”都由读者在自己的环境中测得。
- 问题陈述：假设读者想知道“同一节点在晚高峰是否比非高峰更不稳定”。
- 环境：写下日期、城市、运营商、有线接入、设备型号、客户端名称、协议。
- 基线：不开代理，对一个国内目标和一个境外目标各测三次，延迟、下载、丢包均为“待填”。
- 采样：非高峰三次、晚高峰三次，分布在两个不同日期，每次记录延迟类型、下载、丢包，数值均为“待填”。
- 整理：按时段分别列出，各自看范围与最差值，不合并求平均。
- 结论写法：若三次样本显示差异明显，只写“在所记录的条件下观察到差异，样本较少，需更多重复”；若差异不明显，同样写明样本数与条件。
这个示例想说明的不是结果，而是顺序：先写问题，再测基线，再分时段采样，最后才下一句有限制条件的结论。任何一步被跳过，结论的可信度都会打折扣。
决策树：一次测速该怎样开始
Decision Path
开始一次测速前的检查
text
准备测某个节点
│
├─ 已经写下这次要回答的问题了吗？
│ ├─ 否 → 先写一句话的问题陈述
│ └─ 是 → 继续
│
├─ 测过不开代理的本地基线吗？
│ ├─ 否 → 先测基线，前后各记录一次
│ └─ 是 → 继续
│
├─ 客户端固定在目标节点了吗？
│ ├─ 否 → 关闭自动选择与负载均衡，检查分流规则
│ └─ 是 → 继续
│
├─ 现在是哪个时段？
│ ├─ 20:00–23:00 → 记为晚高峰样本
│ └─ 其他时间 → 记为非高峰样本
│
├─ 这个节点在该时段已有三次、分布在不同日期的样本吗？
│ ├─ 否 → 继续采样，当前只能称为初步观察
│ └─ 是 → 继续
│
└─ 是否覆盖了至少两个不同落地地区的节点？
├─ 否 → 结论限定在单个节点，不写品牌结论
└─ 是 → 整理为七列记录，标注数据状态知识图谱：测速协议
实体定义：测速协议是一份事先公布、可被他人复核的测量流程，规定在什么环境、什么时段、对哪些节点、用什么工具、取多少样本、如何记录。
相关概念：本地基线、晚高峰、非高峰、节点抽样、样本分布、数据状态标签。
技术参数：延迟（ms，注明类型）、下载（Mbps，注明测速服务器位置）、丢包（%，固定数量探测包未返回比例）。具体数值取决于读者自己的网络，本站当前无实测数值。
适用场景：读者自测、比较两个节点、核对他人发布的测速结果是否有可比性。
对比依据：口径是否一致，而不是数字大小。不同时段、不同工具、不同服务器得到的数字不能直接比较。
常见问题指向：为什么要先测基线、为什么两个时段分开、样本不足怎么写结论、本站现在有没有数据，详见下方常见问题。
方案关联：本站测试方案与品牌数据的关系
主题是测试方法，与具体品牌无关，所以这里讨论的是“方案”：本站的测试方案与品牌库字段的关系。
| 项目 | 当前状态 | 说明 | 数据来源 | 更新时间 |
|---|---|---|---|---|
| 品牌价格、流量、线路、协议、客户端 | Vendor Data | 来自品牌公开资料，未经本站验证 | 品牌公开资料/用户提供清单 | 2026-10-18 |
| 延迟、下载、丢包 | Not Tested | 本站未按协议完成测量，显示待核实 | — | 2026-10-18 |
| AI 与流媒体相关使用场景 | Vendor Data 或 Not Tested | 品牌资料显示覆盖相关使用场景，具体可用性、解锁状态及节点表现可能随 IP、地区和平台策略变化，建议以最新实际测试结果为准 | 品牌公开资料/用户提供清单 | 2026-10-18 |
| Measured Data | 无 | 当前没有任何一行满足协议要求 | — | 2026-10-18 |
品牌库中每个字段都带有状态标签。在比较不同方案的价格与线路时，可以回到横向对比入口按需要筛选，再按本页协议自行验证。
优点、限制与风险提示
优点
- 口径公开，任何人都可以照做并发现问题，这比单方面发布数字更容易被纠错。
- 把环境、时段、节点、工具、样本全部纳入记录，结果之间有机会互相对照。
- 先写假设，可以降低事后挑选数据的可能。
- 对不可用样本一视同仁地记录，避免只展示好看的部分。
限制
- 协议面向普通读者可复现的场景，无法覆盖运营商级别的专业测量。
- 样本数量的下限较低，三次样本只能支持初步观察，不足以支撑强结论。
- 本站当前没有任何 Measured Data，协议暂时只是方法。
- 结果只对记录的时间、节点和网络环境成立，不能外推到其他用户。
风险提示
- 不要把单次测速截图当作协议数据，截图缺少时段、样本数和基线。
- 不要把品牌宣传的带宽或“不限速”表述当作测量结果，它们属于 Vendor Data。
- 不要用某次测速结论推断 AI 或流媒体场景的可用性，那需要独立的可用性检测，具体可用性可能随 IP、地区和平台策略变化。
- 测试时注意遵守所在地法律法规与服务条款，本页只讨论技术方法。
常见问题
本站的测速协议由哪几个部分组成？
协议由六个部分组成：测试目的与假设、环境与基线记录、时段安排、节点抽样、工具与指标、样本与记录。六部分缺任何一项，结果都无法被他人复核，因此本站要求同时公布，而不是只公布数字。
为什么测速前必须先记录本地基线？
本地宽带、Wi-Fi 信号、路由器与设备性能都会成为测速结果的上限。不开代理先测一次基线，才能区分瓶颈来自本地网络还是来自代理线路。没有基线的数字，读者无法判断它离上限有多远。
晚高峰和非高峰为什么要分开采样？
两个时段的网络负载不同，跨境链路在使用量集中的时段更容易出现拥塞。分开采样可以区分线路本身的问题和高峰拥塞的问题，合并求平均会把这两种情况混在一起，得到一个谁也解释不了的数字。
节点抽样应该怎么选，为什么不能只测一个节点？
同一品牌不同节点、不同落地地区之间的差异，可能大于不同品牌之间的差异。至少覆盖两个不同地区的节点，并记录入口与落地信息，才能判断差异来自节点还是来自品牌。品牌资料中缺失的节点信息统一写待核实。
测速工具应该怎么选择？
选择工具遵循三条原则：公开可获得、能导出原始数值而不只是截图、测速服务器位置可指定或至少可记录。本页不点名具体工具和版本，读者应在记录里写明自己实际使用的工具，因为工具更新会改变测量方式。
每个节点至少需要多少样本才算有效？
本站口径是每个节点在每个时段至少三次样本，且分布在不同日期，并覆盖工作日与周末。样本数量只是下限，不是保证结论可靠的门槛。样本少时只能描述为初步观察，不能写成稳定的结论。
被剔除的样本应该如何处理？
剔除样本必须写明理由，例如测试中途网络切换、客户端崩溃或服务器无响应，并保留原始记录。不允许因为数字难看而剔除。不可用的样本本身就是有效信息，应当记为 Unavailable，而不是丢弃。
本站现在有哪些品牌的实测数据？
当前没有。17 个品牌的价格、流量、线路、协议等字段为 Vendor Data，测速字段全部为 Not Tested。本页只公布协议，不包含任何实测数字，示例中出现的数字一律标注为示例口径且为假设值。
协议里的假设检验是什么意思？
指在测试前先写下要验证的问题，例如晚高峰是否比非高峰更差，再决定测什么、测几次。先写假设可以避免事后挑选对自己有利的数字，也让他人明确这组数据到底回答了什么问题。
读者自己复现这套协议需要什么条件？
需要一台固定设备、一段可控的网络环境、一个能指定节点的客户端、一份记录表，以及愿意在不同日期和时段重复测量的耐心。不需要特殊设备，但必须全程记录环境信息，否则结果无法与他人比较。
延伸阅读与下一步
Cluster · method
测试方法
- 本站测速方法：时段、节点、工具与样本本站计划如何进行测速，口径是什么？
- 延迟指标：ICMP、TCP 与 HTTP 延迟的区别不同延迟测试方式测的是什么？
- 下载测速工具对比与误差来源常用测速工具的结果为什么不一致？
- 丢包率测试方法与解读如何测丢包率，多少算正常？
- 晚高峰采样：为什么单次测速不够为什么需要多次、分时段测速？
- 服务可用性测试：AI 与流媒体的检测口径AI 和流媒体的可用性应该怎么测？
- 数据状态标签说明：从 Operational 到 Measured Data本站的数据状态标签分别代表什么？
- 想回到测试方法与数据说明的总览，可以看测试方法与数据说明专题首页。
- 想弄清每个状态标签何时出现，可以看七个状态标签的定义。
- 想理解延迟数字的含义，可以看三种延迟指标的区别。
- 想学会读别人发的测速结果，可以看读测速报告的顺序。
- 想先缩小候选范围，可以回到横向对比入口，或回到选型清单看价格口径与适用场景。
- 想了解使用风险与合规边界，可以看风险与合规指南。
- 想查看品牌资料全貌，可以进入品牌库。
信息来源与更新日期
- 信息来源：通用技术资料；品牌公开资料/用户提供清单。
- 数据核实日期：2026-10-18。
- 最近更新时间：2026-10-18。
- 说明：本页不含任何实测数字；所有品牌当前均为 Vendor Data，测速为 Not Tested。