Kiedy debuguję projekt Visual Studio przy użyciu przeglądarki Chrome, przeglądarka próbuje przekierować na https odpowiednik mojego adresu internetowego. Nie mam włączonego protokołu SSL w projekcie internetowym, a początkowy adres URL to adres URL http. Podczas debugowania za pomocą FireFox lub IE nie mam tego problemu.
Ponownie zainstalowałem Chrome, co naprawiło problem przez jeden dzień. Bez pobierania jakichkolwiek dodatków problem powtórzył się następnego dnia.
Co powoduje, że Chrome przekierowuje localhost na https?
Programy inspekcji sieci: Żądanie adresu URL: dane: tekst / html, chromewebdata Żądanie nagłówków Wyświetlane są tymczasowe nagłówki Użytkownik-Agent: Mozilla / 5.0 (Windows NT 6.3; WOW64) AppleWebKit / 537.36 (KHTML, jak Gecko) Chrome / 36.0.1985.143 Safari / 537,36
Brak podglądu i brak danych odpowiedzi na tych kartach.
źródło
.dev
jako lokalnego lokatora, jest to zupełnie nowy problem, więc nie sądzę, aby którakolwiek z tych odpowiedzi już działała. Począwszy od Chrome 63 ... „Chrome wymusza domeny .dev na HTTPS przez wstępnie załadowany HSTS”. Nie musisz już samopodpisywać certyfikatów SSL. Najwyraźniej .dev to prawdziwa domena. Kto wiedział.Odpowiedzi:
Uważam, że jest to spowodowane przez HSTS - patrz http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
Jeśli masz (opracowałeś) inne witryny localhost, które wysyłają nagłówek HSTS ...
na przykład. Ścisłe bezpieczeństwo transportu: maksymalny wiek = 31536000; includeSubDomains; wstępne ładowanie
... następnie, w zależności od wartości maksymalnego wieku, przyszłe żądania do hosta lokalnego będą musiały być obsługiwane przez HTTPS.
Aby obejść ten problem, wykonałem następujące czynności.
To nie jest trwałe rozwiązanie, ale przynajmniej sprawi, że będzie działać między projektami. Jeśli ktoś wie, jak na stałe wykluczyć localhost z listy HSTS, daj mi znać :)
AKTUALIZACJA - listopad 2017 r
Chrome niedawno przeniósł to ustawienie do pozycji Usuń zasady zabezpieczeń domeny
AKTUALIZACJA - grudzień 2017 r. Jeśli używasz domeny .dev, zobacz inne odpowiedzi poniżej, ponieważ Chrome (i inne) wymuszają HTTPS za pośrednictwem wstępnie załadowanego HSTS.
źródło
.dev
to uważam, że to nie działa @Alison, ponieważ od najnowszej wersji v.63 ... „Chrome wymusza domeny .dev na HTTPS przez wstępnie załadowany HSTS”. W związku z tym .dev w zasadzie nie będzie działać, chyba że masz poprawnie podpisany certyfikat SSL. Nie są dozwolone żadne certyfikaty z podpisem własnym. Więcej szczegółów .Ten sam problem wystąpił w przeglądarce Chrome i bezskutecznie próbowałem użyć rozwiązania BigJump .
Rozwiązałem problem, wymuszając twarde odświeżanie, jak pokazano na tym blogu (pierwotnie z tej odpowiedzi SuperUser ).
Upewnij się, że pasek adresu korzysta ze schematu http, a następnie wykonaj następujące kroki, być może kilka razy:
źródło
NOWE ULEPSZENIA! (jeśli masz Chrome 63+)
Jeśli twoja domena localhost jest
.dev
, to nie sądzę, aby wcześniej zaakceptowane i działające odpowiedzi nie miały już zastosowania. Wynika to z tego, że od Chrome 63 Chrome wymusza domeny .dev do HTTPS za pośrednictwem wstępnie załadowanego HSTS.Oznacza to, że w
.dev
zasadzie nie będzie już działać, jeśli nie masz odpowiedniego podpisanego certyfikatu SSL - nie są już dozwolone certyfikaty z podpisem własnym! Dowiedz się więcej w tym poście na blogu.Tak więc naprawienie tego problemu teraz i uniknięcie tego w przyszłości
.test
to jedna zalecana domena, ponieważ jest zarezerwowana przez IETF do celów testowych / deweloperskich. Powinieneś także mieć możliwość korzystania.localhost
z lokalnego dewelopera.źródło
.test
.dev
przez.test
pracował również dla mnie w Chrome 63Piggybacking off Adiyat Mubarak
Nie można mocno odświeżyć, ponieważ było to po prostu odświeżanie na https. Wykonuje niektóre z tych samych kroków.
źródło
Mam ten sam problem, ale tylko w Chrome Canary i szukając rozwiązania znalazłem ten post .
Więc zmień swoje domeny.
źródło
.local
brzmi trochę kruche, choć myślę, że to bezpieczniejsze niż inne TLD..localhost
Cofam również użycie coz, ponieważ wygląda na to, że chrome dokonuje natywnego przekierowania, co wydaje się uniemożliwiać działanie mojego rproxy..test
wydaje się najbezpieczniejszy, choć niezgrabny z powodu kolizji przestrzeni nazw ze wszystkimi ciągami znaków używanymi w TDD /.test()
metodach itp.Chrome 63 (dostępny od grudnia 2017 r.) Wymusi przekierowanie wszystkich domen kończących się na .dev (i .foo) na przekierowanie do HTTPS za pomocą wstępnie załadowanego nagłówka HTTP Strict Transport Security (HSTS). Więcej informacji na ten temat można znaleźć tutaj.
źródło
.app
domeny w ostatnim tygodniu. Tymczasowo przechodzimy na,.test
choć nie sądzę, że jest to rozwiązanie długoterminowe.z https://galaxyinternet.us/google-chrome-redirects-localhost-to-https-fix/
Żadna z poprawek opcji nie działała dla mnie. Naprawiłem
https://localhost:3000
to.kliknij i przytrzymaj
Reload
przycisk i wybierzEmpty Cache and Hard Reload
, wydaje się, że jest to tylko opcja włączonalocalhost
źródło
Walczyłem również z tym problemem. Wydaje się, że HSTS jest przeznaczony tylko dla nazw domen . Jeśli więc pracujesz na komputerze lokalnym, o wiele łatwiej jest użyć adresu IP. Więc przełączyłem się z localhost na 127.0.0.1
źródło
Nigdy nie odkryłem źródła problemu, ale udało mi się go rozwiązać. Usunąłem folder pamięci podręcznej aplikacji Google Chrome, który rozwiązał problem.
C: \ Users [users] \ AppData \ Local \ Google \ Chrome
źródło
Może to być spowodowane przekierowaniem https w pamięci podręcznej i można to naprawić, czyszcząc pamięć podręczną ręcznie, jak w odpowiedzi Adiyata Mubaraka.
Ale jeśli odwiedzasz localhost, prawdopodobnie jesteś programistą, w którym to przypadku znajdziesz rozszerzenie czyszczenia pamięci podręcznej Chrome, takie jak „klasyczny zabójca pamięci podręcznej” (patrz np. Https://chrome.google.com/webstore/search/classic%20cache % 20killer? Hl = en ) przydatny w różnych sytuacjach i prawdopodobnie już go zainstalował.
Szybka poprawka polega więc na: zainstalowaniu zabójcy pamięci podręcznej (jeśli jeszcze go nie masz), włącz go i ponownie załaduj stronę. Gotowy!
źródło
Leniwe i szybkie rozwiązanie dla leniwych ludzi takich jak ja (pracujący w Chrome 67).
Wystarczy uruchomić kolejne okno Chrome w trybie ukrycia , z opcją „Okno incognito” (CTRL + SHIFT + N). Nie musisz usuwać pamięci podręcznej, nie musisz zagłębiać się w głębokie ustawienia Chrome itp.
źródło
Żadne z tych nie działało dla mnie. Zaczęło się dziać po aktualizacji chrome (wersja 63.0.3239.84, linux) z lokalnym adresem URL. Zawsze przekierowuje do https bez względu na wszystko. Straciłem kilka godzin i dużo cierpliwości w tej sprawie
W końcu to, co zadziałało, to po prostu zmiana domeny.
Co warte jest, domeną był .app. Może ma coś do zrobienia? Po prostu zmieniłem go na .test i chrome przestał go przekierowywać
źródło
Jak rozwiązałem ten problem z chrome 79:
Wystarczy wkleić ten adres URL do wyszukiwania, wpisując chrome: // flags / # allow-insecure-localhost
Pomogło mi to, używając funkcji eksperymentalnych.
źródło
Niestety żadne z wymienionych tutaj rozwiązań nie pomogło mi rozwiązać tego problemu. Rozwiązałem ten problem, używając adresu http://127.0.0.1 (adres IP) zamiast http: // localhost . Szybki mały hack do pracy z kątowym rozwojem dzięki przeglądarce Chrome.
źródło
W moim przypadku moja ścieżka projektu była ustawiona jako
/Users/me/dev/project_root/
i odtąd uruchamiałamnodeJS
/express
server. Zmiana nazwy mojej ścieżki na/Users/me/project_root
(usunięciedev
ze ścieżki do projektu) rozwiązała problem.Najprawdopodobniej ma to związek z tym nowym rozporządzeniem:
Więcej informacji na ten temat można znaleźć tutaj .
Za pomocą:
źródło
Prostym rozwiązaniem tego jest edycja
/etc/hosts
pliku i ustanowienie jednego aliasu dla każdego projektu.Te bezdomne nazwy nigdy nie będą miały problemu z HSTS, chyba że wyślesz odpowiedź HSTS wspomnianą przez @bigjump, a dodatkową korzyścią będzie utrzymanie sesji logowania, jeśli zmienisz się pomiędzy projektami.
źródło
Przejdź do ustawień w Chrome, a następnie do ustawień zaawansowanych, w sekcji prywatności i bezpieczeństwa kliknij Wyczyść dane przeglądania, a następnie wyczyść wszystkie dane. Postępowałem zgodnie z tymi krokami i zadziałało to dla mnie. Mam nadzieję, że to komuś pomoże.
źródło
Chrome 63 zmusza domeny .dev automatycznie do HTTPS poprzez wstępnie załadowany HSTS.
Szybka poprawka: wystarczy zmienić domeny .dev na .localhost.
źródło
To nie jest rozwiązanie, to tylko obejście.
Kliknij projekt Visual Studio (najwyższy poziom) w Eksploratorze rozwiązań i przejdź do okna właściwości.
Zmień SSL włączone na true. W oknie właściwości zobaczysz teraz inny numer portu jako „SSL URL”.
Teraz, kiedy uruchomisz aplikację (lub przeglądasz w przeglądarce), musisz ręcznie zmienić numer portu na numer portu SSL na pasku adresu.
Teraz działa dobrze jako link SSL
źródło
Otwórz
Chrome Developer Tools
-> przejdź doNetwork
-> wybierzDisable Cache
-> załaduj ponownieźródło
Dla kogoś, kto miał ten sam problem, rozwiązałem naciskając klawisze CTRL + SHIFT + DELETE, aby usunąć tylko całą pamięć podręczną przeglądarki. Teraz mogę uzyskać dostęp do mojej strony localhost na protokole HTTP.
źródło
@Adiyat Mubarak odpowiedź nie działała dla mnie. Gdy próbowałem wyczyścić pamięć podręczną i ponownie ją załadować, strona nadal przekierowała do https.
Moje rozwiązanie: w prawym górnym rogu paska adresu (po lewej stronie ikony ulubionych) znajduje się ikona z literą „x”. Kliknij to prawym przyciskiem myszy, a powie coś o „niebezpiecznych skryptach”, a następnie istnieje możliwość ich załadowania. Zrób to.
źródło
Inną opcją byłoby użycie czegoś takiego jak https://github.com/rchampourlier/tunnelss
Pewnie dodało to inną zależność / konfigurację, ale umożliwia także testowanie https w dev, co może być miłe.
Używam RVM jednak, aby tunele działały, musiałem użyć
sudo gem install tunnelss
isudo tunnelss
źródło
To dziś najszybsze rozwiązanie (17-3-2018):
Zamknij wszystkie karty / okna Chrome i uruchom w wierszu polecenia: (lub dodaj go jako krótki kod)
źródło