很多站点在完成 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 迟迟不被訪問。與其盯着總量，不如把两種协议族的日誌分開看，差异通常就藏在里面。