Проблема не работает com

Доступ к Интернету есть, но странички не грузятся — как исправить?

В данной статье мы рассмотрим достаточно неоднозначную проблему: подключение в сети присутствует, но вот в браузере невозможно перейти на какой-то веб-ресурс. Верно, порой, может возникнуть такая ситуация, при которой в области уведомлений отчетливо будет указано, что у пользователя открыт доступ к Интернету, т.е. на значке подключения отсутствуют красный крестик или желтый восклицательный знак, но вот браузер настойчиво пытается доказывать ему обратное, выдавая различные ошибки и уведомления о проблемах.

Читая эти строки, вы наверняка и сами столкнулись с этой странной проблемой. К счастью, существует ряд методов, с помощью которых вы можете попытаться устранить эту неурядицу. Также стоит заметить, что данная проблема может возникнуть абсолютно на всех версиях операционной системы Windows, типах подключения и браузерах, так что за бортом никого не останется. Итак, давайте же посмотрим, что вы можете сделать, если доступ к сети наблюдается, но браузер отказывается работать.

Интернет доступен, но браузер не работает. Как исправить проблему?

Что же, как мы уже сказали в самом начале статьи, проблема крайне неоднозначная — и за ней может стоять огромное количество причин. Тем не менее мы рекомендуем вам попросту выполнить ряд из нескольких решений, который, вероятно, смогут вытащить вас из этой не самой понятной ситуации. Давайте же посмотрим, что вы можете сделать…

Смените адрес DNS-сервера сетевого подключения

Самым первым делом, попробуйте использовать другой DNS-сервер, чтобы понять, а не заключается ли проблема в вашем, предоставляемым провайдером. Все дело в том, что порой DNS-сервер провайдера может испытывать какие-то проблемы при своей работы, вследствие чего подключение к сети технически остается, но вот выполнить переход на какой-либо веб-ресурс становится невозможно. Как правило, такие проблемы провайдеры решают крайне быстро, тем не менее вы можете проверить эту вероятность просто воспользовавшись услугами публичных DNS-серверов Google.

Как это сделать? Вам просто нужно изменить адрес DNS-сервера для вашего сетевого подключения — и дело в шляпе. Выполняется это элементарно(шаги проведены на примере ОС Windows 10, но вы можете воспользоваться ими и для иных версий системы):

• нажмите правой кнопкой мыши на значок сетевого подключения в области уведомления и выберите «Открыть «Параметры сети и Интернет»»;
• далее кликните на опцию «Настройка параметров адаптера»;
• найдите в новом окошке ваше сетевое подключение(адаптер) и дважды кликните на него левой кнопкой мыши, чтобы перейти в свойства;
• далее нажмите на кнопку «Свойства»;
• выберите «IP версии 4» или «IP версии 6»(в зависимости от типа вашего сетевого подключения) и нажмите кнопку «Свойства»;
• поставьте галочку на опции «Использовать следующие адреса DNS-серверов»;
• выставьте адрес 8.8.8.8. для основного и 8.8.4.4. для альтернативного DNS-сервера;
• сохраните изменения.

Изменив параметры своего сетевого подключения, попробуйте зайти в ваш браузер и перейдите на какой-то веб-ресурс. Как правило, данная проблема возникает все же из-за временно неработающего DNS-сервера провайдера, что, как вы уже знаете, можно запросто обойти.

Ну что, получилось устранить проблему? Если нет, то давайте двигаться дальше. А дальше у нас еще одно решение, которое касается DNS.

Очистите кэш DNS на компьютере

Возможно, вы потеряли возможность переходить на веб-ресурсы посредством браузера из-за кэша DNS, который скопился в вашей системе. Такое порой происходит — и решается эта проблема с помощью простой команды, вводимой в системной консоли.

Итак, чтобы сбросить кэш сопоставителя DNS, вам нужно сделать следующее:

• нажмите комбинацию клавиш Windows+X;
• выберите пункт «Командная строка(администратор)»;
• открыв консоль, впишите в нее команду ipconfig/flushdns и нажмите Enter;
• дождитесь окончания выполнения команды, и закройте консоль.

Откройте браузер и попробуйте зайти на какой-нибудь сайт. Если результат нулевой, то попробуйте после выполнения команды перезагрузить компьютер, а затем снова проверьте браузер. Не помогло — двигаемся дальше.

Отключение прокси-сервера в параметрах подключения

Еще одной причиной, по которой у вас могли возникнуть сложности с переходами на различные ресурсы в сети, является активированная функция по использованию прокси-сервера для локальных подключений. Возможно, вы сами активировали эту функцию, возможно, это сделало какое-то приложение в вашей системе. Так или иначе вам нужно проверить, не включена ли она. Чтобы сделать это, выполните следующее:

• нажмите Windows+S;
• впишите в поисковик «Панель управления» и выберите найденный элемент системы;
• откройте в панели раздел «Параметры браузера»;
• перейдите во вкладку «Подключения» и кликните на кнопку «Настройка сети»;
• если возле опции «Использовать прокси-сервер для локальных подключения (не применяется для коммутируемых или VPN-подключений)» стоит галочка, то уберите ее, и сохраните внесенные изменения;
• перезагрузите свой компьютер.

Если у вас действительно была по какой-то причине активирована указанная функция, то, отключив ее, откройте браузер и проверьте, сможете ли перейти на какую-то страничку в сети.

Сбросьте настройки своего сетевого подключения

Кто знает, может что-то было изменено в настройках параметров вашего сетевого подключения, после чего вы больше не можете нормально использовать его для выхода в Интернет. Благо, вы запросто можете сбросить эти параметры с помощью нескольких команд. Чтобы применить их, вам нужно сделать следующее:

• нажмите комбинацию клавиш Windows+X;
• выберите пункт «Командная строка(администратор)»;
• открыв консоль, впишите в нее следующий набор команд:
  • ipconfig /flushdns
  • ipconfig /registerdns
  • ipconfig /renew
  • ipconfig /release
• завершив ввод команд, перезагрузите свой компьютер.

Снова откройте браузер и проверьте, встало ли все на свои места. Как правило, к этому моменту у многих пользователей получается устранить проблему. Однако, если у вас так и не получилось, то у нас остался для вас последний совет: воспользуйтесь каким-то антивирусом и просканируйте систему на наличие вирусов. Да, если вам так и не удалось нормально использовать свое сетевое подключение, то, скорее всего, тут замешан какой-то вирус, который попал в систему.

Источник

Диагностика проблем с «нестабильной доступностью» сайта

Представляю вашему вниманию статью, цель которой – определить последовательность действий при анализе нестабильной загрузки страниц или недоступности сайта для обычного пользователя. Кроме того, предлагаю дополнить мою схему общим умом хабрасообщества, поэтому жду ваших комментариев под постом, чтобы совместными усилиями сформировать «памятку для не-сисадмина».

Итак, приступим.

Для начала, необходимо исключить из списка возможных неисправностей самые очевидные и легко диагностируемые: отсутствие подключения к Wi-Fi, проблемы на стороне интернет-провайдера или, например, отсутствие кабеля в розетке и аккумулятора в ноутбуке.

Предлагаю также опустить сложно решаемые проблемы и неисправности локального интернета или самого компьютера, которые требуют непосредственного вмешательства сисадмина. Это могут быть вирусы-трояны, проблемы с железом, браузером или операционной системой, MTU на роутере, неправильно настроенный DNS или сбои в работе DNS и ещё целый ряд проблем, которые выявить можно, но статья, в этом случае, превратится в книгу или даже в учебный курс.

Остановимся на том, что проблем с Интернетом у нас нет и сайты грузятся нормально, но вот наш сайт доступен с перебоями или недоступен вообще.

Как найти причину?

1. Интернет — это огромное количество магистралей, ведущих от сервера к серверу, и бывают случаи, когда наш сервер работает и мы видим другие сайты, но вот путь пакетов от нас к нашему сайту оборван: сегментировалась сеть из-за сбоя роутинга или где-то произошел сбой в работе каналов провайдеров. Конечно же, в консоли команда traceroute (tracert в Windows) покажет, доступен ли сервер нашего сайта, через какие сервера идут пакеты и на каком месте они «стопорятся». Если же traceroute и ping не доходят до нашего сервера, но достигают сети хостера, то самое время звонить в техподдержку хостинга или сисадминам, так как, в этом случае, сложно будет что-то предпринять самостоятельно.

Traceroute и ping – несложные команды, в Википедии есть статьи на эту тему с вполне доступным описанием:
https://ru.wikipedia.org/wiki/Traceroute
https://ru.wikipedia.org/wiki/Ping

Если traceroute «залипает» где-то на магистральных каналах по дороге к сайту, то рекомендую обязательно проверить, как виден сервер / сайт с других серверов (компьютеров) мировой сети вне вашего провайдера. Они, с большой долей вероятности, используют другие магистрали и зачастую бывает видно, что traceroute через другие каналы успешно проходит к вашему серверу. Например,
http://network-tools.com/default.asp?prog=express&host=www.reg.ru

Если всё в порядке, то проблемы либо у вашего провайдера, либо у его провайдеров уровнем выше, но не возле вашего сервера и не на нём.
Теперь можно позвонить в техподдержку вашего локального провайдера и поинтересоваться: «какие там магистральные каналы лежат?» 😉

2. Скорость и стабильность интернет-канала — это скорость и стабильность самого медленного и плохого канала связи на пути от вас к серверу. Определить, есть ли проблемы с потерями пакетов «по дороге», большие задержки пакетов между разными провайдерами или между вами и провайдером, можно с помощью утилиты mtr, а результаты утилиты особенно показательны при большом размере пакета и его возможной сегментации (например, 1500 байт).

Mtr – это что-то вроде совмещённых ping (опрос каждого сервера по пути следования пакетов) и traceroute (определение всего пути следования пакетов), но имейте в виду, что из-за постоянного потока пакетов утилита съедает достаточно много трафика.

Запрос проверки к сайту yahoo.com:

Показательным для нас будет значение процента потерь пакетов (Loss%) нашего, финального в списке, сервера. Потери на промежуточных серверах, если они не сказываются на финальном, скорее всего, происходят из-за ограничения количества тестовых пакетов к ним (ICMP-траффика).

Обычно, если имеется 30 – 50 % потерь больших пакетов, то проблемы с подключением уже становятся ощутимыми (страница «залипает», подтормаживает из-за недогруженных элементов), и чем выше процент, тем сложнее пробиться.

Проблемы могут рождаться на каком-то промежуточном узле, например, на следующем магистральном Wi-Fi-линке от вашего офиса к провайдеру (если есть). К тому же, причиной могут стать проблемы в связи и роутинге пакетов между провайдерами.

С подробной статьей по использованию mtr для диагностики проблем с каналом (на английском) можно ознакомиться здесь или на Википедии.
Некое подобие утилиты mtr в Windows NT — pathping.

Иногда провайдером (или у нашего сервера) может быть вообще отключена или ограничена возможность прохождения этих тестовых пакетов (ICMP-траффика). В этом случае, такие тесты не помогут определить проблему. Тут уж, конечно, впору вспомнить про «каждый сам себе злобный буратино» — если вы отключаете возможность проверять сервер, то и не сможете его проверить :-).

При работе с Chrome Developer Tools (Menu -> Tools -> Developer Tools), во вкладке «Сеть» (Network), обновляем страницу нашего сайта и получаем отчёт о том, как грузятся все ресурсы на ней:

При успешной загрузке (пусть и медленной) страницы сайта будет видно: когда загрузится основной контент страницы и она начнёт формироваться для отображения, когда начнут работать на сайте все вложенные java-скрипты, завязанные на работу с элементами страницы и ожидающие полной догрузки основного кода и необходимых неопределённых дополнительных вложенных элементов. Этот момент на картинке выше: синяя вертикальная линия – это событие DOMContentLoaded, а красная вертикальная линия – срабатывание windows.onLoad event (когда скрипты уже отработали и сформировалась вся страница с элементами, догружается содержимое картинок).

С помощью этого информационного инструмента мы можем проверить, всё ли в порядке с загрузкой основного содержимого страницы и главного html-кода, то есть удостовериться, что наш сервер вполне «живой» и главный движок сайта не тормозит.
Это первый в списке элемент. Кликнув по нему, мы получим более детальное время ответа сервера:

Как мы видим здесь, наш браузер ждал данные от сервера 68 миллисекунд (сервер формировал страницу на полученный от нас запрос) и 2 миллисекунды она принималась (что достаточно быстро).

Уже по этой информации иногда можно увидеть, что проблема состоит в медленной загрузке сайта — это, например, не миллисекундное, а 30-тисекундное формирование основного кода страницы. Такое бывает, когда перегружен запросами сервер или провайдер, используется неэффективный код (долго работает конкретно запрос этой страницы) или существуют какие-либо другие причины, которые уже впору анализировать сисадминам и программистам движка.

Ниже в списке-графике загрузок будет видно, какие ресурсы на странице загружаются дольше, каких ресурсов страницы дожидается браузер перед тем, как показать страницу, и что блокирует её отображение.

Частая причина блокировок — это зависимость момента старта работы изменяющих / формируюших содержимое страницы (до привязки к событию DOMContentLoaded) скриптов от каких-либо внешних сервисов сбора статистики, рекламных движков или страниц обмена ссылками. Обычно это куски скрипта для вставки «ещё одного» внешнего скрипта:

Эти системы расположены на чужих серверах и зачастую недоступны нашим сисадминам, поэтому могут вести себя как угодно, например:

То есть, пока не подгрузится и не отработает блок

Источник