--- title: "Como verificar se uma porta está aberta no servidor" description: "Teste portas de fora com nc, nmap e Test-NetConnection, veja o que escuta no servidor com ss e entenda porta fechada, filtrada e serviço só em 127.0.0.1." url: "https://streethosting.com.br/guias/infraestrutura/verificar-porta-aberta-servidor" category: "infraestrutura" slug: "verificar-porta-aberta-servidor" datePublished: "2026-11-13" dateModified: "2026-11-13" author: "Equipe StreetHosting" difficulty: "iniciante" language: "pt-BR" keywords: - "verificar porta aberta servidor" - "testar porta com nc" - "nmap porta aberta" - "Test-NetConnection porta" - "ss tulpn" - "porta filtrada" --- # Porta aberta, fechada ou filtrada: como testar de fora e diagnosticar por dentro Quando o serviço roda mas ninguém consegue conectar, o problema quase sempre é uma destas três coisas: o programa não escuta onde deveria, o firewall barra o pacote ou a rede no meio do caminho derruba a conexão. Veja como separar cada caso. > **Resposta rápida** > > Para saber se uma porta está aberta, teste de fora, de outra máquina: `nc -zv IP 443` no Linux e no macOS ou `Test-NetConnection IP -Port 443` no Windows. Se a conexão for aceita, está aberta. Se for recusada na hora, está fechada e nada escuta ali. Se o teste ficar parado até dar tempo esgotado, está filtrada por um firewall. Para ver o que escuta no servidor, rode `sudo ss -tulpn`. ## Três lugares onde a porta pode falhar Uma conexão que não chega ao serviço pode ter parado em três pontos diferentes, e cada ferramenta deste guia olha para um deles. 1. **O programa não escuta:** o serviço caiu, nunca subiu ou escuta em outra porta. Quem responde é o sistema operacional, recusando a conexão. 2. **O programa escuta no endereço errado:** ele está de pé, mas só aceita conexões locais, em 127.0.0.1. De fora, o efeito é o mesmo de uma porta fechada. 3. **Um firewall descarta o pacote:** pode ser o firewall do próprio sistema, como o UFW, o de um painel do provedor ou o do roteador em casa. Nesse caso nada volta, e a conexão fica pendurada. O melhor caminho é testar de fora primeiro, porque é o que o seu usuário vive, e depois olhar por dentro para descobrir em qual das três camadas está o defeito. Testar o próprio servidor por dentro, com `curl localhost`, não prova nada sobre o acesso externo: o tráfego local usa a interface de loopback, que o firewall costuma liberar, e nem passa pela rede. ## Testar de fora Rode estes testes de uma máquina que não seja o servidor, como o seu computador, outra VPS ou o celular em dados móveis. Testar da própria rede do servidor pode dar um resultado diferente do que o mundo vê. **Linux e macOS, com nc (netcat):** ``` # testa a porta 443 por TCP, com 5 segundos de limite nc -zv -w 5 IP_DO_SERVIDOR 443 ``` A opção `-z` só tenta conectar e já fecha, sem mandar dados, `-v` mostra o resultado e `-w 5` limita a espera. A mensagem exata muda de uma versão do nc para outra, mas o sentido é sempre este: succeeded ou open quando conectou, e refused quando o servidor recusou. **Qualquer sistema, com nmap:** ``` # três portas de uma vez nmap -p 22,80,443 IP_DO_SERVIDOR # sem tentar ping antes, para servidores que escondem o ICMP nmap -Pn -p 443 IP_DO_SERVIDOR ``` O nmap mostra uma tabela com a coluna de estado, e é a ferramenta certa para testar várias portas de uma vez. A opção `-Pn` pula a checagem de host ativo, útil quando o servidor ignora ping. **Windows, com PowerShell:** ``` Test-NetConnection -ComputerName IP_DO_SERVIDOR -Port 443 ``` Na saída, o campo `TcpTestSucceeded : True` confirma que a conexão foi aceita. Com `False`, o Windows mostra um aviso de que a conexão TCP falhou, sem dizer se foi recusa ou silêncio. Para separar os dois casos, repare no tempo que o comando levou: a recusa volta bem mais rápido, e o silêncio só termina quando o tempo de espera acaba. > **Atenção** > > Varra apenas servidores seus ou que você tem autorização para testar. Rodar o nmap em faixas inteiras de IPs de terceiros pode violar as regras do provedor e gerar bloqueio na sua conta. Para checar uma porta do seu servidor, o nc ou o Test-NetConnection bastam. ## Fechada, filtrada ou aberta A diferença entre fechada e filtrada é a pista mais útil do diagnóstico. | Estado | O que você vê | O que significa | Onde procurar | | --- | --- | --- | --- | | Aberta | Conexão aceita, nmap diz open | Um programa escuta e o caminho está livre | Se o serviço ainda falha, o problema é a aplicação | | Fechada | Recusa imediata, connection refused, nmap diz closed | O servidor foi alcançado e ninguém escuta nessa porta | Serviço parado, porta errada ou escuta só em 127.0.0.1 | | Filtrada | Demora e termina por tempo esgotado, nmap diz filtered | Um firewall descartou o pacote sem responder | UFW, iptables, firewall do painel ou do roteador | Uma porta fechada é uma boa notícia para o diagnóstico: o pacote chegou ao servidor e voltou uma recusa, então a rede e o firewall estão liberando e o defeito está no programa. Uma porta filtrada é o oposto: o pacote nunca teve resposta, e o serviço pode estar perfeito por dentro. Se você quer entender a rota até o servidor quando o silêncio vem do caminho, o guia de [traceroute para descobrir problemas de rota](https://streethosting.com.br/guias/infraestrutura/traceroute-diagnosticar-rota) ajuda a ver onde os pacotes param. ## Ver o que escuta no servidor Entre no servidor por SSH e liste os sockets que estão escutando: ``` sudo ss -tulpn ``` As letras significam: `t` para TCP, `u` para UDP, `l` para só os que escutam, `p` para mostrar o processo dono do socket e `n` para números em vez de nomes. O sudo é necessário para o nome do processo aparecer. Uma linha típica: ``` Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process tcp LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=812,fd=6)) tcp LISTEN 0 128 127.0.0.1:3000 0.0.0.0:* users:(("node",pid=1544,fd=19)) tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=701,fd=4)) ``` Procure a porta que você quer. Se ela não aparece na lista, nenhum programa escuta ali, e o serviço está parado ou configurado em outra porta. Se aparece, olhe a coluna Local Address, que é o assunto da próxima seção. Para filtrar uma porta específica, use `sudo ss -tulpn | grep :3000`. No Windows Server, o equivalente em PowerShell é `Get-NetTCPConnection -State Listen`. ## Serviço só em 127.0.0.1 A coluna Local Address mostra em quais endereços o programa aceita conexões, e é a causa de muita porta que parece fechada: - **127.0.0.1:3000:** só aceita conexões da própria máquina. Quem vem de fora recebe recusa, como se a porta estivesse fechada. - **0.0.0.0:80:** aceita conexões por qualquer endereço IPv4 da máquina, inclusive o público. - **[::]:22:** o equivalente para IPv6. Em muitos sistemas, escutar em `[::]` também atende IPv4. - **IP_PUBLICO:porta:** escuta só naquele endereço, e ignora os outros. Esse comportamento muitas vezes é proposital. Um banco de dados, um painel interno ou uma aplicação atrás do Nginx devem escutar só em 127.0.0.1, e o proxy é quem fala com o mundo. O defeito aparece quando você queria a porta pública e o programa subiu no padrão local, como fazem muitos servidores de desenvolvimento. A correção é na configuração do programa: troque o endereço de escuta para `0.0.0.0` e reinicie o serviço. Em Node, por exemplo, é o segundo argumento do `listen`. > **Dica** > > Antes de abrir qualquer coisa para a internet, pergunte se aquela porta precisa mesmo ser pública. Banco de dados, Redis e painéis de administração em 0.0.0.0 sem firewall são alvo de varredura constante. O caminho seguro é manter o serviço em 127.0.0.1 e expor só o Nginx, como mostra o guia de [Nginx como proxy reverso na VPS](https://streethosting.com.br/guias/vps/configurar-nginx-reverse-proxy-vps). ## Conferir o firewall Quando o programa escuta no endereço certo e a porta de fora continua filtrada, olhe as regras do firewall da própria máquina: ``` # Ubuntu com UFW sudo ufw status verbose # regras do iptables em formato de comando sudo iptables -S # regras do nftables sudo nft list ruleset ``` No UFW, procure uma regra ALLOW para a porta. Se ela não existe e a política de entrada é deny, o pacote é descartado e a porta aparece como filtrada. Para liberar, use `sudo ufw allow 443/tcp`. O passo a passo completo, incluindo como liberar SSH antes de ligar o firewall para não perder o acesso, está no guia de [firewall UFW na VPS Ubuntu](https://streethosting.com.br/guias/vps/firewall-ufw-vps-ubuntu). Lembre que o firewall do sistema não é o único. Se a regra local está certa e a porta continua filtrada, confira também o firewall do painel do provedor, se houver, e o do roteador, quando o servidor fica atrás de um. No caso de servidores em casa, a conversa muda para [NAT e redirecionamento de portas](https://streethosting.com.br/guias/infraestrutura/o-que-e-nat-port-forwarding). ## O caso do UDP O TCP tem conexão: o teste manda um pedido e recebe aceite ou recusa. O UDP não tem nada disso. Um pacote vai e, se o serviço não responder a dados vazios, não volta nada, e o teste não distingue um serviço aberto de um firewall que descarta. O nmap chama esse caso de `open|filtered`. ``` # nc em modo UDP: o resultado não é confiável sozinho nc -zvu -w 3 IP_DO_SERVIDOR 51820 # nmap em UDP, precisa de root e é lento sudo nmap -sU -p 51820 IP_DO_SERVIDOR ``` Duas regras práticas ajudam. A primeira: por dentro, o `ss -ulpn` continua sendo prova confiável de que o programa escuta. A segunda: para provar o caminho completo, use o cliente real do protocolo, como uma consulta `dig @IP_DO_SERVIDOR exemplo.com` para DNS, ou o próprio cliente do jogo ou da VPN. Se o servidor responde, o UDP está passando. A diferença entre os dois protocolos explica por que isso acontece, e está em [TCP ou UDP em servidores](https://streethosting.com.br/guias/infraestrutura/tcp-vs-udp-servidores). ## Acesso total ao servidor Esse diagnóstico exige mexer no que escuta e no que filtra, e por isso precisa de acesso root. Nas [VPS da StreetHosting](https://streethosting.com.br/vps) você tem esse acesso, com virtualização KVM e firewall do sistema nas suas mãos: instala o nmap em outra máquina, usa o ss na VPS e configura UFW ou nftables como preferir. Todas ficam em São Paulo, com IPv4 dedicado, AntiDDoS incluso e ativação em cerca de 60 segundos após o Pix ou o cartão serem aprovados. A VPS Xeon começa em R$ 26,00 por mês, com 2 vCPU, 2 GB de RAM e 20 GB NVMe. ## Perguntas frequentes ### Como saber se uma porta está aberta em um servidor? Teste de fora com nc -zv IP PORTA no Linux ou Test-NetConnection -ComputerName IP -Port PORTA no Windows. Se a conexão for aceita, a porta está aberta. Para confirmar que existe um programa escutando, rode ss -tulpn no próprio servidor. ### Qual a diferença entre porta fechada e porta filtrada? Na porta fechada o servidor responde na hora recusando a conexão, o que indica que a máquina está acessível e nenhum programa escuta ali. Na porta filtrada não vem resposta nenhuma e o teste termina por tempo esgotado, porque um firewall descartou o pacote. ### Meu serviço escuta em 127.0.0.1. Por que não conecta de fora? O endereço 127.0.0.1 só aceita conexões da própria máquina. Para receber conexões da rede, o programa precisa escutar em 0.0.0.0, que vale para todos os endereços IPv4, ou no IP público do servidor. A mudança se faz na configuração do serviço, e depois ele precisa reiniciar. ### Posso usar o nmap em qualquer servidor? Use só nos servidores que são seus ou em que você tem autorização. Varrer portas de terceiros pode violar as regras do provedor e, dependendo do caso, a lei. Para testar uma porta específica do seu servidor, nc ou Test-NetConnection já resolvem sem varrer nada. ### Por que testar porta UDP é mais difícil? O UDP não tem conexão nem confirmação. Um serviço aberto pode simplesmente não responder a um pacote vazio, e o teste não consegue distinguir porta aberta de porta filtrada. O jeito confiável é usar o cliente real do protocolo, como uma consulta dig para DNS. ## Guias relacionados - [UFW na VPS Ubuntu: regras de firewall sem perder o SSH](https://streethosting.com.br/guias/vps/firewall-ufw-vps-ubuntu.md) - [TCP vs UDP: qual protocolo usar em cada servidor](https://streethosting.com.br/guias/infraestrutura/tcp-vs-udp-servidores.md) - [SSH seguro em VPS Linux: chaves, senhas, fail2ban e hábitos que evitam invasão](https://streethosting.com.br/guias/vps/ssh-seguro-vps-linux.md) - [O que é NAT e port forwarding: hospedar em casa e por que falha](https://streethosting.com.br/guias/infraestrutura/o-que-e-nat-port-forwarding.md) - [Como usar traceroute para achar problemas de rota](https://streethosting.com.br/guias/infraestrutura/traceroute-diagnosticar-rota.md) ## Produtos citados - https://streethosting.com.br/vps ## Dados estruturados ```json [ { "@context": "https://schema.org", "@type": [ "Article", "TechArticle" ], "headline": "Porta aberta, fechada ou filtrada: como testar de fora e diagnosticar por dentro", "name": "Como verificar se uma porta está aberta no servidor", "abstract": "Quando o serviço roda mas ninguém consegue conectar, o problema quase sempre é uma destas três coisas: o programa não escuta onde deveria, o firewall barra o pacote ou a rede no meio do caminho derruba a conexão. Veja como separar cada caso.", "description": "Teste portas de fora com nc, nmap e Test-NetConnection, veja o que escuta no servidor com ss e entenda porta fechada, filtrada e serviço só em 127.0.0.1.", "datePublished": "2026-11-13", "dateModified": "2026-11-13", "author": { "@type": "Organization", "name": "Equipe StreetHosting" }, "publisher": { "@type": "Organization", "name": "StreetHosting", "url": "https://streethosting.com.br" }, "inLanguage": "pt-BR", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://streethosting.com.br/guias/infraestrutura/verificar-porta-aberta-servidor" } }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Como saber se uma porta está aberta em um servidor?", "acceptedAnswer": { "@type": "Answer", "text": "Teste de fora com nc -zv IP PORTA no Linux ou Test-NetConnection -ComputerName IP -Port PORTA no Windows. Se a conexão for aceita, a porta está aberta. Para confirmar que existe um programa escutando, rode ss -tulpn no próprio servidor." } }, { "@type": "Question", "name": "Qual a diferença entre porta fechada e porta filtrada?", "acceptedAnswer": { "@type": "Answer", "text": "Na porta fechada o servidor responde na hora recusando a conexão, o que indica que a máquina está acessível e nenhum programa escuta ali. Na porta filtrada não vem resposta nenhuma e o teste termina por tempo esgotado, porque um firewall descartou o pacote." } }, { "@type": "Question", "name": "Meu serviço escuta em 127.0.0.1. Por que não conecta de fora?", "acceptedAnswer": { "@type": "Answer", "text": "O endereço 127.0.0.1 só aceita conexões da própria máquina. Para receber conexões da rede, o programa precisa escutar em 0.0.0.0, que vale para todos os endereços IPv4, ou no IP público do servidor. A mudança se faz na configuração do serviço, e depois ele precisa reiniciar." } }, { "@type": "Question", "name": "Posso usar o nmap em qualquer servidor?", "acceptedAnswer": { "@type": "Answer", "text": "Use só nos servidores que são seus ou em que você tem autorização. Varrer portas de terceiros pode violar as regras do provedor e, dependendo do caso, a lei. Para testar uma porta específica do seu servidor, nc ou Test-NetConnection já resolvem sem varrer nada." } }, { "@type": "Question", "name": "Por que testar porta UDP é mais difícil?", "acceptedAnswer": { "@type": "Answer", "text": "O UDP não tem conexão nem confirmação. Um serviço aberto pode simplesmente não responder a um pacote vazio, e o teste não consegue distinguir porta aberta de porta filtrada. O jeito confiável é usar o cliente real do protocolo, como uma consulta dig para DNS." } } ] } ] ```