HTTP 499 Client Closed Request в логах Nginx

#Что означает ошибка

499 — нестандартный код nginx: клиент закрыл соединение, не дождавшись ответа. Частая причина — медленный backend или таймаут клиента.

#Причины и признаки

#Пошаговое решение

1. Посмотрите время ответаАдминистратору Nginx: найдите в access.log запрос со статусом 499 (это внутренний код nginx, когда клиент разорвал соединение до ответа). Сверьте URL, время, request_time, upstream_response_time, если эти поля настроены, и IP клиента. Статус 499 не всегда означает проблему сервера: пользователь мог закрыть вкладку. Не начинайте с изменения часов или DNS посетителя.
2. Оптимизируйте backendЕсли 499 повторяется именно для медленного обработчика, на сервере посмотрите время работы запроса и журнал приложения/PHP-FPM. Для PHP сопоставьте URL с медленными SQL-запросами и тайм-аутами; устраняйте выявленную задержку. После исправления повторите такой же запрос и проверьте время ответа, а не увеличивайте лимиты «наугад».
3. Согласуйте таймаутыЕсли перед nginx стоит Cloudflare или другой прокси, сопоставьте допустимые тайм-ауты прокси, nginx и приложения. Делайте это лишь при доказанном обрыве через определённый интервал. Сохраните конфигурацию, используйте nginx -t перед любым применением правок и не путайте 499 с 504: в одном случае клиент закрыл соединение, в другом сервер не успел получить ответ от upstream.
4. Проверьте журнал балансировщика и закрытие соединенияДля запросов через балансировщик сравните журналы балансировщика и nginx за один интервал, проверьте, не закрывает ли прокси неактивные соединения. Повторите тест на том же URL с клиентским журналом; если код 499 единичен и совпал с закрытием вкладки, исправление обычно не нужно.

#Проверка результата

Откройте тот же адрес, где возникало «HTTP 499 Client Closed Request в логах Nginx», в исходном браузере. Сравните с другим подключением и проверьте точный код ответа. Не используйте незащищённые обходы HTTPS как доказательство исправления.