TL; DR ... nossa política de domínio forçou silenciosamente as configurações da LAN (incluindo a referência de proxy) para a minha máquina em um intervalo predefinido, que aconteceu enquanto eu estava desenvolvendo, mas depois que eu tinha desativado manualmente o proxy. Desde que eu sabia que eu tinha desativado para endereços locais, não me ocorreu que seria a raiz do meu problema.
Em uma das minhas máquinas de desenvolvimento que está executando o Windows Server 2012 R2, estou tendo um comportamento curioso com a resolução local de um host por meio do arquivo de hosts.
[ Descrição para reproduzir ]
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>_
... Então, eu hospedo um aplicativo no localhost: 7890
/ GET link
Existe alguma explicação razoável sobre por que isso não está resolvendo localmente? Testei exatamente o mesmo procedimento em uma máquina que executa o Windows 7 e a resposta ao proxy HTTP é um recurso resolvido localmente.
WTH?!?!
O HTTP 503 é uma resposta de erro do seu aplicativo, não uma falha de pesquisa de DNS; se a solicitação não fosse realmente capaz de acessar seu aplicativo devido a não resolver seu nome de host, ele não teria recebido uma resposta 503.
Parece que a resolução do seu nome está correta (conforme esperado e confirmada por ping working); seu aplicativo, em vez disso, não é.
Nossa política de grupo determina que as configurações de LAN para o domínio sejam automaticamente enviadas para todas as nossas máquinas conectadas em um timer.
Embora eu tenha desabilitado o script de proxy durante a configuração da resolução do meu host local, quando o timer estava ativo, a referência do script de proxy foi forçada silenciosamente pela LAN e apresentou meu erro. Como eu já havia desativado o proxy HTTP manualmente, não me ocorreu que seria a raiz do meu problema e que "deve" ser algo mais elaborado.
Em vez de criar uma nova política de domínio "privilegiada" que não tenha essas configurações estritas automaticamente enviadas, nossa solução é definir uma convenção em que os hosts destinados à resolução na máquina local receberão um "reservado" baseado em convenção terminando o segmento de autoridade, que então resolverá automaticamente através do proxy como uma referência DIRECT modificando o arquivo proxy.pac enviado do DC com
if(dnsDomainIs(host, ".reserved")) { return "DIRECT"; }