Wie schnell ist Gcore von dir zu Hause?

Die meisten „Cloud-Ping“-Seiten und alle Looking Glasses der Anbieter messen von ihren Servern aus, die in Rechenzentren an erstklassigem Transit hängen. Das zeigt, wie schnell ein Rechenzentrum ein anderes erreicht. Über den Teil, den du wirklich spürst – deinen Anschluss oder Mobilfunk, das Netz deines Anbieters, seine Auslandsverbindungen und wie voll sie heute Abend sind –, sagt es nichts.

Me2Cloud schickt jede Anfrage aus deinem Browser, also steckt alles im Ergebnis: WLAN, Router, Anbieter, die Route, die er wählt, und die abendliche Stoßzeit.

1. Eine Aufwärm-Anfrage baut DNS, TCP und TLS auf. Ihre Zeit wird angezeigt, aber nie mitgezählt.
2. Danach schickt der Browser 5, 10 oder 20 weitere Anfragen an denselben Host über dieselbe Verbindung. Jede kostet eine Laufzeit plus die Bearbeitungszeit beim Anbieter.
3. Jeder Anbieter bekommt die Anfrageart, bei der wir geprüft haben, dass die Verbindung offen bleibt: GET für AWS, Azure, Google Cloud, Huawei Cloud, DigitalOcean und Scaleway; HEAD für Oracle, IBM Cloud, Alibaba Cloud, Tencent Cloud, Volcengine, Baidu AI Cloud, Naver Cloud, Linode, Vultr, OVHcloud, IONOS Cloud, Aruba Cloud, Leaseweb, Gcore und Yandex Cloud (ihr GET schließt die Verbindung und würde jede Messung verdreifachen); <img> nur für Hetzner.
4. Wir zeigen Median (den typischen Wert), Mittelwert, P90 (9 von 10 Messungen liegen darunter), Jitter (mittlere Änderung zwischen aufeinanderfolgenden Messungen) und Verlust (Messungen ohne Antwort im Zeitlimit).
5. Die Stufe ergibt sich aus dem Median: T0 ≤ 30 ms, T1 ≤ 80 ms, T2 ≤ 150 ms, T3 ≤ 250 ms, T4 darüber. Die Gesamtwertung für die Tipps ist Median + 2 × Jitter + Verlust-Abzug – stabile 60 ms schlagen also sprunghafte 45 ms.

• Derselbe Weg wie dein Verkehr. Webseiten, APIs, Tunnel über Port 443, Spiel-Logins und Downloads laufen über TCP. Viele Anbieter stellen ICMP extra an, drosseln es oder routen es anders – der Ping sieht gut aus, während Seiten kriechen, oder umgekehrt.
• Wird nicht weggedrosselt. Router und Clouds begrenzen oder verwerfen ICMP oft. Ein öffentlicher HTTPS-Endpunkt antwortet immer.
• Deine echte Umgebung zählt. DNS, die Wahl zwischen IPv4 und IPv6, Proxys und Beschleuniger wirken auf den Browserverkehr, also misst du, was du wirklich bekommst.
• Der Haken: Jede Messung enthält auch eine kleine, recht konstante Serverzeit. Gemessen haben wir 0–5 ms bei AWS, etwa 8 ms bei Alibaba Cloud und etwa 20 ms bei Huawei Cloud OBS. Ab 100 ms spielt das keine Rolle; bei sehr nahen Regionen liegt die Zahl etwas über dem Ping.

• Heimanschlüsse sind etwa von 20:00 bis 23:00 am vollsten, Auslandsstrecken noch mehr. Eine Region, die mittags T1 ist, kann abends auf NPC fallen.
• Teste einmal tagsüber und einmal in der Stoßzeit. Gespeicherte Tests tragen den Vermerk „Stoßzeit“, und du kannst sie in den Ergebnissen umschalten.
• Pausier während des Tests große Downloads, Streaming und Cloud-Sync. Kabel ist besser als WLAN; im WLAN nah am Router bleiben.
• Im Mobilfunk hängt das Ergebnis am Empfang. Teste dort, wo du den Dienst wirklich nutzt.

• Regionen eingrenzen, bevor du einen Server, Spielserver oder CDN-Ursprung buchst.
• Regionen eines Anbieters vergleichen oder dieselbe Stadt bei verschiedenen Anbietern.
• Stabilität (Jitter, Verlust) für Gaming, Videocalls, Remote-Desktop und SSH prüfen.
• Sehen, was dein Proxy, Beschleuniger oder neuer Tarif wirklich bringt – einmal mit, einmal ohne testen.
• Deinen eigenen Server oder dein CDN mit einem eigenen Ziel neben den großen Namen testen.

• Nur ein Ort. Es ist deine Leitung, nicht die deiner Nutzer. Lass ein paar Nutzer ebenfalls testen oder exportier und vergleich.
• Endpunkte, nicht deine künftige VM. Wir testen den öffentlichen API- oder Speicher-Endpunkt jedes Anbieters in der Region. Server derselben Region teilen meist das Netz, Premium-Routen (z. B. CN2, BGP vs. Einzelanbieter, Lightsail vs. EC2) können aber abweichen.
• Keine Bandbreite, kein UDP, kein Traceroute. Gemessen werden Laufzeiten, nicht Download-Tempo, UDP-Spieleverkehr oder die Hops dazwischen.
• Browser-Effekte. Erweiterungen, Proxys, VPNs und schwere Tabs bringen Rauschen. Schwere Tabs schließen und diese Seite im Vordergrund lassen.
• Hetzner kann aus dem Browser keine Verbindung offen halten, daher steckt in jeder Zahl ein Handshake. Manche Ziele sind aus einigen Ländern nicht erreichbar.

• Die Seite besteht nur aus statischen Dateien bei Cloudflare. Kein Backend, kein Konto, keine Statistik, und Ergebnisse werden nie hochgeladen.
• Alle Testanfragen gehen direkt von deinem Browser zum Anbieter. Öffne das Anfrageprotokoll oder die Entwicklertools (Tab Netzwerk), um jede einzelne zu sehen.
• Die Netzinfos kommen von Cloudflare (speed.cloudflare.com/meta und /cdn-cgi/trace); der optionale WebRTC-Check fragt stun.cloudflare.com nach deiner UDP-Ausgangsadresse. Lässt sich in den Einstellungen abschalten.
• Die IPv4/IPv6-Erkennung fragt zusätzlich ipify.org und ident.me, zwei Anbieter außerhalb von Cloudflare. Blockiert ein Netz einen davon, gilt es deshalb nicht fälschlich als IPv6-los.
• Einstellungen, eigene Ziele und die letzten Tests bleiben im lokalen Speicher dieses Browsers; „Testdaten löschen“ entfernt die Ergebnisse.

Wer öffentliche Endpunkte zu hart anfragt, kann die Drosselung oder WAF eines Anbieters auslösen und verdirbt das Ergebnis. Der Test bleibt bewusst weit darunter:

• Eine Anfrage gleichzeitig pro Host, mit 250–370 ms Pause zwischen den Messungen (höchstens 2–3 Anfragen pro Sekunde und Host).
• Höchstens 2 Hosts pro Anbieter gleichzeitig und insgesamt höchstens 8 (Standard 4).
• Höchstens 21 Anfragen pro Host und Test (Aufwärmen + 20). Kein Dauermodus.
• Ein Host wird nach 3 Fehlschlägen in Folge aufgegeben statt immer wieder versucht.
• Anonyme „einfache“ Anfragen ohne Cookies und Referrer: kein Preflight, winzige Antworten (ein paar hundert Bytes), wo möglich HEAD, keine großen Downloads.

Das ist weniger Verkehr als das Öffnen einer normalen Webseite. Jedes Ziel ist geprüft und beantwortet anonyme Anfragen ganz normal (200, 403 oder 404 sind für die Messung alle gleich gut).

Geht dein Verkehr über einen Proxy, misst der Browser deinen Weg zum Proxy plus den Weg vom Proxy zum Anbieter – nicht deine eigene Leitung. Das Netz-Panel sucht nach den üblichen Zeichen: ein Ausgangsnetz aus einem Rechenzentrum, eine Zeitzone, die nicht zum Ausgangsland passt, WARP oder ein WebRTC-Ausgang, der sich vom HTTPS-Ausgang unterscheidet.

Mit Direktverbindungs-Regeln schickst du nur die Testhosts direkt (Clash / Mihomo, Surge, Shadowrocket, Quantumult X, Loon, sing-box, Xray, SwitchyOmega oder einfache Liste) und prüfst dann neu. Willst du den Proxy selbst messen, lass ihn an – dann sind die Zahlen seine echte Leistung.

• Der Streifen jeder Zeile nutzt eine gemeinsame Skala (logarithmisch, 2 ms bis 3 s). Punkte sind Messungen, der schattierte Kasten deckt die mittlere Hälfte ab, der Strich ist der Median.
• Schmaler Kasten heißt stabil; breiter Kasten oder verstreute Punkte heißen Jitter. Ein rotes × zählt verlorene Messungen.
• Klick auf eine Zeile zeigt jede Messung der Reihe nach, alle Werte und das genutzte Ziel. ✓ markiert, was zu deinen Vorgaben passt.