入口页能不能被抓，很多时候不取决于内容质量，而是取决于请求有没有真正到达源站。内容写得再规整，中间层一个规则命中，蜘蛛看到的就是 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 并跟到下一层，再逐步扩量。