Код статусу 499: що nginx має на увазі під client closed request

Що означає код статусу 499

499 Client Closed Request специфічний для nginx і ніколи не визначений у жодному RFC. Коди вище 99 і нижче 600 загалом зарезервовані для рядків статусу HTTP, але 499 - власна конвенція nginx, що логується, коли nginx виявляє, що з'єднання клієнта обірвалося, поки він ще чекав на відповідь upstream-застосунку, чи поки він ще надсилав тіло відповіді назад клієнту. Найпоширеніша реальна форма цього - повільний upstream у поєднанні з клієнтом, вкладкою браузера чи балансувальником навантаження, чий власний тайм-аут коротший за той час, що мав би зайняти сервер, тож клієнт вішає слухавку першим.

Як це з'являється в логах

Ви ніколи не побачите 499 як код статусу, повернутий якомусь клієнту, браузеру, curl чи іншому, оскільки за визначенням клієнта вже немає на той момент, коли nginx мав би його надіслати. Він існує лише у власному лозі доступу nginx:

10.0.0.12 - - [19/Sep/2026:14:02:11 +0000] "GET /api/report HTTP/1.1" 499 0 "-" "python-requests/2.31"

Розмір відповіді в 0 байтів і час відносно відомого часу відповіді вашого upstream - дві найкорисніші деталі: 499, що стабільно потрапляє точно біля тайм-ауту вашого upstream, з нічим не надісланим назад, прямо вказує на "бекенд був надто повільним, і щось здалося чекати".

Що спричиняє 499

• Повільний upstream-застосунок. Бекенду потрібно більше часу на відповідь, ніж готовий чекати клієнт чи проміжна ланка, чи то повільний запит до бази даних, зовнішній виклик API, чи справді важкі обчислення.
• Тайм-аут на боці клієнта, коротший за те, що потрібно серверу. Закрита вкладка браузера, мобільний застосунок, що здається на нестабільному з'єднанні, чи власний тайм-аут бібліотеки HTTP-клієнта, що спрацьовує раніше, ніж прийде відповідь.
• Балансувальник навантаження чи upstream-проксі, що дає тайм-аут першим. Якщо щось стоїть між справжнім кінцевим користувачем і nginx, його власний тайм-аут може спричинити відключення, яке nginx залогує як 499, навіть коли справжній кінцевий користувач ніколи явно нічого не скасовував.
• Користувач, що йде зі сторінки чи перезавантажує її. Хтось, хто клацає геть зі сторінки, що повільно завантажується, чи нетерпляче натискає перезавантаження, закриває з'єднання, що виконується, до того, як nginx завершив.
• Значення тайм-ауту, неузгоджені по всьому ланцюжку. Клієнт, CDN, балансувальник навантаження й сам nginx можуть кожен мати різний тайм-аут, і той, що найкоротший, визначає, коли трапляється відключення, незалежно від того, як налаштовані інші.

Чому це ніколи не з'являється в браузері

499 - не відповідь, це нотатка, яку nginx робить сам собі про відповідь, яку він так і не встиг закінчити надсилати. Користувач, чия вкладка спричинила 499 у ваших логах, не бачить нічого взагалі: жодної сторінки помилки, жодного коду статусу, лише сторінку, що припинила завантажуватися, чи індикатор завантаження, що ніколи не завершився, бо не було відповіді, яку браузер міг би відрендерити. Саме тому покладання на звіти користувачів про помилки повністю пропускає ці випадки; єдине місце, де 499 видимий, - власний лог доступу сервера.

Як виправити і зменшити кількість 499

Немає одного налаштування, що усуває 499, оскільки базова причина - перегони між тим, що клієнт здається, і тим, що сервер завершує, а виправлення залежить від того, яка сторона цих перегонів справді зламана. Почніть із визначення, чи upstream стабільно повільний для постраждалого маршруту, чи відключення групуються навколо одного клієнта, мережі чи проміжної ланки, оскільки це вказує на різні виправлення.

1. Спершу дослідіть час відповіді upstream, оскільки повільний бекенд - найпоширеніша базова причина. Погляньте, скільки часу постраждалі запити справді зайняли на upstream, а не лише те, що nginx залогував 499.
2. Узгодьте значення тайм-ауту по всьому ланцюжку свідомо, а не лишайте значення за замовчуванням кожного шару як є: клієнт, CDN, балансувальник навантаження й власні proxy_read_timeout та proxy_connect_timeout nginx мають бути встановлені з чітким розумінням, який із них має спрацювати першим.
3. Розгляньте proxy_ignore_client_abort, якщо для вашого застосунку важливо, щоб upstream завершив свою роботу навіть після відключення клієнта, наприклад, щоб завершити запис, який не мав би лишитися напівзробленим:

   proxy_ignore_client_abort on;

   Це не запобігає запису в лог 499 для початкового відключення; це змінює, чи продовжує nginx виконувати запит до upstream незалежно.
4. Пришвидшіть саму роботу upstream там, де корінна причина справді повільний ендпоінт, оскільки жодне налаштування тайм-аутів не виправить бекенд, що сам по собі забирає забагато часу; профілюйте конкретні повільні запити чи виклики за постраждалим маршрутом.
5. Ставтеся до зростаючої частоти 499 як до справжнього сигналу, а не шуму в логах, що варто відфільтрувати, оскільки це зазвичай означає, що ваш застосунок сповільнився чи конфігурація тайм-аутів десь у ланцюжку неузгоджена.

Як запобігти, щоб це не переросло в збій

Оскільки 499 ніколи не доходить до клієнта як видима помилка, справді повільний ендпоінт легко лишається непоміченим, доки хтось не прочитає логи доступу, навіть коли реальні користувачі тим часом мовчки покидають запити. Запланована HTTP-перевірка вимірює справжній час відповіді напряму проти ендпоінта й сповіщає, коли він деградує, ловлячи сповільнення, що спричиняє 499, до того, як воно переросте у відверті збої запитів. Моніторинг з кількох локацій також допомагає відрізнити справді повільний бекенд від тайм-ауту, що спрацьовує лише для клієнтів на конкретному мережевому шляху.

Пов'язані помилки

Дивіться 504 Gateway Timeout для стандартного, видимого клієнту еквівалента, коли сам nginx здається чекати на upstream, а не клієнт здається першим, огляд 4xx для стандартної родини помилок клієнта, і 429 Too Many Requests для іншого виду відмови, пов'язаної з частотою, а не з часом.

Часті запитання

Чи 499 - справжній код статусу HTTP?

Ні. Це власна конвенція логування nginx для клієнта, що відключився до завершення відповіді, і вона ніколи не надсилається по мережі жодному клієнту, оскільки клієнта вже немає на момент, коли її мали б надіслати.

Чому мій інструмент моніторингу ніколи не бачить 499?

Перевірка моніторингу сама є клієнтом, і якщо саме вона здається на повільну відповідь, вона повідомить про власну помилку тайм-ауту, а не 499, оскільки вона ніколи не отримує HTTP-відповіді, з якої можна прочитати код статусу. 499 з'являється лише у власному записі лога доступу сервера для того запиту.

Чи означає 499, що мій сервер впав?

Ні. Це конкретно означає, що сервер усе ще працював чи от-от мав почати працювати, коли клієнт відключився. Збій зазвичай дав би натомість 502 чи 500, щойно щось таки відповіло б.

Чи можу я зупинити обробку на upstream, коли клієнт відключається?

За замовчуванням nginx зазвичай перестає чекати на upstream, щойно клієнта немає, але точна поведінка залежить від ваших налаштувань проксі; proxy_ignore_client_abort on каже nginx дозволити запиту до upstream продовжуватися, а не покидати його.

Яке найпоширеніше виправлення для частих 499?

Узгодження значень тайм-ауту між клієнтом, будь-яким проміжним проксі чи балансувальником навантаження й самим nginx, у поєднанні з вирішенням того, що взагалі робить upstream повільним. Жодне з двох окремо зазвичай не вирішує стійкий патерн.