Sehr seltsames Netzwerkproblem - bestimmte Websites werden nicht geladen


8

Zunächst einmal entschuldige ich mich, wenn ich an der falschen Börse gepostet habe. Ich war mir wirklich nicht sicher, wo diese Frage passt.

Seit geraumer Zeit habe ich dieses sehr seltsame Problem mit meiner Heim-Internetverbindung, das definitiv entweder von meinem Router oder meinem ISP verursacht wird, aber mein ISP ist ziemlich hilflos beim Debuggen.

Zum größten Teil funktioniert meine Verbindung hervorragend - keine Ausfallzeiten und ich bekomme durchweg 100% der Geschwindigkeit, für die ich bezahle.

Es gibt jedoch ein spezifisches Problem: Einige Websites haben dieses sehr seltsame Verhalten, bei dem das Laden sehr lange dauert. Beispiele für solche Websites sind en.wikipedia.org, www.canadapost.ca und www.theweathernetwork.com. Wenn ich auf diesen Websites versuche, eine Seite zu laden, wird zunächst überhaupt nichts geladen, und in der Statusleiste in Chrome wird für eine sehr lange Zeit "Herstellen einer sicheren Verbindung ..." angezeigt, und schließlich wird mir eine " Diese Seite kann nicht erreicht werden "Fehler. Wenn ich nach einigen Malen neu lade und es erneut versuche, wird die Website schließlich geladen, und sobald diese Website geladen ist, kann ich diese Website ungefähr 15 Minuten lang ohne Probleme frei durchsuchen. Dann tritt das Problem erneut auf.

Es ist kein Problem mit meinen Firewall- oder PC-Einstellungen. Ich habe bereits zahlreiche Versuche unternommen, um das Problem zu beseitigen, und festgestellt, dass es sich entweder um meinen Modem-Router oder um meine Internetverbindung selbst handeln muss, da dies bei allen an mein Netzwerk angeschlossenen Geräten (Desktop, Laptop, Smartphone usw.) und mit meinem Smartphone verschwindet das Problem, wenn ich zu mobilen Daten wechsle.

Ich habe ein Support-Ticket bei meinem ISP eingereicht und sie haben mich durch alle offensichtlichen Schritte (Werksreset des Modems usw.) geführt, und jetzt sind sie nicht mehr so ​​hilfreich.

Eine Sache, die ich versucht habe zu testen, ist, dass ich Curl-Befehle für die Websites ausgeführt habe, auf denen dieses Problem auftritt, und dass mir etwas aufgefallen ist. Bei allen Websites mit diesem Problem gibt "curl -v [url]" ein HTTP 301 anstelle eines 200 zurück.

Hat jemand eine Idee, was zum Teufel das verursacht, damit ich die Techniker meines ISP in die richtige Richtung weisen kann?

BEARBEITEN: Es wurde darauf hingewiesen, dass ich https nicht in die Curl-Befehle aufgenommen habe, was zur Rückkehr des 301 führte. Aber jetzt, wo ich https einbinde, ist mir etwas Interessantes aufgefallen:

Wenn ich curl -v für eine https-Site ausführe, die nicht Teil des Problems ist (z. B. Facebook), erhalte ich eine normale Ausgabe. Für eine Website sieht dies jedoch folgendermaßen aus:

$ curl -v https://www.canadapost.ca
* STATE: INIT => CONNECT handle 0x600057810; line 1413 (connection #-5000)
* Rebuilt URL to: https://www.canadapost.ca/
* Added connection 0. The cache now contains 1 members
*   Trying 2600:140a:0:18a::1dc5...
* TCP_NODELAY set
* STATE: CONNECT => WAITCONNECT handle 0x600057810; line 1466 (connection #0)
*   Trying 23.34.200.189...
* TCP_NODELAY set
* Connected to www.canadapost.ca (2600:140a:0:18a::1dc5) port 443 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x600057810; line 1583 (connection #0)
* Marked for [keep alive]: HTTP default
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* STATE: SENDPROTOCONNECT => PROTOCONNECT handle 0x600057810; line 1597 (connection #0)

Es hängt dann wirklich lange dort und endet schließlich mit:

* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=CA; ST=Ontario; L=OTTAWA; O=Canada Post Corporation; OU=Akamai SAN SSL OV; CN=www.canadapost.ca
*  start date: Jan 13 00:00:00 2017 GMT
*  expire date: Jan 13 23:59:59 2018 GMT
*  subjectAltName: host "www.canadapost.ca" matched cert's "www.canadapost.ca"
*  issuer: C=US; O=GeoTrust Inc.; CN=GeoTrust SSL CA - G3
*  SSL certificate verify ok.
* STATE: PROTOCONNECT => DO handle 0x600057810; line 1618 (connection #0)
> GET / HTTP/1.1
> Host: www.canadapost.ca
> User-Agent: curl/7.54.0
> Accept: */*
>
* STATE: DO => DO_DONE handle 0x600057810; line 1680 (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x600057810; line 1807 (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x600057810; line 1817 (connection #0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 301 Moved Permanently
* Server AkamaiGHost is not blacklisted
< Server: AkamaiGHost
< Content-Length: 0
< Location: https://www.canadapost.ca/web/en/home.page
< Date: Mon, 22 May 2017 22:01:55 GMT
< Connection: keep-alive
< Strict-Transport-Security: max-age=31536000
<
* STATE: PERFORM => DONE handle 0x600057810; line 1991 (connection #0)
* multi_done
* Connection #0 to host www.canadapost.ca left intact
* Expire cleared

Es könnte ein IPv6-Problem sein. Was bekommen Sie, wenn Sie auf diese Website gehen: test-ipv6.com
Moshe Katz

Was passiert auch, wenn Sie IPv6 auf Ihrem Computer oder Ihrem Router deaktivieren (versuchen Sie es mit einem der beiden)?
Moshe Katz

In welchem ​​Zustand bist du? Wir sehen dasselbe Verhalten und alle Websites, einschließlich Ihrer, werden auf Akamai gehostet.
Tschad

@ MosheKatz Ich werde das versuchen, wenn ich heute Abend nach Hause komme.
user1072692

@Chad Ontario, Kanada
user1072692

Antworten:


4

Es wurde durch IPv6 verursacht. Ich habe es auf meinem Router deaktiviert und nur auf IPv4 eingestellt, und das Problem ist jetzt behoben.


2

Alle drei dieser Sites scheinen nur HTTPS zu sein. Wenn Sie welche http://Adressen starten , informieren diese Sites Ihren Browser darüber, dass sie httpsmit den 301-Nachrichten dauerhaft verschoben wurden . Dies wird Teil der 301-Nachricht sein. Möglicherweise erhalten Sie zusätzliche Weiterleitungen, die einen Pfad für die Standardseite hinzufügen. Die 301 Weiterleitungen sind wahrscheinlich ein roter Hering.

Lange Verzögerungen wie diese sind häufig, wenn Sie Probleme mit der DNS-Konnektivität haben. Ich würde jedoch erwarten, dass dies beim ersten Versuch geschieht.

Alle diese Sites sind IPv6-fähig. Wenn sich herausstellt, dass Sie IPv6-fähig sind, wird Chrome wahrscheinlich versuchen, IPv6 anstelle von iPv4 für die Verbindung zu verwenden. Das Aushandeln von HTTPS kann mehrere Verbindungen zu verschiedenen Servern umfassen. Wenn eines davon blockiert oder ausgefallen ist, kann dies zu Verzögerungen führen.

Es kann hilfreich sein, die Chome Developer Tools zu verwenden ( CtrlShifti. Wählen Sie die Registerkarte Netzwerk, auf der die Ladezeiten für Seitenkomponenten angezeigt werden . Bewegen Sie den Mauszeiger über die erste langsame Verbindung, um Details zu den Timings zu erhalten.


1
Vielen Dank, dass Sie auf das https hingewiesen haben, das den 301 verursacht hat. Ich habe Curl erneut mit https ausgeführt und etwas Interessantes festgestellt. Https-Websites, auf denen dieses Problem nicht auftritt (z. B. Facebook), können problemlos geladen werden. "Curl facebook.com " funktioniert einwandfrei. Aber mit Websites, die dieses Problem haben, sieht das Curl-Feedback ganz anders aus. Ich habe meinen Beitrag bearbeitet, um ihn
anzuzeigen
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.