Обнаружение прокси .NET - PullRequest
       8

Обнаружение прокси .NET

13 голосов
/ 14 декабря 2010

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

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

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

WebRequest.GetSystemWebProxy().GetProxy(destination);

GlobalProxySelection.Select.GetProxy(destination);

WebRequest.DefaultWebProxy

Вот следующие советы:

  • Мой сценарий устанавливает 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.
  • Жесткое кодирование прокси-серверов в IE ВСЕГДА работает
  • Время всегда решает проблему - если я оставлю компьютер на 20 или 30 минут и вернусь, .NET подберет правильные настройки прокси-сервера, как если бы срок действия кэшированного сценария PAC истек.

Ответы [ 2 ]

4 голосов
/ 22 декабря 2010

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

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

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. 
0 голосов
/ 14 декабря 2010

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

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]   
"ProxyServer"="<your proxy IP address>:8080"
"ProxyEnable"=dword:00000001
"ProxyOverride"="<local>"
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...