Google Chrome перенаправляет localhost на https

Question

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

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

Что заставляет Chrome перенаправлять localhost на https?

Показывает проверку сети: URL запроса:data:text/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

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

Answer 1

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

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

например. Строгая транспортная безопасность: максимальный возраст =31536000; IncludeSubdomains; предварительная нагрузка

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

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

• В адресной строке Chrome введите "chrome://net-internals/#hsts"
• В самом низу страницы находится текстовое поле домена QUERY - убедитесь, что localhost известен браузеру. Если написано "Не найдено", это не тот ответ, который вы ищете.
• Если это так, УДАЛИТЕ домен localhost, используя текстовое поле выше
• Ваш сайт теперь должен работать, используя старый добрый HTTP

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

ОБНОВЛЕНИЕ - ноябрь 2017

Chrome недавно переместил этот параметр, чтобы он находился в разделе " Удалить политики безопасности домена".

ОБНОВЛЕНИЕ - декабрь 2017 г. Если вы используете домен.dev, посмотрите другие ответы ниже, так как Chrome (и другие) принудительно устанавливает HTTPS через предварительно загруженный HSTS.

Answer 2

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

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

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

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

Answer 3

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

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

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

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

Answer 4

Спекуляция от Адията Мубарака

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

1. Open chrome developer tools (ctrl + shift + i)
2. Network Tab at the top
3. Click Disable cache checkbox at the top (right under network tab for me).
4. Refresh page (while the developer tools is still open)

Answer 5

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

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

{ "name": "dev", "include_subdomains": true, "mode": "force-https" },
{ "name": "foo", "include_subdomains": true, "mode": "force-https" },

Итак, измените ваши домены.

Answer 6

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

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

Answer 7

Открыто Chrome Developer Tools -> перейти к Network -> выбрать Disable Cache -> перезагрузить

Answer 8

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

Answer 9

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

Answer 10

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

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

нажмите и удерживайте Reload Кнопка и выберите Empty Cache and Hard Reloadкажется, это только вариант на localhost

Answer 11

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

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

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

Answer 12

Ленивое и быстрое решение для таких ленивых, как я (работа в Chrome 67).

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

Answer 13

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

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

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

Answer 14

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

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

Answer 15

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

Answer 16

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

Я решил это, добавив конечный .localhost к псевдонимам хоста.

Как это:

      127.0.0.1    myproject.localhost
127.0.0.1    dev.project.localhost

Answer 17

Ничто из этого не помогло мне. Это начало происходить после обновления chrome (Версия 63.0.3239.84, linux) с локальным URL. Всегда будет перенаправлять на https, несмотря ни на что. Потерял несколько часов и много терпения на этом

В конце концов, сработало только изменение домена.

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

Answer 18

Простое решение - отредактировать /etc/hosts file и установите по одному псевдониму для каждого проекта.

127.0.0.1   project1 project2 project3

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

Answer 19

Перейти к

      chrome://net-internals/#hsts 

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

Answer 20

Ни одно из других решений мне не помогло. В качестве временной работы я перехожу к:

http://127.0.0.1:3000/

(заменять3000с желаемым портом) И я могу, по крайней мере, получить доступ к своему локальному хосту таким образом!

Answer 21

В моем случае мой путь к проекту был установлен как /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-разрядная версия)
• nodeJS v9.2.0

Answer 22

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

Answer 23

Проблема также может быть воспроизведена в VS 2019. Это вызвано тем, что "Включить отладку Javascript из среды разработки Visual Studio". VS подключается к Chrome, и есть вероятность, что из-за безопасности или причин, известных Google и Microsoft, он иногда не может подключиться, и у вас есть эта проблема. Я могу запускать http и https с localhost из приложения 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://docs.microsoft.com/en-us/visualstudio/debugger/debugging-web-applications?view=vs-2019

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

Answer 24

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

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

2. Изменить SSL включен на true. Теперь вы увидите другой номер порта как "SSL URL" в окне свойств.

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

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

Answer 25

Если вы работаете на сайте Wordpress и после того, как попробовали все на этой странице, http://127.0.0.1/wp-admin перенаправляется на https://127.0.0.1/wp-admin . Попробуй это:

Перейдите в wp-config.php и замените

определить('WP_HOME','https://example.com');

определить('WP_SITEURL','https://example.com');

к

определить('WP_HOME','http://127.0.0.1');

определить('WP_SITEURL','http://127.0.0.1');

Проверено в Chrome и Firefox.

Answer 26

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

Answer 27

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

Я щелкнул маленький значок информации рядом с URL-адресом и открыл настройки сайта из раскрывающегося меню. В списке Insecure content был установлен на Block (default).

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

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

Answer 28

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

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

Он должен находиться в разделе <system.webServer> </system.webServer> в web.config.

          <rewrite>
  <rules>
    <clear />
    <rule name="Redirect to https" stopProcessing="true">
      <match url=".*" />
      <conditions>
        <add input="{HTTP}" pattern="off" ignoreCase="true" />
      </conditions>
      <action type="Redirect" url="http://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" appendQueryString="false" />
    </rule>
  </rules>
</rewrite>

Answer 29

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

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

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

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

Answer 30

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

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

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

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