外观
为什么同一个机场的节点差别这么大
这是选购与使用中最普遍的困惑：同一家机场，A 节点飞快、B 节点几乎不可用；同一个节点，今天很好、明天很差；别人力荐的节点，你用起来平平。
这些都不是异常，而是机场服务的固有特性。 本页把原因拆开说明，并给出能建立可复用判断的测试方法。
八个原因总览
| # | 原因 | 表现 | 你能做什么 |
|---|---|---|---|
| 1 | 超卖程度不同 | 延迟低但丢包高；白天好晚高峰崩 | 换节点 |
| 2 | 落地出口带宽不同 | 延迟低但下载慢 | 换节点 |
| 3 | 上游线路不同 | 同机场不同节点的晚高峰差异大 | 挑出好的固定用 |
| 4 | 入口机房位置不同 | 延迟差 20–40ms | 选离你近的入口 |
| 5 | IP 段被标记程度不同 | 解锁能力不同 | 换节点（换 IP 段） |
| 6 | 时段 | 同节点白天与晚上差 3–5 倍 | 按时段切换节点 |
| 7 | 上游变更 | 原本好的节点突然变差 | 复测，必要时换机场 |
| 8 | 你自己的本地因素 | 所有节点都不好 | 先排查本地 |
排查顺序很重要：先第 8 项，再第 6 项，然后才是节点本身。 很多"机场不好用"的报告实际上是本地问题或时段误判。
原因一：超卖程度不同
什么是超卖
机场的一个节点是一台（或几台）服务器，承载多少用户是机场的商业决定。承载的用户数超过带宽能稳定支撑的水平，就是超卖。
超卖不必然是恶意——用户的使用是错峰的，适度的复用是合理的商业模式。问题在于程度：如果晚高峰的并发超过了带宽，所有人都会受影响。
典型特征
| 特征 | 为什么 |
|---|---|
| 延迟低但丢包高 | 路径通畅（延迟低），但服务器或出口的队列满了（丢包） |
| 白天很快、晚高峰崩塌 | 晚高峰并发最高 |
| 下载速度波动剧烈 | 与其他用户竞争带宽 |
| 同机场其他节点正常 | 超卖是节点级的 |
"延迟低但丢包高"是最有辨识度的信号。 如果是线路问题（公网出口拥塞），延迟会同时抬升；如果延迟正常但丢包高，问题更可能在落地服务器或其出口。
怎么测
| 步骤 | 操作 | 看什么 |
|---|---|---|
| 1 | 白天 ping 100 次 | 基线延迟与丢包 |
| 2 | 白天多线程下载三次 | 基线速度 |
| 3 | 21:00 ping 100 次 | 丢包是否明显上升 |
| 4 | 21:00 多线程下载三次 | 降幅 |
| 5 | 对比同机场其他节点 | 是这个节点的问题还是整家的问题 |
第 5 步是关键。 如果只有这个节点差，换节点就解决了；如果全部节点都差，才是机场层面的问题。
为什么热门节点更容易超卖
用户会自然聚集到"看起来最好"的节点上：名字显眼的、延迟显示最低的、排在列表最前面的。
这带来一个实用技巧：试试列表里不显眼的节点。 延迟稍高、名字平淡的节点往往用户更少，实际体验可能更好。这也是"多测几个节点"的价值所在。
原因二：落地出口带宽不同
它与超卖的区别
超卖是用户数超过带宽；出口带宽不足是带宽本身就小。
两者的表现相似（延迟低但下载慢），但区别在于：
| 超卖 | 出口带宽小 | |
|---|---|---|
| 白天表现 | 好 | 也慢 |
| 晚高峰 | 明显崩塌 | 与白天接近 |
| 丢包 | 晚高峰高 | 通常正常 |
判断方法：看白天的速度。 白天就慢且丢包正常 → 出口带宽小（这是节点的固有上限）；白天快晚上崩 → 超卖。
为什么会有小带宽节点
| 原因 | 说明 |
|---|---|
| 家宽 IP 节点 | 家庭宽带的带宽本来就小，这是解锁能力的代价 |
| 成本控制 | 小带宽的服务器便宜，适合放低需求的节点 |
| 特殊地区 | 某些地区的带宽本身就贵（如部分东南亚、南美） |
| 中转链路的瓶颈 | 中转段的带宽可能小于落地服务器的带宽 |
家宽 IP 节点是最常见的情况。 如果一个节点解锁很好但速度只有几十 Mbps，那很可能是家宽——不要期待它同时快。见 IP 类型。
怎么应对
用规则分流，把大流量需求指向大带宽节点。 下载、4K 视频走机房 IP 的大带宽节点；解锁需求走家宽节点。见 规则分流。
原因三：上游线路不同
同一家机场的节点可能来自不同供应商
这是最容易被忽略的原因。机场的节点通常不是自建，而是从不同的中间商、VPS 商、专线服务商采购。
结果：同一家机场的不同节点，线路质量可能完全不同。
| 节点 | 可能的实际情况 |
|---|---|
| 香港 01 | 供应商 A 的 IEPL 专线 |
| 香港 02 | 供应商 B 的 CN2 GIA 中转 |
| 香港 03 | 便宜 VPS + 普通直连 |
| 日本 01 | 供应商 C 的专线 |
而节点名可能都不体现这些差异，或者体现得不准确。
这解释了什么
一、为什么同机场的节点晚高峰差异大。 不同线路方案的晚高峰表现是结构性不同的，见 中转、直连与专线。
二、为什么"全专线"的标注需要逐地区验证。 机场可能主力地区用专线、边缘地区用便宜方案。
三、为什么机场自己也说不清具体线路。 它转述上游的宣传，而上游可能有多个。
怎么应对
逐节点测，挑出好的固定用，把名字记下来。
不要试图搞清每个节点的线路类型（成本太高、机场也答不清），直接按结果筛：
| 三晚测试结果 | 归类 | 用途 |
|---|---|---|
| 丢包 ≈ 0、降幅 < 30% | 专线级 | 会议、直播、游戏 |
| 丢包 < 1%、降幅 20–40% | 优质中转级 | 日常、看视频 |
| 丢包 1–3% | 普通中转级 | 白天、轻度 |
| 丢包 > 3% | 直连级 | 不用，或只当备用 |
这个分类不需要知道线路名字，只需要知道结果。 对使用来说，结果就是全部。
原因四：入口机房位置不同
对走中转或专线的节点，国内入口机房的位置影响延迟。
| 你的位置 | 入口在华南 | 入口在华东 | 入口在华北 |
|---|---|---|---|
| 华南 | 最优 | +15–25ms | +25–40ms |
| 华东 | +15–25ms | 最优 | +15–25ms |
| 华北 | +25–40ms | +15–25ms | 最优 |
这是纯物理距离造成的，无法优化。
怎么发现
同一地区的多个节点延迟差 20–40ms，且这个差值在白天与晚高峰都稳定存在 → 很可能是入口机房位置不同。
如果差值只在晚高峰出现，那更可能是超卖或线路差异。
怎么应对
选延迟最低的那个节点固定用。 如果机场的节点名标注了入口（如"深港"、"沪日"），选离你近的那个。
原因五：IP 段被标记程度不同
这一项只影响解锁，不影响速度。
同一家机场的不同节点用不同的 IP 段，被服务方标记的程度不同。 所以：
- A 节点 Netflix 能播，B 节点报代理错误
- 昨天能用的节点今天不行了（IP 段刚被标记）
- 换个同地区节点就好了
这是"解锁失败先换同地区节点"的原因。 详细机制与排查流程见 IP 类型。
原因六：时段
差异有多大
| 时段 | 相对白天的速度 | 丢包 |
|---|---|---|
| 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 |
晚高峰与白天可以差 3–5 倍。 这个差异远大于不同机场之间的差异。
所以：不同时段的测试结果不能直接比较。 一个常见的错误是白天测 A 机场、晚上测 B 机场，然后得出"A 比 B 好"的结论。
白天测速图的局限
白天的测速截图无法区分线路类型，也无法预测晚高峰表现。
因为白天公网国际出口不饱和，专线、中转、直连都可能很快。差距只在晚高峰显现。
这也是本站的数据规则之一：收录的 17 张测速快照只做快照记录（图 + 节点分布 + 范围性观察 + 异常项），不 OCR 成逐节点精确表、不据此排名、不推导线路类型或解锁结果。快照不标注测试时段的完整上下文，所以不能用来回答"晚高峰怎么样"。
原因七：上游变更
什么会变
| 变化 | 表现 | 频率 |
|---|---|---|
| 上游把 GIA 降级成 GT | 晚高峰变差 | 不定期 |
| 更换落地服务器 | 延迟与 IP 都变 | 不定期 |
| IP 段更换 | 解锁能力变化 | 较频繁 |
| 节点改名或下线 | 找不到原来的节点 | 不定期 |
| 带宽调整 | 速度上限变化 | 不定期 |
机场自己可能都不知道上游的变更。 它买的是服务，不是线路本身。
这意味着什么
任何测试结论都有保质期。 你三个月前测出来最好的节点，今天可能已经不是了。
这是本站不给"最好的机场"排名的方法论理由之一。 站内的综合榜是编辑排序（editorial 层），不是实测得分——因为可靠的实测排名需要持续监测，而任何一次性的测试结论都会过期。
怎么应对
每季度复测一次关键节点。 把你的节点档案（下一节会讲）拿出来重跑。
发现变差时，先换同机场其他节点。 上游变更通常只影响部分节点。
如果整家都变差，且持续两周以上，考虑换机场。 单次波动不是换的理由，持续劣化才是。
原因八：你自己的本地因素
这一项应该第一个排查，因为它最容易被误判成机场问题。
| 因素 | 表现 | 怎么确认 |
|---|---|---|
| Wi-Fi 丢包 | 所有节点都有丢包 | 换有线重测 |
| 路由器过载 | 多设备时变慢 | 重启路由器后重测 |
| 本地 QoS / 限速 | 速度有明显上限 | 检查路由器设置 |
| 客户端配置问题 | 某些流量不走代理或走错节点 | 看连接日志 |
| DNS 问题 | 部分网站打不开但节点正常 | 换 DNS 测试 |
| 国内段问题 | 国内网站也慢 | 测国内网站与国内测速 |
| 设备性能 | 加密解密成为瓶颈 | 看 CPU 占用 |
| 客户端版本过旧 | 协议不兼容或有已知 bug | 更新客户端 |
最重要的两个判断
一、国内网站晚高峰正常吗？
- 国内也慢 → 问题在本地或城域网，换机场无效
- 国内正常、只有境外慢 → 才是线路或节点问题
二、有线和 Wi-Fi 的结果一样吗？
Wi-Fi 的丢包会污染所有后续判断。所有正式测试都应该用有线。
这两个判断能排除掉相当比例的"机场问题"报告。 在怀疑机场之前先做这两步，能省下大量试错成本。
怎么测出真实差异
核心原则
| 原则 | 为什么 |
|---|---|
| 固定环境 | 同一条宽带、有线、同一台设备 |
| 固定时段 | 白天一轮 + 21:00 一轮 |
| 连续三天 | 单次测试受偶然因素影响太大 |
| ping 100 次 | 客户端里那个"延迟测试"只握手一次，看不到丢包 |
| 多线程下载三次取中位数 | 单线程测不出真实吞吐 |
| 记完整节点名 | 名字是唯一的锚点 |
| 分开记丢包、抖动、速度 | 三个指标反映不同问题 |
具体命令
bash
# 延迟与丢包（100 次样本）
ping -c 100 节点IP
# 更完整的路径 + 丢包视图
mtr -n -c 100 节点IP
# 路径（看线路走向）
traceroute -n 节点IP
# Windows
ping -n 100 节点IP
tracert -d 节点IP下载速度用多线程测速工具或实际下载一个大文件，跑三次取中位数。不要用单线程——单线程受单条 TCP 连接的拥塞控制影响，测不出节点的真实吞吐上限。
三个指标分别说明什么
| 指标 | 反映什么 | 异常时的方向 |
|---|---|---|
| 丢包 | 拥塞（线路或节点） | 延迟也高 → 线路；延迟正常 → 节点超卖 |
| 抖动 | 队列波动 | 影响会议与游戏，中转的固有弱项 |
| 速度 | 出口带宽 + 拥塞 | 白天也慢 → 带宽小；只晚上慢 → 超卖 |
判断顺序：先丢包，再抖动，最后速度。 丢包与抖动决定体验，速度数字最容易被偶然因素影响。
建立节点档案
这是把测试变成可复用资产的方法。
档案表格式
| 节点完整名 | 地区 | 测试日期 | 白天延迟 | 晚高峰延迟 | 晚高峰丢包 | 降幅 | AI | 流媒体 | 归类 | 用途 |
|---|---|---|---|---|---|---|---|---|---|---|
| （完整名） | 香港 | 2026-09-18 | 32ms | 35ms | 0.1% | 18% | ✗ | 港区 | 专线级 | 会议主力 |
| （完整名） | 新加坡 | 2026-09-18 | 78ms | 85ms | 0.6% | 32% | ✓ | — | 中转级 | AI 专用 |
| （完整名） | 日本 | 2026-09-18 | 88ms | 96ms | 1.2% | 41% | ✓ | 日区 | 中转级 | 备选 |
| （完整名） | 美国 | 2026-09-18 | 165ms | 210ms | 2.8% | 58% | ✓ | 美区 | 直连级 | 仅内容需求 |
为什么要记这些
| 字段 | 为什么必须 |
|---|---|
| 完整节点名 | 机场调整时名字会变，这是唯一锚点 |
| 测试日期 | 结论有保质期，三个月后要复测 |
| 白天与晚高峰对比 | 降幅是判断的核心 |
| 晚高峰丢包 | 最关键的单一指标 |
| AI / 流媒体 | 二元结果，一次测试即可 |
| 归类 | 决定这个节点该承担什么流量 |
怎么用这个档案
一、配规则分流。 按"用途"列把对应流量指向对应节点。见 规则分流。
二、季度复测。 把表拿出来重跑关键项，更新日期。变差的重新归类。
三、换机场时对比。 新机场按同样方法测，与旧档案直接对比——这是唯一公平的比较方式（同环境、同时段、同方法）。
四、判断机场整体变化。 如果多个节点同时变差，是机场层面的问题；如果只有一个，换节点即可。
六个不可比较的变量
"为什么别人推荐的节点我用起来不行"值得单独展开，因为它决定了你该怎么看待所有推荐（包括本站的）。
| 变量 | 影响 | 可否标准化 |
|---|---|---|
| 宽带运营商 | 决定本网 / 跨网，影响互联点排队 | 否 |
| 所在省份 | 决定到入口机房的距离与省内出口条件 | 否 |
| 城域网条件 | 同运营商不同城市的接入质量不同 | 否 |
| 本地环境 | 有线 vs Wi-Fi、路由器性能、本地 QoS | 部分可（换有线） |
| 测试时段 | 白天与 21:00 差 3–5 倍 | 是 |
| 测试方法 | 单线程 vs 多线程、ping 10 次 vs 100 次 | 是 |
只有后两项可以标准化。 前四项是你与推荐者之间不可消除的差异。
这意味着什么
一、任何推荐都是"在某人的环境下、某个时间、用某种方法"得出的。 不注明这三项的推荐，信息量很低。
二、跨环境比较必须谨慎。 别人在电信宽带上测出的 CN2 GIA 表现，对你的移动宽带参考价值有限。见 CMI 线路。
三、你自己的数据永远最准确。 这不是空话——你的宽带、你的省份、你的时段、你的设备，这些变量只有你自己的测试能覆盖。
本站的定位
这是本站不给"最好的机场"排名、不填 unlock 字段、把综合榜标为编辑排序的方法论理由。
| 本站不做 | 为什么 |
|---|---|
| 实测排名 | 需要持续多点监测，且结论跨环境不可迁移 |
填 unlock 解锁矩阵 | 节点级、保质期短、需要控制条件实测 |
| 从测速图推导线路类型 | 逻辑上做不到 |
| OCR 快照成逐节点精确表 | 违反数据规则，且会制造虚假精度 |
| 本站做 | 价值 |
|---|---|
结构化的 vendor 层数据 | 价格、流量、协议、地区、运营时长可横向对比 |
| 验证方法与判断标准 | 让你的测试更有效率 |
| 维度分离（线路 / 地区 / IP 类型） | 让你往正确的方向排查 |
| 派生指标（每 GB、折算月均价、完整度） | 由数据在构建时计算，不手填 |
一句话：本站帮你建立判断框架，不替你下结论。
节点选择的实战技巧
前面讲的是原理，这一节是可以直接用的操作。
技巧一：从不显眼的节点开始试
用户会自然聚集到名字显眼、延迟显示最低、排在列表最前的节点上。试试列表中间或后面、名字平淡的节点——用户少、超卖程度低，实际体验可能更好。
技巧二：延迟排序会骗你
客户端里的"延迟测试"通常只做一次 TCP 握手。这个数字：
- 看不到丢包
- 看不到抖动
- 样本量为 1，受偶然因素影响极大
- 反映的是那一瞬间的状态
不要用它做最终判断。 它只适合快速排除完全连不上的节点。
技巧三：按时段用不同节点
如果某个节点白天极快但晚高峰崩塌（典型超卖），而另一个节点白天一般但晚高峰稳定（可能是专线），那就白天用前者、晚上用后者。
多数客户端支持手动切换或按规则切换，不需要固定用一个。
技巧四：会议前十分钟测一次
会议是最不能容忍失败的场景。开会前 ping 一下你要用的节点 100 次，确认丢包正常。
如果丢包异常，立刻换备用节点——这比会议中途断掉再手忙脚乱地换要好得多。
技巧五：给关键场景准备两个节点
| 场景 | 主节点 | 备节点 |
|---|---|---|
| 会议 | 专线级香港 | 专线级台湾或第二个香港 |
| AI | 家宽 / 原生的新加坡 | 日本 |
| 流媒体 | 解锁通过的节点 | 同地区另一个 IP 段 |
| 下载 | 大带宽机房节点 | 任意 |
单节点就是单点故障。 关键场景至少两个。
技巧六：记录"不好用"的节点
节点档案不只记好的，也记差的。否则你会反复试同一个已知不好的节点。
技巧七：不要在晚高峰做首次测试
如果你刚买了一家机场，先在白天跑一遍基线，确认基本可用、找出延迟最低的那批节点。然后晚高峰只测这批。
反过来做（先晚高峰测）会让你在拥塞的条件下评估所有节点，容易误判。
技巧八：客户端的连接日志很有用
多数客户端能显示每个请求走了哪个出站。配完规则分流后看一眼日志，确认：
- AI 请求走的是你指定的节点
- 国内域名走的是直连
- 下载走的是大带宽节点
配错的表现往往很隐蔽（比如国内网站稍微变慢），看日志是最快的确认方式。
常见误判
- 节点数量多就好。 数量是品牌资料里的数字，与你能稳定用的节点数无关。
- 延迟最低的节点最好。 延迟低但丢包高是超卖的典型特征。
- 一次测试就能下结论。 单次受偶然因素影响太大，至少三天。
- 别人推荐的节点我也能用。 六个因素不同，其中四个不可消除。
- 白天测速图能预测晚高峰。 不能，白天三种线路方案都可能很快。
- 全部节点都慢一定是机场问题。 先排查本地（有线 / 路由器 / 国内网站）。
- 节点改名了但应该还是那个。 改名通常意味着后端也变了，要重测。
- 测试结论可以长期用。 线路与 IP 段都会变，建议每季度复测。
- 客户端里的延迟测试够用了。 那只握手一次，看不到丢包与抖动。
- 换机场比换节点更有效。 多数情况下换节点就解决了，换机场成本高得多。
什么时候该换机场
节点波动是常态，换机场是成本较高的决定。下面给出明确的判断标准。
不该换的情况
| 现象 | 为什么不该换 | 该做什么 |
|---|---|---|
| 某个节点变差 | 节点级问题 | 换节点 |
| 晚高峰比白天慢 | 所有方案都会有劣化 | 看降幅是否在合理范围 |
| 某个服务打不开 | 地区或 IP 类型问题 | 换地区 / 换节点 |
| 一晚表现异常 | 单次波动 | 再观察两晚 |
| 国内网站也慢 | 本地问题 | 排查本地 |
| 别人说有更好的 | 跨环境不可比 | 用自己的数据判断 |
该换的情况
| 现象 | 为什么 |
|---|---|
| 全部节点连续两周以上晚高峰丢包 > 3% | 机场层面的容量问题 |
| 三晚波动极大且持续 | 超卖或线路频繁调整，不可靠 |
| 你需要的地区完全没有可用节点 | 覆盖不匹配你的需求 |
| 流量反复不够用 | 套餐不匹配，换档或换家 |
| 客服无法回答基本问题 | 透明度信号 |
| 出现风险信号 | 见 风险信号识别 |
| 标注与实测严重不符且无改善 | 标注不可信 |
换之前先做的三件事
一、把现有的节点档案整理好。 新机场要用同样的方法、同样的时段测，才能公平对比。
二、确认问题不在自己这边。 有线、路由器、国内网站、客户端版本——这四项都排查过。
三、算清成本。 如果当前套餐还有大半个月，可以先买新机场的最低档并行测试，确认更好再完全迁移。并行一个月的成本通常只有 20 元左右，比盲目切换的风险低。
换机场时的选择依据
因为线路标注在当前市场的区分度很低（站内 15/18 家标注专线），换机场时应该看别的维度：
| 维度 | 为什么重要 | 站内情况 |
|---|---|---|
| 退款条款 | 决定你的验证成本 | 只有无忧链接标注无理由退款，其余 17 家待补 |
| 运营时长 | 存续风险 | 2020 年起两家、2023 年起七家、2025 年起若干 |
| IP 类型披露 | 解锁能力的唯一线索 | 只有无忧链接披露 |
| 价格与流量的组合 | 是否符合成本结构 | 见 价格数据库 |
| 客服可达性 | 出问题时能不能解决 | 只有无忧链接填写了客服方式 |
| 支付方式 | 是否方便 | 多数支持支付宝 / 微信 |
注意：这些都是 vendor 层数据（品牌资料），本站未独立验证。 但它们至少是可以横向对比的结构化信息，而"解锁能力"与"线路真实性"不是。
名词速查
| 名词 | 含义 |
|---|---|
| 超卖 | 单节点承载用户数超过带宽能稳定支撑的水平 |
| 落地出口带宽 | 境外服务器到互联网的带宽，是下载速度的上限 |
| 入口机房 | 国内接入中转或专线的机房，位置影响延迟 |
| 上游 | 机场采购节点与线路的供应商 |
| 丢包 | 数据包未到达的比例，最关键的单一指标 |
| 抖动 | 延迟波动幅度，决定会议与游戏体验 |
| 降幅 | 晚高峰速度相对白天的下降百分比 |
| 节点档案 | 你自己维护的节点测试记录 |
| 多线程下载 | 用多条连接同时下载，测真实吞吐 |
| mtr | 结合 ping 与 traceroute 的工具，适合看逐跳丢包 |
完整排查流程
我的机场不好用，怎么排查？
1. 国内网站晚高峰正常吗？
不正常 → 本地或城域网问题，换机场无效。排查有线 / 路由器 / 本地 QoS
正常 → 继续
2. 用的是有线还是 Wi-Fi？
Wi-Fi → 换有线重测。Wi-Fi 丢包会污染所有判断
有线 → 继续
3. 是所有节点都不好，还是部分节点？
部分节点 → 换节点即可，问题在节点级（超卖 / IP 段 / 上游不同）
全部节点 → 继续
4. 什么时段测的？
晚高峰（20:00–23:00）→ 正常会有劣化，对比白天看降幅
白天也慢 → 继续
5. 延迟高还是延迟低但速度慢？
延迟也高 → 线路问题，见 /network/transit
延迟低但慢 → 落地出口带宽或超卖，换节点
6. 是解锁问题还是速度问题？
解锁 → IP 类型问题，见 /network/ip-types，先换同地区节点
速度 → 继续
7. 连续三天测了吗？
没测 → 单次不作数，测三天
三天都差 → 机场层面的问题，考虑换
三天波动大 → 超卖或线路调整，不要买年付
8. 原来好现在变差了？
先换同机场其他节点（上游变更通常只影响部分节点）
持续两周以上整家都差 → 换机场本页数据说明
| 内容 | 层级 | 含义 |
|---|---|---|
| 八个原因的机制说明 | 一般性技术参考 | 非针对具体品牌 |
| 时段差异与指标区间 | 一般性技术参考 | 你的实际值受环境影响 |
| 测试方法与节点档案格式 | editorial | 本站方法建议 |
| 站内无逐节点实测数据 | not-tested | 快照只做范围性记录 |
本站不把测速截图 OCR 成逐节点精确表、不据此排名、不从测速图推导线路类型或解锁结果。 收录的 17 张快照只记录图、节点分布、范围性观察与异常项。规则见 实测方法与环境说明 与 免责声明。
一句话总结
同机场不同节点差别大，主要来自八个原因：超卖程度（延迟低但丢包高）、落地出口带宽（白天也慢）、上游线路不同（同机场的节点可能来自不同供应商）、入口机房位置（延迟差 20–40ms）、IP 段被标记程度（只影响解锁）、时段（晚高峰与白天差 3–5 倍）、上游变更（结论有保质期）、以及你自己的本地因素（应该第一个排查）。正确的做法不是找"最好的节点"，而是逐节点测三晚、按丢包与降幅归类、建立带完整节点名与测试日期的档案、用规则分流让每种流量走最合适的节点、每季度复测一次。换节点通常比换机场更有效。
指标之间的组合诊断
单个指标的异常有多种可能，组合起来看才能定位。下面这张表是本页最实用的诊断工具。
| 延迟 | 丢包 | 白天速度 | 晚高峰速度 | 最可能的原因 | 怎么办 |
|---|---|---|---|---|---|
| 低 | ≈ 0 | 快 | 快 | 一切正常（专线级） | 固定用 |
| 低 | ≈ 0 | 快 | 降 20–40% | 优质中转，正常 | 可用 |
| 低 | 高 | 快 | 崩塌 | 节点超卖 | 换节点 |
| 低 | ≈ 0 | 慢 | 慢 | 出口带宽小（可能家宽 IP） | 用于解锁，不用于下载 |
| 高 | 高 | 快 | 崩塌 | 公网出口拥塞（直连） | 换线路方案 |
| 高 | ≈ 0 | 快 | 快 | 入口机房远，或地区物理距离远 | 换离你近的入口 / 地区 |
| 高 | ≈ 0 | 慢 | 慢 | 绕行，或落地不在标注地区 | 查出口 IP 归属 |
| 极低（低于物理下限） | — | — | — | 落地不在标注地区 | 查出口 IP，标注不实 |
| 低 | ≈ 0 | 快 | 快，但解锁失败 | IP 类型问题 | 换同地区其他节点 |
| 波动极大 | 波动 | 波动 | 波动 | 超卖或上游频繁调整 | 不要买年付 |
| 所有节点都有丢包 | — | — | — | 本地问题（大概率 Wi-Fi） | 换有线重测 |
| 国内网站也慢 | — | — | — | 本地或城域网 | 换机场无效 |
怎么用这张表
从左往右填你的观察，然后读"最可能的原因"。
三个最有价值的行：
"低延迟 + 高丢包"→ 超卖。 这是最容易误判的组合，因为客户端显示的延迟很漂亮，你会以为节点很好。
"极低延迟（低于物理下限）"→ 落地不在标注地区。 这是硬证据：日本节点延迟 40ms 在物理上不可能（下限约 55ms），说明落地不在日本。见 节点地区 的物理下限表。
"所有节点都有丢包"→ 本地问题。 先换有线，这一步能排除很大比例的误判。
一个完整的四周使用周期
把前面所有内容串成一个可执行的时间表，适合刚买机场的人直接照做。
第 1 周：建立基线
| 天 | 做什么 |
|---|---|
| 1（白天） | 排查本地：有线、路由器、国内网站正常。装好客户端，导入订阅 |
| 1（白天） | 快速扫一遍全部节点，排除连不上的，记下能连上的完整节点名 |
| 1（白天） | 对每个地区选 2–3 个节点做基线测试（ping 100 次 + 多线程下载三次） |
| 1（21:00） | 同一批节点重测。这是第一个真正的判断点 |
| 2（21:00） | 重复 |
| 3（21:00） | 重复 + 对表现最好的两个节点做 traceroute |
| 3 | 按丢包与降幅归类，填节点档案 |
| 4 | 测 AI 与流媒体（无痕窗口、非自制剧），只需一次 |
| 5 | 配规则分流，看客户端日志确认生效 |
| 6–7 | 正常使用，观察实际体验与测试结论是否一致 |
第 1 周结束时你应该有：一份节点档案、一套生效的规则分流、以及"这家能不能用"的初步结论。
第 2–3 周：实际使用中验证
| 关注什么 | 怎么看 |
|---|---|
| 会议是否稳定 | 连续 30 分钟通话，有无断音与冻结 |
| 流量消耗速度 | 按当前速度推算够不够用一个月 |
| 是否有节点突然失效 | 记下时间与现象 |
| 解锁是否持续可用 | IP 段可能被标记 |
| 晚高峰体验是否与测试一致 | 测试与实感不符时以实感为准 |
这两周的重点是"实感"，不是数字。 如果测试数据很好但你觉得不好用，那通常是某个没测到的维度（比如某个具体服务的延迟、某个时段的波动）。
第 4 周：决策
| 结果 | 决定 |
|---|---|
| 关键场景都稳定、流量够用 | 续费。考虑年付前先看运营时长 |
| 大部分好、某个场景不行 | 保留 + 为那个场景配第二家 |
| 全部节点晚高峰都差 | 换。有退款的申请退款 |
| 流量明显不够 | 换更大的档，或配一家便宜大流量的 |
| 三周内节点频繁失效 | 换。稳定性问题比速度问题更严重 |
之后：每季度复测
把节点档案拿出来，重跑：
- 关键节点的晚高峰测试（一晚即可，除非发现异常）
- AI 与流媒体的通过性（策略可能变了）
- 更新档案里的测试日期
复测的成本很低（一个晚上），但能及时发现上游变更。 这比"用着突然不行了才开始排查"要主动得多。
下一步
- 想搞清线路方案的区别 → 中转、直连与专线
- 想搞清解锁问题 → IP 类型
- 想搞清地区怎么选 → 节点地区怎么选
- 想看完整测试方法 → 实测方法与环境说明
- 想配规则分流 → 规则分流
- 想看站内的快照记录 → 实测中心
相关页面
- 线路：IEPL · IPLC · CN2 · CMI · 中转、直连与专线 · 节点地区 · IP 类型 · 线路与节点总览
- 教程：节点怎么选 · 规则分流 · 速度慢怎么排查
- 实测：实测方法与环境说明 · 实测中心
常见问题
为什么同一个机场的不同节点速度差这么多？
最常见的原因是各节点的用户密度不同（超卖程度不同）与落地服务器的出口带宽不同。其次是上游线路不同——同一家机场的节点可能来自不同供应商，线路质量不一致。
为什么同一个节点今天快明天慢？
四个常见原因：时段差异（晚高峰拥塞）、机场用户数变化、上游线路被降级或调整、落地服务器被临时限速。前两个是最常见的。
节点延迟低但下载很慢是怎么回事？
延迟测的是单个小包的往返，下载测的是持续吞吐。延迟低说明路径通畅，下载慢通常是落地服务器的出口带宽被超卖或限速——这两个指标测的是不同东西。
为什么别人推荐的节点我用起来不行？
至少六个因素不同：宽带运营商、所在省份、城域网条件、测试时段、测试方法、本地环境（有线/Wi-Fi、路由器）。其中只有时段与方法可以标准化，其余四项是不可消除的差异。
节点名字变了是怎么回事？
机场调整节点时会改名。这也是为什么记录节点的完整名字很重要——名字是你唯一的锚点，名字变了通常意味着后端也变了，需要重新测。
怎么判断一个节点是不是被超卖了？
典型特征是延迟低但丢包高、或白天很快晚高峰崩塌。测法是白天与 21:00 各 ping 100 次 + 多线程下载三次，对比丢包与降幅。
机场的节点数量多是好事吗？
不一定。数量是品牌资料里的数字，与你能稳定用的节点数无关。更有意义的指标是你需要的地区有几个三晚都稳定的节点。
多久应该复测一次？
建议每季度一次。线路会变、IP 段会被标记、机场的用户规模会变化，三个月前的结论可能已经部分失效。