Porta WireGuard: UDP 51820 por padrão, altere-a em 3 passos

O WireGuard usa a porta UDP 51820 por padrão, definida pela linha ListenPort da configuração do servidor (wg0.conf). Nunca usa TCP, e 51820 é apenas uma convenção: pode escolher qualquer porta UDP livre. Quase todos os problemas de "o meu VPN auto-hospedado não se conecta" se resumem a essa porta não estar aberta, não ser encaminhada ou não corresponder ao Endpoint do cliente. Este guia cobre o padrão, como alterá-lo e como abrir e encaminhar corretamente.

Verifique a sua instalação: o verificador de porta WireGuard compara o endereço WAN do router com o seu IP público para detetar CGNAT (onde nenhum redirecionamento de porta funciona) e escreve a regra de redirecionamento e os comandos de firewall para ufw, firewalld, nftables, iptables, Windows ou OpenWrt.

Se o verificador detetar CGNAT, nenhum redirecionamento funcionará a partir de casa: a solução é alojar o servidor num VPS com o seu próprio IPv4 público, por exemplo um VPS Cloud da Contabo (link de afiliado), desde 5,50 € por mês num prazo de 24 meses (preço lido a 17 de outubro de 2026).

As portas do WireGuard num relance

A resposta curta: o WireGuard usa a porta UDP 51820 por padrão - essa é a sua porta padrão (standard), definida pela linha ListenPort. Não existe modo TCP algum. As portas que importam:

O Endpoint = <public-ip>:<port> do cliente deve usar exatamente a mesma porta que a ListenPort do servidor - essa discrepância é de longe o motivo mais comum para um túnel WireGuard auto-hospedado não se conectar.

A maioria das falhas vem de um ListenPort e de um Endpoint que não coincidem, ou de um router onde não é possível encaminhar portas (CGNAT). O nosso gerador de configuração WireGuard gratuito escreve configurações de servidor e cliente coerentes no seu navegador. Um VPS com o seu próprio IPv4 público dispensa o encaminhamento de portas: um Cloud VPS 4 da Contabo aparece a partir de 5,50 €/mês em contabo.com (verificado a 17/10/2026), e um VPS Basic da Ultahost com IPv4 dedicado a 5,52 $/mês com compromisso de 24 meses em ultahost.com (verificado a 21/10/2026).

A sua porta é mesmo alcançável? Um scanner de portas online não lhe consegue dizer: o WireGuard nunca responde a pacotes não autenticados, por isso cada scan diz "open|filtered". O nosso verificador de porta WireGuard gratuito compara o endereço WAN do router com o seu IP público para detetar CGNAT e NAT duplo, e dá a regra de firewall do seu sistema e o teste a partir de fora que prova mesmo que a porta está aberta.

O padrão: UDP 51820

O WireGuard escuta na porta UDP 51820 por convenção, definida pela linha ListenPort na seção [Interface] do servidor. Duas coisas são importantes aqui:

• É UDP, não TCP. O WireGuard não tem modo TCP. Firewalls ou redes que bloqueiam UDP irão interrompê-lo completamente.
• 51820 é apenas o padrão, não uma regra - pode usar qualquer porta UDP livre de 1 a 65535.

Os clientes alcançam o servidor usando a linha Endpoint = <public-ip>:51820 na sua própria configuração. Essa porta deve corresponder exatamente à ListenPort do servidor.

Escolher uma porta: vale a pena usar 443/UDP?

Qualquer porta UDP livre de 1-65535 funciona, mas algumas escolhas são mais inteligentes que outras:

• Mantenha 51820 pela simplicidade se a sua rede não filtra UDP - é o padrão documentado e o mais fácil de suportar.
• Use UDP 443 se estiver numa rede restritiva. A porta 443 é a porta HTTPS, e o tráfego web moderno (HTTP/3 / QUIC) já funciona sobre UDP 443, então um túnel WireGuard ali se mistura com o tráfego criptografado normal e passa por muitos bloqueios baseados em portas. É a mudança de porta mais útil. Note que isso é apenas camuflagem a nível de porta - a inspeção profunda de pacotes ainda pode identificar o handshake (veja a seção de stealth abaixo).
• Evite portas abaixo de 1024 a menos que tenha um motivo; são "privilegiadas" e precisam de root, sem vantagem aqui.

Abrindo a porta no firewall

No servidor, a porta deve ser permitida para UDP. Com UFW:

sudo ufw allow 51820/udp
sudo ufw reload

Com iptables é -A INPUT -p udp --dport 51820 -j ACCEPT. Esta é a causa mais comum de um servidor que "funciona" mas nunca aceita conexões: o serviço WireGuard está ativo, mas o firewall descarta silenciosamente os pacotes.

Encaminhando a porta através de um router

Onde o seu servidor está localizado decide se também precisa de encaminhamento de porta:

• Num VPS (um servidor alugado com um IP público): não é necessário encaminhamento - a regra do firewall é suficiente, pois o IP público aponta diretamente para a máquina.
• Num servidor doméstico atrás de um router: adicione uma regra de encaminhamento de porta no admin do router - encaminhe UDP 51820 (externo) para o IP local do servidor em UDP 51820 (interno). Sem isso, pacotes da internet nunca chegam ao servidor.

Teste de fora da sua rede (por exemplo, um telemóvel com dados móveis, Wi-Fi desligado): um cliente deve alcançar server-public-ip:51820. Se funcionar na sua LAN mas não de fora, o encaminhamento é a peça que falta.

Alterando a porta

Para usar uma porta diferente, defina-a na [Interface] do servidor:

[Interface]
ListenPort = 51821

Depois reinicie o túnel (systemctl restart wg-quick@wg0) e atualize tudo o que referenciava a porta antiga:

1. a regra do firewall (permita a nova porta UDP),
2. o encaminhamento do router (se aplicável),
3. a linha Endpoint em cada configuração de cliente.

Se faltar algum, os clientes não se conectarão. Um VPS auto-hospedado torna tudo isso simples porque controla diretamente o firewall e o IP público. Se está a editar a configuração do zero, os nossos modelos de configuração WireGuard prontos a usar dão-lhe um esqueleto [Interface]/[Peer] correto com as linhas ListenPort e Endpoint já no sítio certo.

Verifique se a porta está realmente a escutar

Antes de culpar o cliente, confirme se o servidor realmente escuta na porta que pensa:

sudo wg show              # mostra a interface e a sua porta de escuta
sudo ss -lunp | grep 51820   # há algo ligado à UDP 51820?

wg show lista a porta de escuta ativa; ss -lunp (note o u para UDP) prova que um processo está ligado a ela. Se wg show reportar uma porta diferente da sua configuração, o serviço não recarregou após a sua edição - reinicie-o. De outra máquina, pode testar a acessibilidade com nc -uvz server-ip 51820, embora sondagens UDP sejam pouco confiáveis, então um handshake real de cliente é o teste definitivo.

Executando mais de um túnel

Cada interface WireGuard precisa da sua própria ListenPort. Se executar, por exemplo, wg0 para tráfego geral e wg1 para um grupo separado de pares, dê-lhes portas distintas (por exemplo, 51820 e 51821), abra e encaminhe ambas, e aponte cada cliente para a correta. Duas interfaces a partilhar uma porta falham silenciosamente ao iniciar.

Alterar a porta esconde o seu VPN?

Uma porta não padrão reduz o ruído de bots que escaneiam 51820, mas não é stealth. A inspeção profunda de pacotes identifica o handshake UDP distinto do WireGuard independentemente do número da porta. Se precisar passar por um firewall que bloqueia ou detecta ativamente VPNs, precisa de ofuscação (envolver o túnel), não apenas uma porta diferente - veja WireGuard com port knocking / stealth. Para rotear tráfego específico ou encaminhar serviços através do túnel, veja encaminhamento de porta.

Sem servidor, só uma rede que bloqueia? Se quer fazer passar o seu próprio portátil pelo Wi-Fi de um hotel, escritório ou campus que corta o WireGuard, uma aplicação VPN com um modo de ofuscação integrado faz o encapsulamento por si: o Proton VPN oferece Stealth, um túnel TLS ofuscado disponível em todos os planos, incluindo o gratuito, e o NordVPN oferece NordWhisper, que faz o tráfego VPN parecer tráfego web normal e agora corre os seus servidores ofuscados (links de afiliado). Contra uma DPI estatal, um servidor privado encapsulado com Xray REALITY resiste melhor; o nosso guia anti-DPI compara os dois caminhos.

Conclusão

O WireGuard usa UDP 51820 por padrão - apenas UDP, sem TCP. Para tornar um servidor auto-hospedado acessível: abra a porta para UDP no firewall, encaminhe-a no router se o servidor estiver atrás de um (um VPS com IP público dispensa isso), e certifique-se de que o Endpoint de cada cliente corresponde. Altere a porta se quiser para menos ruído de escaneamento, mas trate isso como um endurecimento leve, não como stealth real.

Depois de escolher a porta, o nosso gerador de configuração WireGuard gratuito cria uma configuração de servidor e cliente coerente no seu navegador, com o ListenPort e o Endpoint ja alinhados.

Quando nenhuma definicao de porta vai ajudar

Abrir a UDP 51820 só serve se alguma coisa conseguir mesmo chegar ao seu servidor. Atrás de um CGNAT, ou num router que não controla, não há porta para encaminhar nem regra de firewall que resolva. Um VPS com o seu próprio IPv4 público elimina a questão: a porta que abre é a porta que a internet vê. Um Cloud VPS 4 da Contabo por 5,50 €/mês dá-lhe root completo e um IP público, e o guia passo a passo Contabo + WireGuard cobre o resto.

Uma VPN muda o seu IP. Não muda o seu navegador.

Um túnel substitui o endereço que um serviço vê. Não altera nada do que o seu navegador anuncia por conta própria - tipos de letra, ecrã, fuso horário, pilha gráfica - e essa combinação costuma bastar para o reconhecer de uma sessão para a outra.

Meça a sua impressão digital de navegador - medição passiva, sem perguntas, sem conta, sem e-mail.

Guias relacionados

• MikroTik CVE-2026-14227: a sua chave privada WireGuard pode ser lida, e desativar a API não desfaz isso

Num telefone aplicam-se as mesmas verificações de porta e firewall, mas as falhas apresentam-se de outra forma e as ferramentas são menos: veja WireGuard no iPhone para as três que explicam quase todos os túneis iOS avariados.