Automatic proxy settings not seen by PowerShell 6.2.0 on Windows 10

Steps to reproduce

PowerShell 6.2.0 does not appear to see or recognize any system proxy settings on Windows 10 that are not hard coded. My employer uses a non-authenticated proxy server and delivers the configuration to client machines via DHCP (in Internet Options, this is the "Automatically Detect Settings" check box). When using this Proxy Option, the proxy is not recognized and no http-based request will go through, such as install-module, update-help, etc. The same experience occurs when choosing the "Use Automatic configuration script" option and properly configuring the endpoint.

Proxied connections only appear to work when hard-coding the proxy via the "Use a proxy server for your LAN" option.

Expected behavior

PowerShell 6.x should recognize automatic proxy settings in the same manner that Windows PowerShell 5.1 does.

Actual behavior

Proxied connections in PowerShell 6.2.0 only work when the proxy is hard coded. Also, PowerShell 6.2.0 does not appear to recognize proxy settings made via netsh winhttp settings either. Only way to get proxy to work is to hard code it via Internet Options.

Environment data

Name Value

PSVersion 6.2.0
PSEdition Core
GitCommitId 6.2.0
OS Microsoft Windows 10.0.17763
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

Please add repo steps.

Steps to reproduce:
Windows 10 client
Have a network that uses a non-authenticated proxy.
Have a network that provides Proxy settings either via DHCP or a configuration script.
Configure "Internet Options" to use either the "Automatically detect settings" or "Use automatic configuration script".
Open a PowerShell Prompt.
Run any cmdlet that should pick up the proxy this way and watch it fail (example: update-help, Install-Module, find-module, etc.)

Mark Kraus (@markekraus)

I can confirm for Invoke-WebRequest that it works only with explicit proxy settings in command line.

Mark Kraus (@markekraus) Could you please look the issue?

Ilya (@iSazonov)

Thank you Ilya (@iSazonov). FYI, this is a change in behavior from Windows PowerShell.

Ilya (@iSazonov)

Ilya (@iSazonov) this issue appears to not be about the webcmdlets which uses a proxy by default unless -NoProxy is specified. PowerShellGet not respecting a proxy should be opened in that repo, found a similar issue there: https://github.com/PowerShell/PowerShellGet/issues/336

For Update-Help, it seems it needs to be extended to support proxies

this issue appears to not be about the webcmdlets which uses a proxy by default unless -NoProxy is specified.

It seems webcmdlets do not use a proxy by default as expected :-( Should we create new tracking issue?

Ilya (@iSazonov)

Ilya (@iSazonov) yes, we should have a separate issue for that, however, it might just be an issue with HttpClient

Steve Lee (@SteveL-MSFT)

Steve Lee (@SteveL-MSFT) The technology behind is WPAD.

I found the same issue on Asp.Net Core #32135
On coreFx, i found this one relative : #26494

Any updates on the fix for this issue or an ETA?

Andrew (@anmenaga)

Andrew (@anmenaga) can you take a look at this?

Steve Lee (@SteveL-MSFT)

Steve Lee (@SteveL-MSFT) Do you plan to provide support back for proxy.pac ?
.
I have a lot of customers with cloud proxy.

Brian E. Tower (@towerbe)

Brian E. Tower (@towerbe)

I'm from the CoreFx team. We're investigating this proxy issue with .NET Core 2.x regarding WPAD and/or PAC file processing.

Can you clarify something about the PAC files being used in your company? Do they return multiple proxies in the FindProxyForUrl() function in the PAC file?

For example, this snippet from a PAC script returns a single proxy:

// Proxy
return "PROXY proxy.domain.local:8080";

But this one returns multiple proxies separated by semicolons:

// Failover
return "PROXY proxy1.domain.local:8080; PROXY proxy2.domain.local:8080";

We had a bug in .NET Core 2.x where we could not handle getting multiple proxies returned from a PAC file. The end result was we ignored all of them. We fixed that bug in .NET Core 3.0 so that we would at least use the first one returned. See: https://github.com/dotnet/corefx/issues/39104

Given that Andrew (@anmenaga) reported in #9495 (comment) that "Automatically detect settings" was working fine in his tests, perhaps your problem is that the PAC file is returning multiple proxies and hitting bug https://github.com/dotnet/corefx/issues/39104.

Yes, our PAC returns multiple proxies.

Yes, our PAC returns multiple proxies.

Thanks for confirming that.

Can you clarify something about the PAC files being used in your company? Do they return multiple proxies in the FindProxyForUrl() function in the PAC file?

We use MS TMG two servers in "cluster" - wpad returns both.

This has been verified to be working in PS7 Preview.3 where the issue appears to have been fixed by .NET Core 3.0 Preview.8. Closing this issue. Continue to reply if you still have an issue with PS7 Preview.3 or newer.

Steve Lee (@SteveL-MSFT)

I write a comment after the case has been closed as I still experience this issue. And as Steve Lee (@SteveL-MSFT) writes. We can continue to reply if the issue is experienced.

SYS INFO

Windows 10 v1809 (x64)
PowerShell v7.1.0 preview2
Proxy is configured via PAC script (WPAD). Company enforced. No direct access to the Internet.

The part of the pac script that derives a proxy address to use, looks like this:

....
var clientIP = myIpAddress();
// #NSCLIENTIP#
host = host.toLowerCase();    // Make our shExpMatch checks case insensitive.
// Redundant proxy combinations are defined here.
var _proxyList = [
  "PROXY 10.90.100.23:8080;PROXY 10.90.100.24:8080;DIRECT",
  "PROXY 10.90.100.24:8080;PROXY 10.90.100.23:8080;DIRECT"
];
var noProxy = "DIRECT";
// Select a primary candidate proxy, based on the clients IP address.
var _octets = clientIP.split(".");
var _lastOctet = parseInt(_octets[3]);    // Get the last octet og the clients IP address.
var _proxyIndex = _lastOctet % _proxyList.length;  // Determine the proxy sequence.
var proxyString = _proxyList[_proxyIndex];      // Assign the return value.
....

Internet Explorer 11 has been removed (maybe it is relevant, not sure). Edge is installed

Resolution steps tried

To get Install-Module -name invokebuild -Verbose -Scope CurrentUser -Repository PSGallery -Force to work, I've tried the following.

Exexcuted [System.AppContext]::SetSwitch("System.Net.Http.UseSocketsHttpHandler", $false)
- Did not work
Same PS session. Executed: [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
- Did not work

Same PS session. Executed:

[system.net.webrequest]::defaultwebproxy = new-object   system.net.webproxy('http://10.90.100.24:8080')
[system.net.webrequest]::defaultwebproxy.credentials =                                                                              [System.Net.CredentialCache]::DefaultNetworkCredentials
[system.net.webrequest]::defaultwebproxy.BypassProxyOnLocal = $true

Did not work

Tried using the -Proxy & -ProxyCredential parameters to the Install-Module cmdlet.
- No change

I can get the Invoke-WebRequest cmdlet to work with the -Proxy and -UseDefaultCredentials parameters.

Reproduction steps

Run Win10 1809 or higher
Run PS7.1 preview 2 or higher
- thereby I should have the .NET core that should work
Execute: Install-Module -name invokebuild -Verbose -Scope CurrentUser -Repository PSGallery -Force
Run through a proxy, configured via a PAC script

Acceptance criteria

When I can execute Install-Module -name invokebuild -Verbose -Scope CurrentUser -Repository PSGallery -Force in a PS7.1 preview 2 or higher session and the module installs.

Thank you.

Lars Bing Bong. (@larssb)

Lars Bing Bong. (@larssb) If you could create a simple C# app you could open issue in .Net Runtime.
The app could be as simple as:

var a = system.net.webrequest.Create("https://ya.ru");
var b = a.GetResponse();

Ilya (@iSazonov)

Created the app and now the issue. As the .NET throws an error.

Thank you Ilya (@iSazonov) ... I hope they will be able to find something. Really a bummer that Install-Module does not work for me on Win10 PS 7.1

The following:

# For PowerShell to use the Proxy system settings. The bewlow is PS 6 core + compatible
# $true to the System.Net.WebProxy constructor is to indicate that the proxy should be bypassed for local addresses
[System.Net.Http.HttpClient]::DefaultProxy = New-Object System.Net.WebProxy('http://PROXY_IP:PROXY_PORT', $true)
[System.Net.Http.HttpClient]::DefaultProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials

is the solution for the HTTP407 status code thrown, which in a PowerShell session where Install-Module .... -Verbose is executed could show itself as: WARNING: Unable to resolve package source 'https://www.powershellgallery.com/api/v2'.

If proxy detection works follow works too:

[System.Net.Http.HttpClient]::DefaultProxy.Credentials = System.Net.CredentialCache]::DefaultCredentials

Lars Bing Bong. (@larssb)

[System.Net.Http.HttpClient]::DefaultProxy = New-Object System.Net.WebProxy('http://PROXY_IP:PROXY_PORT', $true)
[System.Net.Http.HttpClient]::DefaultProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials

I have been trying to set the default web proxy for Powershell Core (7.1) for several hours without success. I usually found suggestions to set [System.Net.WebRequest]::DefaultWebProxy which didn't have any effect.

Then I finally came to @larssb's comment and it has fixed everything – Invoke-WebRequest, PowerShellGet's Find-Module, Install-Module, etc.

I would just add that to bypass the proxy (use the direct connection), you can set the proxy to null:

[System.Net.Http.HttpClient]::DefaultProxy = New-Object System.Net.WebProxy($null)

Thanks a lot, Lars Bing Bong. (@larssb)!

Navigation Menu

Repository navigation

Automatic proxy settings not seen by PowerShell 6.2.0 on Windows 10 #9495

Steps to reproduce

Expected behavior

Actual behavior

Environment data

14 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Automatic proxy settings not seen by PowerShell 6.2.0 on Windows 10 #9495

Description

Steps to reproduce

Expected behavior

Actual behavior

Environment data

Activity

iSazonov commented on Apr 30, 2019

towerbe commented on Apr 30, 2019

iSazonov commented on Apr 30, 2019

towerbe commented on Apr 30, 2019

SteveL-MSFT commented on May 4, 2019

iSazonov commented on May 4, 2019

SteveL-MSFT commented on May 4, 2019

fMichaleczek commented on May 4, 2019

towerbe commented on Jun 21, 2019

SteveL-MSFT commented on Jun 22, 2019

fMichaleczek commented on Jun 22, 2019

14 remaining items

davidsh commented on Aug 2, 2019

towerbe commented on Aug 2, 2019

davidsh commented on Aug 2, 2019

iSazonov commented on Aug 2, 2019

SteveL-MSFT commented on Aug 26, 2019

larssb commented on May 12, 2020

iSazonov commented on May 12, 2020

larssb commented on May 12, 2020

larssb commented on May 13, 2020

iSazonov commented on May 13, 2020

ferenczy commented on May 18, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions