Schritt 1
Erlaubtes Ziel eingeben
Beispiel, kein Live-Ergebnis
https://clocktools.app/Verwende eine öffentliche HTTP- oder HTTPS-URL ohne Zugangsdaten und eigenen Port.
Trace Route: öffentliche Verbindungsdiagnose
Browser-Verbindung und externen HTTP-Abruf getrennt betrachten. Zeiten und Weiterleitungen prüfen, ohne Routerstationen zu erfinden.
So funktioniert es
Browser-Verbindung und externen HTTP-Abruf getrennt betrachten. Zeiten und Weiterleitungen prüfen, ohne Routerstationen zu erfinden.
Schritt 2
Beobachtungen trennen
Beispiel, kein Live-Ergebnis
Browser → Dienst → ZielDie Verbindung vom Browser zum Dienst ist nicht derselbe Weg wie die Anfrage vom Dienst zum Ziel.
Schritt 3
Bericht vergleichen
Beispiel, kein Live-Ergebnis
JSONExportiere Zeit und Ergebnis. Vergleiche mit einem lokalen Browser- oder Terminaltest.
Praktische Anwendungen
Lokalen Fehler eingrenzen
Dein Laptop öffnet eine öffentliche Website nicht, die externe Prüfung erhält aber eine Antwort. Halte Protokoll, Host und Pfad beim Vergleich mit anderem Browser oder Netzwerk gleich. Prüfe zunächst anonymen Zugriff, dann DNS, VPN, Erweiterungen und Zugriffsregeln einzeln. Der Befund grenzt die Frage ein, bestätigt aber nicht die Verfügbarkeit für alle Besucher.
Weiterleitung prüfen
Prüfe nach einem Seitenumzug die alte URL und lies erste Antwort sowie Location-Header. Eine Weiterleitung erklärt möglicherweise den Browserwechsel zu einer anderen Adresse, doch das Werkzeug stoppt davor. Prüfe das Ziel getrennt, sofern erlaubt, und bewahre beide Befunde im Migrationsticket auf. Eine Weiterleitung ist noch keine geprüfte Zielseite.
Support informieren
Kopiere oder exportiere bei sporadischen Problemen JSON mit URL, Zeit, Status, ungefährer Dauer und Browser-Verbindungskontext. Ergänze, was im eigenen Browser und auf welchem Netz scheiterte. Benötigt der Support Routerhops oder wiederholte Verlustmessungen, liefere autorisierte Terminalmessungen separat. Die dargestellten Stufen ersetzen solche Daten nicht.
Dein Browser
ClockTools-Dienst
Zielantwort
Hintergrund und Technik
Warum Traceroute andere Pakete braucht
IPv4-Router verringern beim Weiterleiten den TTL-Wert. Ist er aufgebraucht, können ICMP-Meldungen den antwortenden Router sichtbar machen. Ein Terminal-Traceroute variiert Paketgrenzen und sammelt Antworten.
Diese Seite sendet keine TTL-gesteuerten Routerproben. Die HTTP-Dauer umfasst den externen Abruf und Dienstaufwand. Ein vorhandener TCP-RTT-Wert gehört dagegen zur Browser-Verbindung. Beides ist weder eine Anzahl von Routerstationen noch ein reiner Ping zum Ziel. ICMP-Spezifikation.
Verbindungen und Antworten können wechseln
Routeranforderungen beschreiben Weiterleitung und TTL. Dennoch können Wege und Antworten variieren. Selbst Terminaltests haben Lücken, wenn Geräte Antworten filtern oder begrenzen; diese Lücken beweisen keinen Paketverlust der Anwendung.
HTTP 403 oder 500 ist eine beobachtete Antwort. Ein Timeout bedeutet nur, dass innerhalb der Frist keine brauchbare Antwort kam. Vergleiche URL, Methode und Zeitpunkt: Ein Browser-GET kann sich von der hier verwendeten HEAD-Anfrage unterscheiden. Anforderungen an IPv4-Router.
Beispiel: extern 403, lokal normal erreichbar
Angenommen, die externe HEAD-Anfrage erhält 403 nach 240 ms, dein angemeldeter Browser öffnet die Seite aber. Das zeigt einen Zugriffsunterschied, keinen kaputten Router. Prüfe anonymen Zugriff und Firewall-Regeln; das Tool sendet keine Browser-Cookies.
- Externe Antwort
- 403 · 240 ms
- Lokaler Browser
- Angemeldeter GET erfolgreich
- Nächster Schritt
- Zugriff und Methode vergleichen
Vergleichbare Prüfbedingungen herstellen
Gib die tatsächliche öffentliche HTTP- oder HTTPS-URL ein. Protokoll und Pfad sind wichtig: http:// kann umleiten, während https:// direkt antwortet; die Startseite kann funktionieren, ein Unterpfad nicht. Das Eingabefeld ist kein Portscanner. Zugangsdaten, private Ziele und eigene Ports werden nicht akzeptiert. Verwende normale, nicht vertrauliche Adressen statt Rücksetz- oder signierter Downloadlinks.
Es gibt keine Einstellung für Hopzahl, Paketgröße, Anzahl der Probes oder HTTP-Methode. Extern wird HEAD verwendet, ohne Weiterleitungen zu verfolgen. So lässt sich nach einer Headerantwort fragen, ohne einen Seitendownload zu behaupten. Die HTTP-Methodensemantik beschreibt HEAD und GET; ein normaler Browser lädt Inhalte und danach möglicherweise Ressourcen, die hier nicht angefordert werden.
Starte eine Prüfung, warte und exportiere vor Änderungen der Bedingungen. Abbrechen oder Zurücksetzen beim Zielwechsel verhindert, dass alte Ergebnisse die neue Ansicht überschreiben. Teilen füllt das Ziel für einen bewussten neuen Lauf vor, überträgt aber keinen Messbefund. Spätere Prüfungen können sich durch Dienst, Netz oder Zielzustand berechtigt unterscheiden.
Messwerte verschiedener Verbindungen nicht vermischen
Die erste Beobachtung betrifft die Verbindung deines Browsers zu ClockTools. HTTP-Protokoll, TLS-Version und gegebenenfalls TCP-RTT gehören zu dieser Verbindung. Die zweite ist eine separate anonyme Anfrage des Prüfdienstes an dein Ziel. Die Stufen ordnen die Beobachtungen; sie bilden nicht die Router zwischen Laptop und Website ab.
Die Zieldauer enthält öffentliche DNS-Prüfungen und die externe Anfrage bis zur Antwort. Sie ist weder reine Serververarbeitungszeit noch Bandbreite, Seitenladezeit oder ICMP-Rundlauf zum Ziel. Subtrahiere die Browser-RTT nicht davon, addiere beide nicht zu einem Gesamtping und teile nicht durch die dargestellten Stufen. Endpunkte und Messgrenzen unterscheiden sich.
Im festen Beispiel können 18 ms Browser-RTT und 240 ms Zieldauer zusammen auftreten, ohne einen langsamen Link zu identifizieren. DNS, Verbindungsaufbau, Zugriffsschicht und Antwort können zur zweiten Zahl beitragen. Fehlende Felder bleiben unbekannt. Ein angezeigter Dienststandort belegt weder physischen Pfad noch exakten Benutzerstandort oder den Ursprung hinter einem Proxy.
Ein HTTP-Fehler ist trotzdem eine Antwort
Eine abgeschlossene Diagnosestufe bedeutet eine erhaltene Antwort, nicht eine funktionierende Seite. Lies anschließend den Status. 200 betrifft den Erfolg dieser Anfrage auf HTTP-Ebene, nicht Darstellung, Anmeldung oder Kaufabschluss. Auch 403 und 500 belegen eine Antwort; sie verlangen eher Zugriffs- oder Anwendungsprüfung als die Behauptung, kein Server sei erreichbar gewesen.
301 oder 302 beschreibt nur die erste Weiterleitung. Location kann relativ sein und muss zur geprüften URL gelesen werden. Das Werkzeug bestätigt weder Sicherheit noch Erreichbarkeit oder Schleifenfreiheit des nächsten Ziels. Bewahre die erste Antwort auf und prüfe das vorgesehene öffentliche Ziel gesondert, wenn du dazu berechtigt bist.
Ein Server kann HEAD anders behandeln als GET, auch wenn die Protokollbeziehung anders vorgesehen ist. Bei 405 oder 501 und funktionierendem Browser frage nach Methodenunterstützung und Sperren. Ebenso kann die anonyme Prüfung eine Schutzseite erhalten, während angemeldete Besucher Inhalte sehen. Das ist ein sinnvoller Vergleich, kein Anlass zum Umgehen von Kontrollen.
| Ergebnis | Beobachtung | Nächster Schritt |
|---|---|---|
| 200 | Erfolgreiche HEAD-Antwort | Seite und Interaktionen separat prüfen. |
| 301 / 302 | Erste Weiterleitung | Location lesen, Ziel getrennt prüfen. |
| 401 / 403 | Anmeldung nötig oder Zugriff verweigert | Anonymen Zugriff und eigene Regeln vergleichen. |
| 404 | Dieser Pfad wurde nicht gefunden | Schreibweise und bekannten öffentlichen Pfad prüfen. |
| 405 / 501 | Methode abgelehnt oder nicht unterstützt | Autorisierten GET und Methodenbehandlung vergleichen. |
| 429 / 5xx | Limit oder serverseitige Antwort | Wiederholungen pausieren, zuständige Logs prüfen. |
Fehler schrittweise eingrenzen
Kommt keine brauchbare HTTP-Antwort, beginne mit dem Fehlercode statt der Dauer. DNS nicht gefunden weist auf Schreibweise oder Namensauflösung hin. DNS nicht verfügbar ist weniger eindeutig: Die Resolverprüfung konnte keine nutzbaren öffentlichen Antworten feststellen. Beides ist kein Ablauftest. Bei eigener Domain vergleiche vorgesehene A- und AAAA-Einträge und Delegation in den üblichen Verwaltungswerkzeugen.
Die externe Prüfung hat einschließlich DNS ungefähr 6,5 Sekunden Gesamtfrist. Ein Timeout bedeutet, dass in diesem Versuch keine brauchbare Antwort innerhalb dieser Grenze eintraf. Es benennt weder einen defekten Router noch einen ausgefallenen Ursprungsserver und misst keinen Paketverlust. Verbindungs- oder TLS-Probleme können ebenfalls als Anfragefehler ohne HTTP-Code erscheinen. Zielprotokolle und unabhängige autorisierte Tests klären die Ursache.
Bei abweichenden lokalen und externen Befunden behalte URL und Zeit bei. Vergleiche anonymes Browserfenster und gegebenenfalls anderes Netz. Ändere jeweils nur Netzwerk, VPN, Browser oder Methode. Scheitern beide Perspektiven, eskaliere mit Belegen statt globalen Ausfall zu behaupten. Ein externer Prüfpunkt ist kein Mehrregionenmonitor.
Wenn tatsächlich Routerhops gebraucht werden
Konventionelles Traceroute sendet Testpakete mit steigenden Paketlebensdauergrenzen und ordnet die Antworten diesen Testpaketen zu. Die ICMP-Spezifikation beschreibt Time-Exceeded-Meldungen; IPv6 verwendet Hop Limit im Basisheader. Dieses Verfahren unterscheidet sich grundsätzlich vom Abruf von HTTP-Headern. ClockTools sendet solche Testpakete nicht und rekonstruiert keine Routerliste aus Antworten.
Nutze bei Fragen zu antwortenden Hops ein geeignetes lokales Terminalwerkzeug für ein autorisiertes Ziel. Notiere das Ausgangsnetz und die Art der Testpakete. Eine Messung von einem anderen Rechner ist nicht automatisch dein Pfad. Halte die Ausgabe getrennt vom JSON dieses Werkzeugs, damit der Support Paketbeobachtungen und Anwendungsantworten unterscheiden kann.
Auch Terminalausgaben brauchen Einordnung. Geräte können Testpakete unbeantwortet lassen und normalen Verkehr trotzdem weiterleiten; Pfade und Antworten können wechseln. Ein fehlender Zwischenhop beweist allein keinen Paketverlust der Anwendung dort. Beginne beim sichtbaren Problem und vergleiche Zielverhalten sowie gegebenenfalls wiederholte autorisierte Messungen. Die Stufen hier verraten keine Routernamen, Entfernungen oder verantwortlichen Anbieter.
Methodik
Der Bericht trennt Browser-Verbindungskontext von frischer öffentlicher DNS-Prüfung und anonymer HEAD-Anfrage ans Ziel. Er hält erste HTTP-Antwort, ausgewählte Header und ungefähre Dauer fest, ohne Weiterleitungen zu verfolgen. Fehlende Felder bleiben unbekannt. JSON erhält die Prüfzeit; Abbrechen und Zurücksetzen verhindern verspätete Ergebnisübernahme.
Grenzen
Gemessen werden keine Routerhops, Hoplatenzen, Ende-zu-Ende-Paketverluste oder Terminaltraces. Ein einzelner externer Befund ist keine globale Verfügbarkeitsprüfung, Ladezeitbewertung oder Dauerüberwachung. Akzeptiert werden nur öffentliche Ziele. Fehler müssen mit URL, Methode und Zeit eingeordnet werden; allein bestimmen sie keine fehlerhafte Netzwerkschicht.
Korrekturen
Melde ein reproduzierbares Problem über die Kontaktseite mit Seiten-URL, unbedenklicher Eingabe, Prüfzeit, erwartetem Ergebnis und Quellenbeleg. Füge nach Möglichkeit die öffentliche Antwort bei, aber keine Kontodaten oder geheimen Links. Eine geänderte Quelle ist nicht automatisch ein Rechenfehler. Vergleiche zunächst denselben Namen, dieselbe Seite und denselben Prüfzeitpunkt.
Häufige Fragen
Ist das ein Traceroute von Router zu Router?
Nein. Getrennt dargestellt werden deine Verbindung zu ClockTools und eine externe HTTP-Prüfung. Die Stufen sind keine Router. Für antwortende Hops nutze ein autorisiertes Traceroute oder tracert vom relevanten Netz und bewahre diese Messung separat auf.
Warum ist die Zielstufe bei 403 oder 500 abgeschlossen?
Abgeschlossen bedeutet, dass eine HTTP-Antwort eingetroffen ist. Ablehnung und Serverfehler sind ebenfalls Antworten, kein fehlender Kontakt. Prüfe Code, Zugriffspolitik und Anwendungsprotokolle. Dass die gewünschte Seite oder Aufgabe funktioniert, ist damit nicht bestätigt.
Werden Weiterleitungen verfolgt?
Nein. Angezeigt werden erste Antwort und gegebenenfalls Location. Das Ziel wurde nicht geprüft. Löse relative Angaben gegen die Ausgangs-URL auf und prüfe das gewünschte öffentliche Ziel separat, bevor du von einem erfolgreichen Gesamtweg sprichst.
Warum funktioniert der Browser, obwohl die Prüfung einen Fehler meldet?
Der Browser kann GET, Cookies, Cache oder ein anderes Netz nutzen; hier erfolgt anonymes HEAD von außen. Vergleiche dieselbe URL anonym und untersuche Methode und Zugriff. 405 oder eine Schutzseite kann die Differenz ohne Routingausfall erklären.
Ist die Antwortzeit der Ping der Website?
Nein. DNS-Prüfung und externe HTTP-Anfrage sind enthalten. Eine verfügbare Browser-TCP-RTT betrifft die Verbindung zu ClockTools. Keine der Zahlen ist Ziel-ICMP-Ping; Addition oder Subtraktion erzeugt keine gültige Ende-zu-Ende-Messung.
Was belegt ein Timeout?
Nur, dass der Versuch innerhalb von ungefähr 6,5 Sekunden keine brauchbare Antwort erhielt. DNS, Verbindungsaufbau, Zugriff und Ziel wirken mit. Bewahre Fehler und Zeit auf und vergleiche einen unabhängigen autorisierten Test. Ein ausgefallener Router lässt sich daraus nicht benennen.
Kann ich ein Intranet oder einen anderen Port testen?
Nein. Erlaubt sind öffentliche HTTP- und HTTPS-Ziele auf Standardports. Private Adressen, Zugangsdaten und eigene Ports werden abgewiesen. Nutze autorisierte lokale Werkzeuge deiner Organisation für interne Dienste und versuche nicht, die Grenze mit anderem Hostnamen zu umgehen.
Beweist ein Ergebnis einen regionalen oder weltweiten Ausfall?
Nein. Es ist ein Befund zu einem Zeitpunkt. Netze und Zugriffsregeln können unterschiedliche Antworten liefern. Vergleiche unabhängige Netze und Betreiberüberwachung vor einer größeren Störungsbehauptung und nenne die Ausgangsbedingungen im Supportticket.
Bewahrt Teilen das Ergebnis oder überwacht die URL?
Nein. Ein geteilter Link bereitet eine neue bewusste Prüfung vor. Kopiere oder exportiere JSON für den alten Befund. Teilen und Offenlassen der Seite planen keine Überwachung. Andere Nutzer können aufgrund anderer Verbindung und Zeit andere Ergebnisse sehen.