Nginxリバースプロキシにより504ゲートウェイタイムアウトが発生する

Nginxをリバースプロキシとして使用しています。リバースプロキシは、要求を受け取り、proxy_passを実行して、ポート8001で実行されている上流サーバーから実際のWebアプリケーションを取得します。

mywebsite.comにアクセスするかwgetを実行すると、60秒後に504ゲートウェイタイムアウトが発生します...ただし、mywebsite.com：8001をロードすると、アプリケーションは期待どおりにロードされます。

そのため、何かが原因でNginxが上位サーバーと通信できません。

これはすべて、私のホスティング会社が私のものを実行していたマシンをリセットした後で始まりましたが、それ以前はまったく問題はありませんでした。

これが私のvhostsサーバーブロックです。

server {
    listen   80;
    server_name mywebsite.com;

    root /home/user/public_html/mywebsite.com/public;

    access_log /home/user/public_html/mywebsite.com/log/access.log upstreamlog;
    error_log /home/user/public_html/mywebsite.com/log/error.log;

    location / {
        proxy_pass http://xxx.xxx.xxx.xxx:8001;
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
} 

そして、私のNginxエラーログからの出力：

2014/06/27 13:10:58 [error] 31406#0: *1 upstream timed out (110: Connection timed out) while connecting to upstream, client: xxx.xx.xxx.xxx, server: mywebsite.com, request: "GET / HTTP/1.1", upstream: "http://xxx.xxx.xxx.xxx:8001/", host: "mywebsite.com"

おそらく、さらに数行を追加して、アップストリームまでのタイムアウト期間を増やすことができます。次の例では、タイムアウトを300秒に設定しています。

proxy_connect_timeout       300;
proxy_send_timeout          300;
proxy_read_timeout          300;
send_timeout                300;

あなたが言うように、実際のターゲットWebサーバーは問題なく応答しているため、タイムアウトを増やしても問題は解決しない可能性があります。

同じ問題があり、接続でキープアライブを使用しないことに関係していることがわかりました。これがなぜなのか実際に答えることはできませんが、接続ヘッダーをクリアすることでこの問題を解決し、リクエストは正しくプロキシされました。

server {
    location / {
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   Host      $http_host;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_pass http://localhost:5000;
    }
}

より詳細に説明しているこの投稿を見てください： nginx要求後にアップストリーム接続を閉じる キープアライブヘッダーの明確化 http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive

user2540984や他の多くのユーザーは、タイムアウト設定を増やしてみることができると指摘しています。私自身もこれと同様の問題に直面し、/ etc / nginx / nginx.confファイルのタイムアウト設定を変更しようとしましたが、これらのスレッドのほぼ全員が示唆しています。しかし、これは私には少しも役に立ちませんでした。NGINXのタイムアウト設定に明らかな変更はありませんでした。何時間もの検索の後、ようやく問題を解決することができました。

解決策はこのフォーラムスレッドにあり、タイムアウト設定を/etc/nginx/conf.d/timeout.confに配置する必要があるということです（このファイルが存在しない場合は作成する必要があります）。スレッドで提案されているのと同じ設定を使用しました：

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

これはあなたの特定の問題の解決策ではないかもしれませんが、/ etc / nginx / nginx.confのタイムアウトの変更が何もしないことに他の誰かが気付いた場合、この回答が役に立てば幸いです！

すべてのサイトの時間制限を増やしたり追加したりする場合は、nginx.confファイルに以下の行を追加できます。

またはファイルのhttpセクションに以下の行を追加します。/usr/local/etc/nginx/nginx.conf/etc/nginx/nginx.conf

fastcgi_read_timeout 600;
proxy_read_timeout 600;

上記の行が存在しない場合はconf、ファイル、それらを追加し、それ以外の場合は増加fastcgi_read_timeoutし、proxy_read_timeoutnginxのとPHP-FPMがタイムアウトなかったことを確認します。

1つのサイトのみの時間制限を増やすには、vimで編集できます /etc/nginx/sites-available/example.com

location ~ \.php$ {
    include /etc/nginx/fastcgi_params;
        fastcgi_pass  unix:/var/run/php5-fpm.sock;
    fastcgi_read_timeout 300; 
}

これらの行をに追加した後nginx.conf、nginxを再起動することを忘れないでください。

service php7-fpm reload 
service nginx reload

または、valetを使用している場合は、単にと入力しvalet restartます。

アップストリームサーバーがドメイン名を使用し、そのIPアドレスが変更された場合も、この状況に直面する可能性があります（例：アップストリームがAWS Elastic Load Balancerを指している）

問題は、nginxがIPアドレスを一度解決し、構成がリロードされるまで、後続の要求のためにそれをキャッシュしておくことです。

キャッシュされたエントリの有効期限が切れたら、ネームサーバーを使用してドメインを再解決するようにnginxに指示できます。

location /mylocation {
    # use google dns to resolve host after IP cached expires
    resolver 8.8.8.8;
    set $upstream_endpoint http://your.backend.server/;
    proxy_pass $upstream_endpoint;
}

proxy_passのドキュメントは、このトリックが機能する理由を説明しています：

パラメータ値には変数を含めることができます。この場合、アドレスがドメイン名として指定されていると、記述されているサーバーグループから名前が検索され、見つからない場合はリゾルバーを使用して決定されます。

賞賛「ダイナミックアップストリームとnginxの」（tenzer.dk）も転送のURIに関するこのアプローチの警告に関連するいくつかの情報が含まれてい詳細な説明のため。

同じ問題があった。上流のサーバーでのiptables接続追跡が原因であることが判明しました。--state NEW,ESTABLISHED,RELATEDファイアウォールスクリプトから削除しconntrack -F、問題を解消した後は消えていました。

NGINX自体が根本的な原因ではない可能性があります。

IF NATゲートウェイの「VMインスタンスあたりの最小のポートが」セット-あなたのnginxのインスタンス＆間のどのスタンドproxy_pass先-同時要求の数には小さすぎる、それは増加させなければなりません。

解決策：NATゲートウェイのVMごとに使用可能なポート数を増やします。

コンテキスト私の場合、Google Cloudでは、リバースプロキシNGINXがNATゲートウェイを使用してサブネット内に配置されました。NGINXインスタンスは、NATゲートウェイ経由でバックエンドAPI（アップストリーム）に関連付けられたドメインにリクエストをリダイレクトしていました。

GCPのこのドキュメントは、 NATがNGINX 504タイムアウトにどのように関連するかを理解するのに役立ちます。

私の場合、私はphpを再起動し、それは大丈夫になります。