Os scripts de início de sessão do proxy do Windows não acompanham alterações posteriores de rede
Trate a seleção de proxy no início de sessão do Windows e as transições de rede posteriores como eventos separados, com uma atualização deliberada do cliente e uma política de ligações.
Um portátil pode receber corretamente o proxy do escritório no início de sessão e mantê-lo depois de voltar a casa. O script de início de sessão foi executado uma vez; não subscreveu cada alteração posterior de Wi-Fi. O processamento em segundo plano de políticas de grupo não é uma promessa de voltar a executar um script de início de sessão arbitrário numa transição.
Defina explicitamente o comportamento posterior:
- Gatilho: uma aplicação gerida pode usar as notificações de alteração de conectividade do Network List Manager para reconsiderar o estado. A notificação em si não escolhe nem escreve um proxy.
- Decisão: inspecione suficiente estado atual da rede. Um único endereço privado ou a primeira interface enumerada é evidência fraca quando Ethernet, Wi-Fi e VPN coexistem.
- Atualização do cliente: aplique a definição através da interface utilizada pelos clientes. A gravação WinINet e as notificações documentadas de alteração de definições e atualização são ações separadas; WinHTTP ou a configuração privada da aplicação podem exigir outro caminho.
- Trabalho existente: decida se as ligações abertas podem terminar, devem restabelecer-se ou devem parar. Uma nova seleção de proxy não pode mover um socket estabelecido para outra saída.
Para os clientes participantes cientes do proxy, o PAC é outro desenho: mantenha a seleção por destino no cliente em vez de substituir repetidamente um ponto final estático. A sua entrega e política de reserva continuam a ter de funcionar nas redes itinerantes.