nginx tcp代理特别说明(解决项目中telnet端口打不开的问题)

文章讲述了telnet虚拟IP端口打开缓慢的问题,通过调整Nginx配置文件,特别是增加worker_connections和proxy_timeout参数,解决了响应速度问题。具体步骤包括检查服务器负载、增大连接数并重启Nginx。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 问题现象

telnet虚拟ip的端口打开慢,导致打不开

解决办法

调整配置文件

正确配置文件如下

user  nginx;

worker_processes  20;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;


events {
    worker_connections  102400;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
 
    sendfile        on;

     # 限制文件上传大小
    client_max_body_size 1024m; 

    keepalive_timeout  65;
 
    upstream backend {
      server 10.160.91.253:8082;
    }
 
 
    server {
        listen       8082;
        server_name  localhost;
        # listen       8161;
        # server_name  localhost; 
    
        location / {
            proxy_pass http://backend;
        }
 
        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
        
    }
    


}

stream {
  
    # tcp负载均衡
    #中间件
    upstream agent{
      server 10.160.91.253:5000;
    }
    server {
        listen 5000;
      
        ###proxy_timeout 24h;
       
        proxy_pass agent;
    }
    
    #mssql数据库连接
    upstream mssql{
      server 10.160.91.253:1433 max_fails=60 fail_timeout=60s;
    
    }
    server {
        listen 1433;
        proxy_connect_timeout 30s;
		    proxy_timeout 10m;
        ###proxy_timeout 24h;
        ###这个参数在使用EMQ压力测试时很有用,刚开始设备的超时时间过段,导致测试一小会儿就出现 {shutdown,connack_timeout}
        proxy_pass mssql;
    }


    #流媒体
    upstream easyd{
      server 10.160.91.253:554 max_fails=5 fail_timeout=10s;
    }
    server {
        listen 554;
        proxy_connect_timeout 5s;
		    proxy_timeout 10m;
        ###proxy_timeout 24h;
        ###这个参数在使用EMQ压力测试时很有用,刚开始设备的超时时间过段,导致测试一小会儿就出现 {shutdown,connack_timeout}
        proxy_pass easyd;
    }

    #mq连接
    upstream mq{
      server 10.160.91.253:61616 max_fails=5 fail_timeout=10s;
   
    }
    server {
        listen 61616;
        proxy_connect_timeout 5s;
		    proxy_timeout 10m;
        ###proxy_timeout 24h;
        ###这个参数在使用EMQ压力测试时很有用,刚开始设备的超时时间过段,导致测试一小会儿就出现 {shutdown,connack_timeout}
        proxy_pass mq;
    }

    # UDP转发
    # 控制台插播
    upstream udp_kzt {
      server 10.160.91.253:30001;
    }

    server {
        listen 30001 udp;
        proxy_pass udp_kzt;
        proxy_timeout 30s;
        proxy_responses 10;
    }

    # 回传
    upstream udp_return {
      server 10.160.91.253:8550;
    }

    server {
        listen 8550 udp;
        proxy_pass udp_return;
        proxy_timeout 30s;
        proxy_responses 10;
    }

}

重点配置

我看了下实体服务器上5000端口已经又3000多个链接了,nginx这边响应慢了

这个配置设置大了之后,速度明显快了不少。 

可以根据实际情况再进行调整,把他调整大

具体处理流程

打开nignx配置文件

修改为20(会占用更多内存,根据实际情况修改),保存

重启nginx

systemctl restart nginx

telnet测试

可以发现明显快多了

<think>首先,用户的问题是关于Nginx配置的:他们希望当后端服务端口(比如18000)失效时,代理端口(18001)能自动下线,这样telnet到18001端口就不会成功。目前,即使后端服务失效,18001端口仍然可达,这不是他们想要的。 从系统指令中,我需要: - 使用$...$格式表示行内数学表达式(但这里可能不涉及)。 - 独立公式用$$...$$格式(可能不适用)。 - LaTeX语法正确(但问题主要是技术性的,不太需要数学)。 - 使用中文回答。 - 生成相关问题。 - 在回答中引用的段落末尾添加引用标识,如[^1]。 用户提供了几个引用: - [^1]: Nginx配置了server和端口20002,但telnet不通,显示连接被拒绝。 - [^2]: Nginx反向代理的服务端口没启动。 - [^3]: Telnet端口时,如果端口没有进程监听,就telnet不到;开启服务后就可以。 - [^4]: Nginx代理telnet端口的连接情况。 用户的核心问题是:如何配置Nginx的健康检查,以便当后端服务端口(18000)失效时,代理端口(18001)自动下线,从而telnet不通。 关键点: - Nginx作为反向代理,监听18001端口代理到后端的18000端口。 - 当18000端口服务失效(例如,服务停止),Nginx仍然监听18001端口,所以telnet 18001成功。 - 用户希望在这种情况下,18001端口不可达,意味着Nginx应该停止监听或拒绝连接。 在Nginx中,代理端口(18001)是Nginx自己监听的端口。即使后端服务失效,Nginx仍然在监听这个端口,所以telnet会成功,但实际请求会失败(例如,返回502错误)。用户想让telnet也失败,这意味着Nginx应该完全停止监听端口或拒绝连接。 标准行为: - Nginx监听端口:当Nginx运行并配置了监听某个端口(如18001),它就会监听该端口,接受连接。 - 如果后端服务失效,Nginx可能返回错误(如502),但端口本身是可达的。 - 要让端口不可达,Nginx必须停止监听该端口或系统防火墙阻止连接。 但用户可能误解了:他们可能想让Nginx在检测到后端服务失效时,自动停止监听代理端口或标记为不可用。然而,Nginx本身不提供动态停止监听端口的功能;监听端口是静态配置的。 可能的解决方案: 1. **健康检查(Health Checks)**:Nginx Plus(商业版)支持主动健康检查,可以自动将不健康的后端从负载均衡池中移除。但开源Nginx(免费版)只支持被动健康检查(基于请求失败)。 2. **使用第三方模块或工具**:对于开源Nginx,可以使用nginx_upstream_check_module或其他模块来实现主动健康检查。 3. **结合外部脚本**:编写脚本监控后端服务,如果失效,则修改Nginx配置并重载Nginx,例如移除或禁用该server块。 4. **防火墙规则**:动态调整防火墙规则,当后端服务失效时,阻止到代理端口的连接。 用户的具体需求:当18000端口失效时,18001端口不可达(telnet失败)。所以,Nginx需要停止监听18001端口或阻止连接。 在Nginx配置中,监听端口是固定的。要动态改变,需要外部机制。 建议的解决方案: - 使用Nginx Plus的主动健康检查(如果可用)。 - 对于开源Nginx,使用nginx_upstream_check_module模块(需要编译Nginx时包含)。 - 或者,使用一个cron脚本或监控工具(如consul、prometheus + blackbox exporter)检测后端状态,并调用脚本修改Nginx配置(例如,注释掉server块)并重载Nginx。 配置示例: 假设Nginx配置如下: ``` upstream backend { server 127.0.0.1:18000; } server { listen 18001; location / { proxy_pass http://backend; } } ``` 添加健康检查: - 对于开源Nginx,可以使用`max_fails`和`fail_timeout`进行被动健康检查: ``` upstream backend { server 127.0.0.1:18000 max_fails=1 fail_timeout=10s; } ``` 这会在请求失败时暂时将后端标记为不可用,但代理端口仍然监听。 要让代理端口不可达,需要更激进的方法:动态修改配置。 一个常见的方法是使用外部健康检查脚本: 1. 编写一个脚本检查18000端口是否存活(例如,使用netcat或curl)。 2. 如果端口失效,修改Nginx配置(例如,重命名或移除server块),然后重载Nginx。 3. 当端口恢复时,恢复配置。 但这可能过度,因为重载Nginx会影响所有服务。 更好的方法:使用Nginx的主动健康检查模块。 参考引用: - [^2]提到proxy_connect_timeout和proxy_timeout,但这些是超时设置,不是健康检查。 - [^3]表明如果端口没有进程,telnet失败。 回答结构: 1. **理解问题**:解释当前行为。 2. **解决方案**:提供配置方法。 3. **配置示例**:给出Nginx配置代码。 4. **注意事项**:讨论局限性。 5. **生成相关问题**:在末尾添加相关问题。 生成相关问题: - 如何安装nginx_upstream_check_module? - Nginx健康检查的最佳实践? - 如何监控Nginx后端服务状态? 确保回答真实可靠:基于Nginx文档和常见实践。</think>### 解决Nginx代理后端服务端口失效后代理端口仍可达的问题 您的需求是:当Nginx代理的后端服务端口(如18000)失效时,代理端口(如18001)也应自动不可达(例如telnet失败),避免用户误以为服务可用。当前问题在于,Nginx默认会持续监听代理端口,即使后端服务宕机,telnet代理端口仍会成功(但实际请求会返回502错误)。这可能导致服务不可用时的误判[^2]。 #### 问题分析 - **Nginx行为原理**:Nginx作为反向代理,监听代理端口(18001)并转发请求到后端端口(18000)。如果后端服务停止(18000端口无进程监听),Nginx仍会接受新连接(telnet成功),但处理请求时会返回502错误[^1][^3]。 - **健康检查缺失**:开源Nginx(免费版)默认只支持被动健康检查(基于请求失败),不会动态停止监听端口或标记代理端口不可达。 - **目标解决方案**:通过配置主动健康检查,当检测到后端服务失效时,自动将后端标记为“不可用”,并结合Nginx重载或外部工具动态调整监听状态,使代理端口(18001)在telnet时失败(连接被拒绝)。 #### 解决方案步骤 要让Nginx在检测到后端端口(18000)失效时,自动使代理端口(18001)不可达,需结合以下方法: 1. **启用主动健康检查**:使用Nginx模块(如`nginx_upstream_check_module`)或Nginx Plus(商业版)实现。 2. **动态修改配置**:通过脚本监控后端状态,自动重载Nginx配置(例如,临时移除监听配置)。 3. **配置示例**:以下以开源Nginx为例,使用`nginx_upstream_check_module`模块(需编译安装)。 ##### 步骤1: 安装并配置健康检查模块 如果尚未安装`nginx_upstream_check_module`,需重新编译Nginx: ```bash # 下载模块 wget https://github.com/yaoweibin/nginx_upstream_check_module/archive/master.zip unzip master.zip # 重新编译Nginx(假设已安装Nginx源码) cd nginx-<version> patch -p1 < /path/to/nginx_upstream_check_module-master/check_<version>.patch ./configure --add-module=/path/to/nginx_upstream_check_module-master make && make install ``` ##### 步骤2: 修改Nginx配置 编辑Nginx配置文件(如`/etc/nginx/nginx.conf`),添加主动健康检查和动态响应机制: ```nginx http { upstream backend { server 127.0.0.1:18000; # 后端服务地址 check interval=3000 rise=2 fall=3 timeout=1000 type=tcp; # 主动健康检查:每3秒检查一次,失败3次标记不可用 } server { listen 18001; # 代理监听端口 location / { proxy_pass http://backend; # 当后端不可用时,返回特定错误或拒绝连接 error_page 502 =503 @down; } location @down { # 模拟端口不可达:返回503并关闭连接 return 503 "Service Unavailable"; # 可选:结合脚本动态移除监听(见步骤3) } } } ``` - **关键参数解释**: - `check interval=3000`: 每3秒检查一次后端端口(18000)是否存活。 - `rise=2 fall=3`: 连续成功2次标记为健康,失败3次标记为不健康。 - `type=tcp`: 使用TCP检查(检测端口是否开放),替代HTTP检查以节省资源。 - `error_page 502 =503 @down`: 当后端失效时,将502错误转为503,并触发`@down`位置块。 - **效果**:当后端端口(18000)失效时: - Telnet 18001会连接成功(因为Nginx仍在监听),但请求会立即返回503错误。 - 要完全使telnet失败,需结合动态配置重载(见步骤3)。 ##### 步骤3: 添加脚本动态调整监听状态(使telnet失败) 仅靠Nginx配置无法完全停止监听端口。需外部脚本监控后端状态,并修改Nginx配置: 1. **创建监控脚本**(如`/scripts/health_check.sh`): ```bash #!/bin/bash BACKEND_PORT=18000 PROXY_PORT=18001 CONFIG_FILE="/etc/nginx/nginx.conf" # 检查后端端口是否存活 nc -z 127.0.0.1 $BACKEND_PORT if [ $? -ne 0 ]; then # 后端失效 # 修改配置:注释掉代理端口的server块 sed -i "s/listen $PROXY_PORT;/#listen $PROXY_PORT;/g" $CONFIG_FILE nginx -s reload # 重载Nginx else # 后端恢复 # 恢复配置 sed -i "s/#listen $PROXY_PORT;/listen $PROXY_PORT;/g" $CONFIG_FILE nginx -s reload fi ``` 2. **设置cron任务定期运行**(例如每分钟检查): ```bash crontab -e # 添加行 * * * * * /bin/bash /scripts/health_check.sh ``` - **效果**:当18000端口失效时,脚本自动注释掉Nginx中的`listen 18001;`行并重载Nginx,使18001端口停止监听,telnet会失败(Connection refused)[^3]。当后端恢复时,脚本恢复配置。 #### 注意事项 - **性能影响**:频繁重载Nginx(步骤3)可能导致短暂服务中断,建议在低峰期执行。健康检查间隔(如`interval=3000`)可根据需求调整。 - **替代方案**: - 使用Nginx Plus:支持内置主动健康检查,无需外部脚本(配置更简单)。 - 结合防火墙:当后端失效时,脚本调用`iptables`或`firewall-cmd`阻止18001端口(例如`firewall-cmd --add-port=18001/tcp` 或 `--remove-port`)[^3]。 - **测试建议**: 1. 启动后端服务(监听18000)。 2. Telnet 18001确认可达。 3. 停止后端服务,观察脚本是否触发(日志在`/var/log/nginx/error.log`)。 4. Telnet 18001应失败(Connection refused)。 - **局限性**:开源Nginx的健康检查模块需手动编译;动态重载可能不适用于高可用场景,建议结合Consul或Prometheus等工具增强可靠性[^2][^4]。 通过以上配置,Nginx能在后端服务失效时自动使代理端口不可达,提升服务可观测性。如需进一步优化,可参考Nginx官方文档或社区资源[^1][^4]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

三希

如果这篇文章帮您解决了技术难题

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值