HTTP 425 Too Early при повторной отправке запроса через посредника

  • Обновлено
  • Чтение ≈ 2 минуты

Краткий ответ

HTTP 425 Too Early защищает сервер от повторного выполнения запроса, который мог прийти как ранние данные TLS 1.3 (0-RTT). Важно не дублировать операции оплаты, заказа или записи, если клиент уже начал отправку.

В этой статье
  1. Что означает проблема и как её распознать
  2. Основные причины и признаки
  3. Пошаговая диагностика и устранение
  4. Как проверить результат и что делать, если не помогло

#Что означает проблема и как её распознать

HTTP 425 Too Early защищает сервер от повторного выполнения запроса, который мог прийти как ранние данные TLS 1.3 (0-RTT). Важно не дублировать операции оплаты, заказа или записи, если клиент уже начал отправку.

#Основные причины и признаки

Возможная причинаКак узнатьЧто делать
Посредник отправил запрос в 0-RTTНа одном участке соединения запрос передан до окончания TLS-рукопожатия.Ошибка чаще появляется через конкретный CDN или прокси и исчезает при штатной повторной попытке.Проверить настройки ранних данных на соответствующем узле.
Клиент повторяет небезопасный запросАвтоматические повторы POST/PATCH не учитывают возможную первую обработку.При повторе появляются дубли операций.Использовать идентификаторы идемпотентности и безопасную логику повтора.
Нарушен обмен заголовком Early-DataПосредник теряет или неправильно пересылает Early-Data: 1.425 связан с определённым звеном прокси.Сверить настройку посредника с RFC 8470.

#Пошаговая диагностика и устранение

  1. Выясните, какой запрос отклонёнЕсли сообщение появилось при открытии обычной страницы GET, попробуйте обновить её один раз. Если ошибка возникла при оплате, регистрации, отправке формы или изменении данных, НЕ нажимайте «Отправить» несколько раз: сперва проверьте историю операции и письмо-подтверждение. Если операция уже выполнена, повторять её нельзя.
  2. Зафиксируйте сетевой ответВ Chrome нажмите F12 → Network («Сеть») → Preserve log; выполните безопасное действие, не связанное с деньгами или изменением данных. Выберите ответ с 425, запишите URL и метод (GET/POST), время и наличие заголовка Early-Data в запросе. Снимок заголовков не должен содержать Cookie, Authorization и токены доступа. Если метод небезопасный, попросите поддержку проанализировать журнал, не повторяя вызов.
  3. Различите приложение и промежуточный узелВладелец инфраструктуры должен открыть панель CDN/обратного прокси, посмотреть журнал конкретного запроса и проверить, включено ли использование TLS 1.3 early data. Если запрос проходил через несколько узлов, проверьте, сохраняется ли Early-Data: 1 при пересылке. Не требуется отключать TLS 1.3 целиком и тем более проверку сертификатов.
  4. Настройте корректное повторение в клиентеДля безопасного GET клиент, получивший 425 на раннем запросе, повторяет его после завершения TLS-рукопожатия, без ранних данных. Для POST/PUT/PATCH разработчик обязан учитывать риск дубля: применять уникальный ключ операции на сервере, проверять факт выполнения и повторять только когда повтор безопасен. Простая команда «повторять всё 3 раза» здесь неверна.
  5. Проверьте цепочку после измененияНа тестовом контуре с журналированием отправьте безвредный запрос и убедитесь, что при повторе после установления TLS соединения сервер не возвращает 425. Сравните ответы через прокси и без него только в санкционированном тестовом окружении. Если проблема не решена, откатите изменённую настройку CDN по сохранённым значениям и отправьте разработчику обезличенный журнал.

#Как проверить результат и что делать, если не помогло

Безопасные запросы проходят без повторяющегося 425, а операции изменения данных не создают дублей. При повторении на одном прокси передайте техническому специалисту сведения о TLS 1.3, ранних данных и методе запроса.

Так эту ошибку тоже называют

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.