当我尝试访问http://mysubdomain.localhost时，chrome解析为[::1]80，即使hosts文件中有此域的显式条目。没有其他浏览器以这种方式工作。Firefox，safari和curl都解析了我的hosts文件中给出的IP地址。这是我的hosts文件的全部内容：
##
# 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
192.168.88.88 mysubdomain.localhost然而，当我试图在chrome中访问http://mysubdomain.localhost时，它并没有解析为192.168.88.88。这对我来说是个问题，因为192.168.88.88是在我的计算机上运行的虚拟机。我可以将域更改为http://mysubdomain.local或http://mysubdomain.dev，但这需要我更新项目中许多人使用的配置文件，我宁愿避免这样做。因为我可能会破坏他们工作流程的某些方面
Firefox（正常运行）
curl（按需工作）
Chrome（无法正常工作）
有些事情我已经尝试过了：
- 我没有使用代理
- 我已经多次清除浏览器缓存
- 我已经清除了
chrome://net-internals/#dns的dns缓存 - 我已经重新启动机器好几次了
- 我已使用终端命令
sudo dscacheutil -flushcache;sudo killall -HUP mDNSResponder清除了系统DNS缓存 - 我试过几次隐姓埋名模式
- 我尝试创建一个新的chrome用户帐户
系统信息：
Chrome版本：53.0.2785.116
操作系统版本：Mac OS 10.11.6（El Capitan）
2条答案
按热度按时间mec1mxoz1#
经过进一步审查，我认为这是unfortunately working as designed。从 chrome 问题队列：
这是作为一种安全缓解措施，因为OS X的解析器无法正确确保.localhost域不会在网络上被查询，这是确保.localhost真正本地的关键安全属性。因为我们不能信任解析器来做安全的事情，不幸的是我们不能信任解析器（即使它可能是安全的）...
安全风险不是关于正确配置的服务器与不正确配置的服务器。它是DNS解析器不应该向网络发送foo.localhost请求。如果这样做，网络攻击者可以使“foo.localhost”指向他们选择的任何IP。这是不好的，因为“localhost”（和“*.localhost”）具有特殊权限（参见http://www.w3.org/TR/powerful-features/#is-origin-trustworthy），因为他们有这些特权，他们需要安全。
事实上，Chrome似乎是唯一一个正确实现RFC-6761的工具，其中部分规定：
名称解析API和库应该识别localhost名称为特殊的，并且应该总是返回IP环回地址，以用于地址查询和所有其他查询类型的否定响应。名称解析API不应该将对localhost名称的查询发送到它们配置的缓存DNS服务器。
所以似乎没有办法解决这个问题。我将更改我的虚拟机的域为
http://mysubdomain.localfhg3lkii2#
在使用了一段时间的firefox之后，我偶然发现了一个解决方案，你可以简单地安装https://www.telerik.com/download/fiddler，而不是改变你的开发环境。
Fiddler绕过了Chrome的DNS，我相信，所以你只剩下一个完美的工作系统，而不必改变你所有的环境。
我已经在Windows 10上使用Hyper-v over vagrant测试了这个功能。