HTTP 405 Method Not Allowed: qué significa y cómo solucionarlo

Qué significa este error y cómo reconocerlo

• Un navegador, cliente de API, herramienta de monitorización o comprobador recibe 405 Method Not Allowed.
• Un método HTTP falla mientras que otro método para la misma ruta puede funcionar.
• El problema puede afectar a una URL, patrón de ruta, cliente o despliegue concretos, en lugar de afectar a todo el sitio.
• La respuesta puede incluir una cabecera Allow con los métodos permitidos.
• Otras cabeceras pueden revelar información sobre redirecciones, caché, autenticación, proxy, CDN o servidor.
• Como se recibió una respuesta HTTP, es posible que la resolución DNS y la negociación TLS ya se hayan completado correctamente, pero esto no demuestra que la aplicación o la ruta estén bien configuradas.

Causas principales, ordenadas por probabilidad

Causas habituales

1. El método no es compatible con la ruta. El endpoint puede aceptar GET pero rechazar POST, o aceptar POST pero rechazar un método de actualización como PUT o PATCH.
2. Las reglas de enrutamiento o del servidor web rechazan el método. Una ruta, un host virtual o una política del servidor pueden impedir que la solicitud llegue al controlador previsto.
3. Un proxy inverso, una CDN o un WAF devuelve primero la respuesta. Un intermediario puede aplicar restricciones de métodos o enrutar la solicitud de forma distinta al origen.
4. La solicitud no coincide con el contrato de la aplicación. La ruta, la barra final, el tipo de contenido, el host, el estado de autenticación u otros detalles de la solicitud pueden seleccionar una ruta o regla de validación diferente.
5. Un despliegue o cambio de configuración reciente introdujo una discrepancia. Las rutas de la aplicación, las reglas del proxy, los métodos permitidos y el comportamiento de la caché pueden haber dejado de coincidir.
6. Una política intencionada o el diseño del endpoint. Algunos recursos rechazan deliberadamente métodos que no son seguros, no son compatibles o quedan fuera de su interfaz documentada.

El código de estado por sí solo no puede identificar qué capa o regla causó la respuesta. Confirma el método, las cabeceras, los logs y los cambios recientes antes de modificar el sistema.

Cómo solucionarlo

Si eres visitante o consumidor de una API

1. Confirma la URL exacta y si el cliente está enviando el método previsto. Una solicitud realizada normalmente desde la barra de direcciones del navegador utiliza GET, mientras que un cliente de API puede utilizar POST, PUT, PATCH, DELETE u otro método.
2. Comprueba las cabeceras de respuesta en busca de una cabecera Allow y de información sobre redirecciones, autenticación, caché o proxy. No consideres otro método una solución válida a menos que la documentación del sitio o de la API indique que es compatible.
3. Si el endpoint requiere una cuenta, inicia sesión mediante el proceso habitual y vuelve a intentarlo sin exponer credenciales en una solicitud de soporte.
4. Evita repetir las solicitudes si el servicio también informa de límites de frecuencia, tiempos de espera o síntomas de sobrecarga.
5. Si el problema persiste, envía al propietario del sitio la URL, el método, la marca de tiempo, el código de estado y las cabeceras relevantes con los datos confidenciales eliminados. No compartas contraseñas, cookies, tokens de autorización ni secretos de API.

Si eres propietario o administrador del sitio

1. Captura una reproducción mínima. Registra el método exacto, la URL, el host, la ruta de la solicitud, el estado y las cabeceras de respuesta relevantes. Conserva el cuerpo de la solicitud solo si no contiene secretos ni datos personales.
2. Comprueba si la respuesta es intencionada. Compara la solicitud con la ruta o el contrato de la API. Determina si el recurso debe admitir ese método y si una cabecera Allow identifica los métodos aceptados.
3. Identifica la capa que responde. Utiliza las cabeceras de respuesta, los ID de solicitud y las marcas de tiempo para determinar si la respuesta procede de la aplicación, el servidor web, el proxy inverso, la CDN o el WAF. Es posible que una respuesta generada por un proxy nunca llegue al origen.
4. Inspecciona los logs correspondientes. Busca en la capa identificada y, cuando esté disponible, en la capa ascendente la misma marca de tiempo, ruta, método e ID de solicitud. Busca discrepancias de rutas, filtros de métodos, solicitudes al origen rechazadas y cambios recientes de políticas.
5. Compara los cambios recientes. Revisa los despliegues, las definiciones de rutas, las reglas del servidor web, el comportamiento del proxy o la CDN, la configuración de autenticación y las políticas del WAF. Compara el método que falla con un método conocido como compatible para la misma ruta.
6. Aplica la corrección autorizada más limitada. Actualiza únicamente la ruta o regla que deba admitir el método. No desactives de forma general la autenticación, las protecciones del WAF ni las restricciones de métodos para que desaparezca el error.
7. Vuelve a probar de forma segura. Repite la misma solicitud en un entorno no productivo cuando sea posible y, después, prueba la ruta de producción afectada siguiendo el proceso de cambio aprobado. Confirma que los métodos no compatibles siguen siendo rechazados y que las rutas relacionadas continúan devolviendo sus códigos de estado previstos.
8. Comprueba las cachés y los intermediarios. Si el comportamiento difiere entre clientes o ubicaciones, verifica si un proxy o una CDN almacenó en caché la respuesta o está aplicando una regla independiente. Purga o modifica el comportamiento de la caché únicamente conforme al procedimiento operativo habitual del servicio.

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

• Define y documenta los métodos compatibles con las rutas web y los endpoints de API importantes.
• Prueba métodos representativos para las rutas críticas después de realizar cambios en la aplicación, el servidor, el proxy, la CDN o el WAF.
• Supervisa las tasas de códigos de estado por ruta y método, en lugar de tratar todas las respuestas 4xx como un único grupo.
• Mantén bajo control de versiones la configuración de enrutamiento, restricciones de métodos, autenticación y proxy.
• Conserva los ID de solicitud y los logs de las capas intermediarias y de origen durante el tiempo suficiente para correlacionar los fallos.
• Documenta las respuestas 405 intencionadas para que los equipos de soporte y monitorización puedan distinguir el comportamiento esperado de las regresiones.
• Evita permitir métodos de forma general; autoriza únicamente los métodos que requiera cada recurso y el contrato de la aplicación.

Preguntas frecuentes