Possible proxy configuration options are:

• Environment variables ( e.g. WINGET_PROXY_URL)
• Auto-detecting settings from inetcpl.cpl aka IE
• command line arguments
• config file
• registry config separate from IE. This would tie in nicely with ADMX (group policy) templates down the road

1080端口，老局域网用户了

please consider also proxy the download link inside the package , for example ,

winget install kodi --proxy http://xxx/

please also proxy the download link 'https://mirrors.kodi.tv/releases/windows/win64/kodi-18.7-Leia-x64.exe' which insided the installation package.

Possible proxy configuration options are:

• Environment variables ( e.g. WINGET_PROXY_URL)
• Auto-detecting settings from inetcpl.cpl aka IE
• command line arguments
• config file
• registry config separate from IE. This would tie in nicely with ADMX (group policy) templates down the road

I would recommend standard variables like HTTP_PROXY or HTTPS_PROXY

When adding proxy support, please do not forget supporting proxies that require NTLM-authentication!!!
In an enterprise environment where the workstations are joined to a domain, and the users use domain accounts, entering a password should not be necessary! (Windows Integrated Authentication)

Thank you!

Any plan regarding this feature?

Also need for winget upgrade

Why not try set http_proxy=http://localhost:7890 and set https_proxy=http://localhost:7890?

@d0zingcat because its not socks5.

@d0zingcat because its not socks5.

Maybe you could use Privoxy(windows)/polipo(macOS) to parse socks5 to http?

not that its an equivalent but even spotify can run over socks5. it would be nice to run winget through tor like all my other package managers to curb targeted injection attacks.

Need it

System-wide proxy actually works.
Windows version: Win 10 22H2 (19045.2251)
Powershell version: 7.3.1

The whole point of asking for a custom proxy support is to make sure one is not using systemwide proxy. The systemwide proxy opens connections to everything else o the system.

As a workaround i use: "bitsadmin /util /setieproxy localsystem MANUAL_PROXY "
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/bitsadmin-util-and-setieproxy

All,

Please be respectful of others who are watching this Issue. Every comment is sent out as an e-mail to every user watching this Issue. Adding comments like "Need it" or "+1" is just causing more noise. We track relative priority by the number of 👍 on the original post for the Issue. I've hid the majority of these comments, as they do not add to the scope of the issue or offer support for others who also want this feature and are essentially "subscribed" because they have added their 👍.

This issue is now high on the backlog. We have several security concerns we have to address in order to enable this feature. As soon as we have a design that is acceptable for our security requirements, we will look to sequence this work for engineering.

You can see how we prioritize work on the Roadmap.

Is there any plan that can be used ?

It's been more than three years since this issue was created, and we see that this issue has a linked PR #1776, which solves some problems. After that PR, this issue was added to the milestones: v1.3-Client, v1.4-Client, v1.5-Client and now v.Next-Client. As the differences between commits increase due to the development of master branches, merge PR has become a challenge by now. Moreover, according to RoadMap, this issue is already the issue with the largest number of 👍 among milestone: v.Next-Client. Can we first merge this PR as an experimental feature, and then gradually fix it according to the new problems we encounter?

We have to adhere to our internal security standards which is why that PR hasn't been merged. We're working on getting the documentation together for our security review, and then we'll be able to either start from that PR or create a new one with the approved method. It will initially start out as an experimental feature in a preview and then it can be made stable feature in the next stable release.

I've changed how we're tracking work across milestones to avoid the constant movement. We've had several other high-priority features and bug fixes in progress, but this has made it to the top of the list for asks from the community.

Hey everyone, I know it's been a long time coming, but we have had our initial security review. We will be submitting a specification document and will work on final review and then we can get into implementation.

• We will need GPO (Group Policy Objects) for enterprise control of WinGet with respect to proxy support.
• Specifying a default proxy for WinGet will require administrative permissions.
• The CLI will not require administrative permissions to pass "--proxy " (will not override GPO).

I want to thank @eternalphane for the draft PR:

• Add basic proxy support #1776

waiting for the good news

Hey everyone, I know it's been a long time coming, but we have had our initial security review. We will be submitting a specification document and will work on final review and then we can get into implementation.

• We will need GPO (Group Policy Objects) for enterprise control of WinGet with respect to proxy support.
• Specifying a default proxy for WinGet will require administrative permissions.
• The CLI will not require administrative permissions to pass "--proxy " (will not override GPO).

I want to thank @eternalphane for the draft PR:

• Add basic proxy support #1776

You mention a GPO. Is there a plan to also include Intune, using a configuration policy, as a means for enterprise control?

We have many workstations that are not domain joined, only Entra joined, that have no GPOs and no intention of introducing any.

the Intune situation should be considered too as a part of supporting proxies. this issue can be closed then.

Hey everybody, the "Proxy" experimental feature is available in the latest WinGet 1.8 preview release.

I'd like to see a few folks test the feature out, but I don't want to add more noise here on the issue that triggers e-mails to everyone subscribed.

Please test out the feature and provide your results over at:

• Testing "Proxy" experimental feature. #4428