入口頁能不能被抓，很多时候不取决于内容质量，而是取决于請求有没有真正到達源站。内容寫得再規整，中間层一個規則命中，蜘蛛看到的就是 403、429，或者一直轉圈的 503。
拦截通常發生在哪一层
一次請求的鏈路大致是：DNS 解析 → CDN 邊缘节点 → WAF → 源站 → 應用层限流。任何一层判定為可疑，蜘蛛就拿不到頁面。麻烦的是，這几层返回的狀態碼往往長得很像，從外部看不出到底卡在哪。
三類最常见的拦截
CDN 預設的爬虫策略
不少 CDN 預設開啟爬虫挑战或 JS 挑战，只放行知名搜尋引擎的 UA。蜘蛛池的入口頁常被归入異常流量，尤其是同一 IP 段在短時間内請求大量不同域名时，触發概率會明顯上升。
WAF 的規則命中
WAF 按特征匹配，路径带大量參數、URL 長度異常、缺少 Referer、UA 與已知爬虫不符，都可能被拦。入口頁如果是批量生成的模板，URL 结构往往非常規整，反而容易整段命中同一條規則。
源站與前置限速
單 IP 並發數、單位時間請求數、连接复用方式，都可能触發 Nginx 的 limit_req，或者云厂商的基础防護。這類拦截的特点是：不是一直拒绝，而是断断續續，看起来像抓取不稳定。
怎么判断是誤伤還是真被拒绝
- 看狀態碼分布。大量 403 或 429 集中在某個時間段，並且同一目标站也同时掉，多半問题出在中間层。
- 驗證来源。正向解析 UA 声称的域名，再反查 rDNS，两者對不上，基本不是真蜘蛛。
- 對照請求频率。真蜘蛛通常有节制，如果被拦的請求频率遠超正常水平，先怀疑是不是別的東西在打。
- 換路径測試。在同一個 CDN 與 WAF 下放一個干净的静態頁，看能不能被正常抓取，用来排除内容层的問题。
配置上可以做的事
- 给已驗證的搜尋引擎 IP 段做白名單，而不是只按 UA 字符串放行。
- 關掉入口頁域名的爬虫挑战與 JS 挑战，這類頁面蜘蛛通常不會去执行脚本。
- 限速規則给搜尋引擎段單獨放行，避免和普通訪客共用一個計數桶。
- 保留一份原始訪問日誌，字段至少覆盖時間、IP、UA、路径、狀態碼、响應時間。
白名單要按官方公布的 IP 段维護，並且定期核對。只按 UA 放行，等于把所有伪装成爬虫的流量一並請進门。
两個常见誤区
一是把 403 直接理解成蜘蛛不喜欢這個站，于是不停換域名、換入口頁，真正的問题其實卡在中間层。二是為了不誤伤，干脆全站放行，结果入口頁被执行大量無效請求，源站压力反而更大，真實蜘蛛的抓取也受影响。
一套可复用的排查顺序
- 先看源站日誌，確認請求有没有到達。
- 若没到達，逐层回退：先临时關掉 WAF 規則观察，再检查 CDN 的爬虫策略。
- 若到達但狀態碼異常，重点看應用层限流與路径規則。
- 恢复之後分批放量，观察狀態碼與後續跟鏈情况的變化。
CDN 要不要挂
入口頁本身内容轻量，多數情况下並不依赖 CDN 缓存。如果确實挂了，至少要確認缓存不會把 403 或 429 存下来長期返回给蜘蛛，否則一次誤伤會變成持續誤伤。
更稳的做法是小范围驗證：先拿几個入口頁跑通鏈路，確認蜘蛛能拿到 200 並跟到下一层，再逐步扩量。