给服務器加防護和限速，本来是為了挡住恶意抓取和突發流量；但如果阈值、規則、驗證方式配得含糊，最先被挡住的往往是搜尋蜘蛛和正常用戶。這類問题不會在頁面上直接暴露，只會体現在抓取量下滑、收錄變慢、日誌里一串 403 和 429。定期做一次爬虫放行自查，比事後猜原因要省事得多。

先分清三類拦截

排查时先把拦截按来源分開，不然容易在一個方向上反复調參：

• 網絡层：CDN、云防護、防火墙按 IP 或 IP 段封禁，常见于机房段被整段拉黑。
• 應用层：Nginx、WAF 的速率限制，按每秒請求數或並發连接數触發，返回 429 或 503。
• 頁面层：JS 挑战、驗證碼、人机校驗，蜘蛛拿不到完整 HTML，抓到的是空壳頁。

常见誤伤场景

• 限速按“單 IP”設定，而搜尋蜘蛛常從少量 IP 高频訪問，直接被判定為異常。
• UA 黑名單里寫了包含“bot”的關鍵詞，把正規蜘蛛一起匹配進去。
• 為了挡采集，把整段 IDC 机房 IP 封掉，结果搜尋蜘蛛的出口也在其中。
• 全站開啟 JS 挑战，蜘蛛拿到的是等待跳轉的中間頁。
• 被拦时預設返回 403，而不是 429，让蜘蛛誤判為永久拒绝。

自查怎么做

1. 看日誌里的狀態碼分布

把最近 7 天的訪問日誌按 UA 和狀態碼分组，重点看蜘蛛 UA 對應的 403、429、503 占比。如果某一时段集中出現，對照同一時間的限速規則改動记錄，基本能定位到是哪條策略。

2. 確認蜘蛛身份驗證方式

不要只看 UA 字符串。正規蜘蛛提供了反向解析再加正向確認的驗證办法，可以把驗證通過的請求放進白名單，跳過通用限速。白名單要按需维護，而不是長期全放開。

3. 检查限速的维度與阈值

• 限速按 IP、按 UA、按接口分別設定，避免一條規則覆盖全站。
• 给抓取類請求單獨留一档更宽松的額度，静態资源可以比動態接口更松。
• 触發後優先返回 429 並带上重试時間，而不是直接 403。
• 對短时突發做排队或降速，而不是一次性拒绝。

4. 確認頁面层没有被挑战拦下

用命令行工具直接請求一個普通内容頁，看返回的 HTML 里有没有正文内容。如果只有一段脚本和跳轉，說明人机校驗對抓取請求也生效了，需要给已確認的蜘蛛放行。

自建抓取程序要避開的行為

如果你自己也在跑蜘蛛池或采集任務，同样要注意別把目标站点逼到必须加嚴防護：

• 控制單站点並發，別用几十個线程同时打同一個域名。
• 遵守對方的 robots 與抓取間隔，抓到 429 就退避，不要立刻重试。
• 标注可识別的 UA，並留下可联系的方式，出問题时對方能直接沟通而不是直接封段。
• 区分“需要频繁回訪的入口頁”和“只需偶尔复查的存量頁”，把請求量花在有變化的地方。

改完之後怎么確認

調整規則後，別只看当天的抓取量，建议连續观察 3 到 7 天：

1. 蜘蛛 UA 的 2xx 占比是否回升。
2. 日誌里 429 與 403 是否降到可解释的范围。
3. 重点栏目和新增内容是否重新出現抓取记錄。
4. 是否有正常用戶被誤伤的反馈。

防護策略的目标是区分“谁在抓”和“怎么抓”，而不是一律拒绝。把驗證做在前面，把白名單做窄做准，比事後從日誌里刨原因要轻松得多。

最後提醒一句：限速和拦截規則属于會随业務變化的配置，建议把每次改動记在同一個地方，包括改動時間、影响范围和回滚方式。出現抓取異常时，第一件事是對照改動记錄，而不是先去改内容。