应使用307或308替代301/302重定向以保留post方法；修正proxy_pass斜线匹配；禁用rewrite/if导致的外部重定向；检查日志格式及第三方插件干扰。
核心是避免使用 301/302/303 这类会强制客户端改用 GET 的重定向状态码。Nginx 默认的永久跳转或配置不当的 rewrite，正是 POST 变 GET 的常见源头。
优先用 307 或 308 替代 301/302
HTTP 标准规定：301、302、303 响应后，客户端必须将后续请求改为 GET（除非手动处理）。而 307 和 308 明确要求保留原始方法和请求体。
- 把 HTTP 强制跳转 HTTPS 的配置从
return 301 https://$host$request_uri;改为：return 307 https://$host$request_uri; - 若需永久跳转，用
return 308，语义更准确，兼容性也已普遍支持 - 注意：307/308 是“重定向给客户端”，由客户端重新发起原样请求，因此后端日志中会看到两次记录（一次原始 POST，一次重定向后的 POST）
检查 location 路径与 proxy_pass 的斜线匹配
路径末尾斜线不一致会触发内部重定向，间接导致方法变更。这不是显式 return，但效果类似。
- 错误写法：
location /api { proxy_pass http://backend/; }
→ Nginx 会把/api/test改写成/api/test/再转发，可能引发 301 - 正确写法（保持路径结构）：
若后端期望/test，就写proxy_pass http://backend;（无结尾斜线）
若后端期望/api/test，且 location 是/api，就写proxy_pass http://backend/;（有结尾斜线）
禁用不必要的 rewrite 或 if 判断
任何触发外部重定向（即响应头含 Location 且状态码为 3xx）的逻辑，都可能让 POST 消失。
- 避免在 location 中对 POST 请求做
rewrite ... redirect或return 302 - 不要用
if ($request_method = POST) { return 302 ... }这类写法——它本质仍是重定向 - 如需按方法分流，直接用
proxy_method POST+ 正常 proxy_pass，不经过重定向环节
确认日志是否真实反映请求方法
有时问题不在转发逻辑，而在日志误判。
- 检查 access_log 格式是否包含
$request_method，例如：log_format main '$remote_addr - [$time_local] "$request" $status "$request_method"'; - 排除宝塔等面板插件、WAF 或自定义 Lua 脚本干扰——它们可能悄悄修改了
$request_method变量 - 用 curl 测试（绕过浏览器缓存）：
curl -X POST http://your-domain.com/path -d "a=1"，观察实际返回和日志
