网站连通性检测

凌晨两点十七分，网站我盯着终端里滚动的连通红色报错，第无数次按下回车。性检ping命令的网站响应时间从42ms跳到超时，再到恢复，连通循环往复，性检像一台失控的网站呼吸机。这不是连通什么重大事故，只是性检监控系统在提醒我：某台位于法兰克福的边缘节点又开始抽风了。

网站连通性检测这事，网站听起来像运维手册里最枯燥的连通一章，但干久了你会发现，性检它本质上是网站在跟网络的不确定性博弈。TCP握手、连通DNS解析、性检TLS证书过期、BGP路由抖动——任何一个环节掉链子，用户看到的就只是“打不开”三个字。去年有个电商客户大促前夜，首页图片全部加载失败，排查到最后，是CDN回源时用的一个备用域名忘记续费，被注册商回收了。没人会想到去查域名状态，因为那个域名三年没动过。

检测手段本身并不复杂。最基础的就是ICMP ping，但ping通不代表服务正常——很多防火墙会静默丢弃ICMP包，而HTTP服务却活得好好的。所以我更信任curl，带上`-I`参数看响应头，200、301、502，每个状态码都是服务端的体检报告。但光看状态码也不够，你得测实际下载速度，测首字节时间，甚至模拟用户在弱网环境下的行为。有一次我抓到一个诡异现象：某API接口在办公室光纤下响应只要80ms，换成4G网络就飙到3.5秒。查到最后，是服务端对特定User-Agent做了限速，而手机端的UA恰好命中了那条规则。

真正的麻烦在于，检测工具本身也会骗人。监控系统告警说某站点全挂，我手动curl却一切正常——后来发现是监控机所在的网段被对方机房加了ACL，只拦监控IP。这种“假警报”比真故障更消耗精力，你得学会交叉验证：换不同地域的探针、换DNS服务器、甚至用浏览器无头模式跑一遍完整渲染流程。有回为了确认某个页面是否真的白屏，我写了个脚本去截屏，结果发现是页面里的WebSocket连不上导致JS阻塞渲染，而HTTP层面一切正常——这种问题，传统连通性检测根本测不出来。

干这行久了，我养成个习惯：每次检测都顺手记下响应时间的分布曲线，而不只是平均值。平均值会掩盖真相——99%的请求都在100ms内完成，剩下1%却要等10秒，这种长尾效应才是用户真正感知到的卡顿。上个月处理一个金融客户的问题，他们的交易接口平均延迟正常，但每分钟总有几个请求超时。翻日志发现，超时都发生在整点前后——那是他们数据库定时备份的时间，I/O争抢把连接池拖垮了。

说了这么多，其实就想表达一个意思：连通性检测不是按几下按钮就完事的例行公事，它更像是在跟一个看不见的对手下棋。你永远不知道下一个坑藏在域名解析里，还是藏在某个云服务商的配额限制里。工具永远不够，经验才是硬通货。每次告警响起，都是网络在跟你说话——你得学会听懂它到底在抱怨什么，是线路拥塞，还是代码里某个没关掉的连接。