Muitos iniciantes confundem banda e tráfego:

Já temos uma solução de monitoramento e alertas com Prometheus + Grafana, que é um monitoramento profissional mais completo. O que este artigo recomenda é uma abordagem mais leve: primeiro ter clareza do tráfego mensal, depois decidir se vale implantar um sistema maior.

Minha recomendação é simples:

1. Instalar o vnStat em todos os VPS para registrar o tráfego diário e mensal a longo prazo.
2. Quando suspeitar que o tráfego aumentou de repente, usar o nload para ver a velocidade em tempo real.
3. Quando ainda não tiver certeza de quem está consumindo tráfego, usar o iftop para encontrar a origem da conexão.
4. Configurar alertas em dois níveis, em 80% e 90% do tráfego mensal.
5. Se for um servidor em nuvem com cobrança por uso, adicionar também alertas de orçamento e uma política de limite máximo.

As vantagens são baixo custo, baixo uso de recursos e um caminho de diagnóstico claro. Até uma instância pequena de 1 núcleo e 512MB consegue rodar, e você não precisa implantar uma grande pilha de monitoramento só para acompanhar o tráfego.

Primeiro veja como se chama sua interface de rede pública:

ip -br addr

Resultados comuns podem ser:

lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             203.0.113.10/24
ens3             UP             203.0.113.10/24

Os exemplos a seguir assumem que a interface é eth0. Se sua máquina mostrar ens3, enp1s0 ou outro nome, basta substituir eth0 nos comandos.

Debian / Ubuntu:

sudo apt update
sudo apt install -y vnstat
sudo systemctl enable --now vnstat

AlmaLinux / Rocky Linux / Fedora:

sudo dnf install -y vnstat
sudo systemctl enable --now vnstat

Após a inicialização, consulte:

vnstat -i eth0
vnstat -d -i eth0
vnstat -m -i eth0

Você verá algo parecido com:

rx      /      tx      /     total
1.12 TiB /  340 GiB    /   1.45 TiB

Dois detalhes a observar aqui:

• rx é tráfego de entrada, tx é tráfego de saída; cada provedor tem sua própria regra de cobrança: alguns contam só a saída, outros contam as duas direções.
• Logo após instalar o vnStat não há dados históricos; normalmente é preciso esperar de alguns minutos a algumas horas para ter estatísticas estáveis.

Se seu plano é de 3TB de tráfego mensal, recomendo calcular de forma conservadora: somar tanto a entrada quanto a saída. Assim, mesmo que a regra do provedor seja mais flexível, você não subestima o risco.

Instalar:

sudo apt install -y nload

Executar:

nload eth0

Ele mostra a velocidade atual de entrada/saída. É útil para responder perguntas como:

• O site está sendo martelado por rastreadores?
• Uma tarefa de backup ainda está enviando dados?
• Algum contêiner Docker está sincronizando sem parar?
• Um proxy ou serviço de download está saturando a saída?

Se você só vê tráfego mensal anômalo, mas o nload atual não mostra velocidade evidente, o problema pode já ter passado, e você precisa verificar logs, tarefas agendadas ou registros históricos de backup.

Instalar:

sudo apt install -y iftop

Ao executar, recomendo adicionar -n para evitar que consultas reversas de DNS deixem a interface lenta:

sudo iftop -n -i eth0

Você verá quais IPs das conexões atuais mais enviam/recebem. Julgamentos comuns:

• Muitos IPs desconhecidos acessando 80/443: podem ser rastreadores, ataques CC, hotlinking ou abuso de API.
• Um único endereço interno/de armazenamento de objetos com tráfego muito alto: podem ser backups, sincronização ou download de imagens.
• Algum IP estrangeiro ocupando a saída por muito tempo: verifique se há tarefas de proxy, download, transcodificação ou download de modelos de IA.

Se descobrir que o site está sob ataque, consulte O que fazer quando um site em VPS sofre ataques CC. Se logs, imagens ou volumes do Docker estiverem descontrolados, leia também Diagnóstico de Docker enchendo o disco; muitas vezes problemas de disco e tráfego aparecem juntos.

O script abaixo é adequado para cenários mínimos: roda uma vez por dia, emite warning ao passar de 80% e critical ao passar de 90%. Você pode enviar a saída para e-mail, Telegram Bot, Webhook do WeCom ou seu próprio sistema de monitoramento.

Criar o script:

sudo nano /usr/local/bin/vps-traffic-alert.sh

Preencher:

#!/usr/bin/env bash
set -euo pipefail

IFACE="eth0"
LIMIT_GB="3000"
WARN_PERCENT="80"
CRIT_PERCENT="90"

MONTH_TOTAL_GB=$(vnstat -i "$IFACE" --oneline b | awk -F';' '{print $11}' | awk '{print $1}')
USED_PERCENT=$(awk -v used="$MONTH_TOTAL_GB" -v limit="$LIMIT_GB" 'BEGIN { printf "%.0f", used / limit * 100 }')

MESSAGE="VPS traffic usage: ${MONTH_TOTAL_GB}GB / ${LIMIT_GB}GB (${USED_PERCENT}%) on ${IFACE}"

if [ "$USED_PERCENT" -ge "$CRIT_PERCENT" ]; then
  echo "CRITICAL: $MESSAGE"
  exit 2
fi

if [ "$USED_PERCENT" -ge "$WARN_PERCENT" ]; then
  echo "WARNING: $MESSAGE"
  exit 1
fi

echo "OK: $MESSAGE"

Dar permissão e testar:

sudo chmod +x /usr/local/bin/vps-traffic-alert.sh
/usr/local/bin/vps-traffic-alert.sh

Depois crie um systemd timer ou cron. Exemplo simples de cron:

sudo crontab -e

Verificar uma vez por dia às 9 da manhã:

0 9 * * * /usr/local/bin/vps-traffic-alert.sh >> /var/log/vps-traffic-alert.log 2>&1

Se seu plano é de 1TB, altere LIMIT_GB="3000" para LIMIT_GB="1000". Se o provedor conta apenas o tráfego de saída, você pode modificar ainda mais o script para ler apenas tx, mas na fase de iniciante recomendo olhar primeiro o total de forma conservadora.

Nas seguintes situações, não pense apenas em limpar o tráfego:

1. Ultrapassar 70% do plano por dois meses consecutivos significa que o crescimento já não é ocasional.
2. Ter que parar serviços manualmente todo fim de mês significa que o plano não corresponde ao negócio.
3. O provedor limita diretamente para 1Mbps após ultrapassar o limite, afetando a disponibilidade do serviço online.
4. Seu tráfego vem principalmente de arquivos estáticos, imagens ou pacotes de download; você deveria considerar armazenamento de objetos ou CDN.
5. Seu negócio é streaming, sites de download ou distribuição de arquivos grandes; você deveria priorizar a compra de um plano de grande tráfego em vez de uma instância pequena comum.

Se você está se perguntando por que o tráfego de saída é caro, leia Explicação do custo do tráfego de saída em VPS internacionais. Se você usa um servidor em nuvem com cobrança por uso, não deixe de ler Como evitar faturas descontroladas em servidores em nuvem com cobrança por uso.

Equívoco 1: Se o provedor diz tráfego ilimitado, não precisa monitorar.

Muitos "tráfego ilimitado" ainda têm cláusulas de uso justo, e após ultrapassar certo limite oculto podem limitar a velocidade ou pedir upgrade. Também temos uma explicação dedicada: O tráfego de um VPS ilimitado é realmente ilimitado?.

Equívoco 2: Olhar só o painel, não as estatísticas locais do servidor.

O painel do provedor é a referência final, mas pode ter atraso; as estatísticas locais detectam anomalias mais rápido. Quando os dois dados não coincidirem, prevalece a fatura do provedor, mas use os dados locais para os alertas.

Equívoco 3: Reinstalar o sistema assim que vê tráfego alto.

Primeiro use iftop, os logs do Nginx e os logs do Docker para localizar a origem. Reinstalar perde evidências e pode não resolver a causa raiz.

Equívoco 4: Monitorar apenas CPU e memória.

Muitos sites pequenos caem não por falta de CPU, mas porque a banda está sendo martelada, o tráfego acabou ou a saída está limitada. O monitoramento de tráfego deve fazer parte da inspeção básica junto com disco, certificados e status dos serviços.

• Usar ip -br addr para encontrar o nome da interface de rede pública.
• Instalar e habilitar o vnStat.
• Verificar vnstat -m -i eth0 semanalmente.
• Instalar o nload para ver a velocidade em tempo real quando houver anomalias.
• Instalar o iftop para encontrar a origem das conexões quando houver anomalias.
• Configurar limites de alerta de 80% e 90% conforme o plano.
• Quando o tráfego mensal ultrapassar 70% de forma consistente, considerar upgrade, migração, adicionar CDN ou separar recursos estáticos.

O monitoramento de tráfego VPS não precisa de uma plataforma complexa desde o início. Para a maioria dos sites pessoais, equipes pequenas e serviços auto-hospedados, o vnStat + nload + iftop + 一个阈值脚本 já resolve 80% do problema.

O ponto realmente crucial é: não espere o provedor limitar a velocidade ou a fatura chegar para começar a investigar. Basta saber quanto você usou neste mês, de onde vem o tráfego anômalo e quando os limites serão acionados, para decidir com antecedência se deve limitar a velocidade, adicionar cache, migrar recursos estáticos ou trocar para um plano VPS mais adequado.