直接答案：最小反向代理要明确上游地址、传递给应用的 Host、客户端IP链、前端协议、超时和错误处理；WebSocket还需正确升级头。若外层还有CDN或负载均衡，只能信任已知代理传来的真实IP头，不能无条件接受客户端自带的 X-Forwarded-For。HTTPS终止在哪一层也必须写清。
本文于 2026 年 9 月按官方文档核对。命令和配置只展示判断方法，不代表可在任意生产环境直接复制；发行版、云平台、网络拓扑和业务写入不同，执行前必须确认对象、权限、备份和带外恢复入口。
专属资产：逐跳请求头验收表
| 现象/阶段 | 要判断什么 | 需要的证据 | 安全边界 |
|---|---|---|---|
| Host | 应用路由与生成链接 | $host或明确域名 | 防止上游收到错误主机名 |
| X-Forwarded-For | 经过的客户端/代理链 | 只信任受控代理 | 客户端可伪造同名头 |
| X-Forwarded-Proto | 外部HTTP或HTTPS | 应用生成安全链接 | TLS终止层要一致 |
| WebSocket Upgrade | 协议升级 | Connection/Upgrade映射 | 普通HTTP代理配置不足 |
| proxy timeout | 各阶段等待上限 | 结合应用SLA | 无限加大掩盖慢请求 |
这张表要求每个结论至少有两个相互独立的证据，例如“服务监听+外部连接”“设备延迟+业务耗时”“备份文件+隔离恢复”。单一控制台绿灯、单次截图或一个User-Agent都可能误导，不能作为完成依据。
为什么常见的一键处理容易失败
运维问题通常跨越控制台、操作系统、应用和外部依赖。重启、全放行、清缓存或重装会改变多个变量，并可能清掉最有价值的现场。正确顺序是先定时间线和影响范围，再确认最靠近故障的证据层，最后做可回滚的最小动作。
对于有数据库、订单、表单、队列或用户上传的站点，还要先判断当前是否仍在写入。回滚旧快照、切回旧主机或恢复旧数据库前，必须处理变更期间的新数据；否则技术状态恢复了，业务数据却可能倒退。
六步安全执行流程
1. 确认对象与基线
画出客户端、CDN/负载均衡、Nginx、应用和数据库，每一跳标记HTTP/HTTPS、端口、DNS名和可见来源IP；路径不清时不要先复制配置片段。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
2. 保留恢复入口
建立命名 upstream，并先从Nginx主机用curl访问健康检查。上游若只监听127.0.0.1、Unix socket或私网地址，proxy_pass必须与实际一致。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
3. 取得直接证据
设置 Host、X-Real-IP、X-Forwarded-For 和 X-Forwarded-Proto，并配置real_ip可信来源；外层代理IP范围变化时应有维护流程。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
4. 只做最小变更
WebSocket使用HTTP/1.1和条件化Upgrade/Connection头，测试握手101、长连接、重连和代理重载；普通页面200不能证明WebSocket可用。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
5. 验证业务与副作用
分别设置连接、发送和读取超时，记录$request_time与$upstream_response_time。出现502/504时先区分连接失败、上游超时和应用错误。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
6. 重启或跨峰复验
用nginx -t检查语法，平滑reload并保留旧配置；验收Host、协议、真实IP、重定向、上传、WebSocket、错误页和日志，失败立即恢复上一配置。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
不应直接照做的五种处理
- 无条件信任任意X-Forwarded-For
- proxy_pass末尾斜杠导致路径变化
- 把超时统一调到很大
- 只测首页不测上传和WebSocket
- 改配置前没有nginx -t和备份
这些做法并非永远错误，而是缺少适用条件。若确需执行，应在变更单中写清目标、影响范围、停止阈值、备份位置、回滚命令和预计恢复时间；高风险动作先在副本或小流量上演练。
回滚触发与数据边界
出现核心写入失败、持续5xx、管理员入口丢失、数据校验不一致、尾延迟越过停止阈值或监控失明时，应停止继续扩大变更。回滚前确认新旧环境各自产生了哪些写入，保留日志和配置差异；回滚后用相同请求和同一时间窗口重测，而不是只看首页恢复。
如果故障根因尚未确认但必须先恢复服务，可以采用限流、摘除单节点、恢复上一配置或临时切流等缓解措施，并明确它只是临时处置。恢复后仍要完成根因分析和复发验证，不能把“重启后正常”写成最终原因。
验收清单
- [ ] 上游健康检查200
- [ ] Host与应用路由一致
- [ ] 真实IP不可被客户端伪造
- [ ] 外部协议识别正确
- [ ] WebSocket握手101
- [ ] 上传与大响应正常
- [ ] 错误与上游耗时可查
- [ ] reload失败可回滚
验收应由另一位维护者按记录复现至少一项关键检查，并覆盖重启、真实高峰或等价受控负载。所有失败项都记录实际值与时间，不使用“基本正常”“应该没问题”作为关闭条件。
相关资料与隔离测试入口
站内可继续参考502/504排查、服务器正常网站打不开、端口不通排查。需要搭建副本验证配置时，可查看美国轻量云和美国弹性云服务器的实时规格；先确认库存、价格和适用条件，不把测试环境当备份或生产容灾。
常见问题
proxy_pass后要不要带斜杠？
它会影响URI替换语义，不能凭习惯添加。根据location和期望上游路径写测试，用包含子路径、查询参数和编码字符的请求验证。
为什么应用拿到的都是127.0.0.1？
直连上游时源地址确实是代理；需要通过受信头传递并在应用中配置可信代理，不能相信所有请求头。
HTTPS一定要回源HTTPS吗？
取决于网络边界和威胁模型。公网或不可信网络建议加密；即使内网明文，也要明确证书终止和X-Forwarded-Proto。
502和504有什么区别？
502常见于连接失败、协议或无效响应，504表示代理等待上游超时。应结合错误日志和upstream时间，不靠状态码单独猜。
Nginx reload会断开连接吗？
平滑重载通常让旧worker处理已有连接，但长连接、配置错误和资源限制仍需测试；先nginx -t并监控新旧worker。