蜘蛛池搭好之後，最常见的困惑是「入口頁明明能打開，蜘蛛就是不来」。很多时候問题不在蜘蛛池本身，而在它前面的那一层：CDN、WAF、云防火墙、负载均衡。這些组件預設把「看起来像自動化訪問」的請求当成威胁，而搜尋蜘蛛恰好就是自動化訪問。
先分清三類不同的拦截
規則拦截
WAF 的預設規則库里，大量條目针對的是掃描器、爬虫框架和異常請求特征。入口頁如果带有比較規整的參數、模板化的正文，很容易命中規則，直接返回 403。這種情况在日誌里表現為蜘蛛請求根本没到源站。
速率限制
蜘蛛抓取往往在短時間内集中訪問，容易触發按 IP 或按 UA 的 QPS 限速。返回碼通常是 429，也可能是 503。表面上看蜘蛛「来過」，但它什么内容都没拿到，抓取日誌里只會留下一片失敗记錄。
回源與缓存問题
開了 CDN 之後，入口頁可能被缓存成舊版本，或者回源时因為超时、源站證书問题拿到 5xx。有些 CDN 預設開啟的 JS 挑战、人机校驗，也會让蜘蛛拿不到真正的頁面内容。
怎么確認蜘蛛是不是真的被拦了
- 直连源站測試：绕開 CDN，直接用源站 IP 訪問入口頁，看返回是否正常。
- 指定 UA 复現：用 curl 带百度、Google、必應的 UA 請求一次，记錄返回碼和响應体長度。
- 對比两层日誌：把 CDN 或 WAF 的拦截记錄與源站訪問日誌對照，看請求在哪一层消失了。
- 看返回碼分布：如果蜘蛛的訪問集中在 403、429、503，基本可以判断不是抓取意愿問题。
放行策略怎么寫
原則是「精确放行」，不是「全站放行」。
- 官方 IP 段優先。百度、Google、必應都公布了自己的抓取 IP 段，按 IP 放行比按 UA 放行可靠得多。
- UA 白名單做辅助。UA 可以伪造，單獨依赖它等于给所有人開门。
- 反向 DNS 校驗。Google 官方建议對声称是 Googlebot 的請求做反向解析驗證，其他搜尋引擎也有類似机制。
- 给爬虫單獨设速率阈值。把蜘蛛的 QPS 上限设得比普通用戶宽松一些，但不要取消上限。
- 入口頁不要被 CDN 長期缓存。如果入口頁需要更新，缓存 TTL 要设短，或者让爬虫請求直接回源。
几個容易踩的坑
- 為了省事直接關掉 WAF。短期抓取是通了，安全風險會一直留在那里。
- 只按 UA 放行，等于没有放行。
- 忽略 CDN 的人机校驗。頁面返回 200，但内容是驗證頁，蜘蛛一样拿不到東西。
- 把 429 当成成功。日誌里看着有訪問，實际抓取量為零。
- 換服務器或換 CDN 之後忘了同步放行規則，抓取量下降却查不到原因。
一個可执行的排查顺序
- 直连源站，確認入口頁本身返回 200。
- 带蜘蛛 UA 走完整鏈路請求一次，记錄返回碼和响應時間。
- 查 WAF 與 CDN 的拦截、限速记錄，定位是規則命中還是频率命中。
- 放行官方 IP 段，观察 24 到 72 小时内的抓取日誌變化。
- 如果仍然没有改善，再回头检查入口頁的連結结构、robots 與站点地图。
把網絡层的問题先排除掉，再看蜘蛛池本身，能省下大量無效調整。
小结
抓取效果是一條鏈路共同决定的：DNS、CDN、WAF、源站、入口頁、連結，任何一环挡住蜘蛛，後面的優化都白費。建议把放行規則和服務器配置一起纳入日常巡检，換机器、換 CDN、改規則之後都重新驗證一次，並把驗證结果记進台帳，方便前後對比。