Client loses UDP sessions over long uptime

[NitroOxid]

Environment

TUIC version: 1.8.4
Client: tuic-client
Server: tuic-server
OS: OpenWRT 25.12.4

Client entry point: local SOCKS5 (ProxiFyre → tuic-client)
Note: SOCKS5 is only used as traffic ingress; issue appears in TUIC UDP relay layer.

Description

The connection works normally after startup.

After ~10–12 hours of uptime, UDP reception starts failing intermittently.
The frequency increases over time.

After ~30 hours, RX failures occur approximately every ~5 minutes.
TX remains fully functional throughout the entire period.

The issue is strictly asymmetric:

• Outgoing traffic (TX) remains stable
• Incoming traffic (RX) progressively degrades

Restarting the client immediately restores full functionality.

Observed behavior

• TX (client → server) remains stable at all times
• RX (server → client) progressively degrades over uptime
• Discord voice/video stops receiving data while sending still works
• Game traffic stops receiving server updates but continues sending
• Issue frequency increases non-linearly with uptime
• Eventually becomes periodic (~every 5 minutes after ~30h)

Logs

Logs indicate UDP session mapping loss followed by SOCKS UDP associate failure and panic:

[26 may 2026 y., 23:39:49 GMT+3] daemon.info: tuic-client[15418]: �[2m26-05-26 23:39:49�[0m �[33m WARN�[0m �[2mtuic_client::connection::handle_task�[0m�[2m:�[0m [relay] [packet] [0x0909] [from-native] [0x0589] unable to find UDP session
[26 may 2026 y., 23:39:49 GMT+3] daemon.info: tuic-client[15418]: �[2m26-05-26 23:39:49�[0m �[33m WARN�[0m �[2mtuic_client::connection::handle_task�[0m�[2m:�[0m [relay] [packet] [0x0909] [from-native] [0x058a] unable to find UDP session
[26 may 2026 y., 23:39:49 GMT+3] daemon.info: tuic-client[15418]: �[2m26-05-26 23:39:49�[0m �[33m WARN�[0m �[2mtuic_client::connection::handle_task�[0m�[2m:�[0m [relay] [packet] [0x0909] [from-native] [0x058b] unable to find UDP session
[26 may 2026 y., 23:39:49 GMT+3] daemon.info: tuic-client[15418]: �[2m26-05-26 23:39:49�[0m �[33m WARN�[0m �[2mtuic_client::connection::handle_task�[0m�[2m:�[0m [relay] [packet] [0x0909] [from-native] [0x058c] unable to find UDP session
[26 may 2026 y., 23:39:49 GMT+3] daemon.info: tuic-client[15418]: �[2m26-05-26 23:39:49�[0m �[33m WARN�[0m �[2mtuic_client::connection::handle_task�[0m�[2m:�[0m [relay] [packet] [0x0909] [from-native] [0x058d] unable to find UDP session
[26 may 2026 y., 23:39:49 GMT+3] daemon.info: tuic-client[15418]: �[2m26-05-26 23:39:49�[0m �[33m WARN�[0m �[2mtuic_client::connection::handle_task�[0m�[2m:�[0m [relay] [packet] [0x0909] [from-native] [0x058e] unable to find UDP session
[26 may 2026 y., 23:39:49 GMT+3] daemon.info: tuic-client[15418]: �[2m26-05-26 23:39:49�[0m �[33m WARN�[0m �[2mtuic_client::connection::handle_task�[0m�[2m:�[0m [relay] [packet] [0x0909] [from-native] [0x058f] unable to find UDP session
[26 may 2026 y., 23:39:49 GMT+3] daemon.info: tuic-client[15418]: �[2m26-05-26 23:39:49�[0m �[33m WARN�[0m �[2mtuic_client::connection::handle_task�[0m�[2m:�[0m [relay] [packet] [0x0909] [from-native] [0x0590] unable to find UDP session
[26 may 2026 y., 23:39:49 GMT+3] daemon.info: tuic-client[15418]: �[2m26-05-26 23:39:49�[0m �[33m WARN�[0m �[2mtuic_client::connection::handle_task�[0m�[2m:�[0m [relay] [packet] [0x0909] [from-native] [0x0591] unable to find UDP session
[26 may 2026 y., 23:39:50 GMT+3] daemon.info: tuic-client[15418]: �[2m26-05-26 23:39:50�[0m �[33m WARN�[0m �[2mtuic_client::connection::handle_task�[0m�[2m:�[0m [relay] [packet] [0x0909] [from-native] [0x0592] unable to find UDP session
[26 may 2026 y., 23:39:55 GMT+3] daemon.info: tuic-client[15418]: �[2m26-05-26 23:39:55�[0m �[33m WARN�[0m �[2mtuic_client::socks5::handle_task�[0m�[2m:�[0m [socks5] [192.168.1.168:52110] [associate] [0x0097] associate connection error: Connection reset by peer (os error 104)
[26 may 2026 y., 23:39:55 GMT+3] daemon.err: tuic-client[15418]:
[26 may 2026 y., 23:39:55 GMT+3] daemon.err: tuic-client[15418]: thread 'main' (15418) panicked at tuic-client/src/socks5/handle_task.rs:104:65:
[26 may 2026 y., 23:39:55 GMT+3] daemon.err: tuic-client[15418]: called `Option::unwrap()` on a `None` value
[26 may 2026 y., 23:41:46 GMT+3] daemon.info: tuic-client[15418]: �[2m26-05-26 23:41:46�[0m �[33m WARN�[0m �[2mtuic_client::socks5::handle_task�[0m�[2m:�[0m [socks5] [192.168.1.168:52276] [associate] [0x05c5] associate connection error: Connection reset by peer (os error 104)
[26 may 2026 y., 23:41:56 GMT+3] daemon.info: tuic-client[15418]: �[2m26-05-26 23:41:56�[0m �[33m WARN�[0m �[2mtuic_client::socks5::handle_task�[0m�[2m:�[0m [socks5] [192.168.1.168:52300] [associate] [0x0279] associate connection error: Connection reset by peer (os error 104)

Reproduction steps

1. Start tuic-client
2. Route normal traffic (Discord + game traffic)
3. Keep connection alive for ~10–12 hours
4. Observe intermittent RX failures
5. After ~30 hours, RX failure becomes frequent (~5 min intervals)

Mitigation

• Restarting tuic-client temporarily restores full functionality
• RAM usage stable (~20MB), no memory leak observed at OS level
• CPU usage normal
• Changing congestion control (BBR/CUBIC), UDP relay mode (Native\QUIC) does not affect issue
• Issue is reproducible only after long uptime and is progressive

Client config

udp_relay_mode = "quic"
congestion_control = "bbr"
alpn = ["h3"]
zero_rtt_handshake = false
disable_sni = false
timeout = "8s"
startup_mode = "lazy"
heartbeat = "10s"
disable_native_certs = false
send_window = 16777216
receive_window = 8388608
initial_mtu = 1200
min_mtu = 1200
gso = false
pmtu = true
gc_interval = "15s"
gc_lifetime = "60s"
skip_cert_verify = false

[local]
server = "0.0.0.0:2080"
dual_stack = true
max_packet_size = 1500

[Itsusinn]

One single udp session could live more than hours in your case?

[NitroOxid]

One single udp session could live more than hours in your case?

Yes, long-lived UDP sessions are common in my setup.

The tuic-client runs on OpenWRT 24/7.
Initially I also experienced "too many open files", but that issue was resolved separately by increasing ulimit/nofile limits.

Discord voice chat is used daily and maintains continuous UDP sessions for ~6–9 hours.
Game traffic sessions are usually ~3–4 hours long.

Interesting observation:

• when RX failure happens, Discord voice/video usually loses incoming audio\video first, text\image loading work correctly.
• browser traffic over the same SOCKS5 proxy continues working normally
• game traffic is sometimes affected, but not always immediately disconnected

So the issue seems to affect long-lived UDP relay/session handling specifically, while TCP traffic remains stable.

[Itsusinn]

Could you try latest CI's artifacts (client) https://github.com/Itsusinn/tuic/actions/runs/26545557037

[NitroOxid]

The client and server have been updated.
Now the opposite happened. Nobody can hear me (TX), but I can hear them (RX). According to Discord, the ping spiked to 5000, and the game disconnected me with a timeout.

26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55323] [connect] [3.174.113.105:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:52810] [connect] [3.174.118.135:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55377] [connect] [18.118.214.191:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55317] [connect] [162.159.136.232:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55371] [connect] [162.159.128.235:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55304] [connect] [8.8.8.8:53] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55366] [connect] [162.159.130.233:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:54451] [connect] [85.236.99.85:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55358] [connect] [162.159.136.232:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:54372] [connect] [13.58.80.207:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55344] [connect] [18.118.214.191:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55409] [connect] [18.118.214.191:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55330] [connect] [18.118.214.191:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55390] [connect] [18.118.214.191:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55321] [connect] [18.118.214.191:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:54228] [connect] [162.159.137.234:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55072] [connect] [3.174.113.17:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55314] [connect] [162.159.136.232:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55368] [connect] [162.159.130.233:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55375] [connect] [162.159.135.234:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55361] [connect] [162.159.136.232:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55228] [connect] [3.141.174.48:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55355] [connect] [162.159.136.232:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55425] [connect] [162.159.128.233:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55333] [connect] [44.208.56.221:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::socks5::handle_task: [socks5] [192.168.1.168:55393] [connect] [44.208.56.221:443] TCP stream relaying error: connection lost
26-05-28 14:53:05  WARN tuic_client::connection: [relay] connection error: reset by peer

[Itsusinn]

Could you provider more logs

[NitroOxid]

Sure. Sorry, I didn’t realize right away that I should collect logs in debug mode.

I managed to reproduce the effect. Everything works correctly at the beginning of the log, and then literally a couple of seconds later the problems start.

At the same time, VLESS on the same server was working without any errors.

Client log (debug mode):
output.txt

Server log (warn-only) at same period:

26-05-29 17:27:34  WARN [packet] [0x0534] UDP session timeout
26-05-29 17:27:44  WARN [packet] [0x0535] UDP session timeout
26-05-29 17:28:34  WARN [packet] [0x0536] UDP session timeout
26-05-29 17:29:28  WARN [packet] [0x0538] UDP session timeout
26-05-29 17:29:34  WARN [packet] [0x0537] UDP session timeout
26-05-29 17:29:58  WARN [packet] [0x053a] UDP session timeout
26-05-29 17:30:34  WARN [packet] [0x053b] UDP session timeout
26-05-29 17:30:49  WARN [packet] [0x053c] UDP session timeout
26-05-29 17:31:34  WARN [packet] [0x0539] UDP session timeout
26-05-29 17:32:34  WARN [packet] [0x053d] UDP session timeout
26-05-29 17:32:54  WARN [packet] [0x053e] UDP session timeout
26-05-29 17:33:24  WARN [packet] [0x0540] UDP session timeout
26-05-29 17:33:34  WARN [packet] [0x053f] UDP session timeout
26-05-29 17:34:34  WARN [packet] [0x0541] UDP session timeout
26-05-29 17:35:34  WARN [packet] [0x0543] UDP session timeout
26-05-29 17:35:48  WARN [packet] [0x0544] UDP session timeout
26-05-29 17:36:34  WARN [packet] [0x0542] UDP session timeout
26-05-29 17:36:47  WARN [packet] [0x04d9] UDP session timeout
26-05-29 17:37:39  WARN [TCP] 3.141.174.48:443: Broken pipe (os error 32)
26-05-29 17:39:01  WARN [packet] [0x0545] UDP session timeout
26-05-29 17:40:02  WARN [packet] [0x0545] UDP session timeout
26-05-29 17:41:28  WARN [packet] [0x0000] UDP session timeout
26-05-29 17:41:31  WARN [packet] [0x0004] UDP session timeout
26-05-29 17:41:41  WARN [packet] [0x0002] UDP session timeout
26-05-29 17:41:42  WARN [packet] [0x0005] UDP session timeout
26-05-29 17:41:53  WARN [packet] [0x0006] UDP session timeout
26-05-29 17:41:58  WARN [packet] [0x0001] UDP session timeout