不少入口頁在服務器确定之後，會顺手接一层 CDN，用来扛並發、挡攻击、降低源站负载。這一步本身没有問题，但 CDN 會改變蜘蛛實际訪問的鏈路：它连到的是邊缘节点，缓存可能让它拿到舊内容，源站日誌里的訪問 IP 也可能全是节点地址。下面把接入 CDN 之後最容易出問题的几個环节拆開说。
缓存：入口頁到底该不该被缓存
缓存是 CDN 最主要的能力，但對入口頁来说，缓存策略要根據頁面性质来定，不能直接套用静態资源的規則。
相對适合缓存的场景
- 入口頁内容長期不變，只做連結聚合，頁面本身没有個性化輸出。
- 源站带宽有限，希望减少重复回源。
- 可以接受較短的缓存時間，例如几分钟到一小时，並配合主動刷新。
不建议缓存或應設定較短缓存的场景
- 頁面内容经常調整，新增連結需要尽快被看到。
- 頁面會根據 UA、Cookie 或来源地区返回不同内容。
- 設定了缓存但忘记清理，邊缘节点長期返回舊版本。
比較稳妥的做法是给入口頁設定一個較短的缓存時間，同时保留手動刷新缓存的入口，避免改了内容却要等很久才生效。
回源之後：日誌里為什么看不到蜘蛛
接入 CDN 後，源站看到的訪問来源會變成邊缘节点的 IP。如果只看源站日誌里的遠端地址，得到的基本都是节点，無法判断来的到底是不是搜尋引擎蜘蛛。
一般需要在源站讀取 CDN 传递的真實 IP 头，例如 X-Forwarded-For、X-Real-IP 或各家服務商自有的头字段。要注意這些头只有在源站可信的前提下才有意义，所以更安全的做法是配合回源 IP 白名單，只信任来自 CDN 节点的請求，其余請求不采信這些头。做完這一步，日誌里的 IP 才具备反查價值。
另外提醒一点：真實 IP 是否属于搜尋引擎，需要通過反向解析或官方 IP 段比對来確認，不能只看 UA 字符串，UA 是可以随意伪造的。
蜘蛛會不會被邊缘节点拦下来
CDN 通常自带一部分安全能力，配置不当时，蜘蛛可能在到達源站之前就被挡掉，而且源站日誌里什么都看不到。常见的拦截点包括：
- WAF 規則把某些參數或路径判定為異常請求。
- 按 IP 维度的频率限制，蜘蛛短時間多次抓取时被限流。
- 地区訪問限制，蜘蛛出口节点所在区域被排除在外。
- 浏览器挑战或 JS 校驗，蜘蛛不执行脚本，直接拿到拦截頁。
排查這類問题时，可以先临时關閉或放宽相關規則，观察入口頁的訪問量是否恢复，再逐步收紧。
回源配置的几個细节
- 回源 Host：確認與源站站点配置一致，否則可能出現預設站点串位。
- 回源协议：如果邊缘用 HTTPS、回源用 HTTP，注意源站的跳轉規則不要形成循环。
- 超时設定：回源超时過短會让响應變慢甚至失敗，蜘蛛侧看到的可能是错誤狀態。
- 回源 IP 白名單：開啟後源站只接受节点訪問，能减少被直接掃描的情况，但要同步维護节点段。
上线後的检查顺序
- 確認入口頁通過 CDN 訪問與直连源站返回的内容一致。
- 检查响應头是否被邊缘节点改寫，例如缓存头、robots 相關头字段。
- 在源站日誌中確認能看到真實 IP，並能與节点 IP 区分開。
- 用真實的抓取工具或日誌观察一段時間，確認訪問没有被邊缘規則拦截。
- 改動内容後主動刷新缓存，再次訪問確認拿到的是新版本。
CDN 只是鏈路中的一层，它不會让入口頁變得更容易被抓取，也不會替代内容本身的建设。接入之前先想清楚要解决的問题，接入之後把日誌和缓存两件事盯住，通常就能避開大部分麻烦。
總的来说，入口頁接 CDN 不是能不能做的問题，而是接完之後有没有把缓存、真實 IP 和拦截規則這三件事對齐。這三項理顺了，日誌才有參考價值，後續的判断也才有依據。