Tutoriais de VPS
Otimização de rede em VPS na prática (2026): como reduzir latência, jitter e perda de pacotes? Do diagnóstico ao ajuste
"A rede está lenta" não significa necessariamente pouca largura de banda; muitas vezes é perda de pacotes, jitter, acúmulo em filas ou incompatibilidade de MTU/MSS. Este artigo segue uma ordem prática: primeiro use ping/mtr/iperf3 para distinguir o tipo de problema e depois aplique otimizações reversíveis em BBR+FQ, DNS, MTU/MSS e buffers TCP; cada etapa traz um método de verificação para evitar ajustes às cegas.
Muitas pessoas dizem "a rede do VPS está lenta" e a primeira reação é: a largura de banda é pequena demais.
Mas o que vejo com mais frequência é:
- Perda de pacotes (mesmo 1%-2% incomoda muito)
- Jitter alto, digitar via SSH fica instável
- Acúmulo em filas (bufferbloat): o teste de velocidade parece bom, mas a interação real trava
- Incompatibilidade de MTU/MSS, HTTPS/downloads travam sem motivo aparente
Este artigo não é "cole um monte de sysctl e pronto". Escrevo na ordem prática: primeiro diagnosticar, depois otimizar; cada etapa pode ser verificada e revertida.
curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com
dnsalto: resolva o DNS primeiroconnectalto: latência do enlace/perda de pacotes/desvio de rotattfbalto: o serviço do outro lado está lento (não necessariamente é a rede do seu VPS)
ping -c 50 1.1.1.1
ping -c 50 8.8.8.8
No Debian/Ubuntu, instale primeiro:
sudo apt-get update && sudo apt-get install -y mtr
Teste da sua máquina local para o VPS:
sudo mtr -rwzc 200 <VPS_IP>
Do VPS para um site de destino (por exemplo, um site que você acessa com frequência):
sudo mtr -rwzc 200 example.com
Como interpretar (com estas duas regras basta):
- A perda de pacotes começa em um salto e todos os saltos seguintes também perdem pacotes: esse trecho do enlace é mais suspeito
- Um salto intermediário mostra muita perda de pacotes, mas os seguintes não: muitas vezes esse roteador apenas limita ICMP, não é perda real
Debian/Ubuntu:
sudo apt-get update && sudo apt-get install -y iperf3
Você precisa de um servidor iperf3 (pode ser outro VPS seu).
# client
iperf3 -c <SERVER_IP> -t 15
iperf3 -c <SERVER_IP> -P 4 -t 15
Baixo em thread única e alto em múltiplas threads geralmente indica que você é mais afetado por "latência + controle de congestionamento" do que por "largura de banda não fornecida".
Para uma rota de diagnóstico mais completa, leia diretamente este artigo (primeiro atribua o problema a uma etapa específica):
Se você tem um enlace transfronteiriço com latência alta, o BBR costuma ser "o ganho de velocidade mais barato".
O tutorial completo de BBR já existe no site, então não repito aqui:
Basta lembrar de uma combinação:
tcp_congestion_control=bbrdefault_qdisc=fq
Verificação:
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
Sintomas típicos:
- o speedtest parece bom
- mas abrir páginas web, SSH e chamadas de API simplesmente "engasga"
Você pode fazer ping enquanto baixa algo para ver se a latência dispara de repente:
# 终端 A：持续 ping
ping 1.1.1.1
# 终端 B：随便跑个大下载/同步
# 例如 curl/wget/apt update 等
Se, ao iniciar o download, a latência do ping salta de 30ms para 300ms+, é um problema típico de acúmulo em filas.
fq costuma melhorar bastante esse tipo de travamento interativo.
Primeiro veja qual DNS você está usando agora:
cat /etc/resolv.conf
Verifique o tempo de resolução DNS (no Debian/Ubuntu, instale primeiro):
sudo apt-get update && sudo apt-get install -y dnsutils
/usr/bin/time -f "DNS time: %e s" dig +tries=1 +time=2 google.com @1.1.1.1
Você pode trocar temporariamente para Cloudflare/Google (o método exato depende de como seu ambiente é gerenciado):
- IPv4:
1.1.1.1/8.8.8.8 - IPv6:
2606:4700:4700::1111/2001:4860:4860::8888
Sintomas:
- Arquivos pequenos não dão problema
- Assim que é HTTPS ou um pacote um pouco maior, trava
Teste o Path MTU:
# 1472 = 1500 - 28
ping -c 3 -M do -s 1472 1.1.1.1
# 不通就逐步减小
ping -c 3 -M do -s 1452 1.1.1.1
Para uma solução de emergência, use MSS clamp (não é cura definitiva, mas muitas vezes melhora na hora):
sudo iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Em enlaces de alta latência, aumentar adequadamente os buffers pode melhorar a vazão; mas ajustar às cegas só torna os problemas mais difíceis de diagnosticar.
Princípio recomendado:
- Primeiro use o iperf3 para confirmar que "a largura de banda não está sendo saturada"
- Depois considere ajustar
rmem/wmem
Você pode anotar primeiro os valores atuais (para facilitar a reversão):
sysctl net.core.rmem_max net.core.wmem_max
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem
Parte da lentidão não é de rede de jeito nenhum.
Rode primeiro estes comandos; muitas vezes dá para ver de cara:
uptime
free -h
df -hT
- CPU no máximo: tudo fica lento
- Memória esgotada: começa o swap/dispara o OOM, e parece que "a rede ficou lenta de repente"
- Disco cheio: não dá para gravar, os serviços falham de várias formas
Para diagnóstico relacionado a CPU, leia diretamente este artigo:
Para apagar incêndio relacionado a disco, leia este:
Sugiro seguir esta ordem (cada etapa pode ser revertida):
curl -wdistinguir DNS/enlace/TTFBping/mtr/iperf3identificar o tipo de problema- BBR + FQ (mais vantajoso)
- Otimização de DNS
- Solução de problemas de MTU/MSS
- Mexer nos buffers TCP só quando necessário
Um último lembrete:
Se o que você mede é "congestionamento no horário de pico/desvio de rota", por mais que ajuste o sysctl, não vai salvar o enlace físico.
Nesse momento, as soluções mais realistas são: trocar de região, trocar de rota ou usar um CDN.