XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: marionf@fact.com

Why do 3 completely different proxy mechanisms exist in Windows?
Hell if I know.

The answer may be simply that Windows evolved over decades, and different components use different networking stacks, each with its own proxy logic.

1. WinINET (Windows Internet API)
Used by: Internet Explorer, legacy Edge, MS Office, "and more".
Proxy set via: Internet Options > Connections > LAN Settings.
Behavior: Reads settings from the registry and supports automatic
configuration via PAC files and WPAD.
Psiphon sets up a proxy here so apps using WinINET use it.

2. WinHTTP (Windows HTTP Services)
Used by: System services like Windows Update, Background Intelligent
Transfer Service (BITS), and some enterprise apps.
Proxy set via: netsh winhttp set proxy or via Group Policy.
Behavior: Doesn't automatically inherit WinINET settings
unless explicitly copied over.
If WinHTTP isn't configured, system services bypass Psiphon's tunnel.

3. PAC/AutoDetect (Proxy Auto-Config)
Used by: Modern browsers like Chrome, Firefox, & Chromium-based Edge.
Proxy set via: Browser-specific settings or via system-wide auto-detect.
Behavior: Uses JavaScript-based PAC files or WPAD to dynamically
choose proxy per URL.
Browsers may ignore WinINET/WinHTTP and rely solely on PAC,
so Psiphon must ensure PAC settings are correctly applied.

If any layer is missed, traffic could leak outside the tunnel - defeating
the purpose of Psiphon's censorship circumvention or privacy protection.

But I never ran into proxies until I started building my own DIY VPN web browser, so I wonder what others here have learned about why Windows has
three different proxy mechanism where you need all three for full coverage.

Q: Why do 3 completely different proxy mechanisms exist in Windows?
A: ?
--
Helping one another - because it's right - & because we learn from others.

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: address@is.invalid

Arlen,

Why do 3 completely different proxy mechanisms exist in Windows?
Hell if I know.

The answer may be simply that Windows evolved over decades, and
different components use different networking stacks, each with
its own proxy logic.

Do you think that would work, three different networking stacks that all try
to talk to the same hardware (the ethernet card) ?

Why do you think they are/expose different proxy mechanisms - where did you
get that info from ?

Have you googled for all three, and if so what is said about them ?

Last but not least : The first two exist as DLLs of the same name and have APIs. I have no idea what you think "PAC/AutoDetect" is, or what ... thingamagotchy (program? DLL? Something else?) in windows offers it to you.

Regards,
Rudy Wieser

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: marionf@fact.com

R.Wieser wrote:

Do you think that would work, three different networking stacks that all try to talk to the same hardware (the ethernet card) ?

Why do you think they are/expose different proxy mechanisms - where did you get that info from ?

Have you googled for all three, and if so what is said about them ?

Last but not least : The first two exist as DLLs of the same name and have APIs. I have no idea what you think "PAC/AutoDetect" is, or what ... thingamagotchy (program? DLL? Something else?) in windows offers it to you.

Oh, they exist.
Trust me, they exist.

The question wasn't whether they exist. But why three of them exist.
All of which, essentially, do the same thing when I run Psiphon freeware.

Run this script I wrote to tell you what each of the settings are set to.
@echo off
REM C:\data\sys\batch\proxy.cmd v2.0 - 20250902
REM Proxy diagnostic & config tool for WinINET, WinHTTP, PAC

REM Usage:
REM Win+R > proxy
REM Win+R > proxy /help
REM Win+R > proxy /sync
REM Win+R > proxy http://url.pac
REM Win+R > proxy /nopac
REM Win+R > proxy /status
REM Win+R > proxy /reset
REM Win+R > proxy /silent
REM Win+R > proxy /silent /sync

REM Proxy types:
REM Type 1: WinINET - IE, Edge, MS Office, most apps
REM Type 2: WinHTTP - system services like Windows Update
REM Type 3: PAC/AutoDetect - Chrome, Edge, Firefox (if set to use system proxy)

REM Show usage
if /i "%~1"=="/help" (
echo Usage:
echo proxy
echo proxy /sync
echo proxy http://...
echo proxy /nopac
echo proxy /status
echo proxy /reset
echo proxy /silent ...
exit /b
)

REM Log command
set LOG=C:\data\sys\log\proxy.log
echo [%DATE% %TIME%] %cmdcmdline% >> %LOG%

REM Begin scoped env
setlocal

set KEY="HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings"

REM Detect /silent flag
if /i "%~1"=="/silent" (
set SILENT=1
shift
)

REM /reset flag
if /i "%~1"=="/reset" (
echo Reset proxy settings...
reg delete %KEY% /v ProxyEnable /f >nul 2>&1
reg delete %KEY% /v ProxyServer /f >nul 2>&1
reg delete %KEY% /v AutoConfigURL /f >nul
reg add %KEY% /v AutoDetect /t REG_DWORD /d 0 /f >nul
netsh winhttp reset proxy >nul 2>&1
echo Proxy settings cleared.
goto SHOWCONFIG
)

REM /status flag
if /i "%~1"=="/status" (
echo Show proxy config...
goto SHOWCONFIG
)

REM /sync flag
if /i "%~1"=="/sync" (
echo Sync WinINET into WinHTTP...
netsh winhttp import proxy source=ie
if errorlevel 1 (
echo ERROR: Access denied. Run as admin.
)
echo Done.
goto SHOWCONFIG
)

REM /nopac flag
if /i "%~1"=="/nopac" (
echo Disable PAC & Auto-Detect...
reg delete %KEY% /v AutoConfigURL /f >nul 2>&1
reg add %KEY% /v AutoDetect /t REG_DWORD /d 0 /f >nul
echo PAC & Auto-Detect disabled.
goto SHOWCONFIG
)

REM Set PAC URL
if not "%~1"=="" (
echo Set PAC URL: %~1
reg add %KEY% /v AutoConfigURL /t REG_SZ /d %~1 /f >nul
reg add %KEY% /v AutoDetect /t REG_DWORD /d 1 /f >nul
)

REM Diagnostic output
:SHOWCONFIG
echo ============================================
echo WINDOWS PROXY CONFIG CHECK
REM Avoid slash to prevent parsing bug
echo ============================================

REM WinINET status
echo.
echo [1] WinINET
for /f "tokens=2,* skip=2" %%A in ('reg query %KEY% /v ProxyEnable 2^>nul') do set ProxyEnable=%%B
for /f "tokens=2,* skip=2" %%A in ('reg query %KEY% /v ProxyServer 2^>nul') do set ProxyServer=%%B
if "%ProxyEnable%"=="0x1" (
echo Proxy ENABLED
echo Server: %ProxyServer%
) else (
echo Proxy DISABLED
)

REM WinHTTP status
echo.
echo [2] WinHTTP
for /f "tokens=1,* delims=:" %%A in ('netsh winhttp show proxy ^| findstr /R /C:"Proxy Server(s)"') do set curWinHTTP=%%B
set curWinHTTP=%curWinHTTP:~1%
if "%curWinHTTP%"=="" (
echo No WinHTTP proxy - import from WinINET...
netsh winhttp import proxy source=ie >nul 2>&1
) else (
echo WinHTTP proxy already set
)
netsh winhttp show proxy

REM PAC status
echo.
echo [3] PAC / AutoDetect
for /f "tokens=2,* skip=2" %%A in ('reg query %KEY% /v AutoConfigURL 2^>nul') do set PACurl=%%B
for /f "tokens=2,* skip=2" %%A in ('reg query %KEY% /v AutoDetect 2^>nul') do set AutoDetect=%%B
if defined PACurl (
echo PAC URL: %PACurl%
) else (
echo No PAC URL
)

REM PAC logic summary
if /i "%PACurl%"=="http://127.0.0.1/proxy.pac" (
echo PAC logic: Bypass Gmail, Amazon, Copilot
echo Other traffic via SOCKS proxy 127.0.0.1:1080
)

if "%AutoDetect%"=="0x1" (
echo Auto-Detect ENABLED
) else (
echo Auto-Detect DISABLED
)

echo.
echo ============================================
echo Proxy check complete
echo ============================================

endlocal

REM Final pause unless /silent
if not defined SILENT (
echo.
echo Press Enter to close...
pause >nul
)
exit

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: address@is.invalid

Arlen,

Last but not least : The first two exist as DLLs of the same name and
have
APIs. I have no idea what you think "PAC/AutoDetect" is, or what ...
thingamagotchy (program? DLL? Something else?) in windows offers it to
you.

Oh, they exist.
Trust me, they exist.

I'm sorry, but no. You have a history of claiming stuff unsupported by anything, and I therefore can't take your word for something anymore.
Sorry.

I know the first two exist as DLLs, but have no idea why you declare them to
be proxies.

The latter one ? Although I think I know what "Proxy Auto Configure / Auto Detect" is supposed to do, I've got no idea what program/DLL/other you are talking about - and as such no idea why you call it a proxy.

The question wasn't whether they exist.

Than my help to you ends here.

Regards,
Rudy Wieser

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: marionf@fact.com

R.Wieser wrote:

I've got no idea what program/DLL/other you are
talking about - and as such no idea why you call it a proxy.

For all to benefit, since I'm wired to be helpful as well as to learn,
my first experience with the Windows proxy mechanism was in the olden days
when we had to proxify tor (well before the tor browser bundle existed).

Before Firefox and before the Tor Browser Bundle, using Tor was like
assembling IKEA furniture without instructions. You had to run Tor
separately, then manually configure each app to use it as a SOCKS proxy. It worked for some people, but I always had problems with the socks proxy.

Since those days (probably around 2001 or so) I haven't touched proxies.
Until the Epic Privacy Browser died that is, about a month or so ago.

So I built my own DIY privacy browser, which is pretty much finished.
But then I wanted to add a proxy on top of the VPN on top of the VPN.

It's slow. But it works. All using freeware that anyone can use too.
No registration necessary (as I don't use tools that need an account).

The free proxy I'm using for Windows is Psiphon <https://psiphon.ca/>
C:\software\network\proxy\psiphon\psiphon3.exe
Name: psiphon3.exe
Size: 10402576 bytes (10158 KiB)
SHA256: DB1BAF76F0333F4743919A86F35037559F9E7DA7DF14982DFC16FB8DC0BE6BE2

A proxy is an intermediary server that routes your internet traffic.

That is, instead of connecting directly to a site, your request goes
through the proxy which forwards it on your behalf for the purpose of
a. Hiding your IP address
b. Bypassing censorship
c. Adding an additional layer of anonymity (e.g., to a VPN setup)

There are different types of proxies, but mainly I seem to see only two:
A. HTTP proxies - for web traffic only
B. SOCKS proxies - which are more flexible so they're used by Tor

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

Windows checks these settings in a layered way, for example,
1. If Auto Detect is enabled, Windows tries WPAD first.
2. If a PAC file is specified, Windows uses that next.
3. If Manual settings are entered, they override the others

Frustratingly though, each method is completely different. Sigh.
1. Automatic Detection uses WPAD to find proxy settings via DHCP or DNS
2. PAC File (Auto Script) loads a JavaScript-based file for routing logic
3. Manual Configuration sets the proxy server address & port

The script I supplied checks proxy mechanisms in the reverse order:
3. WinINET (Manual Proxy Setup)
2. WinHTTP (System Proxy) Automatic Configuration Script (PAC file)
1. PAC / Auto-Detect (Automatic Detection + PAC File) (WPAD)
The script checks them, and then sets them if they're not set.

Specifically
3. WinINET is checked first via registry keys
'ProxyEnable' and 'ProxyServer'.
2. WinHTTP is checked next using 'netsh winhttp show proxy'
1. PAC / AutoDetect is checked last via registry values for
'AutoConfigURL' and 'AutoDetect'

This order makes sense for diagnostics:
- WinINET is user-level and most commonly used.
- WinHTTP is system-level and often inherits from WinINET.
- PAC/AutoDetect is more dynamic and optional, so it's checked last.

Note the '/sync' flag explicitly copies WinINET settings into WinHTTP, reinforcing that WinINET is the primary source and WinHTTP is secondary.

In summary, the question is simply why do 3 completely different proxy mechanisms exist in Windows. I'm hoping to find someone who knows why.

If nobody knows more than I do, then at least everyone can learn from my
recent experience using Psiphon freeware with Microsoft Windows browsers.

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: address@is.invalid

Arlen,

I've got no idea what program/DLL/other you are
talking about - and as such no idea why you call it a proxy.

[snip snip snip]

The free proxy I'm using for Windows is Psiphon <https://psiphon.ca/> C:\software\network\proxy\psiphon\psiphon3.exe

...

A proxy is an intermediary server that routes your internet traffic.

That is, instead of connecting directly to a site, your request
goes through the proxy

Yep. But what was/is its intended purpose ?

which forwards it on your behalf for the purpose of
a. Hiding your IP address

Your psiphon3 proxy is installed on your 'puter, and so it still uses your 'puters IP. No IP hiding possible.

Though that /side effect/ can be had (not a proxies purpose, so it could
still 'leak' your IP).

b. Bypassing censorship

I guess it could do that. A bit of a poor-mans and rather limited VPN I
guess.

c. Adding an additional layer of anonymity (e.g., to a VPN setup)

If your proxy hides your IP, than the VPN just re-hides it. What good does that do ? Also, a repeat of your first point.

[snip snip snip]

There are different types of proxies, but mainly I seem to see only
two:
A. HTTP proxies - for web traffic only
B. SOCKS proxies - which are more flexible so they're used by Tor

[snip snip snip]

So, you now know what a proxy is, that there are different proxies for the different kinds of internet connections and that you installed one yourself.

... which answers your own question to why you could have multiple of them.


- The question still is why you think those two DLLs you named are proxies
(I'm dropping the last one, as thats just a description of an intended functioning, not something you can have running on your 'puter)

Regards,
Rudy Wieser

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: address@is.invalid

Arlen,

The free proxy I'm using for Windows is Psiphon <https://psiphon.ca/>

Oh boy ...

I just visited that above page (to see what it's proxying) and noticed that
it hasn't got "proxy" on that page anywhere. It however /does/ mention,
rather prominently, that its "More Than a VPN" and "Where other VPNs can't connect, Psiphon will find a way."

iow, Psiphon isn't a proxy at all.

Regards,
Rudy Wieser

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: marionf@fact.com

R.Wieser wrote:

That is, instead of connecting directly to a site, your request
goes through the proxy

Yep. But what was/is its intended purpose ?

A proxy like Psiphon reroutes traffic. Instead of going directly to a site, your request goes thru Psiphon, which masks your IP & may encrypt some
data. It's useful for bypassing blocks, switching IPs fast or adding light obfuscation, where you get speed and IP obfuscation as the benefit.

An "intended purpose" can vary, of course, depending on the privacy need.
1. Circumvent censorship
2. Hide IP
3. Add weak encryption
4. Chain with VPNs for layered privacy

My setup, for example, chains three levels (two of which are optional).
1. VPN (full tunnel)
2. Psiphon (proxy tunnel)
3. VPN browser (app-level tunnel)

Each adds a layer. You can use 1, 2 or all 3. More layers = more
obfuscation, but slower speed. Psiphon alone is fast & light.

It's good for quick IP switch or bypassing filters.

which forwards it on your behalf for the purpose of
a. Hiding your IP address

Your psiphon3 proxy is installed on your 'puter, and so it still uses your 'puters IP. No IP hiding possible.

True, Psiphon runs locally but tunnels traffic thru remote servers.
While Psiphon sees my IP address (if I run it first, that is), the
destination sees Psiphon's exit node's IP, not mine. That's IP masking.

Though that /side effect/ can be had (not a proxies purpose, so it could still 'leak' your IP).

Psiphon is definitely not perfect. Especially on Windows which is miserable
to set the proxy (remember, there are three different ways and each app
chooses one or none of those three different ways - so it is miserable).

You're right that a misconfig or leaks can expose your IP, which is why I
wrote the script to check and set the three different ways after all. :)

Used correctly, Psiphon hides your IP from visited sites, and if you put a
VPN before or after Psiphon (or both), then each is hidden from the other.

b. Bypassing censorship

I guess it could do that. A bit of a poor-mans and rather limited VPN I guess.

There's a trick that I don't fully understand so I hope others can flesh it out, but Psiphon and VPN "look different" to the ISP & to the web site.

Psiphon is designed to bypass censorship by tunneling traffic thru proxy & VPN-like methods. It uses a mix of SSH, HTTP & VPN protocols to evade
blocks. While not a full VPN, it routes traffic thru remote servers,
allowing access to restricted content.

It's not "limited" in purpose. It's optimized for reachability, not
encryption. To do that, Psiphon uses obfuscated protocols (SSH, HTTP, VPN)
to bypass blocks. It often mimics regular web traffic to avoid detection.
VPNs use standard tunneling protocols (OpenVPN, WireGuard, IPsec) that are easier to fingerprint.

TO the ISP, for example VPN (encrypted tunnel, known ports, predictable handshake) looks different than Psiphon (which may look like HTTPS or SSH, which could be harder to block due to it not looking suspicious).

To the destination website, the VPN IP exit server is often a known
datacenter, whereas Psiphon's exit node is intended to rotate or mimic residential exit nodes (as far as I can ascertain, anyway).

While it may or may not work, the point is that Psiphon may evade DPI or filtering better. VPN offers stronger encryption but is easier to detect.

c. Adding an additional layer of anonymity (e.g., to a VPN setup)

If your proxy hides your IP, than the VPN just re-hides it. What good does that do ? Also, a repeat of your first point.

To answer your question, let's go slowly here as the order matters (VPN
first Psiphon second versus Psphon first VPN second) and the fact that not every app respects proxy mattes too, as does the fact that proxies are
faster than VPN as does the fact that proxies look different to snoopers
than VPN, etc.,

See? I told you it's complicated.

That's why I'm asking for someone on this newsgroup who knows more than I
do because I only touched proxies 25 years ago and again, only a week ago.

So far you're the only one on this newsgroup who even seems to understand
it, where I was hoping someone would tell ME how this darn thing works.

Each layer masks different metadata. Stacking them splits trust.

For example, let's say I run system-wide VPN first & then Psiphon second.
1. The VPN server sees my real IP address & encrypts my traffic.
2. The Psiphon server sees only the VPN IP & forwards the traffic.
3. The final destination sees the Psiphon server
(which looks like a residential IP address).

The result is no single party sees the full picture. ISP sees VPN. VPN sees Psiphon. Psiphon sees destination. Destination sees Psiphon exit IP.

It's not redundant. It's compartmentalization.

The question still is why you think those two DLLs you named are proxies
(I'm dropping the last one, as thats just a description of an intended functioning, not something you can have running on your 'puter)

Let's be clear that I never once mentioned DLLs. I didn't say WinINET or WinHTTP *are* proxies. I said they support proxy behavior. Windows apps use those APIs to apply proxy settings, including PAC/AutoDetect. PAC isn't a
DLL, it's a config script. AutoDetect uses WPAD or DHCP to find proxy
settings.

My question was about how Windows handles proxy routing, not about DLL internals.

I only started using proxies a week ago so I'm hoping something (anyone!)
on this newsgroup knows them better than I do as they're not intuitive.

Why do 3 completely different proxy mechanisms exist in Windows anyway?

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: marionf@fact.com

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";
}

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: address@is.invalid

Arlen,

That is, instead of connecting directly to a site, your request
goes through the proxy

Yep. But what was/is its intended purpose ?

A proxy like Psiphon reroutes traffic. Instead of going directly
to a site, your request goes thru Psiphon, which masks your IP &
may encrypt some data.

What you are describing there is a VPN, with that Psiphon executable most likely to make configuring easier.

Than again, the above VPN is most always a simple forwarding service, not
even allowing you access to the rest of the "VPN 'puter" you are conncting
to (its a misnomer, but a name one most users know. Like asperine).

And by the way: that (goes thru something which changes your IP) is what an internet modem/router does too. Yet, its not called a proxy ...

Same goes for your internet provider, or a search engine like DuckDuckGo
(and others). Those are not called proxies either.

A description of the different kinds of proxies and the internet protocols
they manage :

https://www.pcmag.com/explainers/what-is-a-proxy-server-and-do-you-need-one

Mind you, although not mentioned, HTTP(S) proxies where ment to buffer
requests for webpages : one person causes the webpage (and its resources) to
be retrieved and cached, and all after him get the cached webpage (and resources).

A way to minimize (metered, costly) internet trafic. It also spead up retrieval times (for all but the first request) - though that was more important when we had only dial-up internet speeds. Than again, Google is known to have proxy servers all over the world, caching the data from it central storage.

My setup, for example, chains three levels (two of which are optional).
1. VPN (full tunnel)
2. Psiphon (proxy tunnel)
3. VPN browser (app-level tunnel)

I'm sorry, but #2 is meaningless to me. Whats the difference with #1 ?

As for #1 and #3 ? That is most likely where the Psiphon executable comes
into play : to be able to easily select your mode, as well as doing the filtering on what (apps as well as target IPs) need to be redirected to the
VPN server.

Each adds a layer. You can use 1, 2 or all 3.
More layers = more obfuscation, but slower speed.

I don't think so. You can't have a "full tunnel" and at the same time a "app-level tunnel". And ofcourse, when you have a "full tunnel" or
"app-level tunnel" you get a "proxy tunnel" thrown in for free - otherwise
the data doesn't get to your VPN server.

Your psiphon3 proxy is installed on your 'puter, and so it
still uses your 'puters IP. No IP hiding possible.

True, Psiphon runs locally but tunnels traffic thru remote
servers.

Indeed.

Did you know that Windows has such a thing build-in and everyone browsing
the internet uses it, but nobody calls it a proxy ? You will probably recognise its name : "default gateway". And the "remote server" ? That
would be your internet modem ofcourse. :-)

Though that /side effect/ can be had (not a proxies purpose,
so it could still 'leak' your IP).

Psiphon is definitely not perfect.

No, the side effect of the proxying server (the remote one you send all your data to). the Psiphon is written for VPN usage, and I expect it to be
running a bit tighter ship than a simple proxying server.

But yes, you might also consider that. Other VPN solutions have been know
to leak /whole connections/ (often DNS) outof the local 'puter, because the local redirector software (what you call a proxy) didn't (know it needed to) redirect that one too.

Than again, thats often a choice : use your own, locally configured DNS, or
the one thats configured on the remote VPN server. Both have pros and
contras.

There's a trick that I don't fully understand so I hope others
can flesh it out, but Psiphon and VPN "look different" to the
ISP & to the web site.

Thats easy: They do not wrap the connection in the standard (and thus easily recognised) "tunneling" layer*, but make it look as if its some other connection. Ofen a normal HTTPS one (which is already encrypted and quite opaque to whats inside of it).

* https://en.wikipedia.org/wiki/Tunneling_protocol

To answer your question, let's go slowly here as the order
matters (VPN first Psiphon second versus Psphon first VPN
second)

Psiphon *is* your VPN. You need both the Psiphon' VPN server and the Psiphon executable. There is no "first" or "second" about it.

every app respects proxy mattes too, as does the fact that
proxies are faster than VPN as does the fact that proxies
look different to snoopers than VPN, etc.,

See? I told you it's complicated.

As you might have noticed, It doesn't sound all that complicated to me.

But I have no idea what the reason would be why a VPN would technically be slower than a proxy. As earlier mentioned, what you call a VPN functions as
a pass-thru proxy.

So far you're the only one on this newsgroup who even seems to
understand it,

Not quite. I'm just pretty-much the only one who still thinks it might be worth my effort/time to talk to you.

where I was hoping someone would tell ME how this darn thing works.

I can't remember you having mentionined what "this darn thing" is, or that
you wanted an explanation to how it works ...

... which is probably why nobody has tried to do so. <whistle>

The result is no single party sees the full picture. ISP sees VPN.
VPN sees Psiphon. Psiphon sees destination. Destination sees Psiphon
exit IP.

It's not redundant. It's compartmentalization.

I'm sorry, but are you now telling me that you would need both a VPN *and* a Psiphon server to make your connection ? That doesn't make any sense, in
more ways than one.

Like who strips the tunneled-but-not-looking-like-a-tunnel layer off of the actual data ?
The VPN server you would connect to would not have any knowledge of it, and would just drop your connection as damaged/not ment for it.

Its much more likely that your local Psiphon.exe redirects your connection
to a Psiphon VPN server on this side of the "wall", which than tries to find
a way around/over/under that wall to a second Psiphon server on the other
side of that "wall", which than uses yet other servers (a kind of bot net)
to hide its actual IP.

Let's be clear that I never once mentioned DLLs. I didn't say WinINET
or WinHTTP *are* proxies.

Indeed, you didn't. You just mentioned both WinInet and WinHTTP in relation
to "each with its own proxy logic". They don't have anything of the kind.

I said they support proxy behavior.

No, they don't. That "behaviour" only occurs *much* lower.

Both those DLLs are high-level file-oriented ones, WinHTTP only dealing with (duh) HTTP connections, and WinInet also supporting some older protocols
like FTP and Gopher, as well as functions to deal with caching them.

WinInet also has got some functions with "proxy" in its name. They are
there to ask if there is a proxy available(!), and to apply a certain
ammount of configuration to it.

iow, not "3 completely different proxy mechanisms", but just a single one (outof the thre you initially mentioned) enabeling you to "do stuff" with a possibly(!) available proxy.

Someone could also format the data themselves and use ws2_32.dll to send it
and receive its answers.

My question was about how Windows handles proxy routing, not
about DLL internals.

You want to go the OSI 11 layer model (
https://en.wikipedia.org/wiki/OSI_model ) and where that the connections are wrapped into a "forwarding" layer and send to a preset IP ? You will like
that even less I'm afraid.

I only started using proxies a week ago so I'm hoping something (anyone!)
on this newsgroup knows them better than I do as they're not intuitive.

Instead of *how* it exactly-but-not-exactly works, try to concentrate on how you, if needed, can configure it.

Why do 3 completely different proxy mechanisms exist in Windows anyway?

You have still not named which ones. :-(

Regards,
Rudy Wieser

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: marionf@fact.com

That is, instead of connecting directly to a site, your request
goes through the proxy

Yep. But what was/is its intended purpose ?

A proxy is an intermediary between client and destination.

It can cache content, filter requests, mask the client IP, or bypass restrictions. Psiphon freeware can operate as a proxy, a VPN, or both.

What you are describing there is a VPN, with that Psiphon executable most likely to make configuring easier.

Psiphon freeware can be added on top of a system-wide VPN if desired. Then Psiphon freeware can function as a VPN or as an application-level proxy.

Psiphon freeware is limited though in that it can be one or the other.
Not both at the same time. That's just a quirk of that freeware though.

In VPN mode freeware encrypts and tunnels all traffic.
In proxy mode it handles selected traffic and may obfuscate it.

Than again, the above VPN is most always a simple forwarding service, not even allowing you access to the rest of the "VPN 'puter" you are conncting
to (its a misnomer, but a name one most users know. Like asperine).

Correct, commercial VPN services forward traffic without shell or file
access to the server. Nothing here adds access to someone else's 'puter.

And by the way: that (goes thru something which changes your IP) is what an internet modem/router does too. Yet, its not called a proxy ...

Routers perform NAT at lower layers.
A proxy operates at the application layer and can parse protocol data.

Same goes for your internet provider, or a search engine like DuckDuckGo
(and others). Those are not called proxies either.

Correct, they may relay traffic but are not user-configured intermediary proxies.

Mind you, although not mentioned, HTTP(S) proxies where meant to buffer requests for webpages...

Yes, HTTP proxies can cache content to reduce bandwidth and improve load
times for repeated requests.

My setup, for example, chains three levels (two of which are optional).
1. VPN (full tunnel)
2. Psiphon (proxy tunnel)
3. VPN browser (app-level tunnel)

I'm sorry, but #2 is meaningless to me. Whats the difference with #1 ?

#1 is a full-tunnel VPN encrypting all traffic. #2 is Psiphon in proxy
mode, routing selected traffic and often disguising it. Even more
miserable, in Windows, only some applications know how to use proxies.

For example, Mozilla browsers are great at using proxies, it turns out.
Sadly, Chromium browsers suck at using proxies. But the good news is some
have no problem using them (e.g., Brave) while others refuse (UC).

Go figure.

As for #1 and #3 ? That is most likely where the Psiphon executable comes into play...

Psiphon.exe freeware manages its own tunnel and can select which
applications or destinations use it. A browser VPN addon is app-scoped.

I don't think so. You can't have a "full tunnel" and at the same time a "app-level tunnel"...

Chaining is possible if the first tunnel allows the second to connect
through it. For example, most free public VPN servers are full tunnel.

With a full-tunnel VPN, Psiphon freeware (or another tunneling tool) can
run its own tunnel inside it without touching any extra settings because
the VPN client is already routing all outbound traffic through the VPN interface by default.

Let's speak carefully though as I'm chaining 3 different things in
different orders during testing so each situation can be different.
a. System-wide free no-registration public VPN servers
b. Browser-specific free no-registration public VPN extensions
c. The Psiphon no-registration freeware censorship circumvention tool

Your psiphon3 proxy is installed on your 'puter, and so it
still uses your 'puters IP. No IP hiding possible.

Indeed.

When Psiphon connects to a remote server, the destination sees the Psiphon
exit IP, not the local IP. The ISP still sees local IP unless another
tunnel is used first. If/when I chain tunnels, each sees only the prior.

Did you know that Windows has such a thing built-in...

A default gateway is part of IP routing, not a proxy.
It forwards packets without interpreting application-layer protocols.

No, the side effect of the proxying server...

VPN software can leak DNS or other traffic if not configured to route all protocols through the tunnel.

Than again, thats often a choice : use your own, locally configured DNS, or the one thats configured on the remote VPN server...

Agreed, local DNS can be faster, remote DNS keeps lookups inside the
tunnel. I recently posted a separate detailed tutorial on setting that up.

There's a trick that I don't fully understand...

Some tools disguise tunnel traffic to look like ordinary HTTPS or other
allowed protocols to avoid detection.

Psiphon *is* your VPN...

Psiphon can be the only tunnel or be chained with another VPN. In a chain
there is a first and a second, defined by which outer path the inner uses.

every app respects proxy matters too...

Some apps ignore system proxy settings. Proxies can be faster when they
avoid encryption, but performance depends on routing and load.

But I have no idea what the reason would be why a VPN would technically be slower than a proxy...

Encryption and encapsulation add overhead. Server distance and routing also affect speed. Sometimes just paying for the tools increases the speed.

The result is no single party sees the full picture...

Compartmentalization works if tunnels are chained correctly, though
metadata can still correlate flows.

It's not redundant. It's compartmentalization.

Understood.

I'm sorry, but are you now telling me that you would need both a VPN *and* a Psiphon server...

You do not need both. You can use only Psiphon, only a VPN, or chain them. Chaining adds complexity and latency. That's why I'm testing for the team.

It takes hundreds of hours to get where I've gotten to today, but with just
one tutorial, anyone can set up my setup in five minutes after I do that.

Like who strips the tunneled-but-not-looking-like-a-tunnel layer...

The endpoint that created the obfuscation removes it, then forwards plain tunneled data to the next hop.

Its much more likely that your local Psiphon.exe redirects your connection...

Psiphon uses an upstream infrastructure of servers and bridges to traverse filtering networks. Details vary by deployment.

Indeed, you didn't. You just mentioned both WinInet and WinHTTP...

They expose separate proxy configuration models for applications, but both
rely on the networking stack to connect to a proxy.

I said they support proxy behavior.

They support using a proxy by honoring configured settings and directing requests accordingly.

My question was about how Windows handles proxy routing...

Windows applies proxy settings from user, system, or auto config.
Applications using WinINet or WinHTTP can query and apply these settings.

Different APIs target different app types and contexts, but can point to
the same proxy address.

Why do 3 completely different proxy mechanisms exist in Windows anyway?

You have still not named which ones. :-(

Based on the information Andy kindly supplied I should have written the
query differently since Windows applications can discover proxy settings in three main ways.

Some use WinINet, which reads the per-user Internet Options settings from Control Panel or IE. Others use WinHTTP, which has its own per-service or machine-wide proxy configuration set with netsh or API calls. A third group bypasses both and uses the WinHTTP AutoProxy/WinINET PAC logic to fetch and parse a proxy auto-config (PAC) file or WPAD discovery, or implements its
own proxy handling entirely. Which method is used depends on how the application was written.

If I had known the answer was really about how Windows apps discover and
apply proxy settings, I could have made the subject line reflect that scope instead of implying three unrelated mechanisms. For example:
Re: How Windows apps use WinINet, WinHTTP, and auto-proxy to find settings

Or, with Andy's admonition in mind, this would have been shorter:
Re: How Windows apps determine proxy settings

Thanks for helping me better understand it's all about three discovery/configuration paths rather than three completely different mechanisms, which better matches the explanation we've ended up with.

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: marionf@fact.com

Andy Burns wrote:

Psiphon freeware can function as a VPN or as an application-level proxy.

I have to wonder, what's in it for them to let you consume their
bandwidth for free?

Hi Andy,

Good question.

Dumbshits just spout the aphorism that "if it's free, you are the product",
but truly intelligent people look to see what the product really does.

Why do I post tutorials that take hundreds of hours to write, for free.
Why did Irfan Skiljan publish Irfanview which we all use, for free.
Why did Linus Torvalds allow his Linux kernel to be available, for free.

Some people, maybe one out of ten million or so, are kind hearted.
They're not in it for the money.

Similarly kind-hearted people come to mind such as Richard Stallman (GNU), Guido van Rossum (Python) and Daniel Stenberg (curl) - but let's first dig
up the history of Psiphon before canonizing Psiphon's creators. :)

Apparently Psiphon began in 2006 as a project by the Citizen Lab at the University of Toronto, a research group focused on digital rights and
global internet freedom. From what I just read, the original idea was to
help people in heavily censored countries access the open internet by
creating a simple, trust-based proxy system
<https://en.wikipedia.org/wiki/Psiphon>

In 2007, Psiphon Inc. was spun off as an independent company based in
Ontario, Canada, where the software is still free and open-source.
<https://psiphon.ca/en/about.html>

For profit, they do offer paid speed boosts and, confusingly, the freeware can't do the VPN/proxy at the same time (it can do one, or the other).

Like me, they donate their time and energy simply to help others.
It's noble. Only those with good hearts do it though. Which is one in ten million or so. Like me! :)

BTW, I humbly submit my candidacy for canonization for my tutorials. :)
Some saints wear sandals & robes but some wear slippers and type at 2am.

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: mikes@is.invalid

On 14/09/2025 19:05, Marion wrote:

Why do I post tutorials that take hundreds of hours to write, for free.

.
.
.

Like me, they donate their time and energy simply to help others.
It's noble. Only those with good hearts do it though. Which is one in ten million or so. Like me! :)
I humbly submit my alternative diagnosis of your condition.

You have a gigantic ego and want others to marvel at your self-professed brilliance.

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: marionf@fact.com

MikeS wrote:

Like me, they donate their time and energy simply to help others.
It's noble. Only those with good hearts do it though. Which is one in ten
million or so. Like me! :)
I humbly submit my alternative diagnosis of your condition.

You have a gigantic ego and want others to marvel at your self-professed brilliance.

You're wrong but you're welcome to your opinion of my tutorials after you
show me all the free tutorials you've contributed to this newsgroup, Mike.

Only one in millions is as purposefully helpful as I am by writing them.
You're not in that group of intelligent kind-hearted people, Mike.

Sorry.

And, besides, it was a joke. Andy understood.

I contribute more to some ngs than thousands of people like you who have
never been able to add even so much as an iota of value in your whole life.

But again, it was a joke for Andy.
He understood, I'm sure.

Since you've never added any value in your life, you jumped in to insult. Everything you've ever posted, Mike, subtracts value.

But then again, it was a joke.

So I'm just forestalling all the other trolls like you who lack any value,
and, if they left Usenet, the value of Usenet would go up the day they do.

Please do not respond unless you can add value to the technical topic.] Otherwise, you cause me to respond to you wasting my time & everyone else.

Stop being a worthless troll, Mike.
Add on-topic technical value for once in your life.
--
People like Mike upset me because they've been told they're stupid their
entire lives, so here they get a chance to throw insults at smart people.

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: address@is.invalid

Arlen,

A proxy is an intermediary between client and destination.

True.

And I've mentioned few which are intermediaries between the client and its destination which are not called proxies. iow, its not that clear-cut.

It can cache content, filter requests, mask the client IP,

Thats what a proxy can *do* ...

or bypass restrictions.

... and thats an *effect* of remote proxies.

Psiphon freeware can operate as a proxy, a VPN, or both

Again, what is the difference between a proxy and a VPN ?

Isn't a VPN server per definition a proxy, and needs some local proxy
software to re-direct the network traffic to the VPN server ?

If-and-when you want precise answers than making clear what exactly you are talking about is rather important. *Especially* for a word like "proxy",
which has a number of different applications within the computer realm.

In VPN mode freeware encrypts and tunnels all traffic.
In proxy mode it handles selected traffic and may obfuscate it.

:-) *Both* will need to tunnel the trafic. Also, if the VPN connection
just uses a standard tunnel (no obsfucation of it) than it might not even
pass the great firewall of china ...

iow, to me you have two descriptions with a zero effective difference.

And by the way: that (goes thru something which changes your IP) is what
an internet modem/router does too. Yet, its not called a proxy ...

Routers perform NAT at lower layers.
A proxy operates at the application layer and can parse protocol data.

And those differences matter to an internet modem being a defacto proxy too
... how ?

Same goes for your internet provider, or a search engine like
DuckDuckGo (and others). Those are not called proxies either.

Correct, they may relay traffic but are not user-configured
intermediary proxies.

The subject was proxies, not if they can be configured (or not). Besides,
you certainly can't configure the remote, "VPN server" proxy. What internet traffic from you goes in there goes out there too.

Also, to be pedantic about it, "intermediary proxies" is saying the same
thing twice. Just try to think of a proxy which /isn't/ an intermediary
too.

Yes, HTTP proxies can cache content to reduce bandwidth and improve
load times for repeated requests.

And that is what proxies origionaly where ment to do. Its current usage ? Thats abusal of them. :-)

But I mentioned it to show you that a "proxy" (in computer land) has got different meanings/usages. Being precise about which one you are talking about helps your audience, me, to understand what you *are* talking about.

I'm sorry, but #2 is meaningless to me. Whats the difference with #1 ?

#1 is a full-tunnel VPN encrypting all traffic. #2 is Psiphon
in proxy mode, routing selected traffic and often disguising it.

As I already mentioned, your distinction between #1 and #2 is meaningless to me.

Even more miserable, in Windows, only some applications know how to use proxies.

Windows only considers caching proxies *for certain protocols*, like HTTP.
If you want to (ab)use such caching proxy mechanisms to do something else
than you are on your own.

I don't think so. You can't have a "full tunnel" and at the same time
a "app-level tunnel"...

Chaining is possible if the first tunnel allows the second to connect
through it.

You can do that ofcourse, but it would normally be rather counter-productive
: if the server doesn't know your actual connection is encapsulated twice it would tunnel the still tunneled inner connection and send it onn - with the than receiving server having the same problem.

With a full-tunnel VPN, Psiphon freeware (or another tunneling tool)
can run its own tunnel inside it

Inside of *what* please ? The Psiphon executable is the one creating the tunnel and deciding what goes thru it. There is no reason or need for a
double tunnel.

without touching any extra settings because the VPN client

The Psiphon executable *IS* the VPN client.

Let's speak carefully though as I'm chaining 3 different things
in different orders during testing

No. Not until its clear what (you think) you are doing. And not as long as
you make a distinction between a "VPN client" and what the Psiphon
executable is supposed to do.

To put it bluntly: you are still confused about what is doing what / is supposed to be doing what. Continuing from such a point is doomed to fail.

When Psiphon connects to a remote server, the destination sees the
Psiphon exit IP, not the local IP.

And again you add to the confusion. :-( What is "a local IP" ? The IP of
the 'puter ? Or perhaps the internet-facing side IP of the internet modem
? Something else ?

And you are mixing up the "remote server" (the VPN server?) and "the destination" (the actual target before the connection was VPN-ed ?), while talking about a single IP. Can you say confusing ? I can. :-(

The Psiphon executable *does not have* an IP. The packets send by it go to
the "default gateway", carrying the IP of the 'puter the Psiphon executable
is running on. After that the packets get the IP of (the internet-facing
side of) the internet modem due to NAT-ing). Just like it happens for any other app on the local 'puter(s).

The only thing different is that the Psiphon executable will have the
/actual/ connection(s) burried inside (tunneled) inside its own one.

That remote (VPN) server will than strip the tunnel off, make another change
to the IP due to NAT-ing, and send it he packet off to its actual intended target (thats the short version).

The ISP still sees local IP unless another tunnel is used first.

:-) And how do you think you will get another tunnel applied between you
and your ISP ? Your ISP is your gateway to the internet. Everything has
to go thru it before you can reach another server.

And no, having the Psiphon executable stacking tunnels doesn't work.

If/when I chain tunnels, each sees only the prior.

Correct. But you can only do that *after* your ISP, not before.

VPN software can leak DNS or other traffic if not configured to
route all protocols through the tunnel.

Indeed. And yet your Psiphon offers app-level VPN ...

A default gateway is part of IP routing, not a proxy.

What was your own definition of a proxy again ? Something with re-routing connections elsewhere ?

But if you think so, than I do not consider that Psiphon executable a proxy either, but just a redirector - the same as what the "default gateway" does.

It forwards packets without interpreting application-layer protocols.

Yes, and ?

You have mentioned "interpreting application-layer protocols" and similar a
few times now, but have not provided any reason to why that the VPN client software (your Psiphon executable) would need to do it. I don't see a
reason.

And you know what I think about (your) unsupported claims ...

There's a trick that I don't fully understand...

That is not something I said. Your indentation whent on the fritz there,
even causing you to answer to yourself

The result is no single party sees the full picture...

Compartmentalization works if tunnels are chained correctly, though
metadata can still correlate flows.

It's not redundant. It's compartmentalization.

Understood.

Continuing from something I said :

I'm sorry, but are you now telling me that you would need both
a VPN *and* a Psiphon server...

You do not need both. You can use only Psiphon, only a VPN, or
chain them.

*Ofcourse* you can chain VPN servers (as long as you use a tunneling
protocol *both* know - which might be a problem when the data is tunneled
thru a non-tunnel protocol.

The point is that saying "only Psiphon, only a VPN," is ... nonsense.
Psiphon *IS* a VPN. Does it matter which VPN you use as long as it does
its job ? Not at all.

Like who strips the tunneled-but-not-looking-like-a-tunnel layer...

The endpoint that created the obfuscation removes it, then forwards
plain tunneled data to the next hop.

Lol ? If the endpoint created the obsfucation and also removes it
(suggesting thet the endpoint both sends and receivesz it), why send it in
the first place ?

In all other cases, the endpoint must know what kind of tunneled-but-not-looking-like-a-tunnel layer is used by the startpoint. And that doesn't quite seem to work between VPN servers of different companies.

Indeed, you didn't. You just mentioned both WinInet and WinHTTP...

They expose separate proxy configuration models for applications,
but both rely on the networking stack to connect to a proxy.

I think I already mentioned that WinHTTP has no proxy related material in
its api. If you do not agree - and your "they" does seem to indicate so -
than do provide why.

But yes, that is all wininet does. IF THERE IS ALREADY A PROXY INSTALLED
than you can use those functions to find, and configure it - as long as the proxy is compatible ofcourse (read: one of the caching proxies).

AGAIN : wininet does *not* have any proxying functionality.

And newsflash : your Psiphon VPN client software (with its own configuration panel) is not such a proxy. IOW, you can forget about using those wininet functions.

I said they support proxy behavior.

No, you didn't. Don't lie to me. What you *said* was "each with its own
proxy logic". And yes, thats quoted from your initial post.

There is no "proxying logic" involved with detecting an installed proxy or shoving a few settings into it.

Also, wrongly indented.

My question was about how Windows handles proxy routing...

Thats your second lie in a row. I don't think I have to quote the
subjectline or the first line of your first post here, do I ? Bad show
Arlen, bad show.

Why do 3 completely different proxy mechanisms exist in Windows anyway?

You have still not named which ones. :-(

Based on the information Andy kindly supplied I should have written the
query differently since Windows applications can discover proxy settings
in
three main ways.

"Discovering proxy settings" is something quite different from "proxy mechanisms"

Or, with Andy's admonition in mind, this would have been shorter:
Re: How Windows apps determine proxy settings

I've tried to explain to you (and provided a link to a webpage explaining
them) that there are quite number of different kinds of proxies, and even definitions to what proxies are. As such that rather unspecific question
would be unanswerable.

Also : those discovery methods are not applicable to the kind of proxy you
are thinking of (regardless of if you mean the VPN client software or the
VPN server).

But, please do /not/ believe me and try it yourself. :-)

Regards,
Rudy Wieser

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: marionf@fact.com

Again, what is the difference between a proxy and a VPN ?

A proxy forwards specific application traffic, often without encrypting it,
and can be set per app or per protocol. A VPN encrypts and routes all
network traffic from the device through a secure tunnel at the OS level. Psiphon freeware can operate in either mode depending on configuration.

Isn't a VPN server per definition a proxy, and needs some local proxy software to re-direct the network traffic to the VPN server ?

A VPN server is not generally called a proxy because it operates at a lower network layer and handles all traffic, not just application data. On
Windows, the VPN client software itself handles redirecting traffic into
the tunnel, so no separate local proxy is required.

:-) *Both* will need to tunnel the trafic. Also, if the VPN connection
just uses a standard tunnel (no obsfucation of it) than it might not even pass the great firewall of china ...

A standard VPN tunnel may be blocked by deep packet inspection. Psiphon freeware in proxy mode uses a series of censorship-aware obfuscation
techniques to disguise traffic patterns, which can help bypass such
filtering.

And those differences matter to an internet modem being a defacto proxy too ... how ?

A modem or router performing NAT does not parse or modify application data,
so it is not considered an application-layer proxy. Proxies generally
inspect, filter, or cache content, which NAT devices typically do not do.

The subject was proxies, not if they can be configured (or not). Besides,
you certainly can't configure the remote, "VPN server" proxy. What internet traffic from you goes in there goes out there too.

The distinction is that a user-configured proxy is intentionally set up on
the client to handle certain traffic, while a VPN server is configured to
route all traffic from the client through its tunnel. You cannot change the
VPN server's own routing rules, but you can choose what traffic enters the
VPN tunnel.

Windows only considers caching proxies *for certain protocols*, like HTTP.
If you want to (ab)use such caching proxy mechanisms to do something else than you are on your own.

Windows supports different proxy types depending on the protocol. HTTP and HTTPS can use system-configured proxies, while SOCKS proxies often require application-level support. Psiphon freeware can run as a local SOCKS or
HTTP proxy so that compatible apps can route through it.

Inside of *what* please ? The Psiphon executable is the one creating the tunnel and deciding what goes thru it. There is no reason or need for a double tunnel.

If Psiphon freeware is run inside an already connected full-tunnel VPN, the outer VPN client handles the first layer of encryption and routing. Psiphon freeware then creates its own tunnel within that connection, which can be useful for adding obfuscation or routing only certain traffic differently.

The Psiphon executable *IS* the VPN client.

Psiphon freeware acts as the VPN client when in VPN mode, but in proxy mode
it functions as a local proxy server for supported applications. The same freeware executable can perform either role depending on settings.

I'm mainly using Psiphon freeware as an application-specific proxy due to
it being blazingly fast compared to the thousands of free public
system-wide VPN servers that I also use with it in layers of obfuscation.

In addition to my testing of Psiphon freeware, I'm also testing it along
with app proxifiers such as FreeCap, ShadowSocks, SocksCap64, Proxifier, ProxyCap, SocksEscort and WideCap, but those proxifiers come after the
Psiphon freeware is already working, so they're not the topic of this
thread.

No. Not until its clear what (you think) you are doing. And not as long as you make a distinction between a "VPN client" and what the Psiphon
executable is supposed to do.

Psiphon freeware is a single executable that can act as a VPN client or as
a local proxy depending on mode. In VPN mode it integrates with the Windows networking stack to route all traffic. In proxy mode it listens locally and only handles traffic from applications configured to use it. There are limitations in the VPN functionality in the freeware, but since I'm not
using the VPN, those limitations don't matter for my purposes.

And again you add to the confusion. :-( What is "a local IP" ? The IP of the 'puter ? Or perhaps the internet-facing side IP of the internet modem
? Something else ?

By local IP I mean the IP assigned to the client device on its LAN.
The internet-facing IP is assigned to the modem or router by the ISP.

When Psiphon freeware connects, the destination sees the Psiphon freeware server's IP instead of either of those.

In addition, if a system-wide VPN is used, depending on when it is started
in the sequence, Psiphon may only see the system-wide VPN IP address, or,
my own IP address.

Likewise, depending on when the system-wide VPN is started, the destination domain only sees either the Psiphon IP address or the VPN server IP
address. It's in my control.

:-) And how do you think you will get another tunnel applied between you
and your ISP ? Your ISP is your gateway to the internet. Everything has to go thru it before you can reach another server.

The first hop is always through the ISP, but you can establish an encrypted tunnel from your device to a remote server over that link. Once that tunnel
is up, you can create a second tunnel inside it to another endpoint.

Indeed. And yet your Psiphon offers app-level VPN ...

Psiphon freeware in VPN mode routes all traffic through a virtual network adapter at the OS level. In proxy mode it only handles traffic from applications configured to use its local proxy service. That is why it can
be described as app-level in one mode and full-tunnel in another.

Again I must stress I'm using the Psiphon freeware only in proxy mode
because I have thousands of free system-wide public VPN servers already.

Adding one more free public VPN server won't be worth the trouble.

What was your own definition of a proxy again ? Something with re-routing connections elsewhere ?

A proxy accepts client connections and forwards them to another server,
often interpreting or modifying application-layer data. This is different
from a default gateway, which forwards packets at the network layer without interpreting the application protocol.

Yes, and ?

In proxy mode Psiphon freeware must understand the protocol it is proxying, such as HTTP, to correctly relay requests and responses. In VPN mode it
does not parse application data because it operates at a lower layer.

*Of course* you can chain VPN servers (as long as you use a tunneling protocol *both* know - which might be a problem when the data is tunneled thru a non-tunnel protocol.

Psiphon freeware can be used alone or chained with another VPN.
When chained, the outer tunnel carries the inner tunnel's traffic.

This can add obfuscation or route specific traffic differently.

Lol ? If the endpoint created the obsfucation and also removes it (suggesting thet the endpoint both sends and receivesz it), why send it in the first place ?

Obfuscation is applied so that intermediate network devices cannot easily identify or block the tunnel. The endpoint removes it so the next hop
receives standard tunneled data.

I think I already mentioned that WinHTTP has no proxy related material in
its api. If you do not agree - and your "they" does seem to indicate so - than do provide why.

WinHTTP includes functions to set and query proxy settings for applications that use it, but it does not perform proxying itself. WinInet likewise can
be configured to use a proxy but does not implement the proxy server.

"Discovering proxy settings" is something quite different from "proxy mechanisms"

In Windows, the three main discovery methods are manual configuration, automatic configuration via PAC or WPAD, and system policy settings. These
are ways applications learn proxy details, not different proxy server
types. That misunderstanding was a mistake for which I openly apologize.

[REDACTED]

You can't get a hint. I removed your doxying each time because I consider
it extremely rude of you to willfully dox people who care about privacy.

You are a classic abuser.

This is your last notice that if you start a response by doxying me, I will consider that to be a clear indication you desire no further response.

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: address@is.invalid

Arlen,

Again, what is the difference between a proxy and a VPN ?

A proxy forwards specific application traffic, often without encrypting
it, and can be set per app or per protocol. A VPN encrypts and routes
all network traffic from the device through a secure tunnel at the OS
level.

Nope, thats not it I'm afraid.

A proxy doesn't need to know *anything* about the app causing a connection
to come in. Its just sees that connection, nothing more. Just like the
VPN server does.

(Than again, you are *again* confusing the matter by talking about the local vpn-client software as being the VPN. Bad show arlen, bad show.)

And encryption or not is not a distinguishing feature. Though nowerdays it would not be a good idea *for either* /not/ to use an SSL connection (iow, encryption is not a feature of the VPN or proxy, but of the used connection
to the remote server).

As for "A VPN ... routes all network traffic" ? You already mentioned that app-level proxying is possible, so thats it either.

And did I already mention the "default gateway" and how it causes all
network traffic to be send to a specific (local) proxying server - the
internet modem ?

And as I already tried to explain, a "VPN server" isn't a doesn't actually
do VPN. Instead it just functions as a relaying proxy.


To repeat myself, your distinction between a VPN and a proxy is rather artificial (made up). /At best/ you could say VPN is a proxy with a
specific goal : to hide your (internet modems) IP. Thats all.

That some VPN solutions can be configured to catch all, or just a subset of
all network traffic is a feature of a specific implementation of a certain
VPN client software.

A VPN server is not generally called a proxy because it operates
at a lower network layer and handles all traffic, not just
application data.

:-) You are *really* trying to confuse everything, are you ? A (remote)
*VPN server* which is located in my local 'puter ? How does that even work
?

And no, at which "dept" the local VPN/proxy client is functioning doesn't matter in the slightest. iow, another artificial distinction.

A standard VPN tunnel may be blocked by deep packet inspection.

:-) You do not need "deep packet inspection" to detect a standard tunnel.

you would need it to detect an obsfucated tunnel (hiding connections in a well-known protocol like HTTP) though.

A modem or router performing NAT does not parse or modify application
data,

And neither does a VPN server. All its does is stripping the incoming packaging layers and apply its own.

The distinction is that a user-configured proxy is intentionally set up on the client to handle certain traffic, while a VPN server is configured to route all traffic from the client through its tunnel.

You already tried to define it as such, and I told you you do not even play
by your own rules : remember app-specific VPN-ing ?

And you *could* VPN a specific protocol, like HTTP. As long as you use the browser to try to get at certain data that you cannot get at because of restrictions that would be pretty-much all you would need.

So no, there is no rule that a VPN has to take *all* network, or even just
all internet traffic.

Inside of *what* please ? The Psiphon executable is the one creating
the
tunnel and deciding what goes thru it. There is no reason or need for a
double tunnel.

If Psiphon freeware is run inside an already connected full-tunnel VPN,
the outer VPN client handles the first layer of encryption and routing. Psiphon freeware then creates its own tunnel within that connection,
which can be useful for adding obfuscation or routing only certain
traffic differently.

Yep, you are suggesting to have *two* VPN clients running on your machine.
Good luck with trying to get both to behave, and not fight each other. Mind you, *both* are trying to grab the internet traffic - unless you use a
special VPN client which doesn't grab anything, but just handles whatever
you send to it (a classic caching proxy behaviour).

Psiphon freeware is a single executable that can act as a VPN client or
as a local proxy depending on mode. In VPN mode it integrates with the Windows networking stack to route all traffic. In proxy mode it listens locally and only handles traffic from applications configured to use it.

Ah yes, that makes more sense. But do I now have to understand that its "app-mode" VPN-ing is fully dependant on if the app supports a proxy ?
Thats a let-down. :-|

[REDACTED]

You can't get a hint. I removed your doxying each time because I
consider it extremely rude of you to willfully dox people who care
about privacy.

As you have [REDACTED] what I said I can't be sure what you are complaining about there. On purpose ?

But if it was about me calling you a liar, than you can't take a hint
yourself. I consider it *very* rude when you try to claim you said
something different than what you did. Same for trying to claim I said something I never did.

As for me doxing you ? Are you trying to re-define what doxing means (gaslighting me) ? I suggest you take a look here : https://en.wikipedia.org/wiki/Doxing

You are a classic abuser.

Ofcourse I am. By pointing out *and* showing you how you lied to me.
Twice.

Kiddo, if I would have wanted to abuse you I would not have tried to give
you hints, pointers and other information to your current subject. And certainly would not have put some effort into finding some informational webpages to your subject. And would not have tried to make you understand
that using ambigue naming is confusing and as such counter-productive.
Somehow you never got that hint either.

This is your last notice that if you start a response by doxying me,
I will consider that to be a clear indication you desire no further
response.

Prove to me that I tried to dox you - quoting where I did will do just
fine - and I'll accept your reason. You won't though, as, as always when
you try to sling mud to me, it doesn't exist.

No kiddo, you are just running away from someone who doesn't accept the shennigans you are trying to pull.

But alright, I'll leave you to yourself. Enjoy the information I gave you.

Regards,
Rudy Wieser

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: MikeS@fred.com

On 14/09/2025 20:51, Marion wrote:

MikeS wrote:

Like me, they donate their time and energy simply to help others.
It's noble. Only those with good hearts do it though. Which is one in ten >>> million or so. Like me! :)
I humbly submit my alternative diagnosis of your condition.

You have a gigantic ego and want others to marvel at your self-professed
brilliance.

You're wrong but you're welcome to your opinion of my tutorials after you show me all the free tutorials you've contributed to this newsgroup, Mike.

Only one in millions is as purposefully helpful as I am by writing them. You're not in that group of intelligent kind-hearted people, Mike.

Sorry.

And, besides, it was a joke. Andy understood.

I contribute more to some ngs than thousands of people like you who have never been able to add even so much as an iota of value in your whole life.

But again, it was a joke for Andy.
He understood, I'm sure.

Since you've never added any value in your life, you jumped in to insult. Everything you've ever posted, Mike, subtracts value.

But then again, it was a joke.

So I'm just forestalling all the other trolls like you who lack any value, and, if they left Usenet, the value of Usenet would go up the day they do.

Please do not respond unless you can add value to the technical topic.] Otherwise, you cause me to respond to you wasting my time & everyone else.

Stop being a worthless troll, Mike.
Add on-topic technical value for once in your life.

Should have mentioned you are also afflicted with verbal diarrhoea.

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: marionf@fact.com

MikeS wrote:

Should have mentioned

I must agree with your premise that proxy configuration on Windows is far
too complex for something like 9,999 out of every 10,000 people on this ng.

But if you still want to control how your IP appears to websites and
services, understanding the basics of Windows proxy stacks is essential.

What matters most to efficient proxy use on Windows is knowing that WinINet
and WinHTTP are separate networking stacks that handle proxy settings for different types of applications. You need to know PAC files provide dynamic proxy logic using JavaScript and WPAD is a protocol that helps clients automatically discover PAC files on a network using DNS or DHCP.

That's how you control apps like Internet Explorer, Microsoft Office and
many legacy desktop applications which use the WinINet stack to handle web requests & proxy settings. Then you want to control system services & background applications like Windows Update, Office activation and some enterprise software which use the WinHTTP stack to handle HTTP requests in
a non-interactive service-friendly way.

As part of your control, PAC files let you define rules like "use proxy X
for domain Y but connect directly for domain Z." In fact, just yesterday I served my PAC file using Mongoose, a lightweight portable web server in addition to using that PAC file directly to set the Windows registry keys.

By doing that I made the PAC file accessible over HTTP, which allowed
Windows clients to fetch it automatically and apply my custom proxy logic.

And here's the key point which many people don't seem to realize, least of
all me until I delved into making my own DIY privacy browser for Windows.

Proxies act as intermediaries, so when your traffic is routed through one,
the destination site sees the proxy's IP address instead of yours. That's
how proxies help mask your identity, bypass geo-blocks or route traffic
through specific networks. It's like having a fresh stash of IP addresses!

In summary, to further flesh out your existing knowledge about proxy
stacks, Windows uses multiple proxy mechanisms depending on the type of application, and understanding which stack an app uses along with how PAC
and WPAD fit into the picture is key to controlling how your traffic flows
and what IP address the outside world sees.

Hope this helps... let the rest of us know where you can add further value.

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: marionf@fact.com

Marion wrote:

Here's the proxy.pac file that I set up but I'm not sure if it works yet.

Hi Andy,

Thanks partly to your suggestion of making use of WPAD and PAC, that
proxy.pac script I wrote has been working nicely for about a week now.

Windows has a built-in system for proxy settings, but it's mostly designed
for HTTP/HTTPS proxies, and not for SOCKS5 proxies, but it's still useful.
Win+I > Settings > Network & Internet > Proxy
(This is only for HTTP/HTTPS proxies via the WinINet API.)
1. Automatic Proxy setup
Automatically detect settings = on
Use setup script = on
Script address: http://127.0.0.1/proxy.pac
(Needs a server to serve it, such as mongoose.)

I see different proxy setups depending on whether psiphon is running.

When Psiphon is NOT running...
2. Manual proxy setup
Use a proxy server = on
Address = http://localhost
Port = 1080
Use the proxy server except for addresses that start with the
following entries. Use semicolons (;) to separate entries.
localhost;127.*;10.*;172.16.*;172.17.*;172.18.*;172.19.*;172.20.*;172.21.*;172.22.*;172.23.*;172.24.*;172.25.*;172.26.*;172.27.*;172.28.*;172.29.*;172.30.*;172.31.*;192.168.*
[x]Don't use the proxy server for local (intranet) addresses.

When Psiphon is running...
2. Manual proxy setup
Use a proxy server = on
Address = http=127.0.0.1:8257;https=127.0.0.1:8257;socks=127.0.0.1:1080
Port = <blank>
Use the proxy server except for addresses that start with the
following entries. Use semicolons (;) to separate entries.
10.*;172.16.*;172.17.*;172.18.*;172.19.*;172.20.*;172.21.*;172.22.*;172.23.*;172.24.*;172.25.*;172.26.*;172.27.
[x]Don't use the proxy server for local (intranet) addresses.

WinINET is PAC-aware and SOCKS-capable.
But WinHTTP ignores PAC files & cannot use SOCKS proxies directly.
PAC logic does not transfer to WinHTTP unless you play tricks.

Win+R > control > Internet Options > Connections > LAN Settings
Automatic configuration
[x]Automatically detect settings
[x]Use automatic configuration script
Address http://127.0.0.1/proxy.pac
Proxy server
[x]Use a proxy server for your LAN
[x]Bypass proxy server for local addresses

Just yesterday I tested out 4 freeware HTTP engines for serving PAC files, including caddy, miniweb, mongoose and python, and I settled on mongoose.
It was lightweight, easy to run, and did exactly what I needed without
extra setup.

By serving the PAC file over HTTP using mongoose, I was able to make the Pac-file logic accessible to both WinINet and WinHTTP stacks on Windows.

That works because WinINet, which is used by apps like Internet Explorer
and Microsoft Office, automatically detects PAC files if WPAD is enabled or
if the PAC URL is set in the system proxy settings. But WinHTTP, which is
used by background services like Windows Update and Office activation, can
also use PAC files but only if the PAC URL is manually configured using the netsh command <netsh winhttp set proxy source=ie>.

However, after experimenting, I used this syntax, which is more advanced.
netsh winhttp set advproxy setting-scope=machine settings={"AutoconfigUrl":"http://127.0.0.1/proxy.pac","AutoDetect":false}

In my case, once the PAC file was served by mongoose and the system was
pointed to it, WinINet-based apps started using the proxy rules I defined without any extra work. For WinHTTP, I used the command line to set the
proxy settings so that services relying on it would also follow the PAC
logic.

This setup lets me control which domains go through Psiphon and which ones connect directly, all without needing a full VPN tunnel. The PAC file acts
like a traffic filter, and by serving it locally with Mongoose, I get full control over how Windows apps and services handle proxy routing.

Every day I add something to my proxy privacy configuration, where just yesterday, with mongoose, I added that setup which allows background
services and system-level apps that use WinHTTP to follow the same proxy
logic defined in my PAC file.

If you're interested, here is my launcher for the freeware Mongoose server.

' ============================================
' launchmongoose.vbs 20250916 version 1.0
' This is version 1.5
' ============================================
' Version History:
' 1.0 - 20250916 Initial silent launch
' 1.1 - 20250916 Added process check and logging
' 1.2 - 20250916 Fixed duplicate End If error
' 1.3 - 20250916 Added version header block, cleaned structure
' 1.4 - 20250916 Removed unconditional launch; now launches only if not running
' 1.5 - 20250916 Updated launch command to explicitly set working directory
' ============================================
' Serves C:\data\sys\batch\proxy.pac as http & https
' Launch using: cscript //nologo launchmongoose.vbs
' Test using: curl http://127.0.0.1/proxy.pac
' Testing using: type mongoose.log
' Or just use: tasklist /fi "imagename eq mongoose.exe"
' Kill using: taskkill /f /im mongoose.exe
' Test this script: cscript //nologo "C:\data\sys\batch\launchmongoose.vbs"
' ============================================

Set WshShell = CreateObject("WScript.Shell")

' ==============================
' Added in version 1.1
' ==============================
' Features:
' - Skips launch if mongoose.exe is already running
' - Logs launch attempts to mongoose.log
' ==============================
' Fixed in version 1.2
' ==============================
' got rid of errors
' ==============================
' Improved in version 1.4
' ==============================
' Removed unconditional launch from version 1.0
' ==============================
' Improved in version 1.5
' ==============================
' Due to error: PAC file not available.
' Added explicit path to Mongoose launch
' WshShell.Run """C:\data\sys\batch\mongoose.exe"" -l http://127.0.0.1:80 -d C:\data\sys\batch", 0, False
' This ensures proxy.pac is served correctly regardless of current working directory

Set execCheck = WshShell.Exec("cmd /c tasklist /fi ""imagename eq mongoose.exe"" | find /i ""mongoose.exe""")
If execCheck.StdOut.ReadAll = "" Then
' Mongoose is not running ¡X launch silently
WshShell.Run """C:\data\sys\batch\mongoose.exe"" -l http://127.0.0.1:80 -d C:\data\sys\batch", 0, False

' Log the launch
WshShell.Run """cmd.exe"" /c echo [" & Date & " " & Time & "] Mongoose launched >> C:\data\sys\batch\mongoose.log", 0, False
Else
' Mongoose is already running ¡X skip launch
WshShell.Run """cmd.exe"" /c echo [" & Date & " " & Time & "] Mongoose already running >> C:\data\sys\batch\mongoose.log", 0, False
End If
--

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)

XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows
From: marionf@fact.com

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¢s 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
--

--- SoupGate-Linux v1.05
* Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)