為什么中間层會改變蜘蛛的体驗
蜘蛛抓取入口頁时，通常不是直接连到你的源站。DNS 解析、CDN 邊缘节点、WAF、反向代理、负载均衡，任何一层都可能先接手這個請求。這些层的預設配置是為“保護站点、加速用戶訪問”服務的，而蜘蛛的需求和普通用戶並不完全一致：它基本不执行 JavaScript、不儲存登入態、請求频率高且集中、還经常從同一個出口反复請求同一個地址。
于是同一個 URL 可能返回三種结果：给普通用戶的是缓存後的完整頁面，给蜘蛛的是被拦下来的驗證頁或空壳，给回源探测的才是源站原始 HTML。蜘蛛最终看到哪一個，取决于中間层如何判断。
最容易出問题的几個設定
缓存與 Vary 头
如果站点按 User-Agent 返回不同内容，又没有正确設定 Vary，CDN 可能把某個 UA 的响應缓存下来，再發给所有来源。结果是蜘蛛拿到一個几乎為空的頁面，而你在浏览器里看起来一切正常，很难第一時間联想到缓存。
WAF 與频率規則
入口頁數量多、抓取相對集中时，很容易触發“單 IP 高频訪問”這類規則。蜘蛛被拦後不會给你發通知，只在日誌里留下 403 或挑战頁记錄。可以考虑把搜尋引擎官方 IP 段加白，或在驗證层放開常见蜘蛛 UA 的訪問。
回源超时與连接复用
中間层的回源超时設定往往短于蜘蛛的等待阈值。源站稍微慢一点，蜘蛛收到的就是 5xx 或连接超时，而不是它本来還能等到的 200。這類問题在直连測試时通常看不出来。
日誌里的真實来源
接入 CDN 後，源站日誌里记錄的多是节点 IP，看不出蜘蛛的踪影。抓取情况的核對要依赖 X-Forwarded-For 或 CDN 自带的日誌字段，否則很容易把正常抓取誤判成“蜘蛛没来”。
上线前後的检查清單
- 用 3 到 5 個不同的 UA 和来源 IP 請求同一個入口頁，比較返回的 HTML 是否一致。
- 检查响應头中的 Cache-Control、Vary、Age，確認缓存策略與预期相符。
- 查看 WAF 拦截日誌，確認是否有蜘蛛 UA 或官方 IP 段被命中。
- 對比 CDN 日誌與源站日誌，確認抓取次數和狀態碼能對上。
- 測試绕過中間层直连源站的表現，作為排查时的基线參照。
中間层本身不是問题，問题在于你不知道它替蜘蛛做了哪些决定。排查抓取異常时，先把這條鏈路打通，再去調整入口頁的内容和结构，顺序會顺很多。
几点使用建议
- 需要被稳定抓取的入口頁，缓存策略尽量保持简單，避免叠加多层規則。
- 把蜘蛛的訪問路径單獨列成白名單，與普通用戶的規則分開维護，改動时互不影响。
- 定期做一次直连與经過中間层的對比，確認两邊的响應内容和狀態碼一致。
- 變更 CDN、WAF 規則後，观察一段時間的抓取狀態與狀態碼分布，再做下一步調整。