The Problem: Lost Connection Between WSL and Browser
The other day, I faced an issue where my connection between Windows Subsystem for Linux (WSL) and my browser was lost. This happened late in the day, and I hoped a simple restart of Windows would resolve it by the next morning. We've all been there, right? Unfortunately, the restart didn't help, so I had to dig deeper.
The Solution: Chrome's HSTS Policy
I'll spare you the details of my troubleshooting journey—from checking the hosts file to running updates. In the end, the solution was surprisingly simple yet unexpected.
Chrome had decided that the localhost domain could only be accessed over a secure connection, enforcing SSL for all calls. This subtle change wasn't immediately obvious. After discussing the issue with a colleague, they suggested trying to connect over HTTP instead of HTTPS. However, when I entered http://localhost:9000, it automatically switched to https://localhost:9000.
This behaviour is due to Chrome's implementation of HTTP Strict Transport Security (HSTS). According to Wikipedia, "HTTP Strict Transport Security (HSTS) is a policy mechanism that helps protect websites against man-in-the-middle attacks and cookie hijacking. It ensures that browsers interact with sites only over HTTPS connections, providing Transport Layer Security (TLS/SSL)."
To resolve this, we need to remove the localhost domain from Chrome's HSTS policy. Here's how:
- Open Chrome and go to chrome://net-internals/#hsts.
- Under "Delete domain security policies", enter localhost and press "Delete".
This action prevents Chrome from redirecting localhost to HTTPS, solving the problem.
A Helpful Tip
One of my colleagues mentioned that the Firefox browser doesn't have this issue. So, if you encounter similar problems, you might want to give FirefoxFirefox a try.
Until next time!