蜘蛛池的入口頁大多不放在目标站同一台服務器上，常见做法是挂在其他域名、其他 IP 甚至其他机房的机器上。這些机器同样可能套着 CDN、WAF 或面板類防護。一旦防護規則把搜尋蜘蛛当成攻击流量，蜘蛛看到的頁面就和你以為的入口頁不是同一份，里面的目标連結也就無從谈起。
拦截不一定表現為抓取失敗
很多人以為被拦截就是日誌里没有蜘蛛记錄。實际情况往往更麻烦：請求确實到了服務器，也返回了 200，但内容被替換掉了。
- 返回 403、406 或自定义拦截頁，狀態碼看起来只是一次普通的错誤响應；
- 返回 200，但内容是 JS 挑战頁、驗證碼或“正在驗證您的浏览器”；
- 回源正常，CDN 邊缘节点却返回缓存的舊版本或错誤版本；
- 同一 URL，蜘蛛 UA 拿到 A 頁面，普通浏览器 UA 拿到 B 頁面；
- 請求被限速、丢包或超时，蜘蛛只抓到一半 HTML，後半部分的連結没被解析到。
這几種情况在服務器日誌里都可能呈現為“有訪問、有 200”，所以只看有没有抓取记錄，很容易誤判。
先分清是拦截還是別的环节
入口頁里的連結没被跟進，原因不止防護一種。排查时建议按顺序排除。
- 換 UA 回源測試：用 curl 或浏览器插件，分別带上普通 UA 和搜尋蜘蛛 UA 請求同一個入口頁，對比返回的狀態碼、Content-Length 以及正文前几百個字符是否一致。
- 绕開 CDN 直连源站：把域名临时解析到源站 IP，或在 CDN 後台使用回源測試，確認源站本身没有被面板拦截。
- 看蜘蛛侧是否真的来過：在服務器日誌里匹配蜘蛛 UA 與已知 IP 段，確認請求數、返回碼和响應時間。如果连請求都没有，問题在更前面的环节，比如 robots 規則、DNS 解析，或者這個入口頁根本没被提交過。
- 確認返回的是完整 HTML：检查 Content-Length 與响應体實际長度是否一致，連結是否正好落在被截断的位置。
調整防護时的几個注意点
確認是拦截造成的問题後，處理方式要克制，不要為了放行而把整站防護關掉。
- 優先按已驗證的蜘蛛 IP 段做白名單，而不是只按 User-Agent 放行。UA 可以随便伪造，只認 UA 相当于给恶意爬虫留了後门。
- 如果确實需要按 UA 放行，建议叠加频率限制，避免白名單被滥用。
- 關閉针對入口頁的 JS 挑战，或者把入口頁路径加入挑战豁免名單。
- CDN 缓存規則要確認不會缓存驗證碼頁或错誤狀態响應，错誤頁建议設定不缓存或使用較短的 TTL。
- 改完後隔一段時間再看一次日誌和抓取情况，確認拦截頁没有再出現，而不是改完就当問题已经解决。
防護需求和抓取需求天然存在冲突，調整时優先精确放行而不是整体關閉；改完要用日誌和回源測試驗證，而不是凭感觉認為已经放通。
最後提醒一点：入口頁能正常返回、蜘蛛也确實抓到了，也不等于里面的目标連結一定會被跟進和收錄。抓取只是發現环节，後面的連結解析、去重、质量判断各有各的規則。把“入口頁能稳定返回一份包含目标連結的正常 HTML”当作底线目标，比指望某一次防護調整带来收錄變化要現實得多。