当我尝试访问http://mysubdomain.localhost chrome解析为[::1]80时，即使主机文件中存在该域的明确条目。其他浏览器没有这种行为。 Firefox，safari和curl都可以解析我的主机文件中给出的IP地址。这是我的主机的全部文件的那一刻：Chrome忽略localhost子域名的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

然而，当我试图访问镀铬http://mysubdomain.localhost，它不能解决以192.168.88.88。这对我来说是个问题，因为192.168.88.88是在我的电脑上运行的虚拟机。我可以将域名更改为http://mysubdomain.local或http://mysubdomain.dev，但这需要我更新项目中许多人使用的配置文件，我宁愿避免这样做，因为我可能会破坏他们工作流程的某些方面。

火狐

卷曲（如所期望的工作）（工作根据需要）

浏览器（如所期望不工作）

我已经尝试了一些事情：从chrome://net-internals/#dns

我不使用代理
我已清除浏览器缓存多次
我已经清除DNS缓存我已经重新启动机器数次
我已经清除与终端命令系统DNS缓存sudo dscacheutil -flushcache;sudo killall -HUP mDNSResponder
我试图隐身模式几次
我试图创建一个新的Chrome用户帐户

系统信息：
Chrome版本：53.0.2785.116
OS版本：MAC OS 10.11.6（酋长）

来源

2016-09-23 Matt Korostoff

经进一步审查，我认为这是unfortunately working as designed。从铬问题队列：

这样做是为安全缓解，如OS X的解析器不能正常保证.localhost域不查询的网络，这是确保.localhost是一个关键的安全特性上真正地方。因为我们不能相信解析器来做安全的事情，所以我们不能相信解析器（即使它可能是安全的）... ...

安全风险不是关于正确配置的服务器vs不正确配置的服务器。这是一个DNS解析器不应该将foo.localhost请求发送到网络。如果是这样，网络攻击者可以将“foo.localhost”指向他们选择的任何IP。这很糟糕，因为“localhost”（和“* .localhost”）具有特殊权限（c.f. http://www.w3.org/TR/powerful-features/#is-origin-trustworthy），并且因为它们具有这些特殊权限，所以它们需要安全。

事实上，似乎铬可能在部分其中规定正确实施RFC-6761了一堆的唯一工具：

名称解析API和库要始终认识到本地主机名称特殊，应该返回IP回送地址用于地址查询和对所有其他查询类型的否定回应。名称解析API不应将 localhost名称的查询发送到其配置的缓存DNS服务器。

因此，似乎没有办法解决这个问题。我会将我的虚拟机的域名更改为http://mysubdomain.local

来源

2016-09-23 18:12:11

不要忘记，Mac OS X上的Bonjour使用.local TLD。我建议不要使用该顶级域名。 Google显然已经向Google申请了.dev。我一直在说YEARS现在我们需要为本地开发提供一个专门的TLD。这真是可悲。 –

Chrome忽略localhost子域名的hosts文件

火狐

卷曲（如所期望的工作）（工作根据需要）

浏览器（如所期望不工作）

回答

相关问题