Bug: Tunnel goes silent ~3.5 min after session start, all streams time out at once

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).