我们在AWS上运行一个具有特定设置的网站：一个ELB将负载分割成2个运行nginx的t2.medium实例。 从那里，PHPstream量被分成两个（前端和API）stream，两个stream向我们的PHP服务器的内部ELB。 为了logging，我们有2个前端PHP服务器（t2.medium）和3个PHP PHP服务器（m4.large）。 所有在端口9000上运行相同版本的PHP-FPM。
所有的工作很好，直到前几天。 出于某种原因，尚未确定，PHP API服务器上的stream量就会死亡，只有一次nginx重新启动才能恢复正常。
我们假设我们可能有一些长时间运行的过程，导致PHP服务器变得忙碌起来，并且从这里一路走下坡路。 但是，所有PHP服务器的CPU使用率都是相当稳定的，直到停止响应。 PHP-FPM仍在运行，ngnix服务器上的负载仍然很低。 客户端收到的响应是504，这就是我在nginx错误日志中看到的： 2016/10/04 14:34:25 [error] 17661#0: *2309784 connect() failed (113: No route to host) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: api.mywebsite.com, request: "GET /some/route HTTP/1.1", upstream: "fastcgi://internalip:9000", host: "api.mywebsite.com"
nginx.conf
worker_processes 4; worker_connections 19000;
nginx网站conf
location ~ \.php$ { try_files $uri =404; fastcgi_buffer_size 512k; fastcgi_buffers 16 256k; fastcgi_busy_buffers_size 1024k; include fastcgi_params; fastcgi_pass route53-php:9000; fastcgi_index index.php; fastcgi_param REQUEST_URI /api$request_uri; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }
www.conf
listen = 9000 pm = dynamic pm.max_children = 50 pm.start_servers = 25 pm.min_spare_servers = 25 pm.max_spare_servers = 25 pm.max_requests = 500
由于设置远不是微不足道的，我不知道PHP位置块是否正确设置。 也可能是所用服务器的大小，但CPU使用率很低。
事实certificate，这是nginx与AWS内部ELB交谈的常见问题。 多了一些googlesearch之后，我发现这个问题： 一些nginx反向代理configuration每天停止工作一次，并添加parsing器帮助 – 我现在没有任何停机3天。
指出我发现的每篇文章都是关于proxy_pass的，但是它似乎也适用于fastcgi_pass 。
希望这将有助于在相同的情况下的人！