为什么入口页容易被自家防护挡在门外
蜘蛛池的入口页通常是公开可访问的聚合页：链接密集、参数多、来自同一批 IP 段的请求集中且规律。这些特征恰好和许多 WAF、限流、反爬规则想拦的“异常访问”高度重合。于是后台看不到任何报错，服务器也没崩，只是在日志里安静地多出一堆 403、429，蜘蛛的到访记录停在某一天。
这不一定是防护配置“错了”。多数默认规则是围绕真实攻击行为设计的，并没有把搜索引擎蜘蛛的抓取习惯单独区分出来。
几种常见的误拦配置
1. 频率阈值设得过低
- 单 IP 每分钟请求次数阈值
- 同一 UA 的并发连接数上限
- 单个 URL 短时间内被重复请求的次数
蜘蛛在发现新入口页时往往会在一个时间段内集中抓取，尤其是入口页刚被大量链接指向时。把阈值定在“每分钟 20 次”这类量级，很容易被触发。
2. UA 与请求特征匹配
部分规则库会把包含 python、curl、Java、Go-http-client 等特征串的 UA 直接拒绝；另一些则反过来，只放行带完整浏览器特征的请求。蜘蛛 UA 中带说明链接或版本号片段的情况并不少见，也可能被当成扫描器处理。
3. JS 挑战与验证码
一些 CDN 的“浏览器完整性检查”要求客户端执行脚本才能拿到页面。蜘蛛不会执行这类挑战，结果通常是 403、空白响应或一个不含正文的壳页面。
4. Referer 与防盗链规则
资源防盗链影响不大，真正麻烦的是整页级的 Referer 白名单。蜘蛛请求通常不带 Referer，一旦规则要求“必须来自本站”，入口页就会被整体拦下。
5. 地域与 IP 信誉库
部分规则会拦截海外 IP 段，或统一拦截被标记为“数据中心”的 IP。而搜索引擎蜘蛛的出口 IP 大多属于数据中心，这条规则容易造成误伤。
怎么确认是不是被拦了
- 看日志里的状态码分布：403、429、503 是否集中在蜘蛛 UA 上；
- 用官方工具验证：Search Console 的网址检查、Bing 的抓取测试；
- 用命令行带真实蜘蛛 UA 请求一次，观察状态码和响应头；
- 换不同 UA 请求同一 URL，对比结果，判断是 UA 规则还是频率规则；
- 留意响应时间：限流往往先表现为 TTFB 升高，之后才出现 429。
放行时的几个注意点
只靠 UA 白名单并不安全，UA 可以伪造。更稳妥的做法是：对声称是蜘蛛的请求做反向 DNS 校验，或直接使用搜索引擎官方公布的 IP 段列表做白名单，同时保留原始访问日志，便于回溯。
- 把入口页从“强防护”路径中拆出来，与登录、后台、接口等路径分开配置；
- 频率阈值按路径设置，入口页可以放宽，写操作接口保持严格；
- 触发限流时返回 429 并带上 Retry-After，避免蜘蛛把站点判断为长期不稳定；
- 不要用验证码拦所有访客，蜘蛛拿不到页面，入口页等于不存在；
- 规则改动后先观察一到两周的抓取日志，再决定是否继续收紧或放宽。
放行不等于放弃防护。关键是区分“人在看什么页面”和“蜘蛛在取什么页面”，把规则按路径和访问角色分开，而不是全站一刀切。
一份可以照着走的排查清单
- 确认入口页可被未登录、无 Cookie 的请求正常访问；
- 检查是否有全站级 JS 挑战或人机校验；
- 核对限流阈值与入口页的实际请求特征是否匹配；
- 检查是否有基于 Referer、地域、IP 类型的拦截规则；
- 变更规则后持续观察状态码分布与抓取日志，而不是改完就算。
WAF 与限流是入口页比较容易踩的坑，因为它不报错、不崩溃，只是把蜘蛛挡在门外。定期核对响应状态和抓取日志，比事后排查省事得多。另外也要有心理预期：放行之后抓取表现未必立刻改变，URL 发现本身需要时间。