--- title: Solução de problemas de SNI e 421 Misdirected Request description: "Se o seu site no Deflect estiver enfrentando erros HTTP 421, 403 ou 400, é possível que você esteja lidando com um problema de SNI. Este artigo tem o objetivo de orientá-lo na resolução desse problema. ### 1. O que…" url: "https://deflect.ca/pt/docs/solu-o-de-problemas-de-sni-e-421-misdirected-request/" updated: "2026-04-23" category: Solução de problemas --- # Solução de problemas de SNI e 421 Misdirected Request Se o seu site no Deflect estiver enfrentando erros HTTP 421, 403 ou 400, é possível que você esteja lidando com um problema de SNI. Este artigo tem o objetivo de orientá-lo na resolução desse problema. ### 1. O que é o SNI? O Server Name Indicator (SNI) é uma extensão do protocolo Transport Layer Security (TLS) que indica a qual nome de host o cliente está tentando se conectar no início do processo de handshaking. Isso permite que um servidor apresente vários certificados no mesmo endereço IP e número de porta e, portanto, permite que vários sites HTTPS seguros sejam servidos a partir do mesmo endereço IP sem exigir que todos esses sites usem o mesmo certificado. ### 2. Cabeçalho de host SNI e HTTP O cabeçalho do host HTTP também é usado para indicar o site que o cliente está tentando acessar. Mas ele não é enviado depois que a conexão SSL é estabelecida. Em outras palavras, tanto a SNI quanto o cabeçalho do host HTTP permitem que o cliente especifique o nome do servidor que está tentando acessar. No entanto, a SNI permite que essas informações estejam presentes no início do processo de configuração do SSL, o que é crucial quando vários sites SSL estão compartilhando um único endereço IP. Nem todo servidor da Web exige o alinhamento do nome SNI e do cabeçalho HTTP Host. Nos casos em que eles não coincidem, o cabeçalho do host HTTP geralmente tem precedência. No entanto, alguns servidores da Web, como o Apache, começaram recentemente a exigir uma correspondência entre o SNI e o nome do host HTTP, criando assim um problema de SNI. ### 3. Identificação do problema do SNI Você pode estar lidando com um problema de conexão SNI se o seu site protegido pelo Deflect estiver enfrentando o seguinte erro HTTP: - 421 Solicitação mal direcionada Ou você está vendo o seguinte erro **, parcial ou totalmente:** - 403 Proibido - 400 Solicitação incorreta E uma das condições abaixo se aplica a você: - Você atualizou recentemente seu servidor da Web de origem - Você atualizou recentemente a configuração do servidor Web de origem - Você está usando o Apache como seu servidor de origem - Você está hospedando vários hosts virtuais em um servidor de origem #### 3.1. Inspecionar o registro do servidor da Web Inspecione o registro do servidor da Web de origem para ver se há mensagens de erro. Por exemplo, se você vir a seguinte mensagem no log de erros do Apache, isso indica que você está enfrentando um problema de SNI. ``` AH02032: Hostname example.com provided via SNI and hostname www.example.net provided via HTTP are different ``` #### 3.2. Conectar-se diretamente ao servidor de origem Verifique se você está encontrando um problema de SNI porque seu site está localizado atrás do proxy reverso do Deflect Nginx. Lembre-se de que não há necessidade de desativar o Deflect universalmente para realizar esse teste. Em vez disso, você pode executar convenientemente o seguinte comando cURL para obrigar a resolução de DNS para o IP do seu servidor de origem. ``` curl --resolve :443: -k "https://" ``` Se não for possível executar o comando cURL, você tem a alternativa de modificar seu /etc/hosts local (ou C:\Windows\System32\drivers\etc\hosts para usuários do Windows). Isso permite que você obrigue manualmente um nome de domínio a resolver para o IP do servidor de origem. **Lembre-se de reverter a alteração depois de concluir o teste.** #### 3.3. Servidor de origem Apache Em 10 de julho de 2025, o Apache lançou a versão 2.4.64, com correções de segurança específicas sobre o manuseio do SNI. Basicamente, essa nova atualização **rejeitará uma conexão se o nome SNI no pacote de handshake do Secure Sockets Layer (SSL) não corresponder ao cabeçalho Host** no pacote HTTP dessa conexão SSL específica. Consulte o [registro de alterações do Apache](https://www.apachelounge.com/changelog-2.4.html). Os sites que utilizam o Nginx como proxy reverso e o Apache como servidor de origem são afetados por essa atualização. Isso ocorre porque, em uma configuração de proxy reverso, o Nginx não retransmite, por padrão, o nome SNI para o servidor de origem. ### 4. Resolução do problema SNI #### 4.1. Verifique se o SNI está ativado em seu site O Deflect ativa automaticamente a SNI para sites registrados a partir do final de 2024. Mas ele pode ser desativado manualmente por nossa equipe de suporte. Para verificar se esse recurso está ativado ou não para o seu site, faça login no painel do Deflect e localize essas configurações em **Settings -> Server Name Indication (SNI)**. Na maioria dos cenários, é aconselhável manter essas configurações ativadas; somente em raras circunstâncias você precisaria desativá-las. No entanto, se o problema persistir mesmo depois de ativar a SNI, talvez você deva considerar a possibilidade de desativar a reutilização da sessão SSL. #### 4.2. Desativar a reutilização da sessão SSL Por padrão, o Deflect reutiliza a sessão SSL no pool de conexões no servidor de origem idêntico para otimização. No entanto, se o servidor de origem hospedar vários hosts virtuais com nomes de domínio diferentes, a desativação da reutilização da sessão SSL poderá resolver o erro de incompatibilidade de SNI. No painel do Deflect, você pode localizar esse recurso em **Labs -> Disable SSL Session Reuse (Desativar reutilização de sessão SSL**). #### 4.3. Vários hosts virtuais Se estiver operando vários hosts virtuais no mesmo endereço IP de origem no Deflect, é recomendável revisar a configuração do respectivo servidor Web e ativar a SNI e a desativação da reutilização da sessão SSL em todos esses hosts virtuais. #### 4.4. domínios www Se o seu site utilizar o domínio apex e o domínio www, com o último adicionado automaticamente pelo Deflect e com proxy para o mesmo IP de origem, considere **adicionar o nome de domínio www ao nome do servidor na configuração do servidor da Web.** #### 4.5. Certifique-se de que o nome comum do certificado de origem corresponda ao nome do host Talvez você queira garantir que o nome comum (CN) do certificado SSL em seu servidor de origem corresponda às solicitações de nome de host do visitante. Você pode verificar isso conectando-se diretamente ao seu servidor de origem usando o cURL. ``` curl --resolve :443: -k "https://" -v -I ``` Procure por **CN=** na saída, por exemplo: ``` * Added example.com:443:203.0.0.0 to DNS cache * Hostname example.com was found in DNS cache * Trying 203.0.0.0:443... * Connected to example.com (203.0.0.0) port 443 * ALPN: curl offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): * (304) (IN), TLS handshake, Server hello (2): * (304) (IN), TLS handshake, Unknown (8): * (304) (IN), TLS handshake, Certificate (11): * (304) (IN), TLS handshake, CERT verify (15): * (304) (IN), TLS handshake, Finished (20): * (304) (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF * ALPN: server accepted h2 * Server certificate: * subject: CN=example.com ... ``` Se o nome comum não corresponder ao nome do host, há várias opções disponíveis: - Gere e instale um certificado SSL de autoassinatura com o nome comum correto, pois o Deflect não exige um certificado SSL válido assinado por uma CA confiável em seu servidor de origem. - Solicite ao Deflect que assine um certificado de origem no painel em [HTTPS / TLS -> Certificados de origem](https://deflect.ca/pt/docs/guia-http-tls/#origin-certificates) e instale-o em seu servidor. - Gerar e instalar um certificado SSL válido usando o Lets Encrypt ou outro provedor de SSL. #### 4.6. Correção temporária: origem HTTP **Atenção! Esta solução não é segura; ela deve servir apenas como uma medida temporária até que uma correção permanente seja implementada.** Se todas as soluções descritas acima não derem certo e for necessário um período de depuração, o problema do SNI pode ser contornado obrigando o Deflect a se conectar ao seu servidor de origem via HTTP. Para ativar o desvio, é necessário verificar a disponibilidade do HTTP no servidor de origem, conectando-se diretamente a ele pela porta 80. ``` curl --resolve :80: "http://" ``` Certifique-se de que o conteúdo seja servido corretamente na porta 80. **Desative qualquer redirecionamento 301 ou 302 para HTTPS a fim de evitar loop de redirecionamento.** No painel do Deflect, em **HTTPS / TLS -> Configuração de HTTPS/TLS**, ative [a criptografia TLS flexível](https://deflect.ca/pt/docs/guia-http-tls/#2-toc-title) **Implicações de segurança**: Embora seu site permaneça acessível por meio de HTTPS, a conexão segura cobrirá apenas o segmento que vai do navegador do visitante até a borda do Deflect. **Os dados transmitidos entre a borda do Deflect e seu servidor de origem não serão protegidos**, o que representa riscos potenciais. #### 4.7. Entre em contato com o suporte do Deflect Procure a ajuda de nossa [equipe de suporte do Deflect](https://deflect.ca/pt/docs/entre-em-contato-com-o-suporte-do-deflect/) se precisar de orientação durante todo esse processo. Inclua mensagens de erro do servidor, registros de acesso e capturas de tela para nos ajudar a resolver o problema mais rapidamente.