Apache 支持断点续传需满足：正确处理 Range 请求并返回 Accept-Ranges: bytes、Content-Range 等规范响应头；日志中仅见 206 不足为凭，须结合 Range 请求头与 Content-Range 响应头验证；curl 测试和后端（如 Java/Tomcat）配合配置是关键确认手段。
Apache 日志中出现大量 206 Partial Content 状态码，通常表明客户端（如浏览器、下载工具、播放器）正在发起范围请求（Range Request），服务端也成功响应了部分内容——这是断点续传和流媒体播放的典型行为。判断 Apache 是否真正支持断点续传，不能只看 206 状态码是否存在，而要看它是否**正确处理 Range 请求并返回符合规范的响应头**。
确认 Apache 是否启用了范围请求支持
Apache 默认开启对 Range 请求的支持（由 mod_headers 和核心逻辑保障），但以下情况会导致 206 不生效或退化为 200：
- 静态文件被代理（如经过 Nginx 或 CDN）且未透传
Range头或未配置Accept-Ranges - 文件由 CGI/PHP/Servlet 动态生成，且代码未手动设置
Accept-Ranges: bytes和处理Range头 - 启用了压缩模块（
mod_deflate）但未配置DeflateFilterNote，导致 Range 响应被错误压缩（Apache 2.4.10+ 已修复，旧版本需注意） - 使用了不支持 Range 的存储后端（如某些 WebDAV 或自定义 handler）
从日志中识别有效断点续传行为
Apache 默认 combined 日志格式中，状态码在第 9 字段，但仅看 206 不够。需结合 Request 和 Response Headers 判断是否真实支持：
- 检查日志中该请求的
Request-Line是否含Range: bytes=xxx-yyy（需开启%{Range}i自定义字段记录） - 确认响应中包含
Content-Range: bytes xxx-yyy/total（可用%{Content-Range}o记录） - 观察同一文件是否被多次以不同 range 请求（如
0-1023、1024-2047），且响应状态均为 206 - 对比相同 URL 的 200 和 206 请求比例：若大文件下载中 206 占比高、且无重复全量 200，则说明客户端成功复用连接续传
验证与排查建议
不依赖日志猜测，直接测试更可靠：
立即学习“Java免费学习笔记（深入）”；
- 用
curl -v -H "Range: bytes=0-999" http://yourhost/file.zip查看响应头是否含HTTP/1.1 206 Partial Content、Accept-Ranges: bytes、Content-Range和正确Content-Length - 用
curl -I http://yourhost/file.mp4检查首响是否有Accept-Ranges: bytes—— 这是客户端决定是否发起 Range 请求的关键依据 - 若使用 Tomcat + Apache（mod_jk/mod_proxy_ajp），确保 AJP 协议未丢弃 Range 相关 header（需在
JkOptions中启用+ForwardKeySize +ForwardURICompatUnparsed） - 对 Java 应用（如 Spring Boot 内嵌 Tomcat），确认资源处理器（
ResourceHttpRequestHandler）未被覆盖，且未禁用HttpRange支持
Java 后端配合要点
若 Apache 前置，后端 Java 服务需确保：
- 静态资源由容器原生支持（Tomcat/Jetty 默认支持 Range），避免用
FileInputStream手动读取却不设Content-Range - Spring MVC 中返回
ResponseEntity<resource></resource>时，框架会自动处理 Range；但若手动写入 OutputStream，必须解析Range请求头、设置状态码、响应头和对应字节段 - 使用
StreamingResponseBody或异步写入时，务必校验HttpServletRequest.getHeader("Range")并提前返回 206 及 headers，否则可能触发容器默认 200 响应 - CDN 或反向代理层需透传
Range、If-Range请求头，并缓存时区分带 Range 和不带 Range 的响应（避免 206 被缓存为 200）
