[Bug]: Connections log misses many connections (TCP and UDP)

[steveepreston]

Platform

Windows

ProxyBridge Version

4.0.13-Beta

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

ProxyBridge does not detect/list all connections in the Connections log section. A significant portion of real network activity never appears there — sometimes an app generates many requests and none of them show up, sometimes only some of them do. The gap is large and easily visible, not an occasional missed edge case.

Some important observations to narrow it down:

• It is not a rules problem. This happens regardless of whether a rule is applied or not. ProxyBridge does list DIRECT (non-matched) connections in the log, so unmatched traffic should appear — yet it's clearly visible that many connections are simply never listed at all.
• It is not limited to UDP. TCP connections are also missing from the log. So this can't be explained by UDP flow-tracking quirks alone.
• Comparison with Proxifier is dramatic. With Proxifier's Handle Direct Connections enabled, its Connections view instantly shows a mass of connections — every single connection, almost "spammy" (which means it's working correctly, that's the real amount of traffic a modern system generates). ProxyBridge on the same machine, same apps, shows very, very few entries in comparison. The difference is not subtle.
• Clean test environment. Proxifier was completely OFF while testing ProxyBridge, so this is not a driver/interception conflict between the two.

Steps to reproduce:

1. Start ProxyBridge (GUI, Administrator), no log filters configured. Rules don't matter — with or without, same result. IsTrafficLoggingEnabled is on.
2. Open the Connections log section.
3. Launch a network-active target app (e.g. a browser or any chatty app.exe) and let it send many requests.
4. Observe the Connections log.
5. (Optional, for comparison) Close ProxyBridge, run Proxifier with Handle Direct Connections enabled, launch the same app, and compare the volume of listed connections.

Expected behavior: every connection that WinDivert intercepts and ProxyBridge processes (PROXY, DIRECT, BLOCK, or no-match) is listed in the Connections log — matching the "Monitor all TCP and UDP connections system-wide" description in the Windows README.

Actual behavior: only a fraction of connections appear. Sometimes a burst of activity from an app produces zero entries; sometimes only some of its connections are logged. Both TCP and UDP are affected.

Additional Context

Possibly related: #155 was a different symptom (connections logged but traffic broken), but the maintainer noted it was "caused by change in relay and DNS because of which packets are dropped" in the v4 relay rework. If packets can be silently dropped/missed in that path, the same plumbing could plausibly cause connections to be silently unlogged here. Mentioning it in case the root cause overlaps; I searched the tracker and found no existing issue about incomplete connection listing itself.

Some hypotheses for where connections could be lost, based on going through the code and docs (take these as guesses to check, not conclusions):

• The Connections log seems to be fed by a one-shot connection event when a new flow is first detected. If the first packet of a flow is missed (WinDivert queue pressure under burst, timing at startup), the whole connection stays invisible forever — there's no later chance to log it.
• Connections already established before ProxyBridge starts would never produce a "new flow" event and thus never appear.
• Reused sockets / keep-alive connections and rapid reconnects might be deduplicated or matched to an existing flow entry instead of being logged again.
• WinDivert handle parameters (queue length/time) under bursty traffic could cause missed packets specifically during the high-activity moments where the gap is most visible.
• The v4.0.0 log-filter engine ([Feature]: Hide/Show Direct Connection in Traffic Logging #97/[Feature]: Implement process-specific log filtering to reduce noise #150) filtering more than intended — though in my tests no filters were configured, so if it's this, it would be default-state filtering.

Happy to provide side-by-side screenshots/recordings of ProxyBridge vs Proxifier on the same workload, my profile export, or to test debug builds.

[Anof-cyber]

I don't think its an issue. Its by design. The app only log initial tcp syn not all packets like wireshark :)

App doesn't track or keep looking for each new packet that will cost alot of cpu memory and will increase network delay and network speed by alot.

[steveepreston]

This got closed on a misreading, so let me state it as precisely as I can.

I am not asking to log every packet like Wireshark. I'm counting exactly what you say the app logs: one entry per new connection (initial TCP SYN). By your own design description, if an app opens 50 new TCP sessions, the log should show 50 rows. It shows far fewer - sometimes zero. These are fresh sessions from a freshly launched app, not reuse of a keep-alive session.

And that's why this is not a cosmetic log issue. The log entry and the rule evaluation are fed by the same event: catching the SYN. If the SYN never produced a log row, it also never went through the rule engine - which means that connection was never proxied/blocked and went out DIRECT, silently. In other words: the missing log rows are just the visible symptom that ProxyBridge is failing to intercept a large fraction of new connections. The app's core function - routing - is not being applied to them.

I can demonstrate it without any packet capture:

1. Fresh boot, start ProxyBridge with a rule app.exe → proxy, my proxy server logging all inbound client connections.
2. Launch the app; it establishes N new TCP sessions (verifiable with netstat / Get-NetTCPConnection timestamps - all new, no reuse).
3. Result: the proxy server receives connections for only a subset of those sessions. The rest reach their destinations directly, and those same missing sessions are exactly the ones with no row in the Connections log.

If interception were complete, step 3 is impossible regardless of any logging design decision. A connection that bypasses the rule it matches is a bug in a traffic-routing app by any definition.

Could you reopen this? I'm fine renaming it to "New connections not intercepted (rules not applied); log rows missing as a symptom" since the original title undersold it. Happy to provide side-by-side proxy-server logs + netstat + ProxyBridge log on the same workload, or run a debug build.

[hishtadlut]

I reproduced this as an actual traffic-routing bypass, not only a logging issue.

Environment

• Windows 11 Home, version 10.0.26200
• ProxyBridge 4.0.0 stable
• ProxyBridge CLI using a .pbprofile
• SOCKS5 proxy: 127.0.0.1:1087
• Profile contains an enabled *:*:*:TCP:PROXY equivalent rule
• The proxy host is an IP address, not localhost

Observed behavior

ProxyBridge initially worked correctly. After approximately four hours of normal system traffic:

• ProxyBridge_CLI.exe was still running and responsive.
• The WinDivert driver was still in the Running state.
• The SOCKS5 server was healthy.
• No ProxyBridge crash or WinDivert unload was recorded in Windows Event Viewer.
• However, newly created TCP connections silently bypassed ProxyBridge and used the direct ISP connection.

I confirmed this using a fresh curl.exe process:

curl.exe -4 https://api.ipify.org

Result: the direct ISP public IP.

The same request explicitly using the configured SOCKS server:

curl.exe -4 --socks5-hostname 127.0.0.1:1087 https://api.ipify.org

Result: the expected VPS/proxy public IP.

This was a newly launched process and a new TCP connection, so it was not an existing session established before ProxyBridge started.

Restarting only ProxyBridge_CLI.exe, without restarting the SSH/SOCKS tunnel, immediately restored transparent routing:

Transparent request: VPS/proxy IP
Explicit SOCKS request: VPS/proxy IP

Impact

The bypass is fail-open: traffic that should have been proxied escaped through the local ISP. In this case, a WebSocket request to:

wss://chatgpt.com/backend-api/codex/responses

reached the local filtering provider and returned its HTTP 418 block page. After restarting ProxyBridge, the same endpoint reached the actual service correctly.

This supports the report that missed connection events also mean missed rule evaluation and direct traffic leakage. Please consider reopening this issue and treating it as a routing/privacy problem rather than only a connection-log problem.

I can run a debug build or collect verbose logs if you provide the required logging procedure.

[steveepreston]

@Anof-cyber Can you re-open this please?
or due misunderstanding about word log in issue title, need creating another?

[dentatli]

@Anof-cyber Can you re-open this please?
or due misunderstanding about word log in issue title, need creating another?

Check #206.

[steveepreston]

@dentatli Thanks. are you sure it matches this issue? or it's another bug?

[dentatli]

A separate deterministic routing defect is now tracked in #209.

In a controlled Windows test, an existing UDP entry and a fresh TCP SYN used the same numeric local source port. The TCP SYN was matched to the UDP record, process/rule lookup was skipped, and the packet entered TRACKED_REDIRECT:

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

This may explain some missed-rule or missing-connection symptoms, but it is not claimed as the root cause of every case reported here. It is also independent of the stale decision-bitmap defect in #206.