Quão rápida é a nuvem Google Cloud aí da sua casa?

Resumindo: só um teste da sua rede diz o quanto uma região é rápida para você.

A maioria dos sites de "ping na nuvem" e todos os looking glass dos provedores testam a partir dos servidores deles, que ficam em data centers com links de primeira. Isso mostra a velocidade de um data center até outro. Não mede a parte que você sente: sua internet de casa ou do celular, a rede da sua operadora, as saídas internacionais dela e o quanto estão congestionadas 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 prepara o DNS, a conexão TCP e a criptografia TLS. O tempo dela aparece, mas não conta.
2. Depois o navegador manda mais 5, 10 ou 20 requisições ao mesmo host pela mesma conexão. Cada uma custa uma única ida e volta, mais um pouco de processamento no servidor do provedor.
3. Cada provedor recebe o tipo de requisição que confirmamos manter a conexão aberta: GET para AWS, Azure, Google Cloud, DigitalOcean e Scaleway; HEAD para Oracle, IBM Cloud, Alibaba Cloud, Tencent Cloud, Volcengine, Baidu AI Cloud, Naver Cloud, Huawei Cloud, Linode, Vultr, OVHcloud, IONOS Cloud, Aruba Cloud, Leaseweb, Gcore e Yandex Cloud (com GET eles fecham a conexão, e cada medição triplicaria); e um GET em modo CORS para a Hetzner, cuja página o navegador cortaria de outro jeito, fechando a conexão.
4. Você recebe a mediana (o valor típico), a média, o P90 (9 de cada 10 medições ficam nesse valor ou abaixo), o jitter (quanto duas medições seguidas variam, em média) e a taxa de timeout (a parte das medições sem resposta antes do tempo limite).
5. O nível vem da mediana: T0 Brabo ≤ 30 ms, T1 Top ≤ 80 ms, T2 Tá ok ≤ 150 ms, T3 NPC ≤ 250 ms e T4 Flopou acima disso. "Nossas sugestões" são ordenadas por mediana + 2 × jitter + uma penalidade por timeout, então 60 ms estáveis ganham de 45 ms instáveis.

• Vai pelo mesmo caminho do seu tráfego. Sites, APIs, túneis na porta 443, login em jogos e downloads usam TCP. Muitas operadoras colocam o ICMP numa fila separada, seguram a velocidade dele ou mandam por outra rota, então o ping pode parecer ótimo enquanto as páginas se arrastam, ou o contrário.
• Não some por causa de limites. Roteadores e nuvens costumam limitar ou descartar ICMP. Um ponto HTTPS público sempre responde.
• Inclui a sua configuração real. 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.
• A contrapartida: cada medição também inclui um pequeno tempo de processamento do servidor, bem estável. Medimos 0–5 ms na AWS, cerca de 8 ms na Alibaba Cloud e cerca de 20 ms no Huawei Cloud OBS. Acima de 100 ms isso não importa; em regiões muito próximas, o número fica um pouco acima do ping.

• As redes de casa ficam mais cheias das 20:00 às 23:00, e os links internacionais mais ainda. Uma região que é T1 ao meio-dia pode cair para NPC à noite.
• Teste uma vez de dia e outra no pico. Os testes feitos no pico ganham a marca "horário de pico", e você pode alternar entre eles nos resultados.
• Pause downloads grandes, streaming e sincronização na nuvem enquanto testa. Cabo ganha do Wi-Fi; no Wi-Fi, fique perto do roteador.
• Nos dados móveis, os resultados mudam com o sinal. Teste onde você vai usar o serviço de verdade.

• Montar uma lista curta de regiões antes de contratar um servidor, um servidor de jogo ou uma origem de CDN.
• Comparar regiões de um provedor, ou provedores diferentes na mesma cidade.
• Ver se a estabilidade (jitter, taxa de timeout) dá conta de jogos, videochamadas, área de trabalho remota e SSH.
• Ver como seu proxy, acelerador ou novo plano de internet se sai de verdade: teste uma vez com ele e outra sem.
• Colocar seu próprio servidor ou CDN ao lado dos grandes com um ponto próprio.

• Só um lugar. Ele mede a sua linha, não a dos seus usuários. Peça para alguns rodarem também, depois exporte e compare.
• O ponto público do provedor, não o seu futuro servidor. Testamos a API pública ou o armazenamento de cada provedor na região. Servidores da mesma região costumam usar essa rede, mas rotas premium (por exemplo CN2, BGP ou operadora única, Lightsail ou EC2) podem ser diferentes.
• Sem banda, sem UDP, sem traceroute. Ele mede idas e voltas, não a velocidade de download nem o tráfego UDP de jogos, e não mostra os saltos no meio do caminho.
• O navegador adiciona um pouco de ruído. Extensões, proxies, VPNs e abas pesadas afetam os resultados. Feche as abas pesadas e deixe esta página em primeiro plano.
• Alguns pontos podem não estar acessíveis de certos países.

• Seus resultados não são enviados e não existe conta. Só quando você toca em Compartilhar o resultado é salvo no 1ms.dog como link curto com imagem de prévia, para os apps de mensagem poderem mostrar.
• Cada requisição de teste vai direto do seu navegador ao provedor. Abra o Registro de requisições acima ou as ferramentas de desenvolvedor do navegador (aba Rede) para ver uma por uma.
• Os dados de rede vêm da Cloudflare: primeiro responde o /_ms/me, deste próprio site, e a palavra final é do speed.cloudflare.com/meta e do /cdn-cgi/trace, que seguem o mesmo caminho dos testes. A verificação opcional de WebRTC pergunta ao stun.cloudflare.com o seu endereço de saída UDP; dá para desligar nas configurações.
• A verificação de IPv4/IPv6 também consulta o ipify.org e o ident.me, fora da Cloudflare, para que uma rede que bloqueie um deles não seja dada como sem IPv6.
• Se a página der erro, ela envia a este site a mensagem de erro, o endereço da página e a versão do seu navegador, para podermos corrigir. Ao usar Compartilhar, também contamos de forma anônima quais etapas foram usadas. Nada disso inclui seus resultados.
• Configurações, pontos próprios e os últimos testes ficam neste navegador. Segurar "Apagar dados de teste" remove resultados e histórico; para apagar também as configurações, limpe os dados deste site no navegador.

Pedir demais aos pontos públicos poderia acionar o limite de requisições ou o firewall (WAF) de um provedor e estragar o resultado. Por isso o teste fica bem abaixo disso:

• Uma requisição por vez em cada host, com pausa de 250–370 ms entre as medições (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 (1 de aquecimento + até 20). Não existe modo contínuo.
• Um host é deixado de lado depois de 3 falhas seguidas, em vez de ser tentado sem parar.
• As requisições são anônimas: sem cookies, sem página de origem, sem requisição prévia (preflight). As respostas têm poucas centenas de bytes, HEAD é usado sempre que dá e nada pesado é baixado.

Um teste inteiro gasta menos dados que abrir uma página comum. Cada ponto foi verificado para responder normalmente a requisições anônimas (200, 403 ou 404 servem igual para medir o tempo).

Se o seu tráfego passa por um proxy, o navegador mede você → proxy mais proxy → provedor, não a sua própria linha. O painel de rede procura os sinais de sempre: uma rede de saída num data center, um fuso horário que não bate com o país de saída, WARP, ou uma saída WebRTC diferente da HTTPS.

Use Pegar regras diretas para mandar só os domínios de teste em conexão direta (Clash / Mihomo, Surge, Shadowrocket, Quantumult X, Loon, sing-box, Xray, SwitchyOmega ou uma lista simples) e verifique de novo. Se o que você quer medir é o próprio proxy, deixe-o ligado: aí os números mostram o desempenho real dele.

• Todas as linhas usam a mesma escala (logarítmica, de 2 ms a 3 s). Os pontos são as medições, a caixa sombreada cobre a metade do meio delas e o traço é a mediana.
• Caixa estreita quer dizer estável; caixa larga ou pontos espalhados querem dizer jitter. Um × vermelho conta as medições que deram timeout.
• Toque numa linha para ver cada medição em ordem, todas as estatísticas e o ponto usado. ✓ marca uma região dentro dos seus limites.