nginx connect() 失败（110：连接超时）

Posted 2023-02-24

【中文标题】nginx connect() 失败（110：连接超时）

【英文标题】：nginx connect() failed (110: Connection timed out)

【发布时间】：2016-06-07 15:29:53

【问题描述】：

我知道，这个问题已经在不同的论坛上被问过多次，但我仍然无法找到解决我的问题的解决方案......情况：我们有一个 nginx、php-fpm 和 mysql 堆栈在服务器上。服务器位于 nginx 反向代理后面。问题是在上游服务器上有干净的错误日志，而在反向代理上我收到了多条消息

connect() 在连接到 >upstream 时失败（110：连接超时），客户端：++++++++++，服务器：domain.com，请求：“GET >/files/imagecache/FrontBullet /blog1/dknasda.jpg HTTP/1.1"，上游：>"http://192.168.158.142:80/files/imagecache/FrontBullet/blog1/dknasda.jpg>"，主机："somedomain.com"

由于某种原因，对于不同的资源或文件，此错误每 1-5 分钟发生一次。

我在反向代理上的 nginx 配置如下：

    user ++++;
worker_processes 3;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

events 
    worker_connections 1024;
    use epoll;


http 
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   60s; #keeps the connection open with the client; MS default is 60.
    types_hash_max_size 2048;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    gzip on; 
    gzip_http_version 1.1; 
    gzip_vary on; 
    gzip_comp_level 6; 
    gzip_proxied any; 
    gzip_types text/plain  text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript text/x-js; 
    gzip_buffers 16 8k; 
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";

    upstream main_upstream 

        server 192.168.158.142:80 max_fails=3  fail_timeout=60s;  #       New Server. Sent to 192.168.90
#   server 192.168.158.143:80;   #       HSB
    keepalive 32;
    

server 
    listen       80 default_server;
    listen       [::]:80 default_server;
    server_name  domain.com;

    location / 
        proxy_buffers 32 32k;
        proxy_buffer_size 64k;
        proxy_pass http://main_upstream;
        proxy_set_header    Host $host;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto $scheme;
        proxy_set_header    X-Forwarded-By $server_addr:$server_port;
            proxy_set_header    X-Real-IP $remote_addr;
        proxy_connect_timeout       600s;
        proxy_send_timeout          600s;
        proxy_read_timeout          600s;
        send_timeout                600s;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        client_max_body_size                            32M;
        client_body_buffer_size                         512k;
    
    error_page 404 /404.html;
        location = /40x.html 
    

    error_page 500 502 503 504 /50x.html;
        location = /50x.html 
    

知道为什么会这样吗？我正在使用 centos 7.1 abd nginx 1.6.3

提前致谢， 托多尔

【问题讨论】：

这不是您的 nginx 问题...很可能是您的上游（Apache？）每隔几分钟就会崩溃并重新启动（或阻塞 nginx ip）

上游又是nginx，上游的错误日志一目了然。如果您有任何其他想法或向我指出如何检查它，我将不胜感激。

确实，您的上游错误很清楚。它告诉你 nginx 请求了某些东西，而某些东西没有回复给 nginx。这不是 nginx 问题，而是您在上游块中列出的那些 ip 上侦听的任何服务器。你在其他服务器上运行 nginx 吗？

【参考方案1】：

终于找到原因了，已经清理了好几个小时了。原来有两个重叠的问题。第一个是队列满后内核丢弃请求。这是一本关于调整内核 linux 内核参数的不错的手册 - https://www.nginx.com/blog/tuning-nginx/

问题开始后，我们将站点迁移到新服务器并使用 DHCP 分配 IP 地址 - 大错特错。每隔一小时左右，dhcp 都会重新启动网络接口。检查整个系统日志，我注意到网络接口的 IP 会定期重新分配。这些时间间隔与日志中错误的爆发相吻合。所以解决方案是回到静态 IP。

【参考方案2】：

你有一个这样的上游块：

upstream main_upstream 
    server 192.168.158.142:80 max_fails=3  fail_timeout=60s;  # New Server. Sent to 192.168.90
#   server 192.168.158.143:80;   #       HSB
    keepalive 32;
    

第一行从 192.168.158.142:80 获取请求并在 3 失败 60 秒后停止尝试。 第二行被注释掉了，所以它不起作用。 您的其他 cmets 上还列出了其他 ip，这显然不起作用。

假设您想从 192.168.158.142:80 获取请求并在失败时故障转移到另一个 ip 192.168.158.143:80，您就是这样做的：

upstream main_upstream 
        keepalive 30;
        server 192.168.158.142:80;        # main server
        server 192.168.158.143:80 backup; # failover

或者，如果您想以循环方式均匀分配负载：

upstream main_upstream 
        keepalive 30;
        server 192.168.158.142:80; # server 1
        server 192.168.158.143:80; # server 2

在这两种情况下，请确保您可以同时访问 192.168.158.142:80 和 192.168.158.143:80

还请记住，您使用的是 keepalive，这意味着如果您的后端服务器设置为以任何方式限制请求，它们可能会开始拒绝向您的前端 nginx 提供请求（我假设这是您的负载均衡器） .

【讨论】：

您好，首先感谢您的回复。对于您的第二个帖子：我们只需要一台服务器 - 192.168.158.142 。另一个是我们关闭主节点时维护窗口的 HotStandBy。上游服务器确实又是 nginx，充当带有 php-fpm 的 Web 服务器。问题是为什么它没有回复反向代理的请求......到目前为止我一无所知，因为上游服务器的错误日志很清楚。我只是手动检查，大多数请求的资源都在服务器上（没有 404），并且它们由 rproxy 正确提供，它们是静态的和动态的..

您从哪里阅读这些110: Connection timed out 日志？它是在负载均衡器上还是后端服务器上？如果它在负载均衡器（前端）上，那么您的后端不会回复反向代理。如果您在后端服务器上看到这些日志，则意味着 php 没有回复您的后端服务器，因此永远无法回复您的前端。您可以在此处发布两个 nginx.conf 文件（用于前端和后端服务器），我们可能会查看是否有问题。如果在单独的文件中，还要添加您的服务器和位置块。

错误在负载均衡器上。由于某些未知的原因，后端服务器每 20 分钟决定不响应来自前端的获取请求。这些是后端配置文件。为了说服pastebin.com/DsH0vbtt，它们被粘贴在一起。我做了 MariaDB 调整，php 调整，增加了打开文件限制，增加了打开端口限制等。没有任何效果。我开始认为问题出在 php 脚本中。似乎有些东西使后端 nginx 无响应。此外，后端错误日志很清楚。里面什么都没有。提前致谢

我忘了提到这些超时发生在静态资源和动态资源中。更奇怪的是，它们似乎出现在 16.02 前后，并且没有系统更新或任何类型的更改。据我所知，托管网站的模板中只有一些小的静态代码 (HTML) 更改。

好的，我看到了一些不应该这样配置的东西，所以让我问你一些事情......你有多少RAM，你有什么CPU以及多少请求（每秒动态 + 静态）您希望从后端提供服务吗？为什么你有 3 个上游服务器 server 127.0.0.1:9000; server 127.0.0.1:9001; server 127.0.0.1:9002; ？这些服务器是不同的版本还是php或什么？用于 drupal 的 Nginx 应如下所示：nginx.com/resources/wiki/start/topics/recipes/drupal