很多人查抓取問题，习惯從頁面内容、狀態碼、内鏈看起，但蜘蛛真正遇到的第一道關，往往發生在 HTML 之前：域名解析、TCP 连接、TLS 握手。這几步出了問题，日誌里可能只是一片空白，连一次訪問记錄都留不下。
DNS：抓取鏈路上最容易被忽略的第一跳
蜘蛛要抓 https://example.com/a，第一步是把域名解析成 IP。這一步的開销取决于解析服務商、TTL 和线路。如果解析响應長期在几百毫秒以上，或者偶尔超时，抓取就會表現為时快时慢、部分頁面始终抓不到。
- TTL 設定過短，解析被反复請求，容易受解析服務商抖動影响；TTL 過長，切換 IP 或迁移时生效太慢。
- 多地解析到不同节点时，要確認每個节点都能正常响應蜘蛛請求，而不是只有主力线路可用。
- 解析记錄里存在失效 IP，或者 CNAME 鏈拉得太長，都會拖慢甚至中断连接。
排查时可以在服務器上直接 dig 域名，看返回的 IP 是否與预期一致、响應時間是否稳定。
TLS 與连接复用：握手失敗等于頁面不存在
HTTPS 站点建立连接时要完成 TLS 握手。證书鏈不完整、中間證书缺失、SNI 配置不對、只支持過老的协议版本，都可能让蜘蛛在握手阶段就断開。這類問题在自己浏览器里往往看不出来，因為浏览器會做缓存和补全，而蜘蛛基本每次都從零開始。
几個常见的坑
- 證书鏈不完整：浏览器能自動补，蜘蛛不一定。
- 證书域名與實际訪問域名不匹配，比如 www 與裸域共用一張不覆盖两者的證书。
- 只開 IPv6 或只開 IPv4，導致部分網絡环境的蜘蛛连不上。
- 强制跳轉 HTTPS 但證书尚未生效，形成连接层面的循环。
用在线工具检查證书鏈，並確認 www、裸域、协议版本都能正常握手，比事後猜测更有用。
服務器稳定性：不是快，而是稳
抓取對服務器的要求不是峰值多快，而是响應是否可预期。同一批 URL，如果响應時間在 100ms 到 3 秒之間来回跳，蜘蛛通常會降低抓取频率，URL 的發現和回訪都會跟着變慢。
- 带宽與並發：蜘蛛的請求會集中在短時間内到達，限速策略要留出余量。
- WAF 與防火墙：驗證碼、JS 挑战、按 UA 拦截，都會让蜘蛛拿不到内容，而且常常留下 403 而不是 5xx，容易被誤判成權限問题。
- 後端接口慢：頁面本身不大，但首字节時間很長，實际效果和超时差不多。
先確認服務器“對谁都稳”，再谈蜘蛛為什么抓得少。站点监控看到的和蜘蛛看到的，往往是同一件事的两個视角。
一條可执行的排查顺序
- 從服務器直接請求几個關键 URL，记錄解析耗时、连接耗时和首字节時間。
- 检查證书鏈、SNI 與协议版本，確認 www 和裸域都正常。
- 對同一 URL 连續請求多次，观察响應時間波動和错誤出現的規律。
- 確認是否有 WAF、限流或地域規則命中蜘蛛。
- 把结果與訪問日誌對照，看蜘蛛請求是被正常记錄，還是在连接层就被断開。
抓取問题從下往上看，常常比從上往下看更快定位：先保證域名能解析、连接能建立、服務器能稳定回應，再去谈 Sitemap、内鏈结构和内容质量。