The 30s cron consumed the need-restart flag with IsNeedRestartAndSetFalse before
calling RestartXray and only logged a failure. If RestartXray failed early (a
transient GetXrayConfig DB error) the old process kept running the old config,
the crash detector saw a running process and never retried, and the flag stayed
cleared — so an admin's saved change silently never reached the core. Move the
consume/restart/retry into ApplyPendingRestart, which re-arms the flag on
failure so the next tick retries.
RestartXray cleared isManuallyStopped unconditionally at its top, so the @30s
pending-config cron (and warp/ldap/outbound reconcile jobs) that call
RestartXray(false) resurrected an Xray the admin had deliberately stopped —
unlike the crash-detector, which honors the manual-stop flag. Skip a non-forced
restart while the stop flag is set; only an explicit forced restart clears it.
removeInboundTagFromRules drops a routing rule whose inboundTag list becomes
empty only if the rule has no other matcher, but routingMatcherKeys omitted
xray-core's canonical source and domains keys. A rule scoped by source or domains
(common in hand-authored or imported configs) therefore lost its whole body —
including a security-relevant block — when its single listed inbound was deleted,
instead of just having the tag trimmed. Recognize source and domains as live
matchers.
ResetAllTraffics and ResetInboundTraffic performed their remote-node reset HTTP
calls inside submitTrafficWrite. Each call can block up to the remote timeout,
and Reset All Traffics loops every node serially, so the single traffic-writer
goroutine was held for seconds — long enough that the concurrent 5s traffic poll
timed out submitting its own write and dropped the deltas it had already drained
from xray. Do the DB reset inside the writer, then propagate to the nodes after
it returns, matching how the mtproto quota reset is already sequenced.
ClientService.ResetAllTraffics zeroed up/down but, unlike every sibling reset
path, never restored enable=true, so clients that had been auto-disabled for
exceeding their quota stayed cut with zero usage after a reset. It also wrote
client_traffics directly on the shared DB handle instead of through the serial
traffic writer, reintroducing the cross-transaction lock-order deadlock the
writer exists to prevent. Restore enable and run the reset inside
submitTrafficWrite within one transaction.
addTrafficLocked stages the inbound and client deltas, then runs three helpers
(auto-renew, disable depleted clients, disable depleted inbounds) that are meant
to log and continue. All three reused the function-scope err that the deferred
commit/rollback inspects, so the last helper's error decided the whole tick: a
failure in disableInvalidInbounds rolled back the already-staged traffic while
AddTraffic reported success, and because xray had already advanced its counter
baseline that traffic was lost for good. Give each best-effort helper its own
error variable so only a genuine staging failure rolls the tick back.
ToggleClientEnableByEmail (Telegram bot) and SetClientEnableByEmail (LDAP sync)
resolved a single inbound via the legacy client_traffics pointer and flipped
enable only there. A client attached to several inbounds kept connecting through
the siblings' running Xray after being disabled, and the next edit could
re-enable it everywhere from a stale sibling. Route both through the
applyClientFieldByEmail fan-out (the #5039 fix path) so the whole multi-inbound
identity is toggled at once, dropping the circular Set/Toggle dependency.
AddInbound, DelInbound and UpdateInbound all flag needRestart when an inbound
routes MTProto through xray, so the egress SOCKS bridge is regenerated. Only
SetInboundEnable's local path omitted it, so toggling a routed MTProto inbound
off then on left the bridge out of the running config while the sidecar dialed
its loopback port, blackholing that inbound until an unrelated restart. Flag the
restart on the local enable path too.
The single-client Delete path removes a client's client_external_links rows,
but BulkDelete (and the DelDepleted reaper that routes through it) deleted the
record, mappings and traffic while leaving the external-link rows keyed by the
now-dead client id, so they accumulated as orphans. Delete them in the same
cleanup transaction, keyed by client id like the single path.
UpdateInbound applied a local MTProto inbound change by calling the runtime
UpdateInbound (which stops/starts the mtg sidecar or talks to it) from inside
runSerializedTx. That runs process and network I/O on the single traffic-writer
goroutine while a DB transaction is open, so a slow sidecar stalls traffic
accounting and every concurrent client mutation, and a later step failing the
transaction leaves the sidecar ahead of the rolled-back row. Move the push into
the post-commit hook, matching the xray branch. Adds a SetLocalRuntimeOverride
test seam mirroring the existing node override so the deferral is regression
tested.
Delete, DeleteByEmail and BulkDelete all pass keepTraffic to their final
cleanup transaction, but each called the per-inbound delete helper with a
hardcoded false. That helper purges the client's traffic, IP and stat rows
before the gated cleanup runs, so keepTraffic=true still destroyed all
traffic history for any client actually attached to an inbound (the pinned
test only covered a record with no inbound mappings). Thread the caller's
keepTraffic through to the per-inbound helper at all three call sites.
lockInbound acquired the global registry mutex and then blocked on the
per-inbound mutex without releasing the registry first. A slow client
operation holding one inbound's mutex (for example a bulk delete pushing to
an unreachable node) made the next waiter park on that inbound while still
holding the registry mutex, which in turn blocked lockInbound for every
other inbound — freezing client mutations panel-wide. Release the registry
mutex before taking the per-inbound lock.
AddInbound's per-client validation switch had cases for every protocol
except WireGuard, so a WireGuard client fell through to the default branch
that requires a non-empty id. WireGuard clients are keyed by their public
key and carry no id, so importing a WireGuard inbound or re-adding one to a
reconciling node was rejected with "empty client ID". Add a wireguard case
that validates the client key, mirroring addInboundClient.
The add controller binds the inbound model's id form field and never clears
it, and AddInbound persisted with GORM Save, which updates in place when the
primary key is non-zero. A client that reused an existing id (for instance by
duplicating an inbound fetched from /get and changing the port) silently
overwrote that stored row instead of creating a new inbound. Zero the id at
the top of AddInbound, matching how it already zeroes the client-stat ids.
In a mixed BulkAdjust (both a days delta and a bytes delta), a per-field
planning skip such as "unlimited expiry" or "unlimited traffic" was recorded
in the same map that gated the client_traffics write. The applied field was
already written to the inbound JSON and the clients table, but the enforcement
row was left untouched, so the depletion job cut the client on the old limit
while the panel showed the new one. Gate the traffic-row write on an actual
inbound-processing failure rather than on any planning-phase skip note.
BulkAdjust clamped a client's new traffic limit with max(total+addBytes, 0).
Because 0 is the unlimited sentinel, reducing a client's quota by more than
it had left silently granted that client unlimited traffic. The sibling
expiry branch already refuses an over-reduction; mirror it for quota so the
adjustment is skipped with a clear reason instead of crossing the sentinel.
FilterNodeSnapshot compared a node snapshot's inbound tags against the
raw selected-tag list with an exact match, while its two siblings
(SnapshotHasUnadoptedInbounds and the reconcile tagToCentral map) expand
each selected tag to both its bare node-side form and its n<id>- prefixed
central form. A panel-created node inbound is recorded in the selected
list under the central prefixed tag but reported by the node under the
bare tag, so the exact match dropped it from every snapshot and the
orphan sweep then deleted its central row one tick after creation. Expand
the allowed set with the same prefix flip the siblings use.
TestConnection skipped the empty-from guard that Send enforces, so with
no sender and no username configured the test issued the null reverse-path
and could report success against a lenient relay while every real
notification send kept failing with the missing-sender error. Guard the
test path the same way and surface a dedicated translated message.
The save-time validator accepts any RFC 5322 address form, so a value
like '3x-ui Panel <panel(at)example.com>' passes validation, but Send and
TestConnection fed that raw string to MAIL FROM, which strict servers
reject with 501, and buildMessage mangled it into a quoted local part.
Parse the configured sender at the point of use: the envelope gets the
bare address and, when no explicit sender name is set, the display name
embedded in the setting is used for the From header.
* feat(settings): add subscription format controls
* feat(sub): auto-detect subscription formats
* fix(xray): validate balancer regexes before save
* Revert "fix(xray): validate balancer regexes before save"
This reverts commit 8a208ce71b.
* doc(endpoints): align indent spaces
* doc(settings): improve error message formatting in validateSubUserAgentRegex
- Use NewErrorf with proper formatting instead of NewError with string concatenation
- Add comment explaining the rationale for returning original pattern value
- This preserves the intentional design where empty input is stored as empty
in the DB and inherited as the runtime default at read time
---------
Co-authored-by: Tomilla <5007859+Tomilla@users.noreply.github.com>
Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>
The notification/test email carried only From/To/Subject/MIME headers, and
the From header was the raw SMTP username. Two problems:
- When the SMTP login is not a bare email address (common with relays and
submission services), the From header has no valid address and strict
receivers reject the message — e.g. Gmail returns "550-5.7.1 ... Messages
missing a valid address in From: header".
- There was no Date (mandatory per RFC 5322 section 3.6) and no Message-ID,
which also raises spam score.
Add smtpFrom (sender address) and smtpFromName (display name) settings and
assemble the message with net/mail: a name-addr From ("Name" <addr>), a
Date, a Message-ID, and an RFC 2047 encoded Subject, in a deterministic
header order. From falls back to the username when smtpFrom is empty, so
existing setups keep working. Wire the settings through the model, the SMTP
send and test paths, the Email settings UI, and all 13 locale files;
regenerate the Zod/OpenAPI artifacts.
Validate smtpFrom in AllSetting.CheckValid (reject anything net/mail cannot
parse), which surfaces a bad address at configuration time and prevents CRLF
header injection; strip CR/LF in buildMessage as defense in depth. Add
buildMessage and CheckValid tests.
Back Up's .db now restores directly into a PostgreSQL panel, so the
SQLite-side Download Migration row only duplicated it; the row stays on
PostgreSQL panels where it is the only PG-to-SQLite path. Restore
accepts .dump and .db everywhere, the backup modal texts describe the
accepted formats in all locales, and the orphaned migrationDownloadDesc
key is removed.
The SQLite panel's Restore now detects the upload by content like the
PostgreSQL panel does: migration dumps are rebuilt with RestoreSQLite,
pg_dump archives get a clear error instead of 'Invalid db file format',
and every upload passes the panel-schema pre-flight before Xray stops.
The .backup fallback survives a failed Xray start and is named in the
error, the DB pool is reopened on every error path after CloseDB, and a
failed InitDB closes the imported file before restoring the fallback so
the rename cannot hit a Windows sharing violation.
The SQLite panel's Download Migration produces a portable SQL text dump
advertised as seeding a PostgreSQL panel, but the PostgreSQL Restore only
accepted pg_dump custom archives, so the migration file was rejected with
'Invalid file' even though the upload picker asked for .dump. importDB now
sniffs the upload header: PGDMP archives keep the pg_restore path, while
raw SQLite databases (.db) and SQL text migration dumps are rebuilt,
integrity-checked, and copied into PostgreSQL with the same MigrateData
engine as 'x-ui migrate-db --dsn'. The restore picker accepts .dump/.db on
PostgreSQL and the backup modal texts describe the accepted formats in
every locale.
* Add outbound egress metadata
Show egress IP and country information for outbound HTTP tests. The probe reuses the temporary SOCKS route from the existing HTTP test and fetches Cloudflare trace metadata after the reachability check succeeds.
The outbound list now adds separate Egress and Country columns, hides egress IPs until the user reveals them, and marks Cloudflare WARP results with an orange cloud pill. Mobile cards keep the same data compact by placing the country and IPv4/IPv6 values on separate lines.
Validation: npm run typecheck; npm run lint; npm run build; go test ./internal/web/service/outbound
* Use context-aware DNS lookup for egress trace
* Address outbound egress review feedback
Restore the Real Delay selector and TCP default so the egress metadata change does not remove an existing test mode.
Keep HTTP probe tests hermetic by stubbing egress trace lookups, run IPv4 and IPv6 trace fetches concurrently with a shorter diagnostic timeout, scope mobile IP reveal state per row, support keyboard activation for reveal toggles, and treat WARP+ trace values as WARP-like.
Bump xtls/xray-core to 50231eaf (v26.7.11) and the three binary pins
(DockerInit.sh, release.yml x2) in lockstep.
Adapt the panel to the upstream changes:
- Shadowsocks "none"/"plain" and VMess "none"/"zero" were removed from
the core. A migration rewrites stored none/plain SS methods to a
supported cipher and none/zero VMess security to "auto" (on both the
clients column and inbound settings JSON); the SS build-time heal does
the same so a row injected after boot cannot brick startup. The removed
values are dropped from every frontend option list, schema and adapter,
and coerced to "auto" at the Go link/sub/Clash emit sites and both link
importers. Fix the CipherType_NONE sentinel that no longer compiles.
- Unencrypted vless/trojan outbounds to a public address are now refused
by the core. Validate outbounds through the vendored config loader when
saving the xray template and when storing/merging outbound
subscriptions, so one such outbound cannot keep the core from starting.
- New TCP finalmask type "xmc" (Minecraft mimicry): add it to the sub
link allowlist, the frontend enum and the FinalMask form (hostname,
usernames, required password), and document it.
- streamSettings gained a "method" alias for "network"; canonicalize it
to "network" at inbound save time and in the form adapters/schema so a
method-keyed config keeps its transport.
- New root "env" config key is passed through xray.Config, compared in
Equals, and forces a restart in the hot diff.
- REALITY now defaults minClientVer to 26.3.27; update the form
placeholder.
Per-inbound Host overrides (Security/SNI/Fingerprint/ALPN and friends)
are looked up by the local inbound id when subscriptions render, but
nothing in the node sync ever fetched the node's hosts table: an
inbound adopted from a managed node got zero Host rows on the master,
so its subscription configs fell back to a bare TLS block without the
fingerprint/SNI the node was configured with.
When a traffic snapshot carries a tag with no central row yet - the
only moment adoption can happen - the sync job now also pulls the
node's existing hosts/list endpoint (best-effort, so old nodes just
skip it) and the adoption branch materializes that inbound's groups
against the new central id inside the same transaction, reusing the
group-to-rows projection the hosts API already uses. Master stays
authoritative afterwards: this is a one-time import, not a continuous
sync, matching how the inbound's own settings are adopted.
Closes#5890
Behind Cloudflare with Rocket Loader enabled, the panel's entry bundles
were rewritten and executed through Rocket Loader's own loader instead
of as native ES modules (a reporter's network capture shows the main
bundle initiated by rocket-loader.min.js). That breaks module semantics
and script ordering, leaving a blank page after login even though every
asset returns 200 - most visibly with a custom URI path, where the
injected base path must be set before the bundle boots.
Stamp data-cfasync="false" - Cloudflare's documented per-script opt-out
- on the built entry script tags via a build-time transformIndexHtml
hook (Vite regenerates entry tags, so a source-HTML attribute would be
stripped), and on the runtime-injected base-path/version inline script
in serveDistPage.
Closes#5868
When a client's connection drops without a clean TCP close, xray-core
keeps its online-map entry until the session context ends (idle policy),
minutes after the kernel socket is gone. The 10s IP-limit scan kept
seeing that stale IP as the oldest live one and re-emitted the same
[LIMIT_IP] Disconnecting OLD IP line plus a RemoveUser/AddUser cycle
every scan - operators measured 100+ repeats over ~1000s for a single
network switch, forcing absurd fail2ban maxretry values to avoid
banning legitimate mobile users.
The core refreshes an entry's lastSeen only when a new connection from
that IP is dispatched, never on traffic, so a frozen lastSeen across
scans is a dead connection, not a reconnect. Track the lastSeen of each
banned (email, ip) pair and skip the log line and disconnect until it
advances; a real reconnect moves lastSeen and is enforced exactly as
before, and an age cutoff that could misclassify long-lived active
tunnels is deliberately avoided.
Closes#5893
Delete aborted its per-inbound loop on the first error, so a client
attached to inbounds across several nodes lost at most one per attempt:
the loop never reached the remaining nodes, the record cleanup after
the loop never ran, and each retry started over with whatever was left.
Operators with many nodes had to delete the same client once per node.
Collect per-inbound failures and keep going so every reachable inbound
and node is cleaned in a single pass, then keep the client record only
when something failed - its settings JSON still holds the client there,
so the next delete retries exactly the leftovers - and return the
joined failures instead of silently reporting success. DeleteByEmail's
legacy fallback loop gets the same treatment.
Closes#5845
Adding a node imports nothing; its pre-existing inbounds only become
central rows on the first clean traffic-sync tick. But any save of the
node (switching sync mode, picking tags after "Load inbounds from
node") marks it config-dirty, and the next tick then ran ReconcileNode
before that first adoption: with zero central rows the delete sweep saw
every remote tag as undesired and destroyed the node's real inbounds -
in "all" mode all of them - disconnecting live clients with no
confirmation, and the master then reported "record not found".
Track the first completed clean sync in nodes.inbounds_adopted_at and
skip the sweep (pushes still run) until it is set, so "absent locally"
can no longer be conflated with "deleted on the master". A node that
has synced before still sweeps normally, including the offline
last-inbound-deleted case. Existing nodes are seeded as adopted on
upgrade to keep their behavior unchanged.
Closes#5898
Update committed an email rename to the clients table with a standalone
write before the per-inbound loop rewrote each inbound's settings JSON.
In that window the record held the new email while the JSON still held
the old one, so any concurrent SyncInbound (traffic poll, another edit)
found no record for the old email and inserted a duplicate seeded from
the stale JSON - carrying the same subId, which then failed every later
edit with "Duplicate subId". The subId collision check also ran after
that write, so even a rejected update permanently renamed the email.
Move the rename inside UpdateInboundClient's serialized transaction,
next to the settings save and SyncInbound, so no other writer can see
one without the other; skip it when a record already owns the target
email (the merge case). Update now only runs collision checks before
the loop and falls back to a direct rename solely for records with no
attached inbound. This covers both the REST API and the web UI editor,
which share this path.
Closes#5870
Create permits a repeat add for an email that already exists when the
payload subId matches the stored one (the documented way to attach an
identity to more inbounds), but it never seeded the payload from the
existing record, so an omitted id minted a fresh UUID via
fillProtocolDefaults. SyncInbound then overwrote the shared clients.uuid
row by email while previously-attached inbounds kept the original UUID
in their settings JSON, silently desyncing panel credentials from
subscription links. BulkCreate had the identical gap.
Seed ID/Password/Auth/Secret from the existing record in both paths
(mirroring what Update, Attach and BulkAttach already do), and preserve
Secret in Update too so partial edits of MTProto clients cannot rotate
the stored secret.
Closes#5903
* fix(clients): include Telegram ID in client list search
clientMatchesSearch only checked Email/SubID/Comment/UUID/Password/Auth,
so searching the client list for a Telegram user ID never matched even
though the field is stored on every client.
This is a real regression, not a field that was simply never included:
before the paged search endpoint (#4500), the frontend searched with
ObjectUtil.deepSearch() over the full client object, which recursed into
every field including tgId. Replacing that with a fixed backend field
list silently dropped it (along with a few other fields, but tgId is the
one that's actually needed here since it's the panel's own way of
looking a client up when it only knows their Telegram ID).
TgID is int64 (0 = unset), so it can't sit in the existing []string
candidates array — matched separately via strconv, and skipped when 0 to
avoid a needle of "0" spuriously matching every client without a
Telegram ID.
Fixes#5880
* fix(clients): drop explanatory comment, mention Telegram ID in search hint
Addresses review feedback on #5888:
- Removed the // comment block above the TgID check in
clientMatchesSearch per repo convention (code should read on its own).
- Updated searchPlaceholder in all 13 locale files to mention Telegram ID,
since the search box now actually matches on it.
* test(clients): remove TgID search test per maintainer request
* feat(balancer): add balancer-to-balancer fallback support
Xray does not natively support using a balancer as fallbackTag for
another balancer. This feature automates the loopback workaround:
when a user selects a balancer as fallback, the panel generates a
loopback outbound + routing rule in the template.
How it works:
- User picks fallback balancer from dropdown
- Panel creates loopback outbound _bl_{target} + routing rule
- Balancer fallbackTag set to _bl_{target}
- Traffic: Balancer A → loopback _bl_B → routing rule → Balancer B
Key features:
- Dedup: multiple balancers sharing same fallback reuse one loopback
- DFS cycle detection at edit time and on save
- Self-reference guard (cannot select own balancer)
- Delete protection (blocks if used as fallback by others)
- Cleans up routing rules referencing deleted balancers
- Override resolves balancer tags through loopback mechanism
- All live status tags resolved for display
- Internal _bl_ objects filtered from Outbounds/Routing UI
- Backward-compatible with old _bl_ naming format
- Translations for all 13 locales
* fix(review): override regression, save payload sync, i18n completeness
- OverrideBalancer: only resolve to loopback when resolution succeeds,
pass original target through for plain outbound tags
- onSaveAll: serialize cleaned template before save to ensure the
healed/cleaned config is what gets persisted
- Add reservedPrefix translation key to all 12 non-English locales
- Restore trailing newlines in all 13 translation JSON files
* fix(test): update balancer form modal tests after cycle-detection guard
The okButtonProps disabled guard (added in 56d5825c) prevents the modal
from firing onOk when the form is invalid. The old tests clicked the
button expecting validation errors to appear, but antd Modal never calls
onOk on a disabled button — causing false failures.
Rewrite to test the actual guard behavior:
- Button starts disabled (empty form)
- Stays disabled with tag only (selector still empty)
- Stays disabled for duplicate tag
- Disabled button does not trigger onConfirm
---------
Co-authored-by: MHSanaei <ho3ein.sanaei@gmail.com>
* feat(xray): default outbound picker in basic routing
Let panel users choose which outbound handles unmatched traffic by
moving it to the first position in the template outbounds list.
* fix(xray): keep direct/blocked outbounds when changing default
* style(routing): revert incidental whitespace churn
Drop double blank lines and the reformatted function signature so the default-outbound diff stays focused on behavior.
* fix(inbound): scope port-conflict check to the stored node on update
UpdateInbound called checkPortConflict before restoring the inbound's NodeID
from the database, so the check used the NodeID from the request body. That
value is unreliable for edits: clients omit it (nodeId is `json:",omitempty"`)
and the code already treats the stored NodeID as authoritative — an inbound
can't be moved between nodes via edit. With a nil request NodeID a node inbound
was mis-checked as a local/main-panel inbound and falsely collided with an
unrelated inbound that happened to reuse the same port on the central panel (or
another node). Symptom: editing a node inbound's listen address was rejected
with "port <p> (tcp) already used by inbound ... " and silently discarded.
Load the old inbound and restore inbound.NodeID *before* checkPortConflict, so
the check runs against the node the inbound actually lives on. checkPortConflict
already scopes candidates by node (sameNode); it was simply being fed the wrong
NodeID.
Add a regression test that seeds a main-panel and a node inbound on the same
port and asserts the node inbound stays editable (fails before this change with
the exact "already used" rejection).
* style(inbound): trim inline comments from port-conflict scoping
Repo convention forbids // line comments in committed Go; keep the scoping fix self-documenting.
Adding a WireGuard client on the master broke every WireGuard connection on
the sub-node until Xray was manually restarted on the node. Adding the same
client directly on the node worked.
Root cause: the panel stores WireGuard clients under the settings key
`clients` (the shape every other protocol uses), but xray-core's wireguard
inbound is configured with `peers`. The `clients`->`peers` conversion lived
only in the full-config generation path (XrayService.GetXrayConfig), which
runs on a full Xray restart. The live gRPC AddInbound path goes through
(*Inbound).GenXrayInboundConfig, which passed the WireGuard settings verbatim
- with `clients` and no `peers`.
Why the master path broke it and the node path did not:
- Adding on the node is a single safe operation: AddInboundClient -> AddUser
-> AlterInbound{AddUser} -> wireguard.Server.AddUser, which appends one peer
via IPC without touching the others. The inbound is local (NodeID == nil),
so nothing is marked dirty and no reconcile runs.
- Adding on the master does two things: it pushes the client to the node
(the same safe hot-add, which succeeds), and it marks the node dirty. The
reconcile then pushes panel/api/inbounds/update/:id to the node, whose
InboundService.UpdateInbound applies it live via DelInbound + AddInbound
(buildRuntimeInboundForAPI -> Local.AddInbound -> GenXrayInboundConfig).
That re-adds the wireguard inbound with zero peers, wiping the device and
dropping every connected client. A manual restart regenerated the full
config, converted clients to peers, and restored them - hence "only a
restart fixes it".
Fix: convert WireGuard `clients` to `peers` in GenXrayInboundConfig itself,
the single chokepoint for every live AddInbound (create, edit, node
reconcile). WireguardClientsToPeers always rebuilds `peers` from `clients`
(matching GetXrayConfig field for field) and drops the `clients` key. It does
not gate on `peers` being absent: the panel seeds every WireGuard inbound with
an empty `peers: []` placeholder (frontend inbound-defaults), so a
"skip if peers present" guard would match that placeholder and make the
conversion never run, leaving the live path emitting zero peers. The
conversion stays idempotent by removing `clients`, so a second call - or an
inbound with no `clients` - is a no-op, leaving the full-config path
unaffected. This also fixes plain WireGuard inbound edits on a standalone
panel, which went through the same peerless rebuild.
* feat(hosts): bulk-add multiple hosts to multiple inbounds
Allow users to select multiple inbound IDs and enter multiple host
addresses (with optional per-host port override) in a single form
submission.
- Add BulkAddHostReq entity and POST /panel/api/hosts/bulk/add endpoint
- Add AddHostsBulk service with GORM transaction safety
- Add parseHostAndPort helper (IPv4, bracketed/bracketless IPv6, port)
- Update HostFormModal to multi-select inbounds and tag-input hosts
- Wire bulkCreate mutation in HostsPage with existing-host suggestions
- Register endpoint in api-docs/endpoints.ts and regenerate OpenAPI/Zod
* feat(hosts): group override records by group_id and support group editing
* fix: import Popover in HostList
* fix: use messageApi in HostFormModal
* fix(hosts): resolve 4 bugs found in host-group code review
- fix(schema): allow empty hosts array in BulkAddHostSchema so users can
save a host without an address (inherits inbound endpoint). The old
.min(1) was never enforced at runtime since the schema is only used for
type inference, but the type was incorrect.
- fix(service): validate new inbound IDs in UpdateHostGroup before deleting
old rows, matching the same check already present in AddHostGroup. Prevents
orphaned host rows when an invalid inbound ID is supplied on edit.
- fix(service): replace full-table scan in GetHostsByInbound with two
targeted queries (DISTINCT group_id WHERE inbound_id=?, then
WHERE group_id IN ?) to avoid loading every host in the DB.
- fix(mutations): remove unused createMut / create export from
useHostMutations. The /hosts/add endpoint is identical to /hosts/bulk/add;
only bulkCreate is used by the UI.
* fix(hosts): address code review feedback (optimize bulk inserts, add validation tests, and remove comments)
* fix(fmt): apply gofumpt formatting to model.go and db.go
The previous merge commit incorrectly applied gofmt (tab-aligned) to
these files. The repository's golangci config requires gofumpt+goimports
which produces space-aligned struct fields. This commit restores the
correct gofumpt formatting that matches upstream/main.
* chore(frontend): regenerate API schemas and update lockfile
* fix
* refactor(hosts): dedupe host-group service and tidy frontend
AddHostGroup and UpdateHostGroup shared an identical ~35-field
model.Host construction and hand-rolled transaction boilerplate
(tx.Begin plus a committed flag plus a deferred recover/rollback).
Extract buildHostRows, validateInboundsExist and formatHostAddr, and
run every mutation through db.Transaction. groupHosts collapses its
duplicated address/port formatting and create/append fork into one
path using slices.Contains. Behavior-preserving: host.go drops ~90
lines with the existing service/controller tests green.
Frontend: drop the Partial union and two as-casts in HostsPage.onSave
(the modal always passes a full BulkAddHostValues), and remove the
movable index map in HostList in favor of the table render index arg.
---------
Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>
Replace strings.Split loops with strings.SplitSeq iterators in the CSV
parsers (reality_scan and the scale-test helpers) and swap a manual map
copy for maps.Copy in the MTProto traffic collector. No behavior change;
these are the fixes the modernize analyzer reports.
* fix(clients): surface bulk-reset auto-enable failures
BulkResetTraffic re-enables a disabled client before resetting its
traffic, but discarded the s.Update result with `_, _ =`, so a failed
re-enable was silent: the client stayed disabled with nothing logged,
unlike the single-client ResetTraffic path which already warns on the
same call. Check the error and log a warning to match, and add a
regression test covering BulkResetTraffic's previously-untested
re-enable path.
* ci: update Go toolchain for govulncheck
---------
Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>
* fix(clients): parse only settings.clients across protocols
Several inbound settings readers decoded the whole settings object into map[string][]model.Client. Real protocol settings include scalar keys such as VLESS decryption and Hysteria version, so that shape can fail before callers reach settings.clients or leave them relying on decoder side effects.
Add one shared helper that extracts only the clients field through json.RawMessage, then use it from GetClients, SearchClientTraffic and the IP-limit job fallback paths. Regression tests cover VLESS and Hysteria settings with scalar protocol fields.
* fix(clients): reject empty inbound settings
* fix(inbound): reject finalmask configured together with REALITY security
finalmask wraps the connection before REALITY's own handshake takes
over (TcpmaskManager.WrapListener -> WrapConnServer runs at Accept()
time, ahead of reality.Server()). reality.Server() does an unchecked
type assertion assuming a raw *net.TCPConn; with finalmask in front,
that assertion panics and takes down the entire xray-core process on
the very first connection to the inbound - not just that connection.
Upstream (XTLS/Xray-core#6453) confirmed this will be documented as
unsupported rather than made graceful, so the panel needs to stop this
combination from being saved rather than relying on docs.
AddInbound/UpdateInbound now reject streamSettings with
security=reality and a non-empty finalmask.tcp/udp with a clear error
instead of letting it reach Xray.
Related: MHSanaei/3x-ui#5857
* fix(inbound): heal legacy rows and narrow the finalmask+REALITY guard
Per review feedback on #5861:
- Narrow the check to finalmask.tcp only. xray-core's TcpmaskManager
(the thing that wraps the TCP listener ahead of REALITY's handshake,
the actual cause of the panic) is only constructed when tcp masks
are present; a finalmask.udp-only config never touches that accept
path and doesn't reproduce the crash, so it shouldn't be rejected.
Extracted the shared check into finalMaskRealityTcpMasks() so both
the save-time guard and the config-build heal below use one
definition of "dangerous".
- Heal already-saved bad rows in GetXrayConfig(), the same way
liftXhttpSessionIDKeys and HealShadowsocksClientMethods heal other
legacy data at config-build time. AddInbound/UpdateInbound only cover
the two save paths - a row that already carries this combination
(saved before this guard existed, synced from a node, restored from
a backup, or edited directly in the DB) would still crash Xray-core
on the next restart without this.
- Add end-to-end tests exercising AddInbound, UpdateInbound, and
GetXrayConfig directly (seeding rows through the real DB) rather
than only unit-testing the extracted helper in isolation, so a
wiring regression in any of the three call sites gets caught.
* fix(routing): allow dns.servers on private IPs past the geoip:private block rule
Xray's own DNS client traffic is dispatched through the same routing
table as proxied client traffic. When dns.servers points at a private
IP (e.g. a self-hosted AdGuard Home / Pi-hole reachable on the same
Docker network as Xray) and the panel's default geoip:private block
rule is active, Xray's own DNS lookups get silently dropped. Xray then
falls back to dialing destinations by raw hostname once its internal
DNS attempt times out (~4s), so proxied connections still work, just
with a multi-second stall added to every new domain-based connection,
with no error surfaced anywhere.
EnsureDnsServerRouting keeps a managed "direct" allow-rule for any
private literal IP found in dns.servers, inserted immediately before
the geoip:private block rule (matched by shape, not position). It only
acts when both ingredients are present, keeps the managed rule in sync
as dns.servers changes across saves, and never touches manually
authored rules.
Fixes#5773
* fix(routing): scope the DNS allow-rule to its port, guard against reorder/UI drift
Addresses three review findings on the initial fix:
1. The allow-rule now carries a "port" matcher (grouped by the
dns.servers entries that share it), instead of opening every port
on the private DNS IP to proxy-client traffic. A private resolver
that also exposes an unauthenticated admin UI on the same address
would otherwise become reachable through the proxy too.
2. EnsureDnsServerRouting now strips every previously-managed rule and
rebuilds the current set fresh, reinserted immediately before the
(re-indexed) geoip:private block rule on every save. Comparing IP
content alone missed the case where an admin drags the rule below
the block rule in the Routing tab (or reorders something else and
incidentally moves it) — silently reintroducing the exact stall
this fix addresses, with nothing to notice or correct it.
3. dnsAllowRuleShape now tolerates an "enabled" key as long as it's
true, matching the existing EnsureStatsRouting precedent
(xray_setting.go's `delete(apiRule, "enabled")`). The Routing tab's
rule editor writes that key on every save regardless of whether
anything changed, and its enabled switch writes it on a plain
toggle — without this, either action permanently disowns the rule
from management and a duplicate gets inserted next save. A rule
explicitly disabled (enabled=false) is left alone and a fresh one
is (re-)created, respecting the admin's choice instead of silently
re-enabling it.
No-op detection now compares rebuilt rules against the original
routing.rules JSON (both decoded through encoding/json to a common
type) rather than reflect.DeepEqual on the parsed Go values, which
falsely reported changes for identical content stored as []any vs
[]string.
5 new tests cover multi-port grouping, position drift, and both
enabled-key cases; existing tests updated for the port field.
* fix: avoid size-computation overflow in allocation hint
CodeQL flagged make([]map[string]any, 0, len(clean)+len(managed)) as a
potential integer-overflow risk in the capacity computation. Drop the
addition and hint with len(clean) alone — it already covers most of
the eventual size, and append still grows correctly for the rest.
---------
Co-authored-by: Volov <volovdata@google.com>
* fix(ldap): convert default total GB to bytes when auto-creating clients
LdapSyncJob.buildClient stored ldapDefaultTotalGB directly into
Client.TotalGB without the GB-to-bytes conversion every other client
creation path applies (client form's gbToBytes, tgbot's
limitTraffic*1024^3, client_inbound_apply.go's totalGB*1024^3). A
"Default total (GB)" of 10 was persisted as 10 bytes, depleting the
client almost immediately.
Closes#5852
* test(ldap): pin the GB-to-bytes conversion in buildClient
Per review feedback on #5854: the existing test only exercised
defGB=0, so it wouldn't have caught the missing conversion.
Map each mtproto client's totalGB and expiryTime onto mtg-multi's new
[secret-limits] (quota/expires): emit them into the generated config and
hot-apply through PUT /secrets so live connections survive. Quota is
written as an exact "<n>B" byte count that round-trips through both the
config and API parsers without the precision loss of a base-2 unit.
The sidecar's quota counter is not pruned when a secret is dropped, so a
panel-side traffic reset re-pushes the client's secret and then calls
POST /secrets/{name}/reset-quota (wired into every reset path) so a
renewed client is not immediately re-blocked.
Resolve the mtg-multi binary from the fork's latest release tag in
DockerInit.sh and release.yml instead of a hardcoded version pin, so the
panel no longer needs a manual bump per fork release.
Drop the axios (and qs) dependencies in favor of a native fetch wrapper.
axios only ever handled same-origin JSON/form calls, a CSRF header, a 401
redirect, and a 403-retry, all of which the platform now provides directly.
- New src/api/http-init.ts (replaces axios-init.ts) reimplements the
request/response interceptors on fetch: base-path prefixing,
X-Requested-With, same-origin credentials, the CSRF token on unsafe
methods, a single 403 retry with token refresh, and the 401
redirect-and-latch. A small encodeForm() reproduces qs's
arrayFormat:'repeat' encoding, so the request wire format is unchanged.
- HttpUtil (src/utils/index.ts) keeps its public signatures and the Msg
envelope, so the ~49 API call sites are untouched. HttpOptions is now
hand-rolled instead of extending AxiosRequestConfig.
- PanelUpdateModal drops its lone direct axios.get in favor of HttpUtil.get
with { silent, timeout }.
- Add tests for the fetch core (CSRF header, form/JSON/FormData bodies,
base-path prefix, 403 retry, 401 redirect, tolerant body parse) and for
HttpUtil's envelope unwrap / toast / error mapping; this logic was
previously untested.
- Remove the vendor-axios manualChunks branch and the qs type shim, and
reword stale "axios" mentions in docs and route comments.
MHSanaei