蜘蛛抓取的第一步不是 HTTP，而是 DNS
很多人調蜘蛛池时盯着狀態碼、頁面体积、内鏈结构，却忽略了一件事：蜘蛛在發出 HTTP 請求之前，先要把域名解析成 IP。解析失敗、超时、返回了错誤的 IP，後面所有優化都没有机會被执行。日誌里看到的抓取量下滑，有时不是頁面問题，而是解析层面的問题。
TTL 决定了換 IP 的過渡速度
TTL（Time To Live）是解析记錄在各級 DNS 缓存里的存活時間，單位是秒。它的實际含义是：你改了记錄，並不代表所有人立刻看到新记錄，最坏情况要等舊的 TTL 到期。
- TTL 设成 86400（一天）时，換 IP 後部分解析节点可能仍把請求送到舊机器上，持續接近一天。
- TTL 设成 60 到 300，切換灵活，但解析請求會更频繁地打到 DNS 服務商，稳定性依赖服務商质量。
- 折中做法：日常用 600 到 3600，計划換 IP 前 24 到 48 小时把 TTL 降到 300 以下，等舊 TTL 全部過期後再切，切換稳定几天後再改回常規值。
不预热 TTL 就直接換 IP，等于让一部分蜘蛛繼續訪問舊地址。舊机器如果已经關停，它們拿到的是连接超时或 5xx，這類记錄對入口頁没有好處。
记錄類型里的几個坑
AAAA 记錄
如果域名同时有 A 和 AAAA 记錄，支持 IPv6 的客戶端會優先走 IPv6。入口頁所在服務器如果没有正确配置 IPv6，或者防火墙只開了 IPv4，就會出現一部分抓取失敗、一部分正常的情况，排查起来很費時間。没有 IPv6 环境时，把 AAAA 记錄清掉比留着更省事。
CNAME 鏈
接入 CDN 或第三方服務後，域名常常指向一层甚至多层 CNAME。鏈條越長，中間任一环节解析異常都會導致整條鏈路失敗；而且每一层的 TTL 可能不同，缓存過期時間以最短的那层為准，行為不好预测。鏈路尽量控制在两层以内。
泛解析
用 * 泛解析可以省去逐個添加子域名，但副作用是任何拼错的、被外部連結引用的、甚至是掃描器猜出来的子域名都會解析成功，並返回同一個頁面。這容易制造出大量内容重复的地址。如果确實需要泛解析，建议在服務端對不在清單内的 Host 返回 404 或直接断開，而不是统一吐首頁。
智能解析與多地节点
使用按线路返回不同 IP 的解析服務时，要保證每一條线路指向的机器都能正常响應、内容版本一致。常见問题是只更新了預設线路，电信或海外节点還指向已经被回收的 IP。蜘蛛的出口 IP 分布很广，命中的线路不可控，只要有一條线路不通，抓取成功率就會被拉低。
怎么自查
- 用 dig 或 nslookup 對域名多次查询，看返回的 IP 是否稳定、是否與预期一致。
- 借助第三方多地解析檢測工具，確認各区域返回的结果。
- 直接以 IP 訪問、带上 Host 头測試，確認机器本身可用，把解析問题和服務器問题分開。
- 對照訪問日誌，看抓取請求的响應碼和耗时，是否存在成片的超时或连接失敗。
解析問题不會出現在頁面上，只會出現在抓取结果里。排查抓取量異常时，先把 DNS 這一层排除掉，再谈頁面和内容。
几條實操建议
- 換 IP 前先降 TTL，切換完成並稳定後再調回，不要長期使用极短的 TTL。
- 裸域和 www 一起检查，两邊记錄不一致是常见疏漏。
- 把解析服務商本身当作可用性的一部分来评估，不要只看價格。
- 入口頁數量較多时，维護一份域名到 IP、TTL、更新時間的清單，避免改漏。
- 不要频繁更換 IP。解析變更越频繁，過渡期越長，抓取越容易在過渡期里踩空。