Comportamento estranho no navegador ao acessar sites do IIS na intranet

1

Desenvolvedor confuso por intranets = P

Portanto, tenho um servidor IIS server em execução na rede local com um IP fixo. Eu tenho algumas configurações de aplicativos no IIS vinculado a diferentes portas.

Eu tenho o comportamento mais estranho: se eu carregar uma página por meio do endereço IP & porta, ele escreve a resposta correta (como visto no meu proxy de depuração), mas trava com uma página em branco por um longo tempo enquanto o Chrome diz "esperando por" e é um endereço IP incorreto não relacionado ao servidor ou aplicativo.

Na verdade, o navegador tenta fazer uma segunda solicitação para um IP incorreto e, de alguma forma, consegue segurar a exibição da página. Acontece no FF e no Chrome, conforme indicado pelo Fiddler.

Ele faz isso para vários aplicativos diferentes em portas diferentes, e cada um faz a mesma coisa, mas com um IP incorreto diferente para cada um. Ele espera se conectar ao IP da intranet local incorreto. Fiz um ping e não é nem um IP atribuído na rede.

Posso repetir isso em uma máquina sem um proxy de depuração, e nenhum dos IPs incorretos aparece em nenhum lugar dos projetos.

Não tenho certeza se temos um servidor DNS configurado. Somos uma pequena empresa sem serviços de TI. O que fiz foi corrigir o endereço IP no adaptador do servidor.

Se eu implantar os mesmos aplicativos em um servidor externo com os domínios / DNS adequados, eles funcionarão bem.

    
por FlavorScape 02.05.2012 / 02:15

1 resposta

1

Se você não tem redirecionamentos malucos acontecendo no site, parece que o navegador do cliente pode estar tentando usar um proxy para chegar em outro lugar.

Isso sugere que você está usando um arquivo PAC (/ WPAD) mal construído ou as configurações de proxy não são apropriadas para a tarefa.

Desative todas as configurações de proxy no navegador, reabra o navegador e veja se o sintoma é o mesmo.

Se o seu navegador oferecer suporte à captura de rede (IE9 com ferramentas de desenvolvimento F12, Fiddler, etc), você poderá ver a origem do problema dessa maneira.

(assumindo que o Wireshark + lendo essa captura não é imediatamente intuitivo para você).

    
por 02.05.2012 / 02:24