蜘蛛池入口頁搭好之後，有时會遇到一個让人摸不着头脑的情况：日誌里能看到蜘蛛的 UA，但返回的狀態碼是 403、429、503，或者被跳到一個驗證頁面。入口頁本身没問题，内容也正常，問题往往出在入口頁和蜘蛛之間的某一层把請求拦下了。這類問题不排查清楚，後面做再多内容調整都很难看到效果。
先確認是不是被拦：看响應碼和响應体
不要只看到訪問日誌里有蜘蛛记錄就認為抓取正常。真正要看的是响應狀態碼和响應体。用 curl 带蜘蛛 UA 請求入口頁，再看返回内容：
- 返回 403、406、429、503：大概率被規則拦下。
- 返回 200，但内容是 JS 挑战頁或驗證頁：被 WAF 的人机校驗挡住。
- 返回 301 或 302 到無關域名：可能被 CDN 或安全策略重定向。
- 响應头里出現 cf-ray、x-waf 之類字段：說明請求经過了安全层。
只看訪問日誌里的 200 不够，有些安全层會先返回 200 再让頁面 JS 跳轉，日誌里看不出異常。
拦截可能發生在哪几层
蜘蛛請求進到源站之前，通常要经過好几层，任何一层都可能拦：
- CDN 與云 WAF：最常见的拦截点，規則包括 UA 黑名單、频率限制、人机校驗。
- 云厂商安全组或防火墙：只放行了常用端口，或者對境外 IP 做了限制。
- Nginx 限速模块：limit_req、limit_conn 配置過嚴，蜘蛛短時間多次請求就被挡。
- iptables 與 fail2ban：把高频訪問的 IP 临时封禁，蜘蛛 IP 也可能中招。
- 應用层逻辑：代碼里對 UA、Referer、Cookie 做了判断，直接返回空頁或 403。
排查顺序：從外到内逐层排除
- 用 curl 從本机請求入口頁，记錄狀態碼和响應体大小。
- 換一個干净的出口 IP 再請求一次，對比结果，判断是否 IP 被限。
- 检查 CDN 或 WAF 後台的拦截日誌，看是否有對應時間点的拦截记錄。
- 在源站直接绑定 hosts 請求，绕過 CDN，確認源站本身是否正常。
- 查看 Nginx 和應用日誌，確認請求有没有到達源站。
- 如果源站正常、CDN 有拦截记錄，問题就在安全层。
這個顺序的好處是從外到内，先排除最外层的可能，避免一上来就改源站配置。
放行策略：驗證過的蜘蛛再放
確認是安全层拦截後，不要直接把所有带蜘蛛 UA 的請求全放行，UA 是可以伪造的。更稳妥的做法是：
- 先做反向解析驗證，確認 IP 确實属于對應搜尋引擎，再把 IP 段加入白名單。
- 按路径放行：入口頁走相對宽松的策略，後台、登入、接口等路径保持嚴格。
- 調整限速阈值：给蜘蛛單獨设一個宽松的限速桶，不要和普通訪客共用一個阈值。
- 關閉针對入口頁的人机校驗，避免蜘蛛拿到挑战頁而不是内容。
- 如果 CDN 提供搜尋引擎白名單功能，優先用官方名單，再叠加自己的驗證。
放行的核心思路是：按已驗證的 IP 和路径放，而不是按 UA 字符串放。UA 只是一层容易伪造的标识。
监控與止损
放行之後要留一個观察窗口。建议每天看一眼安全层的拦截統計，重点看入口頁路径下 403、429 的比例有没有反彈。如果比例突然升高，先回到排查顺序的前几步，確認是規則誤伤還是真的有人在刷。频繁改動規則容易把問题掩盖掉，记錄每次調整的時間和结果，後續排查會轻松很多。
几個常见誤区
- 只看 UA 就放行：伪造 UA 的請求會一起進来，等于给安全层開了口子。
- 把限速關掉：短期看蜘蛛能抓了，但入口頁也更容易被刷，带宽和成本會上去。
- 只查源站日誌：被 CDN 拦下的請求根本到不了源站，日誌里看不到。
- 一次改太多配置：出了問题分不清是哪一层引起的，建议一次只動一個變量。
蜘蛛池的入口頁能不能被正常抓取，很多时候不取决于内容本身，而取决于請求有没有顺利到達。把拦截层排查清楚，再谈内容和連結調整，顺序會更顺。