Add native Shadowsocks 2022 support with gRPC hot‑add and config safeguards

[4erdenko]

Summary

• Add native Shadowsocks 2022 (SIP022) multi‑user support across backend, API client, config generation, subscriptions, and dashboard UI.
• Fix gRPC AddUser for SS2022 by sending the correct xray.proxy.shadowsocks_2022.Account type and payload; remove the non-existent ...User type.
• Restore dashboard auth base path and document the required frontend build env (VITE_BASE_API=/api/).
• Provide safer validation/generation of SS2022 keys and ensure inbounds become UserManager-capable without core restarts.
• Forbid multiple SS2022 inbounds: Marzban stores a single SS account per user, so we fail fast if a config contains >1 SS2022 inbound.
• When an SS2022 inbound method changes, per-user keys are auto-regenerated if their length no longer matches the new method (logged with a warning).

Why

• Previous flows restarted Xray per user and failed for SS2022 with proxy is not a UserManager and failed to parse user > proto: not found.
• Marzban users need hot-add/remove of SS2022 users via gRPC while keeping legacy AEAD Shadowsocks untouched.
• Frontend build lost the /api/ prefix causing 404 on /admin/token; we need reproducible builds.
• One user = one Shadowsocks method/password; allowing several SS2022 inbounds with different methods would silently break keys. We now reject that config up front.

What was done

1. API/types

   • Added SS2022 methods to ShadowsocksMethods; classic account now rejects 2022 methods.
   • Implemented Shadowsocks2022Account that sends TypedMessage(type="xray.proxy.shadowsocks_2022.Account") with a minimal wire-encoded key field, matching Xray-core expectations.

2. Backend models & config

   • ShadowsocksSettings auto-generates/validates per-user PSK lengths per method (16/32 bytes).
   • Inbound config accepts method + server_psk; ensures clients list has a bootstrap entry to enable UserManager; validates missing/invalid PSK with clear errors.
   • Subscription outputs (v2ray/Clash/sing-box) now use password = "{server_psk}:{user_psk}" and expose SS2022 methods.

3. Operations

   • Add/Alter/Remove user flows choose SS2022 account when inbound uses 2022 methods; guardrails against user choosing 2022 on non-2022 inbound.
   • XTLS flow sanitization left intact.

4. Dashboard

   • SS2022 methods surfaced in UI; method selector auto-locks when inbound is 2022.
   • Restored login/API base usage; documented build command with VITE_BASE_API=/api/.

How it works (SS2022 path)

• Inbound: method=2022-blake3-..., password=<server_psk>, clients contains a bootstrap user to activate UserManager.
• User add: backend builds common.protocol.User where account is TypedMessage(type="xray.proxy.shadowsocks_2022.Account", value=<key bytes>); gRPC AlterInbound(AddUserOperation) succeeds without core restart.
• Client configs: password is ${server_psk}:${user_psk}, method matches inbound.
• Config guard: if config has >1 SS2022 inbound, startup / PUT /api/core/config returns 400 with a clear message; service won’t start with an impossible mapping.

Migration / Notes

• Existing SS (AEAD) users/inbounds stay unchanged.
• For any pre-existing SS2022 users created before this patch, resave/update the user to resend the correct AddUser payload.
• Frontend rebuild must set VITE_BASE_API=/api/ (see build workflow).
• Changing an SS2022 inbound method may regenerate user keys to match required key length; clients must refresh subscriptions to pick up new {server_psk}:{user_psk}.

Known issue: Shadowsocks‑2022 memory leak in Xray-core

• Xray-core had a real memory leak in Shadowsocks‑2022 (e.g., 2022-blake3-aes-256-gcm) reported in issue #5163 and fixed in PR #5166; the fix is included in v25.10.15 (release changelog line “Fix shadowsocks2022 memory leak”).
• ❗️ Use xray-core v25.10.15 or newer for SS2022. Older versions are potentially affected; upgrade if you see monotonic RSS growth under SS2022 load.
• SS2022 still uses more RAM than VLESS/VMess by design (issue #3131), so a stable but higher baseline is expected; only monotonic growth indicates the leak.

Testing

• Built docker image locally: DOCKER_BUILDKIT=0 docker compose build marzban.
• Started stack: docker compose up -d marzban.
• Manual e2e:
  • POST /api/admin/token → 200.
  • POST /api/user with SS2022 method+user key on inbound Shadowsocks 2022 TCP → 200; links generated; no gRPC errors; Xray stays up.