Comment diagnostiquer l'impossibilité de passer à un site Web spécifique en tant qu'utilisateur final?
Si je peux généralement accéder aux pages Web sur Internet, mais pas à une page spécifique, comment puis-je résoudre la cause en tant qu'utilisateur final?
Cette question était une question de super utilisateur de la semaine.
Lisez l’entrée de blog pour plus de détails ou contribuer vous-même au blog
Peut-être que le site Web est en fait en panne.
Essayez de visiter http://downforeveryoneorjustme.com .
Si le message "Ce n'est pas que vous", le site Web est probablement en panne et vous devriez essayer de le signaler si possible - ou d'attendre.
Peut-être que c'est un problème de DNS.
Vérifiez si le nom DNS du site Web (disons qu'il s'agit de example.com) se résout en une adresse IP. Vous pouvez le faire en lançant une console ou une commande et en saisissant ping example.com
C:\Users\Jeff>ping example.com
Pinging example.com [192.0.32.10] with 32 bytes of data:
Reply from 192.0.32.10: bytes=32 time=26ms TTL=244
Reply from 192.0.32.10: bytes=32 time=27ms TTL=244
Reply from 192.0.32.10: bytes=32 time=27ms TTL=244
Reply from 192.0.32.10: bytes=32 time=39ms TTL=244
Ping statistics for 192.0.32.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 26ms, Maximum = 39ms, Average = 29ms
Si vous obtenez une erreur "hôte inconnu", cela signifie qu'il existe probablement un problème de DNS. Vous pouvez essayer de voir s'il résout le problème avec le DNS de Google avec nslookup stackoverflow.com 8.8.8.8.
C:\Users\Jeff>nslookup example.com 8.8.8.8
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
Name: example.com
Addresses: 2620:0:2d0:200::10
192.0.32.10
Si cette commande résout le problème, vous souhaiterez probablement contacter votre fournisseur DNS (probablement votre fournisseur de services Internet). Si vous souhaitez exécuter d'autres tests DNS, essayez le test de performances DNS de GRC pour Windows , ou les services qui ne font que ping. com et whatsmydns.net .
Peut-être que c'est un problème de navigateur.
Si cela résout le problème dans le DNS, mais que vous n'obtenez pas de réponses ping, cela signifie qu'elles filtrent les pings ou que vous ne pouvez pas accéder à ce site. Si vous recevez des réponses, vous avez peut-être un problème de navigateur ou de proxy de navigateur. Essayez d'installer un autre navigateur Web avec tous les paramètres par défaut et voyez si vous obtenez des résultats différents.
Peut-être que c'est un problème avec votre connexion Internet.
Si le problème est résolu mais que vous ne pouvez pas l'atteindre, essayez d'exécuter tracert example.com et voyez où ils commencent à expirer.
Tracing route to example.com [192.0.32.10]
over a maximum of 30 Hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 15 ms 26 ms 29 ms c-x-x-x-x.hsd1.ca.comcast.net [x.x.x.x]
3 10 ms 25 ms 9 ms te-5-4-ur04.pinole.ca.sfba.comcast.net [68.86.248.169]
4 12 ms 13 ms 14 ms te-0-6-0-0-ar01.oakland.ca.sfba.comcast.net [68.85.154.86]
5 35 ms 15 ms 12 ms pos-0-3-0-0-cr01.sacramento.ca.ibone.comcast.net [68.86.90.129]
6 15 ms 16 ms 18 ms pos-0-9-0-0-cr01.sanjose.ca.ibone.comcast.net [68.86.85.181]
7 16 ms 18 ms 19 ms xe-11-1-0.Edge1.SanJose1.Level3.net [4.79.43.133]
8 27 ms 18 ms 33 ms vlan69.csw1.SanJose1.Level3.net [4.68.18.62]
9 77 ms 29 ms 183 ms ae-63-63.ebr3.SanJose1.Level3.net [4.69.134.225]
10 28 ms 35 ms 35 ms ae-2-2.ebr3.LosAngeles1.Level3.net [4.69.132.10]
11 43 ms 27 ms 60 ms ae-31-80.car1.LosAngeles1.Level3.net [4.69.144.131]
12 23 ms 23 ms 28 ms INTERNET-CO.car1.LosAngeles1.Level3.net [4.71.140.222]
13 24 ms 23 ms 24 ms www.example.com [192.0.32.10]
Trace complete.
Vous pouvez également essayer PingPlotter (Shareware; Évaluation gratuite de 30 jours.) Qui exécutera de manière répétée un traceroute et un graphique des résultats afin que vous puissiez voir si vous le souhaitez. avoir des problèmes de perte de paquets ou de bande passante à n’importe quel saut sur le traceroute.
Laissez cela courir pendant un moment. Si le délai d’expiration n’est atteint qu’après une entrée ou deux, vous souhaiterez probablement contacter votre fournisseur de services Internet. Si le temps presse avant la fin, vous devriez contacter le webmaster du site, si possible. Qui que vous contactiez, incluez le résultat des commandes ping et traceroute.
Autre chose à rechercher est un routeur défectueux.
J'ai récemment eu cette situation avec l'accès à n'importe quel site Stack Exchange. Il expirerait, renverrait des erreurs de connexion et généralement "me verrouillerait" pendant 5 minutes à la fois. Pratiquement tous les autres sites étaient OK.
Après de longues discussions avec le personnel de Stack Exchange (très utile) et mon fournisseur de services Internet, je l'ai réduite au routeur. L'échanger a apparemment résolu le problème.
Le problème ici (je pense) était que quelle que soit la faute sur le routeur, il ne pouvait pas faire face au volume de trafic relativement élevé que je générais lorsque j'utilisais Stack Exchange en tant qu'utilisateur connecté possédant plusieurs comptes visible à tout moment.
Le fait que seul un site (et bien un ensemble de sites) ait été affecté m'a amené à penser que le problème se situe ailleurs.
Dans mon cas, j’avais un problème assez spécifique, difficile à décoder pour moi. Lorsque j'essayais d'accéder à un site Web spécifique depuis Firefox, j'avais toujours un délai d'attente. Lorsque j'ai essayé de copier l'adresse de la page sur un autre navigateur, le délai d'attente a également été dépassé. Cela se produisait par diverses connexions et tous mes autres appareils fonctionnaient bien. Même interroger le site avec cURL a bien fonctionné! J'ai essayé de modifier les paramètres, les mandataires, de modifier et d'actualiser le DNS, etc.
Bref, le problème était que l'une de mes extensions, HTTPS Everywhere (-) m'a redirigé vers une version https de l'adresse mais le serveur ne répondait pas sur le port SSL.
En essayant de déboguer dans d'autres navigateurs, j'ai inconsciemment également copié-collé le préfixe de protocole https et je rencontrais donc le même problème, mais je l'ai saisi manuellement dans le shell pour exécuter la demande cURL.
Le correctif consistait simplement à désactiver la règle HTTPS Everywhere pour le site Web spécifique.
Un cas très spécial, mais qui pourrait arriver à d’autres et espère que cela aidera.
De nos jours, il faut considérer IPv6. Il est possible qu'il y ait un problème avec le mécanisme IPv6 (DNS, routage, système d'exploitation) mais pas avec IPv4 (ou, moins vraisemblablement, l'inverse). Les commandes ping et tracert à partir de Windows 7 utilisent une option -4 ou -6 pour tester indépendamment IPv4 et le nouvel IPv6.
Cela ressemble à un commentaire à la réponse principale, pas à une autre réponse, mais je n'ai pas suffisamment de représentants pour commenter. Ou peut-être devrais-je éditer le wiki, ce qui voudrait peut-être ajouter un exemple, car la réponse est si professionnelle. Mais je n'ai pas assez de représentants pour l'édition de wiki non plus.
N'hésitez pas à le modifier si nécessaire.