1. Planteamiento y contexto
Una API multiinquilino HTTPS reutiliza conexiones HTTP/2 entre varios dominios. Algunas solicitudes reciben 421 de forma intermitente, y el equipo desea reescribirlo como 503 en el controlador de la aplicación. Evalúe la semántica de 421, explique SNI frente a Host y diseñe el plan de gateway, origen, cliente y observabilidad. Asuma que las solicitudes pueden pasar a través de una CDN, un proxy inverso y una malla de servicios.
2. Qué está evaluando el entrevistador
- Si sabe que 421 significa que la solicitud llegó a un origen incapaz o no dispuesto a proporcionar una respuesta autoritativa para el URI de destino.
- Si puede conectar la reutilización de conexiones, TLS SNI, el Host de la solicitud, el esquema y la autoridad en una única cadena de diagnóstico.
- Si comprende que un proxy no debe inventar un 421 a partir de su propia decisión de enrutamiento y que un cliente solo debe reintentar en una nueva conexión.
- Si puede separar 421 de fallas de upstream, 404, 503 y errores de configuración de certificados en lugar de limitarse a cambiar el código de estado.
3. Preguntas aclaratorias antes de responder
- ¿El 421 es generado por el origen, el gateway, la CDN o la aplicación?
- ¿La solicitud utiliza HTTP/2 o HTTP/3, y puede una sola conexión transportar múltiples autoridades?
- ¿Cuáles son el TLS SNI, el HTTP Host y el host virtual seleccionado en el último salto?
- ¿Puede el cliente abrir una nueva conexión para el dominio de destino, y el método es idempotente o ya generó efectos secundarios?
4. Estructura de respuesta de 30 segundos
421 significa que el origen considera que la solicitud fue dirigida a la conexión o al host virtual incorrecto, como una combinación incompatible entre el certificado de la conexión y la autoridad de destino. Diagnostique SNI, Host, esquema, autoridad, agrupación de conexiones (connection pooling) y enrutamiento del origen antes de cambiar la respuesta; no lo reescriba como 503. Un origen puede enviar 421, mientras que un proxy debe reenviarlo en lugar de generarlo a partir de su propia decisión de enrutamiento. Un cliente puede reintentar en una conexión nueva, sujeto a la idempotencia del método, la rejugabilidad del cuerpo de la solicitud y el retroceso (backoff). Correlacione en los registros el ID de conexión, SNI, autoridad, ruta y resultado del reintento.
5. Respuesta detallada paso a paso
Paso 1: Definir el límite de responsabilidad
La RFC 9110 define 421 como un rechazo del origen debido a que el URI de destino parece haber sido mal dirigido. La causa puede ser un desajuste en la configuración del origen o una solicitud que no se ajusta al contexto de la conexión actual. La aplicación no debe mapear tiempos de espera arbitrarios de upstream, errores de DNS o certificados vencidos a 421; esas condiciones requieren su propia semántica.
Paso 2: Reconstruir el contexto de la conexión
Durante el protocolo de enlace TLS, SNI selecciona un certificado y un host virtual. Una vez establecido el cifrado, el Host o la autoridad de la solicitud selecciona el destino. HTTP/2 puede transportar múltiples solicitudes en una sola conexión, pero la reutilización es segura solo cuando el certificado, el protocolo y la configuración del servidor lo permiten. Registre SNI, Host, esquema, autoridad, ALPN, hora de inicio de la conexión y backend seleccionado, luego compare quién es el propietario de la conexión con el destino de la solicitud.
TLS SNI: api-a.example
HTTP authority: api-b.example
ALPN: h2
selected virtual host: api-a.example
result: 421 from originPaso 3: Manejar proxies, CDNs y mallas de servicios
Un proxy perimetral debe preservar la autoridad original, los detalles de terminación de TLS y el estado de la conexión upstream, al tiempo que evita la reutilización entre inquilinos en una conexión upstream incompatible. Puede reenviar un 421 del origen, pero no debe generar un 421 simplemente porque su propia ruta falló; utilice el contrato de 502, 503 o de error de enrutamiento del proxy. La clave del pool de una malla de servicios debe incluir campos que afecten la selección de certificados y hosts virtuales, en lugar de agrupar solo por IP y puerto.
Paso 4: Diseñar los reintentos del cliente
La especificación permite que un cliente reintente un 421 en una conexión diferente, incluida una conexión nueva hacia el origen de destino. Antes de reintentar, verifique la idempotencia del método, la rejugabilidad del cuerpo de la solicitud, la validez del token y si ya ocurrió una respuesta parcial o un efecto secundario. Para POST u otros métodos con efectos secundarios, use una clave de idempotencia o confirme que la ejecución no ocurrió antes de reintentar. Limite los intentos y registre el motivo; un bucle fijo no debe ocultar un error de configuración.
Paso 5: Observar, corregir y realizar pruebas de regresión
Desglose 421 por SNI, autoridad, host virtual, versión del protocolo y nodo perimetral en lugar de observar únicamente un recuento global. Mantenga un ID de conexión redactado, la decisión de ruta, la huella digital del certificado, la respuesta del origen y si el cliente abrió una nueva conexión. Después de una corrección, pruebe tres rutas: la reutilización válida no debe devolver 421; una conexión incompatible debe devolver consistentemente 421; un reintento en una nueva conexión debe alcanzar la respuesta final del servicio de destino.
6. Ejemplo de una respuesta de alta calidad
Trataría 421 como una incompatibilidad en el contexto de conexión o en la autoridad del origen, no como una interrupción transitoria genérica. Primero correlacionaría TLS SNI, autoridad HTTP, certificado, ALPN, pool de conexiones y enrutamiento del host virtual para confirmar si la solicitud reutilizó una conexión incompatible. El origen puede devolver 421, mientras que un proxy debe reenviarlo en lugar de inventarlo. Un cliente puede abrir una nueva conexión para el origen de destino y reintentar solo después de verificar la idempotencia, la repetición del cuerpo y las claves de idempotencia. Mediría el código por dominio, protocolo, nodo y pool, para luego validar la solución con pruebas de regresión tanto de reutilización como de conexión nueva.
7. Errores comunes
- Reescribir cada 421 como 503 → pierde la evidencia del contexto de conexión → preserve 421 y registre SNI y autoridad en el gateway.
- Verificar Host pero no SNI → omite la reutilización de certificados y hosts virtuales → registre los destinos tanto de TLS como de HTTP.
- Permitir que un proxy invente 421 → viola el límite de responsabilidad del código de estado → reenvíe el 421 del origen y use un contrato 5xx claro para fallas de enrutamiento del proxy.
- Reintentar POST incondicionalmente → puede duplicar escrituras → use una clave de idempotencia o confirme que no hubo ejecución antes de realizar un reintento acotado.
- Probar solo un dominio y una conexión → omite la reutilización de HTTP/2 → incluya pruebas de reutilización entre dominios, reutilización incompatible y conexiones nuevas.
8. Preguntas de seguimiento y respuestas
¿En qué se diferencia 421 de 503?
421 apunta a un desajuste entre la solicitud y la conexión actual o la autoridad del origen; una nueva conexión específica para el destino puede recuperarse. 503 significa que el servicio no puede manejar temporalmente la solicitud, a menudo debido a capacidad, mantenimiento o una dependencia. Sus soluciones, reglas de reintento y dimensiones de alerta difieren.
¿Puede un cliente reintentar 421 en la conexión antigua?
No debe seguir utilizando una conexión que fue juzgada como no apta. Abra una nueva conexión para el origen de destino y renegocie TLS y el protocolo, respetando al mismo tiempo el retroceso (backoff), la repetición del cuerpo y el estado de autenticación.
¿Puede un proxy devolver 421 cuando Host y SNI difieren?
No únicamente a partir de la propia inferencia del proxy. Debe seguir su contrato de error de enrutamiento o reenviar la solicitud para que el origen decida. Si reenvía un 421 del origen, preserve la información de la fuente para el diagnóstico.
¿Cómo demuestra que una corrección en el pool no afectó el rendimiento?
Mida por separado la reutilización válida, los pools basados en autoridad y la reutilización incompatible rechazada. Compare la tasa de 421, la cantidad de handshakes, la latencia de cola (tail latency), la cantidad de conexiones y la CPU. El objetivo es eliminar la reutilización incorrecta manteniendo el costo de handshakes adicionales dentro del presupuesto.