从后端进程到对外入口的六步操作
以下流程以一台 CentOS 服务器、一个后端服务端口为基础示例。实际操作时只需替换 server_name、upstream 名称与端口。
-
1
确认后端进程与监听端口
事前检查在写 Nginx 配置前，先确认后端服务实际监听的地址与端口是否可用，避免把问题带到代理层。
ss -lntp | grep 8080 curl -I --max-time 5 http://127.0.0.1:8080/health如果本机访问返回 connection refused 或 000，需要先恢复后端服务，再继续反向代理配置。 -
2
定义统一 upstream 后端地址池
核心文件同一条业务如果会被多个 server 块引用，用 upstream 块单独定义后端。CentOS 7 默认仓库自带版本较旧，建议在完成 Nginx 官方源替换后再使用以下参数。
upstream ng_web { server 127.0.0.1:8080 weight=1 max_fails=2 fail_timeout=10s; keepalive 32; }weight 只作示例；生产环境若保持单后端，建议省略权重。max_fails 与 fail_timeout 需要根据后端实际恢复耗时调整。 -
3
编写 server 块并开启转发
proxy_passserver_name 替换为需要对外提供服务的域名；location / 把全部业务请求转交给 ng_web。
server { listen 80; server_name app.internal; access_log /var/log/nginx/app.access.log main; error_log /var/log/nginx/app.error.log warn; location / { proxy_pass http://ng_web; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }Host 头与 X-Forwarded-For 通常必须保留，不传递会导致后端日志记录错误来源或生成错误的站点跳转。 -
4
为 WebSocket 与长连接补充转发规则
Upgrade如果业务包含 WebSocket 或 SSE，Nginx 需要把 Upgrade 和 Connection 头保留下来。
map $http_upgrade $connection_upgrade { default upgrade; '' close; } location /ws/ { proxy_pass http://ng_web; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_read_timeout 3600s; proxy_send_timeout 3600s; }read/send timeout 需要结合心跳间隔调整。若业务本身有应用层心跳，可以设置成接近心跳周期的两倍。 -
5
校验配置并平滑重载
nginx -t配置修改完成后先执行语法校验，再通过 reload 让新配置生效。reload 会平滑处理，不中断已有连接。
nginx -t # 显示 test is successful 后执行 systemctl reload nginx避免直接执行 restart 或 stop 后再 start，那会产生短暂服务中断。若有多份 Nginx 实例，需要确认 reload 的对象是当前 master 进程。 -
6
部署验收与状态码定位
日志确认确认入口状态后，再去 Nginx access/error log 观察真实请求。如果出现 502、504、403、404，大方向可按下表判断。
tail -n 100 /var/log/nginx/error.log tail -n 100 /var/log/nginx/access.log502 优先查 backend 是否存活；504 优先看 upstream 超时；403/404 则核对 root、alias 或 proxy_pass 末尾路径是否改写过度。
写配置前确认这 4 个常见边界
反向代理大多数上线问题来自防火墙、URI 拼接、Header 透传与配置路径不一致。对照检查可以减少返工。
防火墙与安全组
代理入口端口需要在 Linux 防火墙与云安全组中同时放行，只放行其中一个仍会连接超时。
- 检查 80、443 端口监听状态
- 确认内网后端口不被外部直接访问
- reload 后测试从客户端实际访问入口
路径拼接规则
proxy_pass 末尾是否保留 / 会直接改变给后端的 URI。配置前先确认后端路由是否自带 /api 前缀。
- 带前缀路径建议先写一个小 location 验证
- 修改 path 后用 curl 观察实际回包
- rewrite 与 proxy_pass 不要同时处理同一段 URI
反向代理部署中的常见问题
问题按故障出现频率排列。回答中的验证命令都可以在 CentOS 7/8/9 默认 shell 中直接执行。
正向代理代表客户端向互联网发起请求，反向代理则代表后端服务器对外提供服务。Nginx 接收外部请求后按规则转发给内部 upstream，再把响应返回给客户端。因此从用户视角看，反向代理入口就是一个独立的服务端地址。
先执行 ss -lntp 查看 upstream 端口是否在监听，再用 curl 访问 upstream 地址并观察响应。端口正常则查看 Nginx error log，确认 upstream 是否在 fail_timeout 内被标记为不可用。常见原因还包括后端进程停止、文件句柄耗尽、keepalive 配置方向不匹配。
location /api/ 配合 proxy_pass http://ng_web; 会将完整 URI /api/xxx 交给后端。若写成 proxy_pass http://ng_web/;，Nginx 会用 / 替换匹配到的 /api/ 后再转发。需要依据后端实际路由是否携带 /api 前缀决定，改完后用 curl 实际请求一次接口。
先确认 nginx -t 读取的是当前服务实际使用的配置文件。部分环境通过不同 prefix 启动多份 Nginx，systemctl reload 只覆盖 systemd 管理的进程。使用 ps -ef | grep nginx 查看 master 进程数量，再结合 access.log 更新时间判断 reload 是否真正执行。
建议使用官方 Nginx 仓库或在备份现有配置文件后替换为更高版本 Nginx。官方仓库需要按 CentOS 7/8/9 选择对应 repo 路径，写入后执行 yum clean all 再重新安装 nginx。升级后用 nginx -V 核对编译参数与模块是否满足现有配置。
Get a reverse proxy deployment template ready to modify
拿一份可直接修改的反向代理部署模板
把 upstream 定义、server 块、Header 透传、WebSocket 规则与 reload 验证命令整理在同一份文档中。适合部署完成后留档，也适合下一次新建站点时快速套用。
