502坏网关：nginx，php5 fpm，175/209 connect（）在连接到上游时失败（111:连接被拒绝）

在Debian Jessie机器上使用nginx和php5 fpm运行shopware 5时，我们经常会遇到502坏网关。这主要发生在后端，当较长的操作像缩略图创建一样工作时，即使这是在单个ajax请求的小块中完成的

使用过的带有64 GB RAM和16个内核的服务器完全处于休眠状态，因为上面没有真正的流量。我们现在使用它就像一个登台系统，除非我们已经修复了所有像这样的错误

错误日志： 在nginx错误日志中，可以找到以下行：

[error] 20524#0: *175 connect() failed (111: Connection refused) while connecting to upstream, client: xx.xx.xx.xx, server: domain.com, request: "POST /backend/MediaManager/createThumbnails HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.domain.com", referrer: "http://www.domain.com/backend/"

[error] 20524#0: *175 no live upstreams while connecting to upstream, client: xx.xx.xx.xx, server: domain.com, request: "POST /backend/Log/createLog HTTP/1.1", upstream: "fastcgi://php-fpm", host: "www.domain.com", referrer: "http://www.domain.com/backend/"

[error] 20524#0: *175 connect() failed (111: Connection refused) while connecting to upstream, client: xx.xx.xx.xx, server: domain.com, request: "GET /backend/login/getLoginStatus?_dc=1457014588680 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.domain.com", referrer: "http://www.domain.com/backend/"

[error] 20522#0: *209 connect() failed (111: Connection refused) while connecting to upstream, client: xx.xx.xx.xx, server: domain.com, request: "GET /backend/login/getLoginStatus?_dc=1457014618682 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.domain.com", referrer: "http://www.domain.com/backend/"

可能值得注意的是，首先出现了大量的“*175 connect”错误，然后出现了“*209 connect”

配置文件： 我将尽量只发布与本主题相关的重要行，并将删除所有被注释掉的行

php fpm： /etc/php5 fpm/pool.d/www.conf：

[www]
user = www-data
group = www-data
listen = /var/run/php5-fpm.sock
listen.owner = www-data
listen.group = www-data
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

nginx: /etc/nginx/nginx.conf：

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
    worker_connections 768;
    multi_accept on;
}

http {
    ## MIME types.
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ## Default log and error files.
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ## Use sendfile() syscall to speed up I/O operations and speed up
    ## static file serving.
    sendfile        on;

    ## Handling of IPs in proxied and load balancing situations.
    # set_real_ip_from        192.168.1.0/24; # set to your proxies ip or range
    # real_ip_header          X-Forwarded-For;

    ## Timeouts.
    client_body_timeout             60;
    client_header_timeout           60;
    keepalive_timeout            10 10;
    send_timeout                    60;

    ## Reset lingering timed out connections. Deflect DDoS.
    reset_timedout_connection on;

    ## Body size.
    client_max_body_size 10m;

    ## TCP options.
    tcp_nodelay        on;
    ## Optimization of socket handling when using sendfile.
    tcp_nopush         on;

    ## Compression.
    gzip              on;
    gzip_buffers      16 8k;
    gzip_comp_level   1;
    gzip_http_version 1.1;
    gzip_min_length   10;
    gzip_types        text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript image/x-icon application/vnd.ms-fontobject font/opentype application/x-font-ttf;
    gzip_vary         on;
    gzip_proxied      any; # Compression for all requests.
    gzip_disable      "msie6";

    ## Hide the Nginx version number.
    server_tokens off;

    ## Upstream to abstract backend connection(s) for PHP.
    upstream php-fpm {
        server unix:/var/run/php5-fpm.sock;
        # server 127.0.0.1:9000;

        ## Create a backend connection cache.
        keepalive 32;
    }

    ## Include additional configs
    include /etc/nginx/conf.d/*.conf;

    ## Include all vhosts.
    include /etc/nginx/sites-enabled/*;
}

/etc/nginx/sites available/site.conf：

server {
    listen 80;
    listen 443 ssl;

    server_name xxxxxxxx.com;
    root /var/www/shopware;

    ## Access and error logs.
    access_log /var/log/nginx/xxxxxxxx.com.access.log;
    error_log  /var/log/nginx/xxxxxxxx.com.error.log;

    ## leaving out lots of shopware/mediafiles-related settings
    ## ....
    ## continue:

    location ~ \.php$ {
        try_files $uri $uri/ =404;

        ## NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
        fastcgi_split_path_info ^(.+\.php)(/.+)$;

        ## required for upstream keepalive
        # disabled due to failed connections
        #fastcgi_keep_conn on;

        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param SHOPWARE_ENV    $shopware_env if_not_empty;
        fastcgi_param ENV             $shopware_env if_not_empty; # BC for older SW versions

        fastcgi_buffers 8 16k;
        fastcgi_buffer_size 32k;

        client_max_body_size 24M;
        client_body_buffer_size 128k;

        ## upstream "php-fpm" must be configured in http context
        fastcgi_pass php-fpm;
    }

}

现在该怎么办？请让我现在是否应该提供进一步的资料，这个问题

更新 从@peixotroms应用nginx-和fpm设置后，nginx日志中的错误更改为：

30 upstream timed out (110: Connection timed out) while reading response header from upstream

---

但问题本身并没有得到解决。它只是另一张脸…

您可能觉得奇怪，但您的问题很可能是因为您在套接字上而不是tcp端口上运行PHP。当在套接字配置上有大约300个对php的并发请求（有时更少）时，您将开始看到502个错误（以及其他错误）

另外，您的

pm.max_子项
太低，除非您想将服务器限制在最多5个同时的php请求：

通过这种方式进行配置，这些错误应该会消失：

对于nginx.conf更改以下值：

worker_processes 4; 
worker_rlimit_nofile 750000;

# handles connection stuff
events { 
worker_connections 50000;
multi_accept on;
use epoll;
}

upstream php-fpm {
        keepalive 30;
        server 127.0.0.1:9001;
}

您的/etc/php5 fpm/pool.d/www.conf

（使用这些设置是因为您有足够的内存和CPU）

在
位置~\.php${
块上也添加此项：

location ~ \.php$ {
        try_files $uri $uri/ =404;

        ## NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
        fastcgi_split_path_info ^(.+\.php)(/.+)$;

        ## required for upstream keepalive
        # disabled due to failed connections
        #fastcgi_keep_conn on;

        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param SHOPWARE_ENV    $shopware_env if_not_empty;
        fastcgi_param ENV             $shopware_env if_not_empty; # BC for older SW versions

        fastcgi_keep_conn on;
        fastcgi_connect_timeout 20s; 
        fastcgi_send_timeout 60s; 
        fastcgi_read_timeout 60s;
        fastcgi_pass php-fpm;
    }

编辑：

将
/etc/php5/fpm/php.ini
文件中的以下值更改为该值，然后重新启动：

safe_mode = Off    
output_buffering = Off
zlib.output_compression = Off
max_execution_time = 900
max_input_time = 900
memory_limit = 2048M
post_max_size = 120M
file_uploads = On
upload_max_filesize = 120M

尝试绑定到0.0.0.0:9000：

listen = 0.0.0.0:9000

我们在一台测试机器上遇到了同样的问题。最后我们发现它是由php扩展引起的，在我们的例子中，
opcache
，删除该扩展解决了问题。因此，您可以尝试逐个禁用扩展并点击服务器来重现错误。在不完全检查当前配置的情况下，您可以检查并检查（在测试环境中！！）如果设置不正确。否则禁用php扩展对我来说非常有用。因为这个问题只是偶尔出现，所以我对这个问题很感兴趣。@semm0:我们的配置与您提到的完全相同：）sry:）任何可能限制上游连接的psad/ufw规则？例如，时间Y内的最大X连接数？虽然您的配置设置对我来说非常合理，但不幸的是，它们没有改变任何东西。是的，我重新启动了fpm和nginx。我还重新启动了整个服务器。但我想，这一定与限制有关。当请求被发送到服务器，一切正常。如果是一堆ajax请求，每次持续数秒，则会再次出现坏网关。nginx日志中的错误更改为：30上游超时（110：连接超时）在从Upstreat读取响应头时，这在php端看起来是个问题，但只是为了确保将
fastcgi\u read\u timeout
和
fastcgi\u send\u timeout
更改为60秒，并删除
fastcgi\u buffers、fastcgi\u buffer\u size、client\u max\u body\u size、client\u body\u buffer\u size
（请参阅我的答案）。还可以使用这些值编辑php.ini文件并重新启动。当php请求开始失败时，我们谈论的是多少个php请求，以及每个请求应该运行多长时间？mysql脚本上是否存在缓慢的查询日志错误（假设您正在使用它们）.是的，你说得太对了！我终于明白了。这都是关于超时的。进一步的调查表明，我提出了一个寿命更长的ajax请求，有时需要更长的时间才能配置超时。非常感谢！
listen = 0.0.0.0:9000