Firefox和Chrome在本地主机上运行缓慢;已知修复不能在Windows 7上工作

时间:2022-08-23 11:45:30

Firefox and Chrome are known to be slow on localhost when IP6 is enabled. In previous versions of Windows, the simplest fix is to comment out this line from the hosts file, as explained in the answer to this question.

当启用IP6时,Firefox和Chrome在本地主机上运行缓慢是众所周知的。在Windows以前的版本中,最简单的解决方法是从主机文件中注释这一行,正如在这个问题的答案中所解释的那样。

::1 localhost

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

然而,正如在这个问题中提到的,在Windows 7中,这一行已经被注释掉了:

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

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

是否有其他方法可以禁用Windows 7中的::1 localhost引用?

9 个解决方案

#1


59  

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

如果您取消对主机文件中的127.0.0.1行的注释,那么Chrome将在本地主机url上恢复正常运行。

# localhost name resolution is handled within DNS itself.
    127.0.0.1 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.

通常在C:\WINDOWS\system32\drivers\etc\hosts.主机文件要在Win7中编辑它,您需要以管理员的身份运行记事本。

#2


22  

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

事实证明,慢度是由与DNS的IPv6问题引起的,并且可以通过在进行本地主机测试时在Firefox中启用IPv6支持来轻松解决。要进行更改,输入

about:config 

in the address bar, locate the

在地址栏中,找到

network.dns.disableIPv6

setting and double-click on it to set it to true. This does the trick for the Firefox localhost issue on Vista and everything is running fast again.

设置并双击它将其设置为true。这对Vista上的Firefox localhost问题很有帮助,而且一切都运行得很快。

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

http://kb.mozillazine.org/Network.dns.disableIPv6拥有所有你可能需要的信息——祝你好运!

#3


3  

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)

我遇到了一个奇怪的问题,只有我的一个本地域名反应缓慢,而其他所有的域名都反应良好。不知道为什么,最后把::1本地主机放在我另一个下面:::1某某东西。本地和它立即澄清,以前我有它上面的其他条目。(我正在运行OS X 10.8.3)

My final hosts file wound up looking something like this:

我最后的主机文件看起来是这样的:

127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 something.local
::1 something2.local
::1 something3.local
::1 localhost
fe80::1%lo0 localhost

#4


2  

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

我会按照蒂姆·施耐德所说的去做。这里的James也提到了:http://themmemrjames.blogspot.com/2010/09/firefox -is really slow-test -sites-on.html

"Double-click on ipv4OnlyDomains, and type localhost "

“双击ipv4onlydomain,并输入localhost”

Jay

周杰伦

#5


0  

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

正如其他人在另一个答案中指出的那样——如果您有bitdefender,那么它将会愉快地破坏您的开发体验。

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

最好打开位保护控制台,输入alt-shift-control-g(将其设置为“游戏模式”)并从那里运行。

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

在游戏模式下,bitdefender不会锁定你的本地主机!

#6


0  

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.

这并不是一个直接的答案,但我也遇到了同样的问题,上面提到的IPv6和主机文件更改对我都不起作用。我的asp.net MVC4项目在按下F5刷新localhost上的js更改后非常慢。它发生在所有浏览器上——Chrome、FF和IE。最后我发现IIS Express 8.0是在我不知情的情况下安装的,而且在提供js文件时,8.0速度非常慢,似乎是一个bug。如果我在命令行上运行iisexpress并点击F5,我可以看到每个js文件加载需要4到5秒。

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 8.0,安装了IIS express 7.5,问题立刻得到了解决。以下是我遵循的步骤:

  • Uninstall IIS express 8.0
  • 卸载IIS express 8.0
  • Delete the IISExpress folder (on Win 7 it's in My Documents\IISExpress)
  • 删除IISExpress文件夹(在win7上它在我的文档中,\IISExpress)
  • Install IIS express 7.5 (Link to IIS Express 7.5 download)
  • 安装IIS express 7.5(连接到IIS express 7.5下载)

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.

IIS Express 8.0似乎是与VS 2012一起安装的,所以如果您有一个新的安装,或者可能有一个服务包更新,这可能已经升级了您以前的IIS Express版本。

#7


0  

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

我在主机中有几个条目(因为我正在运行虚拟服务器)。以前我有

127.0.0.1        localhost
127.0.0.2      i.localhost
127.0.0.3 secure.localhost

What seems to work better but not perfect is this:

看起来更好但不完美的是:

127.0.0.1 localhost secure.localhost i.localhost

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

我建议关闭浏览器,关闭Apache,在测试时按相反顺序重新启动。

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.

如果你关闭WiFi(即关闭外部互联网饲料),例如,如果你有Chrome,FireFox和其他浏览器可能开放的同时,如果页面上的Chrome窒息,得到旋转销轮,你试着在那一刻也从另一个浏览器加载一个文件,(从localhost)它还将挂起,直到Chrome最终超时(或任何)最后完成许多秒以后,即使是简单的页面。

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.

这也发生在IE阻塞和阻塞从其他浏览器的访问。我已经试过很多次了,我确信这是一件很有趣的事情。

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.

不同的浏览器进程之间似乎存在着某种联系。我不想这么说,但我怀疑windows IP堆栈中有一个bug,这听起来是不可能的。另一种可能性是,chrome只是让ip栈陷入僵局,或者锁定一些文件,让其他人无法使用它。

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.

同样值得注意的是,当chrome被冻结时,你可以重新启用WiFi,就像互联网连接之后,chrome或IE也会被关闭一样,其他浏览器也会被屏蔽。

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

如果你问我,那就有点奇怪了。如果您正在处理本地主机,则不应该与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.

我尝试过使用WireShark来查看到底发生了什么,但是它很混乱,到目前为止我还不能确定任何包。

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.

我已经删除了。htaccess,并放置了一个httpd。conf,其中具有与默认值相比最小的更改。

I'm running Win7x64Pro, Apache 2.4.7.

我运行的是Win7x64Pro, Apache 2.4.7。

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

顺便说一句,这不是php。这点我很确定。

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).

还锁ups似乎发生在R ^(加载页面),不浏览到页面上,而其他页面组件需要检查当前,像菜单精灵(图片)。这将是有304状态的地方(使用HttpFox来查看这些)。

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.

同样,如果您快速地重新加载相同的页面,那么它工作的可能性就会更高。如果你再等一分钟,它就会再次出现。我怀疑chrome从短期的案例中得到了结果,这在一定程度上掩盖了更深层次的问题。

#8


0  

A bit late for an answer but i tried all of the above and still it was slow for me on Windows 7. When I use localhost it took about 20+ secs for page load.

虽然回答有点晚,但我尝试了以上所有的方法,但Windows 7对我来说还是很慢。当我使用localhost时,页面加载大约需要20+秒。

Firefox improved with @Mark Mayo's answer but not all the time and Chrome was still very slow.

Firefox改进了@Mark Mayo的答案,但并不是一直如此,Chrome仍然很慢。

I found a solution here

我找到了一个解

Basically, i added the following lines to Apache httpd.conf file (as they weren't there already)

基本上,我将以下代码添加到Apache httpd中。conf文件(因为它们还不存在)

AcceptFilter http none 
AcceptFilter https none 
EnableSendfile off 
EnableMMAP off

Tested both Chrome and Firefox and the page loads instantly

测试了Chrome和Firefox,页面立即加载

#9


0  

Just Try "Incognito" mode on Chrome and "Private Mode" on Firefox.

在Chrome上尝试“隐身”模式,在Firefox上尝试“私有模式”。

I know this not should be a correct answer. But you can use this as a temporary solution.

我知道这不是一个正确的答案。但您可以将其用作临时解决方案。

#1


59  

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

如果您取消对主机文件中的127.0.0.1行的注释,那么Chrome将在本地主机url上恢复正常运行。

# localhost name resolution is handled within DNS itself.
    127.0.0.1 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.

通常在C:\WINDOWS\system32\drivers\etc\hosts.主机文件要在Win7中编辑它,您需要以管理员的身份运行记事本。

#2


22  

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

事实证明,慢度是由与DNS的IPv6问题引起的,并且可以通过在进行本地主机测试时在Firefox中启用IPv6支持来轻松解决。要进行更改,输入

about:config 

in the address bar, locate the

在地址栏中,找到

network.dns.disableIPv6

setting and double-click on it to set it to true. This does the trick for the Firefox localhost issue on Vista and everything is running fast again.

设置并双击它将其设置为true。这对Vista上的Firefox localhost问题很有帮助,而且一切都运行得很快。

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

http://kb.mozillazine.org/Network.dns.disableIPv6拥有所有你可能需要的信息——祝你好运!

#3


3  

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)

我遇到了一个奇怪的问题,只有我的一个本地域名反应缓慢,而其他所有的域名都反应良好。不知道为什么,最后把::1本地主机放在我另一个下面:::1某某东西。本地和它立即澄清,以前我有它上面的其他条目。(我正在运行OS X 10.8.3)

My final hosts file wound up looking something like this:

我最后的主机文件看起来是这样的:

127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 something.local
::1 something2.local
::1 something3.local
::1 localhost
fe80::1%lo0 localhost

#4


2  

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

我会按照蒂姆·施耐德所说的去做。这里的James也提到了:http://themmemrjames.blogspot.com/2010/09/firefox -is really slow-test -sites-on.html

"Double-click on ipv4OnlyDomains, and type localhost "

“双击ipv4onlydomain,并输入localhost”

Jay

周杰伦

#5


0  

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

正如其他人在另一个答案中指出的那样——如果您有bitdefender,那么它将会愉快地破坏您的开发体验。

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

最好打开位保护控制台,输入alt-shift-control-g(将其设置为“游戏模式”)并从那里运行。

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

在游戏模式下,bitdefender不会锁定你的本地主机!

#6


0  

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.

这并不是一个直接的答案,但我也遇到了同样的问题,上面提到的IPv6和主机文件更改对我都不起作用。我的asp.net MVC4项目在按下F5刷新localhost上的js更改后非常慢。它发生在所有浏览器上——Chrome、FF和IE。最后我发现IIS Express 8.0是在我不知情的情况下安装的,而且在提供js文件时,8.0速度非常慢,似乎是一个bug。如果我在命令行上运行iisexpress并点击F5,我可以看到每个js文件加载需要4到5秒。

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 8.0,安装了IIS express 7.5,问题立刻得到了解决。以下是我遵循的步骤:

  • Uninstall IIS express 8.0
  • 卸载IIS express 8.0
  • Delete the IISExpress folder (on Win 7 it's in My Documents\IISExpress)
  • 删除IISExpress文件夹(在win7上它在我的文档中,\IISExpress)
  • Install IIS express 7.5 (Link to IIS Express 7.5 download)
  • 安装IIS express 7.5(连接到IIS express 7.5下载)

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.

IIS Express 8.0似乎是与VS 2012一起安装的,所以如果您有一个新的安装,或者可能有一个服务包更新,这可能已经升级了您以前的IIS Express版本。

#7


0  

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

我在主机中有几个条目(因为我正在运行虚拟服务器)。以前我有

127.0.0.1        localhost
127.0.0.2      i.localhost
127.0.0.3 secure.localhost

What seems to work better but not perfect is this:

看起来更好但不完美的是:

127.0.0.1 localhost secure.localhost i.localhost

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

我建议关闭浏览器,关闭Apache,在测试时按相反顺序重新启动。

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.

如果你关闭WiFi(即关闭外部互联网饲料),例如,如果你有Chrome,FireFox和其他浏览器可能开放的同时,如果页面上的Chrome窒息,得到旋转销轮,你试着在那一刻也从另一个浏览器加载一个文件,(从localhost)它还将挂起,直到Chrome最终超时(或任何)最后完成许多秒以后,即使是简单的页面。

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.

这也发生在IE阻塞和阻塞从其他浏览器的访问。我已经试过很多次了,我确信这是一件很有趣的事情。

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.

不同的浏览器进程之间似乎存在着某种联系。我不想这么说,但我怀疑windows IP堆栈中有一个bug,这听起来是不可能的。另一种可能性是,chrome只是让ip栈陷入僵局,或者锁定一些文件,让其他人无法使用它。

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.

同样值得注意的是,当chrome被冻结时,你可以重新启用WiFi,就像互联网连接之后,chrome或IE也会被关闭一样,其他浏览器也会被屏蔽。

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

如果你问我,那就有点奇怪了。如果您正在处理本地主机,则不应该与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.

我尝试过使用WireShark来查看到底发生了什么,但是它很混乱,到目前为止我还不能确定任何包。

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.

我已经删除了。htaccess,并放置了一个httpd。conf,其中具有与默认值相比最小的更改。

I'm running Win7x64Pro, Apache 2.4.7.

我运行的是Win7x64Pro, Apache 2.4.7。

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

顺便说一句,这不是php。这点我很确定。

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).

还锁ups似乎发生在R ^(加载页面),不浏览到页面上,而其他页面组件需要检查当前,像菜单精灵(图片)。这将是有304状态的地方(使用HttpFox来查看这些)。

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.

同样,如果您快速地重新加载相同的页面,那么它工作的可能性就会更高。如果你再等一分钟,它就会再次出现。我怀疑chrome从短期的案例中得到了结果,这在一定程度上掩盖了更深层次的问题。

#8


0  

A bit late for an answer but i tried all of the above and still it was slow for me on Windows 7. When I use localhost it took about 20+ secs for page load.

虽然回答有点晚,但我尝试了以上所有的方法,但Windows 7对我来说还是很慢。当我使用localhost时,页面加载大约需要20+秒。

Firefox improved with @Mark Mayo's answer but not all the time and Chrome was still very slow.

Firefox改进了@Mark Mayo的答案,但并不是一直如此,Chrome仍然很慢。

I found a solution here

我找到了一个解

Basically, i added the following lines to Apache httpd.conf file (as they weren't there already)

基本上,我将以下代码添加到Apache httpd中。conf文件(因为它们还不存在)

AcceptFilter http none 
AcceptFilter https none 
EnableSendfile off 
EnableMMAP off

Tested both Chrome and Firefox and the page loads instantly

测试了Chrome和Firefox,页面立即加载

#9


0  

Just Try "Incognito" mode on Chrome and "Private Mode" on Firefox.

在Chrome上尝试“隐身”模式,在Firefox上尝试“私有模式”。

I know this not should be a correct answer. But you can use this as a temporary solution.

我知道这不是一个正确的答案。但您可以将其用作临时解决方案。