搭蜘蛛池的时候，很多人的注意力都在入口頁内容、域名歷史和服務器上，DNS 解析往往最後随手配一下就完事。但蜘蛛要爬到入口頁，第一步是拿到 IP。解析這一环出問题，後面做得再好也是空轉。
解析出错时，入口頁對蜘蛛等于不存在
蜘蛛拿到一個 URL 後，大致要走：查 DNS → 拿 A 记錄或 CNAME → 连服務器 → 請求頁面。任何一步失敗，抓取就到此為止，日誌里可能连一條记錄都没有，你只會看到訪問量上不去，却找不到原因。
常见的解析問题包括：
- 子域漏配，入口頁清單里有一批域名根本解析不到 IP；
- DNS 服務商不稳定，解析超时率高，蜘蛛偶尔能拿到、偶尔拿不到；
- 解析指向的 IP 已经下线或換了机房，但记錄没有同步更新；
- 解析记錄被誤删或過期，批量管理时尤其容易發生。
泛解析和逐條解析，各管一段
泛解析：适合入口頁數量大、结构统一的场景
用 *.example.com 一條记錄覆盖所有子域，新入口頁上线不需要改 DNS，运维成本最低。代價是控制粒度粗——如果某個子域需要單獨指向另一台机器，就得為它加一條顯式记錄。
逐條解析：适合需要精细控制的场景
每條入口頁單獨配 A 记錄或 CNAME，可以按机房、按 IP 段、按业務线分開。缺点是维護量大，域名一多，人工很容易漏，建议配合脚本或 API 批量管理。
比較常见的做法是：主入口用泛解析保證覆盖，少數需要單獨調度的入口頁用顯式记錄覆盖。另外別忘记，顯式记錄的優先級高于泛解析，改之前想清楚哪些子域是被盖住的。
TTL 设多長，取决于你要多久改一次
TTL 决定各地 DNS 缓存這條记錄多久。它不是一個越短越好的參數：
- TTL 太短（比如 60 秒）：记錄變更生效快，但解析請求量明顯上升，遇到服務商限速时反而容易出問题；
- TTL 太長（比如 24 小时）：解析压力小，但換 IP、換机房时要等很久才能全量生效，期間會有一部分請求仍然打到舊地址。
已经稳定執行的域名，取几小时到一天比較省心；還在調试、可能频繁調整的域名，取几分钟到十几分钟更方便。切換 IP 前，先把 TTL 調短，等舊缓存過期再改记錄，能少踩很多坑。
如果換 IP 後仍有部分請求落在舊机器上，先別怀疑蜘蛛不听话，多半是 TTL 還没走完。
解析服務商這块，別省過头
解析本身很便宜，但它是整條鏈路的單点。選服務商时，可以看這几項：
- 是否有多個 NS，且分布在不同網絡；
- 是否提供解析线路（电信、联通、移動、海外）與健康检查；
- 是否支持 API 批量增删改，域名多的时候這点很關键；
- 是否有限速策略，超量後是降速還是直接拒绝。
域名規模上百以後，手工在控制台点来点去几乎不可维護，建议提前把 API 接進自己的管理脚本。
几個常见誤区
- 只测主域名，不测随机子域。泛解析配置错了，主域名往往還是好的，問题只出現在子域上。抽查时要随机取若干入口頁域名，用 dig 或在线工具確認返回值。
- 以為解析生效就等于有人来。解析只是让入口頁可達，蜘蛛来不来、来多少，還受域名歷史、内容、抓取配額等影响，別把它当成開關。
- 一次改太多。DNS、服務器、入口頁内容同时換，出問题时很难判断是哪一步造成的，建议分批分次改。
- 忽略解析和 HTTPS 的配合。解析換了 IP 之後，證书、回源配置没跟着更新，會出現握手失敗，蜘蛛同样拿不到頁面。
上线前的检查清單
- 随机抽取若干入口頁域名，逐一確認解析结果與预期 IP 一致；
- 用不同網絡环境（至少两處）驗證解析是否一致；
- 確認 TTL 與目前的變更频率匹配；
- 確認解析记錄有备份，誤删後能快速恢复；
- 確認解析變更後，服務器上的站点配置、證书都已同步。
解析是最底层的一环，做對了不會有額外收益，做错了會让上面所有工作归零。把它当成常規检查項，比出問题後再回头排查省事得多。