O que é o nginx e por que ele está na frente de quase tudo

Publicado em 2026-09-12 por frfrand

Un proxy inverso explicado sin rodeos: qué resuelve, por qué tu app no debería hablar con Internet directamente, y los tres errores que dan 502, 504 y 413.

Sua aplicação roda na porta 3000. As pessoas acessam por https://tudominio.com, que é a porta 443. Quem as conecta?

Um proxy reverso. Quase sempre, nginx.

A palavra "reverso" vem da comparação com o proxy tradicional: aquele representa o cliente perante os servidores; este representa os servidores perante o cliente. Do lado de fora, o nginx é o seu site. Sua aplicação não faz ideia de que a Internet existe.

O que resolve concretamente

Termina o HTTPS. O certificado fica no nginx. Sua aplicação recebe HTTP simples pelo localhost e não precisa saber nada de TLS, nem de renovações, nem de versões de protocolo.

Permite vários sites em um servidor. O nginx olha o nome de domínio que o navegador solicitou e decide para qual aplicação enviar a requisição. Três domínios, três aplicações, um único servidor e um único IP.

Serve arquivos estáticos. Imagens, CSS, JavaScript: o nginx os entrega diretamente do disco, muito mais rápido que sua aplicação e sem gastar processos dela.

Protege. Sua aplicação não tem nenhuma porta exposta à Internet. E no caminho podem ser adicionados limites de requisições, listas de bloqueio, compressão e cabeçalhos de segurança.

A configuração mínima, linha por linha

server { listen 443 ssl; server_name miapp.com;

location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; } }

As três cabeçalhos não são decorativos e esquecê-los causa problemas confusos:

• Sem Host, sua aplicação acha que o domínio é localhost, e as URLs que ela gera vão sair erradas.
• Sem X-Real-IP, todos os seus visitantes aparecem nos logs com o endereço do próprio servidor.
• Sem X-Forwarded-Proto, seu framework acha que a conexão é HTTP e pode criar redirecionamentos infinitos ao tentar forçar HTTPS.

Os três erros que você vai ver

502 Bad Gateway. O nginx não conseguiu falar com sua aplicação. O problema não está no nginx: seu app não está rodando, caiu, ou está escutando em outra porta. Veja o log do seu app, não o do nginx.

504 Gateway Timeout. Sua aplicação respondeu, mas demorou mais do que o nginx espera (60 segundos por padrão). Se for uma operação legítima e lenta, aumente o proxy_read_timeout. Caso contrário, o problema é a consulta.

413 Request Entity Too Large. Alguém tentou enviar um arquivo maior que o client_max_body_size, que vem com 1 MB por padrão. Isso confunde muito porque o erro chega antes do seu código saber.

A regra que evita quedas

nginx -t && systemctl reload nginx

Sempre as duas, sempre nessa ordem. nginx -t valida a configuração e te diz o arquivo e a linha do erro. Sem isso, um ponto e vírgula esquecido pode deixar seu site fora do ar.

E reload, não restart: reload aplica a nova configuração sem cortar as conexões que estão em andamento.

Onde se encaixa no ArduMaker

Cada domínio que você publica fica com seu bloco de nginx e seu certificado, emitido e renovado sozinho. É possível editar a configuração pelo painel quando for necessário algo particular, e ela é validada antes de aplicar, que é exatamente o nginx -t de cima, mas sem a possibilidade de esquecê-lo.