Porta fechada em jogos: como testar sem tirar conclusões erradas

Um cliente que entra num servidor inicia uma conexão de saída. Um servidor hospedado em casa precisa aceitar conexões de entrada. Listas de portas de um jogo podem descrever destinos necessários, sem exigir que todas essas portas recebam conexões novas no seu IP público.

Antes de criar uma regra, confirme na documentação do jogo: plataforma, TCP ou UDP, função da porta e se o cenário é cliente, servidor dedicado, chat ou uso remoto. Não copie uma lista de outro jogo ou de outra edição.

Mantenha o servidor ou aplicativo em execução. No PowerShell, este comando lista portas TCP locais em escuta e o processo responsável:

Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess

A presença na lista não prova acesso externo. Um serviço associado apenas a 127.0.0.1 recebe conexões locais, não da LAN. Confira a configuração de bind/listen do programa, sem trocar a interface de escuta indiscriminadamente.

Para UDP, o comando Get-NetUDPEndpoint | Select-Object LocalAddress,LocalPort,OwningProcess lista endpoints. Isso também não comprova que um pacote vindo da internet receberá resposta.

1. Reserve o endereço LAN do servidor no DHCP, conforme o manual do roteador.
2. Use esse endereço como destino interno, não o IP do roteador.
3. Confira protocolo e portas interna/externa.
4. Verifique uma regra específica no firewall do dispositivo, sem desativá-lo inteiro.
5. Compare a WAN e investigue outro NAT antes do roteador.

Se dois aparelhos precisam da mesma porta pública, uma regra simples não consegue enviar a mesma combinação de endereço, porta e protocolo simultaneamente aos dois. Consulte a seleção de porta alternativa ou o mecanismo recomendado pelo aplicativo.

O teste TCP deste site inicia uma conexão externa ao IP observado da sua própria requisição, numa porta entre 1024 e 65535. Se estabelecer conexão, algum serviço aceitou TCP; o resultado não autentica nem identifica o aplicativo.

Recusa e timeout são resultados diferentes. Ausência de resposta pode envolver filtro, rota, serviço parado ou regra ausente. Falha da infraestrutura é apresentada como inconclusiva. Uma consulta ao próprio IP público por dentro da LAN também pode depender de NAT loopback, produzindo um cenário diferente.

UDP não estabelece a mesma conexão que TCP. Muitos serviços só respondem a pacotes válidos do próprio protocolo, de modo que silêncio não basta para declarar a porta fechada.

Por isso, não adaptamos um teste TCP para prometer “UDP aberto”. Use o teste nativo do console, o diagnóstico do jogo ou uma comunicação real com o servidor. Uma conexão TCP estabelecida nunca substitui o resultado de NAT do console.

Depois de concluir a investigação, remova regras temporárias que não serão utilizadas. Não deixe o painel de administração do roteador publicado na internet para “testar se funciona”.