入口頁铺好了，連結也放出去了，但日誌里長期只有零星抓取，甚至连一條蜘蛛记錄都没有。這时很多人會先怀疑連結质量，却忽略了一個更靠前的环节：請求可能在 CDN 或 WAF 层就被拦掉了，根本没走到源站。
被拦截时常见的几種表現
- 源站日誌完全没有蜘蛛记錄，但 CDN 日誌里有大量 403、405、429；
- 返回 200，内容却是一段人机驗證頁或跳轉脚本，属于“软拦截”；
- 只抓到入口頁，站内連結一個没抓，因為静態资源或子路径被規則挡住；
- 白天正常、夜間掉零，通常是频率策略在起作用。
最容易誤伤蜘蛛的几類規則
频率與並發阈值
預設的“單 IP 每分钟 N 次”往往按普通訪客设定，蜘蛛短時間集中抓取时會被判為異常。限速阈值要留出余量；确實超限时優先返回 429 並带上 Retry-After，而不是直接封 IP。
IP 段與地区封禁
為了挡境外流量而整体封禁某些地区，或把 IDC 机房段一律拉黑，很容易连搜尋引擎的抓取段一起封掉。搜尋引擎的 IP 段會更新，白名單需要定期核對。
校驗方式過于單一
只按 User-Agent 放行，UA 是任何人都能伪造的；反過来，只做反向解析校驗，解析失敗就拒绝，也會誤伤。常见做法是把官方 IP 段、反向解析、正向解析回查三者交叉驗證。
一刀切的訪問策略
诸如禁止空 Referer、禁止無 Cookie 訪問、强制 JS 挑战之類的規則，對爬虫基本等于關站。若必须開啟人机驗證，應给已確認的蜘蛛單獨放行。
一次比較完整的排查顺序
- 先看 CDN 與 WAF 的訪問日誌，確認請求是否到達這一层；
- 比對搜尋引擎官方公布的 IP 段，看被拦的是不是這些地址；
- 查看被拦請求的响應碼、响應体和响應時間，区分硬拦截與软拦截；
- 再往下查源站：Nginx 配置、iptables、fail2ban 以及應用层的防爬插件；
- 放行後连續观察几天抓取量與狀態碼分布，確認不是間歇性触發。
提示：排查时不要只测“能不能訪問”，要看清“被拦的到底是哪一层”。同一個 403，可能来自 CDN 邊缘节点，也可能来自源站的應用逻辑，處理方式完全不同。
几條實用建议
- 把白名單規則放在所有限速和挑战規則之前，顺序很重要；
- 保留 403、429、5xx 的完整日誌，出問题时才有回溯依據；
- 規則變更後做一次模拟抓取驗證，別等日誌掉零才發現；
- 入口頁和目标頁用同一套放行策略，避免只放行了入口。
WAF 和 CDN 本身不是問题，問题是規則没有给正常抓取留出通道。把這一层理顺，往往比繼續增加入口頁更有效。