为了实现动态路由与零停机发布把传统 Nginx 换成云原生 API 网关（Apache APISIX），搜索收录与关键词排名却断崖式暴跌？排查 etcd 节点漂移与动态健康检查误踢致蜘蛛频报 503、real-ip 插件缺失致爬虫 IP 连坐打爆 limit-req 触发 429、proxy-rewrite 覆写 Host 诱发 Canonical 泄露内网域名与动态 SNI 握手失败我踩过的几个深坑

随着微服务数量不断增加，以及前端服务端渲染（SSR）集群的频繁迭代，传统的静态 Nginx 反向代理逐渐跟不上发布节奏。每次微服务扩容缩容、蓝绿发布或者新增路由规则，运维人员都必须修改 nginx.conf 并执行一次 nginx -s reload。

在平常时段，重载配置并没有太大感觉。但在白天业务高峰期，短时间内频繁 reload 会导致 Nginx worker 进程频繁更替，旧 worker 在等待长连接释放时不断堆积，不仅偶尔出现端口竞争和短暂连接重置，还把配置发布的流程卡得死死的。

为了彻底摆脱静态配置重载的束缚，团队决定把外网流量入口全面迁移到云原生 API 网关 Apache APISIX，利用它底层的 OpenResty 运行时和 etcd 强一致性配置中心，实现全量路由、上游节点和插件的毫秒级动态热更新。

迁移上线的第一周，内部联调体验确实有了明显提升。新增一条带有灰度分流的路由规则只需要调用一次 Admin API，微服务滚动更新时 Pod 的 IP 也会通过注册中心同步到 upstream，Nginx worker 进程稳如磐石，再也不需要任何 reload 动作。

然而到了第二周，站长工具的监控数据彻底拉响警报。百度站长平台的抓取异常监控里突然多出了数万次 503 和 429 报错，Google Search Console 覆盖率报表里的“已排除”页面成倍攀升，大量新发布的文章完全无法收录，整站核心关键词排名在一周之内腰斩。

把传统静态反向代理替换成基于 etcd 和 Lua 动态插件体系的 API 网关时，如果忽略了搜索引擎爬虫的抓取特性与边界场景，原本为了提升工程效率的技术改造，很容易演变成技术 SEO 的致命灾难。

动态健康检查过激与 etcd 节点同步漂移，爬虫撞上 503 熔断

为了防止某个 SSR 渲染节点故障导致用户看到白屏，我们在 APISIX 的上游配置中开启了主动与被动健康检查（Health Check）。

初期的配置为了追求对故障的极速响应，参数设置得非常激进：

{
  "nodes": {
    "10.0.3.11:3000": 1,
    "10.0.3.12:3000": 1,
    "10.0.3.13:3000": 1
  },
  "type": "roundrobin",
  "checks": {
    "active": {
      "http_path": "/healthz",
      "healthy": { "interval": 2, "successes": 1 },
      "unhealthy": { "interval": 1, "http_failures": 2 }
    },
    "passive": {
      "unhealthy": { "http_failures": 2, "http_statuses": [500, 502, 503, 504] }
    }
  }
}

这种配置在普通用户低频浏览时问题不大，但在搜索引擎爬虫到来时瞬间崩塌。

百度蜘蛛（Baiduspider）与谷歌爬虫（Googlebot）在抓取时往往采用高并发管道式探测，瞬间向目标站点发起几十个并行 HTTP 连接。SSR 节点在瞬间承受大量无缓存的深层文章渲染计算时，CPU 会偶发性被打到 90% 以上，导致个别请求耗时从 80 毫秒波动到 1.5 秒，甚至偶发返回 504。

根据上面的配置规则，只要连续出现两次慢响应或 504，APISIX 就会立刻将该节点标记为 unhealthy。流量瞬间被全部压向剩下的两台节点，剩下的节点承受了额外的抓取压力，也接连触发被动失败阈值，导致整组 upstream 节点被全部踢出可用列表。

此时，APISIX 找不到任何可用的上游节点，直接在网关层给爬虫返回了 HTTP 503 Service Temporarily Unavailable。

普通用户如果两秒后刷新页面，健康检查刚好重新拉起节点，页面就能正常展示。但搜索引擎爬虫会准确记录下每一次 503 返回码。百度爬虫的调度系统有极其严密的频次保护机制，当目标域名在短时间内密集返回 503 错误时，系统会判定该站点处于服务瘫痪或严重过载状态，立即启动熔断保护，把分配给该站的日抓取配额（Crawl Budget）从几十万次直接腰斩到几千次。

更棘手的是，在微服务滚动更新期间，K8s 注册中心向 etcd 推送节点下线与上线事件。如果 etcd 集群出现几十毫秒的网络抖动，节点状态在多台 APISIX 数据面网关之间产生同步延迟，正在并发爬取的蜘蛛就会在不同网关节点上偶发命中已销毁的旧容器 IP，不断引发 502 Bad Gateway。

缺少 real-ip 插件导致 CDN 节点 IP 连坐，爬虫打爆 limit-req 触发 429

为了保护后端 SSR 服务不被恶意脚本抓取，我们在 APISIX 的全局规则中启用了 limit-req 限流插件，限制每个客户端 IP 每秒最多发起 10 次请求，突发流量允许 20 次。

在传统的 Nginx 环境中，我们在 http 块中配置了 set_real_ip_from 和 real_ip_header X-Forwarded-For，Nginx 会自动从请求头中剥离出真实的客户端 IP 存入 $remote_addr 变量。

但是在 APISIX 体系中，网关默认并不会主动去解析代理层后面的客户端原始 IP。外部流量在经过云厂商 CDN 或四层负载均衡（SLB）到达 APISIX 时，TCP 握手的直接源地址其实是 CDN 边缘节点的反代 IP。

如果我们没有在 APISIX 的 config.yaml 或者全局规则中显式启用 real-ip 插件，APISIX 就会把 CDN 边缘节点的机房 IP 当成客户端的真实地址。

# 容易被遗漏的关键配置：apisix/conf/config.yaml
nginx_config:
  http:
    real_ip_header: "X-Forwarded-For"
    real_ip_from:
      - 100.64.0.0/10
      - 172.16.0.0/12
      - 10.0.0.0/8

一旦缺少正确的真实 IP 映射，灾难就会在爬虫抓取时爆发。

百度爬虫分布在全国各地的几百个爬虫 IP，顺着各省份的 Local DNS 请求进入 CDN 节点回源。CDN 节点把来自几十个不同爬虫的请求通过同一个长连接或者少数几个边缘回源 IP 转发给 APISIX。

在 limit-req 插件眼里，这并不是上百个独立合法的搜索引擎爬虫在有序抓取，而是一个单一 IP 在每秒狂轰上百次请求。限流漏桶瞬间被填满，APISIX 毫不留情地向后续所有的爬虫请求返回了 HTTP 429 Too Many Requests。

在搜索引擎技术规范中，429 状态码代表明确的限流拒绝信号。Googlebot 收到 429 后会按照退避算法主动降低爬取频率，严重时甚至连续数天停止抓取新内容。百度蜘蛛则更加敏感，大面积遭遇 429 会直接导致抓取队列停滞，刚发布的快讯和长尾文章因此错失收录黄金期。

proxy-rewrite 误改 Host 请求头，Canonical 标签泄露内网域名

在配置 APISIX 路由规则把外部流量转发到内部微服务时，有一个看似微小但破坏力极强的配置项：pass_host。

APISIX 在定义 upstream 时提供了三种 pass_host 策略：

1. pass：保持客户端发送的原始 Host（例如 www.llbbs.cn）直接透传给上游。
2. node：将 Host 改写为 upstream 节点中配置的域名或 IP（例如 k8s-ssr-service.default.svc.cluster.local:3000）。
3. rewrite：显式指定一个固定的 Host 头。

在初次通过 APISIX Dashboard 创建路由时，某些开发人员习惯性地选择了 node，或者在路由插件链中盲目配置了 proxy-rewrite：

{
  "uri": "/article/*",
  "plugins": {
    "proxy-rewrite": {
      "host": "ssr-node-internal.local"
    }
  },
  "upstream": {
    "type": "roundrobin",
    "nodes": {
      "10.0.5.21:3000": 1
    }
  }
}

后端运行的 Next.js 或 Nuxt 服务端渲染框架在生成 HTML 时，往往会通过读取请求头里的 host 与 x-forwarded-proto 来动态组装页面的规范网址（Canonical URL）与结构化数据（JSON-LD）：

// 服务端渲染获取规范网址的常规写法
export async function getServerSideProps({ req }) {
  const host = req.headers.host;
  const canonicalUrl = `https://${host}${req.url}`;
  return { props: { canonicalUrl } };
}

当 Host 头被 APISIX 改写为 ssr-node-internal.local 后，SSR 渲染输出的 HTML 头部赫然变成了：

<link rel="canonical" href="https://ssr-node-internal.local/article/315.html" />
<meta property="og:url" content="https://ssr-node-internal.local/article/315.html" />

更糟糕的是，如果爬虫访问了一个不带斜杠的分类目录 URL（如 /category/linux），后端框架识别到这是目录路径后，会主动触发 301 重定向，而重定向的 Location 头同样依赖 req.headers.host 生成，直接返回了 Location: https://ssr-node-internal.local/category/linux/。

搜索引擎蜘蛛在爬取页面时极度看重规范标签。当 Googlebot 在公网的 www.llbbs.cn/article/315.html 页面中读到规范网址指向内网无法解析的域名时，算法会认为公网这个页面只是内网私有资源的副本，从而直接取消公网页面的索引资格。

而在百度蜘蛛顺着内网 Location 跳转时，DNS 解析直接报错，整条抓取链条瞬间变成 301 死链。数千个核心页面的权重被引导到了虚无缥缈的内网域名上，造成收录大面积脱落。

动态 SSL 证书握手缺少默认回退，老旧爬虫 TLS 握手失败

传统 Nginx 在配置 HTTPS 时，证书文件直接写在静态配置的 server 块内。如果客户端发起的 TLS 握手请求没有携带 SNI（Server Name Indication）扩展头，Nginx 依然会把默认 server 块中的证书发送给客户端，完成 TLS 握手。

而在 APISIX 中，为了支持多租户与海量域名的毫秒级动态证书绑定，网关底层利用 OpenResty 的 ssl_certificate_by_lua 阶段，动态提取握手中的 ssl.server_name，然后去 etcd 的 /ssl 路径下实时匹配对应的证书与私钥。

在现代浏览器和 Googlebot 这种基于新版 Chromium 内核的现代爬虫抓取时，SNI 扩展头都会正常携带，TLS 握手毫无问题。

但国内搜索引擎的部分特定抓取集群（尤其是百度图片蜘蛛的部分老旧节点、某些外链探测探针以及监控爬虫），其底层爬虫引擎采用的仍是较旧的 TLS 客户端库，在发起 ClientHello 握手时根本没有注入 SNI 扩展字段。

当 APISIX 拿不到 ssl.server_name 时，它无法匹配 etcd 中的具体域名证书。如果 APISIX 没有配置全局回退证书，网关就会直接返回底层 OpenResty 自签名的临时伪证书，或者直接关闭 TLS 连接。

# 模拟没有携带 SNI 的旧版爬虫发起探测
openssl s_client -connect www.llbbs.cn:443 -servername ""

老旧蜘蛛在握手阶段直接抛出 SSL_ERROR_BAD_CERT_DOMAIN 或 Certificate Untrusted 错误，根本走不到发送 HTTP GET 请求的正文阶段。在站长后台的蜘蛛抓取日志里，这类错误往往表现为“连接超时”或“握手失败”，既没有任何 HTTP 状态码，也不会在 APISIX 的正常 access 日志里留下访问记录，极难被排查。

response-rewrite 破坏压缩流，正文截断导致快照残缺

为了在某些特定渠道投放或者监控需要，我们在 APISIX 上给部分内容路由挂载了 response-rewrite 插件，用于在服务端返回的 HTML 闭合标签 </body> 前动态注入一段统计脚本。

APISIX 的 response-rewrite 插件在修改响应体时，默认会尝试把上游返回的 body 全部缓存在 Lua 内存中。

如果后端 SSR 服务已经开启了 gzip 压缩，或者上游网关启用了分块传输（Transfer-Encoding: chunked），后端返回给 APISIX 的原本是一个经过压缩的二进制流。

response-rewrite 插件在没有配置解压缩逻辑的情况下，直接将纯文本脚本追加到了二进制 gzip 流的末尾，同时没有重新计算并修正响应头里的 Content-Length。

这就产生了一个极其怪异的响应：

1. 响应头声明了原本压缩包的长度，例如 Content-Length: 15420。
2. 实际传输的字节因为追加了未压缩文本，超出了声明的长度。
3. 压缩包结构被尾部追加的纯文本破坏，客户端解压时报校验和错误（CRC mismatch）。

现代桌面浏览器在遇到此类异常时往往具备一定的容错机制，可能会尝试静默截断并勉强渲染。但搜索引擎爬虫对 HTTP 协议和数据流的完整性极其敏感。

百度蜘蛛在下载到损坏的 gzip 流时，要么直接中断抓取报传输错误，要么只能解析出前几十个字节的混乱字符。抓取快照变成了只有几个乱码字符的空白页，被搜索引擎反作弊算法直接判定为无价值的垃圾页面。

彻底解决网关层 SEO 风险的生产配置实践

排查清楚上述深坑后，我们在 APISIX 的整体架构和配置规范上做了全面加固，把搜索引擎友好度作为网关核心稳定性的基准要求。

1. 修正网关真实 IP 与限流白名单

在 apisix/conf/config.yaml 中补充所有 CDN 与内网负载均衡的回源 CIDR 段，并在全局规则中优先加载 real-ip 插件：

nginx_config:
  http:
    real_ip_header: "X-Forwarded-For"
    real_ip_recursive: "on"
    real_ip_from:
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 100.64.0.0/10

对于限流插件 limit-req，绝对不能对搜索引擎爬虫一刀切。我们在网关层编写了轻量级的匹配规则，通过客户端真实 IP 的反向 DNS（rDNS）PTR 记录与知名爬虫网段判断是否为合法蜘蛛，对合法爬虫跳过限流逻辑：

{
  "uri": "/*",
  "plugins": {
    "limit-req": {
      "rate": 15,
      "burst": 30,
      "key": "var.real_ip",
      "rejected_code": 429
    }
  }
}

同时在 APISIX 路由前置规则中，把识别出的合法搜索引擎爬虫路由到独立的无限制通道，彻底避免误伤。

2. 规范 upstream 的 pass_host 策略

在所有面向内容展示与 SSR 渲染的路由定义中，明确将 pass_host 强制锁定为 pass，严禁使用 node 或随意篡改 Host 头：

{
  "uri": "/article/*",
  "name": "article-ssr-route",
  "upstream": {
    "type": "roundrobin",
    "pass_host": "pass",
    "nodes": {
      "10.0.5.21:3000": 1,
      "10.0.5.22:3000": 1
    },
    "timeout": {
      "connect": 2,
      "send": 5,
      "read": 5
    }
  }
}

在后端 SSR 应用代码中，我们也不再单纯相信请求头里的 host，而是通过应用环境变量注入固定的公网权威域名，用于绝对路径 Canonical 标签的拼装。

3. 放宽健康检查阈值与优雅降级

把被动健康检查的失败阈值从过激的 2 次提高到 10 次，并将单次检查的检测窗口拉长，同时开启上游请求自动重试：

{
  "retries": 2,
  "retry_timeout": 3,
  "checks": {
    "active": {
      "http_path": "/healthz",
      "healthy": { "interval": 5, "successes": 2 },
      "unhealthy": { "interval": 2, "http_failures": 5 }
    },
    "passive": {
      "unhealthy": {
        "http_failures": 10,
        "http_statuses": [502, 503, 504]
      }
    }
  }
}

当个别 SSR 节点因突发抓取出现短暂卡顿时，APISIX 会自动将请求重试分配给健康的同伴节点，而不是草率地把整个上游全部熔断。

4. 显式配置默认 SSL 证书与禁用侵入式响应体改写

在 APISIX 的 config.yaml 中显式指定默认主域名的证书文件作为全局兜底，确保老旧无 SNI 客户端请求也能顺利握手：

apisix:
  ssl:
    ssl_trusted_certificate: "/etc/ssl/certs/ca-bundle.crt"
    fallback_sni: "www.llbbs.cn"

同时，严禁在网关层通过 response-rewrite 插件进行跨编码的 HTML 正文注入。页面元数据与统计脚本全部回归到 SSR 前端框架的代码内部进行统一管理，网关层只负责高性能的路由与透传。

恢复成效与日常巡检建议

完成网关规则与健康检查参数的修正后，我们在预发环境使用模拟爬虫工具进行了全量回归探测。

通过向 APISIX 发送连续 200 个并发且无 SNI、无 Cookie 的伪装爬虫请求，网关返回码全部稳定在 200，HTML 头部输出的 Canonical 标签完全一致，没有出现任何 429 限流或 503 熔断。

配置上线一周后，百度站长平台的抓取异常折线逐步归零，日抓取量重新恢复到了数万次的健康水平，被误判剔除的新文章重新进入收录队列，整站排名也在后续两周内逐步回归原有梯队。

在现代技术架构向云原生、动态化演进的过程中，每一个基础设施层面的改动都不只是后台运维的内部事务。越靠近公网入口的组件，其细微的行为变化对搜索引擎爬虫的影响越深远。做好真实 IP 透传、保护好请求头的原生状态并留足健康检查的弹性空间，系统才能在享受动态治理便利的同时，守住搜索流量的基本盘。