Take the 2-minute tour ×


::1 localhost

However, as noted in this question, in Windows 7 this line is already commented out:

# localhost name resolution is handled within DNS itself.
# localhost
#   ::1 localhost

Is there an alternative way to disable the ::1 localhost reference in Windows 7?

share|improve this question
BTW I noticed a similar question was moved to SuperUser - I think this is the sort of problem only a programmer would have an answer to, since no one else uses localhost in the browser routinely; so I hope you'll let me leave it here. I posted this question sometime ago to SuperUser and got absolutely nothing. superuser.com/posts/65049 –  Herb Caudill Nov 13 '09 at 1:32
Would this not be better suited to superuser.com, as it's not particularly programming related? –  Mark Mayo Nov 13 '09 at 1:34
This is an issue that slows down developers if not resolved. I vote to keep it here. Anyone know if this is an issue google / ff is working to resolve? –  kiev May 28 '10 at 16:40
I had this issue after upgrading my dev system to Win 7. Spent hours debugging my web server code, trying to figure out why it was so slow delivering documents, before I tracked it down to DNS and realized it was the resolution of localhost. It's definitely a developer question. –  Lawrence Dol Oct 29 '10 at 19:34
IE9 I found was also slow. –  Orion Edwards Jul 18 '11 at 20:50
show 1 more comment

7 Answers

up vote 48 down vote accepted

Turns out if you uncomment the line in the hosts file, Chrome goes back to its snappy self on localhost URLs.

# localhost name resolution is handled within DNS itself. localhost

The hosts file is typically at C:\WINDOWS\system32\drivers\etc\hosts. To edit it in Win7, you'll need to run Notepad as administrator.

share|improve this answer
+1, Thanks for this -- made a huge differece in my loading times (5-10 seconds to <1 second). –  Jerad Rose May 19 '10 at 15:58
I presume this also works for FF; or do you have to add local host to the IPV4 only domains for FF. –  Lawrence Dol Oct 29 '10 at 19:32
I have Windows 7, and it works for FF too, which negates the need to disable IPv6 in FF itself. –  Moose Factory Nov 25 '10 at 9:56
add comment

Still think it belongs on superuser, but looked it up anyway as I'm a FF fan :) It turns out that the slowness is caused by an IPv6 issue with DNS and can easily be resolved by turning IPv6 support off in Firefox while doing localhost testing. To make the change, type


in the address bar, locate the



http://kb.mozillazine.org/Network.dns.disableIPv6 has all the info you probably need - good luck!

share|improve this answer
Great, thanks. I tried this and it works. I'd still like to see a solution for Chrome. –  Herb Caudill Nov 13 '09 at 2:48
This is a well known FF issue. I always turn ipv6 off on my local dev machine. –  Pure.Krome Jun 1 '10 at 0:00
Personally I prefer adding localhost to network.dns.ipv4OnlyDomains rather than turning off ipv6 entirely. I know it doesn't make much difference now but I can't shake the feeling I'll forget I did this some day and wonder why ipv6 sites won't load –  fyjham Jun 1 '10 at 0:17
Tim's approach is better, see kb.mozillazine.org/Network.dns.ipv4OnlyDomains and another review here: dotnetslackers.com/ASP_NET/… –  James Baker Dec 9 '10 at 3:58
this didn't work for me :( –  bharal Jun 1 '12 at 1:49
add comment

I'd do what Tim Schneider mentioned. Also mentioned by this James here: http://theycallmemrjames.blogspot.com/2010/09/firefox-is-really-slow-testing-sites-on.html

"Double-click on ipv4OnlyDomains, and type localhost "


share|improve this answer
add comment

I ran into a strange issue with only one of my local domains being slow while all the others responded just fine. Couldn't figure out why and finally put ::1 localhost at the bottom underneath my other ::1 something.local and it instantly cleared up, where previously I had it above the other entries. (I'm running OS X 10.8.3)

My final hosts file wound up looking something like this: localhost broadcasthost
::1 something.local
::1 something2.local
::1 something3.local
::1 localhost
fe80::1%lo0 localhost
share|improve this answer
Brilliant! Worked for me on osx –  DudeOnRock Feb 26 at 10:12
add comment

As someone else noted in a different answer - if you have bitdefender, then that will merrily ruin your development experience.

Best to open the bit defender console, enter alt-shift-control-g (which puts it in "game mode") and run from there.

in game mode, bitdefender won't bollocks up your localhost!

share|improve this answer
add comment

This isn't a direct answer but I had the same problem and none of the above IPv6 or hosts file changes worked for me. My asp.net MVC4 project was really slow after hitting F5 to refresh js changes on localhost. It was happening across all browsers - Chrome, FF, and IE. Eventually I found out that IIS Express 8.0 got installed without me realising, and it turns out 8.0 is extremely slow when serving up js files and seems to be a bug. If I ran iisexpress on the command line and hit F5 I could see each js file took 4 or 5 seconds to load.

I ended up uninstalling IIS 8.0 and installing IIS express 7.5 and straight away the problem was fixed. Here are the steps I followed:

IIS Express 8.0 seems to be installed with VS 2012 so if you had a new install or possibly a service pack update this might have upgraded your previous IIS express version.

share|improve this answer
add comment

I had several entries in hosts (because I'm running virtual servers). Previously I had        localhost      i.localhost secure.localhost

What seems to work better but not perfect is this: localhost secure.localhost i.localhost

I suggest closing browsers, shutting down Apache, the restarting in reverse order when testing.

So far none of the fixes have worked very well for me. The problem remains intermittent. ..

However I noticed something interesting and figured I'd share in hopes that someone else can add to this.

If you shut off WiFi (i.e. turn the external internet feed off), and if you have for example, Chrome, FireFox and possibly other browsers open at the same time, and if Chrome chokes on a page, and you get the spinning pin wheel, and you try at that moment to also load a file from another browser, (from localhost) it will also hang until chrome finally times out (or whatever) and finally finishes many seconds later, even for simple pages.

This also happens with IE choking and blocking accesses from other browsers. I've tried this many times and I'm convinced there is something very funny going on.

There seems to be a link between the different browser processes. I hate to say this but I suspect there is a bug in the windows IP stack, as impossible as that sounds. The other possibility is that chrome is just bogging down or hogging the ip stack, or locking some file, so that others can't use it.

Also very interesting to note, is that if while chrome is frozen up, you re-enable WiFi, just as soon as the internet connects then chrome or IE finishes, along with whatever other browsers are also blocked.

That's sort of strange if you ask me. If you are working off of localhost there should be NO interaction with the internet.

I've tried to use WireShark to see what's going on, but it's confusing and so far I have not been able to nail down any packets involved.

There is something very funny going on.

I've deleted my .htaccess, and put an httpd.conf in which has the very minimum changes from the defaults.

I'm running Win7x64Pro, Apache 2.4.7.

BTW, it's not a php thing. Am sure about that at this point.

Also the lock ups seem to happen on ^R (page reload), not on browse to page, and where other page components need to be checked for current, like menu sprites (images). This would be where there is a 304 status (use HttpFox to see these).

Also, if you quickly reload the same page the chance that it will work is much higher. If you wait for a minute then it often gags again. I suspect chrome is getting results out of a short term cashe which is partly masking a deeper issue.

share|improve this answer
add comment

Your Answer


