623

I had something set up wacky in our DNS setup which is now resolved.

The remaining problem is that chrome has cached the incorrect setup.

Specifically, when using Chrome http://example.com is now redirecting to https://example.com (naked domain), which is not valid/supported. http://example.com SHOULD redirect to http://www.example.com and then force https://www.example.com.

But on a handful of browsers (including mine) this doesn't happen because of some funky Chrome caching. I tried going to “Privacy -> Clear Cache” but it had no effect.

HugoFerrant
  • 3
  • 2
phil swenson
  • 6,339
  • 3
  • 13
  • 4
  • 3
    check your plugins (like SSL everywhere) , have you tried to delete (shift+del)? Try to use http://www.google.com/ncr instead of google.xx. – malakrsnaslava Mar 14 '13 at 00:25
  • 3
    possible duplicate of [How can I make Chrome stop caching redirects?](http://superuser.com/questions/304589/how-can-i-make-chrome-stop-caching-redirects) – Ulrich Schwarz Jul 05 '13 at 18:25
  • Just for users coming here through google! For me, ExpressVPN chrome extension was causing the https URL redirection. Do check the recent plugin installations. – NS Gopikrishnan Jul 18 '20 at 09:15

10 Answers10

920

In addition to cached redirects, HTTP Strict Transport Security (aka HSTS) may be at play. HSTS is a security feature that forces the browser to use HTTPS even when accessing an HTTP URL.

The browser will start using HSTS for a domain after receiving a Strict-Transport-Security header from the server. The browser also ships with a list of domains for which HSTS is enabled by default.

In Chrome, there is a way to delete your domain from HSTS after it was added by the server. Though, you can’t exclude domains that are baked in the browser (this includes popular websites and notably everything under the new .dev TLD)

  1. Go to chrome://net-internals/#hsts. Enter example.com under Delete domain security policies and press the Delete button.

  2. Now go to chrome://settings/clearBrowserData, tick the box Cached images and files and press click the button Clear data.

Alex Jasmin
  • 474
  • 4
  • 13
ducpho
  • 9,317
  • 1
  • 11
  • 6
  • 3
    This helped me as well!!! While developing internally and having the same problem of the redirect! – Marcello de Sales Jul 12 '15 at 03:11
  • 5
    Man, this had been bugging me for ages, finally got it, thanks! A potential gotcha of note: If the domain you're having trouble with is a subdomain you may need to delete the primary domain from the HSTS set if "include subdomains for STS is set to true". If you run a query on the parent domain you should see if that's set or not for the domain in question. – Pooch Jan 06 '16 at 17:40
  • 25
    This only worked for me after I also cleared my browser cache. In chrome: **Settings > Show advanced settings… > Privacy > Clear browsing data...** [Source](https://anhsblog.com/blog/make-chrome-stop-redirect-from-http-to-https/#.WXGeJojyuUl) – nittyjee Jul 21 '17 at 06:30
  • 2
    This is now found under the **Domain Security Policy** menu item on the left of the page – Brice Nov 06 '17 at 17:14
  • hsts has been removed from the menu. It is hidden in chrome://net-internals/#hsts – Nick Nov 14 '17 at 20:15
  • 21
    Since 63.0.3239.132 this does nothing. The rule seems to be disregarded and even custom domains that link to localhost is now redirected to https. Annoying factor to have to use self-signed certificates for everything... – Daniel Jan 05 '18 at 08:59
  • @Daniel working with 64.0.3282.186 and works as expected. The only weird is, it doesnt notice you when sometings happend. I entered all pages i called (`http://foobar.xo, https://foobar.xo, foobar.xo, foobar.xo/helloWorld`) than finaly it worked again. – Dwza Mar 20 '18 at 10:23
  • It seems to work fine also with Chrome 66 and deprecated Symantec's certs. – Dragan Marjanović Apr 20 '18 at 09:31
  • yeah seems google and firefox now have non-standard redirects to https, rendering both browsers leaning on internal rules that only apply to google internal developers. aka not internet standard, google internal it policy on the world. #losers – Dawesi Aug 19 '18 at 12:22
  • 1
    A comment on @nittyjee : not not loose your precious browsing-history and cookies, in Chrome you may just clear "cached files and images". – ankostis Oct 10 '18 at 21:50
  • Does not work in Incognito mode. You have to restart Chrome if you opened HTTPS version of website in Incognito mode and want to keep all other tabs opened :( – izogfif Nov 09 '18 at 12:02
  • @ducpho What exactly is `domain security policies`? I am testing something, if I delete it, will the browser create it again? Am I safe in deleting it? What will I lose? Edit: nevermind, I read this answer and I got my questions answered: https://superuser.com/questions/565409/how-to-stop-an-automatic-redirect-from-http-to-https-in-chrome/950424#950424 – Shayan Aug 12 '19 at 16:54
  • 2
    You can avoid clearing all of your browsers cache(!) by keeping the network tab open in Developer tools and checking **Disable cache**. Works only for that site, you don't need to redownload hundreds of MB of JavaScript. – cswilby Apr 08 '20 at 15:34
  • 2
    None of the solutions are working for me. Chrome 85.0.4183.83 on Ubuntu 20 – Michele Piccolini Sep 02 '20 at 12:50
  • Note that there is an option Time Range that you should set to "all time" , when deleting your cached data. – Allie Oct 16 '20 at 12:49
  • For me, the 2nd item (clear browser data) alone was enough to stop redirects. – Lucas Basquerotto Mar 31 '21 at 22:49
  • Just worked for me. Make sure to use the domain name e.g example.com im on macOS big sur with Version 101.0.4951.64 (Official Build) (x86_64) – Mark May 16 '22 at 16:43
  • 1
    Adding this registry value fixes it for me: `Windows Registry Editor Version 5.00` `[HKEY_CURRENT_USER\SOFTWARE\Policies\Google\Chrome\HSTSPolicyBypassList]` `"1"="localhost"` – Daniel Gehriger Jun 01 '22 at 09:15
  • This works for a while, then If I look again - I have to delete it again. Any way to permanently stop it from adding `localhost` to the `domain security policies`? – Pierre Feb 07 '23 at 08:32
260

My problem came from having a .dev domain, which was apparently recently registered as a gTLD and put in a commit to Chrome Canary. I found this out from a recent post I came across as I searched for my problem.

If you have the same problem I do, it appears that the best solution is to change your domain to be something other than .dev. The article suggested .test with a potential solution of .localhost later down the road (via this proposal).

Community
  • 1
Louie Bertoncin
  • 2,701
  • 1
  • 8
  • 5
  • 50
    This was the issue for me as well. On my local development machine I utilized .dev for almost 10 years now. I did a recent Google Chrome update and it started redirecting all of my sites to https for no reason I could understand. Would have never thought it had to do with the .dev, then I came across this answer and changed it to .development and all works well again ... For now :-) . Thanks again! – conrad10781 Dec 08 '17 at 20:04
  • 22
    Perfect! I don't understand why Chrome will do something like that, it's very annoying as I have nearly 30 .dev domains in my local. Hope it's a very, very good reason. – Pablo Ezequiel Leone Dec 11 '17 at 09:00
  • 4
    I have wordpress installed, changing its domain might be a real headache. same for the main directory name ect. is there any other way around? – Rick Sanchez Dec 11 '17 at 16:26
  • 9
    It's because Google bought `.dev` and presumably will start making public sites using it. – Hilton Shumway Dec 11 '17 at 18:41
  • 1
    Thank you! Please upvote this for visibility. Very annoying change indeed. p.s. quickest solution is switching to safari :p sorry chrome! – e_x_p Dec 11 '17 at 19:49
  • 23
    FML… I almost gave up on my 10+ year web dev career because of this. #starbucksbarista – elbowlobstercowstand Dec 13 '17 at 22:34
  • 3
    Absolutely preposterous of google to effectively kill its usage for local machine development. If google.dev is directed elsewhere, the user or the tech knows why it's set that way. **Google should have at least put a note on the page **_If you're using .dev, do this..._** – Regular Jo Dec 20 '17 at 18:13
  • Looks like Safari is doing the same thing. – bob Dec 21 '17 at 05:04
  • Can't use `.localhost` (or for that matter, any non-registered TLD.. ironically this is what allowed us to use `.dev` until now) with Google OAuth because their API throws "Invalid Redirect: ... must end with a public top-level domain (such as .com or .org)". This might force us to use Firefox exclusively for development, except that we least need to QA in Chrome. So for now, we're just using http://localhost/ as fundamentally recommended by that RFC. It's so fascist... – Charney Kaye Dec 31 '17 at 22:43
  • Not a quick fix but a work-around for testing Chrome, Safari, etc. is to use Docker and place your web server, etc. in a Docker instance. Not ideal for the short term, but long term it may be more beneficial. I too have been using the .dev to map to localhost on Linux for years now. Very annoying... – RyanNerd Jan 02 '18 at 22:15
  • 1
    Oh, so it **was** an issue with Chrome after all. I couldn't find anything of note in the changelogs and on the web. Things still work well in Firefox, IE and Edge, so I thought Chrome (and Opera) had broken something pretty bad, and I was tearing my hair thinking why clearing stuff from `chrome://net-internals/#hsts` or `chrome://net-internals/#dns` weren't working!! Thanks for the answer. – kumarharsh Jan 17 '18 at 07:13
  • a billion points to you! – dangel Jan 19 '18 at 00:01
  • 2
    If you're running a local VM with a separate IP, don't use `.localhost` and use something like `.test` instead. On macOS [`.localhost` will skip the hosts file and directly route to local loopback](https://serverfault.com/a/882032/223294) and be inaccessible. – mopsled Jan 25 '18 at 08:54
  • Tried everything else and this was the exact issue! Thanks a bunch. For anyone else using `valet`, you can switch your domain extension via `valet domain test` (where test is the extension you would like to use) – David Feb 04 '18 at 19:22
  • I'm experiencing the same issue as well. What the hell is wrong with Chrome developers?! – Slavik Meltser Mar 25 '19 at 01:57
  • Firefox appears to be doing this for me, too. It's not happening in safari, though. – StevieD Apr 12 '19 at 15:01
  • 1
    A day and a half gone forever for this to be the answer. May the gods of the votings have the favors upon you. – Code Maverick Apr 26 '19 at 21:55
  • What a bad design. Not only did they hijack the .dev domain, they force https on it? I have purchased a dev domain specifically for development and testing, now I can't test something as basic as a plain http site – Maciej Krawczyk Sep 06 '21 at 06:46
  • Same issue using `dev.` at the beginning of the domain. Fixed using `.test` – Alessio Innocenzi Mar 30 '22 at 08:39
32

To delete domain under "HSTS" menu in chrome://net-internals is a temporary solution. After visiting this domain over HTTPS it will be included in HSTS list again.

Basicaly, to solve this issue it is necessary to disable HTTP Strict Transport Security on the web-server 3rdrevolution.com (IIS, Apache, nginx,...). For nginx edit its HTTPS section in nginx.conf and set 'max-age=0' for Strict-transport-Security:

server {
#...
        ssl on;
#...
        add_header Strict-Transport-Security "max-age=0;";
#...
}

More info: HTTP Strict Transport Security (HSTS)

Uwe Keim
  • 2,062
  • 8
  • 31
  • 52
user2285323
  • 81
  • 2
  • 4
  • I wasn't able to get the add_header method to work. – Alex Barker Jan 26 '16 at 06:49
  • for me the server did not issue a HSTS header so this is not a solution. From what I can tell, chrome recorded when I accidentally visited it with https and created an internal HSTS record that then mysteriously redirected me to https everytime. Fix was to use the delete HSTS record in chrome:net-internals. Had a handy checker in there as well. – rob May 15 '17 at 13:53
  • 2
    To delete HSTS record is a temporary solution. You will get this record in chrome again and again after visit https untill server send "max-age=0". – user2285323 May 16 '17 at 17:46
22

https://www.3rdrevolution.com sends the Strict-Transport-Security header so accessing it over https once will make browsers like Chrome/Firefox redirect http requests to https until some specified point in the future.

As the other answer said, the only way to stop this once it starts is to clear the browser cache (or wait for the browser to expire the order).

gronostaj
  • 55,965
  • 20
  • 120
  • 179
Anon
  • 1,299
  • 12
  • 15
15

There could be a couple of reasons for this, including plugins but assuming that you do not have any plugins installed you can do the following:

Goto Settings/Privacy/Clear Browsing Data...

Select The Beginning of Time in the pull down.

Select:

  • Clear saved Autofill form data
  • Delete cookies and other site and plug-in data
  • Empty the cache

Select Clear Browsing Data

This should take care of it doing any Auto-fill based on your previous browsing. Also, it will remove any of the cookies that could also be causing problems.

Atari911
  • 768
  • 4
  • 11
11

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

None of the option fixes worked for me, for fixing https://localhost:3000, this did.

Click and hold reload button and select “Empty Cache and Hard Reload,” this seems to only be an option on localhost.

Screenshot of the “Empty Cache and Hard Reload” option.

Giacomo1968
  • 53,069
  • 19
  • 162
  • 212
user2167582
  • 255
  • 3
  • 11
  • 5
    To make this work on Chrome `Version 77.0.3865.90 (Official Build) (64-bit)` (MacOS), I had to do this **[1]** (after opening problematic page) Right click anywhere and click on `Inspect` **[2]** After the inspect frame appears, click and hold on `reload` button **[3]** in the drop-down that appears, click on `Empty Cache and Hard reload` – y2k-shubham Sep 27 '19 at 07:55
7

If you are facing the problem on a subdomain then this line in Nginx might cause a problem even if the subdomain is in another server, as the browser will cache this information.

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

so remove the includeSubdomains; of it to make it work.

khelll
  • 383
  • 1
  • 5
  • 10
5

A less drastic alternative than clearing all cookies ever is Settings>Show advanced settings>Content Settings>All Cookies and site data then search for the sites in question and clear cookies for only those.

pseudosudo
  • 160
  • 1
  • 4
  • Thanks this works perfectly. I don't know why Chrome makes this such a hidden feature.....well actually, I can guess why... – ktec Dec 06 '16 at 10:05
  • 1
    this doesn't seem to work with current Chrome version. – Vylix Jul 17 '18 at 03:01
4

Before few days I accidentally turned on Chrome options named:

  • Automatically send some system information and page content to Google to help detect dangerous apps and sites
  • Protect you and your device from dangerous sites

And now the main problem was that our website on subdomain always redirect from http:// to https:// and browser gave me an error:

"Your connection is not private. Attackers might be trying to steal your information from censored.censored.com (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID"

Open chrome://settings/privacy and turn previously named chrome options that automatically protect your devices. Hope this will help someone.

hrvojematijevic
  • 41
  • 3
2

in Chrome 66, lots have changed in the Settings tab

you can just go to chrome://settings/resetProfileSettings?origin=userclick then hit reset.

this worked for me.

nljms
  • 29
  • 2