[Bug]: Rules only start working after manually clicking “Test Proxy Connection”

[mehradhm1]

Platform

Windows

ProxyBridge Version

3.2.0

OS and Version

Windows 11

Documentation

• I have read the Windows documentation
• I have read the macOS documentation
• I have read the Linux documentation

Code Review

• I have gone through the code page

Describe the Bug

Hi,

First of all, thank you for ProxyBridge. It is a very useful tool, especially because it provides free per-process proxy routing on Windows.

I found a possible bug or usability issue in the Proxy Settings behavior.

Current behavior:
After setting the proxy as:

Proxy Type: SOCKS5
Proxy IP Address: localhost / 127.0.0.1
Proxy Port: 10808

the routing rules do not start working properly until I manually open the Proxy Settings page and click “Test Proxy Connection”.

After clicking “Test Proxy Connection”, the rules start working as expected.

Expected behavior:
ProxyBridge should initialize and apply the configured proxy automatically on startup, or at least immediately after pressing “Save Changes”, without requiring the user to manually click “Test Proxy Connection” every time.

My setup:

• Windows 11
• ProxyBridge on Windows
• Local SOCKS5 proxy: 127.0.0.1:10808
• Backend proxy app: v2rayN / Xray
• Proxy type: SOCKS5
• No username/password

Observed issue:
Rules are visible and saved, but traffic remains Direct or rules do not behave correctly until the proxy test button is clicked manually.

Possible cause:
It seems that the “Test Proxy Connection” button may be triggering some proxy initialization or refresh logic that is not being triggered on application startup or after saving settings.

Suggested fix:
Please consider calling the same proxy initialization/reload logic used by “Test Proxy Connection” automatically when:

1. The app starts
2. Proxy settings are saved
3. Routing rules are applied or changed

This would make ProxyBridge much more reliable for automatic startup usage.

Thanks again for the great work.

Additional Context

No response

[Anof-cyber]

Its not a valid bug. Its expected and nothing to do with test connection.

Only new tcp handshake connection are forwarded to proxy. It an app has tcp session alive before ProxyBridge rules added. It will stay as direct connection as redirecting existing connection will break the connection and add packet loss and delay.

[mehradhm1]

Thanks, but I don’t think this is caused by existing TCP sessions.

I tested after a full Windows restart, with the target apps not running before ProxyBridge started.

The startup log shows something important:

Configuration loaded successfully
DNS routing: via proxy
Localhost routing: direct
Failed to resolve hostname: localhost
UDP relay listening on port 34011
UDP ASSOCIATE not available yet - will retry when needed
Local proxy listening on port 34010
ProxyBridge started
Local relay: localhost:34010
SOCKS5 proxy: :0
No rules configured - all traffic will be direct
Added rule ID: 1 ...
Added rule ID: 2 ...
Added rule ID: 3 ...
Added rule ID: 4 ...
Added rule ID: 5 ...
Added rule ID: 6 ...

The important part is:

Failed to resolve hostname: localhost
SOCKS5 proxy: :0

So at startup, ProxyBridge is not loading or resolving the saved SOCKS5 proxy correctly. The saved proxy should be:

SOCKS5 127.0.0.1:10808 / localhost:10808

But the startup log shows it as:

SOCKS5 proxy: :0

This happens before any target application is launched, so it cannot be explained by existing TCP sessions.

Another important detail:
Even if I manually open Proxy Settings and click “Test Proxy Connection” and everything starts working correctly, if I close ProxyBridge completely and open it again, the same problem happens again. The proxy is not initialized correctly on startup until I manually click “Test Proxy Connection” again.

So this looks reproducible:

1. Start ProxyBridge
2. Saved proxy settings exist
3. Startup log shows SOCKS5 proxy: :0
4. Rules are loaded, but the proxy backend is not initialized correctly
5. Open Proxy Settings and click “Test Proxy Connection”
6. Proxy routing starts working correctly
7. Close ProxyBridge completely
8. Open ProxyBridge again
9. The same issue returns until “Test Proxy Connection” is clicked again

So the issue seems to be that the saved proxy settings are not fully initialized or resolved correctly on startup, especially when using “localhost” as the proxy host.

Could you please check why the startup initialization logs “SOCKS5 proxy: :0” even though the saved proxy settings contain localhost:10808?

A possible improvement would be to run the same proxy initialization or validation logic used by “Test Proxy Connection” automatically when ProxyBridge starts, or immediately after loading saved proxy settings.

I will also test with 127.0.0.1 instead of localhost to see if the issue is specifically related to resolving localhost.

[mehradhm1]

Update:

I changed the proxy host from localhost to 127.0.0.1 while keeping the same port 10808.

After this change, ProxyBridge initializes the SOCKS5 proxy correctly on startup and the rules start working without needing to click “Test Proxy Connection”.

Before, when using localhost, the startup log showed:

Failed to resolve hostname: localhost
SOCKS5 proxy: :0

After changing it to 127.0.0.1, startup works correctly:

Configuration loaded successfully
DNS routing: via proxy
Localhost routing: direct
Local proxy listening on port 34010
UDP ASSOCIATE established with SOCKS5 proxy
UDP relay listening on port 34011
ProxyBridge started
Local relay: localhost:34010
SOCKS5 proxy: 127.0.0.1:10808

So the issue seems related to resolving or initializing localhost during startup.

A possible fix could be to normalize localhost to 127.0.0.1 when loading saved proxy settings, or handle it as a special case instead of doing normal hostname resolution.

Also, ProxyBridge should probably not continue with an invalid proxy state like:

SOCKS5 proxy: :0

If resolving the saved proxy host fails, it should either retry, show a clear error, or keep the saved host/port instead of silently initializing as :0.

For now, using 127.0.0.1 instead of localhost works as a workaround.

[scotow]

I observe a similar behavior but with a DNS resolution error message (which seems to be related to one described here):

[01:40:41] Configuration loaded successfully
[01:40:41] DNS routing: direct
[01:40:41] Localhost routing: direct (most proxies block localhost for SSRF prevention)
[01:40:41] Failed to resolve hostname: [REDACTED]

Like @mehradhm1, opening the proxy config window and clicking the "Test proxy button" fixes the issue until next startup of ProxyBridge.

[mehradhm1]

Thanks again for building and maintaining ProxyBridge. It is a really useful tool.

This seems to support the idea that the issue is not caused by existing TCP sessions.

The common behavior appears to be:

• ProxyBridge starts
• The saved proxy host fails to resolve or initialize
• Routing does not work correctly
• Opening Proxy Settings and clicking “Test Proxy Connection” fixes it until the next restart

So it looks like the Test Proxy button triggers some initialization or refresh logic that is not reliably triggered during startup.

In my case, replacing localhost with 127.0.0.1 fixed it.
Since this also happens with another hostname, it may be a more general startup DNS/proxy initialization issue.

[nuovomondocxs-star]

I'm having the same issue. After restarting ProxyBridge, all the rules stop working. I have to click Test Proxy Connection or Save Changes in Proxy Settings for the proxy rules to take effect again. I've checked my config.json and the contents are correct.

[Anof-cyber]

@scotow @mehradhm1 @nuovomondocxs-star - A new beta build is out with the reported issue fixed. You can download it and find more details here: #148

Let me know how it goes!