报错是这么冒出来的。站点日志里视频和 PDF 的请求大量返回 206，抓取报表却把这批算成失败，失败率显示 18%，实际打开文件都正常。
中间走过弯路，把「CDN 的回源日志和边缘日志状态码不一致」当成主因，改完现象没变。
真正麻烦的地方在于，几个原因的现象几乎一样。统计脚本只把 200 当成功，206 落进错误桶。也可能是蜘蛛带 Range 取分段内容，本来就不该返回 200。
还有一种情况，脚本按 Content-Length 判完整度，分段响应一律算异常。
第一件事是看 206 在日志里的条数
awk '$9==206' access.log | wc -l随后按状态码重新分类统计
awk '{print $9}' access.log | sort | uniq -c | sort -rn然后确认分段请求来自哪个 UA
awk '$9==206 {print $12}' access.log | sort | uniq -c | sort -rn | head末了把 200 和 206 都计入成功再出报表
grep -E ' (200|206) ' access.log | wc -l恢复的判定其实很直接。重新统计后失败率回到 2% 左右，206 的条数和视频、PDF 的请求量基本吻合。
补一句。206 是正常的分段响应，把它算失败会让抓取报表整体失真，日志口径要先按业务定清楚。这类问题最好一次改到位，反复小改反而容易把原因搅混。