ProxyBridge v4.0.13 Beta - Windows Testers

🚀 ProxyBridge v4.0.13-Beta - Community Testing Requested

Hello everyone,

I'm excited to share ProxyBridge v4.0.13-Beta.

This beta contains a significant number of bug fixes, performance improvements, internal refactoring, and two major new features. Before releasing the stable version, I'd greatly appreciate the community's help testing it across different Windows versions, applications, and proxy configurations.

Download - ProxyBridge-Setup-4.0.13-Beta.zip

---

🧪 Community Testing Requested

This release has been thoroughly tested on my own systems and common day-to-day use cases. However, it has not yet been tested across the wide variety of environments and applications that the community uses.

If you have a few minutes, please download the beta and try your normal workflow.

I'm particularly interested in reports involving:

• 🐞 Bugs or crashes
• 🎨 UI issues
• ⚡ Performance regressions
• 🌐 Proxy routing problems
• 🖥️ Compatibility issues with applications
• 🔄 Anything that behaves differently from previous releases

Every report helps improve the quality and stability of the final v4.0.10 release.

---

Changes 4.0.11--> 4.0.12

• Fixed UI Issues
• Fixed Buffer Overflow in Profile
• Fixed Startup issue [Bug]: run at startup is not working in v4.0.11-beta #195
• Added multi-select in Process name for rules - [Feature]: Multi select #196

Changes 4.0.12--> 4.0.13

• Fixed Empty White Space - [Bug]: There is a unexpected white area in Proxy Rules table and other tables. #200
• Remove Schedule Task on uninstall - [Bug]: if I didn't uncheck the "run at startup" option before uninstalling, the startup task in Task Scheduler wouldn't be automatically deleted. #199
• Updated Installer to safely close the app on new install and run app post install - [Bug]: The ProxyBridge process was not closed during uninstallation, and the files were not deleted. These files were only deleted after I restarted Windows. #198
• Installer now remove old leftover C# DLL files

✨ Major Changes

🌐 Domain Name Support in Proxy Rules

Proxy rules can now match domain names in addition to IP addresses and ports.

Examples:

• *.github.com
• api.example.com
• *.company.local

This allows much more flexible and granular proxy routing without relying solely on IP addresses.

---

🖥️ Complete Native Windows GUI Rewrite

The Windows GUI has been completely rewritten from scratch.

The previous GUI was built using C# + Avalonia. The new GUI is written entirely in native C using the Windows API, with no GUI frameworks or rendering libraries.

What's new

• ✅ Native Win32 GUI
• ✅ Written entirely in C
• ✅ No Avalonia
• ✅ No SkiaSharp
• ✅ No .NET runtime
• ✅ No third-party GUI framework
• ✅ Native Windows controls
• ✅ Lower resource usage
• ✅ Faster startup

AI-Assisted Development

The initial implementation of the GUI rewrite was generated using Claude Code.

After the initial implementation, the code was manually:

• Reviewed
• Refactored
• Optimized
• Debugged
• Security reviewed
• Performance optimized
• Integrated with the existing ProxyBridge codebase

While AI significantly accelerated the initial implementation, the final result has undergone extensive manual review, testing, and refinement before this beta release.

---

📊 Performance Improvements

The native GUI rewrite resulted in significant reductions in binary size, memory usage, startup time, and CPU usage.

Binary Size

Previous GUI

The previous GUI required multiple runtime libraries:

• ProxyBridge.exe (ProxyBridge GUI + .Net Runtime)
• libSkiaSharp.dll
• av_libglesv2.dll
• libHarfBuzzSharp.dll

New GUI

The GUI is now a single native Windows executable.

Component	Previous	New	Improvement
Windows GUI (EXE + GUI runtime libraries)	43.4 MB	501 KB	~98.9% smaller
Installer	11.8 MB	745 KB	~94% smaller

This removes the dependency on Avalonia, SkiaSharp, HarfBuzz, OpenGL rendering libraries, and the .NET runtime.

---

Memory Usage

Based on testing performed so far:

Startup

Previous	New
~40 MB	~2–3 MB

~94% reduction in startup memory usage

During Usage

Previous GUI:

• Typically increased to 100–140 MB
• Memory usage often continued growing over time

New native GUI:

• Peaks at approximately 30 MB during testing
• Improved caching and memory management
• Frees temporary allocations more aggressively
• Returns to approximately 2–5 MB after activity
• Can idle at around 1 MB

---

CPU Usage

Testing performed so far shows:

Previous GUI:

• Commonly used 3–10% CPU during normal operation and idle periods.

New native GUI:

• Approximately 40–55% lower CPU usage in the workloads tested so far.

Performance testing will continue before the stable release across a wider range of systems.

---

Additional Benefits

• ✅ Native Win32 rendering
• ✅ Faster startup
• ✅ Significantly lower memory usage
• ✅ Reduced CPU usage
• ✅ Smaller installer
• ✅ Smaller binaries
• ✅ Fewer runtime dependencies
• ✅ No .NET runtime
• ✅ No Avalonia runtime
• ✅ No SkiaSharp rendering engine
• ✅ No HarfBuzz dependency
• ✅ Simpler deployment

---

🔧 Other Improvements

In addition to the major changes above, this release also includes numerous:

• Bug fixes
• Performance improvements
• Stability improvements
• Internal refactoring
• Memory optimizations
• Code cleanup

---

⚠️ Beta Notice

Although this release has undergone extensive manual review and testing, it is still a beta release.

There may still be edge cases or compatibility issues that haven't yet been discovered.

If you encounter any issues, please include:

• Windows version
• ProxyBridge version
• Steps to reproduce
• Screenshots (if applicable)
• Logs (if applicable)

Every report helps improve the final release.

Thank you to everyone willing to test ProxyBridge v4.0.1w-Beta and provide feedback! ❤️

[leic4u]

This is a groundbreaking version!

I submitted an issue for UX improvement. #192

Looking forward to the official release of this version soon.🎉🎉🎉

[Anof-cyber]

This is fixed in the new 4.0.11-Beta

[laveta331-jpg]

There is a persistent error message, but it doesn't affect usage.

[Anof-cyber]

This is fixed in 4.0.11-beta versio if you can give a try

[laveta331-jpg]

The proxy forwarding issue is even worse in this version, while it is usable, it is highly unstable.
Forwarding failures occur even during normal use, and I have to restart the software to get it working again.
There is no data logged in the activity logs or network connections—it’s as if the connection suddenly drops

[leic4u]

Version 4.0.11-beta appears to have a serious traffic forwarding issue. My configured rules are working, but it seems they aren't fully capturing traffic connections initiated by other applications. Spark Mail fails to connect when using v4.0.11-beta, but Proxifier works without problems. Unfortunately, I can no longer download v4.0.10-beta, so I can't verify if this is a new issue introduced in v4.0.11-beta.

[Anof-cyber]

https://github.com/user-attachments/files/29671498/ProxyBridge-Setup-4.0.10-Beta.zip

Can you check 0.10

[leic4u]

Can you check 0.10

0.10 works well. my Spark mail client is working in 0.10-beta. for serious test, I tried to update to 0.11 again, and I find that 0.11 is working now. I don't know what happened. maybe it's my mistake.

I will continue to report the problems I encounter when using version 0.11. For now, you can ignore the issue I raised just now.

[WvvvWv]

I am using version 4.0.13, and it seems there is an issue with GUI scaling. In the first image, the log lines remain very small even after manually resizing the GUI window; the second image shows the size immediately after the software launches (with Chrome in the background). My laptop has a 14-inch screen with a resolution of 3072x1920.

[Anof-cyber]

I am able to get your point. 2nd image i got its default window size of the app.
Whats the issue with that or after increasing the windows size or full screen?

[WvvvWv]

Is it a bug that the content area of ​​the first image doesn't scale up along with the window?

Is the startup window for the second image application too small? Have you considered reverting to the window size used in version 4.0 or 3.x?

[Anof-cyber]

You mean with window size is increased text size should be increased?

[WvvvWv]

You mean with window size is increased text size should be increased?

yes

[leic4u]

You mean with window size is increased text size should be increased?

Or provide a setting item, to allow users setting the GUI's font size by themselves, including the window font and the logs font.

[CxJuice]

I encountered the same issue as #183 in v4.0 and v4.0.12-Beta, but not in v4.0.7. It seems that this issue has returned.
No screen lock, sleep, or network change is required. Simply leaving ProxyBridge running for some time is enough. New connections may stop being forwarded or stop appearing in the logs, and restarting ProxyBridge restores normal operation.
A possible fix is to fully clear old connection and routing cache state when a new TCP connection starts, and ensure stale connection cleanup also clears the related routing cache.

[leic4u]

I have the same issue like CxJuice. After running for several hours, ProxyBridge becomes unstable. At first, I thought it was a problem with my proxy, but other programs that connect directly to the proxy work fine. However, programs that connect to the proxy through ProxyBridge become unable to connect until I restart ProxyBridge.

In the unstable time, the connection logs were listed as normal, but these listed programs can't connect with proxy.

My proxy is a socks5&http inbound proxy, and I use socks5 in ProxyBridge.

[leic4u]

I tested this issue for a day. I ran ProxyBridge from 11:00 am, and only spark mail became disconnected after seaveral hours(I don't know the disconnected time exactly, I only checked these apps at second day 0:45 am and 2:25 am, sparkmail both was disconnected). The Telegram and the system webview2 are working correctly. maybe you can reproduce this issue in discord or sparkmail.

[leic4u]

Telegram also has issues, messages can be received correctly, but images cannot be opened.

[leic4u]

The telegram images were opened after a long time.

I am thinking about maybe ProxyBridge became too slow after running sevral hours, so it looks like the connection has dropped.

[steveepreston]

Reported the similar ciritical bug in connections here: #205

[steveepreston]

If possible please push beta versions in https://github.com/InterceptSuite/ProxyBridge/releases too
i missed these versions

[steveepreston]

oh, good, btw i saw too many good things in the new beta version

[Anof-cyber]

Its gui is rewritten from scratch thanks to claude who did most of the initial rewrite in just couple of hours. I didn't expect cluade to write C with this efficiency.

[steveepreston]

@Anof-cyber Great! Toolbar UI needs a little improve.

The best thing is that i now see domain-based rules! ❤️

[Anof-cyber]

Can you provide more info for tool bar?

[steveepreston]

@Anof-cyber i already posted in #102 (comment)
here is the simple proposal image:

[dentatli]

Update: I believe I have identified a likely root cause and tested a fix for the UDP connection failures discussed here.

The detailed investigation, diagnostic logs, deterministic A/B tests, and proposed fixes are documented in issue #183.

In short, after recreating a SOCKS5 UDP ASSOCIATE, ProxyBridge could continue using the "fd_set" returned by "select()" for the old sockets. Windows may immediately reuse a closed "SOCKET" value for a newly created UDP socket, causing the stale "fd_set" to report false readiness. ProxyBridge would then call "recvfrom()" on the new socket and could receive "WSAEINVAL 10022", closing an otherwise valid new association.

Two affected paths were found and fixed:

• recreation after the TCP control socket is closed;
• recreation after a failed UDP "sendto()".

The fix starts a new relay-loop iteration after association sockets are replaced, so "read_fds" is rebuilt before the new sockets are inspected.

The dangerous socket-reuse condition was reproduced in diagnostic tests. With the patched build, the stale readiness result was discarded, and extended testing with Discord voice and screen streaming completed without error "10022", UDP relay stalls, or visible interruptions.

The fixes are tested but have not yet been reviewed or merged by the maintainer.

[steveepreston]

#183 title is [Bug]: The connection drops after the screen has been locked for a period of time.
But i have connection miss from the start.
when i open it, it's missing some connection to do proxy. after some restart sometimes works. but it's clear that it has bug in connections handling.

[dentatli]

#183 title is [Bug]: The connection drops after the screen has been locked for a period of time. But i have connection miss from the start. when i open it, it's missing some connection to do proxy. after some restart sometimes works. but it's clear that it has bug in connections handling.

Thanks — that sounds different from the stale fd_set issue in #183.

The fd_set defect specifically affects a SOCKS5 UDP association after its sockets are recreated. It can explain UDP failures or stalls after a reconnect, but it does not necessarily explain connections being missed immediately after startup.

During a separate investigation, I reproduced another connection-handling defect that may be closer to what you are seeing.

On Windows, ProxyBridge currently identifies tracked connections primarily by the numeric local source port. A UDP socket and a TCP socket can legally use the same numeric port.

In a deterministic test:

• UDP created a tracked entry for local port 55123;
• a fresh TCP connection then used the same local port;
• ProxyBridge matched the TCP SYN to the existing UDP entry;
• process-rule lookup was skipped;
• the connection was sent through the tracked-redirect path instead of being evaluated as a new TCP flow.

The internal diagnostic log showed:

request_protocol=TCP
matched_protocol=UDP
protocol_collision=1
destination_collision=1
actual_path=TRACKED_REDIRECT
rule_lookup_called=0

The expected TCP connection to port 41002 then timed out, while the UDP endpoint on port 41001 had already been reached successfully.

The same source-port-only lookup is also used by the TCP relay. Therefore, if the redirected TCP connection is accepted by the relay, it can select destination metadata belonging to the UDP entry.

This defect can occur immediately after startup, affect only some connections, and appear to disappear after a restart because the connection table is cleared and Windows may allocate ephemeral ports differently.

I am currently testing a fix that keys connection entries by:

protocol + address family + original local source address + source port

I cannot yet confirm that this is the exact cause of your case, but your symptoms are consistent with this defect.

[dentatli]

I am currently testing the proposed fix for any measurable impact on network latency and overall performance, while also reviewing the implementation for possible optimization. The goal is to ensure that the connection-table collisions are eliminated without introducing meaningful regressions in latency, throughput, CPU usage, or packet loss.

[tylerblc]

This app doesn't work for me. But I'm entirely new to this app so I'm not sure if I'm doing something wrong. I'm on Windows 10 Enterprise IoT 2021 running in VMware workstation. The box has a VPN active and I am trying to redirect the web browser (MS Edge) through a proxy on the local network. The connection log says msedge.exe is being routed through the proxy IP, but pulling up a web page in Edge has the page time out. I also have a desktop firewall active which complicates things. But if I completely take down the firewall, the issue persists. If I disable the forwarding rule or exit ProxyBridge, connecting with MS Edge immediately works.

As a point of reference, I tried the same exact scenario with the same configuration steps in the other well known app in this space and it worked out of the box, with the exiting IP verified.

Sorry I don't have any more specific information to offer. I'm willing to run a debug version of the app with full logging if it would be helpful.