Simulate manipulation of the etc/hosts file in Google Chrome

How can I set up Chrome to reference hostname lookups locally and not from the standard etc/hosts file?

When debugging a website, it's sometimes useful to set up entries in C:\Windows\system32\drivers\etc\hosts that replace certain domains with localhost, thus allowing me to test out on-the-fly versions of websites or domains that may conflict with live actual sites.

Can I set up Google Chrome in a way that simulates and simplifies this process?

I won't to modify the browser instance to behave as if etc/hosts has been modified although even that might be too much of a security risk in an extension.

Solution 1:

I just found the Host Switch Plus Chrome Extension which does exactly that ;)

Solution 2:

One way to achieve your actual goal does not involve Chrome extensions, or even Chrome, at all. That way is to set up an intelligent proxy HTTP server, point Chrome at it, and then add rewriting rules to the proxy server that rewrite URLs under the covers.

There are many people who do this, with various different proxy HTTP servers — too many to cover each in detail in an answer here. They do so for purposes of zapping advertisements, web bugs, and suchlike, but the principle and the mechanism are identical to what you want to do. They want the WWW browser to fetch a particular URL as normal, but the actual content that it receives to be that of some other (local or otherwise) URL. The only thing that the WWW browser needs to know is that it talks to Internet via a proxy server.

For one example, see the Ad Zapper at SourceForge. That's a Perl script that works in conjunction with the Squid proxy HTTP server to rewrite URLs on the fly in the proxy server. As you can see from its configuration database, people have employed its mechanism for a wide range of purposes, from ensuring that one always sees the "printable" forms of articles on news services to getting rid of the randomized advertising redirections on Internet pornography sites.

Note that this is far better than what you are doing with the hosts file, which is an unsuitable mechanism for manipulating WWW service. hosts only deals in name→address lookups, mucks up everything else (outwith the WWW browser) that needs to do name→address lookups, and (as you probably know already) requires every rewritten host name to be additionally set up as a virtual host on the target content HTTP server. A rewriting proxy HTTP server of this sort, in contrast, deals in URLs and only affects HTTP and the WWW browsers configured to use it in the first place. So it can do things like only rewrite the JavaScript URLs and leave everything else from the same WWW site alone; rewrite a whole load of hostnames to just one; and do (yet further) pattern matching. (There are instances of this very thing in Ad Zapper's configuration database, notice.) And one can do things like have one WWW browser viewing the world through the rewriting proxy and another viewing it directly, on a single machine simultaneously.

Solution 3:

I used (and still use) HostAdmin religiously, but having to empty the cache or opening a new incognito window every time has always been a chore, so I ended up developing a Chrome extension for myself last year to help with a similar situation, and I recently published a very rough version of it in the Chrome Web Store, it's called LiveHosts.

The gist of it is that while @JdeBP is right and setting up a proxy would be the correct solution, it's often not an option. A Chrome extension cannot exactly replicate what happens when you change the hostfile though, so what LiveHosts does right now is:

• lets you set up multiple hostname/IP entries;
• detect requests to one of the defined hostnames;
• redirect the request to the desired IP with the appropriate HTTP Host header;
• add a visual (and ugly, I'll admit) reference in the address bar URL, which will look something like http://127.0.0.1/www.example.com/whateverelse;
• allow different host/IP pairings in different tabs at the same time.

It's not pretty, but it's good enough for the standard web developer who's trying to switch between environments quick. There are of course a few caveats:

• depending on the server, parts of a web page referring to the site URL (like href and src attributes) could be different from the original;
• window.location has a different value that can potentially throw off JavaScript snippets;
• most Cross-Origin request won't work.