Sanaei 272854df91 Client/inbound resilience + Postgres pool tuning + schema fixes (#4607) ...

* fix(clients): fall back to inbound scan when ClientRecord is missing

DeleteByEmail looked up the email in client_records and returned the
raw "record not found" gorm error when nothing matched, even though
the client could still live inside an inbound's settings.clients JSON
(legacy entries that SyncInbound never picked up, or rows deleted out
from under a stale inbound). The user-visible delete then fails
mysteriously while xray happily keeps serving the client.

When GetRecordByEmail returns ErrRecordNotFound, walk inbounds whose
settings JSON references the email and run DelInboundClientByEmail on
each. The traffic / IP rows are cleaned up at the end unless keepTraffic
is set. If no inbound carries the email either, surface a clear
"client %q not found in any inbound or client record" error instead.

* chore(logging): include request + caller context in jsonMsgObj warnings

The generic "X-UI: Something went wrong. Error: record not found" log
gave no clue about which endpoint, client, or controller line emitted
it. Prepend a context block:

  [POST /panel/api/clients/del/ADMIN ip=109.124.234.127
   handler=controller.(*ClientController).delete client.go:146]

Handler frame is located by scanning the stack for the first caller
outside util.go, so it points at the right controller method whether
the path went through jsonMsg, jsonObj, or jsonMsgObj directly.

* fix(clients): tolerate orphan client_inbounds rows in Delete

DeleteByEmail's previous fix only covered the case where GetRecordByEmail
returned ErrRecordNotFound. When the ClientRecord exists but a client_inbounds
row points to an inbound that has been removed out-of-band (failed mid-delete,
manual SQL, pre-SyncInbound migration), Delete bubbled the raw gorm
"record not found" from inboundSvc.GetInbound and aborted before any cleanup
ran — leaving the client un-deletable through the UI/API.

Match the tolerance bulkDelInboundClients already has: when GetInbound
returns gorm.ErrRecordNotFound for a join row, log a warning and continue.
The unconditional Delete(&model.ClientInbound{}) later in the function then
removes the stale row, and the ClientRecord delete succeeds.

* fix(schemas): accept empty-string fingerprint on externalProxy

The External Proxy form offers a "Default" option with value '' for the
uTLS fingerprint dropdown, but UtlsFingerprintSchema.optional() rejects
empty strings (only undefined or a valid enum member). Saving an inbound
with externalProxy rows failed with `expected one of "360"|"chrome"|...`.

Preprocess '' to undefined before the optional enum, matching the existing
pattern used for VmessSecuritySchema.

* chore(logging): drop noisy orphan client_inbounds warning

Per-row WARNINGs spammed logs whenever a client referenced multiple
already-deleted inbounds. The continue keeps the orphan-tolerant
behavior; just no longer announces each skipped row.

* feat(clients): per-client VMess security in client form

Restores the VMess `security` selector on the client form (auto, aes-128-gcm,
chacha20-poly1305, none, zero) and surfaces it only when at least one attached
inbound is VMess. The value rides into the share link via the existing
`scy=` field in genVmessLink; the panel persists it on ClientRecord and in
the inbound's settings.clients so the link generator can read it back.

Adds the pages.clients.vmessSecurity i18n key in en-US and fa-IR.

* fix(xray-config): strip panel-only fields from inbound config

Two fields the panel stores but Xray doesn't accept on the inbound side:

- VMess clients[].security — panel persists it so the share-link generator
  can write `scy=...`, but xray's vmess inbound spec has no per-client
  security. The field was leaking into the inbound JSON pushed to xray-core.
- VLESS settings.encryption — per the xray spec the inbound only takes
  `decryption`; `encryption` is for the matching client outbound. The panel
  keeps it for operator reference, but it must not appear in the inbound
  payload.

Add two strip helpers next to HealShadowsocksClientMethods and wire them
into GenXrayInboundConfig via a per-protocol switch, so both local and
remote runtime paths get the cleaned config.

* chore(db): backend-aware pool sizes with env overrides

Per-backend defaults:
- Postgres: 25 max open / 25 max idle. Matching idle to open removes
  pool churn under bursts (Postgres handles concurrency at the server,
  idle connections are cheap).
- SQLite: 1 max open / 1 max idle. Single-writer model means a wider
  cap just queues behind busy_timeout; tight cap is honest.

Both back ends share ConnMaxLifetime=1h and ConnMaxIdleTime=30m so
stale connections (vault rotation, pgbouncer drops, load-balancer
idle eviction) rotate out without operator intervention.

Operators can override either default at boot via:
  XUI_DB_MAX_OPEN_CONNS=...
  XUI_DB_MAX_IDLE_CONNS=...

envInt parses these; missing/empty/non-positive values fall back to
the per-backend default.

* fix(schemas): accept boolean acceptProxyProtocol on TCP stream

TcpStreamSettingsSchema declared `acceptProxyProtocol: z.literal(true).optional()`,
so saving an inbound where the AntD Switch sat in the off state failed
validation with `Invalid input` because the Switch always emits a plain
boolean.

Switch to `z.boolean().default(false)` — same shape ws/sockopt/httpupgrade
already use, and matches the actual wire payload (golden fixtures and
other settings blocks all store `acceptProxyProtocol: false`).

Snapshots for stream.test and inbound-full.test pick up the new defaulted
field on TCP fixtures.

2026-05-27 22:51:37 +02:00

26 KiB

Raw Blame History

View Raw