Nginx轮询不破坏幂等性但会放大后端重复处理风险，排查重点是日志中同一request_id是否打到不同upstream_addr，再验证后端是否真重复执行而非仅返回相同结果。
Nginx轮询本身不破坏幂等性，但会放大后端服务因无状态分发导致的重复处理风险——比如客户端重试时，两次请求被轮到不同节点，而各节点又未做全局去重，就可能重复扣库存、重复下单。排查重点不在Nginx配置本身，而在它如何暴露后端幂等缺陷。
看日志里有没有“同请求ID打到不同后端”的痕迹
在Nginx access日志中加入 $request_id 和 $upstream_addr，能直接关联一次请求与它最终抵达的后端节点：
- 修改 log_format：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_id $upstream_addr $upstream_response_time';
- 用 grep 提取同一 request_id 的多条日志：grep "req-abc123" access.log
- 若发现同一 request_id 出现在两条及以上日志中，且 upstream_addr 不同，说明该请求被重复转发（大概率是客户端重试 + Nginx轮询共同作用）
查后端是否真在“重复执行”，而非仅返回相同结果
幂等性不是“返回一样就行”，而是“执行多次，业务状态只变一次”。需确认后端行为：
- 检查数据库操作日志或审计表：同一订单ID是否插入了两条记录？同一支付流水是否生成了两个扣款动作？
- 观察下游依赖（如Redis、消息队列）：是否收到重复的幂等键（如 idempotent:order_123）写入或投递？
- 不要只信HTTP状态码——200响应下完全可能已误执行两次
验证Nginx是否无意绕过了幂等守门机制
有些幂等设计依赖请求头（如 X-Idempotency-Key）或 Cookie 绑定，而Nginx默认不透传或改写了关键字段：
- 确认 proxy_set_header 是否保留了幂等标识：proxy_set_header X-Idempotency-Key $http_x_idempotency_key;
- 检查是否启用了 proxy_buffering off 或 gzip on ——某些旧版后端在响应被压缩/缓冲时，无法正确解析原始请求体中的幂等参数
- 若用了 rewrite 或 internal 重定向，注意 $http_x_idempotency_key 可能丢失，需显式携带：rewrite ^/api/(.*)$ /v2/$1 break; proxy_set_header X-Idempotency-Key $http_x_idempotency_key;
模拟重试场景，观察全链路行为
用脚本主动触发典型重试模式，比等线上问题更可控：
- 构造带固定 X-Idempotency-Key 的请求，用 curl -H "X-Idempotency-Key: abc123" http://nginx/api/order，然后立刻再发一次（模拟超时重试）
- 同时 tail -f 后端各节点日志 + Nginx access.log，确认：key是否透传、是否落到同一节点、后端是否拒绝第二次执行
- 若第二次仍成功入库，说明后端幂等校验未生效（如Redis key过期、校验逻辑被跳过、事务隔离级别太低）
