当前位置：首页 > news >正文

Nginx反向代理配置实战：单域名多端口服务统一入口与HTTPS部署

news 2026/7/31 9:23:17

1. 项目缘起：一个域名，多个服务，如何优雅地统一入口？

最近在折腾自己的个人服务器，场景很典型：一台云主机上，跑了不止一个应用。比如，一个主站博客跑在 3000 端口，一个后台管理面板跑在 8080 端口，可能还有个文件上传服务跑在 9000 端口。直接通过IP:端口访问，不仅难记，而且显得很不专业，更别提安全问题了——尤其是那个后台管理面板，直接暴露端口风险不小。

更关键的是，现在 HTTPS 已经是网站的标配。浏览器对非 HTTPS 站点的“不安全”警告，足以劝退大部分访客。给每个端口的服务都单独申请证书、配置 HTTPS？想想就头大，管理成本太高。

这时候，Nginx 的价值就凸显出来了。它不仅仅是一个高性能的 Web 服务器，更是一个强大的“流量调度员”。我们可以通过配置 Nginx，实现：用户只需访问一个主域名（例如www.yourdomain.com），Nginx 根据不同的访问路径（Path）或子域名（Subdomain），将请求透明地转发到服务器内部不同的端口服务上，并且全程使用 HTTPS 加密。对外，用户看到的是一个统一、安全的域名；对内，我们的服务可以各自安好，互不干扰。

这个方案的好处显而易见：

统一入口，提升体验：用户只需记住一个域名，通过不同的路径访问不同服务，逻辑清晰。
集中化管理 HTTPS：只需要为这一个主域名申请和配置 SSL 证书，Nginx 负责统一的 TLS 终止，后端服务可以继续使用 HTTP，简化了后端服务的配置。
增强安全与可控性：可以在 Nginx 层统一设置访问控制、限流、防火墙规则，隐藏后端服务的真实端口，降低被直接攻击的风险。
负载均衡与高可用：未来如果某个服务需要扩展，可以轻松在 Nginx 配置中 upstream 多个后端实例，实现负载均衡。

接下来，我就手把手带你完成这个“一个域名多端口+HTTPS”的经典配置。我会假设你已经在服务器上安装好了 Nginx，并且拥有一个已经解析到该服务器 IP 的域名。

2. 核心原理：Nginx 作为反向代理与 HTTPS 终结者

在动手之前，我们必须搞清楚 Nginx 在这个架构里扮演的两个核心角色：反向代理（Reverse Proxy）和SSL/TLS 终结者（SSL Termination）。理解了这个，配置起来就不会迷糊。

2.1 反向代理：流量的智能路由器

你可以把 Nginx 想象成公司大楼的前台。访客（客户端）来到大楼，只认识前台（Nginx，监听 80/443 端口）。访客说：“我要找技术部的张三（对应访问/api路径）”。前台查了一下内部通讯录（Nginx 的配置规则），发现技术部张三在 3 楼 301 房间（后端服务器 localhost:3000）。于是前台内部电话联系了 301 房间，把访客的需求转达过去，再把张三的回复转交给访客。

在这个过程中：

访客永远只和前台打交道，他不知道张三具体在哪个房间。
前台根据访客的请求内容（如 URL 路径），决定将请求转发给内部的哪个服务。
内部服务（张三）只需要处理前台转交过来的“纯业务”请求，不用直接面对外部的复杂网络。

在技术层面，Nginx 通过proxy_pass指令实现这个功能。例如：

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

这表示，所有以/api/开头的请求，都会被 Nginx 转发到本机3000端口上运行的服务。

2.2 HTTPS 终结：集中化的加密门卫

HTTPS 涉及复杂的 SSL/TLS 握手、证书验证和对称加密解密过程。如果让每个后端服务（比如 Node.js、Python Flask、Java Spring Boot 应用）都自己处理 HTTPS，不仅每个应用都要配置证书，还会消耗大量的 CPU 资源进行加解密。

Nginx 的SSL Termination模式解决了这个问题。它让 Nginx 充当那个面对外界的“加密门卫”：

外部客户端与 Nginx 建立安全的 HTTPS 连接（使用我们为域名配置的 SSL 证书）。
Nginx 完成 TLS 握手，解密收到的 HTTPS 请求，得到明文的 HTTP 请求。
Nginx 根据配置规则，将这个明文 HTTP 请求通过内部网络转发（proxy_pass）给后端的某个服务。
后端服务处理这个普通的 HTTP 请求，返回 HTTP 响应。
Nginx 收到后端响应后，再将其加密，通过 HTTPS 连接发回给客户端。

这样做的好处是：

证书管理简化：只需在 Nginx 一处配置和维护 SSL 证书。
后端服务轻量化：后端服务可以专注于业务逻辑，无需处理 SSL，通常使用 HTTP 协议即可，配置更简单。
性能优化：Nginx 非常擅长高效的 SSL/TLS 处理，并且可以启用会话复用等优化，降低延迟。

一个重要的安全实践：Nginx 与后端服务之间的内部通信，虽然通常是 HTTP，但因为它发生在服务器内部（localhost 或内网），所以风险可控。如果你对安全有极致要求，可以在内网也使用 HTTPS 或其它安全通道，但这会引入额外的证书管理和性能开销，对于大多数个人或中小型项目，HTTP over localhost 是常见且可接受的方案。

3. 实战配置：从零搭建多服务网关

理论清晰了，我们进入实战环节。我将以一个典型场景为例：假设我们有一个域名example.com，需要将流量分发到三个服务：

主网站（前端）：运行在localhost:3000
REST API 接口：运行在localhost:8080
管理后台：运行在localhost:9000

并且，我们要为example.com配置 HTTPS。

3.1 基础环境与证书准备

首先，确保你的 Nginx 已安装并运行。通过nginx -v可以查看版本。Nginx 的配置文件通常位于/etc/nginx/nginx.conf，而具体的站点配置放在/etc/nginx/sites-available/目录下，并通过软链接到/etc/nginx/sites-enabled/。

第一步：获取 SSL 证书现在获取免费 SSL 证书最方便的方式是使用 Let‘s Encrypt 的 certbot 工具。这里以 Ubuntu 系统为例：

# 安装 certbot 和 Nginx 插件 sudo apt update sudo apt install certbot python3-certbot-nginx # 为你的域名申请证书，certbot 会自动修改 Nginx 配置来验证域名所有权 sudo certbot --nginx -d example.com -d www.example.com

执行命令后，按照交互提示操作即可。Certbot 会自动完成证书申请、验证，并修改你的 Nginx 配置以启用 HTTPS。它会将证书文件（通常包括fullchain.pem和privkey.pem）保存在/etc/letsencrypt/live/example.com/目录下。

注意：运行 certbot 前，请确保你的域名example.com的 A 记录已经正确解析到当前服务器的公网 IP，并且服务器的 80 端口（HTTP）和 443 端口（HTTPS）已在防火墙中开放。

第二步：规划配置结构我们不建议直接修改默认的default配置。更好的做法是为你的站点创建一个独立的配置文件。

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

我们将在这个文件中编写完整的配置。

3.2 编写核心 Nginx 配置

下面是一个完整且注释详细的配置示例。请根据你的实际情况修改域名、证书路径和后端端口。

# /etc/nginx/sites-available/example.com # 1. 定义上游服务器组（可选，为未来负载均衡做准备） # 这里我们先以单机为例，实际上 upstream 可以包含多个 server。 upstream backend_website { server 127.0.0.1:3000; # 可以添加更多服务器实现负载均衡 # server 127.0.0.1:3001; # keepalive 32; # 保持连接池，提升性能 } upstream backend_api { server 127.0.0.1:8080; } upstream backend_admin { server 127.0.0.1:9000; } # 2. 主服务器块，监听 80 端口（HTTP），强制跳转到 HTTPS server { listen 80; listen [::]:80; server_name example.com www.example.com; # 将所有 HTTP 请求重定向到 HTTPS return 301 https://$server_name$request_uri; } # 3. 主服务器块，监听 443 端口（HTTPS） server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name example.com www.example.com; # SSL 证书配置（使用 certbot 自动生成的路径） ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # SSL 性能与安全优化配置（可复用 certbot 生成的推荐配置） # 以下是一些关键参数，certbot 通常会配置好 ssl_protocols TLSv1.2 TLSv1.3; # 禁用不安全的 TLS 版本 ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; # 根路径 / -> 转发到主网站前端 location / { proxy_pass http://backend_website; # 使用 upstream 名称 # 以下是一系列重要的代理设置，确保后端服务能正确获取客户端信息 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; # 告诉后端这是通过 https 来的 # 连接超时设置 proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 60s; # 禁用缓冲，适用于 Server-Sent Events 或 WebSocket 等流式响应 # proxy_buffering off; } # API 接口路径 /api/ -> 转发到 API 服务 location /api/ { proxy_pass http://backend_api/; # 注意结尾的斜杠！很重要。 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; # 如果 API 需要处理较长的请求体或响应时间，可以调整超时 # proxy_read_timeout 120s; # client_max_body_size 10M; # 允许更大的文件上传 } # 管理后台路径 /admin/ -> 转发到管理后台服务 location /admin/ { proxy_pass http://backend_admin/; 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; # 可以在此处添加基础认证，增加一层安全防护 # auth_basic "Admin Area"; # auth_basic_user_file /etc/nginx/.htpasswd; } # 静态文件服务优化（可选，如果前端有独立静态资源） location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|woff2)$ { expires 1y; add_header Cache-Control "public, immutable"; # 如果静态文件由前端服务提供，则不需要 proxy_pass # 如果放在 Nginx 本地，可以用 root 或 alias 指令 # root /var/www/example.com/static; } # 错误页面配置 error_page 404 /404.html; location = /404.html { root /usr/share/nginx/html; internal; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; internal; } }

3.3 配置详解与关键陷阱

上面的配置看起来不少，但核心就是几个location块。我们来拆解几个最容易出错的点：

1.proxy_pass结尾的斜杠/这是新手最常踩的坑。proxy_pass指令中，URL 结尾是否有斜杠，行为完全不同。

proxy_pass http://backend_api/;（有斜杠）
- 请求：https://example.com/api/users
- 转发给后端时，Nginx 会移除匹配的/api/部分。
- 后端实际收到的请求路径是：/users
proxy_pass http://backend_api;（无斜杠）
- 请求：https://example.com/api/users
- 转发给后端时，Nginx 会保留完整的/api/路径。
- 后端实际收到的请求路径是：/api/users

如何选择？这取决于你的后端服务期望的路径。如果你的后端 API 根路径就是/api，那么你应该用无斜杠的写法，或者将location改为location /api（不带结尾斜杠）。通常，为了让 Nginx 的配置更清晰（充当纯粹的网关，剥离路径前缀），推荐使用带斜杠的写法，并让后端服务监听在根路径上。

2.proxy_set_header的重要性没有这几行，你的后端服务就像“瞎了”一样：

Host $host：告诉后端请求原始的主机名（example.com），否则后端可能收到localhost:8080这样的 Host，导致生成错误的链接。
X-Real-IP $remote_addr：将客户端的真实 IP 传递给后端。否则在后端日志里，所有请求都来自127.0.0.1（Nginx 的 IP）。
X-Forwarded-For $proxy_add_x_forwarded_for：如果请求经过多层代理，这个头会记录整个代理链的 IP。
X-Forwarded-Proto $scheme：告诉后端请求的原始协议是https。这对于需要生成绝对 URL 或进行重定向的后端应用至关重要。

3. 超时与缓冲区配置默认的 Nginx 超时设置可能对某些长连接应用（如文件上传、WebSocket、Server-Sent Events）不友好。如果你的应用有这类需求，需要调整proxy_connect_timeout，proxy_send_timeout，proxy_read_timeout，以及考虑proxy_buffering off。

3.4 启用配置与测试

配置写好后，需要创建软链接到sites-enabled目录，并测试配置语法，最后重载 Nginx。

# 创建软链接 sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/ # 测试 Nginx 配置语法是否正确 sudo nginx -t # 如果看到 `nginx: configuration file /etc/nginx/nginx.conf test is successful` 则说明语法正确。 # 重载 Nginx 使配置生效 sudo systemctl reload nginx # 或者 sudo nginx -s reload

现在，你可以打开浏览器访问https://example.com，它应该指向你的3000端口服务；访问https://example.com/api/xxx应该指向8080端口；访问https://example.com/admin/应该指向9000端口。并且所有连接都是安全的 HTTPS。

4. 进阶配置与深度优化

基础功能跑通后，我们可以考虑一些进阶配置，让这个网关更强大、更安全。

4.1 基于子域名的路由

除了用路径（/api,/admin）区分服务，更清晰的做法是使用子域名。例如：

www.example.com-> 主站 (3000)
api.example.com-> API 服务 (8080)
admin.example.com-> 管理后台 (9000)

这种配置更符合 RESTful 风格，并且后端服务完全不需要关心路径前缀。配置起来也很简单，为每个子域名设置一个独立的server块即可。

# API 子域名 server { listen 443 ssl http2; server_name api.example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # 可以使用通配符证书 *.example.com ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; location / { proxy_pass http://localhost:8080; # ... 其他代理头设置 } } # Admin 子域名 server { listen 443 ssl http2; server_name admin.example.com; # ... SSL 配置 location / { proxy_pass http://localhost:9000; # 强烈建议在此处增加额外的认证，如 HTTP Basic Auth 或 IP 白名单 # allow 192.168.1.0/24; # deny all; # auth_basic "Restricted"; # auth_basic_user_file /etc/nginx/.htpasswd_admin; } }

使用子域名需要配置 DNS，为api.example.com和admin.example.com添加 A 记录指向服务器 IP。证书方面，可以申请一张通配符证书*.example.com，这样所有子域名都能使用。

4.2 负载均衡与健康检查

当某个服务流量增大时，单实例可能成为瓶颈。Nginx 的upstream模块可以轻松实现负载均衡。我们之前已经定义了upstream，现在可以扩展它。

upstream backend_website { # 默认是轮询 (round-robin) server 127.0.0.1:3000 weight=2; # weight 设置权重，权重越高被分配到的请求越多 server 127.0.0.1:3001; server 127.0.0.1:3002 backup; # backup 服务器，只有当其他服务器都不可用时才启用 # 其他负载均衡方法： # least_conn; # 最少连接数 # ip_hash; # 基于客户端 IP 的哈希，实现会话保持（注意：这不是真正的会话粘滞，后端需要共享会话状态） # hash $request_uri consistent; # 基于请求 URI 的哈希 # 健康检查（需要 Nginx Plus 或使用开源模块如 nginx_upstream_check_module） # check interval=3000 rise=2 fall=5 timeout=1000 type=http; # check_http_send "HEAD /health HTTP/1.0\r\n\r\n"; # check_http_expect_alive http_2xx http_3xx; }

在开源版 Nginx 中，可以通过max_fails和fail_timeout参数实现基本的被动健康检查：

upstream backend_api { server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; server 127.0.0.1:8081 max_fails=3 fail_timeout=30s; }

这表示如果 Nginx 在 30 秒内连续 3 次连接到该服务器失败，则会将其标记为不可用 30 秒。

4.3 安全加固与性能调优

安全加固：

隐藏 Nginx 版本信息：在http块或server块中添加server_tokens off;，防止泄露版本号。

设置安全响应头：

add_header X-Frame-Options "SAMEORIGIN" always; # 防止点击劫持 add_header X-Content-Type-Options "nosniff" always; # 禁止 MIME 类型嗅探 add_header Referrer-Policy "strict-origin-when-cross-origin" always; # 控制 Referer 信息 # 内容安全策略 (CSP) 根据你的站点内容仔细配置 # add_header Content-Security-Policy "default-src 'self';" always;

限制请求方法：对于 API 接口，可以只允许必要的 HTTP 方法。

location /api/ { limit_except GET POST PUT DELETE { deny all; } # ... proxy_pass 等配置 }

速率限制：防止恶意刷接口。

# 在 http 块中定义限制区 # http { # limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s; # } location /api/ { limit_req zone=api_limit burst=20 nodelay; # ... 其他配置 }

性能调优：

启用 HTTP/2：我们在listen指令中已经加了http2，这能显著提升多资源加载性能。

启用 Gzip 压缩：压缩文本响应，节省带宽。

gzip on; gzip_vary on; gzip_min_length 1024; gzip_proxied any; gzip_comp_level 6; gzip_types text/plain text/css text/xml text/javascript application/json application/javascript application/xml+rss application/atom+xml image/svg+xml;

调整缓冲区：根据你的平均响应大小调整代理缓冲区，避免磁盘 IO。
```
proxy_buffers 16 32k; proxy_buffer_size 64k; proxy_busy_buffers_size 128k;
```

连接保持：在upstream中设置keepalive连接数，减少频繁建立后端 TCP 连接的开销。

upstream backend_api { server 127.0.0.1:8080; keepalive 32; } # 同时在 location 中需要设置 location /api/ { proxy_http_version 1.1; proxy_set_header Connection ""; # ... 其他配置 }

5. 常见问题排查与调试技巧

即使配置看起来完美，实际运行中也可能遇到各种问题。这里分享一些排查经验和技巧。

问题一：访问出现 502 Bad Gateway 或 504 Gateway Timeout这是最常见的问题，意味着 Nginx 无法连接到后端服务或后端服务响应超时。

检查后端服务是否运行：sudo systemctl status your-service或ps aux | grep node/python/java。
检查端口是否正确：sudo netstat -tlnp | grep :3000，确认服务在监听你配置的端口。
检查防火墙：确保服务器本地的防火墙（如ufw）没有阻止 Nginx（运行在www-data或nginx用户下）连接到后端的本地端口。对于本地回环（localhost）通信，通常没问题，但如果服务绑定在0.0.0.0而非127.0.0.1，且防火墙规则严格，可能会出问题。
调整超时时间：如 3.3 节所述，适当增加proxy_connect_timeout，proxy_send_timeout，proxy_read_timeout的值。
查看 Nginx 错误日志：这是最直接的线索。日志通常在/var/log/nginx/error.log。使用sudo tail -f /var/log/nginx/error.log实时查看。

问题二：后端服务收到的请求 URL 或 Headers 不对

检查proxy_pass结尾斜杠：重温 3.3 节的内容，这是元凶之一。
检查proxy_set_header：确保设置了Host，X-Forwarded-Proto等头。可以在后端服务中打印接收到的所有 Headers 来验证。
检查 Web 框架配置：许多 Web 框架（如 Express， Flask， Spring Boot）需要显式配置信任代理，才能正确解析X-Forwarded-For等头。例如在 Express 中需要设置app.set('trust proxy', true)。

问题三：静态资源（CSS， JS，图片）加载 404

路径问题：如果前端是单页应用（SPA，如 React， Vue），并且使用了前端路由（如/dashboard），直接刷新页面或访问深链接时，Nginx 会把这个路径当作后端路由去匹配。解决方案是添加一个回退到index.html的规则。
```
location / { try_files $uri $uri/ /index.html; # 先找文件，再找目录，最后回退到 index.html proxy_pass http://backend_website; # ... 代理设置 }
```
注意：try_files和proxy_pass在同一个location中通常不能共存，因为try_files会检查文件系统。对于 SPA 代理，更常见的做法是让 Nginx 直接服务打包后的静态文件，或者确保后端服务能处理前端路由。如果必须代理，可能需要更复杂的配置，或者由前端服务自身处理 404 回退。
MIME 类型错误：确保 Nginx 能正确识别文件类型。检查/etc/nginx/mime.types文件是否包含对应的类型。

问题四：WebSocket 连接失败WebSocket 连接在握手成功后，需要升级协议并保持长连接。Nginx 需要额外配置。

location /ws/ { # 你的 WebSocket 路径 proxy_pass http://backend_website; 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_read_timeout 3600s; proxy_send_timeout 3600s; }

关键就是Upgrade和Connection "upgrade"这两个头，它们告诉 Nginx 这是 WebSocket 连接，需要特殊处理。

调试利器：Nginx 日志养成看日志的习惯。你可以在location块中添加自定义日志格式来调试：

log_format proxy_log '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$upstream_addr" $upstream_response_time'; access_log /var/log/nginx/proxy_access.log proxy_log;

这样，在proxy_access.log中你就能看到请求被转发到了哪个上游服务器（$upstream_addr）以及响应时间（$upstream_response_time），对于排查负载均衡和性能问题非常有用。

配置 Nginx 作为多服务网关和 HTTPS 终结者，是一个运维和开发人员必备的技能。它看似复杂，但核心逻辑清晰：监听、匹配、转发。从最基础的路径转发开始，逐步叠加子域名、负载均衡、安全策略等特性，最终构建出一个稳健、高效、安全的服务入口。这个过程充满了细节，一个斜杠、一个头信息都可能让服务行为异常，但每一次排错都是对网络流量理解的一次加深。我的经验是，写好配置后，先用nginx -t测试，再reload，然后第一时间查看错误日志，并打开浏览器开发者工具的“网络”选项卡，仔细观察每一个请求的响应状态码和 Header 信息，这套组合拳能解决大部分初期问题。

查看全文

http://www.jsqmd.com/news/1299425/