表单数据不丢失的关键在于会话状态持续、请求可重试及后端幂等或恢复能力；Nginx 通过 proxy_next_upstream 智能重试、hash $cookie_JSESSIONID 会话保持、配合后端幂等接口与草稿保存实现保障。
表单数据不丢失，关键不在 Nginx 负载均衡本身，而在于**会话状态能否持续、请求能否重试、以及后端是否具备幂等或恢复能力**。Nginx 无法保存用户正在填写的 HTML 表单内容（那是浏览器内存里的东西），但它能通过合理配置，避免因后端故障导致提交中断、重复提交或跳转登录页——这正是“表单数据不丢失”的实际含义。
确保提交请求被正确重试而非直接失败
用户点击“提交”后若后端宕机，Nginx 默认会返回 502/504，浏览器清空表单或跳转错误页。要避免这种情况，需启用智能重试：
- 在
location块中配置：proxy_next_upstream error timeout http_502 http_503 http_504; - 搭配
proxy_next_upstream_tries 2;和proxy_next_upstream_timeout 3s;，限制最多重试一次其他节点，防止长等待 - 确保
proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout都设为较短值（如 3s/5s/8s），避免卡在故障节点上
绑定用户到稳定后端节点（会话保持）
如果后端未做 Session 共享，表单中间态（如草稿、临时 token、多步流程 ID）可能只存在某台服务器内存中。此时必须让同一用户的多次请求落到同一台机器：
- 优先用
hash $cookie_JSESSIONID consistent;（无需模块），比ip_hash更可靠，不受 NAT、代理影响 - 若后端用 Spring Boot + Redis Session，则根本不需要绑定——直接关闭所有 sticky 策略，改用
least_conn或轮询，靠共享存储兜底 - 禁用
ip_hash时务必确认：前端没 CDN/WAF 透传问题；后端已统一接入 Redis 存储 session
后端配合：支持幂等提交与草稿自动保存
Nginx 只是流量入口，真正防丢数据要靠后端设计：
- 表单提交接口加唯一请求 ID（如
X-Request-ID头），后端校验重复提交并返回原结果 - 前端在输入过程中定时 POST 草稿到 /api/draft（带用户标识），后端存入 Redis，Nginx 将这类请求固定路由或直连主库
- 提交失败时，前端捕获 502/504 并自动重发，或从本地 localStorage 恢复草稿
验证配置是否真起作用
别只看配置文件，动手测才放心：
- 停掉一台后端，用
curl -v -X POST http://nginx-host/form提交，观察是否自动打到另一台且返回 200 - 检查 Nginx error log 是否出现
upstream timed out后立刻切换，而不是挂住 30 秒 - 用浏览器开发者工具禁用 JS，手动填表单→断开某后端→点提交，确认不跳登录页、不报 502
