Ошибка 408 Request Timeout: причины и диагностика

HTTP 408 Request Timeout означает, что сервер не получил полный запрос за время, которое был готов ждать. Это не то же самое, что 504 Gateway Timeout: при 504 gateway/proxy не дождался ответа upstream, а при 408 проблема относится к получению входящего запроса от клиента.

408 возможен при медленной отправке request body, нестабильной сети, зависшем upload или слишком строгом timeout чтения headers/body.

Что означает HTTP 408

клиент ──часть запроса──> сервер
клиент ──медленно/обрыв──X
                         ↓
             server read timeout
                         ↓
                  408 Request Timeout

RFC 9110 допускает повтор незавершённого запроса, но для state-changing операций blind retry опасен: нужно знать идемпотентность и понимать, мог ли предыдущий запрос частично повлиять на систему.

408, client timeout и 504 — разные проблемы

Основные причины 408

Медленная отправка body

Большой upload по медленной сети может не уложиться в лимит чтения запроса на proxy/server.

Нестабильное соединение

Переключение Wi‑Fi/LTE, VPN, packet loss или разрыв TCP способны оставить сервер с неполным request.

Клиент открыл соединение, но не завершил запрос

Серверы ограничивают время ожидания медленных клиентов и не обязаны держать соединение бесконечно.

Слишком строгий read timeout

После изменения конфигурации лимит мог стать меньше реального времени отправки запроса.

Промежуточный proxy задерживает отправку

Корпоративный gateway, WAF или другой компонент способен менять поведение upload path.

Шаг 1. Подтвердите именно HTTP 408

curl -i https://example.com/problem-url

Если curl сам завершился по --max-time, HTTP 408 мог вообще не быть получен.

Verbose mode:

curl -v https://example.com/problem-url

может помочь увидеть этап, но перед передачей вывода удалите Authorization и cookies.

Шаг 2. Зафиксируйте тип запроса

Нужны method, URL, размер body, Content-Length/chunked, client network, timestamp, proxy/CDN и факт появления запроса в application logs.

408 на маленьком GET и на upload большого файла — разные сценарии.

Шаг 3. Сравните маленький и типичный body

Для безопасного тестового upload:

curl -i -F 'file=@small-test.bin' https://example.com/upload

Если маленький запрос проходит, а типичный большой получает 408, исследуйте скорость сети, buffering и read timeout.

Шаг 4. Определите компонент, вернувший 408

клиент → CDN/WAF → load balancer → Nginx → приложение

Если application log не видит запрос, ищите раньше. Если proxy access log содержит 408, изучайте его connection/read timeout и request metrics.

Шаг 5. Сопоставьте логи

Полезны:

timestamp
client IP
method
URL
request length
status
request time
request ID

Если 408 возникают только у одного региона или сети, сначала проверьте сетевой путь.

Шаг 6. Не путайте получение запроса и обработку

408:

server ещё не получил полный request

Медленное приложение:

request уже получен
application долго формирует response

Для второго сценария чаще релевантны client deadline или 504 через gateway.

Связанный материал: ошибка 504 Gateway Timeout.

408 при загрузке файлов

Проверьте:

1. request size limits;
2. timeout чтения body;
3. buffering;
4. upload speed;
5. WAF inspection;
6. временное хранилище proxy;
7. application limits.

Если причина только в размере, более специфичным может быть 413, но фактическое поведение зависит от компонента.

408 после изменения proxy

Сопоставьте начало ошибок с изменениями read/header/body timeout и buffering. Не увеличивайте все таймауты сразу: сначала найдите этап, который превышает лимит.

Как проверить восстановление

Повторите тот же тип запроса несколько раз:

for i in {1..10}; do
  curl -sS -o /dev/null \
    -w '%{http_code} %{time_total}\n' \
    https://example.com/problem-url
  sleep 1
done

Для upload тест должен иметь сопоставимый body.

Один успех недостаточен, если проблема зависит от edge, сети или backend.

Автоматический мониторинг

Обычная GET-проверка может обнаружить неожиданный 408 на публичном URL, но не воспроизводит медленный пользовательский upload. Критерий мониторинга должен быть близок к реальному сценарию и оставаться безопасным.

UpWatch можно использовать для регулярной HTTP-проверки критичных URL и фиксации момента появления неожиданных кодов ответа.

Типичные ошибки

• считать любой timeout HTTP 408;
• увеличивать upstream timeout вместо read timeout;
• автоматически повторять изменяющий данные POST;
• снимать защитные timeout глобально;
• тестировать искусственно медленный клиент на production.

Практический чек-лист

1. Подтвердить именно HTTP 408.
2. Зафиксировать method, URL, body size.
3. Определить компонент, вернувший 408.
4. Проверить, дошёл ли request до приложения.
5. Сравнить маленький и типичный запрос.
6. Проверить client/network path.
7. Проверить timeout чтения headers/body.
8. Отличить 408 от 504 и client timeout.
9. Исправить конкретную причину.
10. Повторить исходный сценарий серией безопасных тестов.

Что собирать для расследования повторяющихся 408

Если ошибка возникает редко, заранее добавьте в access logs поля, которые помогают отличить client/network problem от server limit: request ID, client IP, request length, request time, protocol и upstream status. Для upload полезно отдельно знать ожидаемый размер payload.

Не храните чувствительное тело запроса только ради диагностики. Обычно достаточно метаданных и безопасного request identifier, по которому можно сопоставить внешний failure с server-side событиями.

Источники и спецификации

• RFC 9110: 408 Request Timeout
• curl: официальная документация