nginx 缓冲区过小会导致响应体截断，引发白屏等问题；应比对 curl 获取的响应长度与后端实际内容大小，重点调大 proxy_buffer_size、proxy_buffers 和 proxy_busy_buffers_size 参数。
页面加载不全，比如白屏、JS/CSS 加载中断、HTML 截断、gzip 解压失败或浏览器提示“下载文件”而非渲染，很可能是 Nginx 缓冲区配置太小，导致响应体被截断——尤其在 HTTPS 或大资源场景下更易触发。排查要聚焦“响应是否完整到达客户端”，而不是只看日志有没有报错。
查响应体是否真实截断
这是最直接的判断依据：对比浏览器实际收到的字节数与后端应返回的原始内容大小。
- 用 curl -s URL | wc -c 获取 Nginx 返回的响应体长度（不含响应头）
- 对静态 .gz 文件，执行 wc -c /path/to/file.html.gz 得到原始压缩包大小；对动态接口，可临时在后端打日志输出 Content-Length 或 body 长度
- 两者不一致 → 响应被截断；若 curl 结果明显偏小（如 32768、65536 等整数倍），大概率是缓冲区满后提前终止
- 补充验证：用 tcpdump + Wireshark 抓本地回环流量，观察 TCP payload 是否在固定边界（如 4KB/8KB）突然结束
核对关键缓冲区参数是否过小
Nginx 默认缓冲能力仅约 32KB，远不足以承载现代前端资源（单个 JS/CSS 常超 1MB）。HTTPS 因加解密开销，更容易暴露瓶颈。
- proxy_buffer_size：专存响应头，含 Cookie、CSP、Vary 等关键字段；默认 4k–8k 易被大 Header 撑爆 → 建议设为 128k
- proxy_buffers：存响应体，格式为 “数量 大小”；默认 8 4k = 32KB → 建议调至 32 128k（共 4MB）
- proxy_busy_buffers_size：控制忙时可发送的最大缓冲量；默认常为 8k–16k → 应设为与单 buffer 大小一致，如 128k
- 若确认是流式大文件（如视频、报表导出），且并发可控，可临时关缓冲：proxy_buffering off;（慎用，会增加内存与连接压力）
确认 gzip_static 是否生效且不被缓冲干扰
启用 gzip_static on 后，Nginx 直接返回 .gz 文件，但若缓冲区不足，仍会只发半截压缩流，浏览器无法解压。
- 检查 .gz 文件是否存在、权限可读：ls -l /path/to/index.html.gz
- 确认 gzip_static on 写在对应 location 块内（非仅 http 块），否则不生效
- 用 curl -I URL 查响应头：必须同时有 Content-Encoding: gzip 和正确 Content-Length
- 若 Content-Length 正确但页面仍白屏，说明压缩体被截断 → 优先调大 proxy_buffers，而非关 gzip_static
结合日志与响应头交叉验证
错误日志未必报错，但响应头和自定义日志能暴露线索。
- 开启调试日志：log_format full '$remote_addr "$request" $status $bytes_sent $upstream_http_content_length';，对比 $bytes_sent 与 $upstream_http_content_length 是否一致
- 检查 error.log 中是否有 "upstream sent too big header" 或 "client intended to send too large body" 类提示
- 若使用 proxy_cache，观察 $upstream_cache_status 是否长期为 MISS 或 BYPASS —— 缓冲截断会导致缓存逻辑根本未执行
