给站点做一轮安全加固之後，经常會出現一種很別扭的情况：頁面没動、内容照常更新，但服務器日誌里蜘蛛的来訪次數明顯少了。很多人第一反應是去查收錄、查内容质量，其實問题很可能出在服務器层——防火墙、WAF 或者限流規則把正常蜘蛛一起挡掉了。
為什么這件事容易被忽略
robots.txt 是明面上的規則，改了什么、拦了谁，打開文件就能看见，也容易回滚。而服務器层的拦截往往分散在几個地方：CDN 後台、Nginx 配置、面板自带的安全插件、云厂商的防護策略。它們通常由运维或一键開啟，生效之後不报错，也不影响你自己用浏览器訪問，表現只是抓取量悄悄下滑，所以很难第一時間联想到。
更麻烦的是，這類誤伤通常是「一段時間内全部 403」或者「高峰期才被限流」，比全站宕机隐蔽得多。
常见的誤伤场景
- 按 User-Agent 關鍵詞粗暴拦截。規則里寫了 bot、spider、crawl 之類的關鍵詞，本意是挡掃描器，结果搜尋引擎蜘蛛的 UA 里正好带這些词，一並被拦。
- 频率限制過嚴。蜘蛛抓取往往是並發請求，如果限流阈值按「單個訪客一分钟几次」来设，很容易触發临时封禁，返回 429 或 503。
- 整段封禁 IP。為了挡某個来源的骚扰，直接把一整個 IP 段拉黑，而蜘蛛的部分出口 IP 恰好落在這個段里。
- 人机校驗铺得太广。全站或大范围啟用驗證碼、JS 挑战，普通用戶能過，蜘蛛過不去。
- 規則只改了一半。在 CDN 层放行了蜘蛛，源站的 Nginx 或安全插件還留着舊規則，請求到了源站照样被拒。
怎么確認是不是被拦了
不要凭感觉下结论，按下面這個顺序走一遍，基本能定位到是哪一层的問题。
- 先從服務器訪問日誌里看蜘蛛的返回碼分布，重点看有没有成片的 403、429、503，以及是不是集中在某几個時間段。
- 把日誌里出現的蜘蛛 IP 做一次反向解析，確認它到底属不属于官方公布的 IP 段，別把伪造 UA 的掃描器当成蜘蛛。
- 在服務器上直接發請求做對比：同一台机器、同一個 URL，分別带普通 UA 和蜘蛛 UA 各請求一次，看返回是否一致。
- 检查 CDN、WAF、主机面板的拦截日誌或安全事件列表，很多产品會把触發規則和命中次數列出来。
- 挑一到两個具体 URL 复現，而不是只看總量趋势。總量受很多因素影响，具体 URL 的表現更直接。
處理时守住几條原則
- 白名單優先于黑名單。能用放行官方蜘蛛 IP 段解决，就不要靠改 UA 規則去绕。
- 区分限流和封禁。限流是降低频率，封禁是直接拒绝，两者的影响完全不同。對蜘蛛更适合用較宽松的限流而不是封禁。
- 改完留观察期。調整之後至少要观察一段時間的日誌和抓取資料，確認返回碼恢复正常，別改完就当結束了。
- 別用封 IP 解决内容問题。如果某個 IP 频繁来抓，先想想是不是自己站内出現了大量可遍歷的 URL，而不是先加黑名單。
把規則记成一份可复用的清單
拦截規則散落在多個系統里，最容易出問题的就是「谁在什么时候改了什么」。建议维護一份简單记錄，包含：規則内容、生效位置（CDN / 源站 / 面板）、開啟時間、放行對象、驗證方式。下次抓取量再出現波動时，先翻這份记錄，比重新排查一遍快得多。
安全加固的目标是挡住恶意流量，不是把站点變成一個只有真人能進的封閉空間。拦截策略上线前，多想一步「這會不會连带影响到蜘蛛和普通訪客」，能省掉後面很多来回排查的時間。
小结
爬虫拦截自查不需要多高深的技術，關键在于把它当成一個固定動作：定期看一眼日誌里的返回碼分布，確認白名單還在、規則没被覆盖。抓取量下滑时，先排除服務器层的拦截，再去谈内容和结构，往往能少走很多弯路。