Qué es el error 409 (Conflict), por qué ocurre y cómo solucionarlo

El error 409 (Conflict) es un código de estado HTTP de la familia 4xx. Indica que la petición del cliente entra en conflicto con el estado actual del recurso en el servidor, así que no se puede completar tal cual se ha enviado.

Dicho de otra forma: el servidor entiende perfectamente lo que le pides. Pero lo que intentas hacer tiene algún conflicto con cómo está ahora mismo ese recurso y se niega a ejecutarlo hasta que resuelvas el conflicto.

Como todos los códigos de la familia 4xx, el 409 es un error de cliente: el problema nace en la petición que se ha enviado, no en un fallo interno del servidor.
Y aquí está el matiz que confunde a mucha gente: el 409 no es un 404.

En un 404 el recurso no existe; en un 409 el recurso sí existe, pero tu petición no encaja con su estado en ese momento.

Muchos 409 aparecen además por detrás de capas intermedias como CloudFlare, o al guardar una entrada en WordPress cuando el editor de bloques habla con la REST API.

En este artículo te contamos qué es el error 409, por qué se produce y en qué se diferencia del 404. También cómo solucionarlo paso a paso, cómo arreglarlo en WordPress al guardar y qué hacer cuando llega a través del navegador o de CloudFlare.

Por qué se produce el error 409 en el servidor

El error 409 en el servidor se produce cuando dos operaciones compiten por el mismo recurso o cuando una petición asume un estado que ya ha cambiado. En lugar de dejar los datos inconsistentes, el servidor corta por lo sano y responde con un 409 Conflict. Es un mecanismo de protección, no un fallo aleatorio.

Estas son las causas concretas que disparan un error 409 en el día a día:

• Ediciones concurrentes del mismo recurso: dos usuarios (o dos pestañas del mismo usuario) editan el mismo registro a la vez. El primero guarda, el segundo intenta guardar sobre una versión desactualizada y recibe un error 409.

• Duplicado en una API REST con POST: intentas crear un recurso con un identificador único que ya existe. El servidor no puede tener dos recursos con la misma clave, así que responde con un error 409 en vez de sobrescribir a ciegas.

• Versión desactualizada en un PUT: envías una actualización basada en una versión del recurso que ya ha sido modificada por otra petición. El control de versiones (el llamado optimistic locking) detecta el desfase y devuelve 409.

• Choque con las reglas de estado del servidor: intentas una operación que el estado actual no permite, por ejemplo cerrar algo que ya está cerrado o borrar un recurso del que dependen otros.

El ejemplo más claro es el de la API REST: Lanzas dos peticiones POST casi a la vez para crear el mismo recurso con un identificador único; la primera crea el recurso sin problema y la segunda llega, ve que ese email ya existe y devuelve 409 Conflict.
No es un error de tu código en sentido estricto: es el servidor avisándote de que lo que pides ya está en conflicto con lo que hay.

El 409 no te dice que algo no exista, como el 404: te dice que lo que intentas hacer choca con el estado actual de ese recurso. Por eso casi siempre se soluciona recargando el recurso y reenviando la petición ya sincronizada.

Cómo solucionar el error 409 paso a paso

Para solucionar un error 409 hay que recargar el recurso y obtener su estado más reciente. Posteriormente, reenviar la petición sin que choque con ese estado y descartar ediciones simultáneas de otro usuario o pestaña.

Y si viene de una API REST, revisar que la operación no duplique un recurso que ya existe.

En la mayoría de casos, el 409 se resuelve sincronizando tu petición con el estado real antes de volver a lanzarla.

Esta es la secuencia de comprobaciones que recomendamos seguir, en orden:

1. Recarga el recurso para obtener su estado más reciente. Refresca la página, la ficha o el registro que estás editando para trabajar sobre la versión actualizada.

2. Reenvía la petición ya sincronizada con ese estado. Vuelve a guardar o a enviar tus cambios partiendo de la versión buena, no de la vieja.

3. Descarta ediciones simultáneas. Comprueba que no tengas otra pestaña abierta ni que otro usuario esté tocando el mismo recurso a la vez.

4. Si viene de una API REST, revisa que la operación no duplique un recurso existente (un identificador único ya usado) ni que estés enviando una versión desactualizada en un PUT.

Para identificar los errores 409 con precisión, abre las herramientas de desarrollador del navegador (pestaña Network o Red) y localiza la petición que falla. Verás la respuesta con el estado 409 Conflict resaltada, y muchas veces con un mensaje en el cuerpo que te dice qué recurso ha entrado en conflicto.

Cómo arreglar el error 409 en WordPress al guardar un contenido

En WordPress, el error 409 al guardar una entrada o página casi siempre viene por detrás de la REST API.
El editor de bloques (Gutenberg) no guarda como antaño: envía tus cambios mediante peticiones a /wp-json/. Si algo deja esa petición en conflicto, como por ejemplo un plugin, una regla del .htaccess o una edición simultánea, el resultado es un 409 Conflict justo al pulsar Actualizar o Publicar.

En WordPress, un 409 al guardar casi siempre viene por detrás de la REST API: el editor de bloques envía la petición a /wp-json/ y algo (un plugin, una regla del .htaccess o una edición simultánea) la deja en conflicto.

Los orígenes habituales del 409 en WordPress son unos pocos y conocidos:

• El primero, ediciones concurrentes: si tienes dos pestañas abiertas con la misma entrada o hay bloqueo de edición entre usuarios y los autoguardados se pisan, el editor manda una petición basada en una versión ya cambiada.

• El segundo, plugins de caché o de seguridad que interfieren con las peticiones a /wp-json/: cachés como WP Rocket o LiteSpeed Cache mal ajustadas, o plugins de seguridad que bloquean o filtran la REST API.

• El tercero, reglas en el .htaccess que reescriben o interceptan las rutas de la REST API y dejan la comunicación a medias.

Para arreglarlo, empieza por lo sencillo: recarga el editor (guarda antes lo que puedas), cierra pestañas duplicadas de la misma entrada y vuelve a intentar el guardado sobre la versión actualizada.

 Si el 409 persiste al actualizar o publicar, verás el aviso de error del editor de bloques en cuanto la petición a la REST API se rechaza.

Si sigue apareciendo, toca aislar el conflicto.

Nuestra recomendación de siempre con estos casos es desactivar los plugins uno a uno  y probar a guardar tras cada desactivación, hasta dar con el plugin que provoca el error 409.

Debes ir al listado de plugins del panel de WordPress y los vas desactivando de forma ordenada para acotar el culpable. Si al desactivarlos todos el problema desaparece, ya sabes por dónde va. Y si no, revisa el .htaccess por si alguna regla está interfiriendo con las rutas /wp-json/.

El error 409 en el navegador y con CloudFlare

Muchos errores 409 que ve un visitante en el navegador no llegan directos desde tu servidor, sino a través de capas intermedias como CloudFlare. Lo que el visitante ve en pantalla puede ser una página de error del CDN, pero por debajo hay un código HTTP.

Ya documentamos en su día que los errores 1xxx de CloudFlare salen en el HTML pero no son códigos HTTP puros: son mensajes que CloudFlare pinta en la página.

Los códigos HTTP que están por detrás de esos errores 1xxx son el 409, el 530, el 403 y el 429, es decir, un visitante puede estar viendo un aviso de CloudFlare cuyo código HTTP subyacente es un 409 Conflict.

Como en el resto de casos, conviene separar responsabilidades:

• Si eres el visitante, puedes hacer poco: recargar la página y reintentar, porque el conflicto suele resolverse cuando el estado se sincroniza.

• Si eres el administrador del sitio, ahí está el trabajo de verdad: revisar las reglas y reescrituras configuradas en CloudFlare y comprobar la comunicación entre CloudFlare y tu servidor de origen, porque es donde suele originarse el conflicto.

Otros códigos de error HTTP relacionados con el 409

El 409 es solo uno más dentro de la familia 4xx, los errores de cliente.
Entenderlo en su contexto ayuda a diagnosticar más rápido, porque muchos de sus vecinos comparten esa misma raíz: el problema está en la petición, no en un fallo interno del servidor.

Entre esos vecinos de la familia 4xx están el 400 (Bad Request), cuando la petición tiene una sintaxis incorrecta; el 403 (Forbidden), cuando el servidor entiende la petición pero se niega a autorizarla; el 404 (Not Found), cuando el recurso no existe; y el 429 (Too Many Requests), cuando se han enviado demasiadas peticiones en poco tiempo.

El error 409 se distingue de todos ellos porque el recurso existe y es accesible, pero tu petición tiene un conflicto con su estado.

Si te interesa un caso curioso de la familia 2xx que también genera dudas, échale un ojo a el código HTTP 204, que responde sin cuerpo pero con éxito.

Qué hacer si el error 409 persiste en tu hosting

La mayoría de los errores 409 se resuelven recargando el recurso y reenviando la petición ya sincronizada con su estado actual.

Pero a veces el error persiste pese a haberlo intentado todo, y todo apunta a la configuración del servidor: reglas en el .htaccess, plugins que bloquean la REST API o la comunicación con una capa como CloudFlare.

Si eres cliente de Raiola Networks y el 409 no se soluciona por sí solo, puedes contactar con nuestro soporte técnico 24/7 por teléfono o ticket: revisamos contigo la petición y el .htaccess para dar con el conflicto.

Y si el error 409 en tu WordPress viene mezclado con problemas de rendimiento o de configuración del servidor, podemos ponerte en contacto con nuestro departamento de aplicaciones web para que se encargue de diagnosticar el problema bajo presupuesto.