Como verificar se uma porta está aberta no Linux

Verifique se uma porta está aberta no Linux: escolha primeiro a pergunta certa

Para verificar se uma porta está aberta no Linux, defina primeiro qual pergunta está a fazer, porque “aberta” tem significados diferentes consoante o ponto a partir do qual verifica. No próprio servidor, aberta significa que um processo está associado a essa porta e à espera de ligações. A partir de outra máquina, aberta significa que um pacote chega a esse processo e recebe uma resposta. Quando não há resposta, a pergunta real é qual dispositivo descartou o pacote. sudo ss -ltnp responde à primeira pergunta. nc -z ou nmap respondem à segunda. Os contadores da firewall e tcpdump respondem à terceira.

Executar a verificação errada é o que faz perder uma tarde. Um teste executado no servidor nunca passa pela firewall de rede do fornecedor, porque esse filtro está fora do servidor. Se os números das portas ainda forem novos para si, como funcionam as portas e os sockets no Linux explica o modelo assumido no resto deste guia.

O que está em escuta neste servidor? Leia a saída de ss

ss vem incluído no iproute2, por isso está presente em todas as distribuições atuais. netstat vem do net-tools, que o Ubuntu deixou de instalar por predefinição há vários anos, por isso netstat -tulpn muitas vezes responde netstat: command not found. Aprenda ss e evite essa frustração.

sudo ss -ltnp

-l mostra apenas sockets em escuta. -t limita a lista a TCP. -n apresenta números em vez de resolver nomes, por isso o comando devolve o resultado imediatamente. -p identifica o processo proprietário e requer root: sem sudo, a coluna Process fica vazia para todos os processos que não lhe pertencem. Substitua -t por -u para ver UDP.

State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096   127.0.0.53%lo:53    0.0.0.0:*   users:(("systemd-resolve",pid=612,fd=14))
LISTEN 0      128    0.0.0.0:22          0.0.0.0:*   users:(("sshd",pid=921,fd=3))
LISTEN 0      511    127.0.0.1:8080      0.0.0.0:*   users:(("node",pid=1442,fd=19))
LISTEN 0      128    [::]:22             [::]:*      users:(("sshd",pid=921,fd=4))

A coluna Local Address determina tudo, mas é a coluna que muitas pessoas passam rapidamente por alto.

• 0.0.0.0:22 significa todos os endereços IPv4 da máquina, por isso o serviço pode ser alcançado a partir do exterior se a firewall o permitir.
• [::]:22 representa o mesmo para IPv6.
• 127.0.0.1:8080 significa apenas loopback. Nada fora desta máquina lhe pode aceder.
• 10.20.0.5:5432 significa apenas esse endereço de interface, e nenhum outro. É comum em configurações de redes privadas.
• Uma coluna Process vazia normalmente indica a ausência de sudo, não a ausência de um processo.

Para consultar uma porta específica, filtre dentro de ss em vez de usar grep sobre a lista inteira:

sudo ss -ltnp 'sport = :8080'
sudo lsof -nP -iTCP:8080 -sTCP:LISTEN
sudo fuser 8080/tcp

Uma saída vazia nos três casos significa que nada está a usar essa porta. O serviço está parado, falhou ao iniciar ou está em escuta noutro endereço. Leia systemctl status <unit> e journalctl -u <unit> -n 50 antes de alterar uma única regra da firewall.

Por que 127.0.0.1 em Local Address custa uma tarde inteira

Um socket associado a 127.0.0.1 não pode ser acedido a partir de outro host, e nenhuma regra de firewall altera esse facto. O kernel encaminha 127.0.0.0/8 apenas para a interface de loopback, e um pacote com esse endereço de destino que chegue por uma placa de rede real é descartado como endereço martian. Por isso, o processo está em execução, ss mostra que está à escuta, ufw allow 8080 indica sucesso, mas a ligação a partir do seu portátil continua a falhar. A falha ocorre com um Connection refused imediato, porque o pacote chega ao seu endereço público, não encontra nenhum socket associado a esse endereço e o kernel responde com um reset TCP.

Muitos programas associam-se à interface de loopback de propósito. Para uma base de dados ou uma interface de administração, essa é a predefinição correta. Existem duas opções adequadas. Altere o endereço de associação na configuração do próprio programa (listen_addresses em postgresql.conf, bind em redis.conf ou o argumento de host aceite pela aplicação) e, em seguida, abra a firewall. Ou mantenha o serviço na interface de loopback e aceda a ele através de outro componente, como um reverse proxy nginx ou um túnel SSH a partir do seu portátil:

ssh -L 8080:127.0.0.1:8080 user@203.0.113.10

O Docker mantém a mesma distinção na sua flag de publicação. -p 8080:8080 associa o serviço a 0.0.0.0 e expõe o contentor à Internet. -p 127.0.0.1:8080:8080 associa-o à interface de loopback e mantém o serviço local.

Como verificar se uma porta está aberta no Linux a partir de outra máquina

Execute este teste a partir de uma rede diferente. Um teste no próprio servidor prova apenas que o caminho de loopback funciona. Mesmo ligar ao seu próprio IP público a partir do servidor ignora a firewall de rede do fornecedor, porque esse filtro é executado fora do VPS.

nc -zv -w 3 203.0.113.10 443

-z liga-se e fecha a ligação sem enviar dados. -w 3 desiste após três segundos, e essa flag é importante: sem timeout, um pacote descartado faz o cliente repetir o SYN durante mais de dois minutos, até o kernel parar. Um resultado bem-sucedido é semelhante a este:

Connection to 203.0.113.10 443 port [tcp/https] succeeded!

Se a ferramenta não estiver instalada (nc: command not found), instale netcat-openbsd no Debian ou Ubuntu, ou use o redirecionamento de rede integrado do bash, que não requer nenhum pacote:

timeout 3 bash -c '</dev/tcp/203.0.113.10/443' && echo open || echo "no answer"

Essa sintaxe é uma funcionalidade do bash, por isso execute-a com bash. /bin/sh no Debian e no Ubuntu é o dash, que não tem /dev/tcp e informa que o caminho não existe. Para um intervalo de portas, ou quando quiser que o estado seja identificado, use o nmap nos hosts pelos quais é responsável:

sudo nmap -Pn -p 22,80,443 203.0.113.10
sudo nmap -Pn -p 1-1024 203.0.113.10

-Pn ignora a descoberta de hosts. A maioria dos fornecedores de VPS descarta pedidos de eco ICMP. Sem -Pn, o nmap conclui que o host está inativo e não analisa nenhuma porta. O nmap imprime open quando algo respondeu e aceitou a ligação, closed quando algo respondeu com um reset e filtered quando não houve resposta. Para um serviço web, curl -sS -o /dev/null -w '%{http_code}\n' https://example.com separa uma falha de rede de uma falha da aplicação, porque um código de estado prova que todo o caminho funcionou.

Por que uma porta bloqueada fica pendurada e uma porta fechada recusa imediatamente

Uma recusa imediata. O pacote chegou à máquina e algo respondeu.

nc: connect to 203.0.113.10 port 443 (tcp) failed: Connection refused

Duas causas diferentes produzem exatamente essa mensagem. Ou não existe nenhum processo associado a esse endereço e porta, e o kernel respondeu com um reset TCP, ou uma regra de firewall rejeitou o pacote com um reset ou uma mensagem ICMP de porta inacessível. Uma recusa é uma resposta definitiva e regressa numa única viagem de ida e volta.

Uma pausa, seguida de um timeout. Algo descartou o pacote e não respondeu.

nc: connect to 203.0.113.10 port 443 (tcp) timed out: Operation now in progress

É isso que uma regra ss -ltnp faz, tal como um firewall do provedor ou um grupo de segurança na nuvem. O silêncio é a assinatura de um descarte, porque o remetente não consegue distinguir um descarte de um host inativo.

O sintoma indica onde procurar a seguir. Uma recusa significa que os pacotes estão a atravessar a rede normalmente. Volte a ss -ltnp e verifique o endereço de bind e o número da porta. Um timeout significa que os pacotes estão a ser descartados. Nesse caso, leia os firewalls de fora para dentro. recusada versus timeout no SSH separa o mesmo problema para a porta 22, que é onde a maioria das pessoas o encontra.

O ufw oferece deliberadamente os dois comportamentos: ufw deny 8080 descarta, e ufw reject 8080 envia uma rejeição. No nftables, os dois destinos são drop e reject. No iptables, são -j DROP e -j REJECT. As políticas predefinidas são quase sempre de descarte. Por isso, uma regra em falta provoca uma espera em vez de uma mensagem de erro.

Quem está a bloquear a porta? Trabalhe de fora para dentro

sudo ufw status verbose
sudo iptables -L INPUT -n -v --line-numbers
sudo nft list ruleset

Os contadores -v são a parte útil. Execute o teste nc a partir do exterior, execute novamente o comando do iptables e procure o contador que mudou: a regra cujo número de pacotes aumenta é a regra que está a tratar o seu tráfego. Assim, deixa de adivinhar e passa a ter evidências.

O teste decisivo é executado no servidor, monitorizando a rede enquanto estabelece a ligação a partir do exterior:

sudo tcpdump -ni any tcp port 8080

A chegada de um SYN sem o envio de um SYN-ACK significa que o pacote chegou ao seu VPS e foi descartado pelo host. Nesse caso, a firewall do fornecedor está a funcionar e as regras locais não estão. A ausência total de saída significa que o pacote nunca chegou. A causa é então a firewall do fornecedor, um security group ou um endereço IP incorreto. Esta distinção elimina a maior parte do trabalho.

Duas camadas produzem resultados que parecem impossíveis. A primeira é o IPv6: se o hostname tiver um registo AAAA, o cliente pode estabelecer a ligação por IPv6 enquanto a sua regra cobre apenas IPv4. Por isso, teste cada família com nc -4 e nc -6 antes de confiar em qualquer resultado. regras do ufw e portas IPv6 num VPS aborda esta incompatibilidade. A segunda é o Docker: uma porta de contentor publicada responde a partir da Internet mesmo quando ufw status indica que essa porta está negada, porque esses pacotes são tratados antes de chegarem à chain do ufw. por que o Docker publica portas diretamente através do ufw explica o mecanismo e a correção, e as regras do ufw a definir num VPS novo é o conjunto base que deve configurar primeiro.

Por que as respostas UDP são ambíguas por definição

O UDP não tem handshake, por isso uma sonda não tem uma operação que possa concluir com sucesso. nc -zu 203.0.113.10 53 termina com o código 0 assim que o pacote sai, o que prova apenas que a sua própria máquina o enviou e não prova nada sobre o destino. Quando uma porta UDP está fechada, o host normalmente responde com uma mensagem ICMP port unreachable, e o kernel só comunica esse erro a um socket ligado na próxima escrita. Por isso, uma sonda de um único pacote não o deteta. As firewalls bloqueiam ICMP por padrão, eliminando até essa indicação. É por isso que o nmap apresenta open|filtered para a maioria das portas UDP: a ausência de resposta é exatamente o que produzem tanto um serviço aberto e silencioso como uma porta filtrada.

Teste o UDP falando o protocolo que pretende verificar. Um servidor DNS responde a dig +short @203.0.113.10 example.com com um endereço ou sem resposta. Um peer WireGuard apresenta uma linha latest handshake recente em sudo wg show. Depois, confirme a chegada no lado do servidor:

sudo tcpdump -ni any udp port 51820

A presença de pacotes enquanto o cliente envia significa que eles chegaram. Nesse caso, o problema está no serviço ou na cadeia de entrada. A ausência total de pacotes significa que eles não chegaram ao destino.

Uma checklist na ordem que encontra a falha mais rapidamente

1. No servidor, execute sudo ss -ltnp 'sport = :8080'. Sem saída, nada está a escutar, por isso corrija primeiro o serviço.
2. Se houver saída, leia a coluna Local Address. 127.0.0.1 significa que o acesso externo é impossível até voltar a associar o serviço ao endereço correto ou colocar um proxy à frente.
3. A partir de outra rede, execute nc -zv -w 3 <public ip> 8080.
4. Uma recusa remete para o passo 1. O endereço, a porta ou a máquina não são os que pensa.
5. Um timeout significa que os pacotes estão a ser descartados. Inicie sudo tcpdump -ni any tcp port 8080 no servidor e repita o teste.
6. O SYN chega, mas nada regressa: o firewall do host. Encontre a regra cujo contador aumenta em sudo iptables -L INPUT -n -v.
7. Nenhum SYN chega: o firewall do fornecedor, um security group ou o endereço IP errado.

FAQ

Como verifico quais portas estão abertas no meu próprio servidor Linux?

Execute sudo ss -ltnp para TCP e sudo ss -lunp para UDP. Cada linha corresponde a um socket em escuta, e a coluna Local Address indica quem pode aceder-lhe: 0.0.0.0 e [::] aceitam ligações de qualquer origem permitida pela firewall, enquanto 127.0.0.1 aceita ligações apenas da própria máquina. A coluna Process requer root, por isso execute o comando com sudo; caso contrário, fica vazia. ss faz parte do iproute2 e está sempre instalado; netstat faz parte do net-tools e normalmente não está instalado.

Porque é que o ss mostra o meu serviço em escuta, mas continuo sem conseguir ligar-me?

Há duas causas comuns, e um comando permite distingui-las. Se Local Address for 127.0.0.1, o serviço está associado ao loopback e não pode ser acedido a partir de outro host, porque o kernel encaminha esse intervalo apenas para a interface de loopback. Se for 0.0.0.0 e as ligações continuarem a falhar, execute sudo tcpdump -ni any tcp port <port> no servidor e tente ligar-se a partir do exterior. Um SYN que chega sem resposta significa que uma regra da firewall local o está a descartar. Se não chegar nada, o pacote está a ser bloqueado antes de alcançar o seu VPS, normalmente por uma firewall do fornecedor ou por um security group.

Qual é a diferença entre uma ligação recusada e uma ligação que excede o tempo limite?

Uma recusa é uma resposta. O pacote chegou ao host e recebeu de volta um reset TCP ou uma mensagem ICMP de porta inacessível. Isto significa que nada está em escuta nesse endereço e porta, ou que uma regra rejeitou a ligação. Um timeout é silêncio: uma regra descartou o pacote e não enviou resposta, por isso o cliente tenta novamente até desistir. Uma recusa aponta para o serviço e para o respetivo endereço de associação. Um timeout aponta para uma firewall, e deve verificar primeiro a firewall mais próxima do exterior.

Como verifico se uma porta UDP está aberta?

Não é possível obter uma resposta fiável de sim com uma sonda genérica, porque UDP não tem handshake e um serviço silencioso tem o mesmo comportamento que um pacote descartado. nc -zu devolve sucesso assim que envia o pacote, e o nmap apresenta open|filtered pelo mesmo motivo. Faça o teste através do próprio protocolo: dig +short @<host> example.com para DNS ou sudo wg show para um peer WireGuard com um handshake recente. Para confirmar que os pacotes chegam, execute sudo tcpdump -ni any udp port <port> no servidor enquanto o cliente envia.

Ainda posso usar telnet host port para testar uma porta?

Funciona para TCP, e Escape character is '^]' significa que a ligação foi aceite. Saia com Ctrl+] e depois execute quit. Há dois motivos para nc -z ser uma ferramenta melhor: o telnet não está instalado na maioria das imagens de servidor atuais, e nc aceita um timeout com -w e define um estado de saída que pode ser testado num script. Quando nenhum dos dois estiver disponível, timeout 3 bash -c '</dev/tcp/<host>/<port>' não requer qualquer pacote.