Nginx反向代理本地Web应用

反向代理把域名请求转发给已经运行的Web应用。本文以Ubuntu 24.04 LTS发行版Nginx为例，上游是127.0.0.1:3000的普通HTTP服务，根路径发布，不涉及WebSocket或子路径改写。先按应用官方说明启动服务，不把临时开发服务器当生产部署。产品必须允许该用途，住宅云不能用于建站。

前置操作见Ubuntu安装Nginx并发布静态网站；面板及容器管理的Nginx不能套用本文目录。

先确认应用自身能回答请求

sudo ss -lntp
curl -i http://127.0.0.1:3000/

确认监听地址是127.0.0.1或符合设计的私网地址，并记录应用应返回的状态码和页面。某些应用根路径可能是404，应改用其明确提供的健康检查路径；不能先把上游404判断成Nginx故障。应用在本机都连不上时，先处理进程、端口和应用日志，不改公网规则。

建立域名对应的代理站点

先运行sudo nano /etc/nginx/sites-available/baole-proxy.conf，新建独立配置，在其中填入下方server块并保存。文件名已存在时先确认用途，不能覆盖正式配置。下面example.com必须改成你拥有的实际域名；已有同名域名站点时，在原站点配置内调整，不再新建重复server_name。

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        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;
    }
}

proxy_pass在这里不附加URI，保留原请求路径。带末尾路径的proxy_pass与location前缀组合可能改变转发URI，不能随意加斜杠后再假设路径不变。应用若根据代理头判断HTTPS或真实IP，应只信任你控制的代理来源，不能无条件信任任意客户端提交的X-Forwarded-*。

仅对本次新建文件建立启用链接；原站点内修改则跳过ln步骤。若链接已存在，先检查指向，不能直接覆盖。

sudo ln -s /etc/nginx/sites-available/baole-proxy.conf /etc/nginx/sites-enabled/baole-proxy.conf
sudo nginx -t
sudo systemctl reload nginx
curl -i --resolve example.com:80:127.0.0.1 http://example.com/

从本机、外网依次验证

1. 比较直连上游与经过Nginx的状态码和无敏感内容的健康页，确认命中的是同一个应用。
2. HTTP阶段只验证公开测试页，不发送登录密码、会话令牌或其他敏感资料。
3. 先为Nginx配置有效HTTPS，再验证登录、表单、静态资源及业务路径。应用生成的链接与跳转也要正确，不能只让浏览器看到HTTPS而忽略应用循环跳转。
4. 确认上游端口无需公网直连时，保持仅本机监听，并检查系统及产品访问规则没有多余开放3000。

出现502、504或跳转循环怎么办

回退时恢复原server块并检测后加载；如只是新建代理站点，可先停用该配置链接，保留应用数据。WebSocket、长连接和大文件另按应用要求设置，不能把此最小模板作为所有业务的通用配置。