发现只是第一步，连接成功才算入场
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、超时和中间层纳入例行巡检，通常比反复调整内链更能解决新地址迟迟不进场的问题。具体抓取表现仍以各搜索引擎的实际行为为准，建议结合日志和官方工具的数据做判断。