Google 能收录，为什么手机却打不开我的网站

2026 年 7 月 31 日，Google Search Console 开始记录 s1oopx.bond 的搜索展示。两天后，我用没有开启代理的手机从 Google 点进网站，浏览器却直接报网络错误。

这两个结果并不矛盾。Google 能抓取和索引页面，只能说明 Googlebot 所在网络当时能够访问；国内某个手机网络能否建立到网站入口的连接，是另一条链路。

结论先行#

这次排查得到四个结论：

1. 页面与源站并没有整体失效，通过代理访问一直正常。
2. 山西本地网络直连同一域名解析出的两个 Cloudflare IPv4 地址，结果一个成功、一个在 TLS 前被重置。
3. 这只能证明“这条网络在这个时间对两个入口的可达性不同”，不能外推成“中国大陆都打不开 Cloudflare”。
4. 扫描所谓“优选 IP”可以帮助诊断和监控，但不能自动修复普通浏览器访客的公开访问路径。

原稿后半篇转去讨论 Xray、443、SNI 和 Host。那些内容属于“可控客户端怎样指定入口”，与普通网站访客怎样访问不是同一个问题，反而掩盖了这次排查真正有价值的边界，所以这里全部删掉。

同一个域名，实际走了两条路#

电脑长期启用系统代理，因此访问链路是：

电脑浏览器
  -> 系统代理
  -> 代理出口
  -> Cloudflare 边缘
  -> Cloudflare Tunnel
  -> Nginx 静态站

手机没有代理：

手机浏览器
  -> 本地运营商
  -> Cloudflare 边缘
  -> Cloudflare Tunnel
  -> Nginx 静态站

后半段完全相同，差别发生在用户到 Cloudflare 入口之间。代理出口一直可达，手机所在网络却不稳定，于是电脑端给了我“网站已经正常”的错觉。

这里应该拆开三个问题：

搜索引擎收录从来不是端到端可用性监控。

强制连接两个 Cloudflare 地址#

DNS 当时返回两个 IPv4 地址：

104.21.88.226
172.67.153.179

如果直接访问 IP，TLS 证书与虚拟主机都会不匹配。正确的测试应保留域名、SNI 与 Host，只替换底层连接地址。curl --resolve 正好用于这个目的；--noproxy "*" 则确保系统代理没有再次绕开本地路径。

$ips = @('104.21.88.226', '172.67.153.179')

foreach ($ip in $ips) {
  curl.exe --noproxy "*" `
    --connect-timeout 5 `
    --max-time 12 `
    --resolve "s1oopx.bond:443:$ip" `
    -sS -o NUL `
    -w "ip=$ip http=%{http_code} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}`n" `
    https://s1oopx.bond/
}

2026 年 8 月 2 日在山西本地关闭代理复测，结果仍然是：

这组测试很有价值，因为它把页面、域名证书和 Tunnel 后端都固定住了，只改变 Cloudflare 连接地址。

但它的证据范围也很窄：一个地区、一条运营商线路、两个地址、很少的请求。它能定位当前故障，不能代表全国，也不能保证明天仍然相同。

为什么同一个域名会出现不同结果#

Cloudflare 橙云记录不会把真实源站地址直接返回给访客，而是返回 Cloudflare 的共享 Anycast 地址。Anycast 的含义不是“这个 IP 永远对应某一个城市机房”，而是多个位置发布同一地址，由网络路由把连接带到某个可达入口。

因此真正被测试的是：

某个用户网络
  -> 某个 Cloudflare Anycast 地址
  -> 当时被选中的网络路径

两个地址在一条线路上的表现可以不同；同一个地址从北京、杭州和山西连接，也可能得到不同结果。把 IP 简单标成“香港节点”或“美国节点”，会误解 Anycast 的工作方式。

这次最稳妥的描述不是“Cloudflare 被墙了”，而是：

当前山西本地网络到部分 Cloudflare 入口的连接不稳定，而代理出口走了另一条可用路径。

“优选 IP”为什么不是公开网站的直接修复#

扫描一批 Cloudflare 地址，按成功率、TLS 时间和延迟排序，可以回答两个问题：

• 当前故障是否只出现在部分入口；
• 自己控制的客户端应优先测试哪些地址。

它回答不了另一个关键问题：普通访客怎样自动使用这些结果。

浏览器会按照公开 DNS 解析域名。橙云开启时，权威 DNS 返回哪些 Cloudflare 地址由 Cloudflare 控制；站长不能把扫描出的某个共享地址塞给所有访客，同时还保持标准橙云解析行为。

本地 Hosts、curl --resolve 或自定义客户端当然可以强制指定入口，但那是诊断手段或私有配置，不是公开网站的分发方案。

所以“三地找最快 IP，再选一个主入口”最多构成监控系统，不能单独成为网站修复方案。原稿把这两步连在一起，是最需要纠正的地方。

普通网站真正可以选择什么#

对这个站来说，最小且诚实的下一步不是宣称“已经优选出节点”，而是先做多线路监控，确认问题出现的频率和范围；如果大陆可达性是硬目标，再评估独立镜像或合规的大陆分发方案。

Cloudflare 自己也提供 China Network，但它属于企业级产品，并要求满足中国大陆的备案等条件。它与扫描公共 Anycast 地址不是一回事。

以后怎样验证“网站真的上线了”#

发布完成后，我会把验收拆成四层：

构建层：静态文件、链接和资源是否正确
源站层：Nginx 与 Tunnel 是否健康
边缘层：Cloudflare 是否能正常代理
用户层：不同网络是否能完成 DNS、TLS 和 HTTP 请求

Search Console 只覆盖“Google 是否能发现并处理页面”的一部分。电脑通过代理访问正常，也只覆盖一条网络路径。真正面向读者的网站，至少还需要一条不经过日常代理的外部验证。

这次经历最值得留下的不是某个 Cloudflare IP，而是一个更朴素的判断：

能被搜索到、页面能返回、用户能打开，是三个不同的成功条件。

参考资料：

• Google Search：How Search Works
• Cloudflare：Proxy status
• Cloudflare：What is Anycast?
• Cloudflare China Network