Porque pode a sua VPN WireGuard ficar lenta em viagens ao estrangeiro

Atualizado: 2 de novembro de 2026

Introdução

Muitos utilizadores ficam surpreendidos quando se ligam a partir de outro país ao servidor WireGuard do seu router GL.iNet e descobrem que a velocidade da Internet é bastante inferior à ligação gigabit simétrica de casa ou à ligação igualmente rápida do alojamento no estrangeiro, por exemplo, um Airbnb. Vários fatores podem contribuir para esta diferença de desempenho, incluindo o encaminhamento e o peering dos ISP, o congestionamento da rede, a capacidade de processamento do router e o comportamento das aplicações que comunicam através do túnel VPN.

O que é a latência e porque é importante?

A latência é o tempo que os dados demoram a viajar do dispositivo até ao servidor VPN e a regressar. É frequentemente medida em milissegundos (ms). Por exemplo, se o router GL.iNet no Vietname se ligar a um servidor VPN no Texas, o tempo de ida e volta (RTT) pode facilmente atingir 250-300 ms.

Uma latência elevada não reduz, por si só, a capacidade de encaminhamento de pacotes do WireGuard. Ao contrário do TCP, o transporte de dados do WireGuard, baseado em UDP, não utiliza confirmações nem janelas de congestionamento para regular a transmissão de pacotes de dados normais. Por exemplo, um túnel WireGuard com RTT de 300 ms pode, teoricamente, manter o mesmo débito de encaminhamento de pacotes que um com RTT de 3 ms, desde que a largura de banda disponível, a perda de pacotes e as capacidades de processamento sejam comparáveis.

As aplicações que comunicam através do túnel VPN utilizam frequentemente TCP ou QUIC, que dependem das informações de retorno do ponto terminal recetor. Encaminhar o tráfego através de um servidor VPN distante pode aumentar o RTT sentido por essas aplicações. Isto pode afetar o desempenho, mas não permite estabelecer se o estrangulamento está no comportamento do transporte, no percurso de rede ou no processamento do router.

O comportamento das aplicações também é importante. Abrir ficheiros numa pasta partilhada remota ou copiar muitos ficheiros pequenos pode implicar pedidos e respostas repetidos entre o dispositivo e o servidor. Cada ida e volta necessária acrescenta atraso, pelo que estas tarefas podem parecer lentas mesmo quando a ligação permite descarregar rapidamente um único ficheiro grande. Aumentar a janela de receção TCP não elimina estas esperas ao nível da aplicação.

A relação entre débito TCP e latência

Uma relação útil para compreender o débito TCP em ligações de elevada latência é o produto largura de banda-atraso (BDP):

Produto largura de banda-atraso = Débito x RTT

O BDP descreve a quantidade de dados que tem de permanecer em trânsito, ou seja, enviada mas ainda não confirmada, para manter um determinado débito numa ligação com um dado RTT. Contudo, esta relação, por si só, não estabelece o débito máximo alcançável nem identifica o fator limitante de uma ligação de rede específica.

Por exemplo, manter um débito TCP de 100 Mbps com um RTT de 288 ms exige aproximadamente 3.6 MB de dados em trânsito não confirmados, assumindo que o percurso de rede e os pontos terminais conseguem, de resto, suportar esse ritmo.

Eis algumas definições importantes:

• Janela de receção TCP (rwnd): A quantidade de dados adicionais que o dispositivo recetor anuncia poder aceitar, com base no espaço disponível na memória intermédia de receção.
• Janela de congestionamento TCP (cwnd): A quantidade de dados não confirmados que o emissor pode manter, de acordo com o seu algoritmo de controlo de congestionamento e as condições da rede.
• Débito: O ritmo efetivo a que os dados são transferidos com sucesso
• RTT (tempo de ida e volta): O tempo necessário para os dados viajarem entre os pontos terminais e para uma resposta regressar.

O limite efetivo de dados TCP pendentes do emissor é determinado pela menor das janelas de receção e de congestionamento, além de outras restrições. Esta distinção é importante: uma janela de receção suficientemente grande não garante um débito elevado se o controlo de congestionamento ou o percurso de rede impedir o emissor de manter dados pendentes em quantidade suficiente.

A perda de pacotes pode reduzir o débito TCP por exigir retransmissões e levar o emissor a reduzir a janela de congestionamento. Numa ligação de elevada latência, o retorno de informação e a recuperação podem demorar mais, pelo que uma janela de receção grande pode não bastar para manter transferências rápidas.

Um exemplo real de um membro do subreddit da GL.iNet

Um membro do subreddit GL.iNet no Vietname comunicou os seguintes resultados ao ligar-se ao seu servidor WireGuard doméstico no Texas, a funcionar num router GL.iNet Flint 2.

• Localização do servidor: Texas, Estados Unidos
  
  • Velocidades locais (fibra simétrica) 700 Mbps de download / 940 Mbps de upload
• Localização do cliente: Vietname
  
  • Velocidades locais (sem VPN): 455 Mbps de download / 634 Mbps de upload
    
  • Velocidades locais (com o cliente VPN WireGuard ativado): 47.3 Mbps de download / 12.1 Mbps de upload, ping de 288 ms

Lembre-se de que, ao descarregar através de um servidor VPN em casa, o débito máximo de download também depende da velocidade de upload da ligação doméstica à Internet.

Estas medições demonstram uma diferença substancial entre o desempenho da Internet local e o desempenho da ligação WireGuard internacional. Contudo, os testes não medem necessariamente percursos de rede equivalentes. Um teste local no Vietname pode ligar-se a um servidor próximo, enquanto o tráfego encaminhado pela VPN tem primeiro de atravessar a ligação internacional até ao Texas. Isto envolve diferentes redes de trânsito dos ISP, acordos de peering e possíveis pontos de congestionamento. Duas ligações internacionais com latência semelhante podem oferecer velocidades muito diferentes consoante a qualidade dos percursos. Embora a ligação VPN tenha indicado um RTT de aproximadamente 288 ms, essa medição, por si só, não demonstra que a latência fosse a principal causa da redução do débito. A perda de pacotes, o encaminhamento internacional ineficiente, o congestionamento ou outros fatores podem ter contribuído.

Comecemos por identificar alguns fatores comuns que podem afetar o débito da rede:

1. Variações de desempenho do ISP e congestionamento na vizinhança: O débito pode variar substancialmente com o congestionamento e a carga da rede.
2. Desempenho do Wi-Fi: Muito variável consoante o ambiente físico, as interferências de outros dispositivos sem fios, a capacidade do dispositivo cliente e a natureza inerentemente half-duplex do Wi-Fi, ao contrário do Ethernet full-duplex
   • Para uma explicação detalhada sobre o desempenho realista do Wi-Fi, leia: https://www.wiisfi.com/
3. Encaminhamento dos ISP e peering internacional: O tráfego entre países pode atravessar várias redes operadas de forma independente. Ligações de peering congestionadas, percursos ineficientes ou perda de pacotes podem reduzir substancialmente o débito, mesmo quando ambos os pontos terminais têm Internet local rápida. Dois percursos internacionais com RTT semelhantes podem oferecer velocidades muito diferentes.

O congestionamento do ISP local e as condições do encaminhamento internacional estão geralmente fora do controlo direto do utilizador, embora testar outros ISP ou percursos possa ajudar a identificar diferenças de desempenho. Um encaminhamento internacional deficiente ou peering congestionado são suspeitos frequentes quando ambos os pontos terminais têm Internet local rápida, mas o percurso de longa distância é lento. Um teste através de outro ISP, por exemplo num café, ou de um hotspot pode ajudar a perceber se a lentidão está no percurso. As limitações do Wi-Fi podem muitas vezes ser reduzidas usando ligações Ethernet por cabo sempre que possível. As limitações de processamento do router e os problemas de MTU também merecem investigação ao diagnosticar o débito VPN.

Em última análise, perceber porque uma ligação VPN internacional é lenta exige distinguir as limitações do percurso de rede, do router VPN e das aplicações que comunicam através do túnel.

Escalonamento da janela TCP para melhorar o desempenho

Originalmente, a janela de receção TCP estava limitada a cerca de 64 KB. O escalonamento da janela (RFC 7323) aumenta esse limite para cerca de 1 GiB, e os sistemas operativos modernos ajustam a janela automaticamente. Por exemplo, a definição de ajuste automático Normal documentada pela Microsoft pode representar janelas de receção de cerca de 16.8 MB. As ligações TCP modernas não estão, por isso, inerentemente limitadas a 64 KB.

Fonte: duckware.com/blog/how-windows-is-killing-internet-download-speeds

Como os limites da janela TCP interagem com o RTT

Numa ligação TCP com um limite fixo de dados pendentes, o teto aproximado do débito relacionado com a janela é:

Débito em bits por segundo ≈ Limite da janela em bytes × 8 ÷ RTT em segundos

Mantendo o limite da janela constante, um RTT superior produz um teto inferior relacionado com a janela. Os exemplos seguintes ilustram esta relação; não são previsões do débito VPN real.

Tetos teóricos relacionados com a janela (janela ÷ RTT), usando 1 MB = 1,000,000 bytes. São exemplos ilustrativos, não previsões do débito VPN real.

O débito real também depende do controlo de congestionamento, da perda de pacotes, da largura de banda disponível e dos limites de processamento. Várias ligações TCP podem, por vezes, alcançar um débito agregado superior, mas não existe um limiar universal de RTT acima do qual deixem de conseguir utilizar toda a largura de banda disponível.

No exemplo Vietname-Texas, uma hipotética ligação TCP única limitada a 2 MB de dados pendentes com um RTT de 288 ms teria um teto relacionado com a janela de aproximadamente 55.6 Mbps. A linha de 300 ms da tabela é ligeiramente inferior devido ao RTT maior. Contudo, isto não estabelece porque o utilizador mediu 47.3 Mbps.

Sem conhecer o número de ligações do teste, as janelas TCP reais e as condições da rede, não podemos determinar se o estrangulamento era um limite de janela, congestionamento, perda de pacotes, encaminhamento do ISP ou outra causa.

O que determina o tamanho da janela TCP?

Os tamanhos das janelas TCP pertencem a cada ligação e podem mudar durante a transferência de dados. Os valores dos exemplos acima não devem, por isso, ser tratados como definições fixas aplicáveis a todas as ligações do dispositivo.

O sistema operativo do dispositivo recetor gere a janela de receção. O tamanho depende de fatores como o espaço disponível na memória intermédia de receção, o ajuste automático e os limites do sistema operativo, as definições da aplicação e a rapidez com que esta consome os dados recebidos. Ao descarregar um ficheiro para o portátil, este anuncia a sua janela de receção ao servidor emissor. Ao carregar um ficheiro, é o servidor recetor que anuncia a sua janela ao portátil.

O emissor gere separadamente a sua janela de congestionamento de acordo com o algoritmo de controlo de congestionamento e as informações de retorno da rede. Isto pode limitar os dados pendentes mesmo quando o recetor anuncia uma janela grande. Numa configuração WireGuard típica entre routers, estas janelas TCP pertencem aos computadores e servidores que comunicam; não são uma definição única de tamanho da janela nos routers VPN.

Como verificar uma ligação real?

Para quem está familiarizado com análise de pacotes, o Wireshark permite visualizar a janela de receção TCP anunciada. Numa configuração entre routers, capture o tráfego no computador que realiza a transferência. Inicie a captura antes de estabelecer uma nova ligação TCP, para que o Wireshark registe o handshake inicial e a negociação do escalonamento da janela. Durante um download, examine uma confirmação TCP enviada pelo computador para essa transferência, expanda a secção Transmission Control Protocol e procure Calculated window size. Este valor mostra a janela de receção anunciada pelo computador nesse momento, com o escalonamento aplicado quando o Wireshark conhece o fator de escala negociado.

Esse valor pode mudar durante a transferência. Não revela diretamente a janela de congestionamento do emissor nem estabelece que a janela de receção está a limitar o desempenho. Verificar a definição de ajuste automático do sistema operativo também não indica a janela real que uma ligação específica está a anunciar nesse momento.

Outro exemplo real: velocidades superiores sem reduzir o ping

Noutro caso de assistência, investiguei uma ligação VPN Tailscale lenta. O Tailscale utiliza a encriptação WireGuard, mas as suas opções de retransmissão podem transportar os pacotes encriptados de forma diferente: os retransmissores DERP usam ligações TCP, enquanto os Tailscale Peer Relays usam UDP. Isto difere de uma ligação WireGuard autónoma, que normalmente envia os pacotes encriptados diretamente por UDP. Neste caso, ambos os retransmissores eram alojados autonomamente na mesma instância AWS Lightsail, pelo que a comparação era entre dois métodos de retransmissão alojados de forma privada e não com os servidores DERP públicos do Tailscale.

A ligação à Internet do cliente atingiu aproximadamente 83 Mbps no teste, enquanto a do servidor VPN apresentou uma velocidade de upload medida de aproximadamente 40.6 Mbps. Observaram-se as seguintes velocidades de download:

SQM significa Smart Queue Management, uma funcionalidade do router que gere filas de pacotes e reduz atrasos excessivos sob carga. Nesta comparação, o SQM foi ativado ou desativado no router de viagem do lado do cliente.

O SQM não é uma solução universal para velocidades VPN baixas. Quando identifica apenas um único fluxo de túnel encriptado, não consegue dar prioridade individual às ligações das aplicações ocultas no seu interior. Continua a poder gerir a fila de pacotes partilhada, mas isso só reduz o atraso na fila quando a acumulação excessiva de pacotes é um problema que pode resolver. Se não houver acumulação excessiva de pacotes que o SQM possa controlar de forma útil, definições de largura de banda desnecessariamente restritivas ou uma carga adicional de processamento podem reduzir o débito sem melhorar a capacidade de resposta.

A latência manteve-se praticamente igual, mas o retransmissor baseado em UDP proporcionou um débito substancialmente superior, com SQM ativado ou desativado. A maior melhoria acompanhou a mudança do método de retransmissão, não uma redução do ping ou a remoção do SQM.

Um possível fator é o transporte baseado em TCP do DERP. Cada dispositivo Tailscale liga-se ao retransmissor DERP por TCP, pelo que os pacotes encriptados passam por ligações TCP separadas de cada lado do retransmissor. Várias ligações de aplicações dentro do túnel podem partilhar estas ligações TCP externas. Se houver perda de dados numa ligação TCP externa, os dados seguintes poderão ter de aguardar a retransmissão antes de serem entregues, atrasando potencialmente várias aplicações em simultâneo. Um Peer Relay baseado em UDP evita esta camada adicional de transporte TCP ordenado, embora as aplicações TCP dentro do túnel continuem a usar as suas próprias confirmações e controlo de congestionamento.

Como ambos os retransmissores funcionavam na mesma instância, o anfitrião e a localização mantiveram-se constantes. Isto reforça a interpretação de que o transporte ou a implementação do retransmissor contribuiu para a melhoria, em vez de simplesmente o aproximar dos utilizadores. Contudo, usar o mesmo anfitrião não garante percursos ou condições de rede idênticos, pelo que a comparação não isola TCP face a UDP como causa única.

Estas são observações de um único caso de assistência, não valores de desempenho garantidos. Demonstram, contudo, porque a latência, por si só, não basta para prever a velocidade da VPN.

Conclusão

Espero que este artigo tenha ajudado a compreender melhor porque as velocidades de download e upload em ligações VPN WireGuard de longa distância podem ser substancialmente inferiores às velocidades da Internet disponíveis em qualquer dos pontos terminais. A distinção mais importante é que o próprio WireGuard não impõe um teto de débito dependente do RTT. O seu transporte de dados baseado em UDP não implementa janelas de congestionamento, confirmações nem retransmissões semelhantes às do TCP para pacotes de dados normais.

No entanto, as aplicações TCP e QUIC que comunicam pelo túnel continuam sujeitas aos seus próprios mecanismos de controlo de congestionamento e fiabilidade. Um RTT superior aumenta a quantidade de dados pendentes necessária para manter um dado débito. Várias ligações podem melhorar o desempenho agregado, mas nem o RTT nem o número de ligações, por si só, determina a velocidade alcançável. O desempenho real depende também da perda de pacotes, do congestionamento, do encaminhamento e peering dos ISP, da largura de banda disponível, da configuração MTU e da capacidade de processamento do router VPN.

Numa configuração WireGuard típica entre routers GL.iNet, as ligações TCP são estabelecidas entre os dispositivos finais e os servidores de destino. Os routers VPN encriptam, desencriptam e encaminham pacotes sem controlar diretamente as janelas de receção TCP dessas ligações de ponta a ponta. Embora os limites do hardware do router possam afetar o débito de pacotes encriptados, não devem ser confundidos com limitações da janela de receção TCP.

Ao diagnosticar uma ligação WireGuard internacional lenta, comece por testar a ligação à Internet em cada local, usando Ethernet por cabo sempre que possível. Verifique se o desempenho da VPN muda consoante a hora do dia ou ao usar outra ligação à Internet, como um hotspot móvel. Estas comparações podem ajudar a localizar a lentidão, embora possam ser necessários testes mais detalhados para identificar a causa. Uma latência elevada pode contribuir para aplicações mais lentas, mas não deve ser automaticamente considerada a única explicação para uma VPN lenta.

No futuro, espero experimentar retransmissores UDP em locais estratégicos para perceber se percursos alternativos podem melhorar o desempenho da VPN WireGuard entre os EUA e a Ásia.

Para mais informações e sugestões de resolução de problemas e para compreender a sua configuração de VPN WireGuard, consulte a seguinte publicação no fórum da GL.iNet: https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502