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

Groups > alt.comp.os.windows-10 > #187369 > unrolled thread

Why do 3 completely different proxy mechanisms exist in Windows?

Back to article view | Back to alt.comp.os.windows-10

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 1 of 2  [1] 2  Next page →

#187369 — Why do 3 completely different proxy mechanisms exist in Windows?

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.

[toc] | [next] | [standalone]

#187374

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

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

#187375

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

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

#187382

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

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

#187407

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.

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

#187408

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

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

#187414

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?

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

#187416

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

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

#187421

>> 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.

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

#187424

Marion 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?

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

#187431

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.

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

#187439

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.

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

#187445

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.

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

#187463

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.

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

#187505

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.

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

#187454

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

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

#187460

> 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.

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

#187462

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

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

#187507

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 — 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 — skip launch
  WshShell.Run """cmd.exe"" /c echo [" & Date & " " & Time & "] Mongoose already running >> C:\data\sys\batch\mongoose.log", 0, False
End If
-- 

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

#187409

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

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | alt.comp.os.windows-10

csiph-web