源站防火墙只允许指定地址访问时，监控服务如果频繁更换出口 IP，白名单会很难维护。使用可公布、可追踪的固定探针 IP，能够让源站识别监控请求、限制放行范围并保持长期测试基线。不过固定 IP 只是监控网络设计的一部分：一台探针正常，不能证明所有地区、运营商和真实用户都能正常访问。
固定探针首先解决白名单问题
对内部 API、预发布站点或受限管理页面，监控探针需要通过防火墙才能发起健康检查。若监控供应商提供稳定的探针地址段，源站可只允许这些来源访问指定端口或路径，而不必向全网开放。
地址必须从监控供应商官方文档、控制台或 API 获取，记录 IPv4、IPv6、地区和更新时间。不要根据一次日志反推出单个 IP 后长期放行，因为供应商可能扩容或切换节点。自建探针则要登记云资源、NAT 网关、负责人和续费情况。
固定出口还能提高结果可比性
同一探针长期从相近的网络位置访问，可以减少来源路径变化带来的噪声，更容易比较昨天和今天的延迟、TLS 握手时间、首字节与业务响应。若探针每次随机更换运营商和地区，性能变化可能来自测量路径，而不是网站自身。
可比性不等于代表性。固定探针反映的是“这个位置到网站”的体验，不能直接外推到全国或海外所有用户。
监控至少拆成四层
| 层级 | 检查内容 | 常见故障 |
|---|---|---|
| DNS | 解析结果、响应时间、权威状态 | 地区解析错误、缓存、记录未生效 |
| 网络与 TLS | 连接、路由、证书链、SNI、到期时间 | 防火墙、丢包、证书过期或不匹配 |
| HTTP | 状态码、重定向、首字节、响应内容 | CDN 回源、WAF、应用 5xx |
| 业务 | 登录前查询、API 响应或合成交易 | 页面能开但核心功能失败 |
业务探测应使用专门测试账号、最小数据和可清理的测试记录，避免在生产中反复创建真实订单或向用户发送通知。
为什么需要多地、多运营商
网站可能在一个地区正常，另一个地区因 CDN 节点、DNS、运营商互联或路由故障而失败。关键业务可选择至少两个独立地区和不同运营商的探针；全球业务再按主要用户分布增加区域。探针全部放在同一家云厂商、同一可用区，仍然存在共同故障点。
选择入口时，可利用极跃圈网址导航查找 DNS、HTTP 和多地检测工具进行人工交叉验证。公开工具适合辅助判断，不替代持续监控，也不能对未经授权的网站做高频探测。
白名单放行要限制到必要范围
监控 IP 被加入防火墙，不代表它应该拥有管理权限。可以仅开放 HTTPS 业务端口和特定健康检查路径，后台管理、SSH、数据库仍走独立入口。应用层为探针使用专用令牌时，也应只有读取健康状态的最小权限，并定期轮换。
若健康检查接口返回数据库版本、内部地址或完整错误堆栈，会把敏感信息暴露给探针和日志。响应应尽量简单，只返回判断服务健康所需的状态。
如何区分网站故障和探针故障
- 单个探针失败、其他地区正常，先检查该探针网络和所在区域。
- 多个独立探针同时失败，更接近网站、DNS、CDN 或上游问题。
- 固定探针失败但真实用户监控正常，检查白名单是否遗漏了新的探针地址。
- 所有合成探针正常但用户投诉增加，检查探测路径是否过浅或未覆盖用户地区。
告警可以采用多探针确认、连续失败次数和业务重要等级，避免一次瞬时超时就惊动所有人。反过来，不能为了减少误报把持续失败过滤掉。
地址变更与灾备怎么做
监控供应商更新探针网段时，先加入新增地址、验证请求和日志，再删除官方弃用地址。自建探针迁移时采用相同的双白名单流程。至少准备一个独立备用探针，以便主监控区域故障时仍能判断网站状态。
验收一套监控方案
- 从每个探针查询其真实出口并与资产表一致。
- 确认源站只对官方或自建固定来源放行业务探测范围。
- 在维护窗口内模拟测试页面返回错误，验证告警、通知和恢复闭环。
- 分别测试 DNS、TLS、HTTP 和业务内容，确保告警能指出层级。
- 检查探针日志、令牌和测试数据的权限及保存期限。
固定 IP 让探针更容易被放行和比较，但可靠监控最终依赖多路径覆盖、分层探测和清晰的响应流程。把“某个探针能打开网页”当作网站整体健康，会比没有监控更容易产生错误信心。
