"能 ping 通"不等于"能用"：机场稳定性监控的正确姿势
很多用户在机场 TG 群里看到"我 ping 全部正常啊，怎么打不开网页？"的争吵。问题出在：不同手段测的是完全不同的东西。这篇把四种监控方式各自能证明什么、证明不了什么讲清楚。
四种手段，四种结论
1. TCP ping（连通性探测）
从监控服务器向节点的 IP:端口 发起 TCP 连接，测连接是否成功、耗时多少。
- ✅ 能证明：节点服务器在线、端口开放、路由可达
- ❌ 不能证明：节点还能不能过墙、速度如何、是否被流媒体封锁
- 特点：成本低（几十个节点几秒测完），适合高频监控
2. 真实测速
客户端实际挂上节点，下载一段固定大小的文件（如 Cloudflare speed test），测吞吐。
- ✅ 能证明：端到端真实带宽
- ❌ 不能证明：晚高峰表现（除非持续测）、过墙能力
- 特点：成本高（吃流量、耗时分钟级），适合低频抽查
3. 流媒体 / 平台解锁检测
访问 Netflix、ChatGPT、TikTok 等，看是否返回地区限制。
- ✅ 能证明：该出口 IP 当前的"纯净度"
- ❌ 不能证明：明天还解锁（IP 池是动态变化的）
- 特点：解锁状态瞬息万变，任何榜单都有时效性
4. 订阅可用性
监控能不能拉到订阅、解析出节点。
- ✅ 能证明：机场的服务端管理系统存活
- ❌ 不能证明：节点质量
- 这个指标单独监控很必要：订阅接口挂了，一切免谈
为什么我们把 TCP ping 作为核心指标
在 节点状态页 里，我们每 10 分钟对订阅内全部节点做一次 TCP ping，理由：
- 频率够高：10 分钟粒度才能捕捉"凌晨正常、晚高峰全挂"这类模式
- 成本可控：一次探测几百个节点仅消耗秒级 CPU、几乎零带宽
- 失败信号明确：ping 不通 = 节点死了，这个结论几乎不会误判
它的局限，必须诚实告诉你
- TCP 通 ≠ 能过 GFW：节点可能"活着但已被封锁"
- 不反映速度：延迟 200ms 的节点看 4K 可能完全没问题
- 从单一机房（我们在美国）探测：只能代表国际方向的连通性
所以我们把状态条的含义写得很保守：它回答"这个节点现在活没活着"，而不是"好不好用"。
给普通用户的实用建议
- 看状态页时，关注在线率趋势而不是单格颜色：某天黄一格没事，连续一周走低才是真问题
- 节点大面积离线时，先换协议（见 敏感时期自救）再骂机场
- 订阅失效比节点离线更致命：没有新节点进来，再多备用也是死水
数据不会说谎，但要看你测的是什么。希望这篇能帮你读懂任何一家状态页背后的方法论。