How to Set Per-Machine Proxy Settings on Windows (For All Users)

You've carefully configured the proxy settings on a shared Windows machine, only to find they don't apply to the next user who logs in. Or perhaps a critical system service, like Windows Update, fails to connect to the internet, even though your browser works perfectly. These common frustrations stem from a fundamental aspect of Windows networking: the difference between per-user and per-machine proxy settings. Relying on default, per-user configurations creates security loopholes and administrative headaches. This comprehensive guide will show you how to enforce a single, consistent proxy for all users and services on a Windows system. We'll explore the three primary methods—Group Policy (GPO), Registry modification, and WinHTTP (netsh)—so you can choose the right strategy to secure and manage your network traffic effectively.

Why Per-User Proxy Settings Are Not Enough

Relying on default Windows proxy settings is a common but costly mistake. The motivation is understandable: it's the default behavior. Legacy WinINET settings are stored in the user's profile at HKEY_CURRENT_USER (HKCU), making them per-user settings that are inconsistent and easily bypassed on any multi-user machine.

The price of this error is paid in security breaches and administrative chaos. Consider a public library computer from our example: one user logs in, and because their new profile has no proxy configured, they instantly bypass the mandatory content filter. In a corporate setting, a user can disable their proxy, evade security monitoring, and download malware. The next user to log into that same machine inherits a compromised system, even if their own proxy settings are correct. The financial "price" of responding to a single breach far exceeds the minimal effort required to set a machine-wide policy correctly from the start.

This highlights the critical difference in proxy settings per user vs per machine. A centralized, machine-wide configuration stored in HKEY_LOCAL_MACHINE (HKLM), often deployed via Group Policy, ensures every user is subject to the same rules, closing critical security gaps.

Now that you understand the risks associated with default per-user settings and the necessity of a unified policy, let's compare the three primary methods for implementing a robust, per-machine configuration.

Comparison of Per-Machine Proxy Methods

Selecting the right method for configuring per-machine proxy settings involves clear trade-offs. The choice between using GPO, the registry, or WinHTTP depends on your environment's scale and specific needs. By choosing one method for its primary benefit, you inevitably accept its inherent drawbacks. This table breaks down the core compromises to guide your decision-making.

Choosing Your Method: Per-Machine Proxy Configuration Comparison

This table provides a high-level overview to guide your choice. For large, domain-joined enterprise environments, the clear winner for scalability and control is Group Policy. Here's a detailed walkthrough of how to implement it.

Method 1: Using Group Policy (GPO) for Centralized Control

For domain-joined Windows environments, using Group Policy (GPO) is the most reliable and scalable method to enforce consistent proxy settings for all users on a machine. This centralized approach ensures that every user account on a computer, from standard users to administrators, adheres to the same network routing rules. These GPO proxy settings are essential for security, compliance, and traffic management.

1. Open the Group Policy Management Console on your domain controller, create or edit a GPO, and link it to the Organizational Unit (OU) containing the target computers. For a single machine, you can use the Local Group Policy Editor (`gpedit.msc`).
2. Navigate to the key policy location: Computer Configuration > Administrative Templates > Windows Components > Internet Explorer.
3. Find and enable the setting titled "Make proxy settings per-machine (rather than per-user)". This is the critical step that forces Windows to use a single proxy configuration for the entire system instead of individual user profiles.
4. With the per-machine policy active, you must now define the proxy server. This is typically done through Group Policy Preferences under User Configuration > Preferences > Control Panel Settings > Internet Settings. Configure the LAN settings with your proxy's address and port. For example, a marketing department's shared computer can be forced through a proxy this way for compliance monitoring or specialized tasks like ad verification. Since the "per-machine" policy is enabled, this user-level preference will apply to every user on the computer. In complex environments, you may also need to enable Loopback processing mode to ensure user policies apply correctly to the targeted computer objects.

Understanding "Bypass proxy server for local addresses"

When configuring your proxy, you will see this checkbox. Keeping it enabled is standard practice. It prevents the system from routing traffic intended for your internal network (e.g., intranet sites, local file servers) through the external proxy. Disabling it can break access to local resources.

While GPO is the standard for corporate networks, it's not an option for standalone machines or scripted setups. In those cases, you need a more direct method. Let's dive into how to achieve the same result by modifying the Windows Registry.

Method 2: Direct Registry Modification for Scripting and Standalone PCs

For standalone PCs or scalable automation, direct registry modification provides granular control over proxy configurations. Imagine a developer provisioning a test server that isn't on a domain. To ensure all application services use a specific proxy, they can use a script during automated setup to bypass per-user settings and enforce one machine-wide rule.

Warning: Proceed with Caution

Directly editing the Windows Registry is a high-risk operation. An incorrect change can cause system instability. Always back up the registry before making any modifications.

The objective is to force Windows to use a single proxy configuration for all users on the machine. This is done by a specific entry in the HKEY_LOCAL_MACHINE hive. Using the Registry Editor (regedit.exe), navigate to the following path:

HKLM\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings

If the Internet Settings key does not exist, you must create it. Within this key, create a new DWORD (32-bit) Value named ProxySettingsPerUser and set its value to 0. A value of 0 tells the system to ignore per-user proxy settings and apply the machine-wide configuration instead, a crucial aspect of managing HKLM proxy settings.

For repeatable deployments and automation via scripts, using PowerShell is the most efficient method to manage these windows proxy registry settings. The following script creates the necessary key and sets the value:

# Define the registry path and property name$regPath = "HKLM:\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings"$propName = "ProxySettingsPerUser"$propValue = 0# Create the registry key if it doesn't existif (-not (Test-Path $regPath)) {    New-Item -Path $regPath -Force | Out-Null}# Set the DWORD value to 0 to enforce machine-wide proxySet-ItemProperty -Path $regPath -Name $propName -Value $propValue -Type DWord -ForceWrite-Host "'$propName' set to '$propValue' at '$regPath'"

Once this value is set, the proxy server and port configured in Internet Properties (which writes to the DefaultConnectionSettings registry value) will apply to every user and service on that computer.

Configuring the per-machine policy through GPO or the Registry ensures most user-facing applications are covered. However, there's a crucial piece of the puzzle many administrators miss: system services. These processes use a separate network stack called WinHTTP, which requires its own unique proxy configuration.

Method 3: Configuring Proxies for System Services (WinHTTP)

A critical, often-overlooked aspect of proxy configuration is that many background processes and server applications don't use the user-level settings you configure in Internet Options (WinINET). Instead, System services like Windows Update and other applications built on the WinHTTP API have their own independent proxy configuration.

For example, a DevOps engineer configuring a CI/CD runner service on a Windows server will find their automated builds failing to download dependencies. This happens because the runner, operating as a service, uses WinHTTP and is blind to the user's proxy settings.

To configure these system-wide WinHTTP proxy settings, you must use the netsh.exe utility in an elevated Command Prompt or PowerShell terminal. Use the following command to direct traffic through your proxy:

netsh winhttp set proxy proxy-server="http://your.proxy.address:8080"

You can then verify that the settings were applied correctly by running:

netsh winhttp show proxy

Commercial Use Case

For animated services that require accessing geo-diverse APIs, a reliable pool of proxies is essential. Our mobile proxy service provides a robust solution for such scenarios, ensuring your service can operate from any required location without being blocked.

With the user (WinINET) and system (WinHTTP) proxies configured, your machine should be routing all traffic correctly. But in the real world, issues can still arise. Before concluding, let's address some of the most common problems you might encounter.

Troubleshooting Common Issues

When proxy settings are not working correctly, a systematic approach is essential. Use this quick guide to troubleshoot common proxy issues on Windows.

• Why are my proxy settings grayed out or not saving?
  This almost always indicates that settings are being enforced by a Group Policy Object (GPO). Non-administrative users cannot override these settings. To identify the GPO responsible, run gpresult /r from the command line or use the Resultant Set of Policy tool (rsop.msc) to see which policies are being applied to the user and computer.
• My GPO settings aren't applying to a client machine. What's wrong?
  If a machine fails to pick up a new policy, the most common issue is a delay in GPO processing. Connect to the client machine and run gpupdate /force in an elevated Command Prompt to immediately pull the latest policies. Afterwards, run gpresult /r to confirm that your specific proxy GPO is now listed under "Applied Group Policy Objects."
• How can I verify which proxy is actually being used?
  For .NET applications and PowerShell scripts, you can check the default proxy by running [System.Net.WebProxy]::GetDefaultProxy() in a PowerShell window. For detailed inspection of all HTTP/S traffic from a specific application, a web debugger like Fiddler is the definitive tool. For advanced Troubleshooting, Process Monitor can show which registry keys an application is reading to find its configuration.

Conclusion: Choosing the Right Strategy for Your Environment

Ultimately, the correct proxy configuration hinges on your specific context. For domain-joined machines, Group Policy provides centralized, scalable control essential for enforcing consistent Network Policy. For standalone systems, direct registry edits or Netsh commands offer granular, machine-level control. Your choice between a user-level or system-wide per-machine proxy is dictated by whether you need to route traffic for specific user applications or for background services and scripts. Getting this right is a core task in System Administration.

Mastering these settings is foundational for enabling reliable Automation and large-scale Data Scraping. By mastering per-machine proxy settings, you unlock the ability to manage network traffic for complex tasks like large-scale automated QA testing or market research data collection. For these demanding applications, the quality of your proxy is paramount. Our high-reliability mobile proxies are designed to perform in these exact environments.