Nginx 反向代理怎么配置？上游地址、请求头与路径转发
反向代理把域名入口与应用监听分开，便于集中管理 HTTPS 和访问日志。本文适用于 Ubuntu 24.04 上受维护的 Nginx，以及已经能正常响应 HTTP 的应用。示例假设 Nginx 与应用位于同一主机；容器、跨机部署需要替换实际网络地址。
先确认后端在什么位置提供服务
在服务器本地请求应用的已知只读页面，确认状态码和内容，再查看监听地址。若应用只供本机代理访问，优先监听回环地址，避免同时开放一个绕过站点入口的公网端口。需要跨机连接时，使用受控网络，并限制上游只接受代理节点的来源。
如果应用跑在容器里，先确认 Nginx 位于宿主机还是另一容器。每个容器都有自己的回环地址，不能因为宿主机能访问某端口，就认定代理容器也能访问。把“从哪里发起请求、到哪里监听”写清楚后，再调整站点配置。
为现有站点添加明确的代理路径
在已经配置好域名的 server 块内，按实际应用地址设置路径。下面代理整个站点，并显式传递应用常用的请求信息：
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;
}
应用端口和站点块都需要按本机环境替换。配置没有启用响应缓存，也不包含 WebSocket 升级设置；如果应用需要这些功能，应分别验证相应通道。代理指令的作用与可用上下文可查Nginx 代理模块。
注意 proxy_pass 末尾的路径区别
对于 location /api/，上游地址不带 URI 部分时，常见配置会保留原请求路径；上游地址写成带末尾 / 的形式时，匹配的前缀会被相应 URI 替换。例如后端实际只认识 /users，就要先决定外部 /api/users 是否应该去掉 /api/。
不要依靠反复加减斜杠碰运气。列出根路径、二级路径、带查询参数和不存在路径四个样本，对照后端日志观察实际收到的地址。有正则 location、rewrite 或变量代理地址时，规则会更复杂，应按实际配置单独检查。
代理头必须有可信来源
应用通过 X-Forwarded-Proto 识别外部协议时，可以正确生成 HTTPS 链接；但应用不能无条件相信任意公网客户端提交的代理头。应把应用的可信代理范围限制到实际代理节点，避免错误识别客户端地址或安全连接状态。
域名前还有 CDN 或负载均衡时，当前 $remote_addr 可能只是前一层代理。需要按照那一层的可信地址范围恢复访客地址，不能简单把任意请求头当作真实 IP。与此同时，检查实际命中的站点和 location，避免配置写对了却没有被请求使用。Nginx 请求处理说明
按请求路径验收，再决定是否切换
先备份本次修改的站点文件，执行 sudo nginx -t；检查通过后才重新加载。用真实域名测试页面、静态资源、登录跳转和错误路径，并在应用日志中确认没有多一层或少一层路径。不要使用会创建真实订单的接口反复试验。
若出现新的异常，恢复本次站点配置并重新校验、加载，保持应用进程和数据不变。记录代理地址、路径是否剥离、可信代理设置及验证样本。日后应用迁移端口或增加 CDN 时，沿用这些样本复查，能够更快发现边界变化。