抓取量不動，先別急着怪池子
蜘蛛池跑了一段時間，日誌里看不到几條爬虫记錄，很多人的第一反應是入口頁质量不行、連結不够、池子被识別了。但在排查顺序上，有一個更靠前、也更容易被忽略的环节：入口頁所在的服務器上是不是開着 WAF、CC 防護或频率限制。
這類防護是按“人的行為”设計的，而爬虫的訪問特征恰好和攻击流量高度重合，誤伤几乎是必然的，只是程度不同。
WAF 和限流為什么容易誤伤爬虫
防護系統判断一個請求是否可疑，通常看這几個维度：同一 IP 的請求频率、請求头是否完整、有没有 Cookie、UA 是否在已知列表里、有没有执行頁面脚本。爬虫在這几項上几乎全部踩雷——不带 Cookie、不带 Referer、UA 陌生、單 IP 高频、不执行 JS。
另一個因素是 IP 属性。蜘蛛池的入口頁大多部署在云服務器或机房 IP 上，而机房 IP 段本身就是防護規則的重点關照對象。有些策略干脆整段拉黑，池子里所有入口頁一起失效。
常见的四類誤杀来源
- UA 名單寫死。只放行自己認识的几個 UA，UA 更新或出現新爬虫时直接返回 403。
- 频率阈值過低。例如單 IP 每分钟超過 30 次就临时封禁。對只有一個出口 IP 的池子来说，這個门槛很容易被正常抓取触碰到。
- JS 挑战與人机驗證。返回一段需要浏览器执行脚本才能通過的頁面，爬虫不會执行，拿到的就是一個空壳，等于什么都没抓到。
- 机房 IP 段整段封禁。不区分具体請求，按網段直接拒绝，池子整体不可達。
怎么確認是誤杀，而不是別的問题
- 在服務器本地用 curl 請求入口頁，確認返回狀態碼是不是 200，這是排除程序本身错誤的第一步。
- 換一個不在机房網段的出口，再請求同一個 URL，對比两次结果。如果本地通、外部不通，方向基本就明确了。
- 翻 WAF 或防護面板的拦截日誌，看有没有對應時間点的记錄。有记錄，誤杀基本可以定性。
- 用站長平台提供的抓取诊断類工具測試，观察返回内容是不是“拒绝訪問”“驗證中”之類的頁面。
放行思路：按驗證结果放，而不是按 UA 放
只認 UA 是最省事也最不可靠的做法，UA 本身可以随便伪造。更稳妥的方式是做双重校驗：先對訪問来源 IP 做反向 DNS 解析，解析结果落在官方域名下，再回查這個 IP 是否属于官方公布的 IP 段，两條同时满足才放行。這样既能放進真爬虫，也不會给伪造 UA 的請求開口子。
如果服務器环境不方便做這套逻辑，一個退而求其次的配置是把入口頁單獨放到一個域名或子域上，只保留最基础的防護，不啟用 JS 挑战和嚴格频率限制。池子和主站分開部署，本身也能减少互相牵连。
限流參數怎么设才合理
- 單 IP 每分钟請求數放宽到明顯高于正常抓取峰值的水平，參考值可以放到 120～300 次，具体看入口頁數量和單 IP 承载的並發量。
- 封禁时長设短一点，几分钟即可。誤封之後能自愈，比一次性封几小时要安全得多。
- 返回 429 时带上 Retry-After，给爬虫一個明确的等待時間，好過直接断開连接。
- 入口頁尽量做成静態文件。動態請求经過的規則鏈路更長，被誤判命中的概率也更高。
几個容易忽略的细节
一是 CDN 的防護策略和源站策略可能不一致，源站放行了、邊缘节点拦了，表現是一样的“抓不到”。排查时两端都要看。二是改了規則之後不要立刻下结论，抓取频次的恢复通常需要几天，短期内資料没有變化不代表改動無效。三是在站内留一份目前生效的防護規則记錄，包括放行名單和阈值，下次調整时能省很多回溯成本。
WAF 和蜘蛛池本质上在抢同一份资源：前者要挡住異常請求，後者要把請求放進来。两者之間需要一個明确的邊界，而不是谁迁就谁。
使用建议
- 池子上线前，先用两三個不同出口 IP 测一遍入口頁的可達性，把防護层的問题在上线前解决掉。
- 把入口頁域名和主站域名分開，防護策略互不影响。
- 定期检查拦截日誌里的 IP 段，發現誤封就及时加白，不要等到抓取量掉下去才回头查。
- 不要為了放行把防護全部關掉，按驗證结果放行比一刀切關閉更可持續。
抓取量上不去的原因往往不止一個，但防護层是排查成本最低、也最容易一次性解决的一环。把這一层理顺之後，再去調入口頁内容、連結结构和抓取频率，判断才不會被噪声干扰。