Setup: Server on Docker (ghcr.io/masterking32/masterdnsvpn:v2026.06.13.234407-7de2476, Linux), client on Windows (v2026.05.10.180256-27c7e11), SOCKS5 mode.
Symptom: After session init, the first 1–3 SOCKS5 CONNECTs succeed normally. All CONNECTs after that get no response — no error, just silence — and the browser eventually shows ERR_NETWORK_CHANGED. About 3.5 minutes later, the client force-closes every pending stream almost simultaneously:
ARQ Stream Closed | ... Reason: Terminal ACK wait timeout | PriorReason: Packet TTL expired ... Since: lastActivity=3m30.xxx
The near-identical lastActivity timestamps across streams suggest the return path (server→client responses) got cut off at one specific moment, rather than degrading gradually.
Ruled out:
Reproduced with single resolver (8.8.8.8 alone) and with multiple (8.8.8.8, 9.9.9.9, 4.2.2.4)
Reproduced with both XOR and ChaCha20 encryption
Server-side logs show nothing unusual; port 53 open and DNS delegation verified working (dig) throughout
Not a Windows/browser network issue — only happens while connected to the tunnel's SOCKS5 proxy
Suspicion: Looks like mid-session filtering on the network path silently dropping tunnel responses after an initial grace period — but flagging here in case it's actually a session/ARQ-layer issue.
Logs attached: client.log (multi-resolver, XOR), client-8.8.8.8.log (single resolver, XOR), client_ChaCha20.log (single resolver, ChaCha20 — contains the ARQ Stream Closed sequence).
Setup: Server on Docker (ghcr.io/masterking32/masterdnsvpn:v2026.06.13.234407-7de2476, Linux), client on Windows (v2026.05.10.180256-27c7e11), SOCKS5 mode.
Symptom: After session init, the first 1–3 SOCKS5 CONNECTs succeed normally. All CONNECTs after that get no response — no error, just silence — and the browser eventually shows ERR_NETWORK_CHANGED. About 3.5 minutes later, the client force-closes every pending stream almost simultaneously:
ARQ Stream Closed | ... Reason: Terminal ACK wait timeout | PriorReason: Packet TTL expired ... Since: lastActivity=3m30.xxx
The near-identical lastActivity timestamps across streams suggest the return path (server→client responses) got cut off at one specific moment, rather than degrading gradually.
Ruled out:
Reproduced with single resolver (8.8.8.8 alone) and with multiple (8.8.8.8, 9.9.9.9, 4.2.2.4)
Reproduced with both XOR and ChaCha20 encryption
Server-side logs show nothing unusual; port 53 open and DNS delegation verified working (dig) throughout
Not a Windows/browser network issue — only happens while connected to the tunnel's SOCKS5 proxy
Suspicion: Looks like mid-session filtering on the network path silently dropping tunnel responses after an initial grace period — but flagging here in case it's actually a session/ARQ-layer issue.
Logs attached: client.log (multi-resolver, XOR), client-8.8.8.8.log (single resolver, XOR), client_ChaCha20.log (single resolver, ChaCha20 — contains the ARQ Stream Closed sequence).