不少人给蜘蛛池的入口頁套上 CDN 和 WAF 之後，會看到一個很直接的變化：頁面本身能正常打開，但蜘蛛的訪問记錄明顯變少。這时候容易产生两種极端判断，一是“CDN 會屏蔽蜘蛛”，二是“防護太强必须全關”。實际情况通常介于两者之間——防護层本身不等于拦截，真正让蜘蛛走不進来的，往往是几個具体的配置细节。
CDN 本身很少拦住蜘蛛
CDN 做的是就近分發和缓存回源，對普通 GET 請求一般不會做額外判断。問题多出在這几處：
- 缓存策略過粗。如果入口頁被長時間整頁缓存，蜘蛛和新訪客拿到的是同一份 HTML，頁面内容更新後蜘蛛看到的還是舊版本，長期下来抓取频率會自然下降。
- 回源超时太短。源站响應慢一点就回 522、524 之類的错誤，蜘蛛拿到的是異常狀態碼，自然會降低對這個地址的信任。
- 节点與源站地区不匹配。回源鏈路绕遠，TTFB 偏高，抓取队列里的優先級會被压低。
這几項都能通過监控回源耗时、缓存命中率和狀態碼分布查出来，不需要動防護策略。
WAF 是最常见的誤伤現场
人机校驗、JS 挑战、滑块驗證這些机制，本质上要求客戶端执行脚本或完成交互，而绝大多數搜尋蜘蛛不會做這两件事。结果就是入口頁對人能打開，對蜘蛛返回 403 或一個驗證頁。
另一類誤伤来自規則本身：
- 把包含 bot 的 UA 统一拉黑，顺带把 Googlebot、Bingbot 這類正常爬虫一起挡了。
- 按 IP 請求频率做 CC 防護，阈值设得太低，蜘蛛连續抓取就被判定為攻击。
- 只按 UA 做白名單。UA 可以随意伪造，這種放行方式既挡不住假蜘蛛，也容易在規則調整时誤伤真蜘蛛。
接上 CDN 之後，日誌里的 IP 已经不是訪客 IP
這是很多运营忽略的一点。源站日誌里顯示的全是 CDN 节点的 IP，你看到的“蜘蛛”，可能只是节点回源。判断真實来源需要做两件事：
- 在源站配置真實 IP 解析（如 Nginx 的 real_ip、Apache 的 RemoteIP），並把 CDN 的节点段加入可信来源。
- 優先讀取 CDN 传递的原始 IP 字段，同时保留节点 IP 作為校驗，避免头部被伪造。
否則後面所有關于抓取量、抓取频率的分析都是错的，防護策略也無從調整。
比較稳妥的放行思路
- 入口頁和目标頁分開處理。入口頁以可抓取為第一目标，防護做得轻一些；需要重点保護的接口、後台、資料頁面再上重防護。
- 用 UA、IP 段、反向 DNS 三重校驗放行。只靠其中一項都容易被绕過或誤伤。
- 给已知蜘蛛單獨放宽频率阈值。不要让它和普通訪客共用同一套限速。
- 改動後观察一段時間。看日誌里蜘蛛的抓取量、狀態碼分布和回源耗时，再决定是否繼續收紧。
- 保留一份不经防護的回源入口。方便對比排查，也避免規則出错时彻底断掉抓取。
防護层的目标是挡掉無效流量，而不是挡掉所有自動化請求。把蜘蛛和攻击流量放在同一套規則里處理，几乎是必然出問题的做法。
小規模入口頁未必需要防護
如果只是几台服務器、几十個入口頁，本身没有明顯的攻击压力，套 CDN 和 WAF 反而會增加排查难度：日誌要多解析一层，故障点從一個變成三個，抓取異常时很难快速定位。這種情况下，把精力放在頁面可訪問性、响應速度和内容更新上，收益通常比加防護更直接。
反過来说，如果入口頁已经频繁被打、被刷或被恶意掃描，防護就是必要的，只是要按上面几條把放行通道留清楚。CDN 和 WAF 都是工具，蜘蛛抓取量下降從来不是“用了防護”這一個原因造成的，更多是配置和驗證方式的問题。