网站工具：一次全站扫描被中断后怎样判断已覆盖范围

📍 WDQWDWQD987AAAAA:216.73.216.206
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /62b8717c9e9d.html
📄

网站工具：一次全站扫描被中断后怎样判断已覆盖范围

先看扫描工具留下了什么可核对的记录，再决定是保留现有结果、补扫一部分，还是全部重跑。如果工具只给了一个总数，没有逐页状态或时间戳，那么中断后最稳妥的做法通常不是接着跑，而是把这次结果降级为线索，重新规划扫描范围。判断的关键不在“跑了多久”，而在“哪些页面有明确完成证据”。

先分清三种中断，它们对应的覆盖结论不同

同样是中断，原因不同，已有结果的可用程度差别很大。可以先按下面三类归档：

只有第一类可以较放心地保留。第二类需要找到最后一条完整记录，第三类基本要按新配置重跑，或者把改动前后的结果分开存放、分开解读。

用“完成标记”而不是“进度条”判断覆盖到哪里

进度条反映的是工具自己的估算，中断后往往停在某个百分比，但这个数字不能证明任何具体页面被处理过。真正能作为依据的是逐条记录里的完成标记，常见的有以下几种，具体字段名称要按你所用工具的导出结果核对：

  1. 每个网址是否有一条带时间戳的结果行。
  2. 该行是否包含状态码、标题、可索引状态等至少一个实质性字段，而不是空白占位。
  3. 记录是按什么顺序写入的，是否呈现明显的连续区间。
  4. 是否有批次编号或分段标识。

操作上，先把结果导出为结构化文件，按时间戳或批次号排序，找到最后一条字段完整的记录，把它之前的部分视为候选已覆盖区。这一步的结果直接决定下一步：如果候选区能覆盖你关心的主要目录，就只需补扫剩余部分；如果记录稀疏、大量字段为空，补扫的成本可能接近重跑，此时重跑更省事。

样本正常不代表全站正常，边界要单独验证

一个容易踩的坑是：抽查几个页面，发现数据都对，就认为已覆盖部分整体可信。这在规模化后经常不成立，因为中断往往不是均匀发生的。假设一次扫描按目录顺序推进，前几个栏目记录完整，后面某个栏目因为单页超时反复重试，拖慢了整体进度并最终导致中断。此时你抽查的恰好是前面正常的栏目，结论就会偏乐观。

比较可靠的做法是分层抽样，而不是随机抽样：

如果接近中断点的记录开始出现空字段、重复写入或状态缺失，说明边界比时间戳显示的更靠前，应把这段整体划入未覆盖区。这个动作会直接改变补扫的起点，避免把半成品当成已完成。

保留、改写还是退出：三种取舍的适用前提

保留适用于：中断属于计划内暂停，批次边界清晰，且抽样验证通过。此时可以沿用已有结果，只对未覆盖区发起新一轮扫描，最后按同一口径合并。合并前要确认两轮使用的配置一致，否则合并出来的数据会混入两套标准。

改写适用于：结果大体可用，但边界模糊或存在少量半成品记录。做法是保留候选区，剔除边界附近的不可信记录，把起点向后推一段再补扫。代价是会有少量页面被重复处理，但换来的是边界更干净。适合页面量较大、整体重跑时间成本高的情况。

退出适用于：中断由中途改配置引起，或记录稀疏到无法划出可信边界。此时继续在旧结果上叠加，只会让口径越来越乱。直接按当前配置重跑，并把旧结果单独存档备查，比反复修补更可控。

这三者不是必须依次尝试的流程，而是根据证据强度选一个。证据不足时，倾向于退出重跑，通常比在模糊边界上继续投入更省后续核对成本。

中断后还要检查的一个隐藏变量：限速与重试

有些中断并非工具本身的问题，而是目标站点在扫描过程中开始限速或拒绝连接。这种情况下，即使你准确划出了覆盖边界，直接补扫剩余部分也可能再次被中断。判断方法很简单：看中断点附近的记录里，是否集中出现超时、连接被拒或状态码异常。如果是，先降低并发或放慢请求节奏，再决定补扫范围。否则你会在同一个位置反复中断，覆盖范围永远停在同一个边界上。

需要说明的是，抓取量突然下降或某段时间记录为零，并不能单独证明是限速造成的，也可能是目标站点临时不可用、工具自身出错或网络波动。要结合中断点前后的状态码分布一起看，再决定是调整节奏还是排查其他原因。

最后提醒一点：不同工具对“已完成”的定义和导出字段并不相同，上面提到的字段名称和批次标识需要以你实际使用的工具为准。在依赖任何覆盖结论之前，先用一小段结果验证该工具的记录是否真的逐页可核对，这一步比事后补救更省时间。

图1 图2
nginx