499 код ответа nginx
Possible reason for NGINX 499 error codes
I’m getting a lot of 499 NGINX error codes. I see that this is a client side issue. It is not a problem with NGINX or my uWSGI stack. I note the correlation in uWSGI logs when a get a 499.
I’m looking for a more in depth explanation and hoping it is nothing wrong with my NGINX config for uwsgi. I’m taking it on face value. It seems like a client issue.
15 Answers 15
HTTP 499 in Nginx means that the client closed the connection before the server answered the request. In my experience is usually caused by client side timeout. As I know it’s an Nginx specific error code.
In my case, I was impatient and ended up misinterpreting the log.
Elaboration
Here I will assume that the reader knows as little as I did when I started playing around.
My setup was a reverse proxy, the nginx server, and an application server, the uWSGI server behind it. All requests from the client would go to the nginx server, then forwarded to the uWSGI server, and then response was sent the same way back. I think this is how everyone uses nginx/uwsgi and are supposed to use it.
My nginx worked as it should, but something was wrong with the uwsgi server. There are two ways (maybe more) in which the uwsgi server can fail to respond to the nginx server.
1) uWSGI says, «I’m processing, just wait and you will soon get a response». nginx has a certain period of time, that it is willing to wait, fx 20 seconds. After that, it will respond to the client, with a 504 error.
2) uWSGI is dead, or uWSGi dies while nginx is waiting for it. nginx sees that right away and in that case, it returns a 499 error.
I was testing my setup by making requests in the client (browser). In the browser nothing happened, it just kept hanging. After maybe 10 seconds (less than the timeout) I concluded that something was not right (which was true), and closed the uWSGI server from the command line. Then I would go to the uWSGI settings, try something new, and then restart the uWSGI server. The moment I closed the uWSGI server, the nginx server would return a 499 error.
So I kept debugging with the 499 erroe, which means googling for the 499 error. But if I had waited long enough, I would have gotten the 504 error. If I had gotten the 504 error, I would have been able to understand the problem better, and then be able to debug.
So the conclusion is, that the problem was with uWGSI, which kept hanging («Wait a little longer, just a little longer, then I will have an answer for you. «).
How I fixed that problem, I don’t remember. I guess it could be caused by a lot of things.
The «client» in «client closed the connection» isn’t necessarily the Web browser!
For haproxy the default values for certain applicable timeouts are some 60 seconds for connecting to upstream and for reading from upstream (Nginx) or downstream (Web browser).
Meaning that if after some 60 seconds the proxy hasn’t connected to the upstream for writing, or if it hasn’t received any data from the downstream (Web browser) or upstream (Nginx) as part of a HTTP request or response, respectively, it will close the corresponding connection, which will be treated as an error by the Nginx, at least, if the latter has been processing the request at the time (taking too long).
Timeouts might happen for busy websites or scripts that need more time for execution. You may need to find a timeout value that will work for you. For example extending it to a larger number, like 180 seconds. That may fix it for you.
Depending on your setup you might see a 504 Gateway Timeout HTTP error in your browser which may indicate that something is wrong with php-fpm. That won’t be the case, however, with 499 errors in your log files.
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.
I’ll recommend you to set:
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.
Turns out 499’s really does mean «client interrupted connection.»
I had a client «read timeout» setting of 60s (and nginx also has a default proxy_read_timeout of 60s). So what was happening in my case is that nginx would error.log an upstream timed out (110: Connection timed out) while reading upstream and then nginx retries «the next proxy server in the backend server group you configured.» That’s if you have more than one.
Then it tries the next and next till (by default) it has exhausted all of them. As each one times out, it removes them from the list of «live» backend servers, as well. After all are exhausted, it returns a 504 gateway timeout.
So in my case nginx marked the server as «unavailable», re-tried it on the next server, then my client’s 60s timeout (immediately) occurred, so I’d see a upstream timed out (110: Connection timed out) while reading upstream log, immediately followed by a 499 log. But it was just timing coincidence.
If all servers in the group are marked as currently unavailable, then it returns a 502 Bad Gateway. for 10s as well. See here max_fails and fail_timeout. Inn the logs it will say no live upstreams while connecting to upstream.
If you only have one proxy backend in your server group, it just try’s the one server, and returns a 504 Gateway Time-out and doesn’t remove the single server from the list of «live» servers, if proxy_read_timeout is surpassed. See here «If there is only a single server in a group, max_fails, fail_timeout and slow_start parameters are ignored, and such a server will never be considered unavailable.»
The really tricky part is that if you specify proxy_pass to «localhost» and your box happens to also have ipv6 and ipv4 «versions of location» on it at the same time (most boxes do by default), it will count as if you had a «list» of multiple servers in your server group, which means you can get into the situation above of having it return «502 for 10s» even though you list only one server. See here «If a domain name resolves to several addresses, all of them will be used in a round-robin fashion.» One workaround is to declare it as proxy_pass http://127.0.0.1:5001; (its ipv4 address) to avoid it being both ipv6 and ipv4. Then it counts as «only a single server» behavior.
There’s a few different settings you can tweak to make this «less» of a problem. Like increasing timeouts or making it so it doesn’t mark servers as «disabled» when they timeout. or fixing the list so it’s only size 1, see above 🙂
Возможная причина кодов ошибок NGINX 499
Я получаю много кодов ошибок 499 NGINX. Я вижу, что это проблема на стороне клиента. Это не проблема NGINX или моего стека uWSGI. Я отмечаю корреляцию в журналах uWSGI при получении 499.
Я ищу более подробное объяснение и надеюсь, что с моей конфигурацией NGINX для uwsgi все в порядке. Я принимаю это за чистую монету. Похоже, проблема клиента.
В моем случае я был нетерпеливым и в итоге неправильно истолковал журнал.
разработка
Здесь я предполагаю, что читатель знает так же мало, как и я, когда начал экспериментировать.
Моя установка была обратным прокси, сервером 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, что означает поиск ошибки 499 в Google. Но если бы я подождал достаточно долго, то получил бы ошибку 504. Если бы я получил ошибку 504, я смог бы лучше понять проблему, а затем отладить.
Как я решил эту проблему, не помню. Думаю, это могло быть вызвано множеством причин.
Вы можете найти 499 ошибок в файле журнала, если у вас есть LB (балансировщик нагрузки) перед вашим веб-сервером (nginx) либо AWS, либо haproxy (custom). При этом LB будет действовать как клиент для nginx.
Если вы запустите значения по умолчанию haproxy для:
Это будет означать, что время ожидания LB истечет через 60000 мс, если от nginx не будет ответа. Тайм-ауты могут происходить для загруженных веб-сайтов или сценариев, которым требуется больше времени для выполнения. Вам нужно будет найти тайм-аут, который подойдет вам. Например, расширите его до:
И вы, вероятно, будете настроены.
В зависимости от ваших настроек вы можете увидеть ошибку тайм-аута шлюза 504 в вашем браузере, которая указывает на то, что что-то не так с php-fpm, но этого не будет с ошибками 499 в ваших файлах журнала.
Во многих случаях между пользователем и nginx есть другие прокси. Некоторые из них могут быть в вашей инфраструктуре, например, CDN, Load Balacer, Varnish cache и т. Д. Другие могут быть на стороне пользователя, например, кэширующий прокси и т. Д.
Я рекомендую вам установить:
Это обеспечивает правильную цепочку тайм-аутов. и вы действительно обнаружите, кто дает тайм-аут и возвращает пользователю правильный код ответа.
В моем случае я получил 499, когда клиентский API закрыл соединение до того, как получил какой-либо ответ. Буквально отправил POST и сразу закрыл соединение. Это решается опцией:
Оказывается, 499 действительно означает «соединение прервано клиентом».
У меня был тайм-аут чтения клиента 60 секунд (и nginx также имеет значение proxy_read_timeout по умолчанию 60 секунд). Итак, в моем случае происходило то, что nginx регистрировал ошибку, 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. Но это было совпадение во времени.
Если все серверы в группе отмечены как недоступные в данный момент, то также возвращается значение 502 Bad Gateway. 10 с. Смотрите здесь max_fails и fail_timeout. В журналах будет сказано no live upstreams while connecting to upstream.
Если у вас есть только один прокси-сервер в вашей группе серверов, он просто пробует использовать один сервер и возвращает 504 Gateway Time-out и не удаляет отдельный сервер из списка «живых» серверов, если proxy_read_timeout он превзойден. См. Здесь «Если в группе только один сервер, параметры max_fails, fail_timeout и slow_start игнорируются, и такой сервер никогда не будет считаться недоступным».
NginX выдает ошибку HTTP 499 через 60 секунд, несмотря на конфигурацию. (PHP и AWS)
В конце прошлой недели я заметил проблему на одном из моих средних экземпляров AWS, где Nginx всегда возвращает ответ HTTP 499, если запрос занимает более 60 секунд. Запрошенная страница представляет собой скрипт PHP
Я провел несколько дней, пытаясь найти ответы, и попробовал все, что я могу найти в Интернете, включая несколько записей здесь, в Stack Overflow, ничего не работает.
Я пробовал изменять настройки PHP, настройки PHP-FPM и настройки Nginx. Вы можете увидеть вопрос, который я поднял на форумах NginX в пятницу ( http://forum.nginx.org/read.php?9,237692 ), хотя он не получил ответа, поэтому я надеюсь, что я смогу найти ответьте здесь, прежде чем я вынужден вернуться к Apache, который, как я знаю, работает.
Это не та же проблема, что и ошибки HTTP 500 в других записях.
Я смог реплицировать проблему с помощью нового экземпляра micro AWS NginX с использованием PHP 5.4.11.
Чтобы помочь любому, кто хочет увидеть проблему в действии, я собираюсь провести вас через настройку, которую я запускал для последнего тестового сервера Micro.
Вам нужно будет запустить новый экземпляр AWS Micro (поэтому он бесплатный) с помощью AMI ami-c1aaabb5
Эта запись PasteBin имеет полную настройку для запуска, чтобы отразить мою тестовую среду. Вам просто нужно изменить example.com в конфигурации NginX в конце
Как только вы настроитесь, вам просто нужно создать образец файла PHP, который я тестирую, с которым
Теперь, когда вы можете увидеть таймаут, я рассмотрю некоторые изменения конфигурации, которые я сделал как для PHP, так и для NginX, чтобы попытаться обойти это. Для PHP я создам несколько файлов конфигурации, чтобы их можно было легко отключить
Обновите PHP FPM Config, чтобы включить внешние файлы конфигурации
Создайте новую конфигурацию PHP-FPM для переопределения таймаута запроса
Измените некоторые глобальные настройки, чтобы обеспечить интервал аварийного перезапуска 2 минуты
Затем мы изменим некоторые параметры PHP.INI, снова используя отдельные файлы
Как вы можете видеть, это увеличивает тайм-аут сокета до 3 минут и помогает регистрировать ошибки.
Наконец, я отредактирую некоторые параметры NginX, чтобы увеличить тайм-аут той стороны
Сначала я редактирую файл /etc/nginx/nginx.conf и добавляю его в директиву http fastcgi_read_timeout 300;
Затем я редактирую файл / etc / nginx / sites-enabled / example, который мы создали ранее (см. Запись pastebin), и добавьте следующие параметры в директиву сервера
Наконец, я добавляю следующее в раздел
Прежде чем повторять сценарий, запустите nginx и php-fpm, чтобы убедиться, что новые настройки были подняты. Затем я пытаюсь получить доступ к странице и все еще получаю запись HTTP / 1.1 499 в файле NginX example.error.log.
Итак, где я иду не так? Это просто работает на apache, когда я устанавливаю максимальное время выполнения PHP до 2 минут.
Обновление 1
Проведя еще один тест, чтобы показать, что проблема заключается не в том, что клиент умирает, я модифицировал тестовый файл
Если я запустил скрипт с веб-страницы, я увижу, что содержимое файла будет установлено в первую строку. Через 60 секунд в журнале NginX появляется ошибка. Через 10 секунд содержимое файла изменяется на вторую строку, доказывая, что PHP завершает процесс.
Обновление 2
Установка fastcgi_ignore_client_abort; изменяет ответ от HTTP 499 на HTTP 200, хотя ничего не возвращается конечному клиенту.
Обновление 3
Установив Apache и PHP (5.3.10) на поле прямо (используя apt), а затем увеличивая время выполнения, проблема также возникает и на Apache. Симптомы такие же, как и у NginX, ответ HTTP200, но фактическое время соединения с клиентом перед раздачей.
Я также начал замечать в журналах NginX, что если я тестирую с помощью Firefox, он делает двойной запрос (например, этот PHP-скрипт выполняется дважды, когда он длится более 60 секунд ). Хотя, похоже, это клиент, запрашивающий при неудачном сценарии
Причиной проблемы является эластичная балансировка нагрузки на AWS. Они, по умолчанию, тайм-аут после 60 секунд бездействия, что и вызывало проблему.
Так что это не NginX, PHP-FPM или PHP, а балансировка нагрузки.
Чтобы исправить это, просто зайдите на вкладку «Описание» ELB, прокрутите страницу вниз и нажмите ссылку «(Изменить)» рядом со значением, обозначающим «Idle Timeout: 60 секунд»,
Я думал, что оставлю свои два цента. Сначала проблема не связана с php (все еще может быть связано с php, php всегда меня удивляет: P). Это уж точно. в основном это вызвано сервером, проксированным для себя, в частности, имена имен хостов / псевдонимов, в вашем случае это может быть балансировка нагрузки, запрашивающая nginx, и nginx обращается к балансировщику нагрузки и продолжает идти таким образом.
Я столкнулся с аналогичной проблемой с nginx в качестве балансировки нагрузки и apache в качестве веб-сервера / прокси-сервера
Вам нужно найти, в каком месте проблемы жить. Я не знаю точного ответа, но просто попробуем его найти.
У нас есть 3 элемента: nginx, php-fpm, php. Как вы сказали, одинаковые настройки php под apache в порядке. Разве это не такая же настройка? Вы пытались apache вместо nginx на той же ОС / хосте / и т. Д.?
Если мы увидим, что php не подозревает, у нас есть два подозреваемых: nginx & php-fpm.
Чтобы исключить nginx: попробуйте настроить ту же «систему» на рубине. См. https://github.com/garex/puppet-module-nginx, чтобы получить представление об установке простейшей рубиновой установки. Или используйте google (возможно, это будет еще лучше).
Мой главный подозреваемый здесь – php-fpm.
Попробуйте сыграть с этими настройками:
На самом деле я столкнулся с той же проблемой на одном сервере, и я понял, что после изменений конфигурации nginx я не перезапустил сервер nginx, поэтому с каждым ударом nginx-url я получал ответ 499 http. После перезапуска nginx он начал нормально работать с ответами HTTP 200.
NginX выдает ошибку HTTP 499 через 60 секунд, несмотря на конфигурацию. (PHP и AWS)
в конце прошлой недели я заметил проблему на одном из моих средних экземпляров AWS, где Nginx всегда возвращает ответ HTTP 499, если запрос занимает более 60 секунд. Страница запрашивается-это PHP-скрипт
Я потратил несколько дней, пытаясь найти ответы и попробовал все, что я могу найти в интернете, включая несколько записей здесь о переполнении стека, ничего не работает.
Я попытался изменить настройки PHP, настройки PHP-FPM и Nginx настройки. Вы можете увидеть вопрос, который я поднял на форумах NginX в пятницу (http://forum.nginx.org/read.php?9,237692) хотя это не получило ответа, поэтому я надеюсь, что смогу найти ответ здесь, прежде чем я буду вынужден вернуться к Apache, который, как я знаю, просто работает.
этой не та же проблема, что и ошибки HTTP 500, сообщенные в других записях.
я смог воспроизвести проблему со свежим микро AWS экземпляр NginX с использованием PHP 5.4.11.
чтобы помочь всем, кто хочет увидеть проблему в действии, я собираюсь провести вас через настройку, которую я запустил для последнего тестового сервера Micro.
вам нужно запустить новый экземпляр AWS Micro (так что это бесплатно) с помощью AMI ami-c1aaabb5
эта запись PasteBin имеет полную настройку для запуска, чтобы отразить мою тестовую среду. Вам просто нужно изменить example.com в конфигурации NginX на конец
как только это настроено, вам просто нужно создать образец PHP-файла, который я тестирую с помощью которого
сохраните это в webroot, а затем проверьте. Если вы запустите скрипт из командной строки с помощью PHP или php-cgi, то он будет работать. Если вы получаете доступ к скрипту через веб-страницу и хвост журнала доступа /var/log/nginx / пример.доступ.log, вы заметите, что вы получаете HTTP 1.1 499 ответ через 60 секунд.
теперь, когда вы можете увидеть тайм-аут, я пройду через некоторые изменения конфигурации, которые я сделал для PHP и NginX, чтобы попытаться обойти это. Для PHP я создам несколько конфигурационных файлов, чтобы их можно было легко отключить
обновите конфигурацию PHP FPM, чтобы включить внешние файлы конфигурации
создайте новую конфигурацию PHP-FPM для переопределения запроса ожидания
измените некоторые глобальные настройки, чтобы гарантировать, что интервал аварийного перезапуска составляет 2 минуты
Далее мы изменим некоторые PHP.Настройки INI, снова используя отдельные файлы
как вы можете видеть, это увеличивает тайм-аут сокета до 3 минут и поможет регистрировать ошибки.
наконец, я отредактирую некоторые настройки NginX, чтобы увеличить тайм-аут этой стороны
первый Я редактирую файл /и т. д./nginx/nginx в.conf и добавьте это в директиву http fastcgi_read_timeout 300;
далее я редактирую файл / etc/nginx/sites-включено / пример который мы создали ранее (см. Запись pastebin) и добавьте следующие настройки в сервер директива
наконец, я добавляю следующее в расположение
.в PHP$ раздел сервера dir
перед повторите попытку сценария, запустите nginx и php-fpm, чтобы убедиться, что новые настройки были подобраны. Затем я пытаюсь получить доступ к странице и по-прежнему получать запись HTTP/1.1 499 в Примере NginX.ошибка.бревно.
Итак, где я ошибаюсь? Это просто работает на apache, когда я устанавливаю максимальное время выполнения PHP до 2 минут.
Я вижу, что настройки PHP были подобраны под управлением phpinfo () из веб-страницы. Я просто не понимаю, я на самом деле подумайте, что слишком много было увеличено, так как ему просто нужно PHP max_execution_time, default_socket_timeout изменен, а также NginX в fastcgi_read_timeout только в директиве server->location.
обновление 1
выполнив еще один тест, чтобы показать, что проблема не в том, что клиент умирает, я изменил тестовый файл на
если я запускаю скрипт с веб-страницы, то Я вижу, что содержимое файла будет установлено в первую строку. Через 60 секунд в журнале NginX появится ошибка. Через 10 секунд содержимое файла изменяется на 2-ю строку, доказывая, что PHP завершает процесс.
обновление 2
задание fastcgi_ignore_client_abort on; изменяет ответ с HTTP 499 на HTTP 200, хотя ничто не возвращается конечному клиенту.
обновление 3
имея установленный Apache и PHP (5.3.10) на поле прямо (с использованием apt), а затем увеличение времени выполнения проблема, похоже, также происходит на Apache. Симптомы такие же, как NginX сейчас, ответ HTTP200, но фактическое время подключения клиента перед рукой.
Я также начал замечать в журналах NginX, что если я тестирую Firefox, он делает двойной запрос (например,PHP-скрипт выполняется дважды, когда более 60 секунд). Хотя это, похоже, клиент, запрашивающий при сбое скрипта
5 ответов
причиной проблемы являются упругие балансировщики нагрузки на AWS. Они, по умолчанию, тайм-аут после 60 секунд бездействия, что и было причиной проблемы.
Так что это был не NginX, PHP-FPM или PHP, а балансировщик нагрузки.
чтобы исправить это, просто перейдите на вкладку «описание» ELB, прокрутите вниз и нажмите ссылку» (Edit) «рядом со значением, которое говорит»Время простоя: 60 секунд»
Я думал, что оставлю свои два цента. Во-первых, проблема не связана с php(все еще может быть связана с php, php всегда удивляет меня 😛 ). Это точно. его в основном вызвано прокси-сервером, более конкретно, именем хоста / псевдонимами, в вашем случае это может быть балансировщик нагрузки запрашивает nginx, а nginx вызывает балансировщик нагрузки, и он продолжает идти таким образом.
Я испытал как проблема с nginx в качестве нагрузки балансировщик и Apache в качестве веб-сервера/прокси-сервера
вам нужно найти, в каком месте проблемы живут. Я не знаю точного ответа, но давайте попробуем найти его.
мы имеем здесь 3 элемента: nginx, php-fpm, php. Как вы сказали, те же настройки php под apache в порядке. Это же не та же самая настройка? Вы пробовали apache вместо nginx на той же OS/host/etc.?
Если мы увидим, что php не подозревается, то у нас есть два подозреваемых: nginx & php-fpm.
чтобы исключить nginx: попробуйте настроить ту же» систему » на ruby. Видеть https://github.com/garex/puppet-module-nginx чтобы получить идею установить простейшую установку ruby. Или используйте google (может быть, это будет еще лучше).
мой главный подозреваемый здесь-php-fpm.
попробуйте сыграть с этими настройками:
на самом деле я столкнулся с той же проблемой на одном сервере, и я понял, что после изменений конфигурации nginx я не перезапускал сервер nginx, поэтому с каждым ударом url nginx я получал 499 http-ответ. После перезагрузки nginx он начал работать правильно с ответами http 200.