Как я могу диагностировать неспособность достичь определенного веб-сайта в качестве конечного пользователя?
Если я вообще могу получить доступ к веб-страницам в Интернете, но не могу достичь определенного, как я могу устранить причину в качестве конечного пользователя?
Этот вопрос был вопросом суперпользователя недели .
Прочтите запись в блоге для получения более подробной информации или внесите свой вклад в блог
- Почему сброс ADSL-модема настолько эффективен?
- Локальные и IP-адреса Интернета
- Как установить соединение по коммутируемому соединению автоматически после загрузки + загрузки 90 МБ данных в Windows?
- Разрешая доступ к локальной сети, блокируя доступ в Интернет
- Сделать динамический IP-адрес фиксированным?
- Есть ли способы просматривать сайт, заблокированный моим провайдером?
- Облачные вычисления и веб-сайты для обмена файлами?
- Возможно, для многих доменных имен общий IP-адрес?
- Ethernet (интранет) и Wi-Fi (Интернет) для совместной работы
- Как установить соединение по коммутируемому соединению автоматически после загрузки + загрузки 90 МБ данных в Windows?
- Интернет-магазин DSL медленный по вечерам
- Возможно ли, чтобы ПК одновременно использовал два сетевых соединения?
- Как превратить веб-страницы в pdf?
Возможно, сайт на самом деле не работает.
Попробуйте посетить http://downforeveryoneorjustme.com .
Если в нем говорится: «Это не только вы», на веб-сайте может произойти сбой, и вы должны попытаться сообщить об этом, если это возможно, или просто подождать.
Возможно, это проблема DNS.
Проверьте, разрешено ли DNS-имя веб-сайта (скажем, example.com
) на IP-адрес. Вы можете сделать это, запустив консоль или командную строку и набрав 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
Если вы получаете сообщение об ошибке «неизвестный хост», это означает, что существует проблема DNS. Вы можете попытаться посмотреть, nslookup stackoverflow.com 8.8.8.8
ли он от DNS Google с помощью 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
Если это разрешится с помощью этой команды, вы, вероятно, захотите связаться со своим провайдером DNS (скорее всего, ваш интернет-провайдер). Если вы хотите запустить дополнительные DNS-тесты, попробуйте GRC DNS Benchmark для Windows или службы just-ping.com и whatsmydns.net .
Возможно, это проблема с браузером.
Если он разрешает в DNS, но вы не получаете ответов на ping, это означает, что они либо фильтруют пинги, либо не могут попасть на этот сайт. Если вы получаете ответы, у вас может быть проблема с браузером или браузером. Попробуйте установить другой веб-браузер со всеми настройками по умолчанию и посмотреть, есть ли у вас разные результаты.
Возможно, это проблема с вашим подключением к Интернету.
Если он разрешает, но вы не можете достичь этого, попробуйте запустить tracert example.com
и посмотреть, с чего они начинают отсчет времени.
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 cxxxx.hsd1.ca.comcast.net [xxxx] 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.
Вы также можете попробовать PingPlotter (Shareware; Бесплатная 30-дневная оценка), которая будет многократно запускать traceroute и отображать результаты, поэтому вы можете увидеть, есть ли у вас проблемы с потерей пакетов или пропускной способностью при любом переходе на трассировку.
Пусть это бежит некоторое время. Если вы выбрали время только после ввода или два, вы, вероятно, захотите связаться со своим интернет-провайдером. Если это время до конца, вы должны связаться с веб-мастером сайта, если это возможно. Любой, с кем вы связываетесь, включает в себя вывод команд ping
и traceroute
.
Кое-что еще искать – это неисправный маршрутизатор.
Недавно у меня была такая ситуация с доступом к любому сайту Stack Exchange. Он будет тайм-аут, вернуть ошибки подключения и вообще «заблокировать меня» в течение 5 минут за раз. Практически все остальные сайты были в порядке.
После продолжительных чатов с сотрудниками Stack Exchange (очень полезно) и моего провайдера я сузил его до маршрутизатора. По-видимому, проблема с этим была устранена.
Проблема здесь (я думаю) заключалась в том, что когда-либо ошибка на маршрутизаторе не могла справиться с относительно большим объемом трафика, который я генерировал при использовании Stack Exchange в качестве зарегистрированного пользователя с несколькими учетными записями и имеющего много из них Видимый в любой момент времени.
Тот факт, что был затронут только один сайт (ну один набор сайтов), заставил меня поверить, что проблема лежит в другом месте.
В эти дни нужно рассмотреть IPv6. Возможно, существует проблема с механизмом IPv6 (DNS, маршрутизация, ОС), но не с IPv4 (или, что менее вероятно, наоборот). Команды ping
и tracert
с Windows 7 используют опцию -4
или -6
для независимого тестирования IPv4 и нового IPv6.
Это похоже на комментарий к основному ответу, а не на другой ответ, но у меня недостаточно комментариев для комментариев. Или, возможно, я должен отредактировать Wiki, что означало бы, возможно, добавление примера, поскольку ответ настолько профессионально выглядит. Но у меня не хватает реплики для редактирования Wiki.
Не стесняйтесь редактировать это при необходимости.
В моем случае у меня была довольно специфическая проблема, которую трудно было расшифровать для меня. Когда я попытался добраться до определенного веб-сайта из Firefox, у меня всегда был тайм-аут. Когда я попытался скопировать адрес страницы в другой браузер, это также привело к таймауту. Это происходило по разным связям, и все мои другие устройства работали нормально. Даже запросы на сайт с помощью cURL отлично работали! Я попытался изменить настройки, прокси, изменить и обновить DNS и т. Д. …
Короче говоря, проблема заключалась в том, что один из моих расширений HTTPS Everywhere перенаправлял меня на https-версию адреса, но сервер не отвечал на порт SSL.
При попытке отладки в других браузерах я, бессознательно, также скопировал префикс протокола https и, следовательно, имел такую же проблему, но я набрал его вручную в оболочку для выполнения запроса cURL, чтобы он работал.
Исправление было всего лишь отключением правила HTTPS Everywhere для конкретного веб-сайта.
Очень частный случай, но может случиться с другими и надеюсь, что это поможет.