URL 可访问性检测

从多个区域检查网站与接口是否可访问

需要后端服务检查会从远程区域发起,每个 IP 每日限 10 次。
正在加载工具…

关于 网站可访问性与延迟检测

网站可用性与延迟检查会从一组远端探测地区,向同一个 URL 发出相同的 GET 请求,并在每个地区的结果返回时实时推送回来。对每个地区,你会得到可达性、HTTP 状态码、协商出的协议、样本成功比例,以及覆盖 DNS、TCP、TLS 和首字节时间的分阶段耗时拆解。

「站点挂了」几乎从来都不是一句全局判断。一个站点可能在某个国家完全不可达,而在其他地方一切正常:可能是某个 CDN 节点不健康、某地的 DNS 应答指向了错误地址、某家中转商当天状态不佳,或者一条防火墙规则挡住了整段地址。只从自己所在的位置去看,无法把这些情况和真正的全局故障区分开。问题的另一半在于:失败是分阶段的。DNS 解析、TCP 建连、TLS 握手、首字节到达,是四个彼此独立的事件,知道停在哪一步,就知道该找哪个团队。

如何使用这个开发者工具

  1. 填入包含协议头的准确 URL。请直接测最终地址,而不是短链或会跳转的主机名,这样结果描述的才是页面本身。
  2. 选择与受众或本次故障相符的地区组 —— 想看全貌就用全球代表出口,已知投诉来源时就选单个大洲。
  3. 运行检查,按国家逐条查看流式返回的结果;每一行在对应地区完成时出现,慢的地区不会拖住其他地区。
  4. 把状态码和耗时放在一起读。首字节 3000 ms 的 200 与 120 ms 的 200 是不同的问题,而两者又都不同于超时。
  5. 下结论之前先重跑一次。单个样本失败只是一次请求失败,并不能证明该国每位访客都受影响。

实例:某个地区的边缘节点问题

对一个几乎处处健康的站点做全球范围检查。其中一个地区的数字把问题的形状清楚地显现出来,而只从自己机器上检查一次永远看不到这些。

请求
URL     https://example.com
地区    全球代表出口
结果
8/8 个地区已完成 · 7 个可达 · 1 个失败 · 平均 214 ms

欧洲
  DE  200  h2   3/3 样本   dns 4 ms · tcp 11 ms · tls 22 ms · ttfb 48 ms
  GB  200  h2   3/3 样本   dns 6 ms · tcp 14 ms · tls 28 ms · ttfb 61 ms
北美洲
  US  200  h2   3/3 样本   dns 8 ms · tcp 23 ms · tls 47 ms · ttfb 96 ms
亚洲
  JP  200  h2   3/3 样本   dns 12 ms · tcp 38 ms · tls 79 ms · ttfb 152 ms
  SG  200  h2   2/3 样本   dns 14 ms · tcp 41 ms · tls 88 ms · ttfb 940 ms
  IN  —    —    0/3 样本   PROBE_TIMEOUT

这里能看到三种状态。德国、英国、美国、日本都是健康的。新加坡 3 个样本成功了 2 个,且首字节时间比 TLS 耗时高出一个数量级,说明连接没问题、是响应慢,属于源站或缓存问题。印度在超时之内什么都没返回,更可能指向路由或过滤,而不是应用。

各类响应对可达性检查意味着什么

其中最关键的分界,是「任何状态码」与「完全没有状态码」之间的区别。

结果探测节点观察到什么能说明什么
2xx收到了带成功状态码的完整响应整条链路端到端可用。它不说明页面内容是否正确。
3xx收到了跳转响应服务器应答了,但给的不是页面。请改测最终 URL,否则你测的是跳转这一跳。
401 / 403服务器拒绝了这次请求链路可用,是应用主动拒绝了这个客户端。在公开 URL 上,这通常是机器人防护对机房地址的反应。
404 / 410资源不存在可达性没问题,是 URL 写错了 —— 这是个有用的否定结果,因为基础设施是健康的。
429被限流源站或它的 CDN 正在限速。反复重跑只会让情况更糟,而不会更清楚。
5xx服务器没能产出正常响应网络已经抵达应用,是应用自己出了问题。这是唯一一类明确指向你自己技术栈的结果。
超时(无状态码)在时限内什么都没到达与任何状态码都属于不同性质:可能是路由、防火墙、丢包路径,或源站始终没回。这里没有任何服务端信号可供解读。
DNS 或 TLS 失败连接没走到发出请求那一步阶段直接点名了出问题的层:域名没解析出来、证书被拒,或从该地区无法完成握手。

常见问题排查

浏览器里打开一切正常,但所有地区都返回 403。

成因 机器人防护。WAF 和 CDN 安全产品对机房地址段打分很严,并且期待浏览器特征 —— 完整的请求头集合、TLS 指纹,有时还有 JavaScript 质询 —— 而探测节点不会产生这些。

解决办法 这是一条关于真实行为的正确结论。如果站点由你掌控,可以放行探测行为,或改测受保护路径之外的端点,例如健康检查地址。

检查返回 3xx,浏览器里却直接看到了页面。

成因 浏览器会静默跟随跳转,你根本看不到那一跳。探测节点如实报告它实际收到的那个响应。

解决办法 填入最终 URL —— 规范主机名、正确协议、按实际情况带或不带 www。如果怎么都跳不完,多半是 http 与 https 之间或裸域与 www 之间存在跳转环,它会表现为反复跳转或超时。

只有一个地区失败,其他地区全部成功。

成因 该地区的 DNS 返回了不同地址、某个 CDN 节点不健康、这条路径上的互联或中转出了问题,或者防火墙挡住了某段地址。从外部看,这四种情况症状一样。

解决办法 读失败阶段:DNS 失败说明在那里没解析出来,连接失败或超时说明地址不可达,TLS 失败说明证书不对或路上有拦截设备。确认结果稳定复现后再动配置。

用到一半就不能再检查了。

成因 额度是每个访问 IP 每个 UTC 自然日 10 次,由同一公网地址背后的所有人共用,因为每次检查都会向第三方服务器产生真实请求。

解决办法 提前规划:每次只测一个 URL、一个地区组,而不是边试边找。需要持续观测时,请使用你已授权其持续轮询的监控服务。

延迟数字比用户反馈的差得多。

成因 每个探测都是冷启动:一次完整 DNS 查询、一次全新 TCP 握手、一次完整 TLS 协商,没有会话复用。真实访客会复用连接、命中热缓存。

解决办法 比较分阶段拆解而不是总耗时。首字节时间最接近回访用户的真实体验;DNS、TCP、TLS 属于一次性成本,真实会话会把它们摊薄。

所有地区都返回 200,用户仍然说站点坏了。

成因 可达性检查只请求一个 URL 并读取状态。它不执行 JavaScript、不加载子资源,也不验证页面是否渲染成功。

解决办法 把全绿结果理解为「关于网络和源站入口」的结论。静态资源加载失败或某个 API 调用报错,需要浏览器级测试或你自己的应用日志来定位。

适合用这个工具的场景

  • 在叫醒任何人之前,先判断一次故障报告是全局性的还是局限于某个地区。
  • 确认一次 DNS 变更、CDN 配置或证书续期,在你自己网络之外也已经生效。
  • 找出慢在哪个阶段 —— DNS、TCP、TLS 还是应用 —— 而不是对着一个总耗时猜。
  • 检查刚上线的端点,在用户真正所在的那些大洲是否可达。

应该换用别的工具的场景

  • 持续监控与告警。这是一次快照,且每日额度很小;请使用你已授权其按计划轮询的监控服务。
  • 通过某个指定代理去访问站点。地区代理出口检查会让请求经过你提供的代理,并报告目标看到了什么。
  • 审计页面内容、链接、无障碍或安全性。它读取的是响应状态而不是页面,也不会做任何抓取。

隐私与数据处理

URL 和你选择的检查参数会发送到本站服务器,以便远端探测节点代你发起请求。随后每个探测节点会从自己所在地区直接访问目标,因此目标站点会看到一次来自该地区地址的请求,并可能像记录任何访客一样记录它。正因为 URL 会送到我们的服务器、并由第三方网络实际发起请求,请不要提交后台管理地址、带签名或预授权的链接、包含访问令牌的 URL,以及内部主机名。该检查额度为每个访问 IP 每个 UTC 自然日 10 次,刻意设得很紧,因为每次检查都会向别人的服务器产生真实流量。

相关开发者工具

常见问题

返回 200 就代表站点健康吗?

它代表一个探测节点对一个 URL 发起了一次请求,并拿回了成功状态。它不覆盖其他页面、登录态流程、子资源或 API 依赖。绿色的一行只是关于链路和入口的证据。

为什么只有一个地区失败?

各地的 DNS 应答、CDN 节点健康度、互联关系、中转路由和防火墙规则都不相同,其中任何一环都可能单独出问题。区分它们要看失败阶段:DNS 失败、连接超时和 TLS 错误分别指向不同的层。

一天能检查多少次?

每个访问 IP 每个 UTC 自然日 10 次。额度小是故意的,因为每次检查都会向一台并未请求被测试的服务器发出真实请求,而且这份额度由同一公网地址背后的所有人共用。

它会抓取我的站点吗?

不会。它只请求你填入的那一个 URL 并报告响应,不跟随任何链接,不加载图片或脚本,也不保存页面内容。

为什么这里的延迟比我自己测的高?

每个探测都是冷启动 —— 全新的 DNS、全新的 TCP 连接、完整的 TLS 握手 —— 而你的浏览器和用户会复用连接、命中热缓存。请把探测结果在地区之间、时间之间互相比较。

可以检查内网地址或有密码保护的 URL 吗?

不建议。URL 会先送到我们的服务器,再由第三方网络从公网地址发起请求,因此内部主机名只会解析失败,而带令牌的 URL 则会被不必要地暴露。请改测一个公开的健康检查端点。

成功率既不是 0 也不是 100%,说明什么?

每个地区会取多个样本。部分成功意味着一些请求完成了、另一些没有,这正是间歇性丢包、负载均衡后面某个节点不健康,或限流开始生效的典型特征。