外观
实测方法与环境说明
每条实测必须记录
运营商 · 城市 · 宽带带宽 · 客户端与版本 · 协议 · 日期与时刻
没有环境说明的测速图没有参考价值。
为什么这六项都必须有
| 项目 | 缺了会怎样 |
|---|---|
| 运营商 | 无法判断本网 / 跨网——电信走 CN2、联通走 AS9929、移动走 CMI 的差异很大 |
| 城市 | 无法判断到国内入口机房的距离（差 20–40ms） |
| 宽带带宽 | 无法判断测出的速度是否受本地接入限制 |
| 客户端与版本 | 协议实现与配置会影响结果 |
| 协议 | TCP 系与 UDP 系在高丢包链路上表现不同 |
| 日期与时刻 | 白天与 21:00 可以差 3–5 倍——这是最关键的一项 |
另外还应该记录：
| 项目 | 为什么 |
|---|---|
| 有线还是 Wi-Fi | Wi-Fi 的丢包会污染所有判断 |
| 节点的完整名字 | 机场调整节点时名字是唯一锚点 |
| 节点的倍率 | 影响实际可用流量 |
| 测试方法（样本量、线程数） | 可复现性的前提 |
六项缺失的实际后果
一张"香港节点 200Mbps"的截图，如果不知道这六项，你无法回答：
| 问题 | 为什么答不了 |
|---|---|
| 这是白天还是晚高峰？ | 差 3–5 倍 |
| 测试者是什么宽带？ | 本网 / 跨网差异大 |
| 有没有丢包？ | 速度数字不含这个信息 |
| 我的环境下能达到多少？ | 跨环境不可比 |
| 这个节点现在还在吗？ | 没有节点名与日期 |
所以：没有环境说明的测速图，信息量接近零。 它只能证明"某个时刻某个地方有人测出了这个数字"。
时段
| 时段 | 时间 | 用途 |
|---|---|---|
| 上午 | 09:00–11:00 | 基线 |
| 中午 | 12:00–13:00 | 次高峰 |
| 晚高峰 | 20:00–23:00 | 稳定性核心指标 |
| 凌晨 | 01:00–03:00 | 线路上限 |
各时段的作用与判断标准
| 时段 | 时间 | 作用 | 怎么用 |
|---|---|---|---|
| 上午 | 09:00–11:00 | 基线 | 与晚高峰对比，算降幅 |
| 中午 | 12:00–13:00 | 次高峰 | 观察午间的负载 |
| 晚高峰 | 20:00–23:00 | 稳定性的核心指标 | 真正的判断依据 |
| 凌晨 | 01:00–03:00 | 线路上限 | 看节点的理论能力 |
为什么晚高峰是核心
公网国际出口在 20:00–23:00 饱和，而这是绝大多数人的使用时段。
| 时段 | 出口状态 | 相对白天的速度 | 丢包 |
|---|---|---|---|
| 06:00–09:00 | 空闲 | 100% | ≈ 0 |
| 09:00–18:00 | 中等负载 | 95–100% | ≈ 0 |
| 18:00–20:00 | 负载上升 | 70–90% | 上升 |
| 20:00–23:00 | 饱和 | 15–50% | 1–5% |
| 23:00–01:00 | 回落 | 60–90% | 回落 |
| 01:00–06:00 | 空闲 | 100% | ≈ 0 |
"白天的测速图区分不了线路类型"就是因为这个——白天出口不饱和，专线、中转、直连都可能很快。
降幅：本站的核心判断指标
降幅 = (白天速度 - 晚高峰速度) ÷ 白天速度| 晚高峰丢包 | 降幅 | 对应的线路方案 |
|---|---|---|
| ≈ 0 | < 30% | 专线（IEPL / IPLC） |
| < 1% | 20–40% | 优质中转（CN2 GIA / AS9929 / CMI） |
| 1–3% | 40–60% | CN2 GT / 普通中转 |
| > 3% | > 50% | 直连（163 / AS4837 / AS9808） |
这张表是本站所有线路判断的基础。 它出现在 中转、直连与专线、节点怎么选、速度慢怎么排查 等页面。
为什么需要连续三天
| 天数 | 结论的可靠性 |
|---|---|
| 1 天 | 不可靠——单次受偶然因素影响太大 |
| 2 天 | 有参考 |
| 3 天 | 一致时结论可信 |
| 三天波动大 | 说明超卖或线路在调整——这本身是负面信号 |
"三天波动大"是一个重要的结论，而不是"没测出来"。它意味着不适合买年付。
速度
- 下载 / 上传：多线程下载 100MB 以上文件，取稳定段平均；
- 延迟 / 抖动：ICMP 或 TCP ping 20 次，取平均与标准差；
- 丢包：同上，统计比例。
具体命令与工具
bash
# 延迟与丢包（100 次样本）
ping -c 100 节点IP
# 更完整的逐跳视图（含丢包）
mtr -n -c 100 节点IP
# 路径（看线路走向）
traceroute -n 节点IP
# Windows
ping -n 100 节点IP
tracert -d 节点IP下载速度用多线程测速工具或实际下载一个 100MB 以上的文件，跑三次取中位数。
为什么要这样测
| 要求 | 为什么 | 不这样做的后果 |
|---|---|---|
| ping 100 次 | 需要足够样本看到丢包分布 | 10 次看不出 1% 的丢包 |
| 多线程下载 | 单线程受单条 TCP 连接的拥塞控制限制 | 测出的速度明显偏低 |
| 跑三次取中位数 | 排除偶然因素 | 单次可能是异常值 |
| 文件 ≥ 100MB | 需要足够时间达到稳定段 | 小文件测的是启动阶段 |
| 取稳定段平均 | 开头有 TCP 慢启动 | 平均值偏低 |
| 有线连接 | Wi-Fi 自身会丢包 | 所有节点看起来都有丢包 |
不要用客户端的"延迟测试"
| 项目 | 客户端的延迟测试 | ping -c 100 |
|---|---|---|
| 样本量 | 1（通常一次 TCP 握手） | 100 |
| 能看到丢包吗 | 不能 | 能 |
| 能看到抖动吗 | 不能 | 能（stddev） |
| 受偶然因素影响 | 极大 | 小 |
| 用途 | 快速排除完全连不上的节点 | 判断节点质量 |
"延迟低但丢包高"是节点超卖的典型特征——而客户端的延迟测试恰好只显示那个漂亮的延迟数字。
三个指标分别说明什么
| 指标 | 怎么读 | 反映什么 |
|---|---|---|
| 丢包（packet loss） | 最关键 | 拥塞（线路或节点超卖） |
| 抖动（max-min 或 stddev） | max 是 min 的 3 倍以上就值得注意 | 队列波动，决定会议与游戏体验 |
| 延迟（avg） | 与物理下限对比 | 物理距离 + 排队 |
| 最小延迟（min） | 低于物理下限 → 落地不在标注地区 | 硬证据 |
判断顺序：先丢包、再抖动、最后速度。
为什么丢包最重要： 晚高峰速度崩塌的机制是"丢包让 TCP 主动降速"——1% 的丢包能造成 70% 的速度损失。 两个数字看起来不成比例，但机制上就是这样。
物理下限速查
| 地区 | 物理下限（往返） | 合理上限 | 超过就要怀疑 |
|---|---|---|---|
| 香港 | 约 10ms | 70ms | 100ms+ |
| 台湾 | 约 15ms | 80ms | 110ms+ |
| 日本 | 约 55ms | 130ms | 180ms+ |
| 新加坡 | 约 40ms | 120ms | 170ms+ |
| 美国西岸 | 约 130ms | 250ms | 320ms+ |
低于物理下限是硬证据（物理上不可能）——说明落地不在标注的地区。
高于合理上限只是可疑（可能是绕行或严重拥塞）。
稳定性
- 连续运行 24 小时或 7 天，记录掉线次数与单次持续时间；
- 节点可用率 = 可用节点数 ÷ 总节点数，每天固定时间抽查。
跨环境不可比：本站方法论的核心前提
这是理解本站所有数据处理方式的关键。
六个影响结果的变量
| 变量 | 影响 | 能否标准化 |
|---|---|---|
| 宽带运营商 | 决定本网 / 跨网，影响运营商互联点排队 | 否 |
| 所在省份 | 决定到国内入口机房的距离与省内出口条件 | 否 |
| 城域网条件 | 同运营商不同城市的接入质量不同 | 否 |
| 本地环境 | 有线 / Wi-Fi、路由器性能、本地 QoS | 部分可（换有线） |
| 测试时段 | 白天与 21:00 差 3–5 倍 | 是 |
| 测试方法 | 单线程 vs 多线程、ping 10 次 vs 100 次 | 是 |
只有后两项可以标准化。 前四项是任何测试者与你之间不可消除的差异。
这导致的四个结论
一、本站不给"最好的机场"排名。
因为排名需要跨环境可比，而前四个变量不可消除。站内的综合榜是编辑排序（editorial 层），不是实测得分——这在 排行榜方法论 里有明确说明。
二、本站的测速快照不用于排名。
不同快照的测试环境不同，不可比的数据不能排序。
三、本站的周期榜需要标注测试环境才能发布。
规划中的周期榜会明确标注：测试起止日期、时段分布、测试环境的宽带运营商与所在区域、测试方法、参与节点的完整名、样本量、局限。缺任何一项就不发。 见 周期榜。
四、本站反复强调"自己测"。
不是推卸责任，而是你的数据是唯一覆盖了那四个不可消除变量的数据。
对读者的实际含义
| 你看到 | 该怎么理解 |
|---|---|
| 任何人的测速图 | "某人在某环境某时刻测出了这个" |
| "这家很好用"的推荐 | 对推荐者的环境成立 |
本站的 vendor 层数据 | 可横向对比的结构化信息（价格、流量、协议、地区、运营时长） |
| 本站的编辑排序 | 本站的倾向，不是实测得分 |
| 你自己的三天测试 | 唯一能回答"这家对我好不好用"的数据 |
一句话：本站提供判断框架与可核对的结构化数据，你提供环境。
AI 解锁判定
| 服务 | 通过标准 |
|---|---|
| ChatGPT | 能登录、能发送并收到回复，连续 5 次无验证循环 |
| Claude | 能打开 claude.ai 并对话，无 Region not supported |
| Gemini / AI Studio | 能打开并生成，无地区提示 |
流媒体解锁判定
| 平台 | 通过标准 |
|---|---|
| Netflix | 能播放非自制剧 |
| Disney+ | 能登录并播放 |
| YouTube | 能播放，Premium 地区正确 |
| Spotify / Twitch | 能播放，无地区错误 |
你自己怎么测：完整流程
本站的方法论对你同样适用，而且你的数据比任何公开数据都更准确（因为它覆盖你自己的环境）。
准备
| 项 | 要求 | 不满足的后果 |
|---|---|---|
| 有线连接 | 必须 | 所有节点看起来都有丢包 |
| 固定同一台设备 | 必须 | 数据不可比 |
| 固定同一条宽带 | 必须 | 数据不可比 |
| 关闭其他大流量程序 | 建议 | 速度偏低 |
| 重启过路由器 | 建议 | 可能误判成节点问题 |
| 确认国内网站正常 | 必须 | 可能整个测试都在测本地问题 |
| 记下节点的完整名字 | 必须 | 机场调整后无法对应 |
最后一项容易被忽略：节点名里可能有特殊符号、空格、emoji，原样抄下来。
三天时间表
| 天 | 时段 | 做什么 | 耗时 |
|---|---|---|---|
| 0 | 任意 | 排查本地：换有线、重启路由器、确认国内网站正常 | 10 分钟 |
| 1 | 白天 10:00–12:00 | 每个地区 2–3 个节点：ping -c 100 + 多线程下载三次 | 20 分钟 |
| 1 | 21:00 | 同一批节点重测。第一个真正的判断点 | 20 分钟 |
| 2 | 21:00 | 重复 | 15 分钟 |
| 3 | 21:00 | 重复 + 对最好的两个节点做 traceroute | 25 分钟 |
| 4 | 任意 | 测 AI 与流媒体（无痕窗口、非自制剧），只需一次 | 15 分钟 |
| 4 | — | 汇总，按丢包与降幅归类，填节点档案 | 15 分钟 |
总投入约两小时，分散在四天里。 换来的是一份可以用三个月的节点档案。
节点档案格式
| 节点完整名 | 地区 | 倍率 | 测试日期 | 白天延迟 | 晚高峰延迟 | 晚高峰丢包 | 降幅 | 抖动 | AI | 流媒体 | 归类 | 用途 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| （原样抄） | 香港 | 1x | 2026-09-18 | 32ms | 35ms | 0.1% | 18% | 6ms | ✗ | 港区 | 专线级 | 会议主力 |
| （原样抄） | 新加坡 | 1x | 2026-09-18 | 78ms | 85ms | 0.6% | 32% | 15ms | ✓ | — | 中转级 | AI 专用 |
| （原样抄） | 美国 | 2x | 2026-09-18 | 165ms | 210ms | 2.8% | 58% | 35ms | ✓ | 美区 | 直连级 | 仅内容需求 |
为什么每个字段都必要
| 字段 | 为什么 |
|---|---|
| 完整节点名（原样） | 机场调整时名字是唯一锚点 |
| 测试日期 | 结论有保质期，三个月后要复测 |
| 倍率 | 直接影响实际可用流量 |
| 晚高峰丢包 | 最关键的单一指标 |
| 降幅 | 判断超卖与线路方案 |
| 抖动 | 会议与游戏体验的决定因素 |
| AI / 流媒体 | 二元结果，一次测试即可 |
| 归类 + 用途 | 决定配规则时指向哪里 |
怎么用这份档案
| 用途 | 说明 |
|---|---|
| 配规则分流 | 按"用途"列把对应流量指向对应节点 |
| 每季度复测 | 线路会变、IP 段会被标记 |
| 换机场时对比 | 新机场按同样方法同样时段测——这是唯一公平的比较方式 |
| 判断机场整体变化 | 多个节点同时变差 = 机场级问题 |
| 与客服沟通 | 带数据的反馈获得有效响应的概率高得多 |
最后一项值得强调："很慢"客服无法处理；"香港 xx 节点，9 月 18 日 21:10，ping 100 次丢包 4.2%，下载从白天的 180Mbps 降到 22Mbps"是可以处理的。
本站的数据分层与使用限制
这是本页最重要的一节，它规定了本站怎么使用实测数据。
五层分层
| 层级 | 含义 | 举例 | 使用限制 |
|---|---|---|---|
vendor | 品牌资料，本站未独立验证 | 价格、流量、协议、地区、线路标注、IP 类型、退款规则 | 如实录入，不做事实认定 |
commercial | 推广链接、优惠码，有利益关系 | 部分品牌页的推广链接 | 标注 sponsored nofollow + 页面单独披露 |
measured | 实测数据 | 17 张测速快照 | 只做范围性记录（见下文） |
editorial | 本站的编辑判断 | 综合榜排序、适合人群、验证建议 | 明确标注为编辑判断 |
not-tested | 未测试，字段留空显示"—" | 解锁矩阵、评分 | 不做就不填，不猜 |
测速快照的使用限制
站内收录的 17 张测速快照，本站只做"快照记录"：
| 记录什么 | 说明 |
|---|---|
| 图本身 | 作为只读的原始证据 |
| 节点分布 | 图里出现了哪些地区的节点 |
| 范围性观察 | 比如"香港节点的下载速度在数百 Mbps 量级" |
| 异常项 | 明显偏离的数据点 |
| 测试时间与来源 | 如资料提供 |
明确不做的四件事：
| 不做 | 为什么 |
|---|---|
| 不 OCR 成逐节点精确表 | 会制造虚假的精度 |
| 不据此排名 | 单次测试不足以排名 |
| 不推导线路类型 | 逻辑上做不到（白天三种方案都可能很快） |
| 不推导 AI / 流媒体解锁 | 完全不同的维度 |
为什么这四条限制是必要的
一、不 OCR 成精确表。 一张截图上的"香港 01：238.6Mbps"看起来很精确，但它是某个时刻某个环境下的一次测量。把它录成表格会让读者以为这是该节点的稳定表现。
二、不据此排名。 排名意味着可比，而不同快照的测试环境（运营商、城市、时段、方法）不同——不可比的数据不能排序。
三、不推导线路类型。 白天公网出口不饱和，专线、中转、直连都可能很快。线路类型要靠连续三晚的晚高峰丢包判断，单张截图无法回答。
四、不推导解锁。 解锁由落地 IP 类型决定，与速度完全无关。一张高速截图与"能不能用 Netflix"没有逻辑关系。
评分与解锁矩阵为什么是空的
| 字段 | 需要什么 | 本站现状 |
|---|---|---|
| 评分 | 控制条件下的持续监测 | 还没做 |
| 解锁矩阵 | 逐节点逐服务的实测，且保质期很短（IP 段会被标记） | 还没做 |
空白表示"未实测"，不表示"不支持"或"没有问题"。
为什么不猜一个填上： 一个不可靠的评分或解锁结论会让读者跳过自己的验证——而验证恰恰是唯一可靠的方法。
这与本站其他字段的处理一致：官网域名只收录有可靠依据的 1 家、风险事件记录为空、不做假站黑名单、不维护服务地区可用性列表。宁缺毋滥。
解锁判定的四条通用要点
无论测哪个服务，这四条都适用：
| 要点 | 为什么 |
|---|---|
| 用无痕窗口 | 排除 cookie、缓存与会话状态的干扰 |
| 换节点前重开无痕窗口 | 上一个节点的会话状态会污染结果 |
| 记录测试日期 | 解锁结论的保质期最短（IP 段会被标记） |
| 网页版与 App 分别测 | 两者的检测策略可能不同 |
三个最容易出错的地方
一、用自制剧测 Netflix。
自制剧（Originals）在所有地区都有版权，不需要通过地区检测——用它测出"能播"证明不了任何事。
必须播非自制剧。 这是流媒体测试里最容易出的错。
二、"能登录"就认为通过。
登录环节与使用环节的检测可能不同。 常见的情况是能登录但发不出消息。
所以 AI 的测试一定要实际发一条消息。
三、没有区分"地区不提供服务"与"检测到代理"。
| 提示 | 含义 | 解法 |
|---|---|---|
| 该地区不提供服务 | 服务本身不覆盖该地区 | 换到有服务的地区（换同地区节点无效） |
| 检测到代理 / 无法播放 | IP 类型问题 | 换同地区其他节点 |
这两种失败的解法完全不同，在 Disney+ 上尤其常见。见 Disney+ 节点怎么选。
解锁失败的排查顺序
| 顺序 | 做什么 | 原理 |
|---|---|---|
| 0 | 确认测的是非自制剧（流媒体） | 最常见的假阳性来源 |
| 1 | 换同地区的其他节点 | 多是该节点 IP 段被标记 |
| 2 | 换地区（AI 优先新加坡 / 日本，避开香港） | 地区级限制 |
| 3 | 用无痕窗口重测 | 排除浏览器状态 |
| 4 | 查出口 IP 的类型与归属 | 机房 IP 通过率最低；广播 IP 地区判定不符 |
| 5 | 检查该域名的 DNS 解析位置 | 本地解析可能导致地区判定错 |
| 6 | 看连接日志确认走了指定节点 | 规则可能静默失效 |
| 7 | 用其他网络环境验证账号 | 区分账号问题与节点问题 |
| 8 | 整家全部失败 → 换机场 | 说明它的节点都是机房 IP |
前两步能解决大部分情况，而且成本为零。
为什么本站不填解锁矩阵
即使有了上面的判定标准，本站仍然不填 unlock 字段。四个理由：
| 理由 | 说明 |
|---|---|
| 保质期最短 | IP 段会被标记，一个结论可能几周后失效 |
| 是节点级的，不是品牌级的 | 同一家机场不同节点的表现可能完全不同 |
| 需要持续的逐节点逐服务测试 | 本站没有这个能力 |
| 一份不准确的矩阵比没有更有害 | 它会让读者跳过自己的验证 |
所以本站提供的是判定标准与排查顺序，不是结论。 见 流媒体解锁数据库（那一页说明了为什么矩阵是空的）。
数据流向
实测记录 → data/benchmarks/*.json → 品牌页"相关实测" → 品牌 scores → 排行榜。
当前的数据流向现状
上面的流程图是设计，下面是现状。
| 环节 | 现状 |
|---|---|
实测记录 → data/benchmarks/*.json | 17 张快照已收录（只做范围性记录） |
| 品牌页"相关实测" | 显示快照（图 + 节点分布 + 范围性观察 + 异常项） |
品牌 scores | 空——需要控制条件下的持续监测 |
| 排行榜 | 综合榜是编辑排序，评分榜为空 |
关键：链条在"品牌 scores"这一步断开了。
为什么断开
因为快照不能转成评分。
| 快照有什么 | 评分需要什么 |
|---|---|
| 某个时刻某个环境的一次观察 | 控制条件下的多次测量 |
| 测试环境可能未完整标注 | 标准化的环境 |
| 不同快照之间不可比 | 可比的数据 |
| 白天或未标注时段 | 晚高峰的一致性 |
如果强行把快照转成评分，那个评分就是虚假的精度。
所以本站的排行榜是怎么来的
| 榜单 | 数据来源 | 说明 |
|---|---|---|
| 综合排行榜 | editorial（编辑排序） | 不是实测得分，已明确标注 |
| 价格榜、每 GB 榜 | vendor 派生 | 由价格与流量计算 |
| 评分榜 | measured | 目前为空——需要控制条件实测 |
| 周期榜（规划中） | measured | 需要持续测试才能开始 |
四个榜单回答四个不同的问题，不能互相替代。 见 排行榜方法论 与 周期榜。
一份可复用的测试记录模板
照这个格式记，三个月后你会感谢自己。
环境（每次测试都要记）
| 项目 | 你的填写 |
|---|---|
| 运营商 | （电信 / 联通 / 移动） |
| 城市 | — |
| 宽带带宽 | — |
| 有线 / Wi-Fi | 有线 |
| 设备 | — |
| 客户端与版本 | — |
| 协议 | — |
这七项在整个测试周期内保持不变，否则数据不可比。
单次测试记录
| 项目 | 记什么 |
|---|---|
| 日期与时刻 | 2026-09-18 21:10 |
| 节点完整名 | 原样抄下来 |
| 节点标注的地区 | — |
| 倍率 | 1x / 2x / … |
| ping 100 次：丢包 | % |
| ping 100 次：min / avg / max | ms |
| 抖动（max-min 或 stddev） | ms |
| 多线程下载三次的中位数 | Mbps |
| traceroute 的关键观察 | 有无 202.97、跳数、异常跳 |
汇总与归类
| 节点完整名 | 地区 | 倍率 | 白天速度 | 晚高峰速度 | 降幅 | 晚高峰丢包 | 抖动 | 归类 | 用途 |
|---|---|---|---|---|---|---|---|---|---|
| — | — | — | — | — | — | — | — | 专线级 / 中转级 / 直连级 | 会议 / AI / 下载 / … |
解锁记录（单独一张）
| 节点完整名 | 地区 | 测试日期 | ChatGPT | Claude | Gemini | Netflix（非自制剧） | Disney+ | 备注 |
|---|---|---|---|---|---|---|---|---|
| — | — | — | ✓ / ✗ | — | — | — | — | 用无痕窗口 |
解锁记录要单独一张，因为它的复测频率更高（每月）而线路记录是每季度。
三个提醒
一、节点名要原样抄。 包括特殊符号、空格、emoji——改写过的名字在机场调整后无法对应。
二、测试日期是保质期标记。 超过三个月的结论不要当成现状。
三、环境七项不能变。 如果你换了宽带或设备，之前的数据就不能用来对比了——需要重新建立基线。
稳定性测试的补充说明
"稳定性"是最难测也最容易被忽略的维度。
两种稳定性
| 类型 | 测什么 | 怎么测 |
|---|---|---|
| 连接稳定性 | 会不会掉线 | 连续运行 24 小时或 7 天，记录掉线次数与单次持续时间 |
| 性能稳定性 | 速度与丢包的波动 | 连续三晚同时段的一致性 |
两者都重要，但性能稳定性对多数人影响更大——因为"一直连着但时快时慢"比"偶尔掉线"更影响体验。
性能稳定性的判断
| 三晚的结果 | 结论 |
|---|---|
| 三晚一致（丢包与降幅接近） | 结论可信，可以依赖 |
| 两晚一致、一晚异常 | 可能是偶发，再测一晚 |
| 三晚差异很大 | 超卖或线路在调整——本身是负面信号 |
"三晚差异很大"是一个重要的结论，而不是"没测出来"。 它意味着：
| 含义 | 对你的影响 |
|---|---|
| 不适合会议 / 直播 | 即使平均值还行，波动也是致命的 |
| 不适合买年付 | 服务本身不稳定 |
| 可能在超卖 | 用户规模超过带宽 |
| 可能线路在调整 | 上游变更中 |
节点可用率
节点可用率 = 可用节点数 ÷ 总节点数每天固定时间抽查。 这个指标反映的是机场的运维状态。
| 可用率 | 含义 |
|---|---|
| 接近 100% | 运维正常 |
| 长期 80–90% | 有失效节点未清理 |
| 持续下降 | 可能在停止投入（风险信号） |
| 突然大幅下降 | 上游变更或故障 |
"死节点一直挂着"是一个运维信号——正常运营的机场会下线失效的节点。见 风险信号识别 的第三类信号。
真实场景测试不可替代
数据可以都正常但体验不好。 所以关键场景要做真实测试：
| 场景 | 怎么测 | 为什么数据测不出 |
|---|---|---|
| 视频会议 | 连续 30 分钟真实通话 | 抖动的瞬时峰值可能不体现在平均值里 |
| 游戏 | 进入实际对局 | 同上，且涉及 UDP 与 NAT |
| 远程桌面 | 连续操作 | 跟手感是主观但真实的 |
| 4K 视频 | 播一个 4K 视频看是否缓冲 | 比跑测速更贴近实际 |
"播 4K 看是否缓冲"是本站推荐的 YouTube 测试方法——它测的正是你要用的场景。见 YouTube 节点怎么选。
复测的频率
| 项目 | 建议频率 | 理由 |
|---|---|---|
| 线路表现（晚高峰丢包） | 每季度 | 线路会被上游变更 |
| 解锁能力 | 每月 | IP 段被标记的频率最高 |
| 节点是否还存在 | 每次订阅更新后 | 机场会调整节点 |
| 完整重测 | 换机场时 | 需要对比基准 |
"每次订阅更新后检查节点是否还存在"容易被忽略——如果你的规则指向的节点已下线，规则会静默失效，流量落到默认节点。
常见误判
- 有测速图就有参考价值。 没有环境说明（运营商、城市、带宽、时段、方法）的截图信息量接近零。
- 白天的测速图能说明线路好。 白天公网出口不饱和，三种线路方案都可能很快。
- 能从测速图看出是不是专线。 逻辑上做不到——线路类型要靠连续三晚的晚高峰丢包判断。
- 速度数字是最重要的指标。 丢包才是——1% 的丢包能造成 70% 的速度损失。
- 客户端的延迟测试够用了。 它只握手一次，看不到丢包与抖动。
- 测一次就能下结论。 至少连续三天；三天波动大本身是负面信号。
- 能播 Netflix 自制剧就是解锁成功。 自制剧在所有区都能播，测不出任何东西。
- 能登录就说明能用。 登录与使用的检测可能不同，AI 要实际发一条消息。
- 别人测出来好的节点我也能用。 六个变量里四个不可消除（运营商、省份、城域网、本地环境）。
- 评分是空的说明本站数据不全。 是的，而且本站明确说明了——评分需要控制条件下的持续监测，不做就不填。
名词速查
| 名词 | 含义 |
|---|---|
| 丢包（packet loss） | 数据包未到达的比例，判断线路质量最关键的指标 |
| 降幅 | (白天速度 - 晚高峰速度) ÷ 白天速度，本站的核心判断指标 |
| 抖动 | 延迟波动幅度（max-min 或 stddev），决定会议与游戏体验 |
| 物理下限 | 光纤往返的最短时间；低于它说明落地不在标注地区 |
| 多线程下载 | 用多条连接同时下载，测真实吞吐的正确方法 |
| 稳定段 | 排除 TCP 慢启动后的平稳阶段 |
| 快照记录 | 本站对测速图的处理方式：图 + 节点分布 + 范围性观察 + 异常项 |
| 跨环境不可比 | 六个变量里四个不可消除，本站方法论的核心前提 |
vendor / commercial / measured / editorial / not-tested | 本站的五层数据分层 |
| 自制剧 / Originals | 流媒体自有内容，所有区都能播，测不出解锁 |
本页数据说明
| 内容 | 层级 | 含义 |
|---|---|---|
| 测试方法、时段划分、指标定义 | 规则说明（editorial） | 本站的方法规范 |
| 判断标准（丢包 / 降幅对应线路方案） | 一般性技术参考 | 非针对具体品牌 |
| 物理下限 | 一般性技术参考 | — |
| 站内的 17 张测速快照 | measured | 只做范围性记录（见上文的四条限制） |
站内的 scores（评分） | not-tested | 全部为空 |
站内的 unlock（解锁矩阵） | not-tested | 全部为空 |
| 站内的线路标注 | vendor | 本站不做事实认定 |
本站的测速快照不 OCR 成逐节点精确表、不据此排名、不推导线路类型、不推导 AI / 流媒体解锁。
评分与解锁矩阵全部为空——空白表示"未实测"，不表示"不支持"或"没有问题"。
本站不对任何品牌的线路类型做事实认定。 站内 15/18 家标注专线，这些标注全部来自品牌资料（vendor 层）。
完整规则见 免责声明 与 收录、标注与撤销标注的规则。
一句话总结
实测的第一原则是记录环境：运营商、城市、宽带带宽、客户端与版本、协议、日期与时刻——没有这些的测速图信息量接近零，因为跨环境不可比（六个影响变量里有四个不可消除）。核心判断指标是晚高峰的丢包与降幅，不是速度数字：丢包 ≈ 0 且降幅 < 30% 对应专线、< 1% 对应优质中转、1–3% 对应普通中转、> 3% 对应直连。测法必须是有线、ping -c 100、多线程下载跑三次取中位数、白天一轮加 21:00 一轮、连续三天——客户端的延迟测试只握手一次，看不到丢包与抖动（而"延迟低但丢包高"正是节点超卖的典型特征）。本站的 17 张测速快照只做范围性记录：不 OCR 成逐节点精确表、不据此排名、不推导线路类型、不推导解锁能力；评分与解锁矩阵全部为空，因为它们需要控制条件下的持续监测——不做就不填，而不是猜一个。
下一步
- 看站内的快照记录 → 实测中心
- 排行榜是怎么排的 → 排行榜方法论 · 周期榜
- 评测的写作规范 → 评测方法与写作规范
- 自己测节点 → 节点怎么选 · 节点波动
- 线路判断 → 中转、直连与专线
- 解锁判断 → IP 类型 · Netflix 节点怎么选
- 速度排查 → 速度慢怎么排查
- 本站的完整规则 → 免责声明 · 标注规则
相关页面
常见问题
为什么没有环境说明的测速图没有参考价值？
因为跨环境不可比。同一个节点在电信与移动宽带上、在华南与华北、在白天与 21:00 的结果可能差 3–5 倍。不标注运营商、城市、带宽、时段的截图无法判断它对你是否适用。
站内的 17 张测速快照能说明什么？
只能说明"某个时间某个环境下的一次观察"。本站只做快照记录（图 + 节点分布 + 范围性观察 + 异常项），不 OCR 成逐节点精确表、不据此排名、不推导线路类型或解锁能力。
为什么评分和解锁矩阵是空的？
评分需要控制条件下的持续监测，解锁结论需要逐节点逐服务的实测且保质期很短。本站还没有做这些工作——不做就不填，而不是猜一个。
为什么不能从测速图推导线路类型？
因为逻辑上做不到。白天公网国际出口不饱和，专线、中转、直连都可能很快。线路类型要靠连续三晚的晚高峰丢包与降幅判断，单张截图无法回答。
最关键的测试指标是什么？
丢包，不是速度。晚高峰速度崩塌的机制是"丢包让 TCP 主动降速"——1% 的丢包能造成 70% 的速度损失。判断顺序应该是先丢包、再抖动、最后速度。
为什么要测 100 次 ping 而不是客户端的延迟测试？
客户端的延迟测试通常只做一次 TCP 握手，样本量为 1，既看不到丢包也看不到抖动。而"延迟低但丢包高"恰好是节点超卖的典型特征。
测速为什么必须用多线程？
单线程受单条 TCP 连接的拥塞控制限制，测不出节点的真实吞吐上限。多线程下载跑三次取中位数才能反映实际可用带宽。
我自己怎么测？
用有线、固定同一台设备与同一条宽带、白天一轮加 21:00 一轮、连续三天、ping 100 次加多线程下载三次取中位数、记完整节点名与测试日期。详见本页的完整流程。