Ferramenta de Ping Global
Usuários de uma região reclamam que o site está lento enquanto o resto está ok. Esta ferramenta dispara 5 probes HTTP cronometrados de 10 pontos geográficos para você ver exatamente onde começam latência, jitter ou perda de pacote — antes de abrir um ticket com a sua CDN.
Pronto para testar a performance da rede
O que é Ping e por que é importante?
O ping é uma utilidade fundamental para diagnosticar conectividade de rede. Mede o tempo de ida e volta (RTT) para um destino e é essencial para identificar gargalos regionais que afetam a experiência do usuário.
Como interpretar os resultados
A tabela mostra cinco valores por região. Leia como grupo — isoladamente, qualquer número engana.
- Latência mínima é o piso físico daquela região. Se São Paulo mostra mín 210ms para um servidor em Frankfurt, é basicamente velocidade da luz por fibra mais um ou dois roteadores. Não dá para baixar.
- Latência média é o que o usuário sente. Use para ranquear regiões e identificar outliers.
- Latência máxima expõe a cauda. Média 80ms com máx 800ms significa alguém esperando quase um segundo de vez em quando — GC, cold start de container ou link saturado.
- Jitter é o desvio padrão entre amostras. VoIP e vídeo degradam com jitter acima de 30ms mesmo com média boa.
- Perda de pacotes acima de 1% já é perceptível no TCP (retransmissões e backoff de congestionamento); acima de 5% é efetivamente queda para real-time.
Problemas comuns e como resolver
Latência alta em um continente específico
Normalmente é falta de PoP. Se São Paulo reporta 240ms enquanto EUA/EU está abaixo de 60ms, sua CDN provavelmente não tem borda na América Latina, ou a origem é single-region. Habilite a região de SA na CDN, ou ponha um provedor anycast na frente da origem.
Jitter em VMs de nuvem
Instâncias burstable (AWS t-family, GCP e2) compartilham créditos de CPU com vizinhos barulhentos. Sob carga sustentada o scheduler adiciona jitter. Migre o workload para uma instância não-burstable ou pin de CPU para serviços críticos.
Perda intermitente em horário de pico
Um link de trânsito upstream saturado. A correção normalmente não é do seu lado — abra um ticket com o provedor citando a perda com timestamp desta ferramenta. Se repete todo dia no mesmo horário, é congestionamento, não falha.
Ping HTTP ok, mas carregamento péssimo
A rede está fine — o gargalo agora é TTFB (origem pensando) ou o waterfall (muitas requisições seriais). Troque para uma ferramenta de speed e analise a linha do tempo de recursos.
Próximos passos
Um ping pontual conta o estado da rede agora. Não diz se o pico de 400ms de ontem à noite foi um evento isolado ou um padrão. Recomendações:
- Rode o teste em horários diferentes — congestionamento tem agenda.
- Rode um traceroute da região pior para confirmar qual hop introduz o atraso.
- Configure probes regionais contínuas no FlashMon.app para que regressões gerem alerta em vez de reclamação de usuário.
Monitore latência 24/7
Acompanhe a performance de rede da sua aplicação em tempo real com alertas de jitter e latência.
Perguntas Frequentes
Ping mede o tempo de ida e volta (RTT) para um pacote de dados viajar de uma origem a um host de destino e retornar. O nome vem da terminologia de sonar. Na rede, ping menor significa comunicação mais rápida entre cliente e servidor. Nossa ferramenta realiza medições via HTTP — já que ICMP (ping bruto) exige privilégios especiais de servidor — o que fornece uma medida realista do tempo de resposta de aplicação experimentado por usuários reais visitando seu site.
Os parâmetros de latência dependem do caso de uso. Para navegação web: abaixo de 100ms é excelente, 100–300ms é aceitável, acima de 300ms começa a parecer lento. Para jogos online: abaixo de 50ms é ideal, 50–150ms é jogável, acima de 150ms causa lag perceptível. Para aplicações financeiras e sistemas em tempo real, abaixo de 10ms é crítico. A distância geográfica entre usuário e servidor é o maior fator determinante.
A distância física é o fator principal — dados viajam a cerca de dois terços da velocidade da luz por cabos de fibra óptica, então uma ida e volta de Nova York a Sydney (aproximadamente 16.000 km) leva pelo menos 80ms só de atraso de propagação. Outros fatores incluem o número de hops de rede (roteadores) entre origem e destino, congestionamento em pontos de troca de internet, decisões de roteamento de ISPs e a posição geográfica do servidor em relação à base de usuários.
Esses termos são relacionados mas distintos. Ping é a ação de enviar um pacote de teste; latência é o resultado medido do tempo de ida e volta. Jitter é a variação na latência entre medições consecutivas — jitter baixo significa performance consistente, jitter alto significa atrasos imprevisíveis que degradam aplicações em tempo real como videochamadas e jogos. Um servidor pode ter média de 80ms (latência aceitável) mas com ±60ms de jitter (instabilidade ruim).
Um timeout ocorre quando uma requisição de ping não recebe resposta dentro do tempo permitido (normalmente 8–10 segundos). Isso pode significar que o host está offline ou inacessível, o firewall do servidor está bloqueando requisições, o hostname não resolve via DNS, ou congestionamento de rede causou perda do pacote. Timeouts ocasionais (abaixo de 5%) são normais em conexões de internet. Timeouts consistentes de múltiplas localizações indicam uma queda real, não um problema local.
As estratégias mais eficazes são: implantar uma CDN para servir conteúdo em cache de servidores próximos aos usuários, escolher uma região de hospedagem perto da sua base principal de usuários, habilitar HTTP/2 ou HTTP/3 para reduzir overhead de conexão, implementar cache agressivo para minimizar processamento do servidor, e usar um provedor de DNS global com roteamento anycast. O FlashMon monitora continuamente a latência de 10 localizações globais para medir o impacto real de cada otimização e alerta quando há picos inesperados.
Speed tests do provedor medem o primeiro hop — geralmente um servidor dentro da rede do próprio ISP, a poucos milissegundos. Usuários reais atravessam várias redes até chegar à sua origem: o ISP deles, um trânsito, um ponto de troca, o seu ISP, sua borda e enfim seu servidor. Cada hop soma latência e potencial congestionamento. Os números desta ferramenta refletem esse caminho real. Se uma região é bem mais alta que as outras, o problema quase sempre está no roteamento entre ASes, não no seu servidor.
Para tráfego TCP (HTTP, HTTPS), jitter abaixo de 30ms quase nunca é percebido. Para tráfego UDP em tempo real — voz, vídeo, games — jitter acima de 30ms já introduz artefatos audíveis, e acima de 50ms torna uma chamada VoIP desconfortável. Um servidor com média 80ms e ±5ms de jitter é muito melhor para o usuário que um com 60ms e ±40ms, porque o que parece rapidez é consistência.
Três causas prováveis, em ordem. Primeiro, um firewall ou WAF regional está bloqueando a faixa de IP da nossa probe — comum com "Under Attack Mode" da Cloudflare ou bloqueios por país. Segundo, um trânsito entre aquela região e sua origem tem rota quebrada (BGP leak, cabo submarino rompido) — confira a página de status do provedor. Terceiro, sua origem ou CDN tem um nó de borda falho naquela geografia. Rode um traceroute antes de assumir queda global.
Contra quem o seu DNS resolver. Se você está atrás de uma CDN (Cloudflare, Fastly, CloudFront), cada região vai bater no edge mais próximo e a latência reflete distância usuário-borda — a CDN está fazendo o trabalho dela. Para medir especificamente a latência da origem, aponte para um hostname que bata direto nela, por exemplo origin.seudominio.com. Latência baixa na CDN com origem alta é padrão esperado e saudável.