Sitewatch用11条规则戳破200状态码的谎言

去年双十一，某电商平台首页显示"200 OK"，但结算按钮的JavaScript文件404了。用户能看不能买，技术团队却在监控大屏前喝茶——一切正常，服务器没报警。

这不是个例。Sitewatch团队统计，超过60%的生产事故发生在HTTP 200的掩护下。传统监控工具只问"服务器活着吗"，从不问"用户能正常用吗"。

200状态码的盲区：服务器说"好的"，实际在摆烂

标准监控的逻辑简单到近乎粗暴：发请求，收200，标记健康。但200只是HTTP协议层面的握手成功，跟业务是否可用完全是两回事。

Sitewatch列出的真实故障模式，每一条都披着200的外衣：

前端构建后文件名带哈希（main.a4f2c.js），HTML却引用旧版本，资源404；CDN把JavaScript当成text/html返回，浏览器静默拦截，脚本永不执行；API网关挡在应用前，本该出网页的URL吐出一串JSON错误；DNS切错、CDN漂移，域名解析到陌生IP，内容指纹全变。

这些场景里，服务器日志干干净净，传统监控绿灯常亮，用户却在空白页前刷新到崩溃。

11条检测规则：从"通没通"到"对不对"

Sitewatch把检测拆成三块：资源层、协议层、语义层。11条规则里没有一条是检查"服务器是否响应"——那是最低门槛，不是交付标准。

ASSET_MISSING 抓的是资源级故障。用HEAD请求扫一遍页面引用的JS、CSS、图片，看状态码是不是200。文件名哈希变更后的404，构建工具配置错误的403，对象存储权限漂移的5xx，全部现形。HEAD请求不执行JavaScript，开销极低，失败才降级到GET。

ASSET_MIME_MISMATCH 针对浏览器的安全策略。Content-Type头对不上文件实际类型，现代浏览器直接拒载。一个JavaScript文件被标记成text/html，页面加载完成，功能却全残。这种错误不会进服务器日志，因为服务器确实把文件发出去了。

REDIRECT_LOOP 跟踪跳转链。循环重定向在浏览器里表现为ERR_TOO_MANY_REDIRECTS，但在监控探针的第一次请求里可能只是延迟稍高。Sitewatch记录完整链条的状态码和终点，在浏览器崩溃前拦截。

HOST_DRIFT 做基线比对。持续追踪域名解析的IP和Server头，DNS迁移、CDN切换、故障转移配置错误导致的流量劫持或漂移，触发内容指纹比对。如果"同一个URL"返回的HTML结构和历史样本差异过大，报警。

NON_HTML_PAGE 处理网关层的语义错乱。API网关误配置、鉴权服务异常、或者后端服务直接暴露，都可能让本该渲染页面的URL返回JSON、XML或空体。200状态码配上{"error":"unauthorized"}，传统监控视为成功，用户看到白屏。

剩下的规则覆盖经典故障模式（UNAVAILABLE的5xx和超时）、链路完整性（单页最多50个内链的存活检查）、API端点结构校验、响应体模式匹配。

2-of-3确认机制：宁可漏报，不可误报

监控工具最大的敌人不是漏检，是狼来了。凌晨3点的告警如果是CDN 8秒闪断，团队下次就会静音通知。然后错过真正的数据库主从切换失败。

Sitewatch的确认模型要求：三个独立探针中至少两个在同一时间窗口内检测到同一故障，才触发告警。单次异常——边缘节点抖动、网络瞬断、慢速传播——被自动过滤。

这个设计牺牲了理论上的最快响应时间，换取了告警的可信度。对于200状态码下的隐蔽故障，探测本身就有成本，误报的代价远高于几分钟的延迟。

Sitewatch的产品逻辑，本质是把监控的观测点从"服务器边界"推进到"用户体验边界"。200 OK是服务器说的，不是用户说的。当行业还在比拼探测频率和覆盖地域时，他们选择追问：这个200，是真的好吗？

如果你的监控仪表盘永远绿色，但客服工单里的"页面打不开"从未消失——问题可能不在服务器，在监控的定义里。