為了让入口頁抗住压力、隐藏源站 IP，不少蜘蛛池會把入口頁放到 CDN 或云 WAF 後面。這套架构本身没問题，但它會在“搜尋蜘蛛能不能拿到頁面、拿到的是什么内容、源站能不能看到真實訪問”這几個环节上增加變量。抓取效果不理想时，先排除 CDN 和 WAF 這一层，往往比反复改 HTML 更有效率。
CDN 與 WAF 主要影响哪几件事
可以把這一层理解為中間人，它同时影响三件事：
- 請求能否到達源站：WAF 的規則、频率限制、人机校驗可能直接拦掉搜尋蜘蛛的請求。
- 返回给蜘蛛的内容：CDN 缓存可能返回舊版本，或者返回一個不带連結的驗證頁。
- 源站日誌的可信度：源站看到的 IP 多半是 CDN 回源节点的，不再是蜘蛛的真實 IP。
常见的几類具体問题
WAF 把人机校驗甩给了搜尋蜘蛛
很多云 WAF 預設對“没有浏览器特征”的請求做 JS 挑战或等待校驗。搜尋蜘蛛不會执行 JS，也不會带完整的浏览器指纹，结果就是被反复挑战、最终拿到一個空壳頁面或被直接拒绝。表面上看是“入口頁没被抓”，實际是請求在邊缘就被拦下了。
判断方法很直接：用搜尋引擎官方的抓取測試工具跑一次，或者直接從 WAF 日誌里看有没有被 challenge、block 的记錄。如果同一時間大量被拦截請求的 UA 正是搜尋蜘蛛，基本可以確認是規則誤伤。
缓存把入口頁缓存成了空頁或舊頁
入口頁的内容通常是動態拼出来的，比如從库里取一批目标 URL。如果 CDN 或 WAF 的缓存策略較激進，可能出現两種情况：
- 缓存了首次渲染时還没資料、或者被拦截後的空白版本，之後一直返回這個版本；
- 缓存了几天前的舊連結列表，蜘蛛抓到的還是已经下线的目标 URL。
入口頁這類需要随时反映目前連結列表的頁面，通常不建议做長缓存。给入口頁路径單獨设一條缓存規則，把 TTL 压得很短，或者對搜尋蜘蛛的 UA 直接回源。
源站日誌看不到蜘蛛真實 IP
開啟 CDN 後，源站訪問日誌里记錄的往往是 CDN 回源节点的 IP，而不是搜尋蜘蛛的 IP。這會直接影响蜘蛛身份的正反回驗流程——你按 IP 去反查域名，得到的是 CDN 厂商的域名，看起来“不像蜘蛛”，于是誤判成假蜘蛛。
解决方式有两種：一是開啟 CDN 提供的真實 IP 回传头，常见的是 X-Forwarded-For 或厂商自定义头，並在源站日誌格式里把它记錄出来；二是把 CDN 厂商公布的节点 IP 段整理成一份白名單，日誌分析时先做一层映射。
节点調度带来的区域差异
CDN 會把不同地区的請求解析到不同节点。搜尋蜘蛛的抓取节点分布在不同区域，不同节点上的缓存狀態、回源策略可能不一致，于是會出現“同一時間有的节点能抓到、有的抓不到”的情况。排查时最好固定從一個节点复現，再對比多個节点的差异。
一個可落地的排查顺序
- 先確認請求有没有到源站：看 WAF 或 CDN 日誌里该 URL 的請求记錄，以及源站是否收到對應的回源請求。
- 再確認返回内容：直接請求入口頁 URL，對比带搜尋蜘蛛 UA 和不带两種情况下的 HTML 是否一致。
- 检查缓存狀態：看响應头里的缓存命中标记，判断返回的是缓存版本還是回源版本。
- 核對真實 IP：確認源站日誌记錄的是回源 IP 還是真實客戶端 IP，再决定怎么设計蜘蛛身份驗證。
- 最後才動入口頁本身：HTML 结构、連結寫法這些問题放在這一层之後排查。
配置上的一些實用建议
- 给搜尋蜘蛛的 UA 單獨放行，跳過 JS 挑战和频率限制，但不要因此對所有 UA 都放行。
- 入口頁路径單獨设缓存規則，不要和目标站的静態资源共用一條策略。
- 如果入口頁需要隐藏源站，回源鉴權用密钥或 IP 白名單，不要靠 UA 判断。
- 日誌里務必保留真實客戶端 IP 字段，否則後續的抓取分析和蜘蛛驗證都做不准确。
- WAF 規則調整後，用同一批目标 URL 观察一段時間，對比調整前後的回源量和抓取量。
CDN 和 WAF 是入口頁的门卫，出問题时的表現和“頁面寫得不好”很像，但排查方向完全不同。先把這一层排除掉，再去看 HTML 和連結本身。
最後提醒一句，這一层配置的目的是让正常抓取顺利通過、把異常流量挡在外面，而不是無差別拦截。規則越嚴，誤伤真實搜尋蜘蛛的概率也越高，需要结合日誌持續調整。