Nginx本身不会主动将POST改为GET，问题通常源于上游组件（如CDN、负载均衡器）或重定向（如301/302）导致方法变更；需通过debug日志确认原始请求行，并排查log_format、proxy_method指令及重写规则。
这通常不是 Nginx 自身把请求方法“改成”GET，而是上游（如反向代理、CDN、负载均衡器或客户端）发送过来的请求本来就是 GET，Nginx 忠实记录了它。排查重点应放在：谁改了方法？在哪一环丢失了原始 method？
检查 Nginx 是否真的收到非 GET 请求
最直接的方式是开启 debug 日志，确认 Nginx worker 进程接收到的原始请求行：
- 在 nginx.conf 的 events 或 http 块中临时添加：
error_log /var/log/nginx/debug.log debug; - 重启 Nginx（或 reload），复现一次 POST/PUT 等请求
- 查看 debug.log 中类似这样的行：
*1001 http request line: "POST /api/login HTTP/1.1"
如果这里已经是"GET /..."，说明问题出在 Nginx 之前；如果是正确的 POST，但 access_log 里写成了 GET，才需查日志格式配置
核对 access_log 中的 $request_method 变量是否被覆盖
Nginx 默认 access_log 格式中 $request_method 是只读变量，但以下情况可能导致它“失效”：
- 自定义 log_format 里误用了其他变量（比如写成
$request再截取，或错误引用了重写后的变量） - 使用了
proxy_set_header或fastcgi_param并意外覆盖了内部 method（极少见，但某些定制模块可能干扰） - 检查你的 log_format 定义，确保是标准用法：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent ...';
其中$request包含方法+路径+协议，而$request_method单独提取方法——两者都应一致反映原始请求
排查上游组件篡改请求方法
这是最常见原因，尤其在有 CDN、WAF、API 网关或前端代理时：
- CDN（如 Cloudflare、阿里云 DDoS 防护）：部分免费层或缓存策略会将非 GET/HEAD 请求自动转为 GET（尤其当未正确设置缓存规则或 origin 配置不支持 POST 时）
- 四层/七层负载均衡器（如 AWS ALB、Nginx Ingress Controller）：ALB 默认会对健康检查或某些错误响应降级为 GET；Ingress 若配置了 rewrite 或 proxy_redirect，也可能间接影响
-
浏览器或客户端行为：302 重定向后，浏览器对 POST 响应的重定向默认会改用 GET（符合 RFC）；检查响应头是否有
Location+ 302/303 - 可在 Nginx 的 server 块中加一行临时日志：
add_header X-Real-Method $request_method always;
然后用 curl 或浏览器开发者工具看响应头，对比服务端收到的 method 和客户端看到的是否一致
验证应用层是否主动修改了 method
虽然 Nginx 不改 method，但若你用的是 FastCGI（PHP）、uWSGI 或 proxy_pass 到后端，要确认：
- 后端框架（如 Django、Spring）是否因配置（如
SECURE_PROXY_SSL_HEADER或信任的 X-Forwarded-* 头）误判并重写了 request method - Nginx 中是否错误设置了
proxy_method GET;（该指令极少用，但一旦存在就会强制改写）——全局搜索配置文件排除此可能 - 检查是否有
if ($request_method != GET) { rewrite ... }类重写规则，且未终止流程（例如漏写 break 或 return），导致后续逻辑异常
