很多人在搭好入口頁之後，第一件事就是去看蜘蛛有没有来。结果訪問日誌里只有零星几條，或者干脆一條都没有，但用浏览器打開又是正常的。這種情况里，相当一部分原因不在入口頁本身，而在它前面挡着的那一层：CDN、WAF 或者云厂商自带的安全防護。
為什么會被拦
這類防護产品的預設策略是「像人的才算正常訪問」。蜘蛛的請求恰好有几個特征容易被判成異常：UA 固定、訪問频率高、路径集中、没有 Referer、不执行 JS、不加载图片和 CSS。對防護系統来说，這和采集脚本的行為高度相似，于是被顺手拦掉。
常见的拦截表現
- 返回 403、405 或 503，源站日誌里根本查不到這條請求；
- 返回一個 JS 挑战頁或驗證碼頁，蜘蛛拿不到實际内容；
- 只放行了部分蜘蛛 IP，另一些直接超时；
- 回源正常，但 CDN 缓存里存的是错誤頁，後續請求全部命中缓存；
- 首字节時間拉得很長，蜘蛛等不到响應就断開。
排查顺序
- 先绕過 CDN，用源站 IP 直接請求一次入口頁，確認源站本身返回正常。
- 分別看 CDN 日誌和源站日誌。CDN 有记錄、源站没有，問题基本就在防護策略上。
- 用蜘蛛 UA 發一次請求，看返回的是内容頁、403 還是挑战頁。只看 UA 不够，要结合請求来源 IP 一起看。
- 检查速率限制規則。單 IP 每秒几次、單 URL 每分钟几次這類阈值，對正常用戶宽松，對蜘蛛往往偏紧。
- 检查是否開了「人机校驗」「JS 挑战」「Cookie 驗證」這類預設開關。
- 確認回源 IP 段是否被源站防火墙放行，有些配置會把 CDN 回源当成異常来源。
配置上的几個做法
白名單不要只寫 UA
UA 可以伪造，所以多數防護产品不會只看 UA，反過来只靠 UA 放行也容易被绕過。更稳的做法是把已知的蜘蛛 IP 段和反向解析一起用上，同时保留基本的频率限制，避免整套策略形同虚设。
频率阈值留出余量
蜘蛛抓取往往是突發式的，可能几分钟内连来几十次，然後安静很久。阈值设成「每秒一次」這種硬限制，很容易在突發时被拦。可以改成按分钟或按小时統計，给一個相對宽松的上限。
留一條备用通道
如果主域名前面挂了嚴格的防護，可以把入口頁放到另一個未接防護的子域或源站上，做交叉驗證。主域抓取異常时，至少能判断是防護問题還是入口頁本身的問题。
需要提醒的是，為了放行蜘蛛而把整套防護規則關掉，並不是個好選擇。防護的目的是過滤異常流量，規則全關之後，入口頁本身也更容易被其他脚本盯上。
两個容易忽略的点
- 缓存污染：错誤頁一旦被 CDN 缓存，蜘蛛後續再来命中的還是缓存。清理缓存並調整缓存規則，通常比反复改入口頁更有效。
- 換 IP 後没同步：蜘蛛池換了出口或回源 IP，防護白名單没跟着更新，表現就是「昨天還好好的，今天全没了」。
入口頁抓不到，按「源站 → CDN 日誌 → 防護策略 → 蜘蛛侧」的顺序倒着查一遍，通常比直接去改入口頁模板更快定位。日誌和實际返回是唯一可靠的依據，別凭感觉判断。