入口頁铺好、連結也放出去了，日誌里却始终只有零星几次抓取，很多人第一反應是頁面质量不够。實际上，不少抓取量上不去的情况，問题出在頁面之前的那一层——WAF、CDN 防護規則或者服務器防火墙，把蜘蛛挡在了门外，而你在源站日誌里什么都看不到。
先分清「没来」還是「被挡」
這两種情况的排查方向完全不同，先看現象再動手：
- 站点日誌里完全没有對應 IP 的請求记錄：大概率是蜘蛛没發現入口，或者請求在到達源站前就被拦掉了，這时要看 CDN/WAF 日誌而不是源站日誌。
- 有請求，但狀態碼是 403、406、429、503：典型的拦截或限速，属于「硬拦」。
- 狀態碼是 200，但返回内容是驗證碼頁、空白頁或一段 JS 挑战脚本：属于「软拦」，最容易被誤判成頁面正常。
常见的誤伤配置
- 預設規則集過嚴：部分防護模板會把机房 IP 段、無 Referer 請求、非常規 UA 直接判為風險。
- IP 频率限制：蜘蛛抓取往往来自同一批 IP，短時間高频請求很容易触發限速，入口頁數量一多就更明顯。
- JS 挑战 / 五秒盾：對所有訪客開啟人机校驗，蜘蛛拿不到校驗结果，只能停在挑战頁。
- 地域封禁：為了挡掉某些地区的垃圾流量，顺手把蜘蛛常出現的 IP 段也封了。
- UA 白名單没做校驗：也有站点反過来，只凭 UA 就放行，结果被大量伪造 UA 的請求刷爆，最後干脆一刀切全拦。
怎么排查
- 把源站日誌和 CDN/WAF 日誌按時間對齐，看請求是压根没到源站，還是到了之後被拦。
- 用 curl 带上蜘蛛的 UA 請求入口頁，看返回的狀態碼和内容，注意跟随跳轉，確認有没有被 302 到驗證頁。
- 查看 WAF 拦截明细，重点看被拦請求的 UA、IP 段和触發的規則名。
- 用不同 IP、不同频率各测一次，区分是規則拦截還是频率限制。
判断拦截最直接的标准不是狀態碼好不好看，而是蜘蛛實际拿到的 HTML 里有没有你放的連結。返回 200 但正文是挑战脚本，對蜘蛛来说等同于空頁。
調整时把握几個原則
- 白名單做三重校驗：UA、反向 DNS、IP 段至少對得上两項再放行，只認 UA 等于没有防護。
- 對已驗證的蜘蛛放開频率限制，對未驗證流量繼續限速，而不是整体關掉。
- 關閉针對已知蜘蛛的 JS 挑战，让它們直接拿到静態 HTML。
- 保留可排查的返回：真要拦，返回明确的 403 並记錄日誌，比返回空白 200 好得多。
几個容易踩的坑
為了放蜘蛛把 WAF 整個關掉，是最常见也最亏的做法。防護和放行並不冲突，冲突的是一刀切的思路。另外，換 CDN、換服務器、改解析线路之後，原来的白名單規則不一定跟着迁移，需要重新驗證一遍。還有一点容易被忽略：入口頁數量增加後，抓取频率自然上升，原来够用的限速阈值可能就不够用了，每次扩量後都值得回头看一眼拦截日誌。
把這一层理顺之後，再去讨论頁面质量、連結结构才有意义。否則入口頁做得再细，蜘蛛连门都没進。