Chrome загружает мой локальный веб-сайт как https, а не http, что приводит к ошибке (начало происходить после обновления ubuntu)
У меня есть локальный проект WordPress, над которым я работаю, и обычно я открываю свой веб-сайт, набирая example.dev в строке URL-адреса, и мой веб-сайт, на котором я работаю, отображается правильно.
Я apt-get update и apt-get upgrade мой компьютер с Ubuntu, и он запросил перезагрузку. после перезапуска - я пытаюсь открыть свой локальный веб-сайт и получаю сообщение об ошибке:
Невозможно связаться с этим сайтом example.dev отказался подключиться. Попробуйте:
Проверка соединения Проверка прокси и брандмауэра ERR_CONNECTION_REFUSED ReloadHIDE DETAILS Проверьте подключение к Интернету Проверьте все кабели и перезагрузите все маршрутизаторы, модемы или другие сетевые устройства, которые вы можете использовать. Разрешить Chrome доступ к сети в настройках брандмауэра или антивируса. Если он уже указан как программа, которой разрешен доступ к сети, попробуйте удалить его из списка и снова добавить. Если вы используете прокси-сервер ... Проверьте настройки прокси-сервера или обратитесь к администратору сети, чтобы убедиться, что прокси-сервер работает. Если вы не уверены, что должны использовать прокси-сервер: перейдите в меню Chrome> Настройки> Показать дополнительные настройки ...> Изменить настройки прокси-сервера ... и убедитесь, что для вашей конфигурации установлено значение «без прокси» или «прямой».
и заметил, что мой веб-сайт обслуживается как «https» вместо «http», всякий раз, когда я изменяю «https» на «http», после нажатия кнопки ввода он все равно загружается как https.
Я не был так уверен, что это была проблема - поэтому я открыл Firefox и сделал то же самое - и получил правильный вывод моего сайта, имея «http» в начале, а не «https».
Что вызывает это в Chrome?
Мой сайт работает на сервере apache2. Этого не было до обновления.
изменить: я наткнулся на это сообщение - https://superuser.com/a/1251483/414388 и не очень понимаю, почему мне нужно изменить мое доменное имя - я действительно не ' Я не хочу следовать этому методу. это не решение.
2 ответа
Если у вас нет возможности изменить текущий домен .dev, вы можете понизить Chrome до версии 61 (я сделал это успешно => здесь )
Если вы перейдете к статье , опубликованной в сообщении суперпользователя, tl; dr объяснит это:
tl; dr: Chrome 63 (из декабря 2017 г.), принудительно перенаправляет все домены, заканчивающиеся на .dev (и .foo), на HTTPS через предварительно загруженный заголовок HTTP Strict Transport Security (HSTS).
Таким образом, ваши единственные решения - это либо изменить что-то, кроме TLD .dev, либо создать сертификат и внедрить HTTPS в вашей конфигурации виртуального хоста для локальной разработки.
Чтобы объяснить, почему это ваше единственное решение, мне нужно начать с того, что означает HSTS и как оно работает.
HSTS в целом
HSTS - это относительно новый HTTP-заголовок, который, когда установлен, сообщает браузерам, что в следующий раз, когда кто-то перейдет к домену, доступ к нему будет осуществляться только по HTTPS без необходимости для любого перенаправления на стороне сервера.
Например, давайте рассмотрим, что вы перешли на http://example.com. В заголовках ответов вы получаете следующее:
Strict-Transport-Security: max-age=31536000
Этот заголовок сообщает браузеру, что в течение следующего года (31536000 секунд), когда пользователь получит доступ к http://example.com, перенаправьте этот URL-адрес на https://example.com локально без необходимости какого-либо перенаправления сервера. И только после этого заходите на сайт с https://example.com.
HSTS для поддоменов
Предыдущий действителен только для одного домена. Так, например, если вы попытаетесь получить доступ к http://subdomain.example.com, сайт будет работать без перенаправлений.
Чтобы решить эту проблему, предыдущий заголовок должен быть изменен на:
Strict-Transport-Security: max-age=31536000; includeSubdomains
Теперь, даже если вы никогда не обращались к каким-либо поддоменам из example.com, браузер ВСЕГДА перенаправляет субдомены на https перед выполнением запроса .
Предварительная загрузка HSTS
Последний шаг - исправить одну последнюю проблему. При первом обращении к сайту вы все равно будете обращаться к нему по протоколу HTTP, который перенаправит вас на HTTPS и отправит заголовок HSTS. Предыдущее небезопасно и все еще является проблемой безопасности.
Для решения этой проблемы основные браузеры используют список предварительной загрузки HTTP Strict Transport Security (HSTS) Chrome для жестко заданных доменов, доступ к которым возможен только по протоколу HTTPS. Вы можете найти форму отправки здесь: https://hstspreload.org/
Единственное изменение, которое необходимо сделать перед отправкой домена, - это изменить заголовок, чтобы он кэшировался в браузерах для как минимум 2 года, и добавьте к нему опцию preload.
Strict-Transport-Security: max-age=63072000; includeSubdomains; preload
После того, как вы отправите свой домен и после выпуска новой версии Chrome (или любого другого браузера, реализующего список предварительной загрузки HSTS в Chrome, а не обязательно следующей версии), ваш домен будет жестко закодирован в Chrome как HTTPS- только.
Предварительная загрузка HSTS для TLD
Владельцам TLD разрешается (и поощряется) представлять весь TLD для предварительной загрузки HSTS .
Владельцы рДВУ, нДВУ или любых других доменов общего суффикса могут предварительно загружать HSTS во всех своих регистрируемых доменах. Это обеспечивает надежную защиту всего TLD и намного проще, чем предварительная загрузка каждого отдельного домена.
И так как Google владеет TLD .dev, они сделали именно это. Так что теперь все домены *.dev будут работать только в HTTPS под Chrome. А поскольку большинство браузеров используют один и тот же список предварительной загрузки, эти браузеры также перестают работать.
При поиске в списке предварительно загруженных доменов ( ВНИМАНИЕ : Размер страницы превышает 40 МБ , и для ее отображения потребуется некоторое время. компьютер может зависнуть, если он недостаточно мощный!), вы можете обнаружить, что TLD предварительно загружены: google, dev, foo, page, app, chrome.
// eTLDs
// At the moment, this only includes Google-owned gTLDs,
// but other gTLDs and eTLDs are welcome to preload if they are interested.
{ "name": "google", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true, "pins": "google" },
{ "name": "dev", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "foo", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "page", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "app", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "chrome", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },