Por que não consigo acessar minha porta?

Você configurou um site, um app, um banco de dados, e do seu notebook não consegue acessar. O navegador fica carregando. curl expira por timeout. Você olha para o servidor e tudo lá dentro parece certo — o processo está rodando, os logs dizem "listening on port 8080" — mas, visto de fora, é como se o servidor nem existisse.

Essa é uma das coisas mais comuns em que as pessoas travam. E o motivo da frustração é que três problemas completamente diferentes parecem idênticos vistos de fora. Enquanto você não souber qual deles está acontecendo, não dá para corrigir.

Este artigo passa pelas três camadas, na ordem em que você deve verificá-las, e mostra como o Server Manager encontra + corrige cada uma.

As três camadas, em ordem

Entre o seu navegador e o programa rodando no seu servidor, há três lugares onde o tráfego pode ser bloqueado. Vistos de fora, os três parecem iguais — "não consigo acessar". Por dentro, são problemas bem diferentes, com correções bem diferentes.

As três camadas:

1. Firewall do provedor de nuvem — roda fora do seu servidor, no seu provedor (Hetzner, Oracle, AWS, etc.). Descarta pacotes antes que eles cheguem ao servidor.
2. Firewall do servidor — roda no seu servidor. Descarta pacotes quando eles chegam, antes que qualquer serviço os veja.
3. Seu serviço — o programa em si (Caddy, seu app, seu banco de dados). Ou não está rodando, ou está escutando apenas localmente.

Pense nisso como um prédio com três pontos de controle de segurança. O pacote precisa passar pelos três para chegar até você. Se qualquer um deles bloquear, seu serviço não pode ser acessado — e, de fora, não dá para saber qual ponto de controle barrou o pacote.

Camada 3 — Seu serviço está realmente escutando?

A causa mais barata e mais comum. Antes de se preocupar com firewalls, verifique se existe um programa no servidor escutando ativamente na porta que você espera.

As duas formas como isso dá errado:

• Nada escutando. O container travou. O serviço systemd não conseguiu iniciar. O app encerrou na inicialização. De fora, isso parece idêntico a um bloqueio de firewall — o pacote chega, mas não há ninguém para responder.
• Escutando apenas em localhost. Essa é traiçoeira. Muitos programas usam "apenas loopback" (127.0.0.1) por padrão, o que significa que o programa está rodando e aceitando conexões normalmente — mas apenas do próprio servidor. Conexões externas não conseguem chegar até ele, mesmo que todos os firewalls estejam totalmente abertos. Culpados comuns: PostgreSQL recém-instalado, MySQL/MariaDB, Redis, notebooks Jupyter, servidores de desenvolvimento, qualquer coisa que diga "por segurança, vinculamos apenas a localhost por padrão."

Como o Server Manager ajuda:

• A aba Detalhes do servidor → Firewall consegue responder "o firewall do meu servidor está bloqueando?", mas a Camada 3 é algo em que o chat é melhor — pergunte ao Faro: "Tem alguma coisa realmente escutando na porta 8080?" e ele vai executar ss -tlnp e te dizer.
• Se você clicar em Diagnosticar inacessibilidade na aba Firewall, o diagnóstico verifica as três camadas — incluindo esta — e informa qual é a causa.

Camada 2 — O firewall do servidor (no servidor)

A próxima camada a verificar é o firewall rodando no próprio servidor. No Ubuntu/Debian, geralmente é ufw; no Fedora/Rocky, é firewalld; por trás de ambos está o iptables puro. Seja qual for a interface, a função é a mesma: descartar pacotes de entrada que não tenham sido explicitamente permitidos.

Três coisas para saber sobre esta camada:

• A maioria dos servidores novos vem com "permitir por padrão" — todas as portas são acessíveis pelo firewall do servidor, porque o firewall ou não está instalado ou não está aplicando nenhuma regra. O Server Manager mostra isso claramente: a aba Firewall exibe um aviso amarelo de "Permitir por padrão" quando esse é o caso.
• Um servidor "reforçado" usa "negar por padrão" — o tráfego de entrada é bloqueado por padrão; apenas portas explicitamente permitidas passam. SSH (porta 22) sempre fica aberta, além do que você confirmou durante a configuração.
• A maioria dos provedores de hospedagem não ativa um firewall de servidor para você. Você recebe um servidor com permitir por padrão (todas as portas abertas nesta camada) ou configura um por conta própria.

Como o Server Manager ajuda:

• Detalhes do servidor → aba Firewall mostra o estado atual de relance: backend (ufw / iptables / firewalld / none), ativo ou permitir por padrão, e a lista de portas explicitamente permitidas com rótulos em linguagem simples.
• Abrir uma porta permite liberar uma única porta no firewall do servidor com um clique (o campo Porta + seletor de protocolo no topo da aba). O chat te guia pelo jeito seguro + persistente de fazer isso.
• Reforçar o firewall deste servidor muda com segurança um servidor de permitir por padrão para negar por padrão. Um modal lista todos os serviços que estão escutando no momento e permite escolher quais devem continuar públicos. SSH sempre é mantido (a proteção se recusa a te deixar sem acesso). Docker é detectado automaticamente, e um modo compatível com Docker é usado para que os containers continuem funcionando.
• Diagnosticar inacessibilidade verifica esta camada (e as outras) e informa qual delas está bloqueando sua porta.

Importante: ativar um firewall de servidor + Docker é complicado. Um simples ufw enable em um host Docker pode quebrar a rede dos containers — o Docker gerencia suas próprias regras de firewall por meio de uma cadeia separada (DOCKER-USER), e o ufw não sabe lidar com isso. Se você deixar o Server Manager cuidar do reforço, ele detecta o Docker e usa automaticamente um caminho seguro para Docker. Fazer isso manualmente sem essa integração é uma forma comum de perder conectividade com seus containers.

Camada 1 — O firewall do provedor de nuvem (fora do servidor)

A camada mais complicada. Seu provedor de hospedagem roda um firewall na frente do seu servidor — os pacotes são filtrados antes mesmo de chegarem à sua VM. O Server Manager não consegue enxergar esse firewall diretamente porque ele não está no seu servidor; só o console web do seu provedor pode alterá-lo.

Os nomes e comportamentos variam muito:

O ponto essencial: o firewall do servidor e o firewall da nuvem são dois firewalls separados. Ambos podem bloquear. Ambos podem liberar. Você pode abrir uma porta no lado do servidor e ainda assim ser bloqueado no lado da nuvem (muito comum). Você pode não ter nada no lado do servidor, mas ser bloqueado no lado da nuvem (também comum).

Como o Server Manager ajuda:

• O Server Manager não consegue alterar regras de firewall da nuvem diretamente (ele precisaria de chaves de API de todos os provedores), mas o Faro conhece o passo a passo, clique por clique, dos principais provedores e te orienta. Depois de abrir uma porta no lado do servidor, o Faro pergunta "quer que eu te guie também para abrir no lado da nuvem?" e fornece instruções exatas para o console web do seu provedor.
• Quando você executa Diagnosticar inacessibilidade na aba Firewall, o diagnóstico identifica se o firewall da nuvem é o bloqueador e mostra automaticamente o passo a passo específico do provedor.
• Quando você Reforça o firewall deste servidor, o Faro lembra você de também restringir o firewall do lado da nuvem para combinar (caso contrário, você fica com uma configuração assimétrica — rígida no servidor, frouxa na nuvem).

Como o Server Manager verifica as três camadas para você

O caminho pelo chat: abra o Faro e diga "por que não consigo acessar a porta 8080?" O agente testa as três camadas em ordem — serviço escutando, firewall do servidor, firewall da nuvem — e informa qual delas é a causa. Em seguida, oferece corrigir.

O caminho pela interface: Detalhes do servidor → aba Firewall → Diagnosticar inacessibilidade. Digite a porta e clique no botão. O mesmo teste em três camadas, o mesmo diagnóstico, a mesma oferta de correção.

O resultado sempre nomeia uma camada específica como causa, além de uma única correção proposta em forma de pergunta sim/não. Nada de checklists genéricos de várias páginas.

Cenários comuns

"Implantei um banco de dados e não consigo conectar do meu notebook"

Quase certamente é a Camada 3 — o banco de dados está **escutando apenas em 127.0.0.1**. PostgreSQL, MySQL, MariaDB e Redis usam localhost por padrão. Eles estão rodando corretamente; você só não consegue acessá-los de fora.

A correção depende do que você quer:

• Para app→banco de dados no mesmo servidor (o caso normal) — é assim mesmo que deve ser. Conecte seu app a localhost:5432 (ou seja qual for a porta) e pronto. Não precisa alterar firewall. No Server Manager: nada a fazer — o Faro implanta bancos de dados assim por padrão.
• Para administração remota "meu notebook → banco de dados" — abra um túnel: ssh -L 5432:localhost:5432 user@server a partir do seu notebook e conecte seu cliente de banco a localhost:5432 localmente. É mais seguro do que expor o banco de dados à internet. No Server Manager: peça ao Faro o comando exato do túnel — ele conhece o usuário e o host do seu servidor.
• Para "eu realmente quero que este banco de dados seja acessível publicamente" — altere o endereço de bind na configuração do banco para 0.0.0.0, reinicie o banco e então abra a porta tanto no firewall do servidor QUANTO no firewall da nuvem. Antes disso, tenha certeza absoluta de que você definiu uma senha forte; expor um banco de dados à internet pública sem autenticação forte é uma forma comum de ser comprometido. No Server Manager: peça ao Faro para fazer as três etapas (alterar o bind do banco, abrir a porta no firewall do servidor pela aba Firewall, orientar a regra do provedor de nuvem). Peça ao Faro para gerar uma senha forte antes, se você ainda não tiver definido uma.

"Abri a porta no ufw e ainda não consigo acessá-la"

Camada 1 — o firewall do provedor de nuvem ainda não foi informado. ufw allow 8080/tcp no lado do servidor abre a Camada 2; o pacote ainda precisa passar pela Camada 1 antes de chegar ao seu servidor. Abra a regra correspondente no console do seu provedor de nuvem.

No Server Manager: peça ao Faro para te orientar na regra do lado da nuvem para o seu provedor — ele vai te dar o passo a passo clique por clique para Hetzner / AWS / Oracle / etc. sem você precisar procurar o layout do painel.

"Funcionava ontem, hoje não funciona"

Algumas causas comuns:

• Seu IP mudou — se o firewall da nuvem está restrito a "apenas meu IP" e sua internet de casa recebeu um novo IP durante a noite (muito comum na maioria dos provedores residenciais), o novo IP agora está bloqueado. Amplie temporariamente para 0.0.0.0/0, acesse, depois restrinja novamente.
• O serviço travou — problema de Camada 3 disfarçado. Verifique systemctl status <service> ou docker ps.
• O servidor foi reforçado recentemente — se alguém ativou o firewall do servidor sem incluir a porta que você precisa, essa porta agora está bloqueada na Camada 2. Abra a aba Firewall para ver o conjunto de regras atual.

No Server Manager: digite a porta afetada na aba Firewall e clique em Diagnosticar inacessibilidade — o Faro testa as três camadas e informa qual delas regrediu. Mais rápido do que chutar.

"Consigo usar curl a partir do servidor, mas não de fora"

Essa é a linha divisória do diagnóstico: ela mostra que o serviço está bem e que a Camada 3 não é o problema. Agora é a Camada 2 (firewall do servidor) ou a Camada 1 (firewall da nuvem). Use Diagnosticar inacessibilidade para afunilar mais.

No Server Manager: o botão Diagnosticar inacessibilidade na aba Firewall é a ferramenta certa exatamente para este caso — ele pula a Camada 3 (já que você provou que ela funciona) e informa qual das duas camadas de firewall está descartando o pacote.

Perguntas comuns

Preciso de um firewall de servidor se meu provedor de nuvem já tem um?

Sim e não, dependendo do seu modelo de ameaças. Um firewall da nuvem cobre o caso comum. Um firewall de servidor é útil quando:

• Você roda Docker — containers podem abrir seus próprios caminhos que contornam o firewall da nuvem em algumas configurações. Um firewall de servidor captura a saída dos containers.
• Você esquece de remover regras temporárias do firewall da nuvem — o firewall do servidor é a rede de segurança.
• Você quer filtrar tráfego de saída — firewalls da nuvem geralmente focam na entrada; firewalls de servidor podem fazer os dois.

Se nada disso se aplica, um único firewall da nuvem bem configurado é suficiente para a maioria das configurações.

O Server Manager funciona sem um firewall de servidor?

Sim. O Server Manager não exige nenhuma configuração de firewall para funcionar. A aba Firewall existe para a sua segurança, não para conectar ao próprio Server Manager (o Server Manager só precisa de SSH, porta 22).

Por que a aba Firewall está dizendo "Permitir por padrão" se eu nunca configurei nada?

Porque esse é o estado real. A maioria dos servidores novos não tem firewall de servidor configurado — todas as portas são acessíveis nessa camada. Se algo realmente chega ao seu serviço depende da Camada 1 (firewall da nuvem) e da Camada 3 (se o serviço está escutando). O aviso amarelo é um alerta de que talvez você queira reforçar isso.

"Abrir porta 22 / SSH" é algo que eu devo fechar em algum momento?

Não. O Server Manager fala com seu servidor apenas por SSH. Fechar a porta 22 desconecta o Server Manager, e você precisaria recuperar pelo console do provedor (veja Recuperar quando o SSH para de funcionar). Por esse motivo, a aba Firewall se recusa a oferecer um botão Fechar na linha do SSH, e o modal de reforço trava a linha do SSH como "manter sempre aberta."

O que NÃO está no escopo aqui

• Problemas de tráfego de saída (seu servidor não consegue acessar a internet) — isso é outra configuração: geralmente NAT, DNS ou a rede de saída do provedor. Peça ao Faro para diagnosticar.
• Erros de HTTPS / TLS — nesses casos, a acessibilidade funcionou, mas o handshake de criptografia falhou. É outro tipo de problema; confira a seção domínios-https-email.
• Problemas de DNS ("meu domínio não resolve para o servidor") — coberto em Apontar um domínio para cá. O pacote ainda nem chegou à questão dos firewalls — ele nem sabe onde o servidor está.
• Configuração específica do app (qual variável de ambiente definir para que seu app escute em 0.0.0.0 em vez de 127.0.0.1) — varia conforme o app. Pergunte ao Faro: ele conhece os casos comuns.