从一台服务器去 ping 你首页的可用性监控，只能告诉你一件事：这台服务器能访问你的网站。它对收到验证页面的德国客户、对 CDN 边缘节点不断报错的巴西访客一无所知。如果你在多个国家销售或争取排名，从这些国家检查可用性和内容就是 SEO 监控的一部分，它能发现单一探针永远看不到的问题。
本文介绍单一地点的检测会漏掉什么、每个市场要测试什么、为什么来源 IP 很重要，以及一个可以定时运行的小脚本。
单一地点的可用性检测会漏掉什么
单个探针显示的绿色状态页，可能掩盖以下所有问题：
- 区域性 CDN 故障。 CDN 从离访客最近的边缘节点响应。其他节点正常时，某一个节点也可能宕机或返回缓存的错误。
- 出错的地理跳转。 把法国访客跳转到
/fr/的规则可能陷入循环、指向已不存在的页面，或者把整个国家送到错误的店铺。 - 你自己的安全规则封锁了整个国家。 遭受攻击后收紧的防火墙或反爬规则，可能开始对某个地区的所有访客弹出验证。
- DNS 和路由问题。 地理 DNS 可能把某个市场指向已宕机的源站，有些当地解析器在你修改后很久仍保留旧记录。
- 错误的内容。 页面能打开，但货币不对、缺少同意横幅、语言不对，或者价格区域是空的。
这些问题在你的监控服务器上都不会显示为”宕机”。但每一个都会让你损失访客和销售额；如果 Googlebot 也遇到，还会损失排名。
每个市场要检查什么
把每个国家当作一个独立网站来对待。每次检查记录：
- 状态码和跳转后的最终 URL。 在错误 URL 上返回 200 也算失败。
- 响应时间，以便在某个市场宕机之前发现它正在变慢。
- 内容标记，比如只出现在正确本地版本上的字符串：货币符号、当地电话号码或翻译后的标题。
- 被封锁的迹象，比如验证页面的标题、CAPTCHA 表单，或你自己 CDN 返回的 403。
- 由哪个边缘节点响应，可从
cf-ray、x-amz-cf-pop或x-served-by等响应头读取，这样某个地区出问题时你知道该去哪里排查。
先从能带来收入的页面开始：首页、主要分类页、商品页和结账起始页。如果用户依赖搜索和登录，也一并加入。
为什么来源 IP 很重要
大多数商业可用性监控服务从几十个城市的数据中心运行探针。这足以判断”服务器是否在线”，但你的客户并不是这样访问的。CDN 和反爬规则常常把数据中心地址和家庭宽带区别对待，所以可能出现真实访客被要求验证、探针却畅通无阻的情况，或者反过来，访客毫无问题、探针却被拦截。
通过目标国家的住宅代理进行检查，可以弥补这个差距。请求来自该市场的家庭宽带，因此地理 DNS、CDN 和安全规则都会像对待当地客户一样处理它。在大型市场，你还可以细化到城市，例如从美国的多个地区而不是一个地区进行检查。
把两种角色分开：用住宅代理检查来看每个市场收到了什么、是否正常；用数据中心监控或真实用户数据来获得准确的响应时间，因为经过代理的请求多了一跳。
一个小型多地点检查脚本
这个脚本从多个国家检查一组 URL，跟随跳转，并查找内容标记。请把 USERNAME 和 PASSWORD 替换为你的代理凭据。
import requests
USER = "USERNAME"
PASS = "PASSWORD"
GATEWAY = "p.shifter.io:443"
CHECKS = {
"de": ("https://www.example.com/", "€"),
"gb": ("https://www.example.com/", "£"),
"us": ("https://www.example.com/", "$"),
"br": ("https://www.example.com/", "R$"),
}
def check(country, url, marker):
proxy = f"http://customer-{USER}-country-{country}:{PASS}@{GATEWAY}"
try:
r = requests.get(url, proxies={"http": proxy, "https": proxy},
timeout=30, allow_redirects=True)
except requests.RequestException as e:
return country, "ERROR", str(e)[:80]
blocked = "captcha" in r.text.lower() or r.status_code in (403, 429)
ok = r.status_code == 200 and marker in r.text and not blocked
edge = r.headers.get("cf-ray") or r.headers.get("x-amz-cf-pop") or "-"
return country, "OK" if ok else "FAIL", f"{r.status_code} {r.url} edge={edge} {r.elapsed.total_seconds():.2f}s"
for country, (url, marker) in CHECKS.items():
print(*check(country, url, marker))用 cron 或 CI 调度器运行它，把每行结果写入日志或小型数据库，出现失败时发出告警。有两个习惯能让结果更可靠：
- 先确认再告警。 检查失败时，用同一国家的新 IP 重试一次。只有第二次也失败才告警。
- 按规律告警，而不是按单条结果。 一个国家连续三次失败是事故；一周一次超时只是噪声。
把检查变成日常流程
- 从 Search Console 和分析数据中选出市场：带来流量和收入的国家，以及你正在拓展的国家。
- 按价值设定检查间隔。 主要市场的结账流程每隔几分钟检查一次，其余每小时一次。
- 每次部署和 CDN 变更后都要检查，而且要从所有市场检查，而不只是从办公室。
- 每周复盘哪些国家失败最多，以及原因。
如果某个市场在线但很慢，我们的从不同国家测试网站速度指南介绍了如何找到原因。如果你怀疑某些地区被有意提供了不同的内容，从多个地点检测 SEO 隐藏内容的方法使用的就是同样的分国家请求。
总结
可用性是本地化的。一个网站对你的监控来说在线，对整个国家来说却可能宕机。从每个重要市场检查你的营收页面，关注状态、最终 URL、内容和封锁迹象，用第二个 IP 确认失败，你就能在客户告诉你之前发现区域性问题。