做蜘蛛池的人常遇到一種情况：前一阵抓取還算稳定，某天開始抓取量突然往下掉，登入服務器翻訪問日誌，却發現入口頁的請求數並没有明顯異常——既没有飙升的 5xx，也看不到大量陌生 UA。這種“抓取量掉了，日誌却很干净”的現象，很多时候問题不在池子本身，而在請求到達服務器之前就被拦掉了。
請求可能在到服務器之前就結束了
從蜘蛛發出請求到你的入口頁返回内容，中間通常要经過好几层：CDN 邊缘节点、云厂商的 DDoS 清洗、WAF、负载均衡，最後才是 Nginx 或應用本身。任何一层判定這個請求“不像正常用戶”，都可能直接返回 403、429 或一個 JS 挑战頁。這些响應不會寫進你的站点訪問日誌，所以從日誌上看就是“蜘蛛没来過”。
常见的拦截位置
- CDN 的 Bot 管理：不少 CDN 預設開啟爬虫识別，會把来自机房 IP 段的請求降權或直接挑战。
- WAF 規則：入口頁如果 URL 里带大量參數、目錄结构異常整齐，容易被規則集判定為掃描行為。
- 應用层限速：Nginx 的 limit_req、limit_conn 或框架自带的频率限制，阈值设得偏紧时會誤伤蜘蛛的连續抓取。
- 机房防火墙：部分机房對同一 IP 的高频請求做清洗，表現是間歇性超时而非明确拒绝。
怎么判断是不是被拦了
直接在服務器上模拟一次請求，往往比看日誌更快定位：
- 用與蜘蛛相近的 UA 請求入口頁，观察返回碼和响應体。如果拿到的是驗證頁、挑战跳轉或者 403，基本可以確認。
- 換几個不同 UA、不同来源 IP 再請求一次。如果只有某一類請求被拒，說明是規則匹配，而不是全站故障。
- 去 CDN / WAF 控制台看安全日誌和拦截統計，這里通常能看到被拦下的請求明细，包括命中哪條規則。
- 確認拦截来源後再動手調整，避免把正常防護也一起關掉。
處理时的几個原則
- 優先加白名單，而不是關防護。把已知的蜘蛛 IP 段或驗證方式加入放行列表，比全局關閉 Bot 管理安全得多。
- 限速阈值留出余量。蜘蛛抓取本身带有突發性，阈值按平时均值設定很容易被打满。
- 保留降級路径。即使某個防護层拦了，也让入口頁本身在主站上仍可訪問，便于對比排查。
- 监控要覆盖“没到服務器”的請求。只看站点日誌會漏掉這一整段，建议同时參考 CDN 侧的請求量與狀態碼分布。
两個容易踩的坑
第一個坑是把“日誌空白”直接等同于“蜘蛛不来了”，于是去改内容、換連結、調结构，折腾一圈其實和抓取無關。第二個坑是發現被拦後立刻把 CDN 的 Bot 管理、WAF 規則全部關掉，短期抓取恢复了，但站点同时暴露在掃描和恶意請求里，後續更麻烦。
拦截排查的顺序建议從外到内：先看 CDN / WAF 的拦截日誌，再看负载均衡和 Nginx，最後才是應用本身。大部分“抓取量下滑但日誌正常”的問题，在第一层就能找到答案。
需要說明的是，解决拦截只是让請求能正常到達，抓取量是否回升，還要看入口頁本身的结构與内容。防護配置改完以後，最好观察一段時間的抓取分布和回訪情况，再判断是否達到预期。