站点接入 CDN 或云防護之後，抓取相關的現象往往會變形：源站日誌里看不到蜘蛛，邊缘日誌里能看到但内容對不上，或者同一時間段不同地区的抓取表現完全不同。想搞清楚問题，得先把一條請求经過的几层拆開看。
一條蜘蛛請求通常要经過哪几层
從蜘蛛發起請求到拿到 HTML，大致是：蜘蛛 → DNS 解析 → 邊缘节点 → 缓存判断 →（未命中时）回源站 → 源站應用與資料库 → 原路返回。任何一层出問题，表現都可能被归结為“蜘蛛抓得不好”。
- 邊缘节点：决定用哪份缓存、是否触發防護規則。
- 缓存层：决定返回缓存副本還是回源，以及缓存多久。
- 回源鏈路：决定源站看到的 IP、协议和超时预算。
- 源站：真正生成 HTML 的地方，也是抓取真正消耗资源的地方。
最容易被誤判的三種情况
1. 返回的是缓存副本，内容已经變了
站在蜘蛛角度，它拿到的還是舊版本。如果缓存時間較長，新發布的内容可能迟迟不被看到。排查方式是固定一個刚更新的 URL，连續請求几次，對比返回内容與源站内容是否一致，並查看响應头里的缓存标识。
2. 缓存命中率剧烈波動，回源被打爆
大站常见：蜘蛛集中抓取的时段，缓存陆續過期，回源請求堆上来，源站開始變慢甚至超时，蜘蛛那邊看到的就是超时或 5xx。這種問题往往不是“蜘蛛抓太狠”，而是缓存策略和回源容量没有给足余量。
3. 安全防護把正常抓取挡在外面
部分防護規則按請求特征拦截，可能把蜘蛛和普通爬虫一起拦住，返回 403 或挑战頁面。此时蜘蛛拿到的是拦截頁，自然不會繼續發現 URL。
蜘蛛看到的 IP 與源站日誌的差异
经過 CDN 後，源站日誌里记錄的往往是邊缘节点 IP，而不是蜘蛛的真實 IP。這會影响两件事：一是判断不清抓取是不是真的来了，二是按 IP 做的限流策略可能誤伤。通常需要在回源时透传真實 IP 头（如常见的轉發头），並在源站應用里按该头取真實来源。
一個可执行的排查顺序
- 固定几個代表性 URL：首頁、列表頁、詳情頁、刚更新頁各一個。
- 用不同地区或不同出口分別請求，观察返回内容和狀態碼是否一致。
- 查看响應头中的缓存、节点、回源相關字段，判断命中還是回源。
- 對照邊缘日誌和源站日誌，看同一時間点两侧记錄是否對得上。
- 確認蜘蛛的真實 IP 是否被透传，防護規則是否放行。
- 检查回源超时設定與源站慢請求，看看是否存在超时之後的級联問题。
抓取問题發生在源站时，排查相對直接；發生在中間层时，症状會分散在多個环节，先把鏈路固定下来比急着改配置更有效。
配置上的几点注意
- 動態頁面與列表頁尽量短缓存或不缓存，静態资源可以長缓存。
- URL 參數參與缓存键时，注意別让同一頁面因參數差异生成多份缓存。
- 回源超时不要设得過短，也不要让超时後的重试把源站压垮。
- 放行策略按已驗證的来源做，而不是只看 User-Agent 字符串。
- 發布新内容後，可主動刷新對應 URL 的缓存，缩短被看到的時間。
把中間层当成抓取路径的一部分来看待，很多“蜘蛛不抓了”“抓的是舊内容”“日誌里没有蜘蛛”的問题，會更容易定位到具体环节。