我有一个使用Puma在Nginx上运行的rails应用程序,就像发条一样,应用程序每隔几天就会出现502 Bad Gateway错误.

我的nginx日志包含很多这样的错误：

2015/07/23 14:43:49 [error] 14044#0: *7036 connect() to unix:///var/www/myapp/myapp_app.sock failed (111: Connection refused) while connecting to upstream, client: 12.123.12.12, server: myapp.com, request: "GET /arrangements HTTP/1.1", upstream: "http://unix:///var/www/myapp/myapp_app.sock:/arrangements", host: "myapp.com", referrer: "http://myapp.com/arrangements"

我必须重新启动Puma,一切都再次工作……持续几天.

我有什么想法可以排除故障吗？我是nginx和puma的新手.

/etc/nginx/sites-enabled/myapp.com

upstream myapp {
                server unix:///var/www/myapp/myapp_app.sock;
        }
        server {
                listen 80;
                server_name myapp.com;
                root /var/www/myapp/current/public;
                client_max_body_size 20M;

                location ~ \.php${
                        try_files $uri =404;
                        fastcgi_pass unix:/var/run/php5-fpm.sock;
                        fastcgi_index index.php;
                        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                        include fastcgi_params;
                        allow all;
                        satisfy any;
                }

                location / {
                        proxy_pass http://myapp; # match the name of upstream directive which is defined above
                        proxy_set_header Host $host;
                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                }
                location ~* ^/assets/ {
                        # Per RFC2616 - 1 year maximum expiry
                        expires 1y;
                        add_header Cache-Control public;

                        # Some browsers still send conditional-GET requests if there's a
                        # Last-Modified header or an ETag header even if they haven't
                        # reached the expiry date sent in the Expires header.
                        add_header Last-Modified "";
                        add_header ETag "";
                        break;
                }
        }

解决方法:

DigitalOcean网络团队已经确定了在NYC3内的许多网络交换机上运行固件的问题.此问题导致间歇性丢失与客户飞沫的连接.

虽然该问题仅在机架子集中得到确认,但我们将升级在NYC3中运行受影响固件的所有交换机.随着各个交换机的升级,这种维护将导致维护窗口内某个点的每个机架大约十分钟的停机时间.

维护窗口：
2015-08-27 22:00 EDT – 2015-08-28 02:00 EDT
2015-08-28 02:00 UTC – 2015-08-28 06:00 UTC

对于给您带来的不便,我们深表歉意,并感谢您在我们努力提高网络可靠性时的耐心等待.

我会给它一两天,看看你是否有问题再次出现,或者只是自己消失了.

添加/编辑

附：我刚注意到电子邮件中的详细信息,

Affected Droplets:
railsbox00

如果您收到电子邮件,那么您的Droplet会受到固件问题的影响.检查您的电子邮件,看看他们是否列出了您的VPS;它位于电子邮件的底部.