说到端口转发，就不得不提端口映射，这两个的概念比较容易混淆。喜欢较真的同学就去查查概念吧……
在知乎看到一个比较有意思的解释：
端口转发：你给我了，我打开看看，发现这上面标志显示是要给张三，那么我就给张三去。如果标志是给李四，那我就再给李四去。
端口映射：你放到我左手，我就直接给张三；你放到我右手，我就直接给李四。这中间我不管你放我手上的是什么东西。
这里我认为应该叫端口映射为好，但是不管是什么都是用了nginx的反向代理模块。
先看图和业务吧
上面这个图呢，假设我们这五台服务器在一个集群里面，但是呢，由于集群内防火墙的原因，你的电脑只能连接1号机器，2、3、4、5访问不了，这个时候我们就需要在1号机器做做文章。通过访问1号机器的不同端口，来间接地访问后面的其他机器。
假设五台机器的IP分别是192.168.1.10、192.168.1.20、192.168.1.30、192.168.1.40、192.168.1.50
OK！那我们直接自定义端口映射配置下Nginx就好了呗？
No No No！我们再具体一下我们的需求。
我们把连接类型划分一下：两种。
第一种：http（对应Nginx http模块）
第二种：tcp/udp（对应Nginx stream模块）
比如我们的web项目，需要用浏览器访问的或其他的基于http协议的，要配置在http模块下。
像SSH,FTP这些，需要配置在stream模块下。
先说http，比如我们2号机器上有一只汤姆猫，端口8080，我们监听1号机器8888端口来映射2号机器的8080端口
http配置示例如下：
http{
proxy_read_timeout 300s;
proxy_send_timeout 300s;
keepalive_requests 1000;
keepalive_timeout 300s;
server{
listen 8888;
location / {
proxy_pass http://192.168.1.20:8080;
}
}
}
这段代码的意思就是，指向我1号机器（192.168.1.10:8888）的连接，都映射到192.168.1.20:8080上面。
参数：
“proxy_read_timeout”：从代理服务器读取响应的超时时间（默认60s），这个可以解决因为代理服务器响应过慢而导致的504 Time-out
“proxy_send_timeout”：向代理服务器发送请求的超时时间（默认60s）
“keepalive_timeout”：设置一个保持活动的客户端连接在服务器端保持打开状态的超时时间（默认75s）
“keepalive_requests”：这个参数默认是100，意思就是，一个连接，在他保持连接的状态内（我们设置的是300s），最多能发送1000个请求，如果超过1000请求，那么nginx会把这个连接断掉
如果我们3、4、5机器上面有数据库或者需要SSH连接的话，就要使用stream模块。
stream配置示例如下：
stream{
proxy_timeout 30m;
server{
listen 1521;
proxy_pass 192.168.1.30:1521;
}
server{
listen 3306;
proxy_pass 192.168.1.30:3306;
}
server{
listen 4022;
proxy_pass 192.168.1.40:22;
}
server{
listen 5022;
proxy_pass 192.168.1.50:22;
}
}
需要访问什么，加上我们自定义的端口号，就大功告成。比如我们要访问3号机器的MySQL，那么我们数据库连接就配置192.168.1.10:3306这样我们就能通过Nginx来轻松访问到192.168.1.30:3306的数据库了。
这里留意一个参数–”proxy_timeout 30m;“
注意：“proxy_timeout”这个参数可以写在stream节点下，所有server都生效，也可以单独写在一个server的节点下
这个参数不写的话，默认连接超时是10min，比如我们使用filezilla，10分钟没有任何动作的话，你的连接就会被干掉，ssh、数据库也是的。这里我保守设置30min，具体看自己的需求。
注意，这个超时并不会影响传输中的数据，比如我们设置成10s，这时候我们从ftp服务器上面下载一个文件，10s没下载完，且你没有任何动作的话，会提示连接已断开，但是实测文件还能继续传输，这应该是传输文件是单独出来的一个连接的缘故。
最后多说一点Nginx的配置。
worker_processes 2;
events{
worker_connections 1024;
}
这是Nginx必须的配置，第一个参数，作者推荐写成处理器逻辑核心的个数，实际带来的最直观的效果就是，启动Nginx之后，一个主进程，外加这个参数的个数进程。比如我服务器32逻辑核心，我写了32。启动之后，33个nginx.exe，你闹不闹心，反正我是很闹心。我自己做过压力测试，3000+并发，这个参数写2都没任何问题。所以我推荐写2或者4即可。
第二个参数是最大连接数，这个就看具体使用环境了。几千几万都可以。
（补充：Windows下worker_processes写多少都只有一个worker在工作，且一个worker只能承受1024连接数，这个官方已经说明，而且我亲自实验了，这是操作系统层面的原因。还有一个点[Linux]就是每个worker能够处理的连接数和ulimit里面的‘open files’参数有关系，大致为“全局最大连接数 = worker数量 * open files 参数”）
最后，我们使用它很方便，最好还能监控。
OK！使用ngx_http_stub_status_module
具体的配置写在http模块下:
server{
location /basic_status {
stub_status;
}
}
这时候我们访问http://192.168.1.10/basic_status，我们就能看到效果了。 文本如下：
Active connections: 22
server accepts handled requests
453 453 67
Reading: 0 Writing: 1 Waiting: 0
第一个就是当前活动的连接数
下面的三个数值分别是 处理连接数/创建握手数/处理请求数
---------------------------------------------------------------------
嗯……文章中有什么不对或者不妥的地方欢迎提出来
【LOG】
2017.12.28 更新： http/stream节点参数
2018.01.06 更新： 补充说明worker_processes参数和worker_connections参数
版权声明：本文来源CSDN，感谢博主原创文章，遵循 CC 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/qq_31226223/article/details/78766314
站方申明：本站部分内容来自社区用户分享，若涉及侵权，请联系站方删除。
