504 게이트웨이 시간 초과를 유발하는 Nginx 역방향 프록시

Nginx를 요청을받은 후 proxy_pass를 수행하여 포트 8001에서 실행되는 업스트림 서버에서 실제 웹 응용 프로그램을 가져 오는 역방향 프록시로 사용하고 있습니다.

mywebsite.com으로 이동하거나 wget을 수행하면 60 초 후에 504 Gateway Timeout이 발생합니다. 그러나 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;

시간 초과를 늘리면 실제 대상 웹 서버가 정상적으로 응답하기 때문에 문제가 해결되지 않을 가능성이 높습니다.

나는 이와 동일한 문제가 있었고 연결에서 연결 유지를 사용하지 않는 것과 관련이 있음을 알았습니다. 실제로 이것이 왜 그런지 대답 할 수는 없지만 연결 헤더를 지우면서이 문제를 해결했고 요청이 제대로 프록시 처리되었습니다.

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는 Keep-alive 헤더 설명 요청 후 업스트림 연결 닫기 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_timeout의 nginx와 PHP-FPM은 제한하지 않았다 있는지 확인.

한 사이트에 대한 시간 제한을 늘리려면 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.confnginx를 다시 시작하는 것을 잊지 마십시오.

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 의 문서는 이 트릭이 작동하는 이유를 설명합니다.

매개 변수 값은 변수를 포함 할 수 있습니다. 이 경우 주소가 도메인 이름으로 지정되면 설명 된 서버 그룹 중에서 이름을 검색하고, 찾을 수없는 경우 리졸버를 사용하여 결정합니다.

했네 (tenzer.dk) "동적 업스트림와 Nginx에" 또한 전달 된 URI에 대한 이러한 접근 방식의주의에 대한 몇 가지 관련 정보를 포함하는 자세한 설명을 위해.

같은 문제가있었습니다. 업스트림 서버에서 iptables 연결 추적으로 인해 발생했습니다. --state NEW,ESTABLISHED,RELATED방화벽 스크립트에서 제거 conntrack -F하고 문제를 플러시 한 후 사라졌습니다.

NGINX 자체가 근본 원인이 아닐 수 있습니다.

경우 "VM 인스턴스 당 최소 포트"는 NAT 게이트웨이 설정 - 당신의 nginx 인스턴스 및 사이에 서 proxy_pass대상 - 동시 요청의 수에 비해 너무 작, 그것은 증가되어야한다.

솔루션 : NAT 게이트웨이에서 VM 당 사용 가능한 포트 수를 늘리십시오.

컨텍스트 제 경우에는 GCP에서 역방향 프록시 NGINX가 NAT 게이트웨이와 함께 서브넷 내부에 배치되었습니다. NGINX 인스턴스는 NAT 게이트웨이를 통해 백엔드 API (업스트림)와 연결된 도메인으로 요청을 리디렉션했습니다.

GCP의이 문서는 NAT가 NGINX 504 시간 제한과 어떻게 관련되는지 이해하는 데 도움이됩니다.

제 경우에는 php를 다시 시작하고 괜찮아집니다.