Ошибка 408: сервер не дождался запроса

Ошибка 408 Request Timeout означает, что сервер открыл соединение, но не получил запрос целиком за время, которое был готов ждать. Заголовки или тело запроса не дошли до конца, и сервер закрыл соединение. Чаще всего такой код видят в журнале сервера, а посетителю он показывается реже, чем кажется.

Мы собрали стенд из nginx 1.22, Apache 2.4.68, своего сервера на Python и Chromium 149 и проверили, когда появляется 408, кто его отправляет, что записывается в журнал и как реагирует браузер. Главная находка: на повторно используемом соединении браузер скрывает 408 от человека и отправляет запрос заново — в том числе форму.

Что означает код 408

Код описан в стандарте HTTP, RFC 9110, раздел 15.5.9:

The 408 (Request Timeout) status code indicates that the server did not receive a complete request message within the time that it was prepared to wait.

Перевод: код 408 значит, что сервер не получил полное сообщение запроса за время, которое был готов ждать. Там же сказано, что клиент может повторить запрос, а если соединение уже непригодно, повтор идёт по новому соединению.

Отсюда главное отличие от похожих кодов. При 408 сервер ждёт клиента, а не наоборот. Сервер ещё ничего не начал делать: обработка запроса не начиналась, потому что запроса как такового нет — только его часть.

Где 408 среди других кодов HTTP

Статусный код — трёхзначное число в первой строке ответа сервера. Первая цифра определяет класс ответа, и так устроен весь список кодов протокола HTTP:

• 1xx — информационные. Сервер получил начало запроса и сообщает, что можно продолжать.
• 2xx — успешные. Запрос принят и выполнен, например 200 OK.
• 3xx — перенаправления. Сервер перенаправляет клиента на другой адрес: 301 — навсегда, 302 — временно.
• 4xx — ошибки клиента. Запрос неверный или не может быть выполнен по вине того, кто его отправил.
• 5xx — ошибки сервера. Запрос корректный, но сервер не смог его обработать.

Код 408 входит в группу 4xx рядом с такими соседями:

• 400 Bad Request — неверный синтаксис запроса;
• 401 Unauthorized — клиент не авторизован, нужен вход;
• 403 Forbidden — доступ запрещён, даже если вход выполнен;
• 404 Not Found — по указанному адресу ничего нет;
• 405 Method Not Allowed — метод запроса не разрешён для этого адреса;
• 409 Conflict — запрос вызывает конфликт с текущим состоянием ресурса;
• 410 Gone — ресурс удалён навсегда;
• 413 Payload Too Large — запрос больше, чем сервер готов принимать;
• 429 Too Many Requests — превышен лимит запросов за промежуток времени.

От других кодов группы 408 отличается тем, что ошибка не в содержании запроса: синтаксис, метод и адрес могут быть правильными. Проблема в том, что полный запрос не дошёл до сервера вовремя. Поэтому стандарт прямо разрешает клиенту повторить такой запрос.

Почему возникает ошибка 408

По стенду и документации серверов причины такие:

1. Медленная или нестабильная сеть. Мобильная связь, перегруженный Wi-Fi, слабый сигнал: запрос идёт кусками, и между кусками проходит больше времени, чем ждёт сервер.
2. Большой запрос. Загрузка файла или длинной формы на слабом канале не успевает за таймаут на тело запроса.
3. Короткий таймаут на сервере. Если таймаут на заголовок или тело уменьшили до нескольких секунд, 408 получат даже обычные посетители.
4. Прокси, VPN или антивирус. Промежуточная программа задерживает передачу данных или держит соединение открытым без запроса.
5. Открытые заранее соединения. Браузер открывает соединение «впрок», а запрос по нему не отправляет. Сервер такое соединение закрывает по таймауту, и в журнале Apache остаётся пустая строка с кодом 408.
6. Медленные атаки. Боты нарочно присылают запрос по байту, чтобы держать соединения. Таймаут с кодом 408 — защита от этого, а не поломка.

Стенд: что делает nginx

В nginx за 408 отвечают две настройки, обе по умолчанию 60 секунд. Документация описывает их так:

• client_header_timeout — «If a client does not transmit the entire header within this time, the request is terminated with the 408 (Request Time-out) error». Время считается на весь заголовок.
• client_body_timeout — «The timeout is set only for a period between two successive read operations, not for the transmission of the whole request body». Время считается между двумя порциями данных, а не на всё тело.

Мы поставили обе настройки в 3 секунды и отправляли запросы сырым клиентом на сокетах.

Три вывода.

nginx не отправляет клиенту ответ 408. В исходном коде таймаут обрабатывается вызовом ngx_http_close_request: соединение закрывается, а код остаётся только в журнале. Клиент получил 0 байт во всех случаях. Поэтому, если 408 есть в журнале nginx, посетитель ошибку 408 не видел — у него соединение просто оборвалось.

Таймаут заголовка — на весь заголовок. Клиент, который присылал по байту каждую секунду, не уложился в 3 секунды и был отключён, хотя ни одна пауза не превышала таймаут. Это и есть защита от медленных атак.

Таймаут тела — между порциями. Тело по 100 байт раз в 2 секунды nginx дочитал за 20 секунд и передал дальше: каждая пауза была меньше 3 секунд. Значит, медленная загрузка файла 408 не даст, пока данные идут хоть понемногу.

Соединение без запроса nginx закрыл молча: в журнале доступа ничего нет, в журнале ошибок — «client timed out … while waiting for request». Для неполного заголовка там же была строка «while reading client request headers».

Стенд: что делает Apache

В Apache 2.4 таймауты задаёт модуль mod_reqtimeout. По умолчанию:

RequestReadTimeout handshake=0 header=20-40,MinRate=500 body=20,MinRate=500

Это значит: на заголовок 20 секунд, и за каждые 500 полученных байт срок продлевается на секунду, но не больше 40 секунд. На тело — 20 секунд с тем же продлением. Мы проверили стандартный образ Apache 2.4.68 с этими настройками.

В отличие от nginx, Apache отправляет клиенту ответ 408 с короткой страницей «Server timeout waiting for the HTTP request from the client» и заголовком Connection: close. Именно эту страницу посетитель и видит.

Пустая строка "-" 408 - — частая находка в журналах Apache. Это не запрос и не посетитель с ошибкой: кто-то открыл соединение и ничего не прислал. Так выглядят, например, соединения, которые браузер открыл заранее и не использовал. Тревоги такие строки не требуют.

Что видит человек в браузере

Мы отвечали из своего сервера кодом 408 на разные запросы Chromium 149.

Если сервер прислал свою страницу, браузер показывает её. Если тело пустое, Chromium выводит свой экран: «Страница недоступна. Если проблема не исчезнет, свяжитесь с владельцем сайта. HTTP ERROR 408» и кнопку «Перезагрузить».

Браузер молча повторяет запрос — и форму тоже

В исходном коде Chromium (http_network_transaction.cc) есть отдельное правило: «On a 408 response from the server ("Request Timeout") on a stale socket, retry the request for HTTP/1.1 but not HTTP/2 or QUIC». Перевод: если 408 пришёл на старое соединение, запрос по HTTP/1.1 повторяется; по HTTP/2 и QUIC — нет.

«Старым» считается не только соединение после прошлого запроса. В http_basic_state.cc проверка IsConnectionReused засчитывает и соединение, которое браузер открыл заранее и ещё не использовал (kUnusedIdle). На стенде это видно: даже первый запрос к странице сервер получил дважды — первый раз по соединению, открытому впрок.

Самое неприятное мы получили с формой. Сервер отвечал 408 на второй запрос в каждом соединении. Человек нажимает кнопку отправки формы:

соед7 запрос3 POST /ka/form тело=b'a=1'   → ответ 408
соед8 запрос1 POST /ka/form тело=b'a=1'   → ответ 200

Браузер получил 408, открыл новое соединение и отправил ту же форму с тем же телом. Посетитель увидел обычный ответ и ничего не заметил. А сервер получил данные формы дважды.

Если приложение успевает что-то сделать до того, как отвечает 408, — записать заказ, отправить письмо, — выйдет двойная операция. Поэтому приложение не должно само отвечать 408 на запрос, который оно уже приняло и начало обрабатывать. Этот код — для случая, когда запрос не дошёл. А для любых форм нужна защита от повтора: один идентификатор формы — одна операция.

Как исправить ошибку 408: посетителю

1. Обновите страницу. Браузер откроет новое соединение, и обычно этого достаточно.
2. Проверьте подключение. Откройте другой сайт. При слабом сигнале подойдите ближе к роутеру или переключитесь с мобильной сети на Wi-Fi.
3. Отключите VPN и прокси. Они добавляют задержку и могут держать соединения открытыми.
4. Временно выключите проверку трафика в антивирусе. Такие программы пропускают через себя все запросы. Не забудьте включить её обратно.
5. Уменьшите файл. Если ошибка появляется при загрузке, сожмите файл или загрузите его на более быстром канале.
6. Попробуйте другой браузер или устройство. Если там всё работает, дело в расширениях или настройках первого браузера.
7. Не отправляйте форму или оплату повторно сразу. Сначала проверьте почту или личный кабинет: как показал стенд, запрос мог дойти.

Как исправить ошибку 408: владельцу сайта

1. Найдите 408 в журнале и посмотрите время. Если все 408 на одной отметке — 3, 10, 60 секунд, — это таймаут конкретного звена. Например, для nginx: awk '$9==408' access.log | head.

2. Отделите шум от проблемы. В Apache строки "-" 408 - — пустые соединения, их можно не считать. В nginx соединения без запроса в журнал доступа вообще не попадают.

3. Посмотрите, на каких адресах копятся 408. Если это загрузка файлов или длинные формы, посетители не успевают передать тело.

4. Проверьте таймауты. Значения по умолчанию — 60 секунд у nginx, 20–40 у Apache — подходят большинству сайтов. Если их уменьшили ради защиты, верните разумные значения:

   client_header_timeout 60s;
   client_body_timeout 60s;
   

5. Проверьте прокси и балансировщик. У каждого звена свой таймаут на приём запроса. Если внешний балансировщик ждёт меньше, чем nginx за ним, 408 появится уже на нём.

6. Проверьте плагины и код сайта. Код приложения не должен сам возвращать 408 на долгую обработку или ошибку базы. Для долгой обработки есть 504 и 503, для ошибки — 500.

7. Уменьшите размер запросов. Сжимайте картинки перед загрузкой на стороне браузера, разбивайте большие файлы на части.

8. Распределите нагрузку. Если сервер перегружен, он медленно читает запросы из сети. Добавьте процессы или ресурсы, включите кэш.

9. Защитите формы от повтора. Один идентификатор операции — одна запись, даже если запрос пришёл дважды.

Не уменьшайте таймауты на приём запроса до нескольких секунд в надежде защититься от ботов. Как показал стенд nginx, при таймауте 3 секунды отключается даже клиент, который честно присылает данные каждую секунду.

Чем 408 опасна для пользователей и компании

Для пользователя 408 — потерянная работа: заполненная форма, загруженный файл, начатая оплата. Особенно неприятно, если ошибка появляется на медленном мобильном интернете, когда человек находится в дороге: он пытается отправить данные несколько раз и уходит к другому сайту.

Для компании частые 408 означают, что часть посетителей не может выполнить действие, ради которого пришла. Хуже, если ошибка приходит только у пользователей из отдельных регионов или у одного провайдера: из офиса всё работает, и администраторы не видят проблемы. Поэтому полезно смотреть не только на сам сайт, но и на журнал, где видно, у кого и на каких адресах обрывается передача.

Что проверить на хостинге

На виртуальном хостинге настройки nginx и Apache обычно недоступны. Многие хостинги предоставляют только панель управления, где таймауты не настраиваются. В такой ситуации:

1. Посмотрите журнал доступа в панели. Если там много 408 на одних и тех же адресах, напишите в поддержку с примерами строк — им видна конфигурация сервера и установленные параметры.
2. Уточните, какие ограничения стоят на размер и время загрузки файлов. Иногда лимиты задаёт хостинг, а не сайт.
3. Проверьте, нет ли перед сайтом сервисов защиты или CDN: у них свои таймауты на приём запроса.
4. Если сайт постоянно перегружен, возможно, тарифа уже не хватает: сервер медленно читает запросы, когда обрабатывает слишком много одновременно.

Скорость своего подключения посетитель может проверить сервисом вроде Яндекс Интернетометра. Если загрузка заметно медленнее обычной, дело в сети, а не в сайте.

Советы разработчикам

• Разрабатывайте формы так, чтобы повтор был безопасным. Передавайте в запросе одноразовый идентификатор и проверяйте его на сервере: если запрос с таким идентификатором уже выполнен, верните прежний результат.
• Не возвращайте 408 из кода приложения. Код означает, что запрос не получен. Если приложение его получило, но не успело обработать, это 503 или 504.
• Загружайте большие файлы частями. Каждая часть — отдельный запрос: при обрыве передача продолжается с последней принятой части, а не с начала.
• Ставьте разумный таймаут в своих клиентах. Если ваш скрипт обращается к чужому API, не держите соединение открытым без данных: сервер закроет его по своему таймауту.
• Держите контроль доступности. Мониторинг, который отправляет запросы из разных регионов, быстрее покажет, что у части посетителей передача обрывается.

Ошибка 408 и SEO

Сам по себе 408 в журнале nginx на SEO не влияет: робот поисковика в этом случае ответа не получил, только обрыв соединения. Хуже, когда сайт отвечает роботу кодом 408 по-настоящему.

Google в справке о кодах ответа пишет: «All 4xx errors, except 429, are treated the same» — все ошибки 4xx, кроме 429, обрабатываются одинаково: содержимое считается несуществующим, а ранее проиндексированный адрес удаляется из индекса. Для поиска 408 то же самое, что 404. Если приложение отвечает 408 при перегрузке или ошибке, страницы могут выпасть из выдачи. Для временной перегрузки правильный код — 503 или 429: их Google считает временными.

Проверить, что получает робот, можно в Search Console — инструментом проверки адреса — или в Яндекс Вебмастере, разделом «Проверка ответа сервера».

Чем 408 отличается от 499, 504 и 413

• 408 Request Timeout — сервер не дождался запроса от клиента.
• 499 Client Closed Request — клиент не дождался ответа сервера. Код nginx, только в журнале.
• 504 Gateway Timeout — прокси не дождался ответа сервера за ним.
• 413 Payload Too Large — запрос дошёл, но он больше, чем разрешено принимать.

Границы замера

Стенд локальный: клиент и сервер на одной машине, сеть без потерь. Проверены nginx 1.22 и Apache 2.4.68 со стандартными настройками модуля mod_reqtimeout, браузер — Chromium 149 через HTTP/1.1. По HTTP/2 и QUIC повтор после 408 по исходному коду не делается, мы это не проверяли. Другие браузеры могут вести себя иначе.

Источники

• RFC 9110, раздел 15.5.9 «408 Request Timeout» — rfc-editor.org
• nginx: директивы client_header_timeout и client_body_timeout — nginx.org; ngx_http_request.c — github.com/nginx
• Apache: модуль mod_reqtimeout, директива RequestReadTimeout — httpd.apache.org
• Chromium: http_network_transaction.cc, http_basic_state.cc — github.com/chromium
• Google: коды ответа HTTP и сканирование — developers.google.com

Похожие ошибки

• Ошибка 499 — клиент не дождался ответа.
• Ошибка 504 — прокси не дождался сервера.
• ERR_EMPTY_RESPONSE — сервер закрыл соединение, ничего не ответив.

Коротко

• 408 значит: сервер не получил запрос целиком за время ожидания.
• nginx пишет 408 в журнал, но клиенту ничего не отправляет. Apache отправляет страницу 408.
• Таймаут заголовка в nginx — на весь заголовок, таймаут тела — между порциями.
• Chromium молча повторяет запрос после 408 на старом соединении, даже форму: сервер получает её дважды.
• Для Google 408 — такая же ошибка, как 404. Приложение не должно отвечать этим кодом роботу.