Nginx端口转发是 Linux 服务器中非常常见的一种网络访问配置方式，它可以让客户端访问服务器的某一个端口后，再由 Nginx 将请求转发到本机或者其他服务器上的指定端口。很多人在搭建网站、API 服务、WebSocket 服务、内网应用或者多台服务器之间进行服务分流时，都会接触到端口转发。严格来说，Nginx 本身并不是传统意义上的 NAT 端口转发工具，它主要通过反向代理、TCP/UDP 代理等方式实现“访问一个端口，实际连接另一个服务”的效果。理解这一点非常重要，因为 Nginx 端口转发和 Linux iptables、nftables 所实现的网络层端口转发并不是完全相同的技术。
对于刚开始使用 Linux VPS 或云服务器的用户来说，“端口转发”这个概念容易和“反向代理”“端口映射”“内网穿透”混在一起。比如服务器 A 的 80 端口没有直接运行网站，而真正的应用运行在本机 8080 端口，那么可以让 Nginx 监听 80 端口，再把收到的 HTTP 请求发送到 127.0.0.1:8080。用户访问的仍然是服务器的 80 端口，但后端程序实际监听的是 8080 端口。这样的结构非常适合隐藏后端服务端口、统一处理 HTTPS、配置域名、增加访问控制以及在多个应用之间进行分流。
Nginx端口转发到底是什么
从实际使用角度来看，Nginx端口转发可以理解为一个“请求中转站”。客户端并不需要知道后端服务到底运行在哪一个端口，也不需要直接访问后端程序，而是先连接 Nginx 监听的端口。Nginx 收到请求之后，根据配置文件中的规则找到对应的 upstream 或代理地址，然后建立到后端服务的连接，并把客户端请求转发过去。后端服务处理完成后，再将响应返回给 Nginx，最终由 Nginx 返回给客户端。
例如一台 Linux VPS 的公网 IP 是 203.0.113.10，服务器上的应用程序运行在 127.0.0.1:8080。如果直接访问 http://203.0.113.10:8080，客户端实际上就是直接连接 8080 端口。但是如果使用 Nginx，可以让 Nginx 监听 80 端口，然后把 80 端口收到的 HTTP 请求转发给 127.0.0.1:8080。此时访问流程就变成：
客户端
↓
服务器公网IP:80
↓
Nginx
↓
127.0.0.1:8080
↓
后端应用
从用户角度来看，只需要访问 80 端口或者域名即可，后端的 8080 端口甚至可以只监听本机地址，不需要暴露到公网。这也是 Nginx 端口转发在实际服务器部署中非常常见的原因。
需要注意的是，Nginx 端口转发通常说的是应用层代理，而不是修改数据包目的端口的网络层 NAT。假设你使用 iptables 将 公网IP:8080 映射到 192.168.1.100:80，这种方式属于更加底层的网络转发，Nginx 不参与 HTTP 请求内容。而 Nginx 反向代理则会主动建立新的后端连接，因此它能够读取 HTTP 请求中的域名、URI、请求头等信息，并根据这些内容决定应该把请求发送到哪个后端。
Nginx端口转发的工作原理
Nginx 端口转发最典型的实现方式是 proxy_pass。当客户端向 Nginx 监听的端口发起 HTTP 或 HTTPS 请求时，Nginx 首先接收 TCP 连接，然后根据 server 和 location 配置判断如何处理这个请求。如果匹配到 proxy_pass，Nginx 就会向后端服务器建立连接，并把请求转发过去。
例如下面的配置：
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://127.0.0.1:8080;
}
}
这里的 listen 80 表示 Nginx 监听服务器的 80 端口，server_name example.com 表示这个配置主要处理访问 example.com 的请求，而 proxy_pass http://127.0.0.1:8080 则告诉 Nginx，把匹配到的请求转发到本机 8080 端口。
当用户访问：
http://example.com/
Nginx 收到请求后，并不会让客户端直接连接 8080，而是由 Nginx 自己连接 127.0.0.1:8080。因此从网络连接关系来看，实际上存在两段连接：
客户端 → Nginx:80
Nginx → 后端:8080
这也是为什么 Nginx 可以在中间增加很多额外功能，例如 HTTPS 加密、HTTP Header 修改、访问日志、缓存、限流、IP 黑白名单、压缩以及多个后端服务器之间的负载均衡。
如果后端服务器不是当前这台机器，而是另一台服务器，也可以直接写远程 IP。例如：
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://192.168.1.100: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;
}
}
此时 Nginx 就相当于一台代理服务器。客户端连接 Nginx，Nginx 再连接 192.168.1.100:8080。只要两台服务器之间网络能够互通，就可以完成这种请求转发。
Nginx端口转发和反向代理有什么区别
很多教程直接把 Nginx 端口转发和 Nginx 反向代理当成两个完全不同的功能，其实在 HTTP 场景下，两者往往指的是同一种实现方式。所谓 Nginx 端口转发，很多时候就是通过反向代理把一个监听端口收到的请求发送到另外一个端口。例如 Nginx 监听 80，后端程序监听 8080，这本质上就是通过反向代理实现端口之间的请求转发。
区别主要在描述角度。说“端口转发”时，通常强调的是“80 端口的请求转到 8080”；说“反向代理”时，则更强调网络架构，也就是客户端不知道真正的后端服务器在哪里，所有请求先经过代理服务器，再由代理服务器访问后端。
例如：
用户
↓
example.com:80
↓
Nginx
↓
127.0.0.1:8080
这里既可以说“Nginx 将 80 端口请求转发到 8080”，也可以说“Nginx 作为反向代理，将请求代理到 8080 服务”。
但如果是 TCP 层面的任意端口转发，就不能简单使用 proxy_pass。Nginx 的 HTTP 模块主要处理 HTTP/HTTPS 请求，如果需要转发 SSH、数据库、某些游戏服务或者其他 TCP 服务，就需要使用 Nginx 的 stream 模块。
最简单的Nginx端口转发配置方法
假设服务器已经安装 Nginx，现在有一个 Web 程序运行在：
127.0.0.1:8080
希望通过：
http://服务器IP
访问这个程序，可以创建一个 Nginx server 配置：
server {
listen 80;
server_name _;
location / {
proxy_pass http://127.0.0.1:8080;
}
}
如果使用 Ubuntu 或 Debian 系统，配置文件一般可以放在：
/etc/nginx/sites-available/
例如：
sudo nano /etc/nginx/sites-available/proxy.conf
写入配置以后，可以通过软链接启用：
sudo ln -s /etc/nginx/sites-available/proxy.conf /etc/nginx/sites-enabled/
然后先检查 Nginx 配置是否存在语法错误：
sudo nginx -t
如果看到：
syntax is ok
test is successful
说明配置文件基本没有语法问题，可以重新加载：
sudo systemctl reload nginx
这里建议使用 reload 而不是每次都直接 restart。reload 会让 Nginx 重新读取配置，同时尽可能保持现有连接正常工作，对于生产环境的网站来说更加合适。
使用域名把请求转发到指定端口
实际部署网站时，很少直接让用户通过 IP 访问后端程序，更常见的是使用域名。例如服务器上有一个 Node.js、Python、Java 或其他 Web 服务运行在 3000 端口：
127.0.0.1:3000
希望用户访问：
https://example.com
就可以配置：
server {
listen 80;
server_name 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;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
这里几个 proxy_set_header 参数非常值得注意。因为 Nginx 作为代理服务器以后，后端程序看到的连接来源默认可能是 Nginx，而不是最初访问网站的客户端。如果应用需要获取真实 IP，就需要通过 X-Real-IP 和 X-Forwarded-For 等请求头传递相关信息。
例如：
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
这样后端应用就可以根据代理头获取客户端地址。不过应用程序也应该正确配置可信代理，否则如果直接无条件信任客户端发送的这些 Header，可能产生 IP 伪造等问题。
Nginx HTTPS端口转发怎么配置
如果网站已经启用了 HTTPS，常见结构是：
用户
↓ HTTPS 443
Nginx
↓ HTTP
127.0.0.1:8080
也就是说，客户端和 Nginx 之间使用 HTTPS，而 Nginx 到后端程序之间可以继续使用 HTTP。典型配置如下：
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_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 证书由 Nginx 统一处理。如果服务器上有多个应用，例如 3000、4000、5000 分别运行不同网站，就可以通过不同域名把请求转发到不同端口。
例如：
a.example.com → 127.0.0.1:3000
b.example.com → 127.0.0.1:4000
c.example.com → 127.0.0.1:5000
这样一台 VPS 就可以承载多个独立 Web 服务。
Nginx转发到另一台服务器
Nginx 不只能转发到本机端口，也可以转发到远程服务器。例如：
客户端
↓
Nginx服务器
↓
192.168.1.100:8080
配置可以写成：
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://192.168.1.100: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;
}
}
这种方式在前后端分离、内网服务代理以及多服务器部署中比较常见。例如公网服务器只负责接受用户请求，而真正的应用服务器放在内网环境中。只要 Nginx 所在服务器能够访问后端服务器，就可以建立代理连接。
不过这里要注意防火墙问题。Nginx 服务器必须能够访问后端的 8080 端口，同时后端服务器也需要允许来自 Nginx 服务器的连接。如果后端端口被安全组、iptables、nftables 或云平台防火墙拦截，即使 Nginx 配置完全正确，也会出现 502 Bad Gateway。
Nginx转发TCP端口的方法
如果需要转发的不是 HTTP，而是普通 TCP 服务，就应该考虑 Nginx 的 stream 模块。例如某个 TCP 服务运行在：
127.0.0.1:9000
希望 Nginx 对外监听：
9001
可以使用类似：
stream {
server {
listen 9001;
proxy_pass 127.0.0.1:9000;
}
}
这样访问服务器的 9001 端口时，Nginx 会将 TCP 连接代理到本机 9000 端口。
需要注意，stream 配置和普通 HTTP server 配置所在的位置不同。它不是简单地把 stream 放进 http {} 里面。具体配置位置需要根据当前 Nginx 的主配置结构进行调整。
如果执行：
nginx -t
提示类似：
unknown directive "stream"
则可能意味着当前 Nginx 没有安装或加载对应的 Stream 模块。可以先检查：
nginx -V 2>&1 | grep stream
不同 Linux 发行版安装方式不同，因此不要看到网上某个命令就直接复制执行，最好先确认当前 Nginx 的编译参数以及系统的软件包来源。
Nginx端口转发常见错误
出现502 Bad Gateway怎么办？
502 Bad Gateway 是 Nginx 端口代理中非常常见的问题，通常意味着 Nginx 无法正常从后端获得有效响应。首先不要急着修改 Nginx 配置，可以直接测试后端服务是否真的运行：
curl http://127.0.0.1:8080
如果这里无法访问，那么问题很可能不是 Nginx，而是后端程序没有启动、监听地址错误或者端口写错。
还可以检查监听情况：
ss -lntp
例如看到：
LISTEN 0 128 127.0.0.1:8080
说明 8080 确实有程序监听。
如果后端运行在另一台服务器，可以测试：
curl http://192.168.1.100:8080
如果连接失败，则需要继续检查服务器之间的网络、防火墙、安全组以及路由。
修改配置后Nginx没有生效怎么办？
修改文件以后不要忘记：
sudo nginx -t
sudo systemctl reload nginx
很多所谓“配置不起作用”的问题，其实只是编辑了一个没有被 Nginx 加载的配置文件。可以使用：
nginx -T
查看 Nginx 当前实际加载的完整配置，从中确认自己的 server 是否已经生效。
为什么访问域名没有进入指定端口？
如果服务器配置了多个 server，可能存在 server_name 匹配问题。例如：
server {
listen 80;
server_name example.com;
}
那么访问其他域名时不会按照这个规则处理。还需要检查 DNS 是否真正指向当前服务器，以及 CDN、代理服务或者本地 DNS 缓存是否影响了请求。
Nginx端口转发是否需要开放后端端口
如果后端程序只供 Nginx 在本机访问，例如：
Nginx → 127.0.0.1:8080
通常没有必要把 8080 对公网开放。相反，把后端服务限制为 127.0.0.1 往往更加合理，因为用户只能通过 Nginx 访问服务。
例如：
公网
↓
80/443
↓
Nginx
↓
127.0.0.1:8080
此时防火墙只需要允许必要的公网端口即可。
但如果后端服务器是独立机器：
公网
↓
Nginx
↓
192.168.1.100:8080
那么后端服务器需要允许 Nginx 服务器访问 8080。不过也没有必要把 8080 对整个互联网开放，可以只允许 Nginx 服务器的 IP 连接，从而缩小攻击面。
Nginx端口转发和iptables端口转发怎么选择
如果你的需求是“用户访问一个 Web 地址，然后把请求交给 Node.js、PHP、Java、Python 等 Web 应用”，Nginx 通常更方便，因为它不仅能够完成代理，还可以处理 HTTPS、域名匹配、Header、缓存和日志等功能。
如果需求是纯粹修改网络层的数据包目的地址，例如把公网服务器某个 TCP/UDP 端口透明地转发到另一台机器，iptables 或 nftables 通常更加符合这种场景。它们属于操作系统网络层面的功能，而 Nginx 更偏向应用代理。
因此，不要简单认为“Nginx端口转发就是iptables端口转发的替代品”。两者解决的问题存在重叠，但工作层次不同。尤其是 UDP、透明转发、NAT、复杂网络路由等场景，需要根据实际需求选择对应方案。
配置Nginx端口转发时需要注意什么
实际部署过程中，最容易忽略的并不是 Nginx 配置语法，而是整个链路是否能够正常通信。建议按照“客户端 → Nginx监听端口 → Nginx代理目标 → 后端程序”的顺序逐层排查。首先确认域名解析正确，其次确认云服务器安全组允许访问 Nginx 监听端口，再检查 Linux 防火墙，然后确认后端服务是否监听正确地址和端口，最后通过 Nginx 日志定位请求到底在哪一步失败。
Nginx 日志通常位于：
/var/log/nginx/access.log
/var/log/nginx/error.log
遇到 502、504、连接超时或者请求异常时，直接查看错误日志往往比反复修改配置更加有效。例如：
sudo tail -f /var/log/nginx/error.log
然后重新访问网站，可以实时观察 Nginx 到后端建立连接时发生了什么。
对于生产环境，还建议不要把所有服务都直接暴露到公网。能够只监听 127.0.0.1 的应用尽量不要监听 0.0.0.0，需要跨服务器访问的服务则通过防火墙限制来源 IP。Nginx 本身作为公网入口，可以集中处理 HTTPS、访问日志、域名路由和访问控制，这样服务器的网络结构也更清晰。
总结
Nginx端口转发本质上是一种通过 Nginx 接收客户端连接，再将请求代理到指定后端地址和端口的方式。在最常见的 Web 场景中，它通常通过 proxy_pass 实现，例如 Nginx 监听 80 或 443，而后端应用运行在 3000、8080、9000 等端口。对于普通 HTTP/HTTPS 服务，使用 proxy_pass 就可以完成大多数端口转发需求；对于 TCP 等非 HTTP 服务，则可以根据 Nginx 是否安装 Stream 模块使用 stream 代理。
真正使用 Nginx 做端口转发时，最重要的是理解它和传统 NAT 的区别。Nginx 并不是简单地修改数据包目的端口，而是作为代理服务器建立前后两段连接，因此可以进一步实现 HTTPS、域名分流、Header 处理、访问日志和负载均衡等功能。掌握 listen、server_name、location、proxy_pass、proxy_set_header 这些核心配置之后，大多数常见的 Nginx 端口转发场景都可以独立完成。
如果只是把一个 Web 应用从 8080 转到 80/443，Nginx 是非常常见的解决方案；如果是做底层 NAT、TCP/UDP 网络转发，则应该根据具体网络结构考虑 iptables、nftables 或其他专用代理工具。理解应用层代理和网络层转发之间的区别，比单纯记住几段 Nginx 配置更加重要。
常见问题解答
Nginx端口转发一定要使用proxy_pass吗？
对于 HTTP/HTTPS 请求，最常见的端口转发方式就是 proxy_pass。如果需要代理 TCP 服务，则可以使用 stream 模块。具体使用哪种方式，要根据实际服务协议决定。
Nginx可以把80端口转发到8080端口吗？
可以。例如：
server {
listen 80;
location / {
proxy_pass http://127.0.0.1:8080;
}
}
配置完成后使用 nginx -t 检查，然后执行 systemctl reload nginx 重新加载配置。
Nginx端口转发后为什么出现502？
最常见的原因是后端程序没有运行、端口写错、监听地址不正确、防火墙阻止连接或者 Nginx 无法访问远程后端。可以先使用 curl 和 ss -lntp 检查后端服务，再查看 /var/log/nginx/error.log。
Nginx端口转发和反向代理是一样的吗？
在常见的 HTTP 场景下，两者通常是在描述同一种代理过程，只是强调的角度不同。端口转发强调“请求从一个端口进入后被送到另一个端口”，反向代理则强调“Nginx 位于客户端和后端服务之间”。但如果涉及 Linux NAT 或底层网络转发，两者就不是同一个概念。
