Posted:
Дек 2, 2020
Comments:
0 Comments

Обнулился тиц при переходе на https: Что делать после перехода на HTTPS? Как переехать с HTTP на HTTPS?

Содержание

Что делать после перехода на HTTPS? Как переехать с HTTP на HTTPS?

Согласитесь, тема актуальная – для кого-то просто интересная на перспективу, для другого – больная, так как во время не корректного переезда с HTTP на HTTPS было потеряно что-то из «нажитого непосильным трудом», в любом случае вместо занудно-поучительного монолога, предлагаю осветить ее в виде вопросов и блиц-ответов. Что забуду – обсудим в комментариях.

Так же можно сразу перейти к пунктам переезда сайта.

Основные пункты для переезда сайта:

1. Переход на HTTPS – насколько это реально необходимо?

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

2. Почему стоит перевести сайт на HTTPS?

Во-первых, потому что время, когда браузеры уже не будут поддерживать «устаревший» HTTP не за горами. Во-вторых, читайте список ниже:

  • После перехода на HTTPS сайт;
  • Становится существенно быстрее;
  • Лучше ведет себя при работе с мобильных устройств, а также благосклонней относится к публичным источникам беспроводной сети;
  • Становится более безопасным в части администрирования;
  • Получает крутую отметку «НАДЕЖНЫЙ» от Гугл Хром.

3. А когда стоит перейти?

Строго говоря, как любое устрашающее вас, но неизбежное дело, лучше осуществить переход, чем скорее, тем лучше. Однако есть важный момент: если на текущее время в вашем бизнесе «высокий сезон» — отложите переезд на чуть более поздний срок, чтобы не рисковать постоянными клиентами и годовой прибылью.

4. Правда ли что сразу после переезда улучшится ранжирование моего сайта?

В Google с пятидесятипроцентной вероятностью можно говорить об улучшении ранжирования. В Яндексе, скорее всего, сразу будет заметно снижение позиций. Особенности процесса ранжирования для каждого сайта, переехавшего на HTTPS, зависят от сугубо индивидуальных факторов – хостинг, история, соблюдение правил перехода.

5. Если мне не повезет, и после переезда позиции сайта снизятся, к какой потере трафика мне готовиться?

В Гугл восстановление позиций продлится порядка 10-14 дней, с Яндексом хуже – процедура склейки зеркал нередко занимает 1,5-2 месяца. За это время трафик может снизиться на 1/5 всего объема.

6. Я делаю новый сайт, стоит ли мне сразу запускать его на HTTPS?

Да, это действительно поможет избежать множества проблем!

7. Я планирую поменять доменное имя, стоит ли мне приурочить это к переходу на HTTPS?

Строго говоря, переход на новый домен и смена протокола – это разные подходы к смене зеркал. На практике известно, что смена сразу по двум зеркалам ведет к большой потере трафика, поэтому советуем сначала сменить доменное имя, а потом уже переходить на HTTPS. 

8. Я уже перешел на HTTPS, и мой трафик при этом стремительно полетел вниз. Что делать?

В первую очередь проверьте, на какую версию идет «просевший» трафик – HTTP или HTTPS, обеспечена ли доступность сайта по обоим протоколам. Если глобальное проседание наблюдается по Яндексу, есть смысл обратиться в службу техподдержки. Вообще, будучи твердо уверенным, что переезд организован корректно, выждите минимум 2 недели, и только после этого начинайте обоснованно паниковать.

9. После переезда на HTTPS у моего сайта обнулился ТИЦ – что делать?

Ничего не делайте, это нормальная ситуация, показатель восстановится в течение одного месяца, это связано с передачей тИЦ на основное зеркало.

10. Я слышал, что мега-сайты делают редирект с HTTP на HTTPS? Правда ли это, если да – то, зачем?

У многих акул интернет-бизнеса уже заблаговременно приобретен сертификат SSL, однако это не означает, что они все бросили и начали заниматься полноценным переездом. Многие из них ждут определенного момента, например, окончания сезона активных продаж. Однако «засветив» свою HTTPS-версию, они однозначно попадают под индексирование Гугла, а значит, чтобы направить всех посетителей на еще работающую старую версию HTTP, необходимо настроить редирект.

11. Как правильно переехать на HTTPS?

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

  • Готовим ресурс (и готовимся морально),
  • Покупаете SSL-сертификат,
  • Выполняем настройку,
  • Ждем,
  • Понимаем, где сделали ошибки, исправляем,
  • Ждем,
  • Ура, ваш сайт переехал!

12. Планирую купить сертификат SSL? Где лучше?

Без разницы. Ориентируйтесь на стоимость и обещания в части сервисной поддержки.

13. Знаю, что существуют бесплатные сертификаты SSL. Можно ли использовать его для настройки протокола HTTPS?

Бесплатный сертификат, как и бесплатный сыр, скорее всего доставит своему владельцу множество проблем. Исключением является разве что Let’s Encrypt. Кроме того необходимо узнать более подробно об условиях «бесплатности» — а именно, он бесплатный навсегда или только на определенный срок?

14.

Я пользуюсь сервисами CloudFlare, стоит ли мне приобрести у них и сертификат SSL?

Да, наверное, стоит, по желанию.

15. У моего сайта не просто много, а очень много поддоменов. Как это отразится на выборе сертификата SSL?

Можно ознакомиться с лимитами на поддомены у различных продавцов, например, Let’s Encrypt. При этом важно помнить, что если у вашего ресурса поддомены различных уровней, то необходимо специально настраивать структуру и использовать для перехода на HTTPS каждого уровня отдельно специальные wildcard-сертификаты.

16. Нужно ли после переезда добавлять сайт с новым протоколом в вебмастера?

Да, причем и для Яндекса, и для Гугла.

17. Неглавное зеркало удаляется сразу после склеивания?

Нет, лучше этого не делать. С большой вероятностью после этого можно потерять статистику в Яндексе, с еще большей – в Гугле.

18. Когда настраивается редирект?

Если основной источник трафика у вас Яндекс, то не спешите заниматься редиректом сразу, потому как это только продлит и без того не быстрый процесс склейки зеркал. Вообще можно обозначить такое правило: для Яндекса редирект можно делать, когда HTTP уйдет из индекса. На Гугл это не распространяется.

19. robots.txt необходим для обоих протоколов?

Да, лучше если этот файл будет доступен и для HTTPS, и для HTTP. Это шанс избежать некоторых технических трудностей, связанных с переездом на новый протокол и склейкой зеркал.

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

Для Гугла – процесс может занять порядка 10-14 дней. Для Яндекса – минимум 1 месяц, максимум 2 месяца.

21. Как узнать, что вы успешно «переехали»?

Эту радостную весть вам продемонстрируют уходом из индекса HTTP-версии, и «приходом» возглавляющей группу зеркал версии HTTPS.

22. Что делать со старыми ссылками, которые ориентированы на HTTP версию сайта?

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

23. Нужно ли менять собственную перелинковку?

Да, лучше поменять. Тем более, что можно сделать это автоматически.

24. Затронет ли переезд на HTTPS исходящие ссылки?

После переезда вам не нужно менять исходящую ссылочную массу.

25. Поменяется ли код счетчика после переезда?

Метрический, или аналитический код, менять не нужно. Но важно проверить, что на вашем БЕЗОПАСНОМ сайте нет небезопасного контента. Для этого необходимо прогрузить его через HTML код.

Резюмируем по базовым настройкам, которые необходимо сделать для переезда сайта:

  1. Приобрести и настроить сертификат SSL, который можно купить на площадке, где размещается ваш домен.
  2. Добавляем новую версию с HTTPS в Вебмастер Яндекса, тем самым сообщая, что имеется версия с сертификатом безопасности. С Google Search Console тоже советуем добавить новое зеркало.
  3. Указаваем адрес главного зеркала сайта при помощи директивы Host в файле robots.txt, который находится в корне сайта. Пишем: Host: https://site.ru . Именно с https:// и никак иначе! Так же желательно указать отдельный robots для версии с https? где host будет так же указан с https. 443$
    RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

    если не помогло, вот ещё вариант:

    RewriteEngine On
RewriteCond %{HTTPS} =off  
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L]

    Profit! 

    Что будет с позициями сайта и его посещением после перехода на HTTPS?

    Всем привет! С вами Александр Шкудун и в этой статье я расскажу, что будет с позициями и трафиком вашего сайта или блога, если вы надумаете переходить на защищённый протокол https.

    Как вы можете наблюдать, я перевёл свой сайт на протокол Https. Теперь в адресной строке Творческой мастерской Александра Шкудуна стоит https://shkudun.com.ua/ вместо http://shkudun.com.ua/ Ну, а в браузерах можно увидеть рядом с адресом сайта зеленый замочек, свидетельствующий о том, что соединение с сайтом является безопасным.  

    Сделал я это после того, как неизвестные лица нагло скопировали мой сайт.

    И хотя напрямую эти вещи никак не связаны и не влияют друг на друга, я подумал, что лучше максимально следовать рекомендациям Google и защитить информацию пользователей, которые у меня зарегистрированы.  

    Зачем переводить сайты или блоги на защищённый протокол https?!

    HTTPS (Hypertext Transport Protocol Secure) – это протокол, который обеспечивает безопасность и конфиденциальность при обмене информацией между сайтом и устройством пользователя.

    Иными словами, протокол HTTPS – это гарантия безопасности при передаче ваших персональных данных в сети интернет, будь-это совершение какой-либо покупки в интернет-магазине (вы вводите информацию о своей банковской карте), заполнение любых онлайн-форм, подписка на тот или иной сайт или блог и так далее.  

    Информация, передаваемая через защищённый HTTPS протокол, исключает возможность её перехвата третьими лицами, (ну, или, по-крайне мере, существенно усложняет его), поскольку передаётся в зашифрованном виде.

    Ещё в 2015 году Google настойчиво предлагал всем сайтам перейти на протокол HTTPS, поскольку уже с 2017 года сайты, которые этого не сделают и будут продолжать использовать старый протокол HTTP, будут помечаться в новых версиях браузеров как небезопасные, что может сказаться негативным образом на их трафике.

    Что произошло с позициями сайта и его посещением после перехода на HTTPS?

    Теперь о том, что произошло с позициями моего сайта shkudun.com.ua после того, как был осуществлён переход со старого протокола HTTP на новый протокол HTTPS. А произошла самая настоящая хрень! (извините за мой мексиканский).

    Давайте расскажу по пунктам.

    Сайт перевели на HTTPS примерно 15 мая 2017 года.

    1. Уже через пару дней позиции сайта в поисковых системах (Яндексе, в основном) жёстко просели. Практически до нуля. Это прямым образом сказалось на посещаемости.  

    Посмотрите на графики – всё очень наглядно видно. 

    30.05.2017

    Резкий подъем трафика в Яндексе начался уже 20-21 мая (т.е. буквально через несколько дней после проседания).

    Однако 24 мая снова пошёл спад.  

    В период с 06 по 20 июня 2017 года сайт просто-таки штормило. Трафик то взлетал, то падал.  

    Одна статья вообще выпала из индекса. Надеюсь, вернётся.

     

    2. Что интересно, позиции сайта в поисковой выдаче Google изменились незначительно.  Даже пошёл определённый рост по ряду поисковых запросов.  

    3. Обнулился ТИЦ (т.е. показатель авторитетности сайта). И покуда не вернулся обратно.

    UPD. ТИЦ вернулся только в середине августа месяца 2017 года. Т.е. спустя 3 месяца после перехода на защищённый протокол https.

    4. Обнулилось количество лайков и твитов у моих статей (т.к. поменялись URL-страниц). Это, как минимум, обидно. Ведь некоторые посты собирали очень много (более 100) лайков, а теперь демонстрируют лишь нули.

    5. Что интересно, доход с Adsense практически остался на одном и том же уровне, что навело меня на мысль, что Google реально закладывает определённый ежемесячный бюджет для каждого сайта, использующего Adsense. И если происходит недобор (а он был полюбому, т.к. траффик во время перехода упал более чем в 2 раза), то система автоматически повышает цену за клик.  

    Кстати, постоянно замечаю, что если, допустим, с утра цена за клик составляет 0,22 дол. США, то если собирается уже кликов 6, она автоматом падает до 0.12 или и того меньше.  

    Вот к таким последствиям приводит переход сайта на защищённый протокол HTTPs. Подобный манёвр, вроде, должен наоборот — повышать репутацию площадки, добавлять ей траффика, другим образом поощрять, однако по факту — наоборот, снижает её. 

    Будьте к этому готовыми и не пугайтесь! Ведь всё это делается в целях безопасности. А безопасность превыше всего! 

    Сколько по времени длится проседание сайта в поисковой выдаче после перехода на HTTPS?! 

    Что до посещаемости — то она, конечно, восстановится. У меня это уже постепенно происходит. 

    Знающие люди говорят, что процесс перехода с HTTP на HTTPS (склейка старых url-адресов с новыми) может занимать до 2 недель для Google и до 2-3 месяцев для Яндекс (да, Яндекс всегда тормозит. Говорят, из-за того, что каждый сайт проходит ручную проверку в ФСБ. Шутка, друзья).  

    И, как показала практика (ТИЦ вернулся через 3 месяца) Яндекс реально клеит зеркала так долго.

    Когда лучше переходить на HTTPs.

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

    Но в любом случае — переходить нужно! Мало ли, что Google ещё придумает. Может в будущем вообще будет блокировать сайты, использующие небезопасный протокол.

    Снова шучу. Однако в каждой шутке… 😉

    Увидимся!



    Предыдущий материал:

    Вите надо выйти!
    Следующий материал:

    Вышел 3-й сезон сериала Тёмная материя

    Как остановить автоматическое перенаправление с «http://» на «https://» в Chrome

    Вопрос задан

    Изменено
    6 месяцев назад

    Просмотрено
    823k раз

    У меня была какая-то дурацкая установка в нашей настройке DNS, которая теперь решена.

    Оставшаяся проблема заключается в том, что хром закешировал неверную настройку.

    В частности, при использовании Chrome http://example.com теперь перенаправляет на https://example.com (голый домен), что недействительно/не поддерживается. http://example.com СЛЕДУЕТ перенаправить на http://www.example.com , а затем принудительно https://www.example.com .

    Но в нескольких браузерах (включая мой) этого не происходит из-за какого-то странного кэширования Chrome. Я попытался перейти в «Конфиденциальность -> Очистить кэш», но это не помогло.

    • гугл-хром

    3

    В дополнение к кешированным перенаправлениям может быть задействована строгая транспортная безопасность HTTP (также известная как HSTS). HSTS — это функция безопасности, которая заставляет браузер использовать HTTPS даже при доступе к URL-адресу HTTP.

    Браузер начнет использовать HSTS для домена после получения от сервера заголовка Strict-Transport-Security. Браузер также поставляется со списком доменов, для которых HSTS включен по умолчанию.

    В Chrome есть способ удалить ваш домен из HSTS после того, как он был добавлен сервером. Тем не менее, вы не можете исключить домены, которые запекаются в браузере (включая популярные веб-сайты и, в частности, все, что находится под новой версией 9).0015 .dev TLD)

    1. Перейдите по адресу chrome://net-internals/#hsts . Введите example.com под Удалить политики безопасности домена и нажмите кнопку Удалить.

    2. Теперь перейдите на chrome://settings/clearBrowserData , установите флажок Кэшированные изображения и файлы и нажмите кнопку Очистить данные .

    18

    Моя проблема возникла из-за наличия . dev , который, по-видимому, недавно был зарегистрирован как рДВУ и помещен в фиксацию для Chrome Canary. Я узнал об этом из недавнего сообщения, с которым столкнулся, когда искал свою проблему.

    Если у вас та же проблема, что и у меня, кажется, что лучшим решением будет изменение вашего домена на что-то другое, чем .dev . В статье предлагается .test с потенциальным решением .localhost позже (через это предложение).

    19

    Для удалить домен в меню «HSTS» в chrome://net-internals является временным решением.
    После посещения этого домена через HTTPS он снова будет включен в список HSTS.

    По сути, для решения этой проблемы необходимо отключить HTTP Strict Transport Security на веб-сервере 3rdrevolution.com (IIS, Apache, nginx,…).
    Для nginx отредактируйте раздел HTTPS в nginx.conf и установите max-age=0 для Strict-transport-Security:

     сервер {
#. ..
        SSL включен;
#...
        add_header Strict-Transport-Security "max-age=0;";
#...
}

    Дополнительная информация: HTTP Strict Transport Security (HSTS)

    3

    https://www.3rdrevolution.com отправляет заголовок Strict-Transport-Security, поэтому однократный доступ к нему через https заставит браузеры, такие как Chrome/Firefox, перенаправлять http-запросы на https до определенного момента в будущем.

    Как сказано в другом ответе, единственный способ остановить это после запуска — очистить кеш браузера (или дождаться истечения срока действия заказа в браузере).

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

    Перейти к Настройки/Конфиденциальность/Очистить данные просмотра…

    Выберите Начало Времени в раскрывающемся списке.

    Выберите:

    • Очистить сохраненные данные формы автозаполнения
    • Удалить файлы cookie и другие данные сайтов и плагинов
    • Очистить кеш

    Выбрать Очистить данные просмотра

    Это должно позаботиться об автоматическом заполнении на основе вашего предыдущего просмотра. Кроме того, он удалит все файлы cookie, которые также могут вызывать проблемы.

    4

    Из https://galaxyinternet.us/google-chrome-redirects-localhost-to-https-fix/

    Ни одно из исправлений опций не помогло мне, для исправления https://localhost:3000 это помогло .

    Нажмите и удерживайте кнопку перезагрузки и выберите «Очистить кэш и жесткая перезагрузка».0015 локальный хост .

    1

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

     add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";

    поэтому удалите includeSubdomains; , чтобы заставить его работать.

    1

    Менее радикальной альтернативой, чем очистка всех файлов cookie, является Настройки> Показать дополнительные настройки> Настройки контента> Все файлы cookie и данные сайтов затем найдите нужные сайты и очистите файлы cookie только для них.

    2

    Несколько дней назад я случайно включил параметры Chrome с именем:

    • Автоматически отправлять некоторую системную информацию и содержимое страниц в Google, чтобы помочь обнаружить опасные приложения и сайты
    • Защитите себя и свое устройство от опасных сайтов

    А теперь главная проблема заключалась в том, что наш сайт на поддомене всегда перенаправлял с http:// на https:// и браузер выдавал мне ошибку:

    «Ваше соединение не является частным. Злоумышленники могут попытаться украсть вашу информацию с censored.censored.com (например, пароли, сообщения или кредитные карты). NET::ERR_CERT_COMMON_NAME_INVALID»

    Откройте chrome://settings/privacy и включите ранее названные параметры Chrome, которые автоматически защищают ваши устройства. Надеюсь, это поможет кому-то.

    1

    в Chrome 66 многое изменилось на вкладке Settings

    вы можете просто перейти на chrome://settings/resetProfileSettings?origin=userclick и нажать reset.

    это сработало для меня.

    1

    Google Chrome перенаправляет локальный хост на https

    Спросил

    Изменено
    1 месяц назад

    Просмотрено
    334k раз

    512

    Новинка! Сохраняйте вопросы или ответы и организуйте свой любимый контент.
    Узнать больше.

    Когда я отлаживаю проект Visual Studio с помощью Chrome, браузер пытается перенаправить на https-эквивалент моего веб-адреса. У меня не включен SSL в веб-проекте, а начальным URL-адресом является URL-адрес http. Когда я отлаживаю с помощью FireFox или IE, у меня нет этой проблемы.

    Я переустановил Chrome, что решило проблему на день. Без загрузки каких-либо дополнений проблема повторилась на следующий день.

    Что заставляет Chrome перенаправлять локальный хост на https?

    Проверка сети показывает:
    URL-адрес запроса: данные: текст/html, chromewebdata
    Заголовки запроса
    Показаны предварительные заголовки
    User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, например Gecko) Chrome/36.0.1985.143 Safari/537.36

    На этих вкладках нет предварительного просмотра и данных ответов.

    • гугл-хром

    11

    Я считаю, что это вызвано HSTS — см. http://en. wikipedia.org/wiki/HTTP_Strict_Transport_Security

    Если у вас есть (разработаны) какие-либо другие локальные сайты, которые отправляют заголовок HSTS…

    напр. Строгая транспортная безопасность: max-age=31536000; включать поддомены; предварительная нагрузка

    … тогда, в зависимости от значения max-age , будущие запросы к локальному хосту должны будут обслуживаться через HTTPS.

    Чтобы обойти это, я сделал следующее.

    Это не постоянное решение, но, по крайней мере, оно будет работать между проектами. Если кто-нибудь знает, как навсегда исключить локальный хост из списка HSTS, дайте мне знать 🙂

    ОБНОВЛЕНИЕ — ноябрь 2017 г.

    Chrome недавно переместил этот параметр в раздел

    .

    Удалить политики безопасности домена

    ОБНОВЛЕНИЕ — декабрь 2017 г.

    Если вы используете домен .dev, см. другие ответы ниже, поскольку Chrome (и другие) принудительно использует HTTPS через предварительно загруженный HSTS.

    12

    У меня возникла та же проблема в Chrome, и я безуспешно пытался использовать решение BigJump.

    Я исправил свою проблему, выполнив принудительное обновление, как показано в этом блоге (первоначально из этого ответа суперпользователя).

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

    1. Откройте панель инструментов разработчика (CTRL+SHIFT+I)
    2. Нажмите и удерживайте значок перезагрузки / Щелкните правой кнопкой мыши значок перезагрузки.
    3. Откроется меню.
    4. Выберите 3-й вариант в этом меню («Очистить кэш и принудительно перезагрузить»)

    5

    НОВЫЕ РАЗРАБОТКИ! (если у вас Chrome 63+)

    Если ваш домен localhost — .dev , то я не думаю, что ранее принятый ответ работает. Причина в том, что, начиная с Chrome 63, Chrome принудительно переводит домены . dev на HTTPS через предварительно загруженный HSTS.

    Это означает, что .dev больше не будет работать, если у вас нет надлежащего подписанного SSL-сертификата — самоподписанные сертификаты больше не допускаются! Узнайте больше в этом сообщении в блоге.

    Итак, чтобы решить эту проблему сейчас и избежать ее повторения в будущем .test является одним из рекомендуемых доменов, поскольку он зарезервирован IETF для целей тестирования / разработки. Вы также должны иметь возможность использовать .localhost для локального разработчика.

    10

    Совмещение с Adiyat Mubarak

    Не удалось выполнить жесткое обновление, так как оно просто обновлялось по https. Выполняет некоторые из тех же шагов.

     1. Откройте инструменты разработчика Chrome (ctrl + shift + i)
2. Вкладка «Сеть» вверху
3. Установите флажок «Отключить кеш» вверху (для меня прямо под вкладкой «Сеть»).
4. Обновить страницу (пока инструменты разработчика открыты)

    3

    Я столкнулся с той же проблемой, но только в Chrome Canary и в поисках решения нашел этот пост.

    Одна из следующих версий Chrome заставит все домены, заканчивающиеся на .dev (и .foo), перенаправляться на HTTPs через предварительно загруженный заголовок HTTP Strict Transport Security (HSTS).

     { "имя": "dev", "include_subdomains": правда, "режим": "force-https" },
{ «имя»: «foo», «include_subdomains»: правда, «режим»: «force-https» },

    Итак, меняйте домены.

    1

    Перейти к

     chrome://net-internals/#hsts

    Введите localhost в поле Удалить политики безопасности домена и нажмите кнопку Удалить.

    Теперь перейдите к

     chrome://settings/clearBrowserData

    установите флажок Кэшированные изображения и файлы и нажмите кнопку Очистить данные.

    0

    Я также боролся с этой проблемой. Похоже, что HSTS предназначен только для доменных имен. Поэтому, если вы разрабатываете на локальной машине, гораздо проще использовать IP-адрес. Поэтому я переключился с локального хоста на 127.0.0.1

    0

    Chrome 63 (отсутствует с декабря 2017 г.) заставит все домены, заканчивающиеся на .dev (и .foo), перенаправляться на HTTPS через предварительно загруженный заголовок HTTP Strict Transport Security (HSTS). Дополнительную информацию об этом можно найти здесь.

    1

    Открыть Инструменты разработчика Chrome -> перейти к сети -> выбрать Отключить кэш -> перезагрузить

    1

    с https://galaxyinternet.us/google-chrome-redirects-localhost-to-https-fix/

    Ни одно из исправлений опций у меня не сработало, для исправления https://localhost:3000 это сработало.

    нажмите и удерживайте Кнопка перезагрузки и выберите Очистить кэш и принудительно перезагрузить , похоже, это вариант только на localhost

    2

    Ленивое и быстрое решение для ленивых людей вроде меня (работающих в Chrome 67).

    Просто запустите другое окно Chrome в скрытом режиме с опцией «Окно инкогнито» (CTRL + SHIFT + N). Не нужно удалять кеш, не нужно углубляться в настройки Chrome и т. д.

    1

    Как я решил эту проблему с chrome 79:

    Просто вставьте этот URL-адрес в поле поиска chrome://flags/#allow-insecure-localhost

    Мне помогло использование экспериментальных функций.

    Я так и не понял причину проблемы, однако мне удалось решить эту проблему.
    Я удалил папку кеша приложения Google Chrome, которая решила проблему.

    C:\Users[пользователи]\AppData\Local\Google\Chrome

    2

    Это может быть вызвано кешированным перенаправлением https и может быть исправлено путем очистки кеша вручную, как в ответе Адията Мубарака.

    Но если вы посещаете локальный хост, вы, вероятно, являетесь разработчиком, и в этом случае вы найдете расширение Chrome для очистки кеша, такое как «классический убийца кеша» (см. , например, https://chrome.google.com/webstore/search/classic %20cache%20killer?hl=en) полезен в различных ситуациях и, вероятно, уже установлен.

    Итак, быстрое решение: установите средство уничтожения кеша (если у вас его еще нет), включите его и перезагрузите страницу. Сделанный!

    0

    Мне ничего не помогло. Это началось после обновления Chrome (версия 63.0.3239.84, Linux) с локальным URL-адресом. Всегда будет перенаправлять на https, несмотря ни на что. Потерял несколько часов и много терпения на этом

    Что действительно сработало, так это просто смена домена.

    Для чего стоит, домен был .app. Может быть, ему есть чем заняться? И просто изменил его на .test, и хром перестал его перенаправлять

    К сожалению, ни одно из перечисленных здесь решений не помогло мне решить эту проблему. Я исправил эту проблему, используя http://127.0.0.1 (IP-адрес) вместо http://localhost. Быстрый небольшой хак для работы с угловой разработкой в ​​браузере Chrome.

    Простое решение этой проблемы — отредактировать файл /etc/hosts и установить один псевдоним для каждого проекта.

     127.0.0.1 проект1 проект2 проект3

    Эти бездоменные имена никогда не будут иметь проблем с HSTS, если вы не отправите ответ HSTS, упомянутый @bigjump, и с дополнительным преимуществом сохранения сеанса входа в систему, если вы переключаетесь между проектами.

    Перепробовал все упомянутое (настройки браузера, hsts и т. д.), но у меня ничего не получилось.

    Я решил эту проблему, добавив конечный .localhost к псевдониму хоста. В моем случае этот файл под окнами: %windir%\system32\drivers\etc\hosts

    Вот так:

     127.0.0.1 myproject.localhost
127.0.0.1 dev.project.localhost

    Перейти к

     chrome://net-internals/#hsts

    Введите домен в разделе Удалить политики безопасности домена и нажмите кнопку Удалить.

    В моем случае путь к проекту был установлен как /Users/me/dev/project_root/ и оттуда запускал сервер nodeJS / express .
    Переименование моего пути в /Users/me/project_root (удаление dev из пути к проекту) решило проблему.

    Скорее всего, это связано с этим новым правилом:

    Chrome 63 (отсутствует с декабря 2017 года) заставит все домены, заканчивающиеся на .dev (и .foo), перенаправляться на HTTPS через предварительно загруженный заголовок HTTP Strict Transport Security (HSTS).

    Дополнительную информацию об этом можно найти здесь.

    Использование:

    • Google Chrome версии 70.0.3538.110 (официальная сборка) (64-разрядная версия)
    • узелJS v9.2.0

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

    Chrome 63 принудительно переводит домены .dev на HTTPS через предварительно загруженный HSTS.
    Быстрое исправление: просто измените домены .dev на .localhost.

    Это не решение, а обходной путь.

    1. Щелкните проект Visual Studio (верхний уровень) в обозревателе решений и перейдите в окно свойств.

    2. Изменить SSL Enabled на true. Теперь вы увидите другой номер порта как «SSL URL» в окне свойств.

    3. Теперь, когда вы запускаете приложение (или просматриваете его в браузере), вам нужно вручную изменить номер порта на номер порта SSL в адресной строке.

    Теперь он отлично работает как SSL-ссылка

    Проблема может быть воспроизведена и в VS 2019. Это вызвано «Включить отладку Javascript из Visual Studio IDE». VS подключается к Chrome, и вполне возможно, что из-за безопасности или причин, известных Google и Microsoft, иногда не удается подключиться, и у вас возникает эта проблема. Я могу запускать http и https с локальным хостом из приложения ASP net core 3.1. Поэтому во время отладки в VS перейдите к запуску со стрелкой -> IIS Express, чуть ниже «Веб-браузер (Chrome)» выберите «Отладка сценария (отключено)».

    См. статью: https://devblogs.microsoft.com/aspnet/client-side-debugging-of-asp-net-projects-in-google-chrome/

    https://learn.microsoft.com/en -us/visualstudio/debugger/debugging-web-applications?view=vs-2019

    Всегда обращайтесь к документам Microsoft, чтобы получить больше ясности, чем гуглить проблему.

    Для меня в Chrome 90 работало следующее. Мое приложение открыло локальный сервер веб-пакетов на localhost: 3000 , который автоматически перенаправлялся на HTTPS, и я получил ERR_SSL_PROTOCOL_ERROR .

    Я щелкнул маленький значок информации рядом с URL-адресом, открыл настройки сайта в раскрывающемся меню. В списке Небезопасное содержимое было установлено значение Блокировать (по умолчанию) .

    Я изменил это на Разрешить и просто перезагрузил http-версию, и она загрузилась нормально.

    Надеюсь, это поможет людям.

    Мне не удалось заставить работать какое-либо решение; но перенаправление в моем web. config позволило мне продолжить работу (localhost), пока я не найду причину проблемы.

    По сути, это правило перезаписи, которое превращает HTTPS в HTTP; кажется, что предыдущее правило перенаправляло HTTP на HTTPS.

    Он должен находиться в разделе в файле web.config

     
  <правила>
    <очистить/>
    
      <соответствие URL=".*" />
      <условия>

    В моем случае я использовал синхронизацию браузера на Mac, и браузер продолжал перенаправлять http://localhost:3000 на https://localhost:3000.

    Я использую Valet для обслуживания локальных сайтов, и я запустил valet secure в локальном домене *. test, чтобы дать ему сертификат SSL. Поскольку я проксировал этот домен HTTPS при синхронизации браузера, браузер загружал localhost:3000 с HTTPS.

    Чтобы исправить это, мне пришлось:

    1. запустить valet unsecure , чтобы удалить сертификат SSL
    2. запуск перезапуск камердинера
    3. перезапустить синхронизацию браузера
    4. открыть localhost:3000 в браузере (Vivaldi в моем случае это браузер Chromium)
    5. Открыть инструменты разработчика
    6. Установите флажок «Отключить кэш» на вкладке «Сеть»
    7. Обновить страницу

    Оказывается, это сообщение об ошибке отправляло меня в кроличью нору.

    Проблема для меня заключалась в том, что страница, которую я пытался загрузить на http , не возвращала ответ (из-за ошибки в моем коде, которая приводила к сбою сервера).

    Chrome автоматически пробовал https автоматически в качестве резервной копии, поэтому вместо того, чтобы видеть фактическую ошибку (время ожидания страницы истекло), я видел ошибку SSL, которая была отвлекающим маневром.

    Устранение сбоя базового сервера и возврат к http://localhost:5000 устранили мою проблему.

    Для тех, кто, как и я, запускает экспресс-сервер Node.js на локальном хосте, у меня есть этот фрагмент кода, который перенаправляет http на https:

     const server = express()
  .use((req, res, следующий) => {
    если (req.headers['x-forwarded-proto'] != 'https') {
      res.redirect('https://' + req.headers.host + req.url)
    } еще {
      следующий()
    }
  })

    Вы должны убедиться, что он не перенаправляет localhost:

     const server = express()
  .use((req, res, следующий) => {
    if (req.headers['x-forwarded-proto'] != 'https' && req.headers['host'].indexOf("localhost") == -1) {
      res.redirect('https://' + req.headers.host + req.url)
    } еще {
      следующий()
    }
  })

    Для тех, у кого была такая же проблема, я решил, нажав CTRL + SHIFT + DELETE, чтобы удалить только весь кеш браузера. Теперь я могу получить доступ к своему локальному веб-сайту по протоколу HTTP.

    This entry was posted in Тиц