為什么解析层容易被忽略
搭建蜘蛛池时，注意力通常放在域名數量、IP 類型、入口頁内容和連結结构上，DNS 解析往往被当成“配一次就不用管”的环节。但蜘蛛訪問入口頁的第一步就是解析域名，解析出問题，後面做得再细也接不到流量。常见表現是：浏览器能打開，蜘蛛却抓不到；或者入口頁时好时坏，日誌里出現大量连接超时。
泛解析：低成本铺開子域
泛解析（*.example.com）让所有未單獨設定的子域都指向同一地址，這是蜘蛛池里最常见的做法。它省掉了為每個子域單獨添加记錄的工作量，适合需要批量生成入口域名的场景。
需要注意的是，泛解析铺開的是域名的數量，不等于獨立的抓取资源。如果所有子域都落在同一台服務器、同一個 IP 上，蜘蛛看到的仍然是一個来源。泛解析解决的是入口數量的批量問题，解决不了分散度問题。
TTL 设多少合适
TTL 决定各地递归 DNS 缓存這條记錄多久。设得太長，換 IP 或換服務器後，部分蜘蛛可能還在訪問舊地址；设得太短，解析請求變多，遇到 DNS 服務商限速反而更不稳定。
- 日常稳定執行：300 到 600 秒是比較常见的取值，兼顾切換速度和解析压力。
- 近期計划迁移：可以临时降到 60 到 120 秒，迁移完成、观察一两天後再調回去。
- 不要為了“看起来可控”把 TTL 设成個位數，收益很小，風險不小。
解析生效和铺連結的先後顺序
一個常见的操作失誤是：域名刚註冊、解析還没生效，就把入口連結批量放出去。蜘蛛第一次訪問拿到的是解析失敗或连接超时，這類失敗會被計入抓取质量，後續再来的意愿會下降。
比較稳妥的顺序是：先加解析，用 dig、nslookup 或多地 ping 確認主要地区都能解析到正确地址，再用工具確認入口頁能正常返回 200，最後才開始铺連結。
用 CNAME 接 CDN 时要注意什么
把子域 CNAME 到 CDN 域名後，蜘蛛看到的 IP 是 CDN 节点的地址，回源才到你自己的服務器。這时要留意几点：
- CDN 的缓存規則如果缓存了跳轉或错誤頁，可能把 5xx 缓存下来持續返回给蜘蛛。
- 部分 CDN 對陌生 UA 或高频請求有預設防護，抓取請求可能被拦截或限速。
- 回源地址變更後，记得同步更新 CDN 配置，否則源站換了、回源還指向舊机器。
智能解析與多线路
如果入口分布在多個机房，可以用智能解析按线路或地区返回不同的 IP，這在一定程度上能提升訪問成功率。但別指望它来伪装资源分散度——同一批域名的解析记錄仍然在同一個 DNS 服務商手里，整体特征還是相似的。
排查清單
- 目标域名在多個地区的解析结果是否一致，有没有指向已经不用的舊 IP。
- TTL 是否合理，近期是否調整過 IP 但没有提前降低 TTL。
- 泛解析是否被意外開啟，導致不打算啟用的子域也能訪問。
- DNS 服務商的可用性和限速策略，免費套餐是否有請求频率限制。
- 從服務器本地和外部網絡分別測試解析與訪問，区分是解析問题還是服務問题。
解析是入口頁能被抓到的前提，它本身不产生内容，却决定了後續所有工作的起点是否成立。
寫在最後
DNS 层面的問题往往不复杂，但排查起来容易绕遠路：本地能打開、蜘蛛抓不到，很多时候只是记錄没生效或 TTL 還在缓存期。把解析检查纳入日常巡检，比事後從日誌里倒推原因要省事得多。