Nginx 默认不重试POST等非幂等请求，但配置中若含non_idempotent、http_500或4xx状态码，或启用请求体缓冲，将导致意外重试；应全局删除non_idempotent，显式关闭重试并配合后端幂等防护。
直接禁用 POST 等非幂等请求的自动重试，关键不是“加限制”，而是“默认关死 + 显式排除”。Nginx 本身对 POST/PUT/DELETE 默认不重试，但一旦配置不当（比如误启 non_idempotent、混用老版本或开启请求体缓冲），就会悄悄触发重复提交。
彻底清理 non_idempotent 配置
这是最常被忽略的隐患点。只要 upstream 或 location 块里出现 proxy_next_upstream ... non_idempotent，就等于主动打开非幂等请求重试开关——哪怕只写了一次，也会生效。
- 全局搜索配置文件，删掉所有
non_idempotent字样 - 检查每个
upstream和location块，确认proxy_next_upstream后只包含安全项：error timeout http_502 http_503 http_504 - 特别注意不要带
http_500或任意http_4xx，这些状态码对已发送的 POST 不应触发重试
显式关闭重试并锁定方法语义
别依赖“默认不重试”，要主动关死。尤其当业务路径明确为写操作时，用 location 匹配路径比靠方法判断更可靠。
- 对写接口路径（如
/api/order、/v1/user）单独配置：proxy_next_upstream off;proxy_buffering off;（避免响应缓存干扰判断） - 若需兼容部分 POST（如日志上报），不通过 Nginx 重试，而是由客户端透传
Idempotency-Key，后端做幂等校验 - 禁止用 GET 携带写参数（如
GET /delete?id=123），这类请求即使幂等性成立，也违背 REST 语义，易被误配重试
验证是否真禁用了重试
光改配置不够，得看实际行为。重点观察三类场景：
- 后端返回 500 时：Nginx 应直接返回 500，而不是切到另一台节点
- 后端连接超时（timeout）时：仅在请求体尚未发出阶段才可能重试；若 body 已发，Nginx 会放弃重试——这是设计保障，不是 bug
- 用 curl 模拟 POST 并故意让某台 upstream 返回 502：确认 Nginx 日志中没有
upstream: [next]类记录
配合后端做兜底防护
Nginx 层禁用重试是第一道防线，但不能替代业务层防护。尤其当存在客户端重试、网络抖动或运维误操作时，仍需双重保险。
- 所有写接口强制要求客户端提供
Idempotency-Key请求头，并在服务端用 Redis 或 DB 记录该 key 的执行状态 - 数据库关键字段加唯一索引（如订单号、支付流水号），让重复插入直接报错而非静默成功
- 对上传类大请求体接口，额外加
client_max_body_size限制，并确保proxy_request_buffering off不被启用——否则可能因缓存导致重试时重复发包
