Qual Porta o WireGuard Usa? Porta Padrão, Alteração e Encaminhamento (2026)

A rede do WireGuard é surpreendentemente simples — mas o número que costuma confundir as pessoas é a porta. Por padrão, o WireGuard escuta na porta UDP 51820, e 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 à configuração do cliente. Este guia cobre o padrão, como alterá-lo e como abrir e encaminhar corretamente.

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.

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.

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.