為什么入口頁容易被自家防護挡在门外
蜘蛛池的入口頁通常是公開可訪問的聚合頁：連結密集、參數多、来自同一批 IP 段的請求集中且規律。這些特征恰好和许多 WAF、限流、反爬規則想拦的“異常訪問”高度重合。于是後台看不到任何报错，服務器也没崩，只是在日誌里安静地多出一堆 403、429，蜘蛛的到訪记錄停在某一天。
這不一定是防護配置“错了”。多數預設規則是围绕真實攻击行為设計的，並没有把搜尋引擎蜘蛛的抓取习惯單獨区分出来。
几種常见的誤拦配置
1. 频率阈值设得過低
- 單 IP 每分钟請求次數阈值
- 同一 UA 的並發连接數上限
- 單個 URL 短時間内被重复請求的次數
蜘蛛在發現新入口頁时往往會在一個時間段内集中抓取，尤其是入口頁刚被大量連結指向时。把阈值定在“每分钟 20 次”這類量級，很容易被触發。
2. UA 與請求特征匹配
部分規則库會把包含 python、curl、Java、Go-http-client 等特征串的 UA 直接拒绝；另一些則反過来，只放行带完整浏览器特征的請求。蜘蛛 UA 中带說明連結或版本号片段的情况並不少见，也可能被当成掃描器處理。
3. JS 挑战與驗證碼
一些 CDN 的“浏览器完整性检查”要求客戶端执行脚本才能拿到頁面。蜘蛛不會执行這類挑战，结果通常是 403、空白响應或一個不含正文的壳頁面。
4. Referer 與防盗鏈規則
资源防盗鏈影响不大，真正麻烦的是整頁級的 Referer 白名單。蜘蛛請求通常不带 Referer，一旦規則要求“必须来自本站”，入口頁就會被整体拦下。
5. 地域與 IP 信誉库
部分規則會拦截海外 IP 段，或统一拦截被标记為“資料中心”的 IP。而搜尋引擎蜘蛛的出口 IP 大多属于資料中心，這條規則容易造成誤伤。
怎么確認是不是被拦了
- 看日誌里的狀態碼分布：403、429、503 是否集中在蜘蛛 UA 上；
- 用官方工具驗證：Search Console 的網址检查、Bing 的抓取測試；
- 用命令行带真實蜘蛛 UA 請求一次，观察狀態碼和响應头；
- 換不同 UA 請求同一 URL，對比结果，判断是 UA 規則還是频率規則；
- 留意响應時間：限流往往先表現為 TTFB 升高，之後才出現 429。
放行时的几個注意点
只靠 UA 白名單並不安全，UA 可以伪造。更稳妥的做法是：對声称是蜘蛛的請求做反向 DNS 校驗，或直接使用搜尋引擎官方公布的 IP 段列表做白名單，同时保留原始訪問日誌，便于回溯。
- 把入口頁從“强防護”路径中拆出来，與登入、後台、接口等路径分開配置；
- 频率阈值按路径設定，入口頁可以放宽，寫操作接口保持嚴格；
- 触發限流时返回 429 並带上 Retry-After，避免蜘蛛把站点判断為長期不稳定；
- 不要用驗證碼拦所有訪客，蜘蛛拿不到頁面，入口頁等于不存在；
- 規則改動後先观察一到两周的抓取日誌，再决定是否繼續收紧或放宽。
放行不等于放弃防護。關键是区分“人在看什么頁面”和“蜘蛛在取什么頁面”，把規則按路径和訪問角色分開，而不是全站一刀切。
一份可以照着走的排查清單
- 確認入口頁可被未登入、無 Cookie 的請求正常訪問；
- 检查是否有全站級 JS 挑战或人机校驗；
- 核對限流阈值與入口頁的實际請求特征是否匹配；
- 检查是否有基于 Referer、地域、IP 類型的拦截規則；
- 變更規則後持續观察狀態碼分布與抓取日誌，而不是改完就算。
WAF 與限流是入口頁比較容易踩的坑，因為它不报错、不崩溃，只是把蜘蛛挡在门外。定期核對响應狀態和抓取日誌，比事後排查省事得多。另外也要有心理预期：放行之後抓取表現未必立刻改變，URL 發現本身需要時間。