很多站点在完成 IPv6 改造后，会发现抓取日志里同时出现来自 IPv4 与 IPv6 的请求。表面上看覆盖范围没变，但实际抓取到的 URL 数量、回访频率可能出现差异。IPv6 双栈本身不会直接带来收录变化，它更像是把“入口是否可达”这件事拆成了两条链路：任何一条出问题，蜘蛛看到的站点就只是一个残缺版本。
为什么双栈站点更容易出现抓取路径差异
单栈站点只有一条访问路径，出问题就是全站不可达，现象很直接。双栈站点则不同：IPv4 与 IPv6 可能走不同的 DNS 解析结果、不同的 CDN 节点、不同的回源线路，甚至落到不同的源站机器上。只要其中一条链路的配置有偏差，蜘蛛就会按“哪条先通”来决定访问哪条，而你看到的日志自然只反映那条链路的状态。
更麻烦的是，IPv6 的可用性往往只在部分地区或部分网络环境里成立。同样是 AAAA 记录，某些运营商可以正常解析并回访，另一些则直接超时重试。抓取量因此呈现忽高忽低的波动，而不是稳定的增长或下降。
先确认蜘蛛到底走了哪条链路
从日志入手
- 统计同一时间窗口内，来自 IPv4 与 IPv6 的请求条数比例，观察是否存在明显偏斜。
- 对单个 URL 做抽样，看它在两个协议族下的状态码、响应体长度是否一致。
- 注意同一 URL 是否出现“IPv6 返回 200、IPv4 返回 302 或 403”这类分叉。
从外部探测入手
用支持指定协议族的工具分别访问域名，比较响应头、跳转链与最终落地 URL。只看其中一种协议的结果，很容易得出“站点一切正常”的错误结论。
三类高频不一致
1. DNS 记录不完整
域名只解析出 A 记录，或 AAAA 记录只覆盖部分线路。部分地区解析失败后，蜘蛛会退回 IPv4，但重试过程会消耗时间，表现为回访间隔被拉长。
2. 防火墙与安全组只放行 IPv4
这是最常见的情况。安全策略按 IPv4 网段配置，IPv6 请求直接撞在端口上超时。日志里看不到 403，因为请求根本没到达应用层，只在网络层被丢弃。
3. CDN 与回源的协议处理差异
边缘节点对两种协议的回源策略、缓存键、压缩策略可能不同。结果是同一个 URL 在两条链路上返回不同内容，抓取到的页面版本出现不一致。
一份可执行的核对顺序
- 确认域名解析是否同时存在 A 与 AAAA，并检查各线路的解析结果是否一致。
- 用指定协议族的请求工具分别访问首页与一个深层页面，比较状态码、跳转链、响应头。
- 检查服务器防火墙、云安全组、WAF 是否对 IPv6 放行。
- 核对 CDN 的 IPv6 开关与回源配置，确认缓存键与压缩策略一致。
- 对照抓取日志，确认两条链路的请求比例与状态码分布。
- 修正后持续观察一到两周的回访节奏，而不是当天就下结论。
修正后要观察什么
- 两种协议族的请求占比是否趋于稳定，而不是单边增长。
- 同一 URL 在不同链路上的状态码是否统一。
- 抓取频次是否从集中突发变为更均匀的回访。
- 栏目页与详情页的抓取比例是否回到合理区间。
双栈不是配好就完事的一次性工作，它更像是两条并行的路。任何一条路上有坑，蜘蛛走一次就不会再优先选它。
最后提醒一点：IPv6 相关的问题往往不会在报错里明说。它表现为抓取量的缓慢下滑、回访时间变长、部分 URL 迟迟不被访问。与其盯着总量，不如把两种协议族的日志分开看，差异通常就藏在里面。