核心是分清“头”和“体”再配参数：响应头超限调大fastcgi_buffer_size，响应体过大则合理配置fastcgi_buffers及busy_buffers_size等，并注意超时与流式适配。
核心是分清“头”和“体”，再按实测数据配参数，不是堆大数值。
先定位到底是响应头还是响应体被截
盲目调大所有 buffer 容易浪费内存、引发忙缓冲区卡死或 TCP 窗口收缩。必须先确认截断类型：
- 查错误日志：搜 upstream sent too big header → 响应头超限，问题在
fastcgi_buffer_size - 搜 upstream sent too big response 或 using temporary file → 响应体过大，问题在
fastcgi_buffers或磁盘缓存 - 用 curl 实测：运行
curl -s -w "\n%{size_download}\n" -o /dev/null https://your-site.com/page，对比后端直连返回字节数。明显偏短且无报错，大概率是响应体被截 - 看关键 header 是否完整：执行
curl -I https://your-site.com/page，检查Set-Cookie、Location、X-Debug-Info等是否缺失或不全
响应头太大 → 调大 fastcgi_buffer_size
这个参数只管状态行 + 所有 HTTP 头（不含响应体），默认 4k 在现代 PHP 应用中普遍不够，尤其带 JWT、多 Cookie、链路追踪头时：
- 从 error.log 中找到类似 header: 14280 bytes 的数字，取略大的 2 的幂值：14280 → 设
fastcgi_buffer_size 16k；21500 → 设32k - 该值必须 ≤
fastcgi_buffers中单块大小。例如用了fastcgi_buffers 8 32k，那fastcgi_buffer_size最大可设 32k；若只设了8 16k，就不能超过 16k - 写在
location ~ \.php$ { }块内，且位于fastcgi_pass之前
响应体太大 → 合理配置 fastcgi_buffers 及配套参数
目标是让典型页面（如后台首页、数据报表）的 HTML 或 JSON 尽量落在内存缓冲区里，避免刷磁盘拖慢解析：
- 根据实测响应体大小选组合：比如 curl 测出 dashboard 返回 218KB，则推荐
fastcgi_buffers 12 32k（总 384KB），或8 64k（总 512KB） -
fastcgi_busy_buffers_size必须设为单块 size 的 2 倍（如 32k → 64k），防止突发流量占满所有 buffer 导致阻塞 -
fastcgi_temp_file_write_size与 busy_buffers_size 保持一致（如都设 64k），避免小块频繁刷磁盘 -
fastcgi_temp_path对应目录需有读写权限，且磁盘空间充足；fastcgi_max_temp_file_size别设为 0，建议 1024m
别漏掉超时与流式适配
后端已发数据但 Nginx “停着不收”，常因缓冲区满导致 TCP 窗口收缩，表现为传输卡顿或中途断连：
-
fastcgi_read_timeout控制从 FastCGI 读取响应的总等待时间，建议 ≥ 300s（SSE、导出类接口可设 600s） -
fastcgi_send_timeout是向客户端发送数据的间隔超时，若后端每 30 秒 flush 一次，此值至少设为 45s - 确保
fastcgi_buffering on（默认开启，但 location 内可能被覆盖）
