下载 2GB 的镜像中断后重试，客户端带了 Range: bytes=524288000-，服务端返回 200 和完整文件，又从零开始传，日志里没有 206。日志里能对上时间点，这种反而好排。
静态文件由应用自己读流输出，没有处理 Range 请求头，也不返回 Accept-Ranges，客户端不知道支持续传。有的反向代理还会把 Range 头丢掉，应用收到的就是普通 GET。这一点先确认清楚，后面就不用反复试。
curl -i -H 'Range: bytes=0-1023' https://dl.example.com/app.tar.gz
「断点续传」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。
报错里带路径的，先去看那个路径在不在、权限对不对。同一份配置存在多处的，先确认改的是被加载的那一份。
处理上按这个顺序：确认响应头带 Accept-Ranges: bytes 并且支持 Range 解析；返回 206 时带上 Content-Range 和正确的 Content-Length；代理层打开 Range 透传 别在缓存规则里把它过滤掉；拿大文件在弱网下断三次 每次确认续传起点正确。
结果对不对很好判断，响应状态是 206 Content-Range 显示 0-1023/2147483648 断点续传从指定位置继续。