解决了：
问题是与hamachi客户端，hamachi是高举所有的5.0.0.0/8地址块
在Mac上的修复
如果你只能通过IPv4连接到你的一些networking，这个“修复”将不适合你
—–
几个星期前我开始使用服务 – https://semaphoreapp.com我认为他们做了一个星期前的DNS更改，因为我无法从我的Mac OSX Lion（10.7.4）机器（我的主要开发机器）
但我可以从我的networking上的其他机器访问该网站
一些谷歌search后，我试了这两个
但没有去，我也联系了semaphoreapp，但目前为止还没有任何兴趣，我的同事之一有完全相同的问题，不能通过Mac OSX Lion访问，但可以通过Windows机器，我们远程工作，而不是同一个ISP
一些额外的信息
狮子（10.7.4）不能访问网站
host semaphoreapp.com semaphoreapp.com has address 5.9.53.16 ping semaphoreapp.com PING semaphoreapp.com (5.9.53.16): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 ping: sendto: No route to host Request timeout for icmp_seq 4 ping: sendto: Host is down Request timeout for icmp_seq 5 ping: sendto: Host is down Request timeout for icmp_seq 6 ping: sendto: Host is down Request timeout for icmp_seq 7 .... traceroute semaphoreapp.com traceroute to semaphoreapp.com (5.9.53.16), 64 hops max, 52 byte packets 1 * * * 2 * * * traceroute: sendto: No route to host 3 traceroute: wrote semaphoreapp.com 52 chars, ret=-1 *traceroute: sendto: Host is down traceroute: wrote semaphoreapp.com 52 chars, ret=-1 .... 和MacMini（10.6.8）可以访问它
host semaphoreapp.com semaphoreapp.com has address 5.9.53.16 ping semaphoreapp.com PING semaphoreapp.com (5.9.53.16): 56 data bytes 64 bytes from 5.9.53.16: icmp_seq=0 ttl=44 time=191.458 ms 64 bytes from 5.9.53.16: icmp_seq=1 ttl=44 time=202.923 ms 64 bytes from 5.9.53.16: icmp_seq=2 ttl=44 time=180.746 ms 64 bytes from 5.9.53.16: icmp_seq=3 ttl=44 time=200.616 ms 64 bytes from 5.9.53.16: icmp_seq=4 ttl=44 time=178.818 ms .... traceroute semaphoreapp.com traceroute to semaphoreapp.com (5.9.53.16), 64 hops max, 52 byte packets 1 192.168.0.1 (192.168.0.1) 1.677 ms 1.446 ms 1.445 ms 2 * LOCAL ISP 11.957 ms * 3 etc... 10.704 ms 14.183 ms 9.341 ms 4 etc... 32.641 ms 12.147 ms 10.850 ms 5 etc.... 44.205 ms 54.563 ms 36.243 ms 6 vlan139.car1.seattle1.level3.net (4.53.145.165) 50.136 ms 45.873 ms 30.396 ms 7 ae-32-52.ebr2.seattle1.level3.net (4.69.147.182) 31.926 ms 40.507 ms 49.993 ms 8 ae-2-2.ebr2.denver1.level3.net (4.69.132.54) 78.129 ms 59.674 ms 49.905 ms 9 ae-3-3.ebr1.chicago2.level3.net (4.69.132.62) 99.019 ms 82.008 ms 76.074 ms 10 ae-1-100.ebr2.chicago2.level3.net (4.69.132.114) 96.185 ms 75.658 ms 75.662 ms 11 ae-6-6.ebr2.washington12.level3.net (4.69.148.145) 104.322 ms 105.563 ms 118.480 ms 12 ae-5-5.ebr2.washington1.level3.net (4.69.143.221) 93.646 ms 99.423 ms 96.067 ms 13 ae-41-41.ebr2.paris1.level3.net (4.69.137.49) 177.744 ms ae-44-44.ebr2.paris1.level3.net (4.69.137.61) 199.363 ms 198.405 ms 14 ae-47-47.ebr1.frankfurt1.level3.net (4.69.143.141) 176.876 ms ae-45-45.ebr1.frankfurt1.level3.net (4.69.143.133) 170.994 ms ae-46-46.ebr1.frankfurt1.level3.net (4.69.143.137) 177.308 ms 15 ae-61-61.csw1.frankfurt1.level3.net (4.69.140.2) 176.769 ms ae-91-91.csw4.frankfurt1.level3.net (4.69.140.14) 178.676 ms 173.644 ms 16 ae-2-70.edge7.frankfurt1.level3.net (4.69.154.75) 180.407 ms ae-3-80.edge7.frankfurt1.level3.net (4.69.154.139) 174.861 ms 176.578 ms 17 as33891-net.edge7.frankfurt1.level3.net (195.16.162.94) 175.448 ms 185.658 ms 177.081 ms 18 hos-bb1.juniper4.rz16.hetzner.de (213.239.240.202) 188.700 ms 190.332 ms 188.196 ms 19 hos-tr4.ex3k14.rz16.hetzner.de (213.239.233.98) 199.632 ms hos-tr3.ex3k14.rz16.hetzner.de (213.239.233.66) 185.938 ms hos-tr2.ex3k14.rz16.hetzner.de (213.239.230.34) 182.378 ms 20 * * * 21 * * * 22 * * *
有任何想法吗？
编辑：添加tcpdump
MacMini（可以连接）运行时 – ping semaphoreapp.com
sudo tcpdump -v -i en0 dst semaphoreapp.com Password: tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:33:03.337165 IP (tos 0x0, ttl 64, id 20153, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->3129)!) 192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 0, length 64 17:33:04.337279 IP (tos 0x0, ttl 64, id 26049, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->1a21)!) 192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 1, length 64 17:33:05.337425 IP (tos 0x0, ttl 64, id 47854, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->c4f3)!) 192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 2, length 64 17:33:06.337548 IP (tos 0x0, ttl 64, id 24772, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->1f1e)!) 192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 3, length 64 17:33:07.337670 IP (tos 0x0, ttl 64, id 8171, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->5ff7)!) 192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 4, length 64 17:33:08.337816 IP (tos 0x0, ttl 64, id 35810, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->f3ff)!) 192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 5, length 64 17:33:09.337948 IP (tos 0x0, ttl 64, id 31120, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->652)!) 192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 6, length 64 ^C 7 packets captured 1047 packets received by filter 0 packets dropped by kernel
OSX Lion（无法连接）运行时 – ping semaphoreapp.com
# wireless ~ $ sudo tcpdump -v -i en1 dst semaphoreapp.com Password: tcpdump: listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes ^C 0 packets captured 262 packets received by filter 0 packets dropped by kernel
和
# wired ~ $ sudo tcpdump -v -i en0 dst semaphoreapp.com tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes ^C 0 packets captured 219 packets received by filter 0 packets dropped by kernel
在Request timeout for icmp_seq之后输出25或30以上的输出。 我不太了解tcpdump，但对我来说，似乎并没有ping请求离开我的机器？
你在无法连接到semaphoreapp.com的机器上运行Hamachi吗？
如果你是，我可以build议你禁用Hamachi并重试连接; 你可以在以下地址find更多关于Hamachi街区的信息：
DNSparsing看起来很好，因为您可以将名称parsing为正确的IP地址。 我能够访问狮子和山狮的网站。
您可以尝试重新启动您的networking接口。
sudo ifconfig en0 down sudo ifconfig en0 up
用正在使用的networking接口replaceen0。 使用不带参数的ifconfig来找出正确的接口。
如果您使用两个networking接口（例如无线和有线networking），则可能会导致问题。
如果您使用可能导致问题的VPN。 基本上寻找任何方式在你的狮子框networking可能configuration不同于其他主机上。
而且，跛脚，因为它可能是，如果你还没有尝试过，重新启动可能是为了:)
在Lion上， dscacheutil -flushcache是刷新caching所需要的。 如果这不起作用，那么path中可能还有其他内容，例如具有自己的DNScaching的代理或系统，这是问题所在。 除了给它一点时间之外，你可以对他们做些什么。
如果一切都失败了，从可以连接的机器上获取该站点的IP地址，并尝试使用它。 在共享主机上，您可能无法访问您之后的网站，但至less您可以确认连接。 如果这也无济于事，那么您的系统上可能会阻塞它，所以请检查您正在运行的任何防火墙应用程序或系统。
是的，我见过这个问题。 有时候这是一个MTU问题。 特别是PMTU检测…
你可以到其他https站点没有事件？ 你可以尝试降低你的MTU在系统预置 – >networking – >接口 – >高级 – >硬件 – >configuration手动。 也许设置为1460或更低，而不是默认的1500。
另请参阅：
https://apple.stackexchange.com/questions/39226/https-not-working-on-macbook-pro
我很高兴你解决了你的问题，但是我发现在Mac OSXnetworking中遇到的一个问题是，在/ etc / hosts文件中将多个域放在一行上会导致随机的事情发生在你的networking堆栈上。 我希望这可以帮助别人，谷歌方式来解决这个问题。
所以不要这样做：
127.0.0.1 mylocalsite myotherlocalsite localhost eviladnetworksite.com
你必须把它们分别放在一行上
127.0.0.1 mylocalsite 127.0.0.1 myotherlocalsite 127.0.0.1 localhost 127.0.0.1 eviladnetworksite.com
进行此更改后，必须重新启动以获得未损坏的networking堆栈。
Ref： http : //stevegrunwell.com/blog/quick-tip-troubleshooting-etchosts-issues/