Marcio Cunha

Qué Significa el Código HTTP 405 Method Not Allowed y Cómo Corregirlo en el Servidor

Comprende por qué ocurre el código HTTP 405 cuando un servidor rechaza peticiones y descubre técnicas prácticas para diagnosticar y resolver problemas de enrutamiento.

Marcio Cunha11 min
También disponible en:EnglishPortuguês
Resumen
  • El código HTTP 405 indica que el servidor reconoce la ruta solicitada pero rechaza explícitamente el verbo HTTP utilizado en la petición.
  • La corrección implica verificar el mapeo de rutas en el backend, las configuraciones del servidor web y el uso correcto de la cabecera Allow.
  • Las solicitudes del navegador que involucran CORS preflight frecuentemente encuentran bloqueos de métodos si los proxies intermedios están mal configurados.
  • Probar rutas con herramientas de línea de comandos como cURL ayuda a aislar si el comportamiento proviene de reglas de firewall o código de aplicación.
  • Mantener la documentación de la API alineada con el comportamiento real del servidor previene confusiones de integración para los clientes.

Qué es el código HTTP 405 Method Not Allowed

Cuando navegamos por la web o desarrollamos sistemas, nos comunicamos con los servidores mediante un protocolo llamado HTTP. Este protocolo define reglas de comunicación, incluyendo palabras de comando conocidas como verbos HTTP — por ejemplo, GET para buscar datos, POST para enviar información, PUT para actualizar y DELETE para borrar. En la práctica, el error HTTP 405 avisa que el servidor encontró la dirección exacta que buscabas, pero rechazó el tipo de comando que intentaste usar.

Para entenderlo mejor, imagina que vas a un restaurante y usas la puerta de servicio para entrar como si fuera el salón de clientes. El establecimiento existe y la dirección es correcta, pero esa acción específica no está permitida allí. Eso es exactamente lo que ocurre cuando un cliente hace una petición POST a una URL que solo acepta comandos GET. El servidor web intercepta el intento y responde con un código 405, bloqueando la ejecución por motivos de seguridad, diseño de API o reglas de enrutamiento.

Este mecanismo protege la integridad del sistema al impedir que los usuarios envíen datos a lugares donde no deberían. Sin embargo, para quienes desarrollan o integran sistemas, este error puede causar frustración si no se diagnostica correctamente. En las siguientes secciones, detallaremos las causas más comunes y mostraremos cómo ajustar el código y la infraestructura para eliminar este comportamiento.

Causas comunes del error 405 en aplicaciones web

El origen más frecuente de un error 405 es una discrepancia entre lo que el cliente espera y lo que el servidor está programado para atender en esa ruta específica. Por ejemplo, un desarrollador frontend puede escribir código JavaScript intentando enviar un formulario usando el método PUT, pero el desarrollador backend configuró la ruta en el servidor para aceptar únicamente POST. El servidor actúa como guardián y rechaza la llamada.

Otra causa habitual involucra redirecciones automáticas ejecutadas por servidores web como Nginx o Apache. Cuando un cliente hace una petición POST a una URL que termina sin barra al final (como /usuarios), el servidor puede intentar redirigir el navegador a la versión con barra (/usuarios/). Históricamente, algunos servidores transformaban peticiones POST en GET durante esa redirección, generando conflictos y respuestas de error inesperadas.

También debemos considerar reglas de seguridad aplicadas en cortafuegos de aplicaciones web (WAF) o proxies inversos. Estos intermediarios filtran el tráfico de entrada y pueden bloquear métodos específicos, como DELETE o PATCH, considerándolos amenazas potenciales de explotación. En tales escenarios, la aplicación ni siquiera recibe la solicitud porque la barrera de seguridad bloqueó el verbo en el perímetro de la infraestructura.

Cómo diagnosticar el problema con herramientas de línea de comandos

Antes de alterar cualquier código en el servidor, es fundamental aislar el origen exacto del error 405. Las herramientas gráficas o los navegadores pueden ocultar detalles importantes de las cabeceras de respuesta HTTP, dificultando el análisis. El comando cURL, disponible en la mayoría de las terminales modernas, es el mejor aliado para inspeccionar solicitudes de forma limpia y directa.

Podemos ejecutar una llamada forzando un método específico y observando la respuesta detallada del servidor. Considera este ejemplo práctico en la terminal:

curl -i -X DELETE https://api.ejemplo.com/recurso/123

El parámetro -i indica a cURL que muestre las cabeceras HTTP junto con el cuerpo de la respuesta. Al analizar la salida, presta mucha atención a la cabecera llamada Allow. Los servidores que devuelven un código 405 deben, según la especificación del protocolo HTTP, incluir esta cabecera informando exactamente qué métodos están permitidos en esa dirección (por ejemplo: Allow: GET, POST).

Si la cabecera Allow lista los métodos correctos y sigues recibiendo un error, el problema está en la ruta llamada por el cliente. Si la cabecera regresa vacía o se omite por completo, la falla puede provenir de un proxy intermedio, como un balanceador de carga o una regla de firewall que bloquea el tráfico antes de llegar a la aplicación principal.

Corrigiendo el error 405 en el código de tu servidor

La solución directa para un error 405 radica en ajustar el mapeo de rutas en el backend. Cada framework de desarrollo tiene su propia forma de declarar qué métodos HTTP acepta una URL. Si utilizas Node.js con Express, por ejemplo, es común definir rutas separadas para cada verbo, tal como se muestra a continuación:

const express = require('express');
const app = express();

// Ruta que acepta solo GET
app.get('/api/estado', (req, res) => {
    res.json({ estado: 'ok' });
});

// Intentar un POST aquí generará un error 405 si falta app.post()
app.listen(3000);

Si tu aplicación necesita aceptar múltiples métodos en la misma URL, debes declarar explícitamente esa intención en el código. En el framework Express, podemos usar el método app.route() para agrupar diferentes verbos bajo la misma dirección, evitando mensajes de error indeseados:

app.route('/api/articulos')
    .get((req, res) => {
        res.send('Lista de artículos');
    })
    .post((req, res) => {
        res.send('Artículo creado con éxito');
    });

Lenguajes como Python (con Django o FastAPI) y PHP (con Laravel o Symfony) siguen una lógica similar. El secreto es asegurar que todas las interacciones esperadas por el frontend estén debidamente mapeadas en el código del servidor, eliminando brechas de enrutamiento.

Ajustando configuraciones en servidores web y proxies inversos

A menudo el código de la aplicación es correcto, pero el servidor web ubicado frente a la aplicación — como Nginx, Apache o IIS — está bloqueando o manipulando los métodos HTTP. Nginx, por ejemplo, puede devolver un error 405 si hay una redirección interna mal configurada o si se accede a archivos estáticos usando métodos dinámicos.

Si estás intentando servir archivos estáticos y recibes un error 405 al probar un método POST, verifica si la directiva del servidor web está configurada para permitir solo operaciones de lectura. Ajustar el archivo de configuración de Nginx para manejar correctamente las solicitudes personalizadas resuelve una gran parte de estas incidencias en entornos de producción.

También vale la pena revisar si existen reglas de control de acceso restrictivas en el archivo .htaccess de Apache o en las directivas de seguridad del servidor. Asegúrate de que los módulos de seguridad no estén interpretando verbos HTTP legítimos como intentos de intrusión, lo que provocaría el bloqueo inmediato de la solicitud.

Conclusión y buenas prácticas para prevenir fallas de método

El código de estado HTTP 405 Method Not Allowed es un mecanismo importante de protección y organización en la arquitectura web. Comprender su origen permite a ingenieros y desarrolladores diagnosticar fallas rápidamente, separando problemas de código en la aplicación de configuraciones incorrectas en servidores y proxies.

Para evitar que este problema afecte a los usuarios finales, mantén siempre la documentación de tu API rigurosamente sincronizada con tu código. Adoptar pruebas automatizadas que validen todos los métodos HTTP permitidos en cada endpoint garantiza que las futuras actualizaciones no introduzcan fallas silenciosas en el sistema.