HTTP 410 Gone: qué significa y cómo solucionarlo

Qué significa este error y cómo reconocerlo

• Un navegador, cliente de API, crawler, herramienta de monitorización o comprobador de disponibilidad informa de 410 Gone.
• La respuesta puede afectar a una URL, un patrón de ruta, un método HTTP o una versión de API, en lugar de a todo el sitio web.
• El DNS puede seguir resolviendo y TLS puede seguir completándose porque la solicitud llegó a un endpoint HTTP.
• Las cabeceras de respuesta pueden revelar el comportamiento de caché, el destino de una redirección, el contexto de autenticación, información del proxy o la CDN, o el servidor que gestionó la solicitud.
• Repetir la solicitud normalmente devuelve el mismo resultado cuando el recurso se ha eliminado intencionadamente.

Causas principales, ordenadas por probabilidad

Causas más probables

1. Eliminación intencionada u obsolescencia del recurso — El propietario eliminó permanentemente una página, un archivo, un endpoint de API o una versión, y configuró la dirección antigua para que devolviera 410.
2. Regla de aplicación o de enrutamiento — La aplicación asigna el estado 410 a una ruta retirada, un registro eliminado o una versión de API no compatible.
3. Configuración de reescritura o de host virtual del servidor web — Una regla de ruta, un cambio de despliegue o una configuración incorrecta del sitio devuelve 410 para una URL que debería seguir funcionando.
4. Comportamiento del proxy inverso o de la CDN — Un intermediario puede haber almacenado en caché o generado la respuesta según su configuración de enrutamiento, caché o edge.
5. Desajuste de la solicitud — La URL puede ser válida para un método o una forma de ruta, pero estar eliminada o no admitirse para el método utilizado.
6. Lógica personalizada de seguridad o gestión de solicitudes — Un WAF, gateway o política de aplicación puede usar deliberadamente 410, aunque los problemas de autenticación, autorización y límites de solicitudes suelen usar otros códigos de estado.

El código de estado por sí solo no puede identificar qué componente produjo la respuesta. Se necesitan las cabeceras de respuesta, las marcas de tiempo y los registros para distinguir una eliminación prevista de una regla accidental o de una respuesta obsoleta de un intermediario.

Cómo solucionarlo

Si estás visitando el sitio

1. Comprueba cuidadosamente la dirección, incluido el hostname, la ruta, la ortografía, las mayúsculas y minúsculas y cualquier segmento de versión.
2. Repite la URL exacta una vez sin actualizarla continuamente. Si la página requiere una cuenta, inicia sesión mediante el proceso habitual del sitio y vuelve a intentarlo.
3. Si llegaste a la URL desde un marcador antiguo, un resultado de búsqueda o un enlace externo, busca la navegación actual del sitio o un reemplazo anunciado. No des por hecho que un 410 tiene un destino equivalente.
4. Si la respuesta persiste y el recurso debería seguir existiendo, envía al propietario del sitio la URL, la hora de la solicitud, el método HTTP y el resultado 410 mostrado. No envíes contraseñas, cookies ni tokens de acceso.

Si eres propietario o desarrollador del sitio

1. Reproduce la solicitud exacta. Registra la URL, el método HTTP, el host, los parámetros de consulta, el estado, las cabeceras de respuesta y si la solicitud estaba autenticada. Compara la solicitud fallida con una ruta o método relacionado que funcione correctamente.
2. Determina si el 410 es intencionado. Confirma si la página, el archivo, el registro o la versión de API se eliminaron deliberadamente. Si es así, documenta la eliminación y conserva la respuesta, salvo que se necesite un reemplazo adecuado.
3. Identifica la capa que genera la respuesta. Comprueba si las cabeceras y la ruta de solicitud indican que la respuesta fue generada por la aplicación, el servidor web, el proxy inverso, la CDN o el WAF. Revisa cada capa de la ruta de solicitud en lugar de cambiarlas todas a la vez.
4. Inspecciona los registros correspondientes. Busca en los registros de acceso, aplicación, proxy, CDN o seguridad pertinentes usando la marca de tiempo, la ruta y el identificador de solicitud. Busca una regla de eliminación, un registro borrado, una reescritura, un cambio de despliegue o una respuesta almacenada en caché.
5. Comprueba los cambios recientes y el estado de la caché. Compara la configuración de enrutamiento, versiones de API, autenticación, reescrituras y caché edge con el último despliegue que funcionaba correctamente. Si un intermediario almacenó en caché una respuesta incorrecta, sigue su proceso documentado y autorizado de invalidación de caché en lugar de desactivar la caché de forma generalizada.
6. Aplica la corrección autorizada más limitada. Restaura la ruta o elimina la regla errónea solo cuando el recurso deba estar disponible. Si existe un reemplazo equivalente, configura y prueba una redirección deliberada; no redirijas URL no relacionadas o inexistentes simplemente para ocultar el 410.
7. Vuelve a probar la misma solicitud. Verifica el estado, las cabeceras y el cuerpo de la respuesta desde el cliente correspondiente y, cuando proceda, desde la red o ubicación edge afectada. Confirma que las rutas eliminadas intencionadamente siguen comportándose según lo documentado y que las rutas relacionadas conservan sus estados previstos.
8. Revisa la monitorización y la documentación. Actualiza los inventarios de rutas, los avisos de obsolescencia de API, las redirecciones y las pruebas para que una versión futura no elimine accidentalmente un recurso activo.

Prevención y cómo verificar la solución

• Mantén un inventario de las rutas web, archivos y versiones de API importantes, incluido su comportamiento previsto al eliminarlos.
• Trata las eliminaciones intencionadas como cambios de versión: documéntalas, pruébalas e identifica cualquier URL de reemplazo aprobada.
• Mantén bajo control de versiones la configuración de la aplicación, el servidor web, el proxy, la CDN y el WAF, y revisa los cambios de rutas antes del despliegue.
• Prueba las URL y los métodos de API importantes después de versiones, migraciones y obsolescencias.
• Monitoriza las tasas de estados HTTP por ruta, método y despliegue para distinguir las respuestas 410 inesperadas de las eliminaciones planificadas.
• Conserva los registros de acceso y de la aplicación el tiempo suficiente para correlacionar una respuesta con la capa responsable.
• Define procedimientos de invalidación de caché y reversión para respuestas accidentales del edge o del proxy.

Preguntas frecuentes