From Newsgroup: alt.msdos.batch

UPDATE

Q: How would Microsoft Windows Update know my IP address?
A: It can't. It only sees the proxy. Or VPN. But not my real IP address.

Whew! Good news.
Windows Update was NOT seeing my real IP as tested thoroughly
in multiple ways in the attached script that I wrote today.

Using the existing psiphon.bat starter, the Windows Update Service
(wuauserv) was is always flowing through the proxy service.

This is how to tell if Windows Update is CONFIGURED to use the proxy.

Win+R > cmd {ctrl+shft+rtn}

netsh winhttp show proxy

a. If it shows this, Windows Update is going straight out to the internet:
Direct access (no proxy server)
b. If it shows something like this, Windows Update is using the proxy:
Proxy Server(s) : http=127.0.0.1:8080;https=127.0.0.1:8080

Mine showed this (when Psiphon is running):
Current WinHTTP proxy settings:
Proxy Server(s) :
http=127.0.0.1:3095;https=127.0.0.1:3095;socks=127.0.0.1:1080
Bypass List : <local>;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.*;169.254.*;[fc*];[fd*];[fe8*];[fe9*];[fea*];[feb*]

Regarding: http=127.0.0.1:3095;https=127.0.0.1:3095
This means WinHTTP (and therefore Windows Update) is configured to send all HTTP and HTTPS traffic through a local proxy listening on port 3095.

Regarding: socks=127.0.0.1:1080
Unfortunately, even though there is a socks line, WinHTTP does not support SOCKS. It will ignore that part. Only the HTTP/HTTPS entries matter.

Regarding: <local>;10.*;172.16.* -iK 192.168.*;169.254.*;[fc*];[fd*];[fe*]
This means private/internal addresses are excluded from the proxy.

This is how to tell if Windows Update is actually USING the proxy!

Set up two windows, one of which is an admin window for Powershell:
Trigger a Windows Update scan manually in the Powershell admin window.

usoclient StartScan

Trigger a scan to watch port 3095 while that's running:

netstat -ano | findstr :3095

TCP 127.0.0.1:3095 0.0.0.0:0 LISTENING 9452
TCP 127.0.0.1:3095 127.0.0.1:3151 ESTABLISHED 9452
TCP 127.0.0.1:3143 127.0.0.1:3095 TIME_WAIT 0
TCP 127.0.0.1:3144 127.0.0.1:3095 TIME_WAIT 0
TCP 127.0.0.1:3145 127.0.0.1:3095 TIME_WAIT 0
TCP 127.0.0.1:3151 127.0.0.1:3095 ESTABLISHED 9108

Rather than race the clock, we can run the netstat every second first.

netstat -ano 1 | findstr :3095

I tested Windows Update which is using the proxy as we would want it to
with Psiphon (even with the PAC file set which blocks microsoft.com).

On purpose, I waited to see what would happen when Microsoft stopped
updating Windows 10, and specifically if a free ESU would be offered.

At midnight, on October 14th to 15th, I watched Windows Update finish &
show this prompt to get the ESU if I create an MSA & set up a backup.
<https://i.postimg.cc/Dwv6M7Lr/windowseol01.jpg>

I have NOT created the MSA yet, because it takes about a month on TOR to
get ProtonMail to reliably accept verification emails (ask me how I know
that, where ProtonMail will permanently disable verifications if you rush).

In the interim, I wrote up my best guess as to the absolute bare minimum a user in the USA would need to do in order to qualify for the free ESU.
*Tutorial:*
*How to set up Windows 10 free ESU using bare-minimum requirements*
<https://i2pn2.pugleaf.net/groups/alt.comp.microsoft.windows/articles/4932>

With that done, what's left is to create a private email on TOR
which doesn't ask for another email or for a phone number to create
and use it for about a month with "normal-looking traffic.

Then I can create the MSA account.
But in the interim, I need to keep Microsoft from seeing my real IP
during the Windows Update process (which uses WinHTTP when proxied).

Strategy:
a. Microsoft does NOT get your real IP address
b. Microsoft does not get any information from your email address MSA

For that strategy, you can be on VPN all the time, but a proxy is faster.
Much faster. And you can always tack on the VPN before or after the proxy.

Since I already have the psiphon.bat script starting the proxy, I wrote and tested the script below, which "could" run the Windows Update but I
hesitated to allow the script itself to run the Windows Update from inside
the script because then it would only work on a system that has added
specific PowerShell compoents (necessary to run the Windows Update).

Instead, I made the script need an OUTSIDE manual call to the Windows
Update GUI (which is the most reliable way & still be compatible for everyone).

Below is the script that I tested on my machine to check if Windows Update
is getting my real IP address, or the Psiphon proxy IP address instead.

The use model is simple:
a. Run the script
b. While the script is running, manually run a Windows Update check
c. Kill the script

The log file will look something like this if your proxy is trapping calls.
==============================================
[Thu 10/16/2025 6:01:07.59] Starting scan
[Thu 10/16/2025 6:01:07.63] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:01:07.82] monitoring...
[Thu 10/16/2025 6:01:12.22] PID=0 Proc=System
[Thu 10/16/2025 6:01:12.22] *** WINDOWS UPDATE HIT *** PID=5712 Proc=svchost.exe
[Thu 10/16/2025 6:01:12.22] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:01:12.22] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:01:15.31] monitoring...
[Thu 10/16/2025 6:01:20.16] PID=0 Proc=System
[Thu 10/16/2025 6:01:20.16] *** WINDOWS UPDATE HIT *** PID=5712 Proc=svchost.exe
[Thu 10/16/2025 6:01:20.16] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:01:20.16] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:01:22.87] monitoring...
[Thu 10/16/2025 6:01:27.15] PID=0 Proc=System
[Thu 10/16/2025 6:01:27.15] *** WINDOWS UPDATE HIT *** PID=5712 Proc=svchost.exe
[Thu 10/16/2025 6:01:27.15] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:01:27.15] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:01:29.89] monitoring...
[Thu 10/16/2025 6:01:34.18] PID=0 Proc=System
[Thu 10/16/2025 6:01:34.18] PID=0 Proc=System
[Thu 10/16/2025 6:01:34.18] PID=0 Proc=System
[Thu 10/16/2025 6:01:34.18] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:01:34.61] monitoring...
[Thu 10/16/2025 6:01:39.14] PID=0 Proc=System
[Thu 10/16/2025 6:01:39.14] PID=0 Proc=System
[Thu 10/16/2025 6:01:39.14] PID=0 Proc=System
[Thu 10/16/2025 6:01:39.14] PID=0 Proc=System
[Thu 10/16/2025 6:01:39.14] *** WINDOWS UPDATE HIT *** PID=5712 Proc=svchost.exe
[Thu 10/16/2025 6:01:39.14] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:01:39.14] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:01:42.12] monitoring...
[Thu 10/16/2025 6:01:47.20] PID=0 Proc=System
[Thu 10/16/2025 6:01:47.20] PID=0 Proc=System
[Thu 10/16/2025 6:01:47.20] PID=0 Proc=System
[Thu 10/16/2025 6:01:47.20] *** WINDOWS UPDATE HIT *** PID=5712 Proc=svchost.exe
[Thu 10/16/2025 6:01:47.20] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:01:47.20] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:01:50.16] monitoring...
[Thu 10/16/2025 6:01:55.21] PID=0 Proc=System
[Thu 10/16/2025 6:01:55.21] PID=0 Proc=System
[Thu 10/16/2025 6:01:55.21] PID=0 Proc=System
[Thu 10/16/2025 6:01:55.21] PID=0 Proc=System
[Thu 10/16/2025 6:01:55.21] PID=0 Proc=System
[Thu 10/16/2025 6:01:55.21] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:01:55.84] monitoring...
[Thu 10/16/2025 6:02:00.13] PID=0 Proc=System
[Thu 10/16/2025 6:02:00.13] PID=0 Proc=System
[Thu 10/16/2025 6:02:00.13] PID=0 Proc=System
[Thu 10/16/2025 6:02:00.13] PID=0 Proc=System
[Thu 10/16/2025 6:02:00.13] PID=0 Proc=System
[Thu 10/16/2025 6:02:00.13] *** WINDOWS UPDATE HIT *** PID=5712 Proc=svchost.exe
[Thu 10/16/2025 6:02:00.13] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:02:00.13] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:02:03.30] monitoring...
[Thu 10/16/2025 6:02:08.15] PID=0 Proc=System
[Thu 10/16/2025 6:02:08.15] PID=0 Proc=System
[Thu 10/16/2025 6:02:08.15] PID=0 Proc=System
[Thu 10/16/2025 6:02:08.15] PID=0 Proc=System
[Thu 10/16/2025 6:02:08.15] *** WINDOWS UPDATE HIT *** PID=5712 Proc=svchost.exe
[Thu 10/16/2025 6:02:08.15] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:02:08.15] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:02:11.29] monitoring...
[Thu 10/16/2025 6:02:16.15] PID=0 Proc=System
[Thu 10/16/2025 6:02:16.15] PID=0 Proc=System
[Thu 10/16/2025 6:02:16.15] PID=0 Proc=System
[Thu 10/16/2025 6:02:16.15] PID=0 Proc=System
[Thu 10/16/2025 6:02:16.15] PID=0 Proc=System
[Thu 10/16/2025 6:02:16.15] PID=9452 Proc=psiphon-tunnel-core.exe
[Thu 10/16/2025 6:02:16.79] monitoring...

so that everyone always benefits from the appreciable efforts I expend
to help them, here is the script for your use for testing purposes..

@echo off
REM C:\data\sys\batch\checkwindowsupdate.bat 20251016 version 1.0
REM This is version 1.5
REM Tool to log details (i.e., use of proxy) when an update scan is done.
REM v1.0 20251016, 91 lines
REM Runs "usoclient StartScan" to kick off a Windows Update check.
REM Optionally run "usoclient StartInteractiveScan" for a deeper scan.
REM Every 5 seconds, checks for connections on port 3095.
REM For each PID using that port, resolves the process name
REM (svchost.exe for Windows Update).
REM Creates a timestamped log file in C:\data\sys\log\.
REM Appends timestamp + PID + process name to the log.
REM v1.1 20251016, 101 lines
REM Modified the port to be a variable
REM Padded single-digit timestamps in logfile for consistent sorting
REM v1.2 20251016, 113 lines
REM Added highlight for the wuauserv process
REM If the process is not svchost.exe, it logs normally.
REM If it is svchost.exe, it runs a quick PowerShell check:
REM Which looks up the services hosted by that PID.
REM If one of them is wuauserv, it writes a highlighted line:
REM [date time] *** WINDOWS UPDATE HIT *** PID=736 Proc=svchost.exe
REM Otherwise, it logs normally.
REM v1.3 20251016, 118 lines
REM Fixed %%a was used but never set, which breaks the inner loop.
REM v1.4 20251016, 123 lines
REM Commented out "usoclient StartScan" because it won't run if cached
REM Added "usoclient StartInteractiveScan" as it will run even if cached
REM v1.5 20251016, 138 lines
REM Added a heartbeat to confirm the loop is alive
REM Gave up on the usoclient commands above.
REM Don't want to make the script not work on everyone else's PC
REM But if I wanted to run the update in this script, I need to do this
REM Install-Module PSWindowsUpdate
REM Import-Module PSWindowsUpdate
REM Get-WindowsUpdate -MicrosoftUpdate -AcceptAll -IgnoreReboot
REM Install-Module PSWindowsUpdate
REM But even that requires admin so let's just run the update in the GUI
REM So this is no longer a tool to trigger Windows Update & log proxy hits
REM It just logs proxy hits when the Windows Update is manually triggered.
REM Comment linelength limit ==================================================
REM 567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 12
:: This is how to tell if Windows Update is CONFIGURED to use the proxy.
::
:: Win+R > cmd {ctrl+shft+rtn}
:: C:\> netsh winhttp show proxy
::
:: a. If it shows this, Windows Update is going straight out to the internet:
:: Direct access (no proxy server)
:: b. If it shows something like this, Windows Update is using the proxy:
:: Proxy Server(s) : http=127.0.0.1:8080;https=127.0.0.1:8080
::
:: Mine showed this:
:: Current WinHTTP proxy settings:
:: Proxy Server(s) : http=127.0.0.1:3095;https=127.0.0.1:3095;socks=127.0.0.1:1080
:: Bypass List : <local>;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.*;169.254.*;[fc*];[fd*];[fe8*];[fe9*];[fea*];[feb*]
::
:: Regarding: http=127.0.0.1:3095;https=127.0.0.1:3095
:: This means WinHTTP (and therefore Windows Update) is configured to send all HTTP and HTTPS traffic through a local proxy listening on port 3095.
::
:: Regarding: socks=127.0.0.1:1080
:: Unfortunately, even though there is a socks line, WinHTTP does not support SOCKS. It will ignore that part. Only the HTTP/HTTPS entries matter.
::
:: Regarding: <local>;10.*;172.16.* rCa 192.168.*;169.254.*;[fc*];[fd*];[fe*]
:: This means private/internal addresses are excluded from the proxy.
::
:: This is how to tell if Windows Update is actually USING the proxy!
::
:: Set up two windows, one of which is an admin window for Powershell:
:: Trigger a Windows Update scan manually in the Powershell admin window.
:: PS:> usoclient StartScan
:: Trigger a scan to watch port 3095 while that's running:
:: C:\> netstat -ano | findstr :3095
:: TCP 127.0.0.1:3095 0.0.0.0:0 LISTENING 9452
:: TCP 127.0.0.1:3095 127.0.0.1:3151 ESTABLISHED 9452
:: TCP 127.0.0.1:3143 127.0.0.1:3095 TIME_WAIT 0
:: TCP 127.0.0.1:3144 127.0.0.1:3095 TIME_WAIT 0
:: TCP 127.0.0.1:3145 127.0.0.1:3095 TIME_WAIT 0
:: TCP 127.0.0.1:3151 127.0.0.1:3095 ESTABLISHED 9108
::
:: Rather than race the clock, we can run the netstat every second first.
:: C:\> netstat -ano 1 | findstr :3095
:: This proves that the process found is the Windows Update service
:: PS C:\Windows\system32> Get-CimInstance Win32_Service | Where-Object { $_.ProcessId -eq 736 } | Select-Object Name, DisplayName
::
:: Name DisplayName
:: ---- -----------
:: wuauserv Windows Update
::
::
:: NOTE: Port 3095 is used here because that's the port our local
:: HTTP-to-SOCKS proxy is configured to listen on.
:: You can verify this by checking your WinHTTP proxy settings:
:: netsh winhttp show proxy
:: If it shows http=127.0.0.1:3095, then this script will work as-is.
:: Otherwise, update the port number below to match your actual proxy listener.

set PROXYPORT=3095

set LOGDIR=C:\data\sys\log
if not exist "%LOGDIR%" md "%LOGDIR%"

set hour=%TIME:~0,2%
if "%hour:~0,1%"==" " set hour=0%hour:~1,1%

set LOGFILE=%LOGDIR%\update_proxy_hits_%DATE:~10,4%%DATE:~4,2%%DATE:~7,2%_%hour%%TIME:~3,2%%TIME:~6,2%.log

echo Starting Windows Update scan and proxy logging...
echo Log file: %LOGFILE%
echo Press Ctrl+C to stop.
echo ============================================== >> "%LOGFILE%"
echo [%DATE% %TIME%] Starting scan >> "%LOGFILE%"

:: Trigger Windows Update scan (might not run if results are recently cached)
REM usoclient StartScan
:: Trigger Windows Update scan (should trigger even if it was cached recently)
usoclient StartInteractiveScan

:: Continuous logging of connections to port 3095
:loop
for /f "tokens=5" %%a in ('netstat -ano ^| findstr :%PROXYPORT%') do (
for /f "tokens=1,*" %%b in ('tasklist /fi "PID eq %%a" /fo table /nh 2^>nul') do (
if /i "%%b"=="svchost.exe" (
rem Check if this svchost is hosting Windows Update
powershell -command "if ((Get-CimInstance Win32_Service | Where-Object { $_.ProcessId -eq %%a }).Name -eq 'wuauserv') { Write-Output '[%DATE% %TIME%] *** WINDOWS UPDATE HIT *** PID=%%a Proc=%%b' } else { Write-Output '[%DATE% %TIME%] PID=%%a Proc=%%b' }" >> "%LOGFILE%"
) else (
echo [%DATE% %TIME%] PID=%%a Proc=%%b >> "%LOGFILE%"
)
)
)

:: Add a heartbeat to confirm the loop is alive
echo [%DATE% %TIME%] monitoring... >> "%LOGFILE%"
timeout /t 5 >nul

goto loop

:: end of C:\data\sys\batch\checkwindowsupdate.bat
--
The main point of Usenet is for intelligent people to help each other, &
for results to be archived so that anyone can access our immense knowledge.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Marion wrote:

Q: How would Microsoft Windows Update know my IP address?
A: It can't. It only sees the proxy. Or VPN. But not my real IP address.

UPDATE

Of course, I had to remove the microsoft domains from my PAC file, where I
want to thank Andy Burns for teaching me what the PAC file does as I had
never heard of it until I started this quest to build my own proxy client.


/*
proxy.pac C:\data\sys\batch\proxy.pac (20250902)
This is version 1.4
Selectively bypass proxy for sites sensitive to tunneling or IP shifts:
- Google services (search, mail, etc.)
- Amazon (especially the Amazon Vine Voice program)
- Speicific Microsoft domains (Copilot)
All other traffic routed through local SOCKS proxy at 127.0.0.1:1080
- Including Windows Update

Useful for split-tunnel setups where trusted domains go direct
but everything else is encrypted via Psiphon SOCKS5 proxy.

If needed, test PAC web access and fundamental logic with:
- https://pactester.brdbnt.com/
- https://github.com/termsl/WPADChecker
- curl http://127.0.0.1/proxy.pac

v1.0 20250902(added Amazon Vine Voice https://amazon.com/vine/about)
v1.1 20250910(added Google Gmail but I need to add it to Thunderbird)
v1.2 20250918(added Microsoft sites for practice adding domains)
v1.3 20251016(removed Microsoft domains for Windows-Update reasons)
v1.4 20251016(rewrote to eliminate Windows-Update altogether)
*/

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 Vine
if (shExpMatch(host, "*.amazon.com") ||
shExpMatch(host, "amazon.com")) {
return "DIRECT";
}

// Keep Copilot direct for stability
if (shExpMatch(host, "*.copilot.microsoft.com")) {
return "DIRECT";
}

// All other traffic, including Microsoft Update, Bing, etc. ? proxy
return "SOCKS 127.0.0.1:1080";
}
--
The point of Usenet is for smart people to help each other & for results
to be archived so that anyone can access our immense tribal knowledge.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

UPDATE:

Now that I have multiple proxies (Tor & Psiphon) working with every Windows TCP/UDP binary that I want to be proxied (e.g., curl, powershell, etc.),
it's time to make sure there aren't any leaks, which takes thoughtful
effort to catch (since you can't catch what you're not testing for).

To that end, I wrote this rather detailed testing script, but the problem
is that the output is verbose, so it doesn't give an easy yes/no answer.

Hence, after posting this proxy-testing script, I will post a much simpler proxy test, which outputs a formatted PASS/FAIL to whether or not your IP address is proxied through Tor/Psiphon free no-registration proxy servers.

@echo off
REM C:\data\sys\batch\checkproxy.bat 20250916
REM This is version 2.2
REM Custom unified Windows proxy diagnostic tool
REM v1.0 lists WinINET manual proxy, WinHTTP proxy, PAC/AutoDetect
REM v1.1 replaces echo. with echo( to avoid command misinterpretation
REM v1.2 adds PAC file existence check and SHA256 hash logging (114 lines)
REM v1.3 (152 lines) adds debugging (section 9)
REM v1.4 (161 lines) adds more debugging (section 10)
REM v1.5 (182 lines) adds more debugging (section 11)
REM v1.6 (204 lines) adds command reference (section 12)
REM v1.7 (205 lines) Added example.com which is reserved for demos/tests.
REM v1.8 (217 lines) Added check for freegate proxy in addition to psiphon
REM v1.9 (231 lines) Added output in final report to add freegate logging
REM v2.0 (271 lines) adds timestamped log (checkproxyYYYYMMDD_HHMMSS.log)
REM v2.1 (285 lines) parameterized HTTP port for freegate 8580 & psiphon 3736
REM v2.2 (299 lines) parameterized all the proxy ports throughout
REM Comment linelength limit ==================================================
REM 567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 12
:: Normally the pac file is served by a web server.
:: This script doesn't rely on Windows successfully fetching the PAC file
:: via HTTP. Instead, it Sets the registry key to point to the PAC URL
:: It assumes the PAC logic is known & trusted.
:: It uses proxy.cmd to apply proxy settings directly,
:: bypassing the need for Windows to interpret the PAC file
:: So even if http://127.0.0.1/proxy.pac isnot actually being served
:: by a web server, the system still behaves as if it is because the
:: tooling here enforces the logic manually.
:: This is the where Windows typically looks for the PAC script URL.
:: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\
:: AutoConfigURL = http://127.0.0.1/proxy.pac
:: That tells Windows to fetch the PAC file from your own machine via HTTP
:: http://127.0.0.1/proxy.pac
:: C:\data\sys\batch\proxy.pac
:: curl http://127.0.0.1/proxy.pac
::
:: You could point to the actual pac file but that's less universal
:: AutoConfigURL = file:///C:/data/sys/batch/proxy.pac
::
:: C:\app\network\psiphon\psiphon3.exe -mode=socks
:: Win+I > Settings > Network & Internet > Proxy > Manual proxy setup = on
:: Automatic proxy setup
:: Automatically detect settings = on
:: Use setup script = on
:: Script address = http://127.0.0.1/proxy.pac
:: Manual proxy setup
:: Use a proxy server = on
:: Address http=127.0.0.1:3736;https=127.0.0.1:3736;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.*;172.28.*;172.29.*;172.30.*;172.31.*;192.168.*;169.254.*;[fc*];[fd*];[fe8*];[fe9*];[fea*];[feb*]
:: [x]Don't use the proxy server for local (intranet) addresses
::
:: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL
:: AutoConfigURL = http://127.0.0.1/proxy.pac
::
:: C:\data\sys\batch\proxy.pac
::
:: Final Result
:: WinINET: Enabled and pointing to Psiphon
:: WinHTTP: Synced to match WinINET
:: PAC: Registry keys set, logic assumed, Auto-Detect enabled
:: The system is now fully aligned across all proxy layers.
::
REM BELOW is the log wrapper (console output saved to a timestamped file) v2p0
set "LOGDIR=C:\data\sys\log"

if "%1"=="__LOGGING__" goto :run_script

for /f "tokens=1-4 delims=/ " %%a in ("%DATE%") do (
set DOW=%%a
set MM=%%b
set DD=%%c
set YYYY=%%d
)
for /f "tokens=1-3 delims=:." %%a in ("%TIME%") do (
set HH=%%a
set Min=%%b
set Sec=%%c
)
if "%HH:~0,1%"==" " set HH=0%HH:~1,1%

set LOGSTAMP=%YYYY%%MM%%DD%_%HH%%Min%%Sec%
set "LOGFILE=%LOGDIR%\checkproxy%LOGSTAMP%.log"
set "TMPTXT=%LOGDIR%\checkproxy%LOGSTAMP%.tmp"

if not exist "%LOGDIR%" md "%LOGDIR%" 2>nul

powershell -NoProfile -Command ^
" & { & cmd /c '\"%~f0\" __LOGGING__' 2>&1 | Tee-Object -FilePath '%TMPTXT%' }"

powershell -NoProfile -Command ^
" [System.IO.File]::WriteAllText('%LOGFILE%', (Get-Content -Raw -LiteralPath '%TMPTXT%'), (New-Object System.Text.UTF8Encoding($false))); Remove-Item -LiteralPath '%TMPTXT%' -ErrorAction SilentlyContinue"

echo(
echo Log created at %LOGFILE%
echo(
pause
exit /b

:run_script
REM ABOVE is the log wrapper (console output saved to a timestamped file) v2p0

set FREEGATE_HTTP_PORT=8580
set FREEGATE_HTTP_PORT_ALT=8581
set PSIPHON_HTTP_PORT=3736
set PSIPHON_SOCKS_PORT=1080

echo [%DATE% %TIME%] Starting proxy check...

setlocal

set KEY="HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings"
set PACFILE=C:\data\sys\batch\proxy.pac
REM v2.0 Replace the HTTP proxy port with a parameterized port
echo ==============================================
echo WINDOWS PROXY CONFIGURATION CHECK
echo ==============================================

REM --- PAC file existence check ---
if not exist "%PACFILE%" (
echo WARNING: PAC file not found at %PACFILE%
) else (
echo PAC file found at %PACFILE%
echo PAC file SHA256 hash:
certutil -hashfile "%PACFILE%" SHA256
)

REM --- WinINET (manual proxy) ---
echo(
echo [1] WinINET / Internet Settings
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 is ENABLED
echo Proxy server: %ProxyServer%
) else (
echo Proxy is DISABLED
)

REM --- WinHTTP proxy ---
echo(
echo [2] WinHTTP proxy (system/background services)
netsh winhttp show proxy

REM --- PAC (Proxy Auto-Config) & AutoDetect ---
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 script set: %PACurl%
) else (
echo No PAC script URL found.
)

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


REM Added these debugging commands (v1p3)
echo(
echo [4] Psiphon and Mongoose process check
echo tasklist | findstr /i "psiphon3.exe mongoose.exe"
tasklist | findstr /i "psiphon3.exe mongoose.exe"

:: Added this insert to check for freegate proxy (v1p8)
echo(
echo [4b] Freegate process check
tasklist | findstr /i "fg790p.exe"

echo(
echo [5b] Freegate port binding check
REM netstat -ano | findstr :8580
netstat -ano | findstr :%FREEGATE_HTTP_PORT%
REM netstat -ano | findstr :8581
netstat -ano | findstr :%FREEGATE_HTTP_PORT_ALT%
:: END INSERT to check for freegate proxy (v1p8)

echo(
echo [5] Port binding check (Mongoose/Proxy)
echo netstat -ano | findstr :8080
netstat -ano | findstr :8080

echo(
echo [6] DNS resolution test
echo nslookup example.com
REM nslookup example.com
REM v2.1 suppressed stderr
nslookup example.com 2>nul

echo(
echo [7] Internet connectivity test
echo ping 8.8.8.8
ping 8.8.8.8

REM Using %PROXY_PORT% set to Freegate (8580) & then to Psiphon (3736)
echo(
echo [8] Proxy test via curl (Freegate and Psiphon)

REM --- Freegate test (8580) ---
REM set PROXY_PORT=8580
set PROXY_PORT=%FREEGATE_HTTP_PORT%
echo -- Freegate on port %PROXY_PORT% --
echo curl -x http://127.0.0.1:%PROXY_PORT% http://example.com --max-time 5
curl -x http://127.0.0.1:%PROXY_PORT% http://example.com --max-time 5

REM --- Psiphon test (3736) ---
REM set PROXY_PORT=3736
set PROXY_PORT=%PSIPHON_HTTP_PORT%
REM echo -- Psiphon on port %PROXY_PORT% --
echo curl -x http://127.0.0.1:%PROXY_PORT% http://example.com --max-time 5
curl -x http://127.0.0.1:%PROXY_PORT% http://example.com --max-time 5

echo(
echo [9] .NET proxy settings (PowerShell)
echo powershell -Command "[System.Net.WebRequest]::DefaultWebProxy"
powershell -Command "[System.Net.WebRequest]::DefaultWebProxy"

echo(
echo [10] Network adapter configuration
echo ipconfig /all
ipconfig /all

echo(
echo [11] Network interface and routing diagnostics

echo netsh interface show interface
netsh interface show interface

echo(
echo route print
route print

echo(
echo curl --verbose http://example.com
curl --verbose http://example.com

REM Optional deeper trace (creates trace.txt in current folder)
echo(
echo curl --trace trace.txt http://example.com
curl --trace trace.txt http://example.com


echo(
echo Summary:
echo Proxy Enabled: %ProxyEnable%
echo Proxy Server: %ProxyServer%
echo PAC URL: %PACurl%
echo AutoDetect: %AutoDetect%

echo(
echo ==============================================
echo Check complete.
echo ==============================================

echo(
echo [12] Command Reference (manual run options)
echo certutil -hashfile "C:\data\sys\batch\proxy.pac" SHA256
echo reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
echo reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer
echo netsh winhttp show proxy
echo reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v AutoConfigURL
echo reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v AutoDetect
echo tasklist | findstr /i "psiphon3.exe mongoose.exe"
echo netstat -ano | findstr :8080
echo nslookup example.com
echo ping 8.8.8.8
REM echo curl -x http://127.0.0.1:3736 http://example.com --max-time 5
echo psiphon http port
echo curl -x http://127.0.0.1:%PSIPHON_HTTP_PORT% http://example.com --max-time 5
echo freegate http port
echo curl -x http://127.0.0.1:%FREEGATE_HTTP_PORT% http://example.com --max-time 5
echo powershell -Command "[System.Net.WebRequest]::DefaultWebProxy"
echo ipconfig /all
echo netsh interface show interface
echo route print
echo curl --verbose http://example.com
echo curl --trace trace.txt http://example.com
echo(
echo Freegate process check:
tasklist | findstr /i "fg790p.exe" || echo No Freegate process found.
echo(
echo Freegate port check:
REM netstat -ano | findstr :8580 || echo No listener on 8580
REM netstat -ano | findstr :8581 || echo No listener on 8581
netstat -ano | findstr :%FREEGATE_HTTP_PORT% || echo No listener on %FREEGATE_HTTP_PORT%
netstat -ano | findstr :%FREEGATE_HTTP_PORT_ALT% || echo No listener on %FREEGATE_HTTP_PORT_ALT%
REM Sometimes Freegate sets ProxyServer to 127.0.0.1:8590 in
REM Internet Options while actually listening on 8580 so check for that
echo(
echo ProxyServer registry value: %ProxyServer%
REM echo Expected Freegate listener: 127.0.0.1:8580
echo Expected Psiphon listener: 127.0.0.1:%PSIPHON_HTTP_PORT%
echo Expected Freegate listener: 127.0.0.1:%FREEGATE_HTTP_PORT%
endlocal

REM end of C:\data\sys\batch\checkproxy.bat
--
Helping others & learning from them is what this Usenet ng is all about.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Marion wrote:

Hence, after posting this proxy-testing script, I will post a much simpler proxy test, which outputs a formatted PASS/FAIL to whether or not your IP address is proxied through Tor/Psiphon free no-registration proxy servers.

Here is a vastly simpler pass/fail script to test if your IP is truly tunneled.

Note that if the proxy is as good as my setup, it's difficult to skirt past it. But it can be done. As shown below. Using direct DNS queries, for example.

@echo off
REM C:\data\sys\batch\checkip.bat 20251029
REM This is version 1p2
REM Designed to be a simple proxy check to compare ISP vs Psiphon exit IP
REM Outputs: Proxy OK: ISP=<your real IP> Psiphon=<proxy IP>
REM Or it outputs: Proxy FAIL: both=<your real IP>
REM v1p0 20251029
REM compares IP addresses with & without proxy
REM Drat. The proxy is well entrenced. Curl just can't get around it.
REM This failed: curl -s https://api.ipify.org
REM because, while curl doesn't use WinINET/WinHTTP,
REM curl was being proxied by proxybridge.
REM This failed: curl -s --noproxy "*" https://api.ipify.org
REM because --noproxy only tells curl to ignore configured proxies.
REM It doesn't bypass ProxyBridge's process-level interception
REM The --noproxy doesn't bypass ProxyBridge's interception.
REM This failed: curl -s --proxy 127.0.0.1:34010
REM because the local ProxyBridge relay port is then proxied by Psiphon.
REM That just pointed curl at ProxyBridge's local relay,
REM which itself forwards into Psiphon. So we still got Psiphon's IP.
REM This failed: powershell -Command "(Invoke-WebRequest -UseBasicParsing
REM https://api.ipify.org -Proxy $null).Content"
REM because ProxyBridge was still intercepting PowerShell's HTTP traffic,
REM so even the classic PowerShell "no proxy" call was being tunneled.
REM v1p1 20261029
REM added nslookup to slip around a well-entrenched proxy which worked
REM because ProxyBridge/Psiphon doesn't proxy UDP DNS queries,
REM so nslookup was finally able to slip around the tunnel.
REM That nslookup DNS trick bypasses ProxyBridge/Psiphon because
REM it's a raw DNS query, not HTTP, to get the true IP.
REM DNS query gives a guaranteed "direct" view of the ISP IP address.
REM v1p2 20261029
REM modified to make the output a single line for simplicity
REM a 1st "for /f" grabs the real ISP IP from the DNS trick.
REM a 2nd "for /f" grabs the Psiphon exit IP via SOCKS5
REM then it compares them for an OK vs FAIL outpout.

@echo off
for /f "tokens=2 delims= " %%A in ('nslookup myip.opendns.com resolver1.opendns.com ^| findstr /R "Address:"') do set ISPIP=%%A
for /f %%A in ('curl -s --socks5 127.0.0.1:1080 https://api.ipify.org') do set PROXYIP=%%A

if "%ISPIP%"=="%PROXYIP%" (
echo Proxy FAIL: both=%ISPIP%
) else (
echo Proxy OK: ISP=%ISPIP% Psiphon=%PROXYIP%
)
pause

:: end of C:\data\sys\batch\checkip.bat
--
I am not here for my ego; nor for my amusement; but to teach & learn.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

UPDATE:

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

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

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

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

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

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

With these methods, we can fine tune which traffic is tunneled thru the
proxy, which stays local, and even chain multiple proxies if needed.
1. WinINET is used by user-facing apps like Internet Explorer,
Edge, Office, and anything that says "Use system proxy settings."
It applies a single proxy setting to those applications.

2. WinHTTP is used by background services, scripts, and some system
components. It has its own separate proxy configuration, and it
also is "all or nothing" just like WinINET is "all or nothing".

3. PAC (Proxy Auto-Config) is used by browsers like Firefox
(and optionally by WinINET if you point Windows to a PAC URL via
a lightweight web server such as I did with mongoose.exe).
A PAC file is a small JavaScript program that decides per request
whether to go direct, use a proxy, or choose between multiple proxies.

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

For example, I just wrote, tested, and posted today, moments ago, a
tutorial for setting up Firefox to use a PAC file for all its traffic.

Following this tutorial makes that tunnel about as iron-clad as I can make
it, where I have tested it every way I can think of to ensure it works.
--
Helping others & learning from them is what this Usenet ng is all about.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Marion wrote:

Following this tutorial makes that tunnel about as iron-clad as I can make it, where I have tested it every way I can think of to ensure it works.

Here's a (probably) final summary of the psiphon.bat proxy utility
(as I haven't felt any need to update the script as I've been testing it
by using it all day, every day, for weeks, on my desktop Windows PC).

BTW, the psiphon.bat script is doing more than just launching Psiphon in
SOCKS mode. It is wrapping Psiphon with a set of helpers so that both
WinINET and WinHTTP aware applications can be forced to use the proxy.

Key points of what it does:

1. Elevation
Checks if running as admin, relaunches with UAC if not.

2. PAC serving
Starts mongoose.vbs to serve proxy.pac locally on 127.0.0.1.
https://127.0.0.1/proxy.pac
Waits a couple of seconds to ensure the PAC file is available.
Verifies with curl that proxy.pac is reachable before continuing.

3. Psiphon launch
Starts psiphon3.exe in SOCKS mode, which listens on a local port.
Waits a few seconds for Psiphon to initialize.

4. PAC logic
Logs the event to proxy.log.
Calls pac.cmd to apply PAC logic silently.
Forces registry keys AutoConfigURL and AutoDetect so that IE/WinINET
always point to http://127.0.0.1/proxy.pac and auto-detect is on.

5. WinHTTP sync
Runs netsh winhttp import proxy source=ie so that WinHTTP apps
(like Windows Update or services) inherit the same proxy settings.
This is the step that extends Psiphon's reach beyond WinINET apps.

6. User interaction
Leaves the console open with a pause so you we see output.
Exits without killing the parent shell.

In effect, this script is bridging three layers:
a. Psiphon provides a SOCKS proxy.
b. Mongoose serves a PAC file that tells browsers & apps how to use it.
c. The batch script forces WinINET and WinHTTP to consume that PAC &
syncs them, so both browser traffic & system services are covered.

Compared to the ProxyBridge wrapper, this approach is more about
coaxing Windows' own proxy stacks (WinINET and WinHTTP) into alignment,
whereas ProxyBridge intercepts traffic at the socket level. Both solve
the same problem from different angles making sure all traffic really
goes through the proxy rather than leaking direct.
--
Understanding the issues is important because details are what matter!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

ProxyBridge (pb.bat)

Here's a (probably) final summary of the ProxyBridge pb.bat proxy utility
(as I haven't felt any need to update the script as I've been testing it
by using it all day, every day, for weeks, on my desktop Windows PC).

BTW, the pb.bat script is doing more than just launching ProxyBridge
that it adds the functionality I felt was missing from the native tool.

Andy Burns might be right that they removed basic functionality to differentiate their free product tier from their payware after all!

Speaking of Andy Burns, I need to thank him for cluing me in to the
existence of PAC files about a month ago & at the same time I need to thank Allan Higdon for letting me know about ProxyBridge at about the same time.

I knew nothing about either PAC nor ProxyBridge until they suggested them. Starting with their suggestion, I was able to write the psiphon.bat
previously described, and the ProxyBridge wrapper script (pb.bat).

The ProxyBridge (pb.bat) script is essentially a management layer
that adds basic features that I felt ProxyBridge needed, but it lacked.

The pb.bat batch file does four main things:

1. Elevation & setup
Checks for admin rights & re-launches with UAC if needed.
Sets up a log directory & builds a timestamped log filename.

2. Rules handling
Reads rules from rules.txt (or rules_psiphon.txt, rules_tor.txt).
Strips comments & builds a single %PBARGS% string.
This solves ProxyBridge's lack of import/export for rules.

3. Launch & logging
Kills any existing ProxyBridge_CLI.exe process.
Starts ProxyBridge with the defined arguments.
Uses PowerShell Tee-Object to mirror output to console & log file.
Ensures one Ctrl+C cleanly stops ProxyBridge & the batch script.

4. Cleanup & usability
Ensures only one console window is used.
Avoids the "Terminate batch job (Y/N)?" prompt by wrapping in cmd /c.
Provides examples of rules for proxy, block, direct, & port-based
actions, making it easier for others to adopt.

Overall, the ProxyBridge setup is more than just a proxifier in that
it hooks into the Windows networking stack & applies rules per process,
host, port, & protocol.

The script bridges the gap by making ProxyBridge far more practical for
daily use by adding rule persistence, logging, & clean process control.
--
On Usenet you can often find people who know a lot more than you do.
When that happens, it's our job to expand our knowledge from there.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Drat. I found a flaw....


I may need to add privoxy or polipo, as the pac.cmd script helps enforce consistency between WinINET and WinHTTP, but it does not change the
fundamental limitation that WinHTTP cannot speak SOCKS.

1. The pac.cmd script
Forces the AutoConfigURL registry key to point to
http://127.0.0.1/proxy.pac.
Ensures Auto-Detect is enabled.
Calls proxy.cmd /sync so WinINET proxy settings are copied into WinHTTP.
Verifies and re-applies PAC URL and Auto-Detect so they persist.
Logs all of this for traceability.

2. What it cannot do
If the proxy.pac returns "SOCKS 127.0.0.1:1080" then WinINET-aware
apps (like IE or Chrome) can honor that. But WinHTTP ignores SOCKS
directives. It only understands DIRECT or PROXY host:port for HTTP.
So when we run "netsh winhttp import proxy source=ie", WinHTTP
copies only the static HTTP proxy values, not the SOCKS entries
nor the PAC logic.
That means Windows Update and other WinHTTP clients may not tunnel
through Psiphonos SOCKS port just because the PAC is set.

3. What I might add to the tutorial is the use of Privoxy.
Privoxy listens as an HTTP proxy (127.0.0.1:8118).
Then the PAC can return "PROXY 127.0.0.1:8118" for all destinations.
WinINET & WinHTTP both understand that, so all traffic goes to Privoxy.
Privoxy then forwards into Psiphon's SOCKS port, bridging the gap.

So the pac.cmd script is valuable for keeping WinINET and WinHTTP in
sync and making sure the PAC URL is always enforced. But by itself it
does not solve the SOCKS limitation in WinHTTP.

To cover WinHTTP-only apps like Windows Update, we still likely need an HTTP-to-SOCKS bridge such as Privoxy or Polipo, and then have the PAC point
to that bridge.
--
Usenet allows purposefully helpful people to pool their experiences.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

HUGE UPDATE:

I finally fixed a huge problem in that I could never (until now) get VPN to work *last* in the chain (i.e., psiphon + proxybridge + VPN) even as VPN worked fine *first* in the chain (i.e., VPN + psiphon + proxybridge).

MULTIPLE problems needed to be identified:
1. Windows TAP adapter race condition ("Waiting for TUN/TAP interface to come up")
2. Psiphon SOCKS5 proxy lacks UDP ASSOCIATE
3. TAP adapter DHCP failures -> APIPA fallback
4. Free VPN server config variability (static IP vs DHCP push)

After solving those problems, finally, VPN works fine on Windows
whether it's the first or the last in the encryption chain of events.

However, initially only two issues seemed to show up which had to be solved:
1. Windows is too slow so we get "Waiting for TUN/TAP interface to come up"
2. The Psiphon SOCKS5 proxy supports TCP ASSOCIATE but not UDP ASSOCIATE

Given that, TCP VPN configs "should" have worked, even as UDP wouldn't work when VPN was last in the chain (i.e., after ProxyBridge was initiated).

What took a while to identify was WHY both UDP & TCP OpenVPN configs failed (where the VPN error for TCP was DIFFERENT than the error for UDP configs).
TCP: "Waiting for TUN/TAP interface to come up"
UDP: AIPA fallback "Initialization Sequence Completed With Errors"

What first needed to be modified in order for both TCP & UDP configs to
work (whether or not VPN was first or last in the encryption chain) was
each OpenVPN config file needed to tell OpenVPN.exe to employ adaptive commands to set up the TAP interface, and to wait longer before route injection occurs.
# Adaptively choose how Windows OpenVPN configures the TAP adapter
ip-win32 adaptive
# Give Windows 10 seconds longer before route injection begins
route-delay 10

In addition to that TAP adapter setup race with route injection, there is
no way around the fact that Psiphon's SOCKS5 proxy doesn't support UDP.

So the Psiphon rules.txt file needed to be modified extensively.

The rules.txt file had to be modified so that OpenVPN traffic
was handled correctly depending on protocol type. Before, both
TCP and UDP configs failed when VPN was placed last in the chain.

Here are the key changes between version 1p7 & 2p0 rules.txt:
a. Explicitly route OpenVPN.exe TCP traffic through Psiphon
Rule added:
openvpn.exe:*:443:TCP -> PROXY
This ensures that TCP VPN configs are proxied through
Psiphon's SOCKS5 tunnel.

b. Explicitly allow OpenVPN.exe UDP traffic to bypass Psiphon
Rule added:
openvpn.exe:*:*:UDP -> DIRECT
Because Psiphon's SOCKS5 proxy does not support UDP ASSOCIATE,
UDP VPN configs must go direct to the server.

c. Allow TAP/DHCP/DNS setup traffic to go DIRECT
Rules added:
svchost.exe:*:53:UDP -> DIRECT
svchost.exe:*:67,68:UDP -> DIRECT
system:*:*:UDP -> DIRECT
These ensure that Windows can perform DNS lookups and DHCP
lease negotiation for the TAP adapter without being blocked
or forced through Psiphon.

d. Block unwanted UDP traffic from browsers and apps
Rules added such as:
chrome.exe:*:443:UDP -> BLOCK
firefox.exe:*:443:UDP -> BLOCK
brave.exe:*:443:UDP -> BLOCK
This prevents browsers from leaking QUIC/UDP traffic outside
the encrypted chain.

e. Maintain TCP direct access for system processes
Rules like:
svchost.exe:*:*:TCP -> DIRECT
services.exe:*:*:TCP -> DIRECT
system:*:*:TCP -> DIRECT
These allow Windows core services to function normally while
keeping user applications proxied.

Here is the current status as of version 2p0 of the rules.txt file:
1. TCP OpenVPN configs now work when VPN is last in the chain,
because their traffic is correctly proxied through Psiphon.
2. UDP OpenVPN configs now work when VPN is last in the chain,
because their traffic bypasses Psiphon and goes direct.
3. TAP adapter setup traffic (DNS, DHCP) is allowed direct, so
Windows no longer fails with APIPA addresses.
4. Browser UDP traffic (QUIC) is blocked, preventing leaks.

The critical changes in rules.txt were:
1. Split handling of OpenVPN.exe traffic: TCP -> PROXY, UDP -> DIRECT.
2. Allow svchost/system UDP traffic direct for TAP setup.
3. Block browser UDP traffic to prevent leaks.
4. Keep system TCP traffic direct for stability.

Together with the OpenVPN config additions
(ip-win32 adaptive + route-delay 10), these rules fixed the
longstanding problem which had prevented VPN from being used after ProxyBridge. Now VPN works reliably whether it is first or last in the encryption chain.

Here is the version 2p0 of the rules.txt file to donate to the team.
# C:\app\network\proxy\proxybridge\rules.txt v1p0 20251023
# This is version 2p0
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Load this into ProxyBridge using the pb.bat script.
# Syntax: --rule <process>:<hosts>:<ports>:<protocol>:<action>
# Rules are case insensitive, # indicates comments, blank lines ignored.
# v1p1 20251023
# Added useful examples of block, direct & proxy for others to benefit
# Added usable inline comments (requires pb.bat v2p6 or higher to handle)
# v1p2 20251023
# Added usability explanations of dns complexity & QUIC/HTTPS3 issues.
# Added UDP block to handle Brave using experimental protocols above.
# v1p3 20251023
# Added clarification that TCP & UDP rules are not overridden
# v1p4 20251024
# Added Tor SOCKS5 proxy server (in addition to Psiphon's)
# v1p5 20251024
# Note that Tor cannot proxy UDP, so I had to add specific rules for that.
# v1p6 20251025
# Added Chrome, Brave, Edge & FF browser rules due to phoning home.
# v1p7 20251024
# Fixed error that Psiphon doesn't support UDP ASSOCIATE
# This is to avoid proxying UDP (Psiphon doesn't support UDP ASSOCIATE)
# Cleaned up DNS section because DNS via proxy is enabled by default
# v1p8 20251130
# Added DIRECT rules for svchost.exe, route.exe, and system UDP.
# So that TAP setup traffic bypasses ProxyBridge.
# Tunnel traffic (openvpn.exe on TCP 443) still goes through Psiphon.
# This separation allowed DHCP and ARP to succeed but Windows was slow
# to set up the tunnel until I added two directives to TCP config files.
# ip-win32 adaptive
# route-delay = 10
# Remaining issue:
# Even with bypasses, Windows was slow to mark TAP up.
# OpenVPN kept looping "Waiting for TUN/TAP interface to come up"
# v1p9 20251201
# Combined both TCP/UDP cases in a single rules.txt file by
# explicitly allowing UDP traffic from OpenVPN to go DIRECT,
# while still proxying TCP 443 through Psiphon
# Now TCP tunnel traffic is proxied through Psiphon
# While UDP tunnel traffic bypasses ProxyBridge (DIRECT)
# And TAP setup traffic (DHCP, ARP, route injection) is always DIRECT so
# OpenVPN can bring the interface up in time given ProxyBridge delays.
# v2p0 20251201
# The rules bypassed ProxyBridge, but the TAP adapter still failed DHCP.
# Windows gave it a fallback 169.254.x.x address, so OpenVPN reported
# "Completed With Errors." For UDP VPNGate configs to work, they must run
# DIRECT without Psiphon, and the network must allow the TAP adapter
# to obtain a proper 10.x.x.x lease from the VPN server.
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

--proxy socks5://127.0.0.1:1080 # Psiphon local SOCKS5 listener
# --proxy socks5://127.0.0.1:9150 # Tor Browser SOCKS5 listener (optional)

# Applications that should always use the proxy
--rule telegram.exe:*:*:TCP:PROXY
--rule MemoryHogs.exe:*:*:TCP:PROXY
--rule dialog.exe:*:*:TCP:PROXY

# Block QUIC/HTTP3 globally
--rule *:*:443:UDP:BLOCK

# Brave rules
--rule brave.exe:*:*:TCP:PROXY
--rule brave.exe:*:443:UDP:BLOCK
--rule BraveUpdate.exe:*:*:TCP:BLOCK
--rule brave.exe:*:5228:TCP:BLOCK
--rule brave.exe:*:53:UDP:BLOCK

# Chromium rules
--rule chrome.exe:*:*:TCP:PROXY
--rule chrome.exe:*:443:UDP:BLOCK
--rule chrome.exe:*:5228:TCP:BLOCK
--rule chrome.exe:*:53:UDP:BLOCK

# Firefox rules
--rule firefox.exe:*:*:TCP:PROXY
--rule firefox.exe:*:443:UDP:BLOCK

# Block telemetry and unwanted processes
--rule OneDrive.exe:*:*:TCP:BLOCK
--rule CompatTelRunner.exe:*:*:TCP:BLOCK
--rule SearchApp.exe:*:*:TCP:BLOCK

# Core system processes bypass proxy
--rule svchost.exe:*:*:TCP:DIRECT
--rule services.exe:*:*:TCP:DIRECT
--rule system:*:*:TCP:DIRECT

# Utility
--rule curl.exe:*:*:TCP:PROXY

# DNS and TAP setup bypass
--rule svchost.exe:*:53:UDP:DIRECT
--rule svchost.exe:*:67,68:UDP:DIRECT
--rule svchost.exe:*:*:UDP:DIRECT
--rule system:*:*:UDP:DIRECT
--rule route.exe:*:*:TCP:DIRECT
--rule route.exe:*:*:UDP:DIRECT

# OpenVPN rules
--rule openvpn.exe:*:443:TCP:PROXY # TCP tunnel proxied through Psiphon
--rule openvpn.exe:*:*:UDP:DIRECT # UDP tunnel bypasses ProxyBridge
# NOTE: For UDP OpenVPN configs to work, they must run DIRECT without Psiphon,
# and the network must allow the TAP adapter to obtain a proper 10.x.x.x lease.
# Otherwise OpenVPN will report "Initialization Sequence Completed With Errors"
# and the TAP adapter will fall back to a 169.254.x.x APIPA address.

# Log level
--verbose 3

# end of C:\app\network\proxy\proxybridge\rules.txt
--
The point of Usenet is for smart people to help each other & for results
to be archived so that anyone can access our immense tribal knowledge.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Marian wrote:

So the Psiphon rules.txt file needed to be modified extensively.

Correction.

The "ProxyBridge" rules.txt file had to be extensively modified.
[Not the Psiphon rules.txt file (which doesn't exist).]

I never would have started this project of creating a robust proxy on
Windows had I known how many problems would have to be surmounted, but
finally, after a couple of months (elapsed time), it's all resolved.
VPN + {Psiphon/SOCKS5 + ProxyBridge} required extensive modifications
{Psiphon/SOCKS5 + ProxyBridge} + VPN required even more modifications

But it all works well now (although WinHTTP can't use PAC or SOCKS still)
VPN first, Psiphon SOCKS5 proxy second & ProxyBridge last works well now.
Psiphon SOCKS5 proxy first, ProxyBridge second & VPN last works well too.

The fundamental problems first & foremost were not only that Psiphon's
SOCKS5 proxy does not handle UDP tunneling, but that the Windows TAP
adapter (Terminal Access Point) takes time to come up with ProxyBridge.
*Cannot connect OVPN (UDP) through SOCKS5 proxy*
<https://github.com/OpenVPN/openvpn/issues/661>

*What is TAP-Windows Adapter*
<https://www.thewindowsclub.com/tap-windows-adapters-vpn-driver>

In theory, SOCKS5 proxies "should" be able to work with OpenVPN.
*SOCKS5, HTTP, UDP Proxies in OpenVPN*
<https://www.proxyfella.com/2024/11/30/socks5-http-udp-proxies-in-openvpn/>

Each operating system requires DIFFERENT commands to solve these issues.
For example, "ip-win32 adaptive" is a Windows-only OpenVPN directive.

Linux-based operating systems work better than Windows, where, for example,
on Android, Psiphon's tunneling is more complete (TCP + UDP), but Windows support is limited such that some users have resorted to using dns2socks
for DNS resolution (but this has its own inherent problems as noted here).
*psiphon-tun2socks*
<https://github.com/Nebula-Mechanica/psiphon-tun2socks>

Windows is just a lousy platform for networking, it turns out, where, for example, I had to extensively modify Windows just to make it work well.
a. I had to sync WinINET & static WinHTTP proxy settings
b. I had to set AutoConfigURL and AutoDetect registry keys
c. I had to set the PAC file using the Windows registry
d. I had to sync PAC from file:///C:/data/sys/batch/proxy.pac
e. I had to run Mongoose to serve PAC at http://127.0.0.1/proxy.pac
f. I had to route other traffic via SOCKS 127.0.0.1:1080
g. And even then, WinHTTP can't use PAC or SOCKS, so I have to fix that
etc.

Basically, Windows sucks as these things, but one by one we can work around them, which is what the set of files I posted in this thread purport to do.
1. Win+R > psiphon.bat (this starts Psiphon SOCKS5 & syncs the above)
2. Win+R > pb.bat (this starts ProxyBridge which reads in rules.txt)
3. rules.txt (this tells ProxyBridge what to send thru the socks proxy)
4. pac.cmd (this sets a registry key to point to the PAC file)
5. proxy.pac (this sets PAC rules of what domains to skip proxy)
6. launchmongoose.vbs (this locally serves proxy.pac as http & https)
7. Win+R > psiphonstop.bat (this gracefully undoes all of the above setup)

This is a general purpose solution in that it uses 100% freeware so anyone
can run all of the above without cost simply by installing the software.
1. OpenVPN freeware + freely available UDP/TCP OpenVPN config files
2. Psiphon freeware + scripts to sync WinINET + WinHTTP + PAC files
3. ProxyBridge freeware + scripts to add missing rules.txt functionality
4. Mongoose freeware + scripts to serve the localhost PAC file as HTTPS

In summary, this is a complete DIY proxy + VPN system for all Windows executables (whether or not they inherently work with SOCKS5 proxies),
but even now, WinHTTP apps (e.g., Windows update) do not use PAC/SOCKS
and will and will connect directly unless I add something like Polipo.

What I conclude, personally, from this endeavor, is that while everything
you want to accomplish can be done with effort, Windows sucks at this type
of networking. It would have been much easier to do on a Linux-based PC.
--
Everything is possible if you're intelligent, but it's not always worth it.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

README.TXT 20251202
===========

Overview
This directory contains scripts and configuration files that work
together to launch, manage and stop a Psiphon based SOCKS5 proxy
environment on Windows. The setup uses Mongoose to serve a PAC file,
batch scripts to apply and reset proxy settings, ProxyBridge to enforce
process specific rules, and supporting files to control behavior. The
goal is to route browser and selected application traffic through
Psiphon while leaving system services and critical networking functions
direct.

Files
-----

psiphon.bat
This batch script launches Mongoose to serve proxy.pac, verifies
availability of the PAC file, then launches Psiphon in SOCKS mode. It
applies PAC logic to WinINET applications such as browsers, forces
registry keys to persist AutoConfigURL and AutoDetect, and syncs WinINET
proxy settings into WinHTTP. It logs activity to proxy.log. It warns
that WinHTTP applications such as Windows Update do not honor PAC or
SOCKS. It suggests using Privoxy or Polipo to bridge SOCKS to HTTP if
WinHTTP apps must be tunneled.

launchmongoose.vbs
This VBScript starts mongoose.exe silently if not already running. It
serves proxy.pac at http://127.0.0.1/proxy.pac. It logs launch attempts
to mongoose.log. It ensures the working directory is set so proxy.pac is
served correctly. It includes tutorial comments for loading PAC files
directly into Firefox using file:/// URLs. It notes that WPAD auto
discovery requires the file to be named wpad.dat and served at
http://wpad.domain/wpad.dat. Localhost proxy.pac works only with manual
configuration.

proxy.pac
This PAC file defines proxy rules. It bypasses Gmail, Google, Amazon,
and Copilot domains with DIRECT connections. All other traffic is routed
through SOCKS 127.0.0.1:1080. This works for WinINET based applications
such as Chrome, Edge, and IE. WinHTTP applications ignore PAC and SOCKS.
The file includes version history and comments explaining split tunnel
behavior. It notes that WPAD clients expect wpad.dat not proxy.pac.

pac.cmd
This script is a helper called automatically from psiphon.bat. It
enforces PAC logic silently. It logs its run, detects if it was called
from psiphon.bat, and then calls proxy.cmd to perform actual
configuration. It checks current PAC URL and AutoDetect status, applies
changes if needed, forces registry keys, and re captures status for
display. It ensures that proxy.cmd reflects correct status immediately.
It is a wrapper around proxy.cmd designed for automation.

proxy.cmd
This script is the diagnostic and configuration tool for proxy settings.
It can be run directly by the user or indirectly by pac.cmd. It supports
flags such as /help, /sync, /nopac, /status, /reset, /silent, or a PAC
URL. It manipulates registry keys under HKCU\Software\Microsoft\Windows\
CurrentVersion\Internet Settings. It can set or clear PAC URLs, enable
or disable AutoDetect, enable or disable static proxy servers. It syncs
WinINET into WinHTTP if needed. It displays detailed status of WinINET,
WinHTTP, and PAC configuration. It logs every invocation to proxy.log.
It is the heavy duty tool that pac.cmd relies on.

psiphonstop.bat
This batch script stops Psiphon and Mongoose if running, resets WinINET
and WinHTTP proxy settings, flushes DNS, resets IP stack, and attempts
Winsock reset with retry logic. It logs shutdown events to proxy.log and
mongoose.log. It exports registry keys before deletion for backup. It
sets ProxyEnable to 0 to force direct access. It clears ProxyOverride.
It resets WinHTTP proxy with netsh winhttp reset proxy. It checks Wi Fi
adapter state before Winsock reset. It logs environment proxy variables.
It reminds the user to clear browser cache and disable proxy extensions.
It ends with a beep to signal completion.

pb.bat
This batch script launches ProxyBridge CLI with rules defined in
rules.txt. It checks for administrator privileges, sets up logging,
reads rules.txt, strips comments, builds arguments, and runs ProxyBridge.
It ensures only one console window is used and that Ctrl+C stops
ProxyBridge cleanly. It logs output to timestamped files. It is designed
to enforce process specific proxy rules using Psiphon or Tor SOCKS5
listeners. It is a wrapper around ProxyBridge CLI for usability and
persistence.

rules.txt
This file defines ProxyBridge rules. It sets Psiphon SOCKS5 at
127.0.0.1:1080 as the default proxy. It forces browsers such as Brave,
Chrome, and Firefox to use the proxy for TCP traffic and blocks UDP
QUIC. It blocks telemetry processes such as OneDrive and CompatTelRunner.
It bypasses core system processes such as svchost.exe, services.exe, and
system to ensure DNS, DHCP, ARP, and TAP setup traffic go direct. It
proxies OpenVPN TCP 443 traffic through Psiphon but allows UDP tunnel
traffic direct. It logs at verbose level 3. It notes that UDP based VPN
configs must run direct without Psiphon.

Note that VPN can be run either before or after ProxyBridge now, i.e.,
VPN + {Psiphon/SOCKS5 + ProxyBridge/rules.txt} always worked fine
{Psiphon/SOCKS5 + ProxyBridge/rules.ext} + VPN now also works fine

Behavior Summary
----------------
Browsers using WinINET such as Chrome, Edge, IE, and Opera will honor
proxy.pac and route traffic through Psiphon SOCKS except for domains
explicitly bypassed. Firefox requires manual configuration or use of
system proxy settings. WinHTTP applications such as Windows Update and
Microsoft Store do not honor PAC or SOCKS and will connect direct unless
an HTTP to SOCKS bridge is used. Command line tools (such as curl and git)
ignore WinINET PAC unless configured with environment variables.
ProxyBridge enforces process specific rules to ensure selected apps are
tunneled while system services remain direct.

Limitations
-----------
WinHTTP does not support PAC or SOCKS. Windows Update and other system
services will not use Psiphon under this setup. UDP traffic cannot be
proxied through Psiphon SOCKS. WPAD auto discovery requires wpad.dat
served at http://wpad.domain/wpad.dat. Localhost proxy.pac works only
with manual configuration. Environment variables such as HTTP_PROXY may
still affect command line tools unless cleared. ProxyBridge rules must
explicitly list each application to be tunneled. Applications not listed
will connect direct.

Conclusion
----------
This environment provides a controlled way to route browser and selected
application traffic through Psiphon while leaving system services direct.
It uses Mongoose to serve PAC, batch scripts pac.cmd and proxy.cmd to
apply and reset proxy settings, and ProxyBridge with rules.txt to enforce
process specific behavior. For full coverage, including WinHTTP programs,
an HTTP to SOCKS bridge (such as Privoxy or Polipo) is likely required.
--- Synchronet 3.21a-Linux NewsLink 1.2