Planteamiento y contexto
Un cliente que utiliza la reutilización de conexiones HTTP/2 recibe de forma intermitente 421 Misdirected Request al llamar a varios dominios HTTPS. Explica qué significa la respuesta, cómo separar el enrutamiento de protocolos de los errores de aplicación, cómo inspeccionar SNI, authority y la cadena de proxies, y cómo reintentar de forma segura.
Qué evalúa el entrevistador
- Comprender el 421 como un servidor que no puede atender el scheme y authority solicitados en la ruta actual.
- Conectar TLS SNI, certificados, reutilización de conexiones HTTP/2 y enrutamiento de reverse proxies.
- Rastrear la solicitud a través del cliente, el edge, el proxy y el origen.
- Reintentar en una nueva conexión sin duplicar efectos secundarios.
Preguntas para aclarar antes de responder
- ¿El 421 ocurre en HTTP/1.1, HTTP/2 o HTTP/3, y solo en conexiones reutilizadas?
- ¿Coinciden el scheme, authority, Host, SNI y el SAN del certificado?
- ¿El DNS, un balanceador de carga, una CDN o una malla de servicios envían múltiples dominios a una sola conexión?
- ¿Un proxy reescribe Host, authority o los detalles de terminación de TLS?
- ¿La solicitud es idempotente, está protegida por una clave de idempotencia y se encuentra dentro de un límite de tiempo de reintento?
Estructura de respuesta de 30 segundos
El 421 significa que el servidor considera que la solicitud se envió a la conexión o nodo incorrecto, no que falló una validación de negocio normal. Registro authority, SNI, certificado, ID de conexión y saltos de proxy, y luego comparo las rutas exitosas con las fallidas. Si se confirma una falta de coincidencia en la reutilización o el enrutamiento, el cliente puede reintentar en una nueva conexión, de forma automática solo para solicitudes idempotentes o con clave de idempotencia y con un límite máximo. La solución suele consistir en agrupar los pools de conexiones, preservar SNI/Host o ajustar el enrutamiento de proxies en lugar de realizar más reintentos a ciegas.
Análisis paso a paso
Paso 1: Definir el límite del 421
RFC 9110 define el 421 cuando el origen considera que una solicitud fue mal dirigida y no puede producir una respuesta para la combinación de scheme y authority del URI. Es diferente de un recurso inexistente, un permiso denegado o un error de validación de negocio.
Paso 2: Verificar la identidad del destino
Captura el scheme de la URL, authority, Host, SNI, SAN del certificado, ALPN y los marcadores de reutilización de conexión. Una solicitud HTTPS necesita un certificado y una identidad TLS que cubran el origen de destino; la resolución DNS por sí sola no es suficiente.
Paso 3: Inspeccionar la agrupación y reutilización
HTTP/2 puede transportar muchas solicitudes en una sola conexión, pero un servidor puede rechazar un authority en una conexión ya establecida. Verifica si los pools están agrupados por proxy, parámetros TLS y authority, y si se está reutilizando incorrectamente una conexión antigua.
Paso 4: Rastrear la cadena de proxies
Registra el ID de solicitud, authority, SNI, el upstream seleccionado y el estado en la CDN, la pasarela, la malla de servicios y el origen. Compara los nodos visitados por solicitudes exitosas y con 421 para detectar reescritura de Host, SNI faltante o mal enrutamiento.
Paso 5: Reintentar en una nueva conexión
La especificación permite que un cliente reintente un 421 en una conexión diferente. La nueva conexión debe rehacer DNS, TLS, ALPN y la vinculación de authority; enviar la misma solicitud en la conexión antigua no es suficiente. Verifica primero la idempotencia del método, el cuerpo reproducible y el límite de tiempo.
Paso 6: Corregir el enrutamiento del lado del servidor
Mantén alineada la configuración de scheme, authority, SNI y certificados en el edge y el origen, y preserva los campos requeridos durante el reenvío. Para certificados comodín o compartidos, decide explícitamente qué dominios pueden compartir conexiones y cuáles deben aislarse.
Paso 7: Agregar observabilidad y pruebas de regresión
Mide el 421 por authority, ID de conexión, protocolo, nodo y versión de certificado. Utiliza pruebas de carga HTTP/2 multidominio, alternadores de reutilización e inyección de fallas para validar la solución y asegurarte de que los reintentos en nuevas conexiones no oculten un defecto de enrutamiento persistente.
Respuesta de ejemplo de alta calidad
Primero verificaría si el 421 aparece únicamente en conexiones HTTP/2 reutilizadas. Los registros capturan scheme, authority, Host, SNI, SAN del certificado, ALPN, ID de conexión y el upstream del proxy. Si una solicitud fallida a api.example.com se reutilizó en una conexión configurada solo para static.example.com, eso coincide con un 421. El cliente reintenta una vez en una nueva conexión solo para GET o una solicitud con clave de idempotencia; una escritura se pasa a la capa de negocio para su confirmación. El servidor verifica que la CDN, la pasarela y el origen preserven authority y SNI, y agrupa los pools por dominio. Luego mido el 421 por dominio y nodo, y valido la corrección con pruebas de reutilización multidominio.
Errores comunes
- Tratar el 421 como 404, 401 o un 400 ordinario y modificar parámetros de negocio.
- Verificar DNS pero no SNI, SAN del certificado, authority o el reenvío de proxies.
- Reintentar indefinidamente en la misma conexión tras un 421.
- Reproducir automáticamente un POST con efectos secundarios sin protección de idempotencia.
- Conservar solo el error final del cliente y perder la evidencia de conexión y enrutamiento salto a salto.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Cuál es la diferencia clave entre 421 y 400?
El 400 normalmente indica una sintaxis de solicitud no válida o errores de framing en el mensaje. El 421 apunta a una falta de coincidencia entre el destino y el servidor o la conexión actual, especialmente en el enrutamiento, authority o la identidad TLS.
Pregunta de seguimiento 2: ¿Por qué HTTP/2 expone esto con más frecuencia?
HTTP/2 admite multiplexación y conexiones compartidas, por lo que un cliente puede enviar múltiples authorities a través de una sola conexión TLS. Un servidor que rechaza esa combinación devuelve un 421.
Pregunta de seguimiento 3: ¿Cambiar la IP solucionará el problema?
No necesariamente. Si la agrupación en pools, SNI o la reescritura de proxies son incorrectos, una IP diferente solo altera la probabilidad. Verifica primero la identidad TLS de la nueva conexión y la ruta completa.
Pregunta de seguimiento 4: ¿Cuándo se puede reintentar un POST?
Únicamente cuando la API cuenta con una clave de idempotencia, deduplicación en el servidor o un contrato de reproducción explícito, y el cuerpo sigue disponible dentro del límite de tiempo.
Pregunta de seguimiento 5: ¿Cómo se demuestra que la reutilización de conexiones es la causa?
Compara el comportamiento con la reutilización habilitada y deshabilitada, los IDs de conexión, las secuencias de authority y los nodos que fallan. Una conexión nueva y exitosa junto con fallas reproducibles de reutilización proporciona una evidencia más sólida.
Pregunta de seguimiento 6: ¿Sobre qué debería alertar producción?
Monitorea la tasa de 421, el éxito de los reintentos y la creación de nuevas conexiones por authority, protocolo, nodo de edge y versión del certificado. Un pico a menudo indica una desviación en el enrutamiento o en los certificados.