只要干过几年服务器运维或后端部署大概率都撞上过这类场景一台服务器上同时跑着好几个服务比如某个内部管理系统占了8080、一个API服务占了8001、还有个静态站点占了3000。一串服务全靠“IP:端口”访问不仅难记还容易把管理端口直接暴露到公网。我在实际项目里踩过这个坑之后才意识到与其给每个服务单独开防火墙、配域名解析不如直接用Nginx在服务器上做一个统一入口把所有流量按域名或路径转发到对应端口。这套单台服务器的多端口反向代理方案正是解决“一机多服务”最经典也最稳的做法。这篇文章不打算扯太多概念就从一个实际可落地的配置出发把Nginx如何实现多端口反向代理讲清楚从最基础的“一个端口转一个服务”开始到多域名共用一台服务器、多路径转发、WebSocket代理这类进阶场景最后附上我这几年的排错经验和配置模板。不管是刚接手服务器的新手还是想优化现有部署架构的开发者都可以拿来直接参考。1. 多端口反向代理的核心需求解析1.1 什么是反向代理为什么不用直接端口访问先说一个基本概念。反向代理翻译成大白话就是用户访问的入口是Nginx所在的端口通常是80或443Nginx根据规则把请求转给后面实际提供服务的内网端口再把结果原样返回给用户。用户始终只看得到Nginx这一层并不知道后端服务到底跑在哪个端口。那为什么不直接给用户提供带端口的地址我举一个很常见的例子。假设服务器上有两个服务服务A运行在127.0.0.1:8080是一个管理后台服务B运行在127.0.0.1:3000是一个前端应用。如果不做反向代理用户访问就是http://服务器IP:8080和http://服务器IP:3000。问题随之而来第一端口暴露越多被扫描和攻击的面就越大第二用户必须记住端口号体验很差第三混用HTTP和HTTPS时想在Nginx层面统一加证书也变得很麻烦。所以核心思路就是把所有外部流量收编到80或443端口由Nginx按规则分发到内网端口。这样对外看起来就像只有一个入口逻辑清晰安全性也更好控制。1.2 单台服务器多端口转发的两种典型架构形态实际操作中“单台服务器多端口反向代理”通常有两种布局。第一种叫“多域名转发”。比如服务器上有两个站点一个绑定service-a.example.com另一个绑定service-b.example.com但两台站点实际都在同一台机器上。Nginx通过匹配请求头中的Host字段就能把流量转发到不同的后端端口。第二种叫“单域名多路径转发”。比如你只有一个域名example.com但想通过/api/访问8080端口的API服务通过/admin/访问9000端口的管理后台。这时候Nginx根据URL路径来做转发。这两种形态在实际项目中很常见甚至有混合使用的情况。我个人经验是能用域名区分就优先用域名因为路径方式对后端服务是有潜在影响的——如果后端服务自身带有路由逻辑多了个前缀路径可能会导致内部跳转路径不匹配。这个后面会说具体例子。1.3 Nginx在处理多端口转发时的优势在Nginx之前类似的需求也有人用Apache或专门的反代工具实现过但Nginx能成为主流选择主要就几点一是性能好。Nginx基于事件驱动架构处理高并发连接时占用的内存和CPU资源很少。单台服务器上挂着四五个服务Nginx扛住入口流量完全不是问题。二是配置灵活。一个server块对应一个域名一个location块对应一条转发规则组合起来表达力很强。要加一个服务就是加几行配置的事不需要重启整个架构只需要reload。三是生态成熟。从HTTP转发到HTTPS证书配置、从WebSocket到TCP/UDP层代理Nginx都有完善的处理方案踩坑经验在网上也能找到大量参考。2. 配置前必须搞懂的Nginx转发细节2.1 location匹配规则别在根路径上踩坑location是Nginx配置里几乎所有转发规则的核心。它的作用是根据URL路径决定把请求交给哪个处理逻辑。我见过不少新手在location /里直接配一串proxy_pass然后发现所有请求都进了同一个后端导致其他location规则全部失灵。这就是没搞懂location匹配优先级。Nginx的location匹配有几种形式location /前缀匹配匹配以/开头的所有请求是默认兜底项location /精确匹配只匹配根路径location ~ /api/正则匹配区分大小写location ~* /api/正则匹配不区分大小写location ^~ /api/前缀匹配但一旦命中就停止继续搜索正则。匹配优先级从高到低是精确匹配 前缀匹配^~ 正则匹配~/~* 普通前缀匹配。举个例子server { listen 80; server_name example.com; location / { return 200 root; } location /api/ { proxy_pass http://127.0.0.1:8001; } location / { proxy_pass http://127.0.0.1:3000; } }这时访问/会直接走精确匹配规则访问/api/login会走/api/前缀规则访问/home才会走默认的/规则。也就是说location /并不是“根路径专用”而是所有未匹配路径的兜底。把服务A的转发写在location /把服务B的转发写在location /api/时服务A的配置绝不能是location /和location /api/同时存在下的“优先项”这个顺序关系务必记牢。2.2 proxy_pass带不带斜杠结果差之千里这是反向代理配置里最容易忽略但又影响极大的细节。proxy_pass后面的URL结尾是否带斜杠直接决定了转发给后端时是否保留原始路径。看下面两种情况# 情况一proxy_pass不带路径 location /api/ { proxy_pass http://127.0.0.1:8001; } # 情况二proxy_pass带路径 location /api/ { proxy_pass http://127.0.0.1:8001/; }在情况一下请求/api/login转发给后端时路径是/api/login。在后端服务能感知到前缀路径且能正确处理的情况下这是没问题的。在情况二下其匹配规则是把location前缀匹配到的那部分路径“替换”为proxy_pass中的路径。/api/login中匹配到/api/替换为/后后端收到的就是/login。我遇到过的典型问题场景是这样的某个后端服务自身设计时就是以根路径为基准的所有路由定义里都没有/api前缀。这时候如果用了情况一后端收到的是/api/login但它的路由表里找的是/login于是返回404。换成情况二就解决了。但情况二也有副作用。如果后端服务内部有跳转逻辑比如登录后重定向到/dashboard那用户浏览器会直接访问http://example.com/dashboard而不是/api/dashboard结果又404了。所以没有哪种写法是“万能正确”的必须根据后端服务的路由设计来选择。建议在配置前先确认后端服务是否能感知并容忍前缀路径。2.3 转发请求头保留客户端真实信息Nginx做反向代理时默认情况下后端服务收到的请求来源是Nginx本身。如果后端要做用户IP、来源域名之类的判断就需要在配置里显式传递请求头。我在每个反代location里都会带上这三行proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;第一行Host有时候要按场景调整。默认保留用户请求里的Host字段是最稳妥的但如果你希望后端始终看到某个固定域名比如内部服务域名也可以写死。第二行和第三行用于传递真实客户端IP后端只要是标准的Web框架比如Flask、Django、Spring Boot都能从这两个头里拿到用户原始IP。另外还有一个常被忽略的请求头是X-Forwarded-Proto。当Nginx负责终止HTTPS、后端是HTTP时后端会以为自己在被HTTP访问某些框架在生成回调链接时会自动用http://前缀。加上这一行可以规避proxy_set_header X-Forwarded-Proto $scheme;2.4 用upstream管理后端节点让配置更清晰如果一个后端端口对应了多个实际服务实例比如负载均衡场景或者单纯想给多个location复用同一个后端地址用upstream定义一组后端会更清晰。它的写法是upstream backend_a { server 127.0.0.1:8001; server 127.0.0.1:8002; }然后在location里引用location /api/ { proxy_pass http://backend_a; }upstream还支持权重、健康检查等高级参数但对于单台服务器多端口转发这个场景来说最大的价值其实是“抽象”把目标地址集中定义在配置顶部后面多个location需要转发到同一个服务时就不用重复写IP和端口。要调整端口时也只改一处即可。3. 完整实操从最简配置到生产级方案3.1 服务器环境与前置条件开始配置之前确认三件事。第一Nginx已安装。Debian系用apt install nginxCentOS系用yum install nginx或dnf install nginx。装好之后用nginx -v确认版本。第二确认服务器上各服务的监听状态。用ss -tlnp或netstat -tlnp查看确保要代理的后端端口都处于LISTEN状态并且确认是监听在127.0.0.1还是0.0.0.0。如果服务监听在0.0.0.0意味着服务器所有网卡都能直接访问该端口这本身就不够安全。理想的架构是后端服务只监听127.0.0.1由Nginx来统一对公网提供服务。第三确定域名解析已经指向这台服务器公网IP。如果只是测试临时用curl -H Host: test.example.com http://服务器IP也可以模拟域名访问效果。3.2 场景A一个服务器跑两个独立域名的服务假设场景如下服务Ablog.example.com后端端口127.0.0.1:8080服务Bshop.example.com后端端口127.0.0.1:8081目标是通过两个域名分别访问这两个服务对外只开放80端口。在/etc/nginx/conf.d/下新建配置文件比如multi-site.confserver { listen 80; server_name blog.example.com; location / { proxy_pass http://127.0.0.1:8080; 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; } } server { listen 80; server_name shop.example.com; location / { proxy_pass http://127.0.0.1:8081; 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; } }这里有两个关键点第一两个server块都监听80端口靠server_name区分流量。Nginx收到请求后先检查Host头将blog.example.com的请求交给第一个server块shop.example.com的交给第二个。访问一个未匹配的域名时默认会走第一个server块作为兜底。第二每个server块内部都是一套独立的location规则。也就是说这个场景下就算两个服务都配置了location /也不会互相干扰因为这俩分别在不同server块内。写完配置后先测试语法nginx -t输出出现successful字样后平滑加载配置nginx -s reload然后分别用curl验证两个站点是否都能正常返回内容。3.3 场景B一个域名通过路径区分多个服务假设只有一个域名app.example.com有三个服务在跑API服务127.0.0.1:8001管理后台127.0.0.1:8002前端静态站127.0.0.1:3000分配的URL路径为/api/→ API服务/admin/→ 管理后台/→ 静态站配置文件如下server { listen 80; server_name app.example.com; location /api/ { proxy_pass http://127.0.0.1:8001; 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; } location /admin/ { proxy_pass http://127.0.0.1:8002; 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; } 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; } }这里最需要注意的就是我在前面反复强调的如果后端API服务无法感知/api前缀就得把第一个location的proxy_pass改成http://127.0.0.1:8001/。路径转发方式虽然直观但它有一个致命限制如果多个location的路由前缀过长、过复杂配置会变得臃肿。而且不同后端服务如果都定义了外层通配路径很容易互相干扰。所以在多服务场景下我一直建议优先考虑域名方式路径方式重点只做API网关入口这类用途。3.4 场景C混合场景同一个域名既有页面又有API还有WebSocket实际项目中更常见的其实是混合场景。举个我整理过的配置模板前端页面和后端API都在同一个域名下同时还要支持WebSocket实时通信server { listen 80; server_name www.example.com; # 前端页面走静态服务 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; } # 后端API location /api/ { proxy_pass http://127.0.0.1:8001; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # WebSocket长连接 location /ws/ { proxy_pass http://127.0.0.1:8002; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_read_timeout 3600s; } }WebSocket这块必须单独说明。普通的HTTP代理只需设置请求头而WebSocket是长连接需要完成协议升级所以必须额外配置Upgrade和Connection这两个头同时把proxy_read_timeout调大避免长时间没有数据交互时连接被Nginx切断。我一开始没注意这个前端一直报WebSocket连接被断开排查了很久才定位到是Nginx默认60秒超时把连接掐断了。把超时改成3600秒后问题直接消失。如果是心跳比较频繁的应用适当地调低超时时间也行关键是要与业务心跳间隔匹配。这里补充一个建议如果项目里WebSocket连接量比较大可以考虑把Nginx版本升级到支持HTTP/2的版本同时开启listen 443 ssl http2减少握手延迟效果会更明显。3.5 开启HTTP/2和HTTPS统一入口前面所有配置里Nginx监听的都是80端口。但在生产环境里我们通常还会把HTTPS一并加上。最简单的方式是在同一个server块内同时监听443和80并把80的请求重定向到443server { listen 80; server_name app.example.com; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name app.example.com; ssl_certificate /etc/nginx/ssl/app.example.com.pem; ssl_certificate_key /etc/nginx/ssl/app.example.com.key; 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; } location /api/ { proxy_pass http://127.0.0.1:8001; 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进程对证书目录是否有读取权限。如果启动报错nginx -t会给出明确提示。3.6 配置后的验证方法配置写完后我习惯做这几步验证全部通过才算真正上线第一步nginx -t测试语法确认没有错误。第二步curl -I http://localhost访问本机入口看看返回状态码。如果是302或200说明Nginx正常启动。第三步用带Host头的命令分别测试每个虚拟主机curl -H Host: blog.example.com http://127.0.0.1/ curl -H Host: shop.example.com http://127.0.0.1/第四步如果配置了/api路径使用curl http://127.0.0.1/api/health验证路径转发是否生效。4. 常见问题与排查技巧实录4.1 配置生效了但后端大量出现502 Bad Gateway502是反向代理场景中出现概率最高的错误几乎所有Nginx使用者都遇到过。这个状态码的含义是“网关收到无效响应”绝大多数情况下是后端服务挂了或者Nginx连不上后端端口。排查思路按顺序来先确认后端服务进程是否存活ps aux | grep 后端进程名再确认端口还在监听ss -tlnp | grep 8001接着在服务器本地直接访问后端地址curl http://127.0.0.1:8001/health看是否正常返回如果本地能通再检查Nginx里proxy_pass写的地址是否正确比如是不是写成了http://127.0.0.1:8001/而实际端口是8080这类笔误。另外还有一种常见情况是后端服务监听的是IPv6地址::1而Nginx配置里写的是127.0.0.1导致连接失败。这时候要么统一监听地址要么把proxy_pass改成[::1]对应的写法。4.2 504 Gateway Timeout请求卡了很久才报错504说明Nginx把请求转发给了后端但后端在规定时间内没有返回结果。通常有两类原因。一类是后端处理本身就慢。这时可以在location里调整proxy_read_timeout、proxy_connect_timeout、proxy_send_timeout这三个参数默认都是60秒按需调大proxy_connect_timeout 60s; proxy_send_timeout 120s; proxy_read_timeout 120s;另一类是后端的连接池或线程池被打满了请求排队时间过长。这种情况调Nginx超时只是缓解表象核心还是要去优化后端服务的处理能力比如调整连接池大小、缓存查询结果等。4.3 页面能打开但CSS和图片全部404这种问题几乎都出在路径配置上。我实际遇到的场景是前端静态站部署在127.0.0.1:3000页面内容能通过/正常返回但页面里引用的/assets/style.css无法加载。原因在于后端页面里用的是根路径/assets/...但Nginx只把/的请求转给了前端服务页面拿到后浏览器直接向服务器请求/assets/style.css这个路径并不在Nginx的任何location规则里于是404。解决办法有两个方向。第一个方向是把静态资源的路径也加入到Nginx转发规则中比如location /assets/ { proxy_pass http://127.0.0.1:3000; }第二个方向是调整后端服务的静态资源引用路径统一加上前缀。真心建议优先从根源上解决因为一旦页面里到处是根路径引用Nginx这边要配的额外location会越来越多。4.4 用路径方式转发后后端重定向跳到了错误地址这是路径方式转发最容易暴露的隐患。假设配置把/api/转发给后端时去掉了前缀后端收到请求后返回一个302重定向到/users这个重定向是后端自己生成的浏览器就会带着http://example.com/users去访问。但Nginx的路线里没有/users对应的规则最终落到location /如果这里的转发目标是另一个服务就会出现奇怪的跳转错乱。要解决这个问题要么在后端代码里配置一个全局的URL前缀让所有生成的链接都带上/api前缀要么在Nginx层面对响应内容做替换通过sub_filter模块把响应体中的某些字符串替换掉。但我的经验是Nginx层面的替换属于补丁方案维护成本很高最好还是推动后端开发一起把前缀问题解决掉。4.5 日志怎么看、如何定位转发错误的根因Nginx的日志是排查一切问题的基础。默认访问日志在/var/log/nginx/access.log错误日志在/var/log/nginx/error.log。遇到转发相关问题时先查看错误日志tail -f /var/log/nginx/error.log里面通常会直接给出上游连接失败的具体原因比如“connect() failed (111: Connection refused) while connecting to upstream”这类信息一眼就能看出连不上哪个端口。访问日志则可以用来确认请求最终命中了哪个server块和location块。我在排查问题时的标准做法是先看访问日志确认请求是否到达Nginx再看错误日志确认转发环节哪里断了最后配合curl直接在后端服务本地测试三步下来基本能定位绝大多数问题。4.6 常用排查命令速查表目的命令验证Nginx配置语法nginx -t重载Nginx配置nginx -s reload查看后端端口监听状态ss -tlnp本地直接访问后端服务curl http://127.0.0.1:8001/health模拟域名请求测试转发curl -H Host: app.example.com http://127.0.0.1/查看Nginx错误日志tail -f /var/log/nginx/error.log查看Nginx访问日志tail -f /var/log/nginx/access.log4.7 一些额外的避坑心得我在多次配置和迁移Nginx之后总结出几个不太容易在文档里看到的经验。第一后端服务尽量绑定127.0.0.1而不是0.0.0.0。这样即使Nginx被攻击突破攻击者也不能直接利用其他端口访问内部服务。如果是Docker部署则需要注意端口映射时不要轻易映射到宿主机所有网卡。第二Nginx配置做完后修改使用nginx -s reload而不是nginx -s restart。reload可以做到平滑变更几乎不影响线上正在进行的连接restart则会直接中断所有现有连接。第三每加一个服务就在配置里留下一段对应注释标明端口和用途。别依赖记忆力也别相信“以后会整理文档”这种话。服务器上配置多起来后没有注释的Nginx配置文件就像一盘散沙改一处可能要花半小时去猜原先意图。第四proxy_pass指向的地址后面是否带路径不是拍脑袋决定的。去确认后端服务自身的路由设计再决定用不带斜杠还是带斜杠的写法。实在拿不准时先在测试环境里用curl实测。第五如果Nginx版本较旧建议升级到较新的稳定版。早期版本在HTTP/2、SSL安全参数上有不少短板新版在这些方面都做了明显优化。5. 多端口反向代理的扩展思路与实用建议5.1 从多端口反代到统一API网关配置完多端口反向代理之后下一个自然演进方向就是把它当做一个轻量级API网关来用。比如在Nginx层统一做限流、鉴权、日志审计这些都不需要改动后端代码。以限流为例Nginx内置了limit_req模块可以针对某个路径设置每秒请求数上限limit_req_zone $binary_remote_addr zoneapi_limit:10m rate10r/s; server { location /api/ { limit_req zoneapi_limit burst20 nodelay; proxy_pass http://127.0.0.1:8001; } }这段配置意思是对每个客户端IP限制每秒最多10个请求允许短时突发20个请求。相当于给API入口装了一个简易闸门。需要更复杂的鉴权还可以结合auth_request模块把请求转发给统一的鉴权服务做校验。5.2 从HTTP反向代理升级到TCP/UDP负载均衡有不少业务走的是非HTTP协议比如数据库连接、消息队列、自研协议等。这些流量没法用location来转发但Nginx依然支持。通过stream模块可以做四层代理stream { upstream mysql_pool { server 127.0.0.1:3306; } server { listen 3307; proxy_pass mysql_pool; } }不过四层代理的“多端口”含义和七层代理不同七层靠域名和路径区分流量四层则是直接在Nginx上开放不同的端口再把每个端口转发到对应后端。这种方式适合对性能要求极高的场景也适合做一些非HTTP服务的统一入口。但副作用是端口会重新暴露因此要配合防火墙规则把Nginx端口设为白名单。5.3 架构层面再往前一步多台服务器的反向代理单台服务器的多端口反代是所有反向代理架构的基础。再往后走就是多台服务器节点的高可用和负载均衡了。虽然这已经是另一个量级的问题但从单机反代过渡到多机反代时Nginx的核心配置思路几乎完全延续只是upstream里的地址从127.0.0.1:8001换成其他机器的内网IP同时加上健康检查参数而已。所以把单机场景吃透价值不只是眼前这一台服务器的部署更是后续横向扩展的地基。5.4 实战建议配置管理要早做规划我见过不少团队的服务器上Nginx配置是一长串堆在nginx.conf主文件里几千行连在一起没人敢动。建议从一开始就养成分文件管理的习惯主配置只管全局参数每个站点独立用conf.d下单独文件管理文件名里带上域名或服务名。具体来说/etc/nginx/nginx.conf不做站点具体配置只包含events、http等全局块/etc/nginx/conf.d/example.com.conf一个服务一个文件对应证书文件放/etc/nginx/ssl/下按域名命名。这样每个文件短小清晰排错时直接定位到对应文件不会牵一发动全身。我个人在实操中还有一个习惯就是每完成一个配置就在文件头部写清楚这次改动登记了什么服务、哪个端口、哪天改的类似这样# 2025-04-10: 接入数据报表服务后端端口 8082路径 /report/这种注释在半个月后再回头看时价值远比自己想象的大。6. 结尾聊几句实操体会说实话这套多端口反向代理的配置本身并不复杂真正考验人的是遇到隐藏问题时会不会排查。我前前后后配置过不少服务器的反向代理最深的体会是能不能稳很大程度上取决于前期把后端服务的监听地址、路径设计、请求头传递这些细节是否处理干净。比如一开始就把后端服务全绑在127.0.0.1、提前确认好后端对URL前缀的态度、统一做好请求头透传后面能省掉大量的排障时间。如果这篇文章能帮你少走几个弯路我觉得就值了。最后再分享一个小技巧每次改完Nginx配置都习惯性地随手执行一下nginx -t并把这句命令记在肌肉里这可能是所有运维和开发人员都应该刻进DNA的动作。配置多了之后一个空格一个分号的错误都可能导致服务不可用提前验证永远是成本最低的保障。