Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got a bit of a weird problem and a stack of symptoms that I can't make sense of.

I have a .com domain that points to my home IP address. Inside my LAN, I use external DNS resolution, so if I perform an nslookup internally, I get my external IP rather than the LAN IP.

Here's what happens:

  • When I am at home (on a device that has an internal IP, say
  • AND I am running Chrome for Windows (running Chrome 35 atm)
  • AND I try to reach a resource using my external domain name via HTTP (e.g.

... then Chrome immediately converts the protocol to https (in the address bar) and complains about an SSL error. I can't reach the target.

It works as expected if I use the same Chrome build on an external machine (e.g. same user profile on my PC at the office). It also works locally using Internet Explorer and Firefox. It is only an issue running Chrome internally. I can reproduce this on 2 different machines, one running Windows 8.1 and the other Windows 7, and can reproduce it both on wifi and wired.

My home server runs Windows Server Essentials 2012 and I have an internal domain, but I don't think the server is involved in my issue.

I've configured my router to forward port 1880 to a Raspberry Pi device, where I have an http server listening. Outside of Chrome, I can hit and it will resolve perfectly. When I try it in Chrome, it instantly converts to https and fails (because the RPi isn't accepting SSL connections). When I use the LAN IP in Chrome it also works.

The router is running the Tomato firmware.

What's going on here?

  • It can't be a blatant Chrome setting/bug, because the same Chrome profile/version works when I am outside the LAN.
  • It can't be a local PC setting, because IE and Firefox work fine.
  • It can't be my Windows Server, because the router itself is handling the port forwarding.
  • It can't be the router, because IE and Firefox work fine.

I'm out of ideas - clearly one of my above assumptions is incorrect. Does Chrome have fancier network code that is causing unexpected behaviour in my situation? Can I have some kind of loopback issue that IE/FF are gracefully handling?

I've run out of ideas. If anyone has a suggestion for where to investigate I'd appreciate it.

Update: Another piece of data - Chrome (using the same user profile) behaves correctly when run inside a Hyper-V VM hosted on an affected machine.

Update 2: This behaviour goes away when I create a new Chrome user profile. The moment I log that profile into my Google account, however, the problem returns. It seems to be "something in the Chrome user profile" that is tied to my Google account.

share|improve this question
dunno and this may be irrelevant but does it make a difference whether you are logged in to google or not? I find if I go to it goes https if i am logged in. I also have an issue with a win xp sp2 machine running chrome, that when it tries to go to twitter it goes to https and gives en error. other browsers are fine – barlop Jun 6 '14 at 19:50
Good suggestion, @barlop! Being signed into Google or not (I used Incognito mode to test) didn't make a difference, but in checking that I discovered that this problem doesn't affect Chrome when it's run in a Hyper-V VM hosted on an affected computer. – Stefan Mohr Jun 6 '14 at 20:34
ah I just tested without being logged in (whether normal window or incognito window) and it went to https About a year ago it only went to https when logged in. – barlop Jun 6 '14 at 20:43
up vote 2 down vote accepted

Not a certainty by any means, but here's a guess:

Google Chrome (along with other modern browsers) supports the Strict-Transport-Security HTTP Header, which informs the browser that "this site is supposed to be accessed only via HTTPS, so in the future even if the user asks for HTTP give them HTTPS instead." As using HTTPS becomes more and more common, sending this header is becoming the default in new software and frameworks, as generally if HTTPS is set up at all (which it needs to be for the Strict-Transport-Security header to have any effect), it is preferable to use it for everything. Your experience leads me to think that at some point you tried to go to some page in Chrome on your domain over HTTPS, and that the application you used sent that header. So, Chrome on the affected machines has it in its Strict-Transport-Security list, so it won't allow going to non-HTTPS pages on that domain.

You don't mention ever trying to do anything on that domain ever via HTTPS, but is there a chance that you did at some point and that's when your trouble started? (The even less likely scenario is that your domain is on Chrome's compiled-in-preloaded HSTS list without you knowing.) I haven't found a way to view Chrome's Strict-Transport-Security list, so I don't know how to validate that it's the problem, but all "Chrome wants to go HTTPS and I don't know why" problems that I've seen ended up being that at some point the domain was over HTTPS and used the Strict-Transport-Security header, so that's the hypothesis I would assume for now, unless there's something else that can trigger the behavior in Chrome.

Hope that helps.

share|improve this answer
Good thinking! I found in that you can access the Chrome HSTS list by navigating to about:net-internals and changing the dropdown list to HSTS. Looks like my domain isn't in the list, but that looks similar to what's happening. – Stefan Mohr Jun 10 '15 at 19:51
Alright, well, Chrome didn't show my domain in the HSTS list when I searched, but I tried explicitly deleting it in the Delete box anyway and my problem has gone away! This might just be a quirk in the dev tools. Ugh! Thank you! – Stefan Mohr Jun 10 '15 at 19:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .