Modelos de configuração WireGuard prontos a usar 2026

Instalou o WireGuard no seu VPS. Leu três tutoriais contraditórios. O wg0.conf que colou não faz ping, ou faz ping mas há fugas de DNS, ou o kill switch desativa toda a sua máquina quando se desconecta. A causa é quase sempre a mesma: um modelo copiado sem compreender o contexto original.

Este guia fornece 8 modelos wg0.conf para um Contabo Cloud VPS 4, com caso de uso, armadilhas conhecidas e as quatro linhas que precisa adaptar. Escolha o que corresponde ao seu cenário, troque as chaves, conecte. Cinco minutos.

Ainda não tem servidor? Todos os modelos abaixo pressupõem um VPS com IPv4 pública. Um Contabo Cloud VPS 4 aparece a partir de 5,50 €/mês em contabo.com (preço de tabela verificado a 17 de outubro de 2026, prazo de 24 meses, sem IVA). É um link de afiliado: podemos receber uma comissão, o seu preço não muda. Se preferir um fornecedor dos EUA com 30 dias de reembolso, o VPS Basic da Ultahost custa 5,52 $ por mês em 24 meses (1 GB de RAM, IPv4 dedicado, lido a 21 de outubro de 2026), suficiente para um servidor WireGuard com poucos dispositivos.

Quer o modelo já preenchido? O nosso gerador de configuração WireGuard gratuito recebe o IP do seu servidor, a sub-rede e o número de pares, e escreve um wg0.conf pronto a colar mais as configurações dos clientes, com chaves geradas no seu navegador. Os modelos abaixo servem para perceber o que faz cada linha e as armadilhas de cada cenário. O gerador é gratuito e sem conta, até 250 dispositivos, e a sua exportação ZIP junta cada .conf de cliente e o seu código QR em PNG, prático para configurar um escritório ou uma família inteira de uma só vez.

Ainda não escolheu o VPS? A nossa comparação Melhor VPS para uma VPN compara oito fornecedores para auto-alojar o WireGuard pelo preço que realmente paga, incluindo as duas rubricas que mudam a classificação: IPv4 paga e limitação de velocidade.

Por que usar modelos em vez de gerar tudo manualmente

O WireGuard é conhecido por ter uma configuração minimalista comparada ao OpenVPN, mas minimalista não significa trivial. Cada seção tem um significado implícito que os tutoriais copiam e colam sem explicar, e um único valor errado pode quebrar silenciosamente o túnel ou vazar tráfego sem nenhum sintoma visível imediato. Uma pergunta que os iniciantes fazem vezes sem conta: "meu túnel está ativo, o ping funciona para o servidor, mas nenhuma conexão HTTP funciona a partir do cliente". A causa habitual é um AllowedIPs mal colocado ou um PostUp/PostDown ausente.

Os modelos abaixo cobrem 8 cenários de implantação distintos e reais. Cada um vem com um comentário de contexto descrevendo para quem é, o que garante e os limites conhecidos. Se o seu caso corresponder ao modelo em 80%, adapte os 20% restantes; se o seu caso não se encaixar em nenhum modelo, reconstrua a partir do modelo mais próximo e mantenha apenas as diretivas que se aplicam a si. Isso é mais rápido do que começar do zero e mais confiável do que remendar a partir de uma resposta aleatória do Stack Overflow de 2020.

A outra razão para usar modelos é a manutenção a longo prazo. Se uma futura versão do WireGuard alterar uma diretiva, republicaremos os modelos com os ajustes claramente marcados, e saberá exatamente qual linha atualizar no seu wg0.conf. É o equivalente a um manifesto Kubernetes versionado para VPN - o valor não está no conteúdo inicial, mas na capacidade de iterar de forma limpa em cima.

Convenções partilhadas

Cada modelo segue as mesmas regras - simplifique o seu modelo mental:

• Sub-rede do cliente: 10.66.66.0/24 (peers .2 → .254)
• Interface pública do servidor: eth0 (verifique com ip route | awk '/default/ {print $5}')
• Porta UDP: 51820 (alterável e a abrir na firewall; veja o modelo 7 de ofuscação)
• Chaves: geradas via wg genkey | tee server.key | wg pubkey > server.pub
• Sysctl: net.ipv4.ip_forward=1 ativado no servidor (/etc/sysctl.conf)
• MTU: 1420 por padrão, ajustado quando necessário

Os blocos PrivateKey abaixo são espaços reservados - substitua pelos seus. Nunca comprometa estes ficheiros num repositório git público.

Modelo 1 - Servidor WireGuard padrão (1 cliente roadwarrior)

O caso mais comum: o seu VPS Contabo expõe um túnel para o seu MacBook na estrada.

# /etc/wireguard/wg0.conf (servidor)
[Interface]
PrivateKey = SERVER_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820
MTU = 1420

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# MacBook do Eric
PublicKey = CLIENT_PUBLIC_KEY_HERE
AllowedIPs = 10.66.66.2/32

Lado do cliente:

# /etc/wireguard/wg0.conf (cliente macOS/Linux)
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9, 149.112.112.112
MTU = 1420

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Pontos de atenção:

• AllowedIPs = 0.0.0.0/0, ::/0 roteia TODO o tráfego do cliente através do VPS - é isso que deseja para uma VPN clássica.
• PersistentKeepalive = 25 é obrigatório se o cliente estiver atrás de NAT (rede de hotel, 4G) - sem isso, o túnel morre assim que o mapeamento NAT expira.
• DNS = 9.9.9.9 força a resolução Quad9 - caso contrário, o cliente usa DNS local e as suas consultas vazam.

Modelo 2 - VPN doméstica (túnel dividido: LAN local excluída)

Quer VPN para o seu tráfego web, mas manter o acesso à LAN local (impressora, NAS) sem passar pelo túnel.

# Cliente doméstico
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9
MTU = 1420

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
# Tudo exceto LAN RFC1918 + multicast + APIPA
AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/3, 224.0.0.0/4, 240.0.0.0/5, 248.0.0.0/6, 252.0.0.0/7, 254.0.0.0/8, 255.0.0.0/9
PersistentKeepalive = 25

O truque da sub-rede fragmentada (em vez de 0.0.0.0/0) faz com que o WireGuard adicione rotas específicas que não substituem a rota padrão. A sua LAN 192.168.x.x e 10.x.x.x permanecem acessíveis diretamente.

Uma calculadora de AllowedIPs online pode gerar esses intervalos por si.

Modelo 3 - VPN de viagem com kill switch estrito de netfilter

Vai viajar para a China, Irão, Rússia. Se o túnel cair, nada vaza. Solução: kill switch de netfilter que bloqueia tudo exceto o tráfego via wg0 e o handshake do servidor.

# Cliente com kill-switch de viagem
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9
MTU = 1280

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PostUp = ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Essas quatro linhas PostUp/PreDown são o verdadeiro kill switch - não um popup de aplicação. Até que wg-quick down wg0 seja executado, nenhum pacote sai da interface que não esteja marcado pelo WireGuard.

MTU 1280 para redes exigentes (hotéis, 3G). Perder um pouco de throughput é melhor do que um túnel instável.

Modelo 4 - Multi-peer (5 dispositivos, mesmo utilizador)

Tem um MacBook, iPhone, iPad, VPS de trabalho, Raspberry Pi. Quer que todos sejam roteados pela mesma VPN com sub-redes separadas para monitorização.

# /etc/wireguard/wg0.conf (servidor)
[Interface]
PrivateKey = SERVER_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# MacBook
PublicKey = MAC_PUBKEY
AllowedIPs = 10.66.66.2/32

[Peer]
# iPhone
PublicKey = IPHONE_PUBKEY
AllowedIPs = 10.66.66.3/32

[Peer]
# iPad
PublicKey = IPAD_PUBKEY
AllowedIPs = 10.66.66.4/32

[Peer]
# VPS de trabalho (Hetzner)
PublicKey = WORKER_PUBKEY
AllowedIPs = 10.66.66.5/32

[Peer]
# Raspberry Pi em casa
PublicKey = RPI_PUBKEY
AllowedIPs = 10.66.66.6/32

Cada peer tem um IP fixo na sub-rede 10.66.66.0/24. Se monitorizar via Prometheus (veja o guia de monitorização), pode etiquetar por IP e saber quem consome mais largura de banda.

Modelo 5 - Hub-and-spoke (peer-to-peer entre clientes)

Por padrão, o WireGuard não roteia entre peers. Se quiser que o seu iPhone fale com o seu Raspberry Pi através do servidor hub:

No servidor, adicione:

sysctl -w net.ipv4.ip_forward=1

E nos blocos [Peer] do servidor, defina AllowedIPs = 10.66.66.X/32 (IP único do peer).

Nos clientes, altere AllowedIPs:

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
# Toda a sub-rede, não apenas 0.0.0.0/0
AllowedIPs = 10.66.66.0/24

Agora, a partir do seu iPhone (10.66.66.3), pode ssh pi@10.66.66.6 diretamente - o hub encaminha.

Modelo 6 - Restrição de egress por peer (lista de permissões)

Caso avançado: um peer (o seu filho, um convidado, um serviço automatizado) deve conectar-se ao túnel mas apenas alcançar domínios/IPs específicos.

Adicione ao PostUp do servidor, além do MASQUERADE:

iptables -A FORWARD -s 10.66.66.50/32 -d 1.1.1.1 -j ACCEPT
iptables -A FORWARD -s 10.66.66.50/32 -d 142.250.0.0/15 -j ACCEPT  # Google
iptables -A FORWARD -s 10.66.66.50/32 -j REJECT

O peer 10.66.66.50 só pode alcançar 1.1.1.1 (DNS) e IPs do Google. Tudo o resto é rejeitado.

Modelo 7 - Ofuscação na porta 443 via udp2raw

Alguns firewalls corporativos bloqueiam UDP de saída. Solução: encapsular o WireGuard dentro de TCP/443 falso via udp2raw.

Lado do servidor:

udp2raw_amd64 -s -l 0.0.0.0:443 -r 127.0.0.1:51820 -k "p@ssw0rd_long" --raw-mode faketcp

Lado do cliente:

udp2raw_amd64 -c -l 127.0.0.1:50000 -r vpn.example.com:443 -k "p@ssw0rd_long" --raw-mode faketcp

No wg0.conf do cliente, altere Endpoint:

Endpoint = 127.0.0.1:50000

O throughput cai (o encapsulamento adicional tem um custo) mas passa por quase qualquer DPI corporativo.

Modelo 8 - Site-to-site (duas LANs interligadas)

Duas casas, dois gateways Raspberry Pi, um VPS Contabo como hub. Cada LAN vê a outra como se fosse local.

Servidor (hub VPS):

[Interface]
PrivateKey = HUB_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Site A (LAN 192.168.10.0/24)
PublicKey = SITE_A_PUBKEY
AllowedIPs = 10.66.66.10/32, 192.168.10.0/24

[Peer]
# Site B (LAN 192.168.20.0/24)
PublicKey = SITE_B_PUBKEY
AllowedIPs = 10.66.66.20/32, 192.168.20.0/24

Site A (Raspberry Pi):

[Interface]
PrivateKey = SITE_A_PRIVATE_KEY_HERE
Address = 10.66.66.10/24

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE

[Peer]
PublicKey = HUB_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 10.66.66.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Não se esqueça de ip_forward em ambas as Raspberries e de uma rota estática nas outras máquinas da LAN se precisarem responder do outro site.

Diagnóstico rápido quando nada funciona

Colou o modelo, executou wg-quick up wg0, ele inicia - mas o ping falha. Lista de verificação nesta ordem:

• wg show: último handshake recente? Se "nunca" → handshake KO, verifique Endpoint, porta UDP no firewall do servidor (ufw status ou iptables -L).
• ip route no cliente: rota para a sub-rede VPN presente? Se não → AllowedIPs do cliente está errado.
• dig @9.9.9.9 ifconfig.me +short do cliente conectado: retorna o IP do VPS? Se não → MASQUERADE ausente no servidor, ou ip_forward = 0.
• tcpdump -i wg0 no servidor: vê pacotes a chegar? Se sim, mas nada sai de eth0 → regra FORWARD/MASQUERADE ausente.
• MTU: ping -M do -s 1400 1.1.1.1 do cliente. Se "Frag needed" → reduza MTU no wg0.conf para 1380 ou 1280. O nosso guia para corrigir o MTU do WireGuard detalha a medição sem fragmentação e o valor certo por tipo de ligação.

Se está a começar do zero e está preso, o guia de configuração passo a passo do Contabo percorre toda a instalação desde o SSH inicial.

Em produção: o que estes modelos omitem

São intencionalmente minimalistas. Para produção a longo prazo, planeie:

• Backup regular de /etc/wireguard/ (perder a chave do servidor = regenerar todos os clientes)
• Rotação de chaves a cada 12-18 meses (procedimento: gerar nova chave, adicionar peer paralelo, migrar clientes um a um, retirar peer antigo)
• Monitorização via Prometheus + wireguard_exporter (veja guia de monitorização)
• O que é uma Sub-rede? Subnetting e CIDR Explicados (2026)
• WireGuard no Android: Guia Completo de Configuração (2026)
• Fail2ban no SSH, não no WireGuard. O WireGuard nunca responde a um pacote não autenticado e não escreve nenhuma linha de tentativa falhada, por isso journalctl -u wg-quick@wg0 não dá ao fail2ban nada para detetar. Proteja antes a porta SSH.
• Limite de largura de banda por peer via tc (controlo de tráfego Linux) se um peer consumir toda a largura de banda

E acima de tudo: nunca comprometa um wg0.conf real num repositório, mesmo privado. Mantenha-os .gitignore'd ou encripte com age / sops.

Quando o WireGuard não é suficiente: V2Ray para países censurados

O WireGuard é excelente para casos de uso de privacidade padrão. No entanto, o WireGuard vanilla (incluindo NordLynx) é agora sistematicamente bloqueado pelo Grande Firewall da China e cada vez mais filtrado na Rússia e no Irão: o seu formato de handshake fixo é reconhecível por deep packet inspection.

Se o seu objetivo é contornar a censura ativa (China, Irão, Rússia), os modelos WireGuard não ajudarão por si só. Precisa de ofuscação: ou WireGuard + Cloak (camada de mascaramento TLS) ou uma mudança completa de protocolo para V2Ray VMess/VLESS com REALITY para China, Irão, Rússia. O protocolo REALITY do V2Ray torna o seu servidor indistinguível de um nó CDN da Microsoft - o estado da arte atual contra a inspeção profunda de pacotes do GFW em 2026.

Para ter o essencial à mão: a WireGuard Cheat Sheet gratuita (PDF de 5 páginas em inglês, download direto, sem registo) reúne as tabelas de keepalive e MTU, os comandos wg genkey/wg pubkey/wg genpsk e as quatro verificações de servidor numa linha a correr primeiro quando um túnel não passa tráfego. O WireGuard Self-Hosting Kit pago (9 USD, em inglês) acrescenta uma checklist de diagnóstico com 12 causas e 11 modelos de configuração.

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.

Indo mais fundo

Se quiser entender por que o WireGuard supera o OpenVPN com CPU igual, veja a nossa comparação técnica WireGuard vs OpenVPN (módulo de kernel vs espaço de utilizador).

E para a parte de prevenção de fugas, o guia de kill switch para Linux (iptables + systemd) mostra como garantir zero fuga mesmo quando o WireGuard falha.

Prefere um assistente visual em vez de blocos INI brutos? O nosso gerador de configuração WireGuard pega no IP do seu servidor, sub-rede e contagem de peers e gera um wg0.conf pronto a colar em menos de um minuto. E para verificar se o Contabo Cloud VPS 4 é mais barato do que o seu plano NordVPN atual ao longo de 2 anos, insira os números no nosso calculador de custos de VPN auto-hospedada.

Cada modelo acima é construído para funcionar num Contabo Cloud VPS 4 - espaço suficiente para um túnel de produção estável além de outros serviços auto-hospedados ao lado.