Flexus 云服务器上 Nginx 反向代理 8080 端口实战：配置、验证与排障

场景

很多人在 Flexus 云服务器上跑应用时都会遇到同一种部署形态：应用本身只监听本地 8080 端口，对外由 Nginx 做反向代理，统一走 80 和 443 端口提供服务。好处很直接：应用不用直接暴露端口，域名、证书、访问日志和限流都收敛到 Nginx 这一层。

本文就以一台 Flexus 云服务器为例，把一次可复用的配置写清楚：先给最小可用配置，再讲验证方法，最后按安全组、系统防火墙、Nginx、后端服务四层讲排障。

一、最小可用配置

先确认 Nginx 已经安装并在运行，配置文件通常在 /etc/nginx/nginx.conf 或 /etc/nginx/conf.d/ 目录下。建议把站点配置单独放一个文件，例如 /etc/nginx/conf.d/app.conf，便于管理。

下面是一个只监听 80 端口的最小配置，把请求转发到本地 8080 端口的应用：

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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：后端地址，指向本地 8080 端口的应用。
• proxy_http_version 1.1：让代理使用 HTTP 1.1，配合长连接和 WebSocket 更稳。
• Host：把原始域名原样传给后端，否则后端按默认站点处理请求，容易返回 404 或跳转到错误域名。
• X-Real-IP 和 X-Forwarded-For：把真实客户端 IP 传给后端，否则后端日志里看到的永远是 127.0.0.1。
• X-Forwarded-Proto：告诉后端原始请求是 http 还是 https，后端据此生成正确的跳转地址。

二、加上 HTTPS 的配置

生产环境建议只保留 443 端口对外提供服务，80 端口只做跳转。配置思路是：一个 server 块监听 80 端口并返回 301 跳转到 https，另一个 server 块监听 443 端口并启用 SSL，证书路径按实际文件填写。

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

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

注意：证书两个文件缺一不可，路径写错会导致 Nginx 启动失败；申请证书的域名必须和 server_name 一致。

三、部署后如何验证

改完配置不要直接重启，先按顺序验证：

1. 检查语法：执行 nginx -t，通过后再重载配置。
2. 重载服务：执行 systemctl reload nginx，比 restart 更平滑，不会中断已有连接。
3. 确认监听：执行 ss -tlnp，确认 Nginx 在监听 80 和 443 端口，后端应用在监听 8080 端口。
4. 本机验证后端：执行 curl 127.0.0.1:8080，确认应用本身能正常响应。这个命令绕过 Nginx，可以把问题范围先缩到后端或代理。
5. 本机验证代理：在服务器上执行 curl -I 域名或 curl -I localhost，确认经过 Nginx 后状态码正常。
6. 外网验证：用浏览器或手机网络访问域名，确认页面能打开。

四、访问不了时的三层排查法

安全组已放行 80 和 443 端口、服务还是访问不了，是最常见的报错场景。按下面三层从外到内排查，通常十分钟内能定位。

第一层：安全组与网络入口

在控制台检查实例绑定的安全组，确认入方向放行了 80 和 443 端口，协议和端口范围不要写错。还要确认实例绑定了弹性公网 IP，并且访问用的是公网 IP 或已解析到该 IP 的域名，而不是内网 IP。

第二层：系统防火墙与 Nginx

云服务器系统里可能还开着 firewalld 或 iptables，安全组放行不等于系统防火墙放行。依次确认：

• systemctl status nginx，确认 Nginx 在运行。
• ss -tlnp，确认 80 和 443 端口确实在监听。
• 查看 Nginx 错误日志 /var/log/nginx/error.log，最近的报错往往直接写明原因，例如端口被占用、证书文件找不到、配置文件语法错误。

第三层：后端服务与代理配置

如果 Nginx 本身能访问，但页面返回 502 或 404，问题一般在后端或代理规则：

• 后端是否真的在监听 8080 端口，curl 127.0.0.1:8080 能否拿到正常响应。
• proxy_pass 地址有没有写错端口。
• proxy_pass 末尾斜杠：带斜杠和不带斜杠时 URI 的拼接规则不同，写错会导致后端收到错误的路径。
• 上传大文件失败时，检查 client_max_body_size 是否太小；接口响应慢时，检查 proxy_read_timeout 是否太短。

五、三个容易踩的坑

1. 只改了配置文件却忘了重载：nginx -t 通过不等于配置已生效，必须执行 systemctl reload nginx。
2. Host 没有透传：后端拿不到真实域名，生成的跳转链接或页面静态资源地址会错。
3. 日志不看就反复改配置：先执行 curl 127.0.0.1:8080，再看 access.log 和 error.log，比盲目改配置快得多。

总结

一套可复用的检查清单：安全组放行 80 和 443 端口，系统防火墙同步放行，Nginx 监听正常且语法检查通过，后端在 8080 端口能正常响应，代理头透传完整。按这个顺序走一遍，绝大多数反向代理访问问题都能定位到具体的一层。