在 Ubuntu 24.04 LTS 上部署 Nginx 反向代理的 linux上线步骤与验证方法

上线前先确认三个条件

在 Ubuntu 24.04 LTS 上部署 Nginx反向代理，核心目标不是“能安装 Nginx”，而是让外部请求稳定进入 Nginx，再由 Nginx 转发到后端应用，并且能通过端口、日志和接口响应确认回源正常。本文以常见后端服务 127.0.0.1:3000 为例，演示一套可直接用于 linux 上线的部署教程。

开始操作前，先确认以下条件已经满足：

• 服务器系统为 Ubuntu 24.04 LTS，当前用户具备 sudo 权限。
• 后端应用已经启动，例如监听在 127.0.0.1:3000。
• 域名已经解析到服务器公网 IP；如果暂时没有域名，也可以用 Host 请求头进行本机验证。
• 云服务器安全组、系统防火墙允许访问 80 端口；如后续启用 HTTPS，再放行 443 端口。
• 当前操作不会中断已有线上服务；如果服务器上已经运行 Apache、旧版 Nginx 或其他占用 80 端口的服务，需要先确认迁移窗口。

反向代理上线的基本判断是：外部客户端 → 服务器 80/443 端口 → Nginx server 块 → proxy_pass 后端服务 这条链路全部可达。任意一层失败，都可能表现为 502、超时、空白页或访问到默认站点。

环境检查：确认系统、端口和后端服务状态

先确认系统版本，避免把其他发行版的命令套用到 Ubuntu 24.04 LTS 上。

lsb_release -a

正常会看到类似信息：

Distributor ID: Ubuntu
Description:    Ubuntu 24.04 LTS
Release:        24.04
Codename:       noble

检查当前 80、443 和后端端口占用情况：

sudo ss -lntp | grep -E ':80|:443|:3000'

如果后端应用应监听 3000，需要看到类似结果：

LISTEN 0 511 127.0.0.1:3000 0.0.0.0:* users:(("node",pid=1234,fd=20))

这里有两个关键判断：

• 后端只给本机 Nginx 访问：建议监听 127.0.0.1:3000。
• 后端需要被其他内网组件访问：可以监听内网地址，但不要无必要暴露到公网。

再用 curl 直接访问后端健康检查接口。接口路径请替换成你自己的应用地址，例如 /health、/api/health 或首页路径。

curl -i http://127.0.0.1:3000/health

如果这里已经失败，先不要配置 Nginx。Nginx反向代理不能修复后端应用本身不可用的问题。应先检查应用进程、监听地址、容器端口映射、应用日志和数据库连接。

安装 Nginx 并启动服务

Ubuntu 24.04 LTS 默认使用 apt 管理软件包。安装前先更新软件源索引。

sudo apt update
sudo apt install -y nginx

确认 Nginx 版本和服务状态：

nginx -v
sudo systemctl status nginx --no-pager

如果状态为 active (running)，说明 Nginx 已启动。也可以用端口确认：

sudo ss -lntp | grep ':80'

本机访问默认站点：

curl -I http://127.0.0.1

如果返回 HTTP/1.1 200 OK 或 Nginx 默认页相关响应，说明 Nginx 已经监听 80 端口。

配置系统防火墙时先保留 SSH

如果服务器启用了 UFW，放行 Web 端口前务必确认 SSH 已允许，避免远程操作被锁在服务器外。

sudo ufw status

如需启用或调整 UFW，建议先允许 SSH：

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx HTTP'

如果后续需要 HTTPS，可再放行：

sudo ufw allow 'Nginx HTTPS'

如果是云服务器，还要同步检查云平台安全组。UFW 放行但安全组未放行时，公网仍然访问不到。

创建 Nginx 反向代理站点配置

Nginx 在 Ubuntu 上常用的站点目录是：

• 配置文件目录：/etc/nginx/sites-available/
• 启用站点目录：/etc/nginx/sites-enabled/
• 主配置文件：/etc/nginx/nginx.conf
• 访问日志：/var/log/nginx/access.log
• 错误日志：/var/log/nginx/error.log

下面以域名 app.example.com、后端服务 127.0.0.1:3000 为例。请替换为你的真实域名和后端端口。

sudo nano /etc/nginx/sites-available/app.example.com

写入以下配置：

server {
    listen 80;
    listen [::]:80;

    server_name app.example.com;

    access_log /var/log/nginx/app.example.com.access.log;
    error_log /var/log/nginx/app.example.com.error.log;

    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_connect_timeout 5s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }
}

这段配置的作用是：Nginx 监听 80 端口，当请求域名为 app.example.com 时，把请求转发到本机 3000 端口的后端服务。

几个关键字段需要理解：

启用站点：

sudo ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/

如果这是新服务器，可以禁用默认站点，避免访问域名时落到 Nginx 默认页。该操作只删除启用链接，不删除默认配置文件。

sudo rm /etc/nginx/sites-enabled/default

操作已有生产服务器时，不建议直接删除或覆盖旧配置。可以先备份：

sudo cp /etc/nginx/sites-available/app.example.com /etc/nginx/sites-available/app.example.com.bak.$(date +%F-%H%M)

检查配置语法：

sudo nginx -t

看到以下类似结果再重新加载：

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

重新加载 Nginx，而不是直接重启：

sudo systemctl reload nginx

reload 会让 Nginx 重新读取配置，通常比 restart 对线上连接更友好。

关键配置：路径转发、超时和 WebSocket

普通后端应用的推荐写法

大多数 API、管理后台、Web 应用使用下面这种写法即可：

location / {
    proxy_pass http://127.0.0.1:3000;
    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 后面没有额外路径。这样访问：

http://app.example.com/users

会转发到：

http://127.0.0.1:3000/users

/api/ 前缀是否保留要提前确认

如果只代理 /api/，斜杠写法会影响后端收到的路径。

保留 /api/ 前缀：

location /api/ {
    proxy_pass http://127.0.0.1:3000;
}

访问 /api/users 时，后端收到 /api/users。

去掉 /api/ 前缀：

location /api/ {
    proxy_pass http://127.0.0.1:3000/;
}

访问 /api/users 时，后端收到 /users。

这类问题经常被误判为后端路由异常。上线前应和后端路由设计对齐。

WebSocket 应用需要增加升级头

如果后端包含 WebSocket，例如实时消息、在线协作、终端控制台，需要增加 Upgrade 和 Connection 头。

可以在 server 内对应路径增加：

location /ws/ {
    proxy_pass http://127.0.0.1:3000;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    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_read_timeout 300s;
}

如果只是普通 HTTP API，不需要额外配置 WebSocket。

验证一：确认 Nginx 监听端口正常

重新加载配置后，先看 Nginx 是否仍在监听 80 端口。

sudo ss -lntp | grep ':80'

正常应看到 nginx 进程监听 0.0.0.0:80 或 [::]:80。

再检查服务状态：

sudo systemctl status nginx --no-pager

如果 Nginx 没有启动，查看 systemd 日志：

sudo journalctl -u nginx -n 80 --no-pager

常见原因包括配置语法错误、端口被占用、配置文件路径错误、重复定义冲突的 server_name 等。

验证二：本机模拟域名访问

在 DNS 未完全生效或不方便修改本机 hosts 文件时，可以直接在服务器上用 Host 请求头验证 server 块是否匹配。

curl -i http://127.0.0.1/health -H 'Host: app.example.com'

如果返回后端健康检查结果，说明：

• Nginx 已接收请求；
• server_name app.example.com 匹配成功；
• proxy_pass 已转发到后端；
• 后端接口响应正常。

如果返回 Nginx 默认页，通常是 server_name 不匹配或默认站点仍然抢占请求。检查：

sudo nginx -T | grep -n "server_name"

nginx -T 会输出完整生效配置，适合确认最终加载的是哪一份配置。

验证三：从外部访问域名

从本地电脑或另一台服务器访问域名：

curl -i http://app.example.com/health

也可以绕过 DNS 缓存，强制把域名解析到指定服务器 IP：

curl -i --resolve app.example.com:80:SERVER_PUBLIC_IP http://app.example.com/health

将 SERVER_PUBLIC_IP 替换为服务器公网 IP。

外部访问成功，才说明公网链路、云安全组、系统防火墙、Nginx 和后端服务都基本可用。只在服务器本机成功，不代表公网用户一定可以访问。

验证四：通过日志确认转发和回源

打开两个终端观察日志更直观。

查看站点访问日志：

sudo tail -f /var/log/nginx/app.example.com.access.log

查看站点错误日志：

sudo tail -f /var/log/nginx/app.example.com.error.log

然后发起请求：

curl -i http://app.example.com/health

访问日志中应出现请求路径、状态码、客户端 IP 等信息。错误日志为空或无新增报错，通常表示 Nginx 层没有明显异常。

不同状态码的排查方向如下：

常见错误检查顺序

502 Bad Gateway：先查后端是否可达

502 是 Nginx反向代理上线时最常见的问题。先在服务器本机访问后端：

curl -v http://127.0.0.1:3000/health

如果失败，检查后端监听：

sudo ss -lntp | grep ':3000'

再查看 Nginx 错误日志：

sudo tail -n 80 /var/log/nginx/app.example.com.error.log

如果日志里有 connect() failed (111: Connection refused)，通常表示后端端口没有进程监听，或 proxy_pass 端口写错。

如果有 upstream timed out，说明连接到了后端，但后端响应太慢。此时应优先检查应用日志、数据库连接、外部依赖，而不是单纯把 Nginx 超时时间调得很大。

访问到默认页：检查 server_name 和默认站点

如果访问域名看到 Nginx 默认欢迎页，说明请求没有命中你配置的站点，或默认站点仍然被匹配。

检查启用的配置：

ls -l /etc/nginx/sites-enabled/

检查完整配置：

sudo nginx -T | less

确认是否存在多个 server 块监听 80，并且 server_name 是否写对。域名大小写一般不敏感，但拼写、二级域名、泛域名配置要准确。

外部访问超时：不要只查 Nginx

服务器本机 curl 成功，但外部访问超时，常见问题在网络入口层。

按顺序检查：

1. 域名是否解析到当前服务器公网 IP。
2. 云安全组是否放行 TCP 80。
3. UFW 是否放行 Nginx HTTP。
4. Nginx 是否监听 0.0.0.0:80，而不是只监听 127.0.0.1:80。
5. 本地运营商或办公网络是否缓存了旧 DNS。

相关命令：

dig +short app.example.com
sudo ufw status
sudo ss -lntp | grep ':80'

如果没有安装 dig，可安装工具包：

sudo apt install -y dnsutils

修改配置后不生效：确认是否 reload 成功

修改 Nginx 配置后，需要先检查语法，再重新加载。

sudo nginx -t
sudo systemctl reload nginx

如果 nginx -t 失败，不要强行 reload。根据提示定位到具体文件和行号修复。

查看当前 Nginx 实际加载配置：

sudo nginx -T | grep -n "app.example.com"

有时配置文件写在 sites-available，但忘记链接到 sites-enabled，也会导致修改不生效。

Docker 后端代理失败：检查容器端口映射

如果后端运行在 Docker 中，Nginx 在宿主机上访问的是宿主机端口，不是容器内部端口。推荐把容器端口绑定到本机地址，例如：

docker run -d \
  --name myapp \
  -p 127.0.0.1:3000:3000 \
  myapp:latest

然后 Nginx 使用：

proxy_pass http://127.0.0.1:3000;

如果容器没有映射端口，宿主机上的 Nginx 无法直接访问容器内部的 3000。此时需要调整 Docker 网络或端口映射。

上线检查清单

正式切流前，建议逐项确认：

• Ubuntu 24.04 LTS 系统版本已确认，命令与包管理器匹配。
• 后端应用本机访问正常：curl http://127.0.0.1:3000/health。
• Nginx 已安装并运行：systemctl status nginx 为 active。
• 站点配置已放在 /etc/nginx/sites-available/，并链接到 /etc/nginx/sites-enabled/。
• server_name 与域名一致，DNS 已解析到当前服务器公网 IP。
• proxy_pass 地址、端口、协议正确。
• nginx -t 语法检查通过。
• 已执行 systemctl reload nginx，并确认端口监听正常。
• UFW 和云安全组已放行 80 端口；如使用 HTTPS，再检查 443 端口。
• 本机 Host 头验证通过：curl -H 'Host: app.example.com' http://127.0.0.1/health。
• 外部访问验证通过：curl http://app.example.com/health。
• 访问日志有记录，错误日志无新增关键报错。
• 已保留旧配置或备份文件，出现异常时可以快速回滚。

完成以上检查后，这套 Nginx反向代理部署即可满足一般后端应用在 Ubuntu 24.04 LTS 上的 linux 上线要求。后续如果增加 HTTPS、负载均衡或多后端 upstream，应在当前反向代理可用的基础上逐项扩展，并继续保留端口、转发、日志和后端健康检查这四类验证。