Ошибка 409 Conflict означает, что запрос нельзя выполнить при текущем состоянии ресурса. Например, действие уже выполнено, запись изменилась или выбранное имя занято; точную причину нужно искать в ответе конкретного приложения.
Не нажимайте «Отправить» несколько раз подряд. Сначала сохраните введённый текст, прочитайте сообщение сервера и проверьте актуальное состояние заказа, записи или операции: повтор без изменений может снова получить отказ.
Что означает 409 и чем он отличается от 412
По RFC 9110, 409 описывает конфликт с текущим состоянием целевого ресурса, который пользователь потенциально может разрешить. Сам код не говорит, какой именно объект изменился и завершилась ли предыдущая попытка.
Если сервер проверяет HTTP-предусловие из заголовка, например If-Match, и оно не выполнено, для этого предусмотрен 412 Precondition Failed. Подробная работа с версиями разобрана в статье об If-Match и защите от потери изменений.
409 не доказывает падение всего сайта. Главная страница может отвечать нормально, пока сохранение карточки или отдельный API-запрос отклоняется из-за состояния данных.
Как найти запрос, который получил отказ
- Откройте инструменты разработчика браузера и вкладку Network — «Сеть».
- Найдите запрос со статусом 409. Запишите метод, путь без секретных параметров и время с часовым поясом.
- Посмотрите Response — тело ответа. Ищите объяснение конфликта, имя поля, ожидаемое состояние или машинный код ошибки.
- Сравните действие пользователя с текущими данными: существованием записи, статусом заказа, результатом предыдущей попытки.
- Если ответа недостаточно, передайте разработчику безопасный идентификатор запроса и последовательность действий для поиска события в журналах.
Не повторяйте оплату или создание заказа только ради записи в Network. Используйте уже полученный ответ, а воспроизведение с изменением данных перенесите на тестовый стенд.
HTML-страница вместо ожидаемого JSON — повод проверить, кто вернул отказ: приложение, прокси или защитный слой. Формат ответа даёт зацепку, но окончательный вывод требует сопоставления с журналами.
Что делать при разных причинах конфликта
Запись успели изменить
Сохраните свои правки отдельно, заново загрузите запись и сравните версии. Объедините изменения осознанно; полная отправка старой карточки поверх новой может стереть чужую работу.
Если API передаёт версию в теле запроса, проверьте её по документации приложения. Не подставляйте свежую версию автоматически к старому содержимому, чтобы просто убрать 409.
Действие не подходит текущему статусу
Представим, что интеграция пытается отменить уже отправленный заказ. В таком случае изменение HTTP-заголовков не поможет: нужно сверить разрешённые переходы статусов и выбрать действие, доступное сейчас.
Если пользователь видит старый статус, проверьте обновление интерфейса и порядок запросов. Если несколько обработчиков меняют один объект одновременно, разработчику нужно проверить согласованность проверки состояния и записи.
Имя или объект уже существует
При создании записи сравните введённое значение с существующими объектами, включая правила регистра и нормализации в приложении. Если это новая сущность, выберите допустимое уникальное значение; если та же самая — откройте найденную запись вместо повторного создания.
Не удаляйте существующий объект ради обхода ошибки. Сначала установите, кто и для какой операции его создал.
Предыдущая операция ещё выполняется
Проверьте её статус предусмотренным API способом. Ожидание и повтор допустимы только по контракту конкретного сервиса: универсального времени ожидания для 409 нет.
Если используется ключ идемпотентности, сверьте правила его повторного применения и соответствие параметров исходному запросу. Например, документация Stripe API v1 различает повтор с теми же параметрами и конфликт с параллельно выполняющимся запросом; переносить эти правила на любой API нельзя.
При неопределённом результате после тайм-аута сначала установите исход операции. Это отдельная задача, описанная в руководстве по повтору API-запроса без дублей.
Как проверить исправление
На тестовом стенде выполните действие в допустимом состоянии, затем повторите его в конфликтующем. Проверьте не только код ответа: при отказе не должно быть нежелательных изменений данных или побочных действий.
Если причина в параллельных запросах, воспроизведите именно параллельную работу. Критерий исправления — согласованный итоговый объект, понятный отказ проигравшей стороне и отсутствие бесконечного автоматического повтора.
Web-Puls помогает контролировать доступность публичного URL, но успешная внешняя проверка не подтверждает работу авторизованного сохранения или переходов статуса. Такие операции проверяют отдельно, без реальных платежей и заявок.
Если конфликт повторяется и мешает работе сайта, можно отправить заявку на диагностику: укажите публичный адрес, действие, время события и обезличенное сообщение 409. Команда оценит задачу и согласует формат и стоимость работ до их начала; пароли, cookie и токены передавать не нужно.