Problème de réseau très étrange - certains sites ne se chargent pas


8

Tout d'abord, je m'excuse si j'ai posté sur le mauvais échange, je ne savais vraiment pas où cette question allait.

Depuis un certain temps, j'ai ce problème très étrange avec ma connexion Internet à domicile qui est certainement la faute de mon routeur ou de mon FAI, mais mon FAI est assez impuissant à le déboguer.

Pour la plupart, ma connexion fonctionne très bien - pas de temps d'arrêt et j'obtiens à peu près 100% de la vitesse pour laquelle je paie.

Cependant, il y a un problème spécifique: certains sites Web ont ce comportement très étrange où leur chargement prendra très longtemps. Des exemples de tels sites Web sont en.wikipedia.org, www.canadapost.ca et www.theweathernetwork.com. Avec ces sites Web, chaque fois que j'essaie de charger une page, au début, rien ne se charge du tout, et la barre d'état dans Chrome indiquera "Etablissement d'une connexion sécurisée .." pendant très longtemps, et finalement cela me donnera un " Ce site est inaccessible "erreur. Si je recharge et réessaye, après quelques fois, le site finira par se charger, et une fois ce site Web chargé, je pourrai naviguer librement sur ce site Web sans problème pendant environ 15 minutes, puis le problème reviendra.

Ce n'est pas un problème avec mes paramètres de pare-feu ou de PC. J'ai déjà essayé de nombreuses choses pour éliminer le problème et j'ai déterminé que ce devait être mon modem-routeur ou ma connexion Internet elle-même, car cela arrive à tous les appareils connectés à mon réseau (ordinateur de bureau, ordinateur portable, smartphone, etc.) et avec mon smartphone, lorsque je passe aux données mobiles, le problème disparaît.

J'ai déposé un ticket de support auprès de mon FAI et ils m'ont guidé à travers toutes les étapes évidentes (réinitialisation d'usine du modem, etc.) et maintenant ils ne sont pas si utiles.

Une chose que j'ai fait pour essayer de tester, c'est que j'ai exécuté des commandes curl pour les sites Web qui ont ce problème et j'ai remarqué quelque chose; avec tous les sites Web ayant ce problème, "curl -v [url]" renvoie un HTTP 301 au lieu d'un 200.

Quelqu'un a-t-il une idée de ce que l'enfer est à l'origine de cela afin que je puisse orienter les techniciens de mon FAI dans la bonne direction?

EDIT: Il a été souligné que je n'incluais pas https dans les commandes curl, ce qui a provoqué le retour du 301. Mais maintenant que j'inclus https, j'ai remarqué quelque chose d'intéressant:

Lorsque vous exécutez curl -v sur un site https qui ne fait pas partie du problème (tel que facebook), je me retrouve avec une sortie normale .. mais pour un site Web qui est, cela ressemble à ceci:

$ 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)

Il se bloque alors là, pendant très longtemps, puis finalement il continue et se termine par:

* 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

Il semble que cela pourrait être un problème IPv6. Qu'obtenez
Moshe Katz

De plus, que se passe-t-il si vous désactivez IPv6 sur votre ordinateur ou votre routeur (essayez l'un ou l'autre)?
Moshe Katz

Dans quel état vous trouvez-vous? Nous constatons le même comportement et tous les sites Web, y compris le vôtre, sont hébergés sur Akamai.
Tchad

@MosheKatz J'essaierai ça quand je rentrerai ce soir.
user1072692

@Chad Ontario, Canada
user1072692

Réponses:


4

Il a fini par être causé par IPv6. Je l'ai désactivé sur mon routeur et l'ai réglé sur IPv4 uniquement et le problème a maintenant disparu.


2

Ces trois sites ne semblent être que HTTPS. Si vous commencez à quelles http://adresses, ces sites informent votre navigateur qu'ils ont migré en permanence httpsavec les 301 messages. Cela fera partie du message 301. Vous pouvez obtenir des redirections supplémentaires qui ajoutent un chemin d'accès à la page par défaut. Les redirections 301 sont probablement un hareng rouge.

De longs retards comme celui-ci sont courants si vous avez des problèmes de conmectivité DNS. Cependant, je m'attendrais à ce que cela se produise du premier coup.

Tous ces sites sont compatibles IPv6. S'il semble que vous ayez la capacité IPv6, Chrome tentera probablement d'utiliser IPv6 plutôt que iPv4 pour se connecter. La négociation de HTTPS peut impliquer plusieurs connexions à différents serveurs. Si l'un d'eux est bloqué ou en panne, cela peut entraîner des retards.

Il peut être utile d'utiliser les outils de développement Chome ( CtrlShifti. Sélectionnez l'onglet Réseau qui vous montrera les temps de chargement des composants de la page. Passez la souris sur la première connexion lente pour plus de détails sur les horaires.


1
Merci d'avoir souligné le https provoquant le 301, complètement oublié. J'ai couru à nouveau curl en utilisant https, et j'ai remarqué quelque chose d'intéressant .. Les sites https qui n'ont pas ce problème (comme facebook) se chargent bien .. "curl facebook.com " fonctionne très bien. Mais avec les sites Web qui rencontrent ce problème, les commentaires sur les boucles semblent très différents .. J'ai modifié mon message pour le montrer
user1072692
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.