Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.microsoft.windows > #2807 > unrolled thread

Why do 3 completely different proxy mechanisms exist in Windows?

Started byMarion <marionf@fact.com>
First post2025-09-11 17:46 +0000
Last post2025-10-30 00:47 -0600
Articles 5 on this page of 25 — 6 participants

Back to article view | Back to alt.comp.microsoft.windows

Contents

  Why do 3 completely different proxy mechanisms exist in Windows? Marion <marionf@fact.com> - 2025-09-11 17:46 +0000
    Re: Why do 3 completely different proxy mechanisms exist in Windows? "R.Wieser" <address@is.invalid> - 2025-09-11 22:18 +0200
      Re: Why do 3 completely different proxy mechanisms exist in Windows? Marion <marionf@fact.com> - 2025-09-11 20:50 +0000
        Re: Why do 3 completely different proxy mechanisms exist in Windows? "R.Wieser" <address@is.invalid> - 2025-09-12 08:25 +0200
          Re: Why do 3 completely different proxy mechanisms exist in Windows? Marion <marionf@fact.com> - 2025-09-14 02:07 +0000
            Re: Why do 3 completely different proxy mechanisms exist in Windows? "R.Wieser" <address@is.invalid> - 2025-09-14 08:59 +0200
              Re: Why do 3 completely different proxy mechanisms exist in Windows? Marion <marionf@fact.com> - 2025-09-14 10:08 +0000
                Re: Why do 3 completely different proxy mechanisms exist in Windows? "R.Wieser" <address@is.invalid> - 2025-09-14 15:11 +0200
                  Re: Why do 3 completely different proxy mechanisms exist in Windows? Marion <marionf@fact.com> - 2025-09-14 17:25 +0000
                    Re: Why do 3 completely different proxy mechanisms exist in Windows? Andy Burns <usenet@andyburns.uk> - 2025-09-14 18:39 +0100
                      Re: Why do 3 completely different proxy mechanisms exist in Windows? Marion <marionf@fact.com> - 2025-09-14 18:05 +0000
                        Re: Why do 3 completely different proxy mechanisms exist in Windows? MikeS <mikes@is.invalid> - 2025-09-14 20:09 +0100
                          Re: Why do 3 completely different proxy mechanisms exist in Windows? Marion <marionf@fact.com> - 2025-09-14 19:51 +0000
                            Re: Why do 3 completely different proxy mechanisms exist in Windows? MikeS <MikeS@fred.com> - 2025-09-15 14:11 +0100
                              Re: Why do 3 completely different proxy mechanisms exist in Windows? Marion <marionf@fact.com> - 2025-09-17 19:34 +0000
                    Re: Why do 3 completely different proxy mechanisms exist in Windows? "R.Wieser" <address@is.invalid> - 2025-09-15 01:30 +0200
                      Re: Why do 3 completely different proxy mechanisms exist in Windows? Marion <marionf@fact.com> - 2025-09-15 07:34 +0000
                        Re: Why do 3 completely different proxy mechanisms exist in Windows? "R.Wieser" <address@is.invalid> - 2025-09-15 12:20 +0200
                          Re: Why do 3 completely different proxy mechanisms exist in Windows? Marion <marionf@fact.com> - 2025-09-17 20:01 +0000
            Re: Why do 3 completely different proxy mechanisms exist in Windows? "R.Wieser" <address@is.invalid> - 2025-09-14 09:44 +0200
              Re: Why do 3 completely different proxy mechanisms exist in Windows? Marion <marionf@fact.com> - 2025-09-18 06:42 +0000
            Re: Why do 3 completely different proxy mechanisms exist in Windows? Andy Burns <usenet@andyburns.uk> - 2025-09-14 10:35 +0100
              Re: Why do 3 completely different proxy mechanisms exist in Windows? Marion <marionf@fact.com> - 2025-09-14 10:20 +0000
    Re: Why do 3 completely different proxy mechanisms exist in Windows? Marion <marionf@fact.com> - 2025-09-21 16:02 +0000
      Re: Why do 3 completely different proxy mechanisms exist in Windows? Marion <mariond@facts.com> - 2025-10-30 00:47 -0600

Page 2 of 2 — ← Prev page 1 [2]

#2829

FromMarion <marionf@fact.com>
Date2025-09-18 06:42 +0000
Message-ID<10ag9ki$21h1$1@nnrp.usenet.blueworldhosting.com>
In reply to#2813
UPDATE:

I've been building a privacy-based system for about a month now, and while 
I had not touched proxies since, oh, about 2001 or so, they're complex now.

Windows doesn't use a single unified proxy configuration. Instead, it has 
multiple proxy stacks, each used by different types of applications.
 1. WinINet Stack
 2. WinHTTP Stack
 3. Windows Web Proxy Auto-Discovery (WPAD)
 4. Modern App Stack (Windows Runtime / UWP)
 5. Custom Proxy Clients

Examples of apps using those proxy stacks might be
 1. The WinINet stack is used by Internet Explorer & Chrome 
 2. The WinHTTP stack is used by Windows Update
 3. WPAD + PAC Files is used by the WinInet stack (e.g., Chrome & Firefox)
 4. Windows Runtime / UWP is used by the Microsoft Store, Mail, Weather
 5. I wrote my own custom proxy client but another example is Proxifier

A custom proxy client is any tool or script that:
 a. Launches or manages a proxy service
 b. Configures system or application proxy settings
 c. Handles traffic & proxy logic independently of Windows stacks

Below, for example, is my script-driven custom proxy client.

My custom proxy client (
 A. Bridges Psiphon with Windows proxy stacks, 
 B. Serves and applies PAC logic, 
 C. Syncs across WinINet and WinHTTP, 
 D. and handles elevation and logging. 

I feel it's a custom proxy client by any reasonable definition, which...
 1. Launches a Proxy Engine 
 2. Serves a PAC File Before launching Psiphon. 
 3. Applies Proxy Logic Once Psiphon is running.
 4. Syncs Proxy Settings Across Stacks After configuring WinINet 
 5. Handles Elevation and Logging If not already running as admin.
 6. Keeps the Shell Open Instead of closing the command window.

Specifically, in my Windows 10 environment, the script below 
 1. Starts psiphon3.exe in SOCKS mode which provides a local SOCKS5
    proxy tunnel, which apps can use to route traffic through 
    Psiphon's encrypted network.
 2. Runs mongoose.vbs to serve a proxy.pac file over HTTP at
    http://127.0.0.1/proxy.pac. It waits a couple seconds, 
    then uses curl to verify the PAC file is actually available
    before continuing.
 3. Calls pac.cmd, which sets up the system to use the PAC file. 
    It also directly sets the PAC URL and enables Auto-Detect 
    in the registry under: 
    HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings
 4. Runs "netsh winhttp import proxy source=ie" which copies the 
    static proxy settings from WinINet into WinHTTP
    Note: It smartly avoids transferring SOCKS or PAC logic 
    to WinHTTP, since WinHTTP doesn't support those.
 5. Relaunches itself with UAC elevation & logs activity to proxy.log, 
    including timestamps when PAC logic is triggered.
 6. Pauses at the end so you can see what happened.

Here, for open source inspection, is some of that custom proxy client code.
 @echo off
 REM C:\data\sys\batch\psiphon.bat version 1.0 20250819  
 REM This is psiphon.bat version 2.1 (118 lines)
 REM Runs "C:\app\network\psiphon\psiphon3.exe" -mode=socks
 REM This method leaves windows open.
 REM %comspec% /k C:\app\network\psiphon\psiphon3.exe -mode=socks
 REM This method closes windows.
 REM psiphon.bat version 1.1 20250916
 REM Added automatic PAC sync/apply after Psiphon launch
 REM psiphon.bat version 1.2 20250916
 REM Added logging to proxy.log when PAC is triggered from psiphon
 REM psiphon.bat version 1.3 20250916
 REM Added optional pause for viewing output before closing
 REM psiphon.bat version 1.4 20250916
 REM Changed to never close parent cmd window and always pause at end
 REM psiphon.bat version 1.5 20250916
 REM Added self-elevation to request UAC if not already admin
 REM psiphon.bat version 1.6 20250916
 REM Added final PAC URL + Auto-Detect set to ensure persistence 
 REM after Psiphon/proxy changes
 REM psiphon.bat version 1.7 20250917
 REM Added launch of mongoose.vbs to serve proxy.pac before PAC logic
 REM psiphon.bat version 1.8 20250917
 REM Reordered launch sequence: Mongoose now starts BEFORE Psiphon
 REM Added PAC availability check using curl
 REM Added 2-second wait after Mongoose launch to ensure readiness
 REM psiphon.bat version 1.9 20250917
 REM Error: PAC file not available. Aborting. Press any key to continue 
 REM Increased delay from 2 to 4 to give Mongoose more time to bind & serve
 REM psiphon.bat version 2.0 20250917 (111 lines)
 REM Decreased delay back to 2 as it didn't make a difference
 REM Added echo message during Mongoose wait to indicate progress
 REM psiphon.bat version 2.1 20250917 (118 lines)
 REM Expanded Psiphon┬ reach to WinHTTP apps without compromising WinINET apps
 REM By adding Automatic Sync of WinINET to WinHTTP (e.g., for Windows Update)
 REM Transfers only the Psiphon-injected static HTTP/HTTPS proxy address
 REM Does not transfer PAC logic and SOCKS settings from WinInet to WinHTTP
 
 :: --- Elevate to admin if not already ---
 >nul 2>&1 net session
 if %errorlevel% neq 0 (
     echo Requesting administrative privileges...
     powershell -Command "Start-Process '%~f0' -Verb RunAs"
     exit /b
 )
 
 REM Launch Mongoose silently to serve proxy.pac
 cscript //nologo "C:\data\sys\batch\launchmongoose.vbs"
 
 REM Wait for Mongoose to initialize (added in v1.8)
 echo waiting for mongoose... (added in v2.0)
 timeout /t 2 /nobreak >nul
 
 REM Verify PAC file is available before proceeding (added in v1.8)
 curl --silent --fail http://127.0.0.1/proxy.pac >nul || (
     echo PAC file not available. Aborting.
     pause
     exit /b
 )
 
 REM Launch Psiphon in SOCKS mode
 start "" /D "C:\app\network\psiphon" psiphon3.exe -mode=socks
 
 REM Wait a few seconds for Psiphon to initialize
 timeout /t 5 /nobreak >nul
 
 REM Log that PAC is being run from psiphon
 echo [%DATE% %TIME%] pac.cmd triggered from psiphon.bat >> C:\data\sys\log\proxy.log
 
 REM Apply PAC logic automatically (silent mode)
 call "C:\data\sys\batch\pac.cmd" /silent
 
 REM Force PAC URL and Auto-Detect to desired values at the very end
 REM This ensures Psiphon or proxy sync cannot leave them unset
 reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v AutoConfigURL /t REG_SZ /d http://127.0.0.1/proxy.pac /f >nul
 reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v AutoDetect /t REG_DWORD /d 1 /f >nul
 
 REM Sync WinINET proxy settings into WinHTTP (added in v2.1)
 netsh winhttp import proxy source=ie
 
 REM Always pause so you can see output if run from a console
 echo.
 echo Press any key to close...
 pause >nul
 
 REM End batch without killing the shell
 exit /b
 
 
 ::START: You type Win+R -> psiphon
 ::    |
 ::    v
 ::psiphon.bat 
 ::    - Check if running as admin
 ::        - If not, request UAC elevation and restart
 ::    - Launch mongoose.vbs to serve proxy.pac (moved earlier in v1.8)
 ::    - Wait 2 seconds for Mongoose to initialize (added in v1.8)
 ::    - Echo "waiting for mongoose..." during delay (added in v1.9)
 ::    - Verify PAC file is accessible via curl (added in v1.8)
 ::    - Launch psiphon3.exe in SOCKS mode
 ::    - Wait 5 seconds for Psiphon to initialize
 ::    - Log that pac.cmd is being run
 ::    - Call pac.cmd /silent
 ::        |
 ::        v
 ::    pac.cmd
 ::        - Log run
 ::        - Run proxy.cmd /sync to align WinINET -> WinHTTP
 ::        - Capture current PAC URL and Auto-Detect status
 ::        - If missing or wrong, call proxy.cmd with PAC URL
 ::        - Force set PAC URL and Auto-Detect in registry
 ::        - Re-capture status so final display is accurate
 ::        - Show final PAC and Auto-Detect status
 ::        - Return to psiphon.bat
 ::    - Force set PAC URL and Auto-Detect again (double guarantee)
 ::    - Pause for user to see output
 ::    - Exit without closing parent shell
 ::END
--

[toc] | [prev] | [next] | [standalone]

#2814

FromAndy Burns <usenet@andyburns.uk>
Date2025-09-14 10:35 +0100
Message-ID<minginF756qU1@mid.individual.net>
In reply to#2811
Marion wrote:

> Windows uses 3 proxy configuration methods to accommodate different
> environments, user needs & network policies. These mechanisms are:
> 1. Automatic Detection (WPAD)
> 2. Automatic Configuration Script (PAC file)
> 3. Manual Proxy Setup

WPAD is just a mechanism (two actually, one via DHCP, the other via DNS) 
to provide a PAC script.

[toc] | [prev] | [next] | [standalone]

#2816

FromMarion <marionf@fact.com>
Date2025-09-14 10:20 +0000
Message-ID<10a64u8$1rrc$1@nnrp.usenet.blueworldhosting.com>
In reply to#2814
Andy Burns wrote:
> Marion wrote:
> 
>> Windows uses 3 proxy configuration methods to accommodate different
>> environments, user needs & network policies. These mechanisms are:
>> 1. Automatic Detection (WPAD)
>> 2. Automatic Configuration Script (PAC file)
>> 3. Manual Proxy Setup
> 
> WPAD is just a mechanism (two actually, one via DHCP, the other via DNS) 
> to provide a PAC script.

Hi Andy,

Lord knows this proxy stuff is confusing to me, so I appreciate your help.

So first, thanks for trying to help me better understand why Windows is so
miserable when setting up something seemingly as simple as Psiphon to
proxify a web browser, a Usenet client, a Telegram/WhatsApp client, etc.

I think what you're trying to explain is that Web Proxy Auto-Discovery is
just a way for Windows to auto-find proxy settings where WPAD uses DHCP or
DNS to locate a Proxy Auto-Config script file where the PAC script tells
Windows which proxy to use for each URL. Is that right?

So I think you're saying that WPAD itself doesn't do proxying. It just
helps Windows find the PAC file. The PAC file then controls proxy behavior.

If that's right, then WPAD is just a discovery method, not a proxy engine.
It helps Windows locate the PAC script, which defines proxy rules.

Here's the proxy.pac file that I set up but I'm not sure if it works yet.
(I glommed it using my needs + a bunch of examples I had found on the net.)

 /* C:\data\sys\batch\proxy.pac v1.1 - 20250902
    Bypass proxy for:
    - *.google.com, *.gmail.com, mail.google.com
    - *.amazon.com, amazon.com
    - *.copilot.microsoft.com, *.bing.com, *.microsoft.com
    Other traffic via SOCKS proxy 127.0.0.1:1080
 */
 
 function FindProxyForURL(url, host) {
   // Bypass Gmail & Google
   if (shExpMatch(host, "*.google.com") ||
       shExpMatch(host, "*.gmail.com") ||
       shExpMatch(host, "mail.google.com")) {
     return "DIRECT";
   }
 
   // Bypass Amazon
   if (shExpMatch(host, "*.amazon.com") ||
       shExpMatch(host, "amazon.com")) {
     return "DIRECT";
   }
 
   // Bypass Copilot & Microsoft
   if (shExpMatch(host, "*.copilot.microsoft.com") ||
       shExpMatch(host, "*.bing.com") ||
       shExpMatch(host, "*.microsoft.com")) {
     return "DIRECT";
   }
 
   // All other traffic via SOCKS
   return "SOCKS 127.0.0.1:1080";
 }

[toc] | [prev] | [next] | [standalone]

#2834

FromMarion <marionf@fact.com>
Date2025-09-21 16:02 +0000
Message-ID<10ap7i1$29m1$1@nnrp.usenet.blueworldhosting.com>
In reply to#2807
UPDATE

I've been testing the free proxy browsers, mostly Aloha VPN browser, where
I found a quirk that isn't intuitive - but which is easy to understand.

When you turn on Aloha's blue VPN shield, the browser creates a virtual
network interface and routes all traffic through that VPN shield.

This means even if Psiphon is running, Psiphon's proxy is ignored unless
Aloha is configured to respect system proxy settings (which it isn't).

VPNs, even Aloha's browser-based blue shield VPN, operate at a lower level
(network layer) while Psiphon's SOCKS proxy works at the application layer.

I found this out by running three simple tests anyone can easily run now:

Scenario 1: Aloha without turning on the Aloha VPN nor turning on Psiphon
 IP shown: My ISP-assigned IP.
 Why? No VPN or proxy is active, so traffic flows directly through.

Scenario 2: 1st Psiphon, then Aloha (without turning on Aloha's VPN shield)
 IP shown: Psiphon's SOCKS proxy IP (172.236.227.192).
 Why? Psiphon routes traffic through its encrypted tunnel & Aloha 
 (even without its VPN turned on) uses the system's proxy settings.

Scenario 3: 1st Psiphon, then Aloha with VPN shield ON
 IP shown: Aloha VPN IP (176.123.4.107).
 Why? Aloha's VPN is a full tunnel VPN, which overrides system proxy 
 settings. Once I activate Aloha's VPN shield, it takes control of 
 the network stack and routes all traffic through its own VPN 
 server (which effectively bypasses Psiphon's socks proxy entirely).

Once the Aloha blue VPN shield is active, it takes control of the network
stack with the result being the Psiphon SOCKS proxy becomes irrelevant
unless the Aloha browser is explicitly configured to tunnel through it.

[toc] | [prev] | [next] | [standalone]

#2954

FromMarion <mariond@facts.com>
Date2025-10-30 00:47 -0600
Message-ID<10dv1mb$2tvg$1@nnrp.usenet.blueworldhosting.com>
In reply to#2834
When I started this thread, oh, about a month ago, I didn't have any
experience with PAC (proxy auto config) files on Windows. Now I do.

It turns out, after I wrote a complete Windows system proxy utility, that
the question I had oh so innocently asked on 9/11 was confusing to all.

It turns out, after I wrote and tested a few tutorials for using proxies
with and without PAC files, that Windows has two built-in proxy mechanisms.
 1. WinINET
 2. WinHTTP

I'm indebted to Andy Burns for cluing me into PAC files a month ago
because WinINET and WinHTTP are global "all or nothing" proxy mechanisms,
whereas the PAC file mechanisms (proxy auto config) allow you to decide,
per request, per app (such as FF) whether to go direct or thru the proxy.

In addition, since a month ago when I knew nothing about proxies, I've
written tutorials on using proxifiers (such as ProxyBridge which Allan
Higdon kindly clued me into) which allow you to choose binaries to proxy.

Some apps (like Firefox) can load a PAC file directly. Others can use it if
you serve it via HTTP and point Windows’ system proxy settings at it.

For serving the PAC file, I've written tutorials in the past month using
the free lightweight "mongoose" file server, launched with a vbs script.

I've also written tutorials in the past month on how to use the Tor &
Psiphon & Freegate free ad-free no-registration proxies for your use.

With these methods, we can fine tune which traffic is tunneled thru the
proxy, which stays local, and even chain multiple proxies if needed.

In summary, in the past month since I asked this innocent question, I've
learned that Windows already has two built-in proxy systems: 
 1. WinINET (used by user-facing apps like Internet Explorer, Edge, Office,
and anything that says "Use system proxy settings").
 2. WinHTTP (used by background services and scripts). 

Both let us set a proxy, but they're blunt tools where it's either
everything through the proxy or nothing.

As Andy had suggested to me, a PAC file is smarter. 

It's just a tiny JavaScript function that runs for every web request and
decides: should this go direct, or through the proxy? 

That means we can tunnel most of our traffic through Psiphon or Tor (or any
SOCKS/HTTPS proxy) while letting sensitive or local sites bypass it
automatically. Instead of flipping proxy settings on and off, the PAC file
acts like a traffic cop, routing each request down the right road.

In a nutshell, I think that's the answer to the question originally asked.
-- 
Helping others & learning from them is what this Usenet ng is all about.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | alt.comp.microsoft.windows

csiph-web