在Mac OS X Lion上解析虚拟主机非常慢


26

自从从Snow Leopard升级到Mac OS X Lion之后,我注意到解析到虚拟主机非常慢(大约3秒钟之间)。我发现了许多技巧(例如,不使用.local TLD)可以解决此问题,但是它们不适用于我的设置。

我的设置非常简单:-Apache 2(Lion附带)-启用了PHP-添加了一些虚拟主机-安装了Mail和SMTP Pear软件包

Apache的hosts文件如下所示:

127.0.0.1   localhost
255.255.255.255 broadcasthost
::1             localhost 
fe80::1%lo0 localhost
127.0.0.1   tbi.dev
127.0.0.1   www.tbi.dev
127.0.0.1   test1.tbi.dev
127.0.0.1   test2.tbi.dev
127.0.0.1   psa.dev
127.0.0.1   snd.dev

Apache的虚拟主机文件如下所示:

<VirtualHost *:80>
    DocumentRoot "/Users/Bart/Sites/tbi"
    ServerName tbi.dev
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/Users/Bart/Sites/tbi"
    ServerName tbi.dev
    ServerAlias *.tbi.dev www.tbi.dev
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/Users/Bart/Sites/psa"
    ServerName psa.dev
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/Users/Bart/Sites/sandbox"
    ServerName snd.dev
</VirtualHost>

该设置基本上与我在Snow Leopard上的设置相同,但是Apache解析虚拟主机的性能有很大不同。我运行Mac OS X Lion 10.7.2,但是在运行10.7.1时已经存在该问题。

这似乎是一个小问题,但是,当您每天访问数百次虚拟主机时,这将浪费大量时间,您可以想象。


我没有在问题描述中看到任何东西,该问题排除了诸如系统负载,网络利用率,内存利用率之类的普通问题。您说解析虚拟主机很慢。来自哪里?主机命令,还是查看服务器提供的页面?如果它完全是与DNS /主机相关的,则可以在命令行上对性能进行计时:time host snd.dev
labradort

Answers:


22

长时间的DNS超时几乎总是表明IPv6问题。

您是否需要IPv6连接来实现apache?

如果没有,我建议改变

<VirtualHost *:80>

进入

<VirtualHost 0.0.0.0:80>

或完全禁用IPv6连接。


3
+1:ipv6 DNS查找是OSX上的主要问题。由于某些晦涩的原因,OSX首先执行ipv6查找。如果超时(大约30秒),它将继续运行v4。OSX似乎不首先检查V6的/ etc / hosts,而是针对v4进行检查,但仅在v6超时后才检查。如果无法更好地禁用v6,请确保您具有完整的v6设置,包括v6 DNS。
Tonny

感谢您的回答。我不确定这是否是唯一在这里起作用的问题,但是大多数情况下,解决本地虚拟主机所需的时间减少了。
巴特·雅各布斯

我的DNS查找大约需要2-5秒才能解决,而不是30秒。所以,我不确定我的问题是什么,因为那不太可能会超时。无论如何,自从此答案进行更改以来,这是立即的。
贾斯汀

22

我刚才也遇到了这个问题。

这会将网络配置中的IPv6设置为关闭...

# list all network interfaces to get their names
networksetup -listallnetworkservices
# disable the one you want, in my case it's WiFi
networksetup -setv6off Wi-Fi

但是..不幸的是,这没有为我解决DNS解决问题(也许在系统重启后)。真正有用的是将ipv6样式的IP添加到/ etc / hosts中,如下所示:

# my original /etc/hosts ...
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1             localhost 
fe80::1%lo0 localhost

127.0.0.1 project.local

# adding this solved resolving:
fe80::1%lo0 project.local

wget http://project.local现在立即显示

Resolving project.local... 127.0.0.1
Connecting to project.local|127.0.0.1|:80... connected.

而不是在解析project.local上挂5秒钟。


您的建议就是我所需要的-只需将IPv6条目与标准一起添加到我的主机文件中127.0.0.1,问题就得到了彻底解决。
Kirk Woll

好极了!这在OS X 10.8(Mountain Lion)中有帮助。从10.6直接升级到10.8之后,我发现我的本地主机查找太久了……好像它们在解决之前就超时了。这为我解决了这个问题。谢谢!
Lothar_Grimpsenbacher 2012年

我最近遇到了这个问题,/ etc / hosts中的IPv6条目完美地修复了它。
尼尔·阿尔伯克

它,现在可以在Max OS 10.10.1上为我工作
ezmilhouse'Mar

10

MacOSX .local上,“域”已被“保留”用于多播DNS解析器(bonjour)。

这意味着查找任何以.local结尾的域将导致在/ etc / hosts 之前进行mDNS查找(最多5s)。

修正:

  1. 将您的测试域更改为其他一些TLD(例如.dev
  2. 使用dscl工具添加异常。

也为我工作...使我发疯,因为只有少数开发站点做到了这一点...低估了...所有以.local结尾的网站!在我升级到High Sierra之前,这直到我才开始发生……感谢@artur
Mfoo,

1
dscl例外策略非常漂亮。@阿图尔- bodera你的链接已过期,但他们归档他们的旧博客在github github.com/icebourg/itandme-archive/blob/master/posts/2011/08/...
lkraav

还请注意,.local是IETF提出的建议标准:tools.ietf.org/html/rfc6762如果您需要“测试”域,那么仅注册域名也是一个很好的主意,因为您可以完全控制它的方式在DNS中配置。制作了一个域名极有可能会导致域名系统的其他部分怪异的冲突(如在这种情况下的mDNS。)
詹姆斯Tikalsky

3

看一下这个博客,看看是否有帮助,特别强调问题2:

显然,终端和某些BSD Unix工具正确使用/etc/resolv.conf以及/ etc / hosts的正确顺序,然后再使用DNS服务器。但是,OS X Lion上的所有其他功能(包括您的所有应用程序)都可以反向执行!


1

有用。

我用这个解决方案

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1   localhost
255.255.255.255 broadcasthost
::1             localhost6
fe80::1%lo0 localhost

1

小牛上的相同错误。

我将本地主机定义放在的开头时已解决/etc/hosts,如下所示:

127.0.0.1 localhost project1.dev project2.dev
127.0.0.1 project3.dev project4.dev
255.255.255.255 broadcasthost
::1             localhost
fe80::1%lo0     localhost

0

我会尝试更改:

::1             localhost 
fe80::1%lo0 localhost

::1             localhost6 
fe80::1%lo0 localhost6

1
不幸的是,这不能解决问题。您能否说出建议背后的逻辑是什么?谢谢您的回应。
巴特·雅各布斯

最近,我为不运行IPV6但在/ etc / hosts中具有类似条目的计算机进行的snmp响应进行了长时间的争夺。现在想到的是名称服务器超时-尽管有点奇怪,因为主机应优先于绑定。(当然可以这样配置)。
外星生命表格,

确实很奇怪。有时,解析主机是瞬时的(正如一个人所期望的),而在其他主机上,则可能需要几秒钟。
巴特·雅各布斯
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.