Nginx 499 오류 코드

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

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

    timeout client  60000
    timeout server  60000

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

    timeout client  180s
    timeout server  180s

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

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

---

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

proxy_ignore_client_abort on

Nginx 문서

---

As you point 499 a connection abortion logged by the nginx. But usually this is produced when your backend server is being too slow, and another proxy timeouts first or the user software aborts the connection. So check if uWSGI is answering fast or not of if there is any load on uWSGI / Database server.

In many cases there are some other proxies between the user and nginx. Some can be in your infrastructure like maybe a CDN, Load Balacer, a Varnish cache etc. Others can be in user side like a caching proxy etc.

If there are proxies on your side like a LoadBalancer / CDN ... you should set the timeouts to timeout first your backend and progressively the other proxies to the user.

If you have:

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

I'll recommend you to set:

• n seconds to uWSGI timeout
• n+1 seconds to nginx timeout
• `n+2' senconds to timeout to Load Balancer
• n+3 seconds of timeout to the CDN.

If you can't set some of the timeouts (like CDN) find whats is its timeout and adjust the others according to it (n, n-1...).

This provides a correct chain of timeouts. and you'll find really whose giving the timeout and return the right response code to the user.

---

This error is pretty easy to reproduce using standard nginx configuration with php-fpm.

Keeping the F5 button down on a page will create dozens of refresh requests to the server. Each previous request is canceled by the browser at new refresh. In my case I found dozens of 499's in my client's online shop log file. From an nginx point of view: If the response has not been delivered to the client before the next refresh request nginx logs the 499 error.

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)

If the php-fpm processing takes longer (like a heavyish WP page) it may cause problems, of course. I have heard of php-fpm crashes, for instance, but I believe they can be prevented configuring services properly like handling calls to xmlrpc.php.

---

...came here from a google search

I found the answer elsewhere here --> https://stackoverflow.com/a/15621223/1093174

which was to raise the connection idle timeout of my AWS elastic load balancer!

(I had setup a Django site with nginx/apache reverse proxy, and a really really really log backend job/view was timing out)

---

Once I got 499 "Request has been forbidden by antivirus" as an AJAX http response (false positive by Kaspersky Internet Security with light heuristic analysis, deep heuristic analysis knew correctly there was nothing wrong).

---

I encountered this issue and the cause was due to Kaspersky Protection plugin on the browser. If you are encountering this, try to disable your plugins and see if that fixes your issue.

---

One of the reasons for this behaviour could be you are using http for uwsgi instead of socket. Use the below command if you are using uwsgi directly.

uwsgi --socket :8080 --module app-name.wsgi

Same command in .ini file is

chdir = /path/to/app/folder
socket = :8080
module = app-name.wsgi

---

Many cases cause 499 error，one of my case is, Content-Length field missed in http request from a pocco client

참고URL : https://stackoverflow.com/questions/12973304/nginx-499-error-codes