搜尋蜘蛛抓取不到頁面时，很多人的第一反應是去看服務器應用日誌，翻不到记錄就断定“蜘蛛没来”。但抓取鏈路並不止應用层這一段，DNS 解析、CDN 邊缘节点、WAF 規則都可能让請求在到達服務之前就被拦下或改寫。按层次從上到下核對，通常比在應用日誌里反复搜尋更有效率。

一、先确定請求是否真的到達了源站

排查之前先把观察点分開：邊缘层日誌（CDN、WAF）记錄的是“有没有請求進来”，源站日誌记錄的是“請求有没有被應用處理”。两邊對不上，問题大概率在中間层。

• 邊缘有记錄、源站無记錄：多半是缓存命中未回源，或被 WAF 直接返回了拦截頁。
• 邊缘無记錄、源站也無记錄：需要往 DNS 與網絡可達性方向查。
• 两邊都有记錄但狀態碼異常：属于應用层問题，回到 5xx、超时那條线核對。

二、DNS 與解析层核對

蜘蛛抓取前要先解析域名。解析层面出問题，表現往往是某段時間抓取几乎停滞，而且不分頁面、不分路径。

• 解析是否長期稳定，是否出現過记錄被誤删、迁移期間同时存在冲突记錄。
• 是否使用按地域或线路分流的解析，部分线路返回的结果是否可達。
• CNAME 鏈路過長或指向已下线主机，是否造成解析超时。
• DNS 服務商是否存在查询频率限制、查询被拒的情况。

记錄一次解析结果快照（域名、返回 IP、TTL）在排查时很有用，至少能先排除“解析變了”這個變量。

三、CDN 與缓存层核對

缓存命中與回源

缓存命中本身是好事，但要注意两類情况：一是把临时的错誤狀態碼缓存住了，二是缓存了舊的跳轉規則，導致蜘蛛一直走到错誤的地址。

邊缘节点的差异

• 不同邊缘节点缓存狀態不一致，部分节点返回舊内容或驗證頁。
• 更換 CDN 或切換回源地址期間，是否存在节点仍指向舊源站。
• 是否對特定 User-Agent 做了差別化處理，例如對未知 UA 返回驗證頁面。

如果邊缘层對蜘蛛 UA 返回了驗證頁或 403，源站日誌里是看不到這次訪問的，很容易被誤判為“蜘蛛不来”。

四、WAF 與 IP、UA 規則核對

WAF 常因為高频訪問、可疑路径或未知 UA 触發拦截。蜘蛛抓取的特征恰好是短時間内大量請求，容易被誤伤。

• 是否屏蔽了云服務商 IP 段，而蜘蛛出口 IP 正落在其中。
• 是否采用 UA 白名單放行，白名單外的 UA 一律進入挑战驗證。
• 拦截規則近期是否調整過，調整時間点與抓取下降的時間点是否吻合。
• 是否有速率限制規則，把正常的並發抓取判定為攻击流量。

不建议只靠 UA 判断“是不是真蜘蛛”，UA 可以伪造，反向解析加 IP 段核對更可靠。但反過来，也不應因為無法百分之百確認真伪，就把整段 IP 全部拒绝。

五、建议的排查顺序

1. 確認現象范围：全站還是部分路径，持續還是間歇。
2. 查看邊缘日誌是否有對應請求记錄。
3. 核對 DNS 解析结果是否與预期一致。
4. 检查 CDN 缓存狀態與回源配置。
5. 检查 WAF 拦截记錄與近期規則變更。
6. 最後再回到應用层日誌與狀態碼分析。

六、日常可以做的小巡检

與其等到抓取量骤降再排查，不如把几個關键点做成定期检查項：

• 用不同出口網絡（不同地区、不同运营商）解析域名，比對返回结果。
• 定期用蜘蛛 UA 請求核心入口 URL，记錄狀態碼與响應時間。
• 保留一份 CDN 與 WAF 的規則變更记錄，便于和抓取波動做時間對齐。
• 關注 DNS 與證书到期時間，避免過期引發连鎖故障。

網絡层排查的價值在于，它能排除掉一大批看起来像内容問题的假象。把這几层核對清楚之後，再去看抓取预算、内鏈结构、Sitemap 這些环节，判断會准确得多。