Um servidor, muitos domínios: como o tráfego é distribuído

Publicado em 2026-09-12 por frfrand

Cómo un solo servidor con una sola dirección atiende diez sitios distintos, qué es SNI, por qué el primer bloque de nginx es especial y cómo evitar que un dominio sirva el sitio de otro.

Você tem um servidor com um único endereço público. Quer hospedar dez sites diferentes, cada um com seu domínio e seu certificado. Como o servidor sabe qual servir?

A resposta é que o navegador diz. Antes de pedir qualquer coisa, ele anuncia para qual nome está vindo.

Em HTTP é fácil

Quando o navegador abre a conexão, envia um cabeçalho:

GET /preços HTTP/1.1 Host: loja.exemplo.com

O nginx lê esse Host, compara com os server_name de seus blocos e escolhe o correspondente. Cada site é um bloco server em seu próprio arquivo, todos ouvindo na mesma porta.

Em HTTPS há um problema de ordem

Com HTTPS surge um problema de ovo e galinha: o certificado precisa ser apresentado no início do handshake, antes de existir uma requisição HTTP onde ler o Host. Qual certificado o servidor apresenta se ainda não sabe qual site estão pedindo?

A solução se chama SNI (Server Name Indication): o cliente inclui o nome do domínio na primeira mensagem do handshake, em texto claro. O servidor lê esse nome, escolhe o certificado correto e continua.

É por isso que hoje um servidor pode ter vinte certificados e apresentar o correspondente. Antes do SNI era necessário um endereço por certificado, o que é parte do porquê de a hospedagem compartilhada com HTTPS ser cara.

Um detalhe que surpreende: como o SNI viaja sem criptografia, a rede pode ver para qual domínio você se conecta, embora não veja o conteúdo.

O bloco padrão, que é onde se rompe

Esta é a parte que causa os problemas mais desconcertantes.

Se chegar uma solicitação com um nome que não corresponde a nenhum server_name, o nginx não devolve um erro: ele encaminha para o primeiro bloco que escuta nessa porta. E "o primeiro" depende da ordem alfabética dos arquivos, que ninguém escolheu de propósito.

Sintomas típicos:

• Um domínio novo, para o qual você ainda não configurou o bloco, mostra o site de outro cliente.
• Os scanners que entram pelo endereço público veem um site real em vez de nada.

A solução são cinco linhas:

server { listen 443 ssl default_server; server_name _; ssl_reject_handshake on; return 444; }

444 é um código próprio do nginx que significa "feche a conexão sem responder". Quem não pediu um domínio conhecido, não recebe nada. E como efeito colateral, um domínio mal configurado deixa de falhar silenciosamente: falha de forma óbvia, o que é muito melhor.

Um erro que custa caro

A ordem dos blocos importa, mas a ordem das correspondências também. O nginx prefere a correspondência exata sobre o curinga. Se você tem:

server_name *.ejemplo.com; server_name app.ejemplo.com;

uma solicitação para app.ejemplo.com vai para o segundo, mesmo que o primeiro esteja antes no arquivo. Isso é o que você quer quase sempre, mas vale a pena saber porque explica por que às vezes "a ordem não importa" e às vezes sim.

Como se resolve no ArduMaker

Cada domínio que você adiciona gera seu próprio bloco e seu próprio certificado, sem que você precise tocar em arquivos nem se lembrar do default_server. E se precisar de uma configuração específica, ela pode ser editada no painel, com validação antes de aplicar.

A vantagem de ser automático não é se livrar do trabalho de escrever vinte linhas: é que o décimo site fica tão bem configurado quanto o primeiro, seis meses depois e com outra pessoa fazendo isso.