proxy_buffering 与 proxy_cache 可协同工作：前者控制响应体收发，后者决定整条响应复用；需保持 proxy_buffering on 以确保缓存生效，并调优缓冲参数与缓存策略实现秒级返回。
proxy_buffering 和响应缓存（proxy_cache）不是互斥关系，而是可以协同工作的两层机制：前者控制 Nginx 如何收发响应体，后者决定是否复用已缓存的整条响应。要让二者配合加速 API 返回，核心是——在开启 proxy_buffering 的前提下，让缓存命中时跳过缓冲等待，直接高效吐出内容；同时避免因缓冲配置不当导致缓存失效或延迟升高。
保持 proxy_buffering on 是缓存生效的基础
proxy_cache 默认只对完整响应起作用，而完整响应的前提是 Nginx 已接收完后端返回的数据。若设为 proxy_buffering off，Nginx 边收边转，无法确定响应是否结束，会导致：
- proxy_cache 不生效（多数版本下直接跳过缓存逻辑）
- 无法修改响应头（如添加
X-Cache-Status） - 无法做 gzip 压缩等后处理
所以对普通 RESTful API，应保持默认或显式设置：proxy_buffering on;
调优缓冲参数，避免缓存“卡住”首字节
即使启用缓存，如果 proxy_buffers 太小或 proxy_buffer_size 不足，Nginx 可能在等待响应头/体填满缓冲区时引入额外延迟，尤其对小响应（如 JSON {“code”:0}）。建议：
-
proxy_buffer_size 4k;—— 足够容纳绝大多数响应头（含 Set-Cookie、自定义认证头等） -
proxy_buffers 8 16k;—— 总内存约 128KB，兼顾吞吐与内存占用；不盲目堆大，避免小响应被“攒着不发” -
proxy_busy_buffers_size 32k;—— 允许部分缓冲区在发送中仍可接收新数据，提升流式友好度
缓存配置需绕过缓冲干扰，确保命中即快
以下配置能防止常见陷阱，让缓存真正“秒出”：
- 用
proxy_cache_use_stale updating;：当缓存即将过期时，Nginx 在后台异步刷新，前台仍立即返回旧缓存，避免用户等待新响应生成 - 加
proxy_cache_lock on;和proxy_cache_lock_age 5s;：防止多个相同请求同时击穿到后端，首个请求建缓存，其余排队拿现成结果 - 禁用干扰头：
proxy_ignore_headers Cache-Control Expires Set-Cookie;—— 防止后端错误返回no-cache或private导致缓存被跳过 - 显式声明缓存键：
proxy_cache_key "$scheme$request_method$host$request_uri";—— 排除 Cookie、Authorization 等变量影响（若接口无状态），避免缓存碎片
验证是否真在“缓存+缓冲”协同工作
上线后通过响应头快速确认：
- 命中缓存：
X-Cache-Status: HIT，且响应时间稳定在 5–20ms（不含网络） - 后台刷新中：
X-Cache-Status: STALE，说明updating生效 - 检查
Content-Length是否存在且合理 —— 若缺失或为 chunked，可能是缓冲未生效或后端强制流式输出
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
