Определение прокси-сервера .NET

У меня возникла проблема с .NET, определяющим настройки прокси-сервера, настроенные через Internet Explorer.

Я пишу клиентское приложение, которое поддерживает прокси, и для тестирования я настроил массив из 9 серверов squid для поддержки различных методов проверки подлинности для HTTP и HTTP. У меня есть script, который обновляет IE до любой конфигурации, которую я выбираю (какой прокси, обнаружение через "Авто", PAC или жесткий код).

Я попытался использовать 3 метода ниже, чтобы определить конфигурацию IE через .NET. В частности, я заметил, что .NET собирает неправильный набор прокси-серверов. IE имеет правильные настройки, и если я просматриваю веб-страницы с помощью IE, я вижу, что я нахожусь на правильных серверах через wirehark.

WebRequest.GetSystemWebProxy().GetProxy(destination);

GlobalProxySelection.Select.GetProxy(destination);

WebRequest.DefaultWebProxy

Ниже приведены следующие советы:

  • My script устанавливает файл PAC на веб-сервере и обновляет конфигурацию в IE, затем очищает кеш IE
  • .NET, похоже, "застрял" в определенной конфигурации прокси, и мне нужно установить еще одну конфигурацию для .NET, чтобы понять, что произошли изменения. Иногда кажется, что выбирается какой-то случайный набор серверов (я уверен, что они не случайные, просто набор серверов, которые я использовал один раз, и находятся в каком-то кэшированном файле PAC или что-то в этом роде). Как и в, я проверю прокси для адресата "https://www.secure.com", и у меня может быть настроен IE и, следовательно, вы получите "http://squidserver: 18", и вместо этого он вернет "http://squidserver: 28" (порт 18 запускает NTLM, 28 работает без аутентификации). Все серверы squid работают.
  • Это не проблема для XP, только Vista, 2003 и Windows 7.
  • Hardcoding прокси-серверов в IE ALWAYS работает
  • Время всегда решает проблему - если я покину компьютер около 20 или 30 минут и вернусь,.NET подберет правильные настройки прокси-сервера, как если бы кешированный PAC script истек.

Ответы

Ответ 1

Я нашел решение.

.NET использует "службу автоматического обнаружения веб-прокси-сервера WinHttp" для выполнения PAC script и, вероятно, кэширует результаты. Просто останавливать и перезапускать эту службу делает трюк. Следующая команда делает это для меня.

NET STOP WinHttpAutoProxySvc
NET START WinHttpAutoProxySvc

http://wiki.blackviper.com/wiki/WinHTTP_Web_Proxy_Auto-Discovery_Service

Я нашел это, следуя предложению Джеймса Ковача о прикреплении отладчика. Я уже просмотрел код и сделал неудачную попытку подключить отладчик, прежде чем я когда-нибудь разместил этот вопрос, но не смог точно определить, что происходит. Завершив опции, я снова попробовал отладку и через несколько часов нашел следующий комментарий в _AutoPWebProxyScriptEngine.cs в строке 76, который привел меня к этому открытию

        // In Win2003 winhttp added a Windows Service handling the auto-proxy discovery. In XP using winhttp
        // APIs will load, compile and execute the wpad file in-process. This will also load COM, since 
        // WinHttp requires COM to compile the file. For these reasons, we don't use WinHttp on XP, but
        // only on newer OS versions where the "WinHTTP Web Proxy Auto-Discovery Service" exists.

Ответ 2

У меня была такая же проблема, и мне удалось получить/установить настройку прокси-сервера в реестре:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]   
"ProxyServer"="<your proxy IP address>:8080"
"ProxyEnable"=dword:00000001
"ProxyOverride"="<local>"