TL;DR
结论：先用 3 分钟判断是本地网络、DNS、GFW 封锁，还是服务端本身不稳；再看 4 个指标：可用率、延迟、丢包、晚高峰速度。不要先看“免费”“高速”字样，先看实测数据。本文给出可执行的诊断命令、验证方法和选型规则，适用于机场评测、VPN 梯子对比、加速器推荐场景。
前置条件
环境版本：Windows 11 23H2 / macOS 14.4 / iOS 17.4 / Android 14；测试日期：2025-08-18。你需要一台能联网的设备、一个终端或命令提示符，以及一个可访问的测速目标。若只想排查“打不开/进不去”，先不要改太多设置，按下面顺序做。
Note: 如果你在公司网、校园网或公共 Wi‑Fi 下，先记录当前网络名称、时间段、DNS 地址和是否开了代理。很多“机场挂了”其实是本地网络策略在拦截。
1. 先区分是本地问题还是服务问题
第一步只做最小化判断：同一台设备切换到手机热点，再访问同一个目标。如果热点可用，问题大概率在当前网络；如果热点也不行，再看 DNS 和代理配置。
第二步检查 DNS。Windows 运行：
ipconfig /all
预期输出里会看到当前网卡的 DNS Server 地址，例如 223.5.5.5 或 114.114.114.114。如果显示为空、异常地址，或代理软件在接管但未生效，先修复 DNS。
然后做解析测试：
nslookup example.com
预期输出应返回一个或多个 IPv4/IPv6 地址，耗时通常在 20-100ms。若出现 server can't find、超时或返回明显错误地址，问题在解析层。
Warning: 不要一上来就连续切换 5 个节点。先确认“能不能连上”和“解析是否正常”，否则你会把故障面扩大到无法判断。
2. 用 3 个命令快速定位断点
下面这组命令足够覆盖 80% 的“打不开/挂了”排查。每个命令都要看结果，不要只看能否执行成功。
-
连通性：
ping 1.1.1.1预期输出：平均延迟 20-80ms，丢包 0%。如果全丢包，先修本地网络。
-
DNS 解析：
nslookup www.google.com预期输出：返回 IP 地址，耗时通常小于 100ms。若超时，优先换 DNS 或关闭本地劫持代理。
-
路由可达性：
tracert 1.1.1.1预期输出：前几跳正常，后续是否中断可帮助判断是局域网、运营商还是跨境链路问题。macOS/Linux 可用
traceroute 1.1.1.1，预期同理。
如果这三步都正常，但目标站点仍打不开，通常是目标站点被屏蔽、服务端异常，或者你的代理规则没命中。此时应检查代理模式是全局还是规则分流，以及目标域名是否在直连白名单。
3. 机场评测看什么，不看什么
判断一个服务是否靠谱，不要先看“永久免费”“极速云666.com”这类包装词。实测里更重要的是：晚高峰可用率、节点延迟、丢包率、单线程/多线程速度。我常用的基准是：工作日 20:00-23:00 连续测 3 次，记录同一节点的平均值和波动。
一个可操作的评测表如下：
| 指标 | 合格线 | 为什么重要 |
|---|---|---|
| 可用率 | > 95% | 节点是否经常挂 |
| 延迟 | < 180ms | 网页打开和握手速度 |
| 丢包 | < 2% | 视频、语音、游戏是否稳定 |
| 下载速度 | > 20 Mbps | 大文件和流媒体体验 |
实测示例：同一条线路在晚高峰下，A 节点平均延迟 142ms、下载 38 Mbps、丢包 0.3%；B 节点平均延迟 260ms、下载 8 Mbps、丢包 4.8%。B 节点虽然宣传“高速机场”，但实际不达标。
Note: “免费机场”可以用来验证基础连通性，但通常会有限速、限流量、排队和节点不稳定的问题。适合临时测试，不适合长期主用。
4. 可复制的测速与验证流程
下面是我建议的标准流程。每次换服务、换节点、换网络，都按同样的方法跑一次，结果才可比。
-
固定测试时间，建议 09:00、14:00、21:00 各测一次。
-
固定测试目标：同一个公共 DNS、同一个下载文件、同一个网页。
-
记录三项数据：ping 平均值、丢包率、下载速度。
-
对比 3 天平均值，不看单点峰值。
命令示例：
ping example.com -n 20
预期输出：20 次请求中成功 20 次，平均延迟例如 155ms。
下载测速示例：
curl -o NUL -L https://speed.hetzner.de/100MB.bin
预期输出：显示下载完成，若终端显示平均速度 30-80 Mbps，说明链路可用。Linux/macOS 可将 NUL 改为 /dev/null。
如果测速结果白天正常、晚上明显下降 50% 以上，说明服务端容量不足，不是你的设备问题。此时应把“晚高峰表现”作为主要评分项，而不是白天的峰值速度。
5. 选型建议：按场景而不是按宣传词
如果你只是偶尔查资料，优先选配置简单、节点少但稳定的方案；如果你经常视频会议或游戏，对丢包和抖动更敏感，优先选延迟更低、晚高峰更稳的线路；如果你只想临时应急，免费方案可以先顶上，但要接受波动。
下面是实用分法：
- 轻度使用：免费机场或官方内置方案，重点看是否可用，不追求满速。
- 中度使用：付费小型机场，要求可用率和晚高峰稳定性。
- 高频使用：优先看多节点冗余、故障切换和客服响应，不要只看月费。
如果你在对比“极光加速器”这类商业方案，建议把它放进同一套测试表里跑 3 天，再和自建、免费、其他机场一起比；它只是众多选项之一，免费方案、自建节点和官方内置方案也都能在不同场景下成立。更多可参考 roxi.cc。
如何确认问题已解决
按下面 4 条逐项验收，全部通过才算真正解决：
- 同一目标在当前网络和手机热点下都能打开。
nslookup无超时，解析结果稳定一致。- 连续 20 次
ping丢包为 0% 或接近 0%。 - 晚高峰测速至少连续 3 次结果波动不超过 30%。
如果上述结果仍不稳定，不要继续加节点数量。优先回退到最简单配置：关闭多余代理、固定 DNS、只保留一个可用节点，再重新测一次。能稳定复现，才能稳定解决。
References
1. Cloudflare DNS 文档：基础 DNS 与连通性排查思路
2. Microsoft Windows ipconfig / ping / tracert 帮助文档
3. Apple macOS 网络工具文档：ping、dig、traceroute
4. Linux man pages：ping、nslookup、curl