聊蜘蛛抓取，多數人先看頁面层：内鏈、Sitemap、robots.txt、内容质量。但蜘蛛發出的第一條請求，走的第一段路其實是網絡层——域名解析、连接建立、CDN 回源。這一层不稳定，頁面层做得再規范，蜘蛛也可能根本拿不到東西。
蜘蛛的一次請求，會经過哪几步
以 https://example.com/a 為例，蜘蛛大致會做這几件事：
- 查询 DNS，把域名換成 IP 地址；
- 與這個 IP 建立连接，HTTPS 還要完成 TLS 握手；
- 如果站点接了 CDN，請求先到邊缘节点，再由节点回源站取内容；
- 拿到狀態碼和 HTML，才開始解析連結、繼續往下抓。
前两步失敗，蜘蛛拿到的是解析超时或连接超时，而不是一個明确的 404；第三步失敗，你看到的往往是 CDN 返回的 5xx、超时頁，或者节点自己生成的错誤响應。
DNS 层面的常见坑
TTL 设得太長，換 IP 後蜘蛛還在敲舊地址
迁移服務器或更換接入商时，如果域名 TTL 设為 24 小时，各地递归解析器會繼續缓存舊 A 记錄。蜘蛛的抓取节点分布在不同網絡环境，缓存到期時間不一致，于是同一批 URL 里，一部分抓到新 IP，一部分還在撞舊 IP，表現為随机失敗、間歇超时。做迁移前把 TTL 調短（比如 300 秒），观察一两天再切換，能明顯减少這種抖動。
多個 A 记錄里有一個是坏的
有的站点為了冗余配了多條 A 记錄，其中一台机器已经下线或防火墙没放行。解析器可能轮询到這條记錄，蜘蛛就连不上。要么及时清理無效记錄，要么在前面加一层带健康检查的负载均衡，让解析结果始终指向可用节点。
權威 DNS 本身响應慢
免費的解析服務偶發抖動时，解析耗时可能從几十毫秒涨到几秒。單次抓取的等待時間被拉長，整体抓取节奏自然變慢。這類問题從頁面代碼里完全看不出来，只能通過多地解析測試對比發現。
CDN 與回源：別把回源超时当成抓取異常
蜘蛛抓取的 URL 里，很多是缓存未命中的新頁面。這时邊缘节点必须回源，源站响應慢或並發受限，节点就可能返回 5xx 或超时頁。蜘蛛遇到持續的 5xx，會主動降低對站点的抓取频率，等站点稳定後再逐步恢复。所以看到抓取量下滑时，先確認是源站問题還是頁面問题，再看是不是 CDN 回源配置導致。
几種容易忽略的情况：回源协议與站点實际协议不一致（例如站点只监听 HTTPS，回源却用 HTTP）；回源时 Host 头被改寫，源站虚拟主机匹配不到，直接返回預設站点内容；CDN 缓存規則把 robots.txt 或 Sitemap 也缓存住，蜘蛛讀到的是舊版本。
一份可操作的排查清單
- 用多個公共解析服務對比同一域名的解析结果，看是否一致、是否明顯變慢；
- 直接绑定源站 IP 請求一次，和走 CDN 的结果對比狀態碼與响應头；
- 在 CDN 日誌里按蜘蛛 UA 過滤，看 2xx、3xx、4xx、5xx 的分布；
- 確認 robots.txt、Sitemap、主要入口頁是否也走了 CDN，是否存在缓存或拦截規則；
- 检查回源协议、端口、Host 头是否與源站配置匹配；
- 換 IP 或換 CDN 前後，观察抓取日誌里超时請求的比例變化。
它和 URL 發現的關系
網絡层長期不稳定，受影响的不只是某一個頁面。蜘蛛在首頁拿不到内容，就發現不了下一层連結；列表頁超时，後面的詳情 URL 就迟迟進不了抓取队列。Sitemap 提交只是把 URL 送進队列，真正决定它們能否被抓到、多久被复查的，仍然是每一次請求能不能顺利拿到响應。把 DNS 和 CDN 這两段路走通，是頁面层優化能生效的前提。