Quão rápido é Gcore a partir da sua casa?

A maioria dos sites de “ping na nuvem” e todos os looking glasses dos provedores medem a partir dos servidores deles, em data centers com trânsito de primeira. Isso mostra quão rápido um data center chega a outro. Não diz nada sobre o que você sente de verdade: a sua fibra ou o seu 4G/5G, a rede da sua operadora, as saídas internacionais dela e o quanto estão lotadas hoje à noite.

O Me2Cloud manda cada requisição do seu navegador, então o resultado inclui tudo: Wi‑Fi, roteador, operadora, a rota que ela escolhe e o horário de pico.

1. Uma requisição de aquecimento abre DNS, TCP e TLS. O tempo dela aparece, mas nunca entra na conta.
2. Depois o navegador manda mais 5, 10 ou 20 requisições ao mesmo host pela mesma conexão. Cada uma custa uma ida e volta mais o tempo de processamento do provedor.
3. Cada provedor usa o tipo de requisição que verificamos manter a conexão aberta: GET para AWS, Azure, Google Cloud, Huawei Cloud, DigitalOcean e Scaleway; HEAD para Oracle, IBM Cloud, Alibaba Cloud, Tencent Cloud, Volcengine, Baidu AI Cloud, Naver Cloud, Linode, Vultr, OVHcloud, IONOS Cloud, Aruba Cloud, Leaseweb, Gcore e Yandex Cloud (o GET deles fecha a conexão e triplicaria cada amostra); <img> só para a Hetzner.
4. Mostramos a mediana (o valor típico), a média, o P90 (9 de cada 10 amostras ficam abaixo), o jitter (mudança média entre amostras seguidas) e a perda (amostras sem resposta no tempo limite).
5. O nível vem da mediana: T0 ≤ 30 ms, T1 ≤ 80 ms, T2 ≤ 150 ms, T3 ≤ 250 ms e T4 acima disso. A pontuação das sugestões é mediana + 2 × jitter + penalidade de perda, então 60 ms estáveis ganham de 45 ms que oscilam.

• O mesmo caminho do seu tráfego. Sites, APIs, túneis na porta 443, login de jogos e downloads usam TCP. Muitas operadoras colocam o ICMP em outra fila, limitam ou roteiam diferente, então o ping parece bom enquanto as páginas se arrastam, ou o contrário.
• Não some por limitação. Roteadores e nuvens costumam limitar ou descartar ICMP. Um endpoint HTTPS público sempre responde.
• Sua configuração real conta. DNS, a escolha entre IPv4 e IPv6, proxies e aceleradores valem para o tráfego do navegador, então você mede o que realmente teria.
• O porém: cada amostra inclui também um pequeno tempo de processamento do servidor, bem constante. Medimos 0–5 ms na AWS, uns 8 ms na Alibaba Cloud e uns 20 ms no Huawei Cloud OBS. Acima de 100 ms não faz diferença; em regiões muito próximas o número sai um pouco maior que o ping.

• Redes residenciais ficam mais cheias das 20:00 às 23:00, e as ligações internacionais mais ainda. Uma região T1 ao meio-dia pode cair para NPC à noite.
• Teste uma vez de dia e outra no pico. Os testes salvos ganham a marca “horário de pico” e dá para alternar entre eles nos Resultados.
• Pause downloads grandes, streaming e sincronizações durante o teste. Cabo é melhor que Wi‑Fi; no Wi‑Fi, fique perto do roteador.
• Em dados móveis, o resultado muda com o sinal. Teste onde você vai usar o serviço de verdade.

• Fazer uma lista curta de regiões antes de contratar servidor, servidor de jogo ou origem de CDN.
• Comparar regiões de um mesmo provedor, ou a mesma cidade entre provedores.
• Ver se a estabilidade (jitter, perda) dá conta de jogos, videochamadas, área de trabalho remota e SSH.
• Ver quanto o seu proxy, acelerador ou plano novo ajuda de verdade, testando com e sem.
• Testar o seu próprio servidor ou CDN ao lado dos grandes com um destino personalizado.

• Um lugar só. É a sua conexão, não a dos seus usuários. Peça para alguns usuários rodarem também, ou exporte e compare.
• Destinos, não a sua futura VM. Testamos o endpoint público de API ou armazenamento de cada provedor na região. Servidores da mesma região costumam compartilhar a rede, mas rotas premium (por exemplo CN2, BGP versus uma única operadora, Lightsail versus EC2) podem ser diferentes.
• Sem banda, sem UDP, sem traceroute. Medimos idas e voltas, não a velocidade de download, o tráfego UDP de jogos ou os saltos no meio do caminho.
• Efeitos do navegador. Extensões, proxies, VPNs e abas pesadas trazem ruído. Feche abas pesadas e deixe esta página na frente.
• A Hetzner não consegue manter a conexão a partir de um navegador, então os números dela incluem um handshake toda vez. Alguns destinos podem estar inacessíveis de certos países.

• A página é só um conjunto de arquivos estáticos no Cloudflare. Sem servidor próprio, sem cadastro, sem analytics, e os resultados nunca são enviados.
• Todas as requisições de teste vão direto do seu navegador ao provedor. Abra o Registro de requisições ou as ferramentas de desenvolvedor (aba Rede) para ver uma por uma.
• As informações de rede vêm do Cloudflare (speed.cloudflare.com/meta e /cdn-cgi/trace), e a verificação WebRTC opcional pergunta a stun.cloudflare.com o seu endereço de saída UDP. Dá para desligar nas Configurações.
• A detecção de IPv4/IPv6 também consulta ipify.org e ident.me, dois provedores fora da Cloudflare, para que uma rede que bloqueie um deles não seja dada como sem IPv6.
• Configurações, destinos personalizados e os últimos testes ficam no armazenamento local deste navegador; “Apagar dados de teste” remove os resultados.

Bater forte demais em endpoints públicos poderia acionar a limitação ou o WAF de um provedor e estragar o resultado. O teste fica bem abaixo disso:

• Uma requisição por vez por host, com pausa de 250–370 ms entre amostras (no máximo 2–3 requisições por segundo por host).
• No máximo 2 hosts por provedor ao mesmo tempo, e 8 no total (4 por padrão).
• No máximo 21 requisições por host em cada teste (aquecimento + 20). Sem modo contínuo.
• Um host é deixado de lado após 3 falhas seguidas em vez de ficar tentando.
• Requisições “simples” anônimas, sem cookies nem referer: sem preflight, respostas minúsculas (algumas centenas de bytes), HEAD sempre que possível e nada de downloads grandes.

É menos tráfego do que abrir uma página web comum. Verificamos que cada destino responde normalmente a requisições anônimas (200, 403 ou 404 servem igual para medir).

Se o seu tráfego passa por um proxy, o navegador mede o seu caminho até o proxy mais o do proxy até o provedor, não a sua conexão. O painel de rede procura os sinais comuns: rede de saída de data center, fuso horário que não bate com o país de saída, WARP, ou saída WebRTC diferente da saída HTTPS.

Use Regras de conexão direta para mandar direto só os hosts de teste (Clash / Mihomo, Surge, Shadowrocket, Quantumult X, Loon, sing-box, Xray, SwitchyOmega ou lista simples) e verifique de novo. Se a ideia é medir o próprio proxy, deixe ligado: os números serão o desempenho real dele.

• A faixa de cada linha usa uma escala comum (logarítmica, de 2 ms a 3 s). Os pontos são amostras, a caixa sombreada cobre a metade central das amostras e o traço é a mediana.
• Caixa estreita é estável; caixa larga ou pontos espalhados é jitter. Um × vermelho conta as amostras perdidas.
• Clique numa linha para ver cada amostra em ordem, todas as estatísticas e o destino usado. ✓ marca o que atende às suas exigências.