TUIC traffic reached Xray through a loopback SOCKS relay that took no login,
so Xray never learned which client a connection belonged to and user routing
rules never matched TUIC (#6874). The relay now carries one account per client
email, so per-user rules match on TCP and both UDP modes; admission stays with
the native TUIC server.
Adding, removing or renaming a TUIC client swaps only that inbound's relay
instead of restarting Xray: new sessions wait behind a bounded gate while live
streams and UDP associations continue, accounts are verified after the swap and
rolled back on failure, one failing relay no longer strands the others or blocks
unrelated live changes, and emails over SOCKS5's 255-byte limit are excluded
with a warning.
* Write config.json after a hot apply
tryHotApply only updated the in-memory snapshot, so bin/config.json stayed
stale until the next cold start and the Telegram/Discord config backups
uploaded old rules. Persist the new config once the API calls succeed; a
write failure is logged and does not restart the running core.
* Test that a hot apply refreshes config.json
Egor
kaveh