移动客户端中有一些API调用失败。 为了进行调查，我遵循了Joseph Scott的build议 ，用几个debugging参数来执行curl：
Amazon EC2服务器的结果：
time_namelookup: 0.011 time_connect: 0.011 time_appconnect: 0.016 time_pretransfer: 0.027 time_redirect: 0.000 time_starttransfer: 0.049 ---------- time_total: 0.049 一台笔记本电脑的结果（在以色列）：
time_namelookup: 5.004 time_connect: 5.264 time_appconnect: 5.851 time_pretransfer: 5.851 time_redirect: 0.000 time_starttransfer: 6.188 ---------- time_total: 6.188
我的resolv.conf ：
# # Mac OS X Notice # # This file is not used by the host name and address resolution # or the DNS query routing mechanisms used by most processes on # this Mac OS X system. # # This file is automatically generated. # nameserver 192.168.0.1
其他详情：
dig即刻返回。 任何想法为什么time_namelookup需要这么长时间？
更新
当我在不同的无线networking中执行相同的命令时，我得到以下结果：
time_namelookup: 0.003 time_connect: 0.273 time_appconnect: 2.189 time_pretransfer: 2.189 time_redirect: 0.000 time_starttransfer: 3.200 ---------- time_total: 3.201
这可能意味着很长的time_namelookup确实是一个防火墙问题。 感谢所有帮助过的人！
超时时间为5秒的事实可能是重要的。 一些应用程序（但不是dig ）使用getaddrinfo()而不是gethostbyname() ; 前者如果被某些参数调用，将等待IPv4和IPv6响应，而后者将立即返回一个IPv4响应。 在这种情况下， getaddrinfo()的默认超时值是5秒。
我们确实需要从错误客户端的angular度来看端口53stream量的tcpdump跟踪，以了解发生了什么事情。 我最近解决了这样的问题，事实certificate， 防火墙阻止了其中一个回复数据包 。
这是macosx，我看到你的resolv.conf转储。 此文件用于兼容性。 名称服务器192.168.0.1是否正常工作？ 行为指向我，它不工作，并与DNS联系超时。 另外，192.168.0.1是不可路由的ip class中的本地ip（不通过Internet路由）。 这应该是任何本地cachingDNS服务器。 这工作？ 你用nslookuptesting过吗？
另一点，在macosx你有/ etc / resolver / *文件。 也许有一个工具从resolv.conf获取configuration并等待超时，另一个工具从/ etc / resolver / *文件获取。 看看在那个文件中configuration了什么。 也许你应该更新configuration，特别是在resolv.conf中。 不要手动编辑（如注释中所述），请使用任何macosx工具。
我发现一些解决DNS的食谱，但我不知道它适合你： http : //www.justincarmony.com/blog/2011/07/27/mac-os-x-lion-etc-hosts-bugs – 和 – DNS解决scheme/但也许这可以帮助你。