Como configurar Docker e Nginx no FreeBSD 14.3

17 min de leitura  ·  Guia técnico

Como otimizar Docker e Nginx para automação residencial no FreeBSD 14.3 é o processo de organizar containers, portas, proxy reverso, logs e reinicialização para manter serviços como Home Assistant, Node-RED e n8n mais estáveis. Para ajustar o servidor do jeito certo, siga estes passos:

1. Confirme se FreeBSD 14.3, Docker e Nginx estão funcionando antes de alterar a configuração.
2. Mapeie quais containers precisam ser acessados externamente e quais devem ficar internos.
3. Deixe o Nginx como único ponto público para HTTP e HTTPS, evitando conflito nas portas 80 e 443.
4. Revise volumes persistentes, política de reinicialização e logs dos containers de automação.
5. Teste a configuração do Nginx, recarregue o serviço e valide cada domínio ou subdomínio.
6. Monitore CPU, memória, disco e erros para corrigir lentidão antes que afete a automação residencial.

Validando a base antes de otimizar o ambiente

Servidor de automação residencial com Docker precisa ser previsível: cada aplicação deve ter porta, volume, nome e rota bem definidos. No FreeBSD 14.3 LTS, o ponto mais importante é validar se a sua pilha de containers está compatível com o runtime disponível no ambiente, porque automação doméstica costuma depender de serviços contínuos, reinício automático e comunicação de rede estável. Antes de mexer em Nginx, revise a base para evitar corrigir o proxy quando o problema real está no container.

Use este artigo quando você já tem Docker e Nginx em execução e quer melhorar a organização do acesso a Home Assistant, Node-RED, n8n ou outros painéis internos. Se você ainda está planejando a infraestrutura, também vale revisar Compreendendo o Servidor VPS: O que é e Como Funciona! para entender o papel do servidor antes de publicar serviços em rede.

freebsd-version
uname -r
nginx -v
docker version
docker ps

Output esperado:
14.3
kernel compatível com FreeBSD 14.3
nginx version exibida
cliente e servidor Docker respondendo
lista de containers em execução

Ao rodar estes comandos, você verá se o sistema, o Nginx e o Docker respondem antes de qualquer mudança. Se algum comando falhar, pare a otimização e corrija a base primeiro. Otimizar proxy reverso sem confirmar que os containers estão ativos cria diagnóstico falso, principalmente quando há automações críticas dependentes de webhook, MQTT, painel web ou integrações externas.

Pré-requisitos

• Acesso administrativo ao servidor FreeBSD 14.3 LTS.
• Nginx já instalado e com permissão para recarregar a configuração.
• Docker ou runtime compatível já validado no ambiente.
• Um ou mais serviços de automação em containers, como Home Assistant, Node-RED ou n8n.
• Domínio ou subdomínios apontando para o IP do servidor, quando houver acesso externo.
• Conhecimento básico de terminal, leitura de logs e edição de arquivos de configuração.
• Backup da configuração atual antes de alterar proxy, portas ou volumes.

Mapeie portas e serviços antes de expor a automação residencial

Conflito de portas entre Docker e Nginx é uma das causas mais comuns de instabilidade quando vários painéis de automação rodam no mesmo servidor. A regra prática é simples: evite publicar cada container diretamente na internet. Em vez disso, mantenha as aplicações em portas internas ou restritas e deixe o Nginx receber o tráfego externo, roteando cada domínio para o serviço correto. Em setups gerenciados com docker-compose, você consegue declarar essa separação de portas e redes no próprio arquivo de composição, tornando os serviços mais fáceis de manter e auditar.

Comece listando containers e portas publicadas. Procure principalmente por serviços tentando usar 80, 443 ou a mesma porta de outro container. Em setups com Home Assistant Docker e Nginx no FreeBSD, Node-RED proxy reverso e n8n Docker Nginx, o erro normalmente aparece como falha ao iniciar container, página errada abrindo no domínio ou resposta 502 no navegador.

docker ps --format "table {{.Names}}\t{{.Ports}}\t{{.Status}}"

Output esperado:
NAMES          PORTS                  STATUS
homeassistant  8123/tcp                Up
nodered        1880/tcp                Up
n8n            5678/tcp                Up
nginx          80/tcp, 443/tcp         Up

Atenção: se algum container de aplicação estiver publicado diretamente em 0.0.0.0:80 ou 0.0.0.0:443, alterar essa porta pode interromper o acesso externo. Faça a mudança em janela de manutenção e mantenha acesso administrativo aberto para reverter caso necessário.

1. Identifique quais serviços precisam de acesso público.
2. Remova exposição direta desnecessária das portas HTTP e HTTPS nos containers de aplicação.
3. Mantenha apenas o Nginx exposto para usuários externos.
4. Use subdomínios claros, como automacao.seudominio, nodered.seudominio e n8n.seudominio.
5. Teste cada aplicação localmente antes de validar pelo domínio.

Configure o Nginx como proxy reverso para Home Assistant, Node-RED e n8n

Nginx como proxy reverso para automação centraliza o acesso, reduz colisões de porta e facilita aplicar TLS e cabeçalhos consistentes. O objetivo não é tornar o Nginx obrigatório para todos os casos, mas usá-lo quando há múltiplas aplicações web no mesmo servidor e você precisa separar cada painel por domínio ou subdomínio. Para HTTPS, a combinação mais comum em ambientes FreeBSD é usar SSL Let's Encrypt via certbot, que emite e renova certificados automaticamente, eliminando a necessidade de certificados auto-assinados em produção.

Antes de editar arquivos, faça backup da configuração atual. Em FreeBSD, muitos ambientes usam arquivos do Nginx abaixo de diretórios de configuração do próprio serviço. Se o seu caminho for diferente, adapte o comando ao local usado na sua instalação.

nginx -T

Output esperado:
configuração completa do Nginx exibida
linhas com server_name
linhas com proxy_pass quando já existirem rotas configuradas

nginx -t

Output esperado:
nginx: the configuration file syntax is ok
nginx: configuration file test is successful

Ao rodar nginx -t, você confirma a sintaxe antes de recarregar o serviço. Isso evita derrubar todos os painéis por erro simples de configuração. Para publicar múltiplos serviços, cada bloco virtual deve apontar para a porta correta do container, como Home Assistant na porta interna do painel, Node-RED na porta do editor e n8n na porta da interface web. Mantenha nomes de domínio coerentes e evite reaproveitar o mesmo subdomínio para aplicações diferentes.

Depois de ajustar a configuração, recarregue sem reiniciar o servidor inteiro:

service nginx reload
service nginx status

Output esperado:
Nginx recarregado sem erro
serviço nginx em execução

Se você também estiver configurando redirecionamento de HTTP para HTTPS, consulte Como redirecionar um site http para https? para entender o conceito de redirecionamento antes de aplicar no proxy. Em automação residencial, HTTPS ajuda a reduzir exposição de credenciais quando painéis são acessados fora da rede local.

Otimize containers Docker com volumes, restart e logs previsíveis

Volumes persistentes no Docker são essenciais para automação residencial porque configurações, fluxos e credenciais não podem desaparecer quando um container é recriado. Home Assistant, Node-RED e n8n normalmente dependem de diretórios persistentes para guardar integrações, automações, chaves, banco local ou fluxos. A otimização real começa quando cada container deixa de ser temporário e passa a ter armazenamento bem definido. No FreeBSD, usuários avançados costumam combinar volumes Docker com ZFS, o sistema de arquivos nativo, para aproveitar snapshots e integridade de dados. Outro recurso exclusivo do FreeBSD são os FreeBSD Jails, que oferecem isolamento de processos no nível do sistema operacional e podem coexistir com containers, dependendo da arquitetura escolhida.

docker inspect homeassistant
docker inspect nodered
docker inspect n8n

Output esperado:
detalhes do container
mapeamentos de volumes
política de restart
rede usada pelo container

Ao revisar o resultado, procure por três pontos: volumes montados, política de reinicialização e portas. Se o container não possui volume persistente, qualquer recriação pode exigir reconfiguração. Se não possui reinicialização automática, um reboot do servidor pode deixar sua automação fora do ar. Se expõe porta pública sem necessidade, o Nginx perde a função de ponto único de entrada. Ao definir os serviços via docker-compose, você declara volumes, restart e rede em um único arquivo, facilitando auditoria e reprodução do ambiente.

docker logs --tail 80 homeassistant
docker logs --tail 80 nodered
docker logs --tail 80 n8n

Output esperado:
últimas linhas de log de cada serviço
erros de inicialização, rede, autenticação ou dependência quando existirem
nenhum loop contínuo de falha

Evite ignorar logs com reinicialização frequente. Um container que sobe e cai repetidamente pode parecer disponível por alguns segundos, mas falhar quando uma automação precisa executar. Para reduzir falhas silenciosas, padronize nomes dos containers, documente portas internas e mantenha logs acessíveis. Essa prática facilita o diagnóstico quando um webhook não dispara ou quando a interface do Node-RED fica intermitente.

Valide rede, DNS interno e resposta HTTP antes de abrir para usuários

Proxy reverso para múltiplos containers só funciona bem quando Nginx consegue alcançar cada aplicação na rota correta. A falha pode estar no DNS do domínio, na porta do container, na rede entre serviços ou na própria aplicação. Por isso, valide em camadas: primeiro container, depois Nginx local, depois domínio público.

docker ps
docker port homeassistant
docker port nodered
docker port n8n

Output esperado:
containers ativos
portas internas conhecidas
nenhuma disputa direta com 80 ou 443 para aplicações internas

Depois, teste a resposta HTTP local conforme a porta que cada serviço usa no seu ambiente. O importante é confirmar que o serviço responde antes de culpar o Nginx. Se a aplicação não responde localmente, o proxy apenas repassará a falha.

curl -I http://127.0.0.1:8123
curl -I http://127.0.0.1:1880
curl -I http://127.0.0.1:5678

Output esperado:
HTTP com resposta do serviço quando a porta estiver correta
ou erro de conexão quando o serviço não estiver escutando nessa porta

Em seguida, teste pelos nomes configurados no Nginx. Se o domínio não apontar para o IP correto, a requisição nem chegará ao servidor. Se chegar e retornar 502, o Nginx recebeu a conexão, mas não conseguiu falar com o backend. Se retornar 404, a rota pode estar indo para o bloco errado.

curl -I https://automacao.seudominio.com.br
curl -I https://nodered.seudominio.com.br
curl -I https://n8n.seudominio.com.br

Output esperado:
HTTP 200, 301, 302 ou resposta esperada pela aplicação
sem erro 502 quando o backend estiver acessível
sem erro de certificado quando TLS estiver correto

Monitore recursos para evitar lentidão na automação em Docker

Logs de containers Docker ajudam a explicar lentidão, mas não substituem a checagem de CPU, memória e disco. Automação residencial costuma ter tarefas recorrentes, integrações externas e eventos em tempo real. Quando muitos serviços rodam juntos, o gargalo pode aparecer como painel lento, webhook atrasado, automação que não executa ou container reiniciando sem motivo aparente.

top
df -h
docker stats --no-stream

Output esperado:
uso atual de CPU e memória
espaço livre em disco
consumo de recursos por container em um instantâneo

Ao executar estes comandos, observe se um único container domina CPU ou memória. Também veja se o disco está próximo do limite, pois logs e bancos locais podem crescer com o tempo. Se o armazenamento ficar cheio, containers podem falhar ao gravar configurações, Nginx pode não conseguir registrar logs e automações podem parar de salvar estado.

Para uma visão geral de boas práticas de desempenho em servidores, veja Dicas de Otimização de Servidores Linux. Embora o ambiente deste artigo seja FreeBSD 14.3, a lógica de observar consumo, reduzir serviços desnecessários e validar gargalos antes de alterar configurações continua útil.

Problemas comuns e como resolver

Sintoma: navegador mostra 502 Bad Gateway no painel de automação

Causa: o Nginx recebeu a requisição, mas não conseguiu alcançar o container na porta configurada. Isso ocorre quando o container está parado, a porta mudou ou o proxy aponta para o backend incorreto.

Solução: rode docker ps, confirme a porta com docker port nome-do-container e teste localmente com curl -I. Depois valide a sintaxe com nginx -t e recarregue o Nginx.

Sintoma: dois serviços tentam usar a mesma porta

Causa: containers publicados diretamente em 80 ou 443 disputam com o Nginx, ou dois painéis usam a mesma porta externa. Esse cenário é comum quando cada aplicação foi instalada isoladamente, sem desenho de proxy reverso.

Solução: deixe apenas o Nginx exposto nas portas públicas e mova os serviços para portas internas. Depois crie subdomínios separados para Home Assistant, Node-RED e n8n.

Sintoma: automações param após reiniciar o servidor

Causa: containers sem política de reinicialização automática ou dependentes de volumes não montados corretamente podem não voltar após reboot. Também pode haver falha de rede no início do serviço.

Solução: inspecione os containers com docker inspect, valide volumes persistentes e confirme se os serviços sobem depois de reiniciar. Em seguida, confira logs com docker logs --tail 80 nome-do-container.

Sintoma: painel abre, mas fica lento ou instável

Causa: CPU, memória, disco cheio, logs grandes ou excesso de serviços ativos podem degradar a resposta. Também é possível haver reinicialização frequente de um container sem alerta visual no navegador.

Solução: use top, df -h e docker stats --no-stream. Depois reduza serviços desnecessários, revise logs e separe aplicações críticas das experimentais.

Perguntas frequentes sobre Docker, Nginx e automação no FreeBSD

Como otimizar Docker e Nginx para automação residencial no FreeBSD 14.3?

A otimização começa separando o papel de cada componente: Docker executa os serviços de automação e Nginx atua como proxy reverso com TLS, cabeçalhos corretos e rotas bem definidas. Também é importante revisar portas expostas, volumes persistentes, reinicialização automática dos containers e logs para evitar falhas silenciosas.

Nginx é necessário para Home Assistant, Node-RED ou n8n em Docker?

O Nginx não é obrigatório para executar esses serviços, mas é recomendado quando você precisa publicar múltiplas aplicações no mesmo servidor com domínios ou subdomínios diferentes. Ele centraliza o acesso HTTP/HTTPS, reduz conflitos de porta e facilita o uso de certificados TLS.

FreeBSD 14.3 LTS é uma boa opção para servidor de automação com Docker?

FreeBSD 14.3 LTS pode ser usado como base de servidor quando o ambiente já foi planejado para compatibilidade com containers e rede. Antes de colocar em produção, valide suporte do runtime, persistência de volumes, comportamento de rede e reinicialização dos serviços após reboot.

Como evitar conflito de portas entre Docker e Nginx?

Evite publicar todos os containers diretamente nas portas 80 e 443. Mantenha as aplicações em portas internas ou redes isoladas e deixe apenas o Nginx exposto para receber o tráfego externo e encaminhar cada domínio para o container correto.

O que verificar quando a automação em Docker fica lenta ou instável?

Verifique primeiro CPU, memória, disco, logs do container e logs do Nginx. Em seguida, revise volumes, limites de recursos, número de serviços ativos, erros de DNS interno e reinicializações frequentes dos containers.

Conclusão

• Use o Nginx como ponto central de acesso e evite publicar vários containers diretamente nas portas 80 e 443.
• Revise volumes, restart, portas e logs antes de culpar o proxy reverso por falhas de automação.
• Teste em camadas: container local, Nginx, domínio público e consumo de recursos do servidor.

Leia também

• Solucionar erro de Traefik ao rotear containers Docker no Debian 12
• configurar rede Docker para isolar serviços no VPS
• Otimizar Docker Compose e Nginx no mesmo servidor AlmaLinux 9

Precisa de ajuda com Docker e Nginx para automação residencial?

A AviraHost oferece infraestrutura para quem precisa hospedar serviços, painéis e automações com mais controle sobre rede, acesso e recursos do servidor. Se você pretende organizar containers e proxy reverso com segurança, escolha um ambiente adequado ao tamanho da sua aplicação.

Conheça os planos de Servidor VPS da AviraHost