[nginx] NGINX 499 오류 코드의 가능한 이유

499 NGINX 오류 코드가 많이 나타납니다. 이것이 클라이언트 측 문제라는 것을 알았습니다. NGINX 또는 내 uWSGI 스택의 문제가 아닙니다. 나는 499를 얻을 때 uWSGI 로그의 상관 관계에 주목합니다.

address space usage: 383692800 bytes/365MB} {rss usage: 167038976
bytes/159MB} [pid: 16614|app: 0|req: 74184/222373] 74.125.191.16 ()
{36 vars in 481 bytes} [Fri Oct 19 10:07:07 2012] POST /bidder/ =>
generated 0 bytes in 8 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1
switches on core 1760)
SIGPIPE: writing to a closed pipe/socket/fd (probably the client
disconnected) on request /bidder/ (ip 74.125.xxx.xxx) !!!
Fri Oct 19 10:07:07 2012 - write(): Broken pipe [proto/uwsgi.c line
143] during POST /bidder/ (74.125.xxx.xxx)
IOError: write error

더 자세한 설명을 찾고 있으며 uwsgi에 대한 NGINX 구성에 문제가 없기를 바랍니다. 나는 그것을 액면 그대로 받아들이고있다. 클라이언트 문제인 것 같습니다.

답변

Nginx의 HTTP 499 는 서버가 요청에 응답하기 전에 클라이언트가 연결을 닫았 음을 의미합니다 . 내 경험상 일반적으로 클라이언트 측 시간 초과로 인해 발생합니다 . 내가 알고 있듯이 그것은 Nginx 특정 오류 코드입니다.

답변

제 경우에는 참을성이 없어서 로그를 잘못 해석했습니다.

실제로 실제 문제는 브라우저와 nginx 간의 통신이 아니라 nginx와 uwsgi 간의 통신이었습니다. 내 브라우저에 사이트를로드하고 충분히 기다렸다면 “504-Bad Gateway”를 얻었을 것입니다. 하지만 시간이 너무 오래 걸려서 계속 시도하고 브라우저에서 새로 고침했습니다. 그래서 504 오류를 볼 때까지 기다린 적이 없습니다. 브라우저에서 새로 고침하면 이전 요청이 닫히고 Nginx는이를 로그에 499로 기록합니다.

동화

여기에서는 내가 놀기 시작했을 때와 마찬가지로 독자가 아는 것이 거의 없다고 가정합니다.

내 설정은 역방향 프록시, nginx 서버 및 응용 프로그램 서버, 그 뒤에있는 uWSGI 서버였습니다. 클라이언트의 모든 요청은 nginx 서버로 이동 한 다음 uWSGI 서버로 전달 된 다음 동일한 방식으로 응답이 전송됩니다. 나는 이것이 모든 사람들이 nginx / uwsgi를 사용하고 그것을 사용하는 방법이라고 생각합니다.

내 nginx가 제대로 작동했지만 uwsgi 서버에 문제가 있습니다. uwsgi 서버가 nginx 서버에 응답하지 못하는 두 가지 방법이 있습니다.

1) uWSGI가 “처리 중입니다. 잠시만 기다려주십시오. 곧 응답을 받으실 것입니다.” nginx는 기다릴 수있는 일정 시간 (fx 20 초)을 가지고 있습니다. 그 후 504 오류로 클라이언트에 응답합니다.

2) uWSGI가 죽었거나 nginx가 기다리는 동안 uWSGi가 죽습니다. nginx는이를 즉시 확인하고이 경우 499 오류를 반환합니다.

클라이언트 (브라우저)에서 요청하여 설정을 테스트하고있었습니다. 브라우저에서는 아무 일도 일어나지 않았고 계속 중단되었습니다. 약 10 초 (시간 초과 미만) 후에 뭔가 잘못되었다는 결론 (사실)을 확인하고 명령 줄에서 uWSGI 서버를 닫았습니다. 그런 다음 uWSGI 설정으로 이동하여 새로운 것을 시도한 다음 uWSGI 서버를 다시 시작합니다. uWSGI 서버를 닫는 순간 nginx 서버는 499 오류를 반환합니다.

그래서 499 erroe로 계속 디버깅했는데, 이는 499 오류에 대한 인터넷 검색을 의미합니다. 그러나 충분히 기다렸다면 504 오류가 발생했을 것입니다. 504 오류가 발생했다면 문제를 더 잘 이해하고 디버깅 할 수 있었을 것입니다.

결론은 uWGSI에 문제가 있다는 것입니다.이 문제는 계속 매달려 있습니다 ( “조금 더 오래, 조금만 더 기다리십시오. 그러면 제가 답변 해 드리겠습니다 …”).

어떻게 그 문제를 고쳤는지 기억이 나지 않습니다. 많은 것들이 원인 일 수 있다고 생각합니다.

답변

클라이언트가 연결을 닫았다 고해서 브라우저 문제가 아닙니다!? 전혀!

웹 서버 (nginx) 앞에 LB (로드 밸런서)가 AWS 또는 haproxy (사용자 지정) 인 경우 로그 파일에서 499 오류를 찾을 수 있습니다. 그것은 LB가 nginx의 클라이언트 역할을 할 것이라고 말했습니다.

다음에 대해 haproxy 기본값을 실행하는 경우 :

    timeout client  60000
    timeout server  60000

이는 nginx에서 응답이 없으면 LB가 60000ms 후에 시간 초과됨을 의미합니다. 실행에 더 많은 시간이 필요한 바쁜 웹 사이트 또는 스크립트의 경우 시간 초과가 발생할 수 있습니다. 자신에게 맞는 타임 아웃을 찾아야합니다. 예를 들어 다음으로 확장하십시오.

    timeout client  180s
    timeout server  180s

그리고 당신은 아마 설정 될 것입니다.

설정에 따라 php-fpm에 문제가 있음을 나타내는 504 게이트웨이 시간 초과 오류가 브라우저에 표시 될 수 있지만 로그 파일에 499 오류가있는 경우는 해당되지 않습니다.

답변

499nginx가 기록한 연결 중단 을 가리 킵니다 . 그러나 일반적으로 이것은 백엔드 서버가 너무 느리고 다른 프록시가 먼저 시간 초과되거나 사용자 소프트웨어가 연결을 중단 할 때 생성됩니다 . 따라서 uWSGI가 빠르게 응답하는지 여부를 확인하고 uWSGI / 데이터베이스 서버에 부하가 있는지 확인하십시오.

많은 경우 사용자와 nginx 사이에 다른 프록시가 있습니다. 일부는 CDN, Load Balacer, Varnish 캐시 등과 같은 인프라에있을 수 있습니다. 다른 일부는 캐싱 프록시 등과 같은 사용자 측에있을 수 있습니다.

LoadBalancer / CDN과 같은 프록시가있는 경우 타임 아웃을 먼저 백엔드에서 시간 초과로 설정하고 점진적으로 다른 프록시를 사용자에게로 설정해야합니다.

당신이 가지고 있다면:

user >>> CDN >>> Load Balancer >>> Nginx >>> uWSGI

다음을 설정하는 것이 좋습니다.

n uWSGI 시간 초과까지의 초
n+1 nginx 시간 초과까지 초
n+2 로드 밸런서 시간 초과에 대한 조건
n+3 CDN에 대한 제한 시간 (초).

일부 시간 제한 (예 : CDN)을 설정할 수없는 경우 시간 제한이 무엇인지 찾아 그에 따라 다른 항목을 조정합니다 ( n, n-1…).

이것은 올바른 타임 아웃 체인을 제공합니다. 타임 아웃을 제공 한 사람을 찾고 사용자에게 올바른 응답 코드를 반환합니다.

답변

제 경우에는 클라이언트의 API가 응답을 받기 전에 연결을 닫았을 때 499를 얻었습니다. 말 그대로 POST를 보내고 즉시 연결을 닫습니다. 이것은 옵션으로 해결됩니다.

proxy_ignore_client_abort on

Nginx 문서

답변

499는 실제로 “클라이언트가 연결을 중단했다”는 의미입니다.

클라이언트 읽기 제한 시간이 60 초였으며 nginx에는 기본 proxy_read_timeout도 60 초가 있습니다. 그래서 제 경우에 일어난 일은 nginx가 error.log an upstream timed out (110: Connection timed out) while reading upstream다음 nginx가 “구성한 백엔드 서버 그룹의 다음 프록시 서버”를 재 시도 한다는 것 입니다. 하나 이상있는 경우입니다.

그런 다음 ( 기본적으로 ) 모든 항목을 다 사용할 때까지 다음과 다음을 시도 합니다. 각각의 시간이 초과되면 “라이브”백엔드 서버 목록에서도 제거됩니다. 모두 소진 된 후에는504 gateway timeout.

그래서 제 경우에는 nginx가 서버를 “사용할 수 없음”으로 표시하고 다음 서버에서 다시 시도한 다음 클라이언트의 60s시간 초과 (즉시)가 발생했기 때문에 upstream timed out (110: Connection timed out) while reading upstream로그가 표시되고 즉시 499 로그가 표시됩니다. 그러나 그것은 단지 타이밍 우연이었습니다.

답변

이 오류는 php-fpm에서 표준 nginx 구성을 사용하여 재현하기가 매우 쉽습니다.

페이지에서 F5 버튼을 누르고 있으면 서버에 수십 개의 새로 고침 요청이 생성됩니다. 각 이전 요청은 새로 새로 고칠 때 브라우저에 의해 취소됩니다. 제 경우에는 고객의 온라인 상점 로그 파일에서 수십 개의 499를 찾았습니다. nginx 관점에서 : 다음 새로 고침 요청 전에 응답이 클라이언트에 전달되지 않은 경우 nginx는 499 오류를 기록합니다.

mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:32 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:35 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:35 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)

php-fpm 처리가 더 오래 걸리는 경우 (예 : 무거운 WP 페이지) 물론 문제가 발생할 수 있습니다. 예를 들어 php-fpm 충돌에 대해 들었지만 xmlrpc.php에 대한 호출을 처리하는 것과 같이 서비스를 올바르게 구성하지 못할 수 있다고 생각합니다.