HTTP 505 HTTP Version Not Supported: qué significa y cómo solucionarlo

Qué significa este error y cómo reconocerlo

• Un navegador, cliente de API, sistema de monitorización o herramienta de línea de comandos recibe 505 HTTP Version Not Supported.
• La respuesta puede incluir un mensaje que indique que la versión HTTP solicitada no es compatible.
• DNS puede resolver correctamente y TLS puede completarse porque el cliente recibió después una respuesta HTTP.
• El error puede producirse únicamente con un cliente, una ruta de negociación del protocolo, una URL, un método HTTP o un intermediario concretos.
• Las cabeceras de respuesta pueden revelar si la respuesta provino de un proxy, CDN, balanceador de carga o servidor de origen, y pueden mostrar detalles de caché o de la conexión.

Causas principales, ordenadas por probabilidad

1. Versión del protocolo HTTP no compatible: El endpoint no admite la versión principal de HTTP utilizada por la solicitud. Esta es la causa que define el estado 505.
2. Incompatibilidad de protocolo entre un intermediario y su upstream: Un proxy inverso, CDN, balanceador de carga o gateway puede utilizar una versión del protocolo que el siguiente servidor no acepta, o puede devolver su propia respuesta 505.
3. Configuración incorrecta o incompleta del protocolo HTTP: Un cambio reciente en el servidor, proxy o aplicación puede haber habilitado o requerido una versión del protocolo que no es compatible en toda la ruta de la solicitud.
4. Negociación o comportamiento de solicitud específico del cliente: Un cliente o herramienta de monitorización puede seleccionar un protocolo HTTP distinto al de los navegadores u otros clientes, dejando expuesto un problema de compatibilidad.
5. Respuesta inesperada de una capa que no es el origen: El estado puede ser producido por un gateway o intermediario de seguridad, en lugar de por la aplicación propietaria de la URL. Se necesitan cabeceras y logs para distinguirlo de una respuesta del servidor de origen.

La autenticación, los límites de frecuencia, DNS y TLS pueden afectar a una solicitud, pero por sí solos no explican una respuesta HTTP 505. Trátalos como vías de investigación independientes, salvo que las cabeceras de respuesta o los logs los relacionen con el fallo de versión del protocolo.

Cómo solucionarlo

Para visitantes y usuarios de API

1. Vuelve a intentar la URL exacta una vez y comprueba que el cliente esté actualizado y configurado para realizar una solicitud HTTP normal.
2. Si el problema se produce en un cliente de API o una herramienta de monitorización, compara el resultado con otro cliente compatible. Registra si el fallo es específico del cliente.
3. Anota la URL, el método HTTP, la hora aproximada, el estado de respuesta y las cabeceras de respuesta. No incluyas contraseñas, cookies, tokens de autorización ni otros secretos.
4. Si el error persiste, envía esos datos anonimizados al propietario del sitio o de la API. Por lo general, un visitante no puede corregir un problema de compatibilidad del protocolo en el servidor.

Para desarrolladores y propietarios de sitios

1. Captura la solicitud exacta. Registra el hostname, la ruta, el método, el protocolo de la solicitud, el cliente, la marca de tiempo y el estado final. Confirma que la respuesta sea realmente 505 y no una redirección o un estado mostrado por un cliente después de otro fallo.
2. Comprueba la negociación del protocolo. Determina qué versión HTTP utilizó o intentó utilizar el cliente y qué versión admiten el endpoint, el proxy, el balanceador de carga o la CDN. En conexiones cifradas, revisa el protocolo de aplicación negociado cuando tus herramientas lo muestren.
3. Identifica la capa que respondió. Utiliza las cabeceras de respuesta, las firmas del servidor cuando estén disponibles, los identificadores de solicitud y los logs de acceso para determinar si el 505 provino de la CDN, el WAF, el gateway, el proxy inverso, el servidor web o la aplicación.
4. Correlaciona los logs. Busca en la capa identificada y en la capa upstream la misma marca de tiempo, ruta, método, cliente e ID de solicitud. La ausencia de un log en el origen puede indicar que un intermediario rechazó la solicitud antes de reenviarla.
5. Revisa los cambios recientes del protocolo. Comprueba las implementaciones y los cambios de configuración recientes que afecten a la compatibilidad con versiones HTTP, las conexiones del proxy al origen, los listeners del balanceador de carga, el enrutamiento del gateway y la configuración del cliente o de la monitorización.
6. Aplica la corrección autorizada más limitada. Alinea el cliente, el intermediario y el origen afectados con una versión del protocolo compatible con toda la ruta de la solicitud. No desactives la validación de TLS, la autenticación ni los controles de seguridad como solución alternativa.
7. Vuelve a probar la misma solicitud. Verifica la URL y el método originales y, después, prueba rutas y recorridos de protocolo representativos. Confirma que la corrección no haya cambiado códigos de estado ni comportamientos de enrutamiento no relacionados.
8. Utiliza un despliegue controlado para la infraestructura compartida. Si la configuración afectada sirve a muchos sitios o rutas, pruébala en staging aprobado o en un cambio de alcance limitado antes de aplicarla ampliamente. Sigue los procedimientos de cambio y rollback del entorno.

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

• Documenta las versiones HTTP compatibles con clientes, gateways, proxies, balanceadores de carga y orígenes en cada ruta de solicitud.
• Prueba las rutas importantes del navegador y los métodos de API a través de la ruta realista de producción del proxy y la CDN después de cambios de protocolo o infraestructura.
• Monitoriza los códigos de estado por ruta, tipo de cliente, protocolo y despliegue para que las respuestas 505 específicas de un cliente sean visibles.
• Mantén bajo control de versiones la configuración del proxy, el balanceador de carga, el servidor web y la aplicación, con un procedimiento de rollback probado.
• Conserva los logs de acceso y del gateway correlacionados durante el tiempo suficiente para identificar qué capa generó una respuesta inesperada.
• Mantén actualizadas las herramientas de monitorización y los clientes de API, y valida su configuración de protocolo durante la incorporación o los cambios de configuración.

Preguntas frecuentes