Serviço VPS iniciado mas inacessível pela internet (2026): como diagnosticar portas, firewall, security groups e endereços de escuta

O primeiro passo não é abrir o firewall nem mexer no Nginx, mas confirmar em qual camada está o problema.

Execute dentro do VPS:

systemctl status your-service
curl -I http://127.0.0.1:3000
curl -I http://服务器内网IP:3000
curl -I http://服务器公网IP:3000

Se nem 127.0.0.1 é acessível, o serviço em si não está funcionando bem; veja primeiro os logs da aplicação.

Se 127.0.0.1 funciona mas o IP público não, basicamente é problema de endereço de escuta, firewall, security group ou camada de rede.

Esse julgamento é muito importante. Muitas pessoas têm um bug no próprio serviço mas ficam mexendo no firewall; outras têm o serviço funcionando mas reiniciam a aplicação repetidamente; a direção está completamente errada.

Esse é o erro mais comum.

Muitos frameworks de desenvolvimento escutam por padrão apenas em localhost ou 127.0.0.1, então é acessível localmente mas definitivamente não pela internet.

Verifique o endereço de escuta:

ss -lntp

Você verá algo como:

LISTEN 0 511 127.0.0.1:3000 0.0.0.0:* users:(("node",pid=1234))

Se for 127.0.0.1:3000, só o acesso local é permitido. Para a internet se conectar diretamente, altere para escutar em:

0.0.0.0:3000

Cada programa escreve de forma diferente:

# Vite / Node 常见写法
npm run dev -- --host 0.0.0.0

# Python 简单服务
python3 -m http.server 8000 --bind 0.0.0.0

# Uvicorn
uvicorn app:app --host 0.0.0.0 --port 8000

Dito isso, em produção não necessariamente é recomendável expor diretamente a porta da aplicação. O mais comum é a aplicação escutar em 127.0.0.1 e depois o Nginx/Caddy fazer proxy reverso para a 80/443 pública.

Depois que a escuta do serviço está ok, verifique o firewall do sistema.

No Ubuntu o comum é UFW:

ufw status verbose
ufw allow 3000/tcp

No CentOS / Rocky / AlmaLinux o comum é firewalld:

firewall-cmd --list-ports
firewall-cmd --add-port=3000/tcp --permanent
firewall-cmd --reload

Se você usa iptables/nftables diretamente, verifique:

iptables -L -n -v
nft list ruleset

Um lembrete: não desligue o firewall para facilitar. Parar brevemente para um diagnóstico temporário é aceitável, mas deixar exposto a longo prazo é perigoso. O correto é liberar apenas as portas necessárias, como 80, 443, 22 ou alguma porta de negócio específica.

Muitos servidores em nuvem têm duas camadas de firewall: uma dentro do sistema e outra no security group do console.

Você fez ufw allow 3000 dentro do VPS, mas se o console do provedor de nuvem não liberou a 3000, a internet também não consegue acessar.

As plataformas comuns são parecidas:

• AWS / Lightsail: Security Group / Firewall
• Google Cloud: VPC Firewall
• Azure: NSG
• Oracle Cloud: Security List + Network Security Group
• Vultr / DigitalOcean / Linode: Cloud Firewall
• Alguns provedores de VPS: firewall integrado ao painel de controle

No security group, confirme:

• Se a regra de entrada permite TCP 3000
• Se o IP de origem está restrito a um endereço específico
• Se a regra está vinculada a esta máquina
• Se IPv4 e IPv6 estão liberados separadamente
• Se o firewall da nuvem nega todo o tráfego de entrada por padrão

Quando faço diagnóstico, costumo primeiro usar uma porta de teste temporária, como 8080, para confirmar que tanto o sistema quanto o security group da nuvem liberam, e depois reduzo para a porta oficial.

Às vezes o serviço falha ao iniciar porque a porta já está em uso.

Verifique o uso da porta:

ss -lntp | grep ':3000'
lsof -i :3000

Se descobrir que a porta está com um processo antigo, primeiro confirme o que é; não faça kill -9 diretamente. Pode ser a mesma aplicação que você iniciou antes ou outro serviço.

Tratamento comum:

# 看进程详情
ps -fp 进程ID

# 正常停止 systemd 服务
systemctl stop your-service

# 确认后再杀进程
kill 进程ID

Quando há conflito de portas, os logs da aplicação também costumam mostrar avisos como EADDRINUSE, address already in use.

Se você não acessa diretamente a porta da aplicação, mas por meio de um domínio, também precisa verificar o proxy reverso.

Configuração comum do Nginx:

server {
    listen 80;
    server_name example.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-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Verifique a configuração e recarregue:

nginx -t
systemctl reload nginx
journalctl -u nginx -n 100 --no-pager

Erros comuns:

• proxy_pass porta escrita errada
• A aplicação escuta em 127.0.0.1:3000, mas o Nginx encaminha para 127.0.0.1:3001
• O DNS do domínio não resolve para este VPS
• A configuração do Nginx foi alterada mas não recarregada
• O certificado HTTPS não está configurado corretamente, então o navegador parece que o site não abre

Usuários de Caddy são parecidos; foque em verificar se o endereço reverse_proxy no Caddyfile está correto.

IPv6 está cada vez mais comum hoje e traz alguns problemas estranhos.

Por exemplo, o serviço escuta em:

[::1]:3000

Ou só o IPv6 está habilitado e o IPv4 não escuta corretamente. Quando você acessa por IPv4 no navegador, falha.

Verifique a escuta:

ss -lntp
curl -4 http://服务器IP:3000
curl -6 http://[IPv6地址]:3000

Se por enquanto você não pretende suportar IPv6, pode primeiro vincular o serviço explicitamente a 0.0.0.0, e diagnosticar o security group e o firewall para IPv4 primeiro. Quando o IPv4 funcionar, trate o IPv6 separadamente.

Não altere IPv4, IPv6, DNS e proxy reverso ao mesmo tempo. Altere apenas uma camada por vez para saber qual passo resolveu.

Alguns provedores de VPS bloqueiam certas portas, como 25, 80, 443, portas relacionadas a SMTP, ou exigem um ticket para liberá-las.

Se você confirmou:

• O programa escuta corretamente
• O firewall do sistema libera
• O security group libera
• A configuração do Nginx está correta
• Não há conflito de portas

Mas a internet ainda não acessa, teste com outra porta:

python3 -m http.server 8080 --bind 0.0.0.0

Depois acesse do seu computador local:

curl -I http://服务器IP:8080

Se a 8080 funciona e a 80/443 não, pode ser o provedor, o firewall do console ou a configuração do serviço web local. Nesse momento, abrir um ticket com os resultados do teste é muito mais eficaz do que apenas dizer "o site não abre".

Minha própria ordem é esta:

1. curl 127.0.0.1:端口 local
2. ss -lntp para ver o endereço de escuta
3. Dentro do VPS, curl 公网IP:端口
4. O firewall do sistema libera a porta
5. O security group do provedor de nuvem libera a porta
6. Computador local curl 公网IP:端口
7. Verificar o proxy reverso Nginx/Caddy
8. Verificar DNS, IPv6, HTTPS
9. Trocar para uma porta de teste para confirmar se o provedor restringe
10. Contatar o suporte com evidências

A vantagem dessa ordem é que ela vai de dentro para fora, eliminando camada por camada, e você não faz alterações aleatórias.

O que mais se teme durante o diagnóstico são alterações aleatórias:

• Reinstalar o sistema de cara
• Desligar todos os firewalls e deixar assim a longo prazo
• Alterar Nginx, DNS, security groups e configuração da aplicação ao mesmo tempo
• Não ler os logs, apenas reiniciar por intuição
• Pedir reembolso antes de confirmar a porta
• Expor 0.0.0.0 para todos os serviços, especialmente bancos de dados, Redis e painéis de administração

Especialmente para serviços como bancos de dados, Redis e Elasticsearch, não os abra para a internet pública só para "ficarem acessíveis de fora". Quando precisar de acesso remoto, prefira túneis SSH, VPN, redes internas ou listas de permissão.

Quando um VPS está inacessível pela internet, não se apresse em duvidar da qualidade da máquina. A maioria dos problemas é "o serviço só está escutando localmente" ou "alguma camada de firewall não está liberando". Verifique em ordem, não altere dez coisas ao mesmo tempo, e o problema na verdade fica mais fácil de resolver.