Коды ошибок Nginx 499

Ответ 1

HTTP 499 в Nginx означает, что клиент закрыл соединение, прежде чем сервер ответит на запрос. По моему опыту обычно возникает время ожидания на стороне клиента. Как я знаю, это специфический код ошибки Nginx.

Ответ 2

В моем случае я был нетерпелив и в итоге неправильно интерпретировал журнал.

Фактически реальной проблемой была связь между nginx и uwsgi, а не между браузером и nginx. Если бы я загрузил сайт в свой браузер и долго ждал, я бы получил "504 - Bad Gateway". Но это заняло так много времени, что я продолжал пробовать вещи, а затем обновлялся в браузере. Поэтому я никогда не ждал достаточно долго, чтобы увидеть ошибку 504. При обновлении в браузере, то есть когда предыдущий запрос закрыт, и Nginx записывает это в журнал как 499.

разработка

Здесь я буду считать, что читатель знает, как я, как я, когда начал играть.

Моя установка была обратным прокси-сервером, сервером nginx и сервером приложений, сервером uWSGI. Весь запрос от клиента будет отправлен на сервер nginx, а затем перенаправлен на сервер uWSGI, а затем ответ отправлен так же назад. Я думаю, что каждый использует nginx/uwsgi и должен использовать его.

Мой nginx работал так, как должен, но что-то не так с сервером uwsgi. Есть два способа (возможно, больше), в которых сервер uwsgi может не отвечать на сервер nginx.

1) uWSGI говорит: "Я обрабатываю, просто подождите, и вы скоро получите ответ". nginx имеет определенный период времени, что он готов ждать, fx 20 секунд. После этого он ответит клиенту с ошибкой 504.

2) uWSGI мертв, или uWSGi умирает, пока nginx его ждет. nginx видит это сразу, и в этом случае он возвращает ошибку 499.

Я тестировал свою настройку, делая запросы в клиенте (браузере). В браузере ничего не произошло, оно просто продолжало висели. Через 10 секунд (меньше таймаута) я пришел к выводу, что что-то не так (что было правдой) и закрыл сервер uWSGI из командной строки. Затем я перейду к настройкам uWSGI, попробую что-то новое, а затем перезагрузите сервер uWSGI. В тот момент, когда я закрыл сервер uWSGI, сервер nginx вернет ошибку 499.

Поэтому я продолжал отлаживать с помощью 499 erroe, что означает поиск в Google для ошибки 499. Но если бы я ждал достаточно долго, я бы получил ошибку 504. Если бы я получил ошибку 504, я бы лучше понял проблему, а затем смог отлаживать.

Таким образом, вывод заключается в том, что проблема заключалась в том, что uWGSI, который продолжал свисать ("Подождите немного, немного дольше, тогда у меня будет ответ за вас...").

Как я исправил эту проблему, я не помню. Думаю, это может быть вызвано множеством вещей.

Ответ 3

Клиент закрыл соединение не означает, что проблема с браузером!? Совсем нет!

Вы можете найти 499 ошибок в файле журнала, если у вас есть LB (балансировка нагрузки) перед вашим веб-сервером (nginx) либо AWS, либо haproxy (custom). Тем не менее, LB будет выступать в качестве клиента для nginx.

Если вы используете значения по умолчанию для haproxy для:

    timeout client  60000
    timeout server  60000

Это означало бы, что LB будет тайм-аут после 60000 мс, если нет ответа от nginx. Время ожидания может произойти для занятых веб-сайтов или скриптов, для которых требуется больше времени для выполнения. Вам нужно будет найти тайм-аут, который будет работать на вас. Например, расширьте его до:

    timeout client  180s
    timeout server  180s

И вы, вероятно, будете установлены.

В зависимости от вашей установки в вашем браузере может быть обнаружена ошибка тайм-аута шлюза 504, которая указывает, что что-то не так с php-fpm, но это не относится к 499 ошибкам в ваших файлах журналов.

Ответ 4

В моем случае я получил 499, когда клиентский API закрыл соединение, прежде чем он получил какой-либо ответ. Буквально отправил POST и сразу же закрыл соединение. Это решается с помощью опции:

proxy_ignore_client_abort on

Nginx Doc

Ответ 5

Как вы указали 499 прерывание соединения регистрируется nginx. Но обычно это происходит, когда ваш бэкэнд-сервер работает слишком медленно, и другие тайм-ауты прокси сначала или пользовательское программное обеспечение прерывает соединение. Поэтому проверьте, отвечает ли uWSGI быстро или нет, есть ли какая-либо нагрузка на сервер uWSGI/Database.

Во многих случаях есть некоторые другие прокси между пользователем и nginx. Некоторые из них могут находиться в вашей инфраструктуре, например, CDN, Load Balacer, кэш Varnish и т.д. Другие могут быть на стороне пользователя, например, кеширующий прокси и т.д.

Если на вашей стороне есть прокси-серверы, такие как LoadBalancer/CDN... вы должны установить тайм-ауты для тайм-аута сначала вашего бэкенда и постепенно для других прокси для пользователя.

Если у вас есть:

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

Я рекомендую вам установить:

• n секунд до тайм-аута uSSGI
• n+1 секунда до тайм-аута nginx
• 'n + 2' - тайм-аут для балансировки нагрузки
• n+3 секунды тайм-аута в CDN.

Если вы не можете установить некоторые тайм-ауты (например, CDN), найдите их тайм-аут и настройте остальные в соответствии с ним (n, n-1...).

Это обеспечивает правильную цепочку тайм-аутов. и вы действительно найдете чей тайм-аут и вернете правильный код ответа пользователю.

Ответ 6

Эта ошибка довольно легко воспроизвести, используя стандартную конфигурацию nginx с php-fpm.

Удержание кнопки 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.

Ответ 7

... пришел сюда из поиска Google

Я нашел ответ в другом месте здесь → fooobar.com/questions/108403/...

который должен был увеличить тайм-аут простоя соединения моего компенсатора эластичной нагрузки AWS!

(Я установил сайт Django с обратным прокси-сервером nginx/apache, и действительно действительно действительно работа с бэкэнд-журналом была в тайм-ауте)

Ответ 8

Как только я получил 499 "Запрос был запрещен антивирусом" в качестве ответа HTTP AJAX (ложный положительный результат от Kaspersky Internet Security с легким эвристическим анализом, глубокий эвристический анализ правильно знал, что не было ничего плохого).

Ответ 9

Одной из причин такого поведения может быть то, что вы используете http для uwsgi вместо socket. Используйте команду ниже, если вы используете uwsgi напрямую.

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

Та же команда в файле .ini -

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

Ответ 10

Я столкнулся с этой проблемой, и причина была связана с плагином Kaspersky Protection в браузере. Если вы столкнулись с этим, попробуйте отключить свои плагины и посмотрите, устраняет ли это вашу проблему.

Ответ 11

Многие случаи вызывают ошибку 499, один из моих аргументов - поле Content-Length, пропущенное в запросе http от клиента pocco