MTU do WireGuard: o valor certo e como corrigir o túnel travado (2026)

Aviso de afiliação — Este artigo contém links de afiliado da Contabo. Se contratar um VPS através deles, ganhamos uma comissão sem custo extra para si. Cada comando e valor abaixo está documentado a partir de fontes oficiais do WireGuard e escrito para ser reproduzível na sua própria máquina.

O seu túnel WireGuard diz «ligado». O wg show mostra um handshake recente, o ping ao servidor responde na hora — e ainda assim as páginas web giram sem fim, o SSH congela a meio da transferência, e os downloads grandes morrem após poucos kilobytes. Nove em cada dez vezes o culpado é a MTU: o tamanho máximo de pacote que o seu túnel consegue transportar. Este guia explica por que a MTU quebra um túnel que de resto parece perfeitamente saudável, como medir o valor certo para a sua ligação, e exatamente o que ajustar.

Se o seu handshake nunca conclui à partida, a MTU ainda não é o seu problema — comece pela lista completa de correções do handshake do WireGuard e volte aqui quando o túnel estiver de pé mas a travar.

O que é a MTU e por que o WireGuard se importa

A MTU (Maximum Transmission Unit) é o maior pacote, em bytes, que uma interface enviará sem o fragmentar. Numa ligação Ethernet ou de fibra normal são 1500 bytes. O WireGuard envolve cada um dos seus pacotes dentro do seu próprio pacote UDP, e esse invólucro custa espaço:

• Cabeçalho externo IPv4: 20 bytes
• Cabeçalho externo IPv6: 40 bytes
• Cabeçalho UDP: 8 bytes
• Cabeçalho de dados do WireGuard: 32 bytes

Então um pacote WireGuard sobre IPv6 precisa de cerca de 80 bytes de overhead. Tire-os de um caminho de 1500 bytes e sobram cerca de 1420 bytes dentro do túnel — é exatamente por isso que o WireGuard define a sua interface em 1420 por padrão. Confirme o valor padrão em qualquer túnel ativo:

ip link show wg0
# ... mtu 1420 ...

Os problemas começam quando o caminho entre si e o seu servidor transporta menos de 1500 bytes. Então 1420 é grande demais, o seu tráfego real transborda, e os pacotes em excesso desaparecem em silêncio.

Por que o túnel responde ao ping mas as páginas travam

É o sintoma característico, e confunde toda a gente da primeira vez:

• Um ping é minúsculo — cabe em qualquer MTU, então funciona e convence-o de que o túnel está bem.
• Uma consulta DNS e o handshake TCP de três vias também são minúsculos, então as ligações começam.
• O primeiro pacote de tamanho completo — uma página web, uma imagem, um pedaço de ficheiro — excede a MTU do caminho e é descartado.

Normalmente um router devolveria uma mensagem ICMP «fragmentação necessária» dizendo ao emissor para usar pacotes mais pequenos (é a descoberta da MTU do caminho, PMTUD). Mas o ICMP está filtrado numa fatia enorme da internet, então essa mensagem nunca chega. O emissor continua a disparar pacotes sobredimensionados para um buraco negro. Isso é um buraco negro de PMTU, e por isso um túnel pode parecer vivo e ainda assim ser inútil para o trabalho real.

A mesma lógica explica os relatos de «ligado mas sem internet»: o pequeno tráfego de controlo passa, os dados grandes não. Se já descartou o encaminhamento IP e a regra de masquerade (cobertos no guia de instalação Contabo + WireGuard), a MTU é o próximo suspeito.

Meça a MTU certa para a sua ligação

Não copie um número de um fórum. Meça o seu próprio caminho com um ping sem fragmentação para o IP público real do servidor (não o seu IP de túnel), reduzindo a carga útil até os pacotes passarem:

# -M do = não fragmentar, -s = tamanho da carga útil
ping -M do -s 1472 IP_PUBLICO_SERVIDOR

A carga útil -s 1472 mais 28 bytes de cabeçalho ICMP+IP dá 1500. Se falhar com «message too long» ou sem resposta, baixe e tente de novo:

ping -M do -s 1464 IP_PUBLICO_SERVIDOR
ping -M do -s 1400 IP_PUBLICO_SERVIDOR
ping -M do -s 1372 IP_PUBLICO_SERVIDOR

No Windows o equivalente é ping -f -l 1472 IP_PUBLICO_SERVIDOR; no macOS, ping -D -s 1472 IP_PUBLICO_SERVIDOR.

Pegue a maior carga útil que passa, e faça a conta:

1. Maior carga útil que passa + 28 = a sua MTU do caminho.
2. MTU do caminho − 80 = uma MTU do WireGuard segura (use 80 para o caso IPv6; caminhos só IPv4 podem usar −60, mas −80 é a escolha universal segura).

Exemplo resolvido. Suponha que -s 1400 seja o maior que responde e -s 1408 falhe. MTU do caminho = 1400 + 28 = 1428. MTU do WireGuard = 1428 − 80 = 1348 → arredonde para um 1340 limpo.

Defina a MTU do WireGuard

Adicione uma linha ao bloco [Interface] no lado limitado (normalmente o cliente) e reinicie o túnel:

[Interface]
PrivateKey = ...
Address = 10.66.66.2/32
MTU = 1340

sudo wg-quick down wg0 && sudo wg-quick up wg0
# ou, sem um reinício completo:
sudo ip link set dev wg0 mtu 1340

Teste de novo de imediato: carregue uma página pesada, lance uma transferência de ficheiro, ou faça um ping sem fragmentação através do túnel para o IP de túnel do servidor. Se o tráfego grande agora flui, tem o seu valor. Se constrói configurações do zero, os modelos de configuração prontos a usar incluem a linha MTU no sítio certo para cada plataforma.

Valores sensatos por tipo de ligação

Quando não pode medir — ou quer um ponto de partida seguro — estes valores de referência documentados cobrem a maioria das ligações reais:

1280 é o valor que todo caminho com IPv6 é obrigado a transportar, então é o recurso seguro quando nada mais funciona: perde um pouco de eficiência mas o travamento desaparece. Prefira sempre um valor medido quando puder obter um — 1280 deixa desempenho na mesa num caminho limpo de 1500 bytes.

Quando a MTU não é a resposta

Baixar a MTU é a correção quando os pacotes pequenos passam e os grandes não. Se nada flui depois do handshake, o problema está noutro lado — verifique, por ordem:

• net.ipv4.ip_forward = 1 e a regra MASQUERADE no servidor.
• Os AllowedIPs do lado servidor sem sobreposição entre pares.
• Um PersistentKeepalive = 25 em qualquer par atrás de NAT.

Os três são percorridos no guia de resolução de problemas do handshake. E se só precisa de certas apps no túnel, baixar a MTU combina-se naturalmente com um encaminhamento em split-tunnel para que o grosso do seu tráfego evite por completo o overhead do túnel.

Uma ligação limpa torna a MTU previsível

Metade da dor de MTU vem de um caminho desarrumado: duplo NAT, um router doméstico instável, um túnel empilhado sobre um túnel. Um VPS com um IPv4 público limpo dá-lhe um único salto bem-comportado, onde o valor padrão de 1420 normalmente funciona sozinho. Um Contabo VPS S a 4,99 €/mês dá-lhe root completo e um IP público sem firewall do fornecedor para combater — exatamente as condições em que a descoberta da MTU do caminho se comporta bem. Siga a instalação passo a passo Contabo + WireGuard, e se ainda está a escolher um fornecedor, compare as opções no guia Contabo vs Hetzner vs OVH.

Para aprofundar

• Handshake do WireGuard não conclui: a lista completa de correções
• Que porta o WireGuard usa e como abri-la
• Modelos de configuração WireGuard prontos a usar 2026
• VPN auto-hospedada na Contabo: guia completo WireGuard 2026
• VPN de túnel dividido com tabelas de roteamento
• Glossário de VPN auto-hospedada — AllowedIPs, MTU, NAT explicados

Fontes e referências:

• Whitepaper do WireGuard — Jason A. Donenfeld
• Quickstart do WireGuard e documentação wg-quick
• Arch Wiki — WireGuard (notas de MTU)
• RFC 8200 — MTU mínimo IPv6 de 1280

Publicado em 2026-06-24. Os números de overhead vêm dos cabeçalhos do protocolo WireGuard; o método de medição é a descoberta padrão da MTU do caminho. As suas condições de ligação diferem — confirme sempre com um ping sem fragmentação antes de fixar um valor.

Lembrete: executar o WireGuard e auto-hospedar uma VPN é legal na UE, nos EUA, no Canadá e na maioria dos países democráticos. A VPNSmith publica este conteúdo para fins educativos.