土耳其区账号被 Google Search Console 判成垃圾流量后，我把验证链路重搭了一遍

店里有个做土语小站的外包单，站点部署在 Cloud Run 上一个 512MB 实例，前面挂 Cloudflare。Google Search Console 是去年底接进来的，验证方式一直用「HTML 文件上传」。上周开始，Search Console 的「安全与手动操作」里冒出一条提示，说站点有「纯垃圾」的自动流量，同时覆盖率报告里原本每天稳定 2000 左右的抓取请求掉到不足 300，索引量从 4200 条掉到 3900 条。后台没有手动操作记录，但抓取预算明显被砍了。

我第一反应是查服务器日志，看 Googlebot 的命中模式。结果发现一个很具体的问题：Cloud Run 前面套了 Cloudflare 之后，X-Forwarded-For 里同时带了 Cloudflare 的出口 IP 和真实客户端 IP，而 X-Forwarded-Proto 被 Cloudflare 改写成 http。Search Console 的文件验证路径是 https://example.com/googleXXXX.html，但 Cloud Run 服务内部按 http 拼重定向，于是 Googlebot 拿到的验证文件是 301 到 http:// 版本，再被 Cloudflare 跳回 https://。一次验证变成三次跳转，抓取预算全耗在这上面。

处理步骤分三块。先修转发头，在 Cloud Run 的容器启动参数里加环境变量，让应用信任 Cloudflare 的段：

# 部署时加，不要写死 IP，用 Cloudflare 公布的段
--set-env-vars TRUSTED_PROXY_CIDRS="173.245.48.0/20,103.21.244.0/22,104.16.0.0/13"

应用侧改写取真实 IP 的函数，只在请求来自可信段时才认 CF-Connecting-IP。然后改验证方式，从 HTML 文件换成 DNS TXT，绕开跳转链路。TXT 记录在 Cloudflare 的 DNS 面板加，TTL 设 300，等了两轮验证周期才通过。最后把 googleXXXX.html 这个路径在 Cloudflare 里设一条 Page Rule，关闭 Always Use HTTPS，只对这一个路径生效，避免以后又有人用文件验证时被改写。

为什么选 DNS 验证：机制上 Search Console 验证的是「你对域名的控制权」，DNS TXT 不经过 HTTP 层，跳转、缓存、WAF 都影响不到它。代价是 TXT 记录不能随手删，后续再验证还要用，而且换 DNS 服务商时会丢，得记在部署清单里。另一个取舍是 TRUSTED_PROXY_CIDRS 写进环境变量之后，Cloudflare 段更新时要手动同步，我加了一个每周跑一次的检查脚本，从 Cloudflare 的 ips-v4 接口拉最新段，跟环境变量里的值做差集，不一致就发邮件。

会失效的地方有三个。第一，如果站点开了 Cloudflare 的「Under Attack」模式，Googlebot 也会被挑战，Search Console 的抓取会直接报 403，这时验证和抓取都会挂，得把 Googlebot 的 ASN 加进白名单。第二，DNS TXT 验证对子域名有边界，www 和裸域要分别加记录，我一开始只加了裸域，www 那条一直报「无法验证」。第三，Cloud Run 的冷启动会让第一次验证请求超时，如果验证文件放在实例本地而不是镜像里，重启后文件就没了，这是我自己踩过的坑，后来改成文件打进镜像。

现在抓取量回到每天 1800 左右，索引量缓慢回升，但「纯垃圾」那条提示还没消失。想问问跑过土语站或者多语言站的朋友：你们遇到 Search Console 的自动流量判定时，是先申诉还是先改结构？申诉窗口里填什么证据比较有效？