OPTIONS预检易受Nginx缓冲机制影响，因其响应极短，而默认proxy_buffering可能误判需等待更多数据，导致延迟、超时或卡住连接；应通过map指令按方法关闭缓冲、强制HTTP/1.1、收紧缓冲区参数，并确保CORS头正确返回。
当Nginx作为反向代理处理前端发起的跨域请求（尤其是带自定义Header或非简单方法如PUT/DELETE）时，浏览器会先发送一个OPTIONS预检请求。若Nginx未正确配置缓冲区行为，该预检可能被阻塞、超时或返回错误响应，导致后续真实请求根本不会发出。
为什么OPTIONS预检容易被Buffer机制影响
Nginx默认对代理请求启用缓冲（proxy_buffering on），它会暂存后端响应再整块转发给客户端。但OPTIONS预检通常极短（响应体为空，仅含状态码和CORS头），若后端响应速度慢、或Nginx因缓冲策略等待更多数据（如误判需等chunked body），就会人为引入延迟甚至超时。更常见的是：后端服务未明确返回Content-Length: 0或Transfer-Encoding: chunked，Nginx缓冲模块可能持续等待“结束信号”，卡住整个连接。
关键缓冲相关配置与推荐设置
针对预检请求，应主动控制缓冲行为，避免默认策略干扰：
-
关闭OPTIONS请求的缓冲：用
map指令识别请求方法，在location中按需关闭：map $request_method $proxy_buffering_flag {<br> OPTIONS off;<br> default on;<br>}
然后在proxy location中写：proxy_buffering $proxy_buffering_flag; -
强制清空缓冲并立即发送：对OPTIONS添加
proxy_buffering off;的同时，加上proxy_http_version 1.1;和proxy_set_header Connection '';，防止HTTP/1.0兼容逻辑干扰 -
限制缓冲区大小与数量：即使开启缓冲，也应收紧限制，例如：
proxy_buffer_size 4k;、proxy_buffers 8 4k;、proxy_busy_buffers_size 8k;，避免小响应被过度缓存
配合CORS头确保预检真正通过
仅调缓冲不够——预检响应必须包含合法CORS头，否则浏览器仍拒绝后续请求：
- 后端需返回
Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers等；若Nginx代为注入，用add_header（注意：需加always参数，否则2xx以外响应不生效） - 对OPTIONS响应，显式设置
add_header Access-Control-Allow-Origin "*" always;、add_header Access-Control-Allow-Methods "GET, POST, OPTIONS, PUT, DELETE" always;等 - 确保
add_header写在location块内，且优先级高于后端返回的同名头（Nginx默认覆盖后端头）
验证与调试技巧
快速确认是否为缓冲问题：
- 用
curl -v -X OPTIONS http://your-api/path观察响应时间与headers，对比直接访问后端服务的耗时 - 开启Nginx debug日志（
error_log /path/to/log debug;），搜索proxy buffering、http proxy关键词，看是否出现waiting for next request或buffer is full类提示 - 临时在location中加入
return 200 "OK";并配CORS头，绕过后端直测Nginx层是否能秒回OPTIONS——若此时正常，问题一定出在代理链路或后端响应格式
