蜘蛛没来，還是没被放進来
不少站点排查抓取問题时，第一反應是翻服務器日誌，看有没有蜘蛛的訪問记錄。如果没有，就預設蜘蛛没来過，接着去改内鏈、改 Sitemap、加外鏈。但更常见的情况是：請求确實發出過，只是被站点前面的 CDN、WAF 或自建限流层挡掉了，源站日誌里干干净净，什么也看不到。
這類問题會直接影响 URL 發現效率——已经存在的連結可能長期不進待抓队列，新 URL 的曝光速度也會明顯變慢。麻烦的地方在于，它在源站一侧几乎無法自我暴露，需要主動去驗證。
三類高频誤伤
1. 按 User-Agent 做關鍵詞拦截
有些防護規則會拦掉 UA 里带 bot、spider、crawler 的請求，或者只放行少數几個自己寫進去的 UA。蜘蛛的 UA 較長且带版本信息，很容易被当成自動化工具誤伤。反過来，只靠 UA 放行也不够安全，因為 UA 可以伪造，但這属于另一個問题，先解决誤伤。
2. 频率限制與驗證挑战
限流規則通常按 IP 或 UA 統計單位時間内的請求數。蜘蛛抓取时會在短時間内集中請求同一批 URL，很容易触發阈值，随後收到 429、403，或者被塞進一個 JS 驗證頁面。它拿不到真實 HTML，抓取路径就在這里断了。JS 挑战尤其麻烦，因為返回的往往是 200，從狀態碼上很难看出問题。
3. IP 段與地区封禁
為了挡掉恶意流量，部分站点會整段封禁某些云服務商或海外 IP 段。蜘蛛的出口 IP 恰好落在這些網段里时，就會连门都進不来。這類封禁常寫在 CDN 或防火墙的最外层，源站再怎么調整也绕不過去。
怎么確認是不是被挡了
先做交叉驗證，不要只看單一来源：
- 看 CDN 或 WAF 侧的回源日誌與拦截統計，而不是只看源站訪問日誌。拦截记錄里通常能看到被拒的 UA 和狀態碼。
- 把搜尋平台提供的抓取統計與源站日誌對照。如果平台顯示大量超时、连接失敗，而源站没有對應记錄，基本可以定位到中間层。
- 核對蜘蛛 IP 真實性时，用反向 DNS 解析到官方域名，再正向解析回原 IP。不要只依赖一份静態 IP 清單，清單更新不及时會誤判。
可以直接落地的几條原則
- 把已驗證的蜘蛛来源做成白名單，放在限流和驗證規則之前，優先級高于通用風控。
- 對 HTML 與静態资源分開限流。图片、CSS 這類請求量大的资源不设過嚴阈值，否則頁面渲染和抓取都會被拖住。
- 限流触發时優先返回 429 並给出合理的重试提示，避免用 200 的驗證頁伪装成功。
- 定期复查封禁列表，尤其是地区級和網段級規則，改版或迁移後要重新確認一遍。
- 把抓取相關的拦截事件纳入日常监控，出現突增时先排查配置變動，而不是急着改内容。
几句提醒
防護和抓取並不是對立面。多數誤伤来自預設規則和長期未复查的例外項，而不是有意的封禁。把放行條件寫清楚，比事後反复猜為什么没抓有效得多。
另外要接受一個前提：把蜘蛛放進来，只代表它有机會看到你的頁面，不代表一定會抓、一定會收錄。抓取只是流程里的一环，能做的部分是减少無谓的阻断，让 URL 被發現、被訪問的路径保持通畅。