抓取量突然掉下来，而服務器 CPU、带宽、内存都很正常，日誌里也看不到異常請求——這时候有一類原因容易被忽略：請求确實發出去了，但没能到達你的應用。CDN 的 WAF、机房防火墙、云厂商的流量清洗、應用层的限速模块，任何一层把蜘蛛的請求判成可疑流量，站点侧看到的現象就是蜘蛛不来了。
拦截可能發生在哪几层
從搜尋引擎到源站，請求通常要穿過好几道關卡，按顺序大致是：
- DNS 與 CDN 調度层：某些解析线路異常，蜘蛛走了不通的节点。
- CDN 或云 WAF：最常见的一层，規則包括 CC 防護、频率限制、UA 黑名單、地域封禁、人机驗證。
- 机房或云主机的網絡防火墙：對来源 IP 段做限制，或對異常並發直接丢弃。
- Web 服務器與中間件：Nginx 的 limit_req、limit_conn，Apache 的並發上限。
- 應用层：框架自带限流、防爬中間件、驗證碼挑战頁。
每一层被拦，表現都不一样。先确定层，再谈放行，顺序反了容易白折腾。
用日誌差异缩小范围
關键思路是拿三份資料對時間轴：源站訪問日誌、CDN 或 WAF 的請求拦截记錄、搜尋引擎後台的抓取統計與错誤报告。
如果搜尋後台顯示有抓取尝试、CDN 日誌里有對應請求、源站日誌里却没有，拦截点就在 CDN 到源站之間；反過来，源站日誌里有大量 403 或 503，問题就在服務器或應用层。如果三份資料完全對不上，先怀疑解析和线路。
還有一個笨但有效的办法：取一個確認来自官方的蜘蛛 IP，在 WAF 或防火墙後台做一次模拟測試，看它命中了哪條規則。
常见的誤伤類型
- CC 防護把同一 IP 段的密集請求当成攻击。蜘蛛本身就會並發抓取，阈值设低了必然中招。
- UA 黑名單寫得過宽，把包含某些關鍵詞的 UA 一並拦掉。
- 只放行了 GET，蜘蛛的 HEAD 請求、條件請求被拒，影响更新判断。
- 並發连接數限制過低，蜘蛛的多线程請求被部分丢弃。
- 人机驗證或 JS 挑战頁返回 200，蜘蛛拿到的是挑战頁而不是正文。
- 地域封禁誤伤了蜘蛛所在节点的区域。
核對與放行的顺序
- 先在搜尋後台確認抓取是在下降，還是只是你自己日誌里的记錄變少了。
- 拉取最近一周的 WAF 拦截记錄，按狀態碼和規則名分组統計。
- 確認被拦請求的来源 IP 是否落在搜尋引擎官方公布的 IP 段内。
- 對確認過的官方 IP 段做定向放行，而不是全站關閉防護。
- 放宽與蜘蛛相關的限速阈值，單獨给一個並發與速率上限。
- 放行後观察 24 到 72 小时日誌，確認請求能落到應用层。
放行不等于關閉防護。正确做法是给確認過的来源單獨開一條通道，而不是把 UA 關鍵詞加進白名單——UA 可以伪造，只按 UA 放行等于自己開了個口子。
放行时容易踩的坑
- 只放行主站，忘了图片、CSS、JS 所在的静態资源域名。
- 只處理 IPv4 段，漏掉 IPv6。
- 規則改完没確認生效時間，CDN 配置通常有几到几十分钟的下發延迟。
- 放行了抓取，却没同步检查 robots.txt 和驗證碼策略，蜘蛛依然拿不到内容。
放行之後要看的指标
請求恢复不代表事情結束。接下来几天重点看三件事：官方 IP 段的請求量是否回升、狀態碼中 5xx 與 403 的比例是否下降、以及這些請求抓到的 URL 是不是你希望被發現的那些。如果請求回来了但抓的多是參數頁或舊地址，那就得回到内鏈结构和 Sitemap 上繼續核對。
防護規則是双刃剑，挡住攻击的同时也容易挡掉合法抓取。把拦截层定位当成一個固定排查動作寫進日常巡检，比等到抓取量掉了才去翻日誌要省事得多。