發現只是第一步，连接成功才算入场
URL 發現的鏈條通常是：入口暴露地址、抓取系統记錄到待抓队列、建立连接、获取响應、解析内容。前两步顺利，不代表後面也顺利。很多站点看到站点地图里的地址已经“被發現”，却迟迟没有抓取记錄，問题往往不在連結结构，而在连接层。
抓取系統在調度时會先確認目标地址是否可连接。DNS 解析失敗、TLS 握手失敗、连接超时都會让這次抓取直接失敗，地址重新回到队列里等下一轮。次數多了，調度频率會被压低，新地址的入场時間随之被拉長。
DNS 层面的三類常见問题
- 解析失敗或不稳定：授權服務器响應慢、丢包，導致部分抓取节点拿不到 IP。表現是間歇性失敗，而不是彻底抓不到。
- 解析结果不一致：多地解析到不同 IP，其中某些节点指向未部署的舊服務器，返回 502 或直接超时。
- CNAME 鏈過長或指向失效目标：CDN 切換、域名迁移後遗留的 CNAME 记錄没有清理，解析鏈路中途断掉。
排查时不要只在自己常用的網絡环境里測試。用多個公共解析点分別查询，比對返回的 IP 集合是否一致，並確認每個 IP 都能正常响應。
TLS 與證书：握手失敗等于门没開
證书過期、證书鏈不完整、缺少中間證书，都會让抓取端的 TLS 握手失敗。這類問题在浏览器里可能被“繼續訪問”掩盖，但抓取程序通常不會绕過。
- 證书到期時間要有监控和提前提醒，不要等出問题再續。
- 检查是否只在部分节点部署了證书，邊缘节点配置不一致。
- HTTP 與 HTTPS 混用、跳轉規則混乱时，容易形成循环，抓取在握手和跳轉之間反复消耗。
超时、5xx 與内容截断
服務器响應慢到超過抓取端的等待阈值，這次請求就作废。稳定返回 5xx 同样如此。更隐蔽的是响應被截断：连接建立了，但返回的 HTML 不完整，連結解析不到位，下一頁地址就發現不了。
抓取系統會根據服務器反馈調整节奏。错誤率高、响應慢的站点，抓取频率會被主動降低，待抓队列里新地址的相對優先級下降，表現出来就是“發現很久了還没抓”。
把连接层問题当成連結结构問题去改内鏈，往往白費力气。先確認每次抓取請求能否稳定拿到完整响應，再谈路径優化。
容易被忽略的中間层
- WAF 與防護規則：誤拦正常抓取請求，返回 403 或驗證頁面，地址虽被發現却拿不到内容。
- CDN 缓存策略：缓存了错誤頁或舊版本頁面，抓取端拿到的是過期响應。
- 负载均衡配置：部分後端节点異常，導致同一地址时而正常时而失敗。
- 限流規則過紧：正常抓取被判定為異常流量而拒绝。
把连接层纳入日常检查
- 在服務器日誌里按狀態碼統計，区分 2xx、3xx、4xx、5xx 與超时的比例，观察趋势而不是單点。
- 定期用多個解析点驗證 DNS，確認返回 IP 一致且可用。
- 設定證书到期提醒，並在更換 CDN 或服務器後复查證书鏈。
- 检查防護與限流規則，確認搜尋引擎的抓取請求不會被誤拦。
- 出現“已發現未抓取”堆积时，先按连接层顺序排查，再考虑提交方式和站点结构問题。
URL 發現和抓取是一整條鏈路，任何一环不稳定都會拖慢终点。把 DNS、TLS、超时和中間层纳入例行巡检，通常比反复調整内鏈更能解决新地址迟迟不進场的問题。具体抓取表現仍以各搜尋引擎的實际行為為准，建议结合日誌和官方工具的資料做判断。