TL; DR …我们的域策略默默地强制将LAN设置（包括代理引用）按预定义的时间间隔推到我的机器上，这正好是我正在开发的时候，但手动禁用代理之后。 因为我知道我已经禁用了本地地址，所以我不会想到这是我的问题的根源。
在运行Windows Server 2012 R2的其中一台开发机器上，我遇到了通过hosts文件本地parsing主机的好奇行为。
[描述重现]
C:\Windows\system32>ping baz.inga Ping request could not find host baz.inga. Please check the name and try again. C:\Windows\system32>_ 127.0.0.1 baz.inga ::1 baz.inga
C:\Windows\system32>ping baz.inga Pinging baz.inga [127.0.0.1] with 32 bytes of data: Reply from 127.0.0.1: bytes=32 time<1ms TTL=128 Reply from 127.0.0.1: bytes=32 time<1ms TTL=128 Reply from 127.0.0.1: bytes=32 time<1ms TTL=128 Reply from 127.0.0.1: bytes=32 time<1ms TTL=128 Ping statistics for 127.0.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms C:\Windows\system32>_
然后，我在localhost：7890上托pipe一个应用程序
/ GET http：//baz.inga：7890
有没有合理的解释，为什么这不是在当地解决？ 我在运行Windows 7的机器上testing了完全相同的过程，对HTTP代理的响应是本地parsing的资源。
WTH？！？！
HTTP 503是来自应用程序的错误响应，而不是DNS查找失败; 如果由于未parsing其主机名而导致请求实际上无法到达您的应用程序，则不会收到503响应。
看起来像你的名字parsing是可以的（如预期，并确认ping工作）; 您的应用程序，而不是。
我们的组策略规定，域的LAN设置会自动推送到所有连接的计算机上。
尽pipe我在configuration本地主机parsing时禁用了代理脚本，但是当定时器启动时，代理脚本引用被静默地强制推送到整个局域网，并引入了我的错误。 由于我已经手动禁用了http代理，因此我不会想到这将是我的问题的根源，而且它“必须”是更精细的东西。
代替创build没有自动推送这些严格设置的新的“特权”域策略，我们的解决scheme是定义一个约定，在这个约定中，要在本地机器上parsing的主机将被给予基于约定的“保留”结束权限段，然后通过修改从DC推送的proxy.pac文件，通过代理作为DIRECT引用自动parsing
if(dnsDomainIs(host, ".reserved")) { return "DIRECT"; }