#Что означает и когда возникает ошибка
Один случай 499 при закрытой вкладке не доказывает поломку. Повторяющиеся 499 во время долгих запросов PHP требуют сопоставления времени запроса, тайм-аутов на стороне клиента или прокси и реальной длительности работы PHP-FPM.
#Причины и как их различить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Клиент не дождался ответаБраузер, мобильное приложение или внешний балансировщик прерывает долгое соединение. | 499 появляется примерно через одинаковое время после начала тяжёлого запроса. | Измерить время по журналам и исправить узкое место. |
| Медленный PHP или база данныхКод выполняет тяжёлый SQL, ждёт внешнюю службу либо блокировку. | Одни URL стабильно дольше других, растёт request_time, PHP-FPM занят. | Исследовать PHP-FPM slowlog, БД и очереди. |
| 499 вызван обычным уходом пользователяПосетитель обновил страницу или закрыл вкладку. | Редкие одиночные записи без сообщений об ошибках, другие запросы нормальны. | Не менять конфигурацию при отсутствии пользовательской проблемы. |
#Пошаговая диагностика и исправление
- Уточните масштаб и время ошибкиУзнайте у пользователя URL, время попытки и через сколько секунд он нажал «Обновить» либо увидел прекращение загрузки. Откройте в браузере F12 → «Сеть» → повторите действие и запишите длительность. Не запускайте повторно денежные операции или массовые импорты ради теста: они могут выполниться на сервере, даже если вкладка была закрыта.
- Найдите 499 в журнале запросовВойдите по SSH на сервер и выполните
sudo nginx -T 2>&1 | grep -n "access_log"для поиска действующего пути, затемsudo tail -n 100 /var/log/nginx/access.log, если это действительно используемый журнал. Запись должна содержать URL и код 499. Если формат не включает время выполнения, временно добавьте отдельный формат с$request_timeи$upstream_response_timeтолько после резервной копии и проверкиnginx -t; не пишите в логи токены из параметров URL. - Сопоставьте с журналом PHP-FPMНайдите конкретный PHP-пул через конфигурацию
fastcgi_passи конфигурационные файлы его службы, напримерphp8.2-fpm(версия пример). Выполнитеsudo journalctl -u php8.2-fpm --since "30 minutes ago" --no-pagerлишь если именно эта служба установлена. Ищите сообщения о достигнутом pm.max_children, перезапусках, ошибках PHP. Если PHP-FPM обслуживает запрос быстро, изучайте промежуточный прокси/сеть; 499 сам по себе не указывает на PHP. - Проверьте длительность кода и запросов к базеЕсли 499 связан с конкретным действием PHP, получите из журнала приложения длительность именно этой операции и оцените время SQL-запросов, блокировки таблиц, обращения к стороннему API. Включайте PHP-FPM slowlog только для нужного пула и с согласованным порогом:
request_slowlog_timeout,slowlog; для доступа к журналам учитывайте персональные данные и нагрузку. Оптимизируйте причину задержки прежде, чем менять тайм-ауты. - Сравните тайм-ауты разных уровнейПроверьте через
sudo nginx -T, установлен лиfastcgi_read_timeout; этот параметр относится к паузе между чтениями от PHP-FPM, а не к максимальному времени всей работы. Отдельно проверьте ожидание в браузере, балансировщике/CDN и PHP-FPMrequest_terminate_timeout. Если внешний шлюз закрывает соединение через 30 секунд, увеличение одного тайм-аута Nginx до 120 секунд не устранит внешний лимит. - Перенесите долгую задачу в фоновое выполнение, если это возможноДля отправки массовых писем, генерации отчёта и импорта разработчик должен создать задачу с идентификатором и выдавать пользователю быстрый ответ о её постановке в очередь, а затем статус выполнения. В интерфейсе отображайте прогресс и результат, не заставляя браузер ждать минуты. Не советуйте делать повторный POST при 499, пока не проверено, была ли исходная операция выполнена.
- Если меняли настройки — проверьте и откатитеПеред точечной правкой сохраните копию файла, затем
sudo nginx -tиsudo systemctl reload nginx. Повторите безопасный тестовый запрос и сравните длительность, долю 499 и ошибки приложения. Если изменения ухудшили работу, верните исходный файл из копии, снова проверьтеnginx -tи примените конфигурацию. При обычных одиночных 499 не предпринимайте действий. - Дополнительная команда по темеLinux · Терминал (Bash)КомандаНужен sudoЧитать на своём сервере по SSH; вывод конфига может раскрыть переменные и секреты, не публикуйте его целиком.
sudo nginx -T 2>&1 | grep -nE "access_log|fastcgi_pass|fastcgi_read_timeout"sudo journalctl -u nginx --since "30 minutes ago" --no-pager
#Проверка результата
Успех: целевое действие завершает работу, а повторяемые 499 для него перестали возникать. Сравните время исполнения до и после при одинаковой нагрузке; единичные 499 допустимы.
#Если проблема осталась
Сохраните дату, точный URL без паролей и токенов, код ответа, обезличенные строки error.log и access.log за это время и перечень уже сделанных изменений. Сравните работу при обращении через публичный адрес и через внутренний балансировщик, если он есть. Если причину пока не удалось подтвердить, восстановите исходную конфигурацию из копии и передайте эти сведения администратору или разработчику приложения; не меняйте несколько параметров одновременно.