ErrorBase
Referencia técnica independienteSitio oficial
  • Software y sistemas
  • Servicio HTTP

421

HTTP 421 Misdirected Request: el servidor no atiende ese dominio

Verificada con fuentes2 fuentesRevisada 4 oct 2026
¿Viene un técnico? Mira los 2 pasos que debe enseñarte

Nivel de riesgo

Seguro

Puedes actuar sin peligro siguiendo las comprobaciones seguras.

Urgencia

Media — atiéndelo hoy

Respuesta rápida

HTTP 421 indica que la petición llegó a un servidor que no puede responder con autoridad por esa dirección, a menudo por reutilizar una conexión abierta para otro dominio. Prueba una conexión nueva hacia el mismo dominio y pide al administrador que revise sus hosts virtuales y certificados.

Seguridad primero

Antes de continuar

  • No silencies el 421 haciendo que el servidor responda por cualquier dominio: RFC 9110 avisa de que aceptar hosts que no corresponden puede servir contenido no público o envenenar cachés.

Puedes hacerlo con seguridad

  • Petición repetida por una conexión nueva
  • Certificado presentado y nombres que cubre
  • Host virtual y reglas de la pasarela

Deja estas tareas a un profesional cualificado

  • No intentes esta tarea profesional: Corrección de enrutado por SNI y Host en la CDN o el balanceador
  • No intentes esta tarea profesional: Alta del dominio en el servidor de origen

Lo que un técnico debe poder justificar

Viene un técnico

Estos son los pasos que tiene que hacer y enseñarte. Márcalos mientras trabaja: si se salta pasos, no aceptes el cambio de pieza.

No son instrucciones para que abras o manipules el equipo. Son las comprobaciones que deben sostener una conclusión técnica.

  1. Corrección de enrutado por SNI y Host en la CDN o el balanceador

    Qué haceEl operador de la CDN o del balanceador alinea la selección de servidor por SNI con el host de cada petición, o devuelve 421 de forma deliberada cuando no pueden coincidir.

    Te tiene que enseñardos peticiones a dominios del mismo certificado servidas sin 421.

    Por escritolas reglas cambiadas y los dominios afectados.

  2. Alta del dominio en el servidor de origen

    Qué haceEl proveedor de hosting o el administrador registra el dominio como origen atendido, con su certificado, en el servidor que recibe la conexión.

    Te tiene que enseñarla configuración del host y una petición correcta tras el cambio.

    Por escritoel dominio dado de alta y la fecha.

Antes de aceptar una pieza o reparación

Aún no ha demostrado nada. No aceptes un cambio de pieza solo por el código.

Sigue estos pasos

Aviso: Sigue el orden documentado. Un código identifica el sistema afectado, pero por sí solo no demuestra qué pieza está averiada.

  1. Petición repetida por una conexión nueva

    Sin herramientas especiales

    Quién:
    el desarrollador o el administrador, con un cliente HTTP en línea de comandos que abra una sola conexión por ejecución.
    Cómo:
    lanza la misma URL en una ejecución aislada, sin otras peticiones previas a dominios hermanos, y anota el estado y la versión de HTTP.
    Resultado que importa:
    si el 421 desaparece cuando la conexión es exclusiva para ese dominio.
    Si desaparece:
    confirma la reutilización de conexión entre dominios como origen; el servidor está avisando de que no es el destino correcto para ella.
    Si el 421 sigue en una conexión nueva:
    descarta la reutilización e indica que el servidor no tiene configurado ese dominio.
    Evidencia a conservar:
    salida del cliente con versión de HTTP, SNI y hora de cada prueba.

    Evidencia: RFC 9110 section 15.5.20 - 421 Misdirected Request · RFC 9113 section 9.1.1 - Connection Reuse

  2. Certificado presentado y nombres que cubre

    Sin herramientas especiales

    Quién:
    el administrador del sitio o el operador de la CDN.
    Cómo:
    consulta el certificado que entrega el servidor para el dominio afectado y lista sus nombres alternativos; compáralo con el dominio de la URL.
    Resultado que importa:
    si el certificado de esa conexión es válido para el host pedido.
    Si no cubre el dominio:
    confirma que el servidor debía rechazar la petición; emite o asocia un certificado correcto para ese host.
    Si lo cubre junto a otros dominios:
    indica que los navegadores pueden compartir conexión entre ellos; revisa que cada servidor detrás acepte todos esos nombres.
    Evidencia a conservar:
    lista de nombres del certificado, emisor y fecha de caducidad.

    Evidencia: RFC 9110 section 7.4 - Rejecting Misdirected Requests · RFC 9113 section 9.1.1 - Connection Reuse

  3. Host virtual y reglas de la pasarela

    Sin herramientas especiales

    Quién:
    el administrador del servidor de origen o de la pasarela inversa.
    Cómo:
    busca en la configuración el bloque que atiende el host y puerto de la URL y la regla que elige backend según SNI o Host.
    Resultado que importa:
    si existe una entrada para ese origen exacto.
    Si no existe o apunta a otro backend:
    confirma la causa; añade el host o corrige la regla de enrutado.
    Si existe y es correcta:
    descarta la configuración local y revisa la terminación TLS de la CDN delante.
    Evidencia a conservar:
    fragmento de configuración revisado y registro de acceso con el 421.

    Evidencia: RFC 9110 section 15.5.20 - 421 Misdirected Request · RFC 9110 section 4.3.1 - URI Origin

Situación no resuelta

Si el error persiste, no sigas probando por tu cuenta. Mira qué tiene que hacer y enseñarte el técnico.

Dónde se aplica este código

Un código solo tiene significado dentro del producto y la versión correctos.

Ámbito principal

Sistema
Software y sistemas
Marca
HTTP
Tipo de producto
Servicio HTTP

Variantes conocidas del código

  • 421 Fehlgeleitete Anfrage
  • 421 Misdirected Request
  • 421 Requête mal acheminée
  • 421 Richiesta indirizzata male
  • 421 Solicitud mal dirigida
  • HTTP 421
  • HTTP status 421

Qué significa

RFC 9110 define 421 (Misdirected Request): el servidor de origen, o una pasarela en su nombre, rechaza una URI que no coincide con ningún origen configurado (esquema, host y puerto) o con el contexto de la conexión por la que llegó. Una petición https debe rechazarse si la conexión no usa un certificado válido para ese origen. En HTTP/2 los navegadores pueden reutilizar una conexión para varios dominios cubiertos por el mismo certificado, y un terminador TLS que elige servidor por SNI puede acabar enviando la petición al servidor equivocado. Un proxy nunca debe generar 421.

Advertencias y condiciones de parada

  • Seguroverificada con fuente

    No silencies el 421 haciendo que el servidor responda por cualquier dominio: RFC 9110 avisa de que aceptar hosts que no corresponden puede servir contenido no público o envenenar cachés.

    Evidencia: RFC 9110 section 7.4 - Rejecting Misdirected Requests

Síntomas y causas

Causas probables · en orden

  • Conexión HTTP/2 reutilizada para otro dominioFrecuente

    RFC 9113 permite reutilizar una conexión con varios dominios si el certificado los cubre; cuando la terminación TLS reparte por SNI, la petición del segundo dominio puede llegar a un servidor que no lo sirve y este responde 421.

    Evidencia: RFC 9110 section 15.5.20 - 421 Misdirected Request · RFC 9113 section 9.1.1 - Connection Reuse

  • Dominio sin host virtual en el servidor que recibePosible

    El origen responde 421 si la URI no coincide con un origen para el que está configurado, por ejemplo tras añadir un dominio al certificado o al DNS sin darlo de alta en el servidor.

    Evidencia: RFC 9110 section 15.5.20 - 421 Misdirected Request · RFC 9110 section 4.3.1 - URI Origin

  • Certificado no válido para el dominio pedidoPosible

    Una petición https solo se atiende por una conexión asegurada con un certificado válido para su origen; si el certificado de esa conexión no cubre el host, el servidor debe rechazarla.

    Evidencia: RFC 9110 section 7.4 - Rejecting Misdirected Requests

Técnico virtual

¿Sigue apareciendo 421 tras comprobarlo?

Responde unas preguntas para acotar la causa probable y la siguiente acción segura. Es una orientación - nunca sustituye a un profesional.

Iniciar diagnóstico

Fuentes y referencias técnicas

  1. 1

    IANA HTTP Status Code Registry

    Internet Assigned Numbers Authority · 2025 · standard

  2. 2

    RFC 9110 - HTTP Semantics

    IETF / RFC Editor · 2022 · standard

Fuentes: IANA HTTP Status Code Registry · RFC 9110 - HTTP Semanticsrevisado 2026-10-04 · verificado

¿Te ha resultado útil esta ficha?