fix(tuic): preserve client identity for Xray user routing (#6875)

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.
This commit is contained in:
Egor
2026-10-24 09:20:39 +05:00
committed by GitHub
parent 07910bf6c0
commit 207c705300
38 changed files with 3510 additions and 170 deletions
+3 -2
View File
@@ -555,8 +555,9 @@ func (s *Server) start(restartXray bool, startTgBot bool) (err error) {
// The closures bridge into XrayService (which owns the running xray
// process state) without forcing the runtime package to import service.
mgr := runtime.NewManager(runtime.LocalDeps{
APIPort: func() int { return s.xrayService.GetXrayAPIPort() },
SetNeedRestart: func() { s.xrayService.SetToNeedRestart() },
APIPort: func() int { return s.xrayService.GetXrayAPIPort() },
SetNeedRestart: func() { s.xrayService.SetToNeedRestart() },
RequestReconcile: func() { s.xrayService.SetToNeedReconcile() },
})
runtime.SetManager(mgr)
mgr.SetNodeEgressResolver(&s.settingService)