Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Netzwerke>Im Browser prüfen, wo man sich befindet?

Im Browser prüfen, wo man sich befindet?

jogoto09.01.1517:12
Kann man in Safari oder mit einem anderen Browser am Mac prüfen, wo man sich eigentlich gerade befindet (auf welchem Server)? Ich habe hier nämlich ein Problem, das mich langsam verzweifeln lässt: eine Internetseite meldet ab und zu Fehler 404 zurück. Nachdem ich alles geprüft hatte, was nur geht kam ich mal auf die Idee die Fehlerseite des Servers anzuschauen und siehe da, die hat einen ganz anderen Text zu 404. Ich habe deswegen den Verdacht, dass ich bei Auftauchen des Fehlers nicht auf dem Server bin auf dem die Internetseite ist (deswegen 404), nur wie prüfe ich das? Mit sämtlichen Netzwerktools lande ich immer auf dem richtigen Server (IP), es scheinen nur die Browser "umgeleitet" zu werden und das auch nur ohne SSL. Deswegen suche ich nach einer Möglichkeit direkt im Browser und direkt wenn ich die 404 Seite sehe eine Art "wo bin ich hier eigentlich" absetzen zu können. Der Quelltest der 404 Seite gibt leider auch nichts her. :'( :'( :'(
0

Kommentare

breaker
breaker09.01.1517:33
Nenn doch mal die Internetseite.
0
jogoto09.01.1517:51
Das bringt nichts. Wer sie noch nie zuvor aufgerufen hat, bekommt den Fehler nicht. Die Umleitung erfolgt irgendwo im Router bei den Leuten, die die Seite früher schon mal aufgerufen hatten. Als Fehlerquelle kristallisieren sich immer mehr diverse Speedports heraus.
Mir geht es auch gar nicht um die Ursachenforschung, da bin ich schon dran, auch nicht um eine Lösung (Speedports verschrotten ), sondern nur wo ich da eigentlich lande, da es der neue Server nicht sein kann und es den alten physikalisch gar nicht mehr gibt.
0
Cyco
Cyco09.01.1518:13
Browser Cache leeren? Speedport neustarten?
Ja das wäre evtl. eine Lösung.

Versuch mal im Netzwerkdienstprogramm einen Trace, indem Du die aktuelle Adresse rüber kopierst, wenn der Fehler auftritt.
Der Trace sollte in dem Moment auf die selben DNS-Daten zugreifen.
0
jogoto09.01.1519:17
Die DNS ist in Ordnung. Ein Trace wandelt die Adresse sofort in die richtige IP und geht deswegen den richtigen Weg.

Cyco
Browser Cache leeren? Speedport neustarten?
Ja das wäre evtl. eine Lösung.
Alles schon gemacht. Seite wird ein paar Klicks lang richtig angezeigt, dann 404.

Ich müsste einfach wissen, wo ich da lande.
0
FloMac09.01.1519:37
Hier ein paar Vorschläge:

1. Arbeite ohne DNS, nimm die IP das Servers
2. Hast Du geprüft, ob sich die IP des DNS Eintrags ändert? Loadbalancer?
3. Probiere per Telnet eine Verbindung auf Port 80 aufzubauen, und ein einfaches HTTP Get absetzen.
4. Die Entwickler Tools in Firefox oder Chrome sind immer sehr hilfreich.
0
DonQ
DonQ09.01.1519:41
Gibt eine Erweiterung für Firefox…Geolocator oder so ähnlich, damit sollte es funzen

Viel Glück
„an apple a day, keeps the rats away…“
0
jogoto09.01.1520:29
FloMac
Hier ein paar Vorschläge:

1. Arbeite ohne DNS, nimm die IP das Servers
Mit DNS scheint das Problem nichts zu tun zu haben. Der Name wird immer sauber aufgelöst.
Die IP zeigt immer auf den Server aber nicht auf die Seite (Shared Hosting)
2. Hast Du geprüft, ob sich die IP des DNS Eintrags ändert? Loadbalancer?
Ja, ändert sich nicht. Loadbalancer gibt es nicht.
3. Probiere per Telnet eine Verbindung auf Port 80 aufzubauen, und ein einfaches HTTP Get absetzen.
GET ergibt 400 aber schon Telnet liefert eine IPv6 Adresse mit der ich schon mal weiter komme!
4. Die Entwickler Tools in Firefox oder Chrome sind immer sehr hilfreich.
Das stimmt, ich verwende sie ständig. Nur wie solle sie in so einem Fall helfen? Eine Fehlerseite liefert nun mal nicht mehr Infos als wie im Quelltest enthalten. Oder übersehe ich da was?
0
jogoto10.01.1502:58
Okay, die Fehlerquelle Speedport war ein falscher Weg. Der „Fehler" tritt bei den IP Anschlüssen der Telekom auf, weil die tatsächlich versuchen Port 80 über IPv6 anzusteuern. Die Seite ist aber über IPv6 gar nicht zu erreichen, was nicht schlimm ist solange es keine AAAA-Records dafür gibt. Die waren aber in dem Domain-Paket automatisch im DNS gesetzt.

Danke an alle für die Hilfe und danke FloMac, Telnet hat mich auf die richtige Spur gebracht.
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.