Erro 421 Misdirected Request

A RFC 9110, seção 15.5.20, diz que o servidor de origem envia 421 quando a URI pedida não corresponde a uma origem para a qual ele foi configurado, ou não corresponde ao contexto da conexão. O cliente pode repetir numa conexão nova, mesmo que o método não seja idempotente, porque nada foi processado. Proxies não podem gerar 421.

O código surgiu com o HTTP/2, em que o navegador reaproveita uma conexão TLS para vários domínios quando o certificado cobre todos e o DNS aponta para o mesmo IP. Se o servidor nesse IP não hospeda de fato um desses domínios, o 421 avisa o navegador para abrir uma conexão só para ele.

Uma segunda onda veio em julho de 2025 com o Apache httpd 2.4.64, que endureceu a checagem de SNI. Configurações com nginx na frente do Apache via HTTPS (comuns em cPanel, Plesk e DirectAdmin) passaram a devolver 421 porque o nginx não enviava SNI para o backend. O log de erros do Apache mostra AH02032 nesse caso.

Se você está visitando o site

• O navegador reaproveitou uma conexão HTTP/2 para um segundo subdomínio que divide certificado e IP, mas é atendido por outro backend.
• O site tem um proxy mal configurado; todo visitante vê o mesmo 421.

Se você administra o servidor

• O nginx faz proxy para um backend HTTPS sem proxy_ssl_server_name on, então o backend não recebe SNI, ou recebe o errado, e recusa o Host.
• Um certificado wildcard ou multidomínio permite que o navegador junte conexões de hosts que ficam em virtual hosts ou servidores diferentes.
• O mod_ssl do Apache percebe que o nome no SNI e o cabeçalho Host apontam para virtual hosts com configurações TLS incompatíveis (AH02032).

Se você está visitando o site

• Recarregue a página; o navegador tenta de novo numa conexão nova. Se persistir, feche o navegador para descartar conexões abertas, ou teste outro navegador.

Se você administra o servidor

• No nginx, repasse o SNI para upstreams HTTPS: proxy_ssl_server_name on; e proxy_ssl_name $host;. Os painéis de hospedagem incluíram isso depois da mudança do Apache 2.4.64.
• Dê certificados separados, ou IPs separados, para hosts que ficam em servidores diferentes, assim o navegador não junta as conexões deles.
• Procure AH02032 no log de erros do Apache para confirmar a divergência entre SNI e Host.

Na maior parte das vezes você está corrigindo um 421, não enviando. O bloco do nginx é a correção para o caso do proxy reverso; os exemplos de Express e Go mostram uma origem recusando domínios que não atende.

const HOSTS = new Set(['example.com', 'www.example.com']);

app.use((req, res, next) => {
  if (!HOSTS.has(req.hostname)) {
    return res.status(421).send('Misdirected Request');
  }
  next();
});

func onlyHosts(next http.Handler, hosts ...string) http.Handler {
	allowed := map[string]bool{}
	for _, h := range hosts {
		allowed[h] = true
	}
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		if !allowed[r.Host] {
			http.Error(w, "misdirected request", http.StatusMisdirectedRequest) // 421
			return
		}
		next.ServeHTTP(w, r)
	})
}

# Fix: send SNI to an HTTPS backend (avoids 421 from Apache 2.4.64+)
location / {
  proxy_pass https://backend;
  proxy_set_header Host $host;
  proxy_ssl_server_name on;
  proxy_ssl_name $host;
}

421 vs 400

O 400 serve para um Host ausente ou malformado; o 421 indica que o Host é válido, só não é atendido nesta conexão.

421 vs 502

O 502 é um proxy relatando resposta ruim do upstream; o 421 vem da própria origem, e proxies não podem gerá-lo.

Como resolver o erro 421 Misdirected Request com nginx?

Se o nginx faz proxy para um backend HTTPS, adicione proxy_ssl_server_name on; e proxy_ssl_name $host; no bloco location para o backend receber o SNI certo, e recarregue o nginx.

Por que o erro 421 apareceu depois de atualizar o Apache?

O Apache httpd 2.4.64 (julho de 2025) passou a exigir correspondência mais rígida entre o nome do SNI e o cabeçalho Host. Proxies na frente que não mandavam SNI para o Apache começaram a receber 421, registrado como AH02032.

O navegador pode repetir o pedido depois de um 421?

Pode. A RFC 9110 permite repetir numa conexão diferente, seja o método idempotente ou não, porque o servidor não processou o pedido.