mirror of
https://github.com/MHSanaei/3x-ui.git
synced 2026-08-09 21:00:58 +00:00
17e6b5a460a73160d455c47e02f7faecf9f83a9c
3226 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Shichao Song
|
17e6b5a460 | inbounds: allow custom monthly traffic reset days (#6071) | ||
|
Intervence
|
34d2591e50 |
fix (install.sh): use realpath instead of script name (#6075)
* fix (install.sh): use realpath instead of script name ###Description: During arch() sctipt tries to delete itself in case no compatible arch found. This may lead to unexpected file deletion if executed outside root dir; also cur_dir is declared but doesn't seem to be used anywhere ###Way to reproduce: ```bash cd "/some/other_dir_with_install_sh" /3x-ui/project/dir/install.sh ``` * fix(install): quote the script path before the self-delete realpath was handed an unquoted $0, so a script living under a path that contains spaces was split into several arguments: realpath printed a partial path plus an error, and rm -f then targeted a name matching nothing at all. The unsupported-arch branch silently kept the script it means to remove — the very case the surrounding fix exists for. |
||
|
PathGao
|
ca6955d88b |
feat(ui): validate the REALITY client version range at save time (#6126)
* feat(ui): validate the REALITY client version range at save time The impossible range from PR #6125 — a max below the effective minimum — could still be saved; the tooltip only helps a user who hovers it. Add save-time validation mirroring xray-core's parser (up to three dot-separated parts, each 0-255) on both fields, plus a cross-field check that a non-empty max is not below a non-empty min. Errors are field-level i18n keys following the REALITY target precedent, so the modal stays open and points at the offending field instead of storing a config that rejects every client. A malformed min is reported by its own field and skipped by the max comparison, so the user sees one precise error per field. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ui): reject untrimmed client versions and revalidate max on min edits From review: the validators trimmed but the save path ships the value verbatim, and xray-core's part parser accepts no surrounding whitespace — so a green form could still save a config the core refuses to load. Reject any value that differs from its trimmed form. Also revalidate the max field after a min edit when max already shows an error, so correcting the min clears the stale cross-field message without waiting for the next submit. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
PathGao
|
411271b454 |
refactor(ui): share one onNumber handler for numeric setting inputs (#6127)
* refactor(ui): share one onNumber handler for numeric setting inputs The Number(v) || 0 idiom in InputNumber onChange handlers is the root pattern behind the cleared-port bug (#6121): AntD reports a cleared field as null, and || 0 turns that into a stored zero or a min-clamp. The port fields got an inline null-guard; the other sixteen numeric settings kept the idiom, so every new field is a chance to reintroduce the bug. Extract the guard into onNumber(apply): null, empty and NaN change events are ignored so a cleared field snaps back to its stored value on blur, and numeric events pass through unchanged. Convert all sixteen sites in the settings and xray pages. Two sites keep their deliberate different semantics: smtpPort falls back to 587 on clear, and the Telegram notify interval clamps through Math.max. For the non-port fields this changes clearing from storing 0 to keeping the stored value; zero remains reachable by typing it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(ui): fold the remaining hand-rolled numeric guards into onNumber From review: ObservatorySettingsTab's sampling field hand-rolled the same ignore-null semantic and smtpPort kept a fallback-to-587 on clear that nothing documents as intentional and that silently overwrites a configured non-standard port — both now go through the shared helper, leaving the Telegram interval clamp as the one deliberate exception. Also from review: narrow the helper to numbers only (no stringMode input exists in the repo, and the string branch codified a guarantee the number-typed callback cannot honour), soften the docblock to describe behavior rather than promise prevention, add a GeneralTab component test covering the clear-vs-typed-zero semantics, and assert the blur snap-back in both settings tests so a display/state desync cannot ship unnoticed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Tosd
|
e862d81c60 |
fix(sub): omit hyphen for empty remark variables (#6101)
* fix(sub): omit hyphen for empty remark variables
The default INBOUND-EMAIL template left a leading hyphen when an inbound had no remark after display remarks became template-driven in
|
||
|
Kim Fom
|
6af2995930 |
feat(api): add GET endpoint to look up clients by Telegram ID (#5945)
* feat(api): add GET endpoint to look up clients by Telegram ID
GET /panel/api/clients/getByTgId/:tgId returns all clients matching the given Telegram user ID. tgId is not unique, so the response is an array of {client, inboundIds, externalLinks, usedTraffic} objects.
* fix: guard tgId=0 sentinel, index tg_id, deduplicate enrichment in getByTgId
Three issues from the code review on the new GET /panel/api/clients/getByTgId/:tgId
endpoint: the lookup did not short-circuit tgId <= 0 (this codebase's sentinel
for 'no Telegram ID'), had no index on clients.tg_id causing a full table scan
on every call, and duplicated the per-record enrichment (inbound IDs, external
links, effective flow, traffic) identically between get and getByTgId.
- Reject tgId <= 0 in GetRecordsByTgId with a clear error, matching the
'0 = none' convention used elsewhere in the codebase.
- Add index:idx_clients_tg_id to ClientRecord.TgID (struct tag + idempotent
startup migration for existing databases).
- Extract buildClientPayload helper used by both get and getByTgId.
- Update client_lookup_test.go to verify sentinel rejection instead of
expecting tgId=0 to be a valid lookup.
* refactor(api): move Telegram client lookup under /get/tgId/:tgId
Nest the Telegram-ID lookup beside the email lookup as /get/tgId/:tgId
instead of the flat /getByTgId/:tgId, so both client fetch routes share the
/get prefix. Gin resolves the static tgId segment ahead of the :email
wildcard, so /get/:email keeps matching plain email lookups, including a
literal 'tgId' email. The endpoint is unreleased, so no compatibility
concern.
|
||
|
Maksim Alekseev
|
041476a317 |
feat(sub): Add XHTTP session field compatibility in share links and subscriptions (#5929)
* ✨ Add sessionKey and sessionPlacement compatability for previous clients * ✨ Add sessionKey and sessionPlacement compatability for previous clients on backend |
||
|
Mr. Nickson
|
ff954ec48c |
fix: stop deleting client_traffics for detached-but-alive clients (#6110)
* fix: stop deleting client_traffics for detached-but-alive clients MigrationRemoveOrphanedTraffics keyed "orphaned" off presence in some inbound's settings.clients[] JSON, a definition that predates #4469's standalone clients table. ClientService.Detach intentionally keeps a client's traffic row when it drops its last inbound attachment (so it can be re-attached later without losing stats/expiry), but that client has no entry in any inbound's JSON anymore - so every x-ui migrate run or backup restore deleted its traffic row anyway, even though the client itself was untouched and still listed. Scope the query to the clients table instead, which is the function's actual intent. Separately, frontend/src/hooks/useClients.ts recomputed the clients summary from the client_stats WS snapshot as soon as it arrived, even when that snapshot held fewer rows than the server's own total (e.g. exactly the gap above, or any other client with no client_traffics row). The recompute can only bucket the clients it was given, so the missing ones silently fell out of every bucket while the headline total still counted them - the Ended/Disabled cards read 0 and their hover lists were empty even though the table below listed those rows, leaving the Filter drawer as the only way to reach them. Extracted the decision into pickClientsSummary and added the guard: fall back to the server summary (built from the clients table, always sums to total) whenever the snapshot doesn't cover every client. Fixes #6102. * fix: union both keep-sets instead of replacing (review feedback) Address the automated review on this PR: switching MigrationRemoveOrphanedTraffics to key solely off the clients table traded the original bug for a worse one. The one-shot ClientsTable seeder (internal/database/db.go) skips a client it fails to unmarshal and never retries, so a client still live in an inbound's settings.clients[] JSON can have no clients row at all - the new predicate deleted its traffic row too, and an empty clients table would have emptied client_traffics outright. Union both keep-sets: a row survives if it's referenced by either the clients table or any inbound's JSON, and is removed only when it's in neither. Log the delete's outcome instead of discarding it silently, since a whole-table wipe would otherwise leave no trace. Rewrote the migration test as a table of all four combinations, driven through real ClientService calls (SyncInbound, Detach) rather than hand-built rows wherever a real path produces the state, so it tracks actual behavior instead of an assumption about it. Added the missing case the review flagged: a client live in JSON only, with no clients row, must survive. Also stripped the // comments this PR had added - CLAUDE.md states committed Go/TS carries none, which the review separately flagged. |
||
|
H-TTTTT
|
8f49327efb |
feat(sub): allow identity tokens on every subscription link (#5935)
Keep usage tokens first-link-only while adding an opt-in setting for repeating EMAIL and USERNAME in subscription-body remarks. Co-authored-by: x06579 <x06579@ai-dashboard> |
||
|
n0liu
|
8bbca76bdd |
fix(sub): drop duplicated fingerprint in external-proxy tlsSettings (#6096)
applyExternalProxyTLSToStream wrote the external proxy fingerprint both to tlsSettings.fingerprint and to tlsSettings.settings.fingerprint, so the generated JSON subscription for an XHTTP Host group carried the same fingerprint twice. Every other field in this function writes a single location, and tlsData already emits fingerprint at the top level, so keep only tlsSettings.fingerprint. |
||
|
PathGao
|
a2774bf212 |
fix(ui): explain the REALITY client version gate and drop the impossible placeholder (#6125)
* fix(ui): explain the REALITY client version gate and drop the impossible placeholder An empty Min Client Ver looks unrestricted, but Xray-core silently falls back to a built-in minimum (currently 26.3.27) that rejects third-party cores such as Mihomo and sing-box with a bare REALITY verification failure, and nothing in the panel points at the field. Add tooltips to both version fields explaining the fallback and its TLS-fingerprint-freshness rationale. The Max Client Ver placeholder (25.9.11) sat below the built-in minimum, so filling in both placeholders produced a range that rejects every client. Remove it; empty genuinely means no upper limit for that field. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(reality): warn that an empty min client version rejects old cores Common pitfalls covered bad targets, SNI mismatches, leaked keys and wrong flow, but not the client version gate that currently bites Mihomo and sing-box users. Add it to all four doc languages. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ui): word the version hints against the effective minimum Address the automated review: the Max Client Ver hint said only 'not lower than Min Client Ver', which re-establishes the empty-means-unset mental model when the effective floor is the core's built-in minimum. Both hints now name the effective minimum and tie the quoted 26.3.27 to the core build the panel runs, since operators can install any Xray-core version. Also from review: full-width quotes and a missing verb in the zh doc bullet, the idiomatic Arabic opening, and a format-only x.y.z placeholder on Max Client Ver so the field still conveys its shape. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Jingyue Yao
|
48675ff197 |
style(i18n): normalize Chinese-English spacing (#6076)
Add consistent spacing between Chinese text and Latin terms in the Simplified and Traditional Chinese translations to improve readability without changing keys or placeholders. |
||
|
PathGao
|
604986598f |
fix(ui): commit date-picker selections immediately instead of on confirm (#6122)
* fix(ui): commit date-picker selections immediately instead of on confirm With showTime, Ant Design's DatePicker stages a clicked date until the OK button confirms it. Closing the dropdown any other way - clicking elsewhere in the form or hitting Create/Save directly - discarded the staged date without a hint, so an inbound saved this way ended up with expiryTime=0 (never expires). The Now shortcut commits in one click, which made it look like only the current time could ever be set. Drop the confirm step (needConfirm=false) and propagate every calendar selection through onCalendarChange, so the picked date reaches the form state the moment it is clicked and can no longer be lost to a race with the submit button. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * test(ui): pin calendar clicks committing without a confirm press A clicked day cell must reach onChange with the exact selected timestamp while the dropdown is still open, and the footer must not render a confirm button. Pins the needConfirm-free behavior so a picker dependency bump cannot silently bring the staged-value discard back. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Sanaei
|
b6473004ac |
fix(ci): harden the conflict resolver against the branch it checks out
resolve-conflicts is the one job that puts a pull request's own tree in the working directory while holding CLAUDE_CODE_OAUTH_TOKEN, CLAUDE_BOT_PAT and a write-scoped token, which is what CodeQL alert 101 (actions/untrusted-checkout) points at. Nothing in the job executes that tree and the trigger is gated on the repository owner, so the alert is not reachable as written, but two of its guards were weaker than they read. Git hooks were neutered only after gh pr checkout had already run, so the guard sat one step behind the checkout it exists to cover; it now precedes it. The conflicted paths are concatenated into the --allowedTools value handed to the model, so a path carrying a comma or a parenthesis would widen that allowlist. Only both-modified paths reach that code today, which means they already exist in the base repository, but the merge is now handed back to the maintainer unless every conflicted path is plain [A-Za-z0-9._/-]. The file's header comment block is dropped. |
||
|
PathGao
|
579acbc669 |
fix(settings): keep the stored port when a port field is cleared (#6121)
* fix(settings): keep the stored port when a port field is cleared Clearing the panel-port, subscription-port or LDAP-port InputNumber fired onChange(null), which the handlers coerced to 0; on blur Ant Design clamped the empty field to min=1 and the next save silently persisted port 1. For subPort that breaks the generated subscription links; for webPort it moves the panel itself to port 1 and locks the admin out until the port is fixed via the x-ui CLI. Ignore null changes so clearing a port field snaps back to the last valid value instead of committing a bogus port. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * test(settings): pin cleared port fields to the stored value Clearing the subscription-port field must not reach updateSetting at all, while typed ports still pass through unchanged. Pins the fix so a handler refactor cannot silently reintroduce the clamped port 1. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Sanaei
|
4605f00a15 |
fix(nodes): keep the credential-presence flag on the node heartbeat push
The Nodes page cache is overwritten wholesale by the heartbeat websocket push, but the job broadcast a raw []*model.Node while the REST list returns []*service.NodeView. model.Node tags the api token json:"-" and carries no hasApiToken field, so every push stripped the flag the edit form reads to decide whether a token is already stored. One 5s tick after the page loaded, editing any non-mTLS node then failed with "Name, address, port and API token are required" — and stayed failed, because setQueryData refreshes dataUpdatedAt, so the query never goes stale and never refetches the intact REST payload. Broadcast the NodeView read contract instead. |
||
|
Sanaei
|
dc6a16019e |
fix(xray): reject configs xray-core refuses, and check the fixtures against it
The frontend's golden fixtures are the panel's model of an xray config, but nothing ever asked xray-core whether it would accept them: the snapshots only prove the Zod schemas agree with themselves. Building every fixture through the same config builders the panel hands its config to — conf.InboundDetourConfig for the full-config and AddInbound paths, conf.RouterConfig for ApplyRoutingConfig, conf.DNSConfig for the dns section — found seven the core refuses, three of them reachable from the panel's own UI. A refusal is not scoped to one inbound: the config fails to load and every inbound stays down. Hysteria: xray-core builds version 2 only, in both the protocol settings and the transport settings, but the inbound settings schema accepted any version from 1 up and its comment claimed upstream still supported v1. Both fixtures carried version 1. The schema now pins 2, GenXrayInboundConfig heals stored rows on the way out the way it already heals shadowsocks ciphers and wireguard peers, and the share link drops the dead hysteria:// scheme — the subscription server already emitted hysteria2:// for the same inbound. XHTTP uplinkDataPlacement: both transport forms offered "query", which the core has never accepted for that field (auto and body always, cookie and header in packet-up mode). Replaced with auto, which was missing, and the default label now names auto rather than body. FinalMask items: switching an item to the rand-driven array kind wrote packet:[] next to the rand. xray-core counts an empty array as a packet and every item kind is exclusive, so noise answers "len(item.Packet) > 0 && item.Rand.To > 0" and header-custom "exactly one item kind must be set". The editor now clears the packet, and GetXrayConfig strips the residue from rows already saved with it. The remaining four were stale fixtures: an xmc mask still on the usernames shape v26.7.28 replaced with profiles, a fragment mask with no length, and header-custom and noise items passing an array to the string packet kind — all shapes the panel's own editors cannot produce. golden_fixtures_xray_test.go keeps this from drifting again: every fixture in every category is built through xray-core on each run, with a self-signed pair standing in for the deployment certificate paths, so the next core bump reports which fixture it broke. |
||
|
Sanaei
|
fea6a20f7c |
fix(xray): stop the runtime user API from crashing xray-core
Exercising the whole XrayAPI surface against a real xray-core 26.7.28 (the version go.mod pins) turned up a way for ordinary panel activity to kill the core process, plus two smaller mismatches with what the core actually does. buildUserAccount picked the shadowsocks account type by falling through to a 2022 account whenever the cipher was not one of six hardcoded names. xray's legacy and 2022 inbounds cast the account they are handed without checking (proxy/shadowsocks/validator.go, proxy/shadowsocks_2022/inbound_multi.go), so the wrong type is not an error — it panics the core and drops every connection on the server. The fallback was reachable without any misconfiguration: autoRenewClients hands AddUser the client object straight out of the inbound's settings, where the cipher lives under "method", never "cipher", so every auto-renewed client on a legacy-cipher shadowsocks inbound took xray down. The xray-valid aead_* aliases hit it too. The cipher is now read from either key, matched with the same table (and case-insensitivity) the core's own conf package uses, and an unrecognized one is an error instead of a guess. The legacy shadowsocks validator is also the only one that accepts a second user under an email it already holds, and RemoveUser then drops just one of them — a disabled or expired client kept connecting. AddUser now drops the email first on that account type so a single removal fully revokes the client. GetTraffic skipped every stat the first time it saw it. xray creates a counter on a user's first use, so that dropped a new client's traffic for a whole polling interval, as did the counter reset after a core restart. Only the first poll of a process is a baseline now; later, unseen and rewound counters both count from zero. Also fixes three unchecked settings["method"].(string) assertions that panic the panel on a shadowsocks inbound whose settings carry no method, and bounds TestRoute's port so an out-of-range value cannot wrap into the uint32 the core is asked about. Tests: api_users_e2e_test.go drives add/remove for every protocol against a real core and asserts it survives each one (skipped unless XRAY_E2E_BINARY is set); the account-type, traffic-delta and renew paths get unit coverage. |
||
|
Sanaei
|
7f7b7e16a4 |
feat(xray): update xray-core to v26.7.28 and adapt panel
Bump xtls/xray-core to 5ca6f4b7d4dc (v26.7.28) and move the three binary pins (DockerInit.sh, the Linux and Windows URLs in release.yml) in lockstep so the in-process conf.Build() validation and the child binary agree. XMC finalmask (#6487) is the breaking change. The mask's `usernames` string list is gone, replaced by a required `profiles` array whose entries each need a 3-16 character [A-Za-z0-9_] username, a parseable UUID and both Mojang texture fields; the "default to Dream when empty" fallback was removed, so an xmc mask saved by an older panel now fails to build and takes the whole config down with it rather than degrading one inbound. The textures are a signed blob only Mojang's session server can issue, so a legacy username cannot be upgraded automatically. The panel now: - rejects an incomplete xmc mask at save time (AddInbound/UpdateInbound), pointing at the specific field that is missing; - drops only the offending mask when generating the core config, for rows that never went through the form (upgrade, node sync, restored backup, direct DB edit), warning which inbound lost its obfuscation instead of leaving every inbound offline; - carries legacy usernames into profile stubs in the finalmask form so the operator keeps their player names and sees exactly what still needs filling in, and edits profiles through a list editor. No destructive DB migration: unlike the removed shadowsocks ciphers there is no valid replacement to rewrite to, and dropping the mask from stored rows would discard the operator's hostname and password for config they can still repair. The generation-time strip already prevents the startup failure. Also track the core's xmux maxConnections fallback, lowered from 6 to 3 for anti-TSPU, in the fresh-XMUX seed so a new panel config matches what the core would pick on its own. TUN gained a `desc` key and random utunN naming, but the Go validator no longer accepts TUN inbounds and the panel only renders legacy saved rows, so nothing there needs adapting. The remaining commits are REALITY log-warning wording, gRPC/XHTTP localAddr accuracy and a routing tweak, none of which change the JSON config surface. Tests cross-check the panel's profile predicate against conf.XMCProfile.Build() so a future core release that tightens or relaxes the rules fails loudly rather than silently emitting configs the core refuses to start on. |
||
|
Sanaei
|
fd17255f1d |
Revert "fix(sub): keep the client identity on every subscription link (#6098)"
This reverts commit |
||
|
Sanaei
|
8bc00d1e90 |
style: drop the line comments added with the triage fixes
CLAUDE.md rules out // line comments in committed Go. The rationale they carried is in the commit messages for each fix; doc comments that already existed are kept, updated where the code they describe changed. Also replaces reflect.Ptr with reflect.Pointer and rewrites the YAML keyword alternation as a lookup table, both flagged by golangci-lint. |
||
|
Sanaei
|
6f4cc1e53c |
fix(xray): emit an empty client array instead of null in the generated config (#6117)
finalClients was a nil slice, so an inbound that has a clients key but whose clients are all filtered out — disabled by an admin, or cut by the traffic job for quota or expiry — was handed to xray-core as "clients": null. The panel already treats a stored null client list as invalid data and coerces it to [] at startup, and null is what reporters see in bin/config.json when they go looking for a connectivity problem, which sends the diagnosis after a serialization bug that is not there. Build the slice empty so the same state serializes as []. The reported inbound also needs the clients table to be in sync, which is a separate question still open on the issue. |
||
|
Sanaei
|
0e69f64e56 |
fix(job): bound the traffic-notify POST so a stalled receiver can't wedge it (#6115)
informTrafficToExternalAPI posted through the package-level fasthttp.Do, which carries no read or write deadline. Run() is scheduled @every 5s under cron.SkipIfStillRunning, so a receiver that accepts the connection and then neither answers nor closes did not just delay one notification — it held the job, and every following tick was skipped for the duration. What stops with it is more than counters: AddTraffic runs autoRenewClients and disableInvalidClients in the same call, so quota and expiry enforcement stall too, and an over-quota client keeps transiting for the whole hang. The online-client refresh and the websocket broadcasts sit later in the same tick. Give the endpoint its own client with read/write deadlines and a DoTimeout budget under the poll cadence, close the connection rather than pooling it for a call this infrequent, and skip the POST outright when there is nothing to report. Retries stay off: the payload carries per-tick deltas, so a resend after a failed response leg would double-count on the receiver. Verified against a listener that accepts and stalls: fasthttp.Do was still blocked after 8s, the new client returns at its 3s budget. |
||
|
Sanaei
|
7fe9932d7b |
fix(sub): quote Clash scalars a YAML parser would read as numbers (#6104)
A REALITY short-id like 2351e1 is valid hex, but as a bare YAML scalar the resolution rules read it as the float 23510. mihomo hex-decodes the resulting five-digit string, fails with "invalid REALITY short ID", and the whole provider loads zero nodes — one proxy takes the entire subscription down. The encoder quotes the forms it recognises (plain integers, hex, booleans) but not the exponent-float form, and its own parser reads that token back as a string, so nothing in a round-trip through it reveals the problem. Check the values against the resolution rules instead, and force quotes on any plain scalar that would resolve to a non-string. Applied to every string in the document rather than to short-id alone: the panel's own short-id generator emits random hex, and passwords, obfs- passwords and pre-shared keys reach the output the same way. Unambiguous values are untouched, so the document is otherwise byte-identical. The existing Clash tests assert on the config map, never on the serialized text, which is why this survived; the new tests assert on the output. |
||
|
Sanaei
|
c004c18d90 |
fix(sub): keep the client identity on every subscription link (#6098)
|
||
|
Sanaei
|
f8e9f2f087 |
fix(node): stop a departed master's frozen traffic from disabling clients (#6113)
client_global_traffics rows are keyed by (master_guid, email) and are only
ever overwritten by a push from that same master. A master that stops
pushing — decommissioned, reinstalled under a fresh GUID, or detached from
the node — therefore leaves its last snapshot behind permanently.
depletedClientsCond's cross-panel EXISTS branch matched any such row, so a
node kept comparing a client's quota against counters frozen weeks earlier.
Once they exceeded the quota the node disabled the client on every traffic
poll, and the node -> master enable merge latched that off on the master too,
where nothing sets it back. The reported symptom is exactly this: a client at
11 GB of a 24 GB quota, enabled on two nodes, disabled on the third, which
still held a 27-day-old row from a previous master reporting 30 GB.
Bound both the enforcement predicate and the display overlay to rows a master
refreshed within globalTrafficFreshWindow. Masters push every 30s, so a live
master is never affected; a master that is merely unreachable for a while
keeps enforcing for a full day before its numbers are set aside.
The one-way enable merge that makes such a disable permanent on the master is
deliberate (
|
||
|
Sanaei
|
5accd8a611 |
fix(ci): stop the conflict job trusting the branch it is merging
A second audit of the hardened workflow found the "no shell at all"
claim in resolve-conflicts was still false, by two routes that live
outside this file.
The job runs the model in the workspace right after `gh pr checkout`,
so for a fork pull request the working directory is attacker-controlled.
claude-code-action writes `enableAllProjectMcpServers = true` into
~/.claude/settings.json before starting Claude Code
(base-action/src/setup-claude-code-settings.ts), and the CLI honours a
project `.mcp.json` unless `strictMcpConfig` is set, which the action
never sets. A contributor branch carrying an `.mcp.json` therefore got
its command spawned at session start, with --allowedTools gating tool
calls but not server startup. The same tree also supplied CLAUDE.md and
.claude/ as project instructions. The job now passes
`--strict-mcp-config` and `--setting-sources user`, so nothing in the
merged tree configures the session.
The second route was `Edit` with no path scope, the only unscoped file
grant left. Editing `.git/config` to set `core.fsmonitor` or a
`credential.helper` gets a command run by the next step's git calls,
which hold CLAUDE_BOT_PAT, and the stray-file guard could never see it
because `git diff --name-only` lists tracked paths only. The merge step
now emits one `Edit(//<workspace>/<file>)` rule per conflicted path and
the model gets exactly those plus /tmp, with `.git/**` denied outright
and Bash, WebFetch, WebSearch and Task denied by name. Hooks are
disabled for the run (`core.hooksPath=/dev/null`, `commit --no-verify`).
Conflict handling gets three real gaps closed: modify/delete, rename and
both-added conflicts (git status DD/AU/UD/DU/AA/UA) leave no markers, so
they used to sail through the marker check and get committed unresolved
- they are now detected up front and handed back untouched; the marker
scan covers `=======` and `|||||||`, not just the outer pair; and after
staging, `git diff --diff-filter=U` must come back empty or nothing is
committed. A `=======` markdown underline of exactly seven characters in
a conflicted file will now hand the merge back rather than commit it,
which is the safe direction.
Smaller things the audit was right about:
- the mutating gh rules are prefix rules, so `Bash(gh issue close:*)`
reached every issue in the repository. They now carry the triggering
number: `Bash(gh issue close ${{ github.event.issue.number }}:*)`.
- `Write(//tmp/**)` is granted alongside `Edit(//tmp/**)`: the docs say a
Write(path) rule is never matched by the file checks, so the Edit rule
is what authorises it, but the tool has to be listed to exist at all.
Without this the model could not create /tmp/comment.md.
- the mention prompt lost its thread context when it moved to agent mode
and referred to "<number>" literally; it now gets repo, number, title
and whether the thread is a pull request.
- `git log`/`git show` are gone from mention: `--output=<file>` makes
them a file-write primitive.
- `@claude resolve pr conflicts` on a plain issue matched no job at all.
- the commit step gated on `skip != 'true'`, so it also ran when the
merge step died before writing any output; it now needs `skip ==
'false'`.
- bot-authored pull requests (dependabot opens three ecosystems' worth)
no longer start a review run that the action refuses to serve.
- resolve-conflicts drops to `contents: read`, since the push is the
PAT's job, and fails with a comment when that PAT is missing.
|
||
|
Sanaei
|
f46b1726cf |
fix(ci): close the write paths an audit found still open in the bot
Making the jobs read-only in the previous commit was not enough: two of the mechanisms that grant write access were invisible in the workflow file itself. Every job now passes a `prompt:` input. Without one, claude-code-action picks tag mode for a mention, and src/modes/tag/index.ts then appends `--permission-mode acceptEdits`, its own allowedTools including `Bash(git commit:*)` and a push wrapper, and calls setupBranch. So the mention job could edit files and commit them no matter what its own allowedTools said, and its system prompt claiming otherwise was simply wrong. A `prompt:` selects agent mode, which adds nothing. It also removes tag mode's hidden requirement that the comment contain the trigger phrase, which would have made resolve-conflicts a no-op for a comment that said only "resolve pr conflicts". resolve-conflicts no longer hands git to the model. `Bash(git:*)` is a prefix rule, so it permitted `git push origin HEAD:main`, `--force`, `git remote set-url`, and shell execution through `git config alias.x '!sh -c ...'` - the action ships scripts/git-push.sh precisely because `git push:*` allows `--receive-pack='sh -c ...'`. The job now splits in three: a step checks out the PR branch, merges the base and collects the conflicted paths; the model gets Read/Glob/Grep/Edit and no shell at all; a final step verifies and pushes. That step refuses to commit if a conflict marker survives, if the model wrote /tmp/ABORT, or if anything outside the conflicted set was touched, and it stages those paths individually instead of `git add -A`. The PAT is now written to the push URL only in that last step, after the model's session has ended, instead of sitting in .git/config while untrusted branch content is read. The bare `Write` grant in the three answering jobs becomes `Edit(//tmp/**)`, since only prose kept it out of the checkout and out of $GITHUB_ACTION_PATH, whose scripts run after the model step. Each prompt now says to fall back to an inline --body if the write is refused, so a denied write cannot silently cost a reply. mention gains the transcript upload and the no-reply guard the other jobs already have, keyed to the triggering comment's timestamp. Restores the header note about the 21000-character expression cap, with the current block sizes. |
||
|
Sanaei
|
acbb879f80 |
refactor(ci): make the bot read-only except for PR conflict resolution
The bot is meant to investigate and explain, not to write code. It could
do considerably more than that: handle-pr-fix applied fixes and pushed
them to any trusted author's PR, an @claude mention on a pull request
could edit files, and an @claude mention on an issue opened a pull
request against main. All of it is gone.
Now every job that answers automatically runs with a contents: read
token, so pushing is impossible rather than merely forbidden:
- handle-pr-fix is deleted. handle-pr-review takes every pull request
instead of only the ones from outside contributors, and it comments.
- mention drops contents: write, the push-URL routing step, and the
Edit tool. Its Bash allowlist is now an explicit read-only set - the
gh subcommands it needs plus git log/show/diff/blame - so gh api,
gh pr merge and gh pr create are no longer reachable. Asked for a
fix, it now writes the change out in full instead of applying it.
One narrow exception replaces all of that: resolve-conflicts. It runs
only when the repository owner comments "resolve pr conflicts" on a
pull request, and it may merge the base branch into that PR's head
branch and resolve the conflicts, nothing else. It keeps both sides of
every conflict, takes the base version of generated artifacts it cannot
regenerate here, and aborts the merge rather than guess when a hunk
needs a human. It never force-pushes, merges, or closes.
Also removes the pull-request-opening step whose guard never worked:
gh api prints the 404 body on stdout, so `ahead=$(gh api ... || echo 0)`
became `{"message":"Not Found",...}0`, never equal to "0", and every
reply-only mention run ended red on `gh pr create`. Uploads the
handle-pr-review transcript the way handle-issue already does, so a run
that dies inside the sandbox leaves evidence.
|
||
|
Sanaei
|
1358f65bec |
fix(ci): unbreak the issue-triage bot, which answered nothing
Since 2026-07-20 every `issues` run reported success while posting no comment at all - #6094 through #6103 carry zero replies. The cause is the sandbox, not the prompt or the model. `handle-issue` and `handle-pr-review` pass allowed_non_write_users, which is what lets the bot run for reporters who have no write access. claude-code-action reacts to that input by turning subprocess isolation on and installing bubblewrap, and that sandbox cannot start on the runner: every Bash call dies during setup, before the command itself runs, with bwrap: Can't create file at /home/.mcp.json: Permission denied `gh` is reachable only through Bash, so the triage investigated the issue, wrote its reply to /tmp/comment.md, and could never post it. The action itself did not crash, so the job stayed green. Opt both jobs out with CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=0. The scrub is a best-effort wipe of secrets from subprocess environments, not an access control; what actually bounds these jobs is unchanged - a contents: read token that cannot push, and a Bash allowlist holding only specific `gh issue`, `gh label`, `gh search` and `gh release` subcommands. Code changes stay confined to handle-pr-fix and mention, which only trusted actors and the owner can trigger. Add a step to each job that fails the run when no bot comment landed on the issue or pull request, so the next silent breakage shows up red instead of green, and lower retention-days to the repository maximum of 7 so the artifact upload stops warning. |
||
|
Sanaei
|
f4e79e70ea |
chore: refresh dependencies, fix Linux tool tasks, modernize Go idioms
Frontend deps: @hookform/resolvers 5.4.0 -> 5.4.3 and react-hook-form 7.82.0 -> 7.83.0. The @typeschema/valibot override is what makes this installable at all. Resolvers 5.4.3 re-declares 25 optional peers for its validator matrix, and npm resolves them into the ideal tree even though none are used here; two of them contradict, since resolvers wants valibot ^1 while @typeschema/main -> @typeschema/valibot pins valibot ^0.39. Both target the same node_modules/valibot, so a plain npm update dies with ERESOLVE. The override settles that one edge and nothing extra lands in node_modules. Backend deps: telego 1.10.0 -> 1.11.1 (Telegram Bot API v10.2, additive only), klauspost/compress 1.19.1, plus the indirect bumps that came with them. VS Code tasks: the golangci-lint and modernize tasks assumed Windows PATH semantics, where PATH is a persistent user variable that every process inherits, so ~/go/bin was always visible. On Linux that directory is exported from ~/.bashrc, which the non-interactive `bash -c` behind a task never sources, and both tasks failed with exit 127. Adds linux/osx option blocks that prepend the Go bin directories and leaves the Windows path untouched, plus tasks to install the two tools; those are split because go install rejects packages from different modules in one invocation. Go sources: modernize -fix output, covering range-over-int, slices.Backward, maps.Copy, strings.CutPrefix and strings.SplitSeq. Behaviour is unchanged. |
||
|
Sanaei
|
edb487a005 |
chore(deps): migrate to react-router 8 and refresh frontend dependencies
react-router-dom 7 is superseded by react-router 8, which folds the DOM bindings back into the core package. RouterProvider now comes from `react-router/dom`, while the hooks and `createBrowserRouter` move to `react-router`. Updates the nine importing modules and the router line in docs/architecture.md to match. Also refreshes antd, react-i18next, storybook, eslint, lint-staged and playwright to current patch/minor releases, and restores alphabetical order in devDependencies for the @vitest/browser-playwright and playwright entries. Bumps brace-expansion to 5.0.8, the only release outside the affected range of GHSA-mh99-v99m-4gvg (unbounded expansion length causing an OOM crash). `npm audit fix` could not apply this on its own: the lockfile pinned 5.0.7 and npm will not re-resolve a transitive-only dependency in place, so the entry was updated directly and reinstalled. |
||
|
Sanaei
|
35cf6be6f9 |
fix(ci): keep the triage prompt under the 21000-char expression cap
The previous commit pushed handle-issue's prompt to 21587 characters and
GitHub stopped parsing the file: "(Line: 39, Col: 19): Exceeded max
expression length 21000". Because the prompt interpolates ${{ }}, GitHub
treats the whole block scalar as a single expression, and the cap applies
per expression. The failure mode is quiet and total - no job fails,
the workflow itself disappears, its registered name reverts from "Claude
Bot" to the file path, and the only signal is a run attributed to the
push with no jobs in it.
Drop the hand-written stack description, repository map and runtime-fact
list from that prompt and point at CLAUDE.md and docs/architecture.md
instead. Both are maintained, both are already in the checkout, and the
copy in the prompt had drifted from them anyway - it still described the
mtg worker, omitted internal/tunnelmonitor/ and memory.high, and filed
internal/web/runtime/ under "wiring". Only the support-facing facts that
live in neither file are kept: the install one-liner, the random initial
credentials, the distro-dependent env file, the Docker image and the
capabilities fail2ban needs.
handle-issue is now 15069 characters, and a header comment records the
limit so the next edit does not rediscover it in production.
|
||
|
Sanaei
|
0f7329c3ce |
fix(ci): repair the Claude bot and narrow what it can reach
Three problems, all in .github/workflows/claude-bot.yml. It was silently dead. No comment had been posted since 2026-07-20 while every run reported success: roughly twenty issues and pull requests each burned 18-56 turns and up to $2.59, ended with permission denials, and published nothing. Comment bodies are markdown, markdown is full of backticks, and inside a quoted `--body "..."` backticks are command substitution, so the write was rejected and a failed triage looked exactly like a clean one. The body now goes to /tmp through Write and out through --body-file, in every branch of both jobs, and each job re-reads the thread afterwards so a rejected write fails loudly instead of reporting success. The run transcript is kept as an artifact. It could reach much further than it claimed. Both jobs that any GitHub user can trigger declared themselves READ-ONLY in prose while holding Bash(gh:*), which is not a GitHub-scoped allowlist: `gh alias set --shell` runs its argument through sh -c and `gh extension install` fetches and executes code, both as single commands whose first token is gh. That is a general shell on a runner holding CLAUDE_CODE_OAUTH_TOKEN, which does not expire with the job. `gh api` accepted any method, issues: write is repo-scoped rather than issue-scoped, and `gh pr review --approve`, `gh pr close` and `gh pr checkout` were forbidden in prose only. Those two jobs now list the subcommands they actually run. The untrusted title and body are fenced in tags carrying github.run_id, unguessable at the time the issue is written, and the invariants an allowlist cannot express - one issue number, labels and title only, /tmp as the sole writable path, never $GITHUB_ENV - are stated explicitly. Both checkouts get persist-credentials: false. handle-pr-fix and mention keep their wildcards: only owners, members and collaborators can trigger them, and narrowing the maintainer's own path risks more than it protects. Its review hid findings and its triage quoted stale facts. "Prefer a few high-signal findings over many low-value ones" is read literally by Opus - it finds the bug, judges it below the stated bar and says nothing - while the Severity and Confidence tiers already existed to do that filtering. The review also never said that the working directory is the base revision, so it could assert that a case was unhandled in code the pull request had already rewritten, and label it confirmed, on an outside contributor's first patch. Four CLAUDE.md conventions were missing, each a guaranteed miss: openapigen's StructAllow allowlist, the layering rules including the runtime.Runtime dispatch requirement that silently breaks multi-node when bypassed, the assertion standard, and golden share-link fixtures regenerated to turn a red test green. On the triage side the invalid and duplicate branches were gated three times over and so never fired, leaving spam to collect a full investigation and a courteous reply; /etc/default/x-ui was given as the env file when it is distro-dependent, making the PostgreSQL migration advice a silent no-op on RHEL and Arch; an env list labelled "full" omitted XUI_PORT and the XUI_TUNNEL_HEALTH_* family; XTLS was offered as a security option the panel does not have. docs/architecture.md was invisible to both prompts despite being maintained and already in the checkout. From the bot's own output: it published a trigger only the maintainer can use, retitled issues without saying so, asked for screenshots it cannot open, and once invented a reason for a number it had miscounted. All four jobs move to Opus 5, at xhigh effort rather than max - the recommended tier for agentic work, and one below the overthinking that max invites on routine triage. |
||
|
Sanaei
|
29557e2153 |
fix(sub): gate the VLESS flow in JSON subscriptions like raw and Clash links
genVless emitted client.Flow unconditionally, while the raw link (service.go:806) and the Clash proxy (clash_service.go:251) both gate it behind vlessFlowAllowed. A flow_override left on client_inbounds after its inbound moved to a transport Vision cannot use -- ws, grpc, httpupgrade -- therefore survived only into the JSON subscription, handing that client an outbound xray-core rejects while its other two formats were correct. Apply the same gate at the call site, reading the network from the per-host stream so a host that rewrites the transport is judged on what it actually emits. Verified by seeding a flow_override on a ws+tls inbound: before, raw and Clash dropped the flow and JSON kept it. |
||
|
Sanaei
|
0b60154383 |
fix(docs): force transitive sharp up to patched 0.35.3
sharp <0.35.0 inherits four libvips CVEs (GHSA-f88m-g3jw-g9cj). It comes in as an optional dependency of next, which still declares ^0.34.5 on its current release, so only an override reaches the fixed line. Brings libvips 8.18.3 via @img/sharp-libvips-* 1.3.2. |
||
|
Sanaei
|
c3967e57dc |
perf(clients): take one email snapshot per client fan-out, not one per inbound (#6091)
Create and Attach called the exported AddInboundClient once per target inbound, and that wrapper passes a nil email→subId map, so every iteration re-ran getAllEmailSubIDs -- a JSON_EACH expansion over the settings blob of every inbound in the panel. Adding one client to 24 inbounds on a panel with ~300 users meant 24 full expansions of ~7k rows to answer the same question. Hoist the snapshot above the loop and call the unexported addInboundClient with it, exactly as BulkAttach (client_bulk.go:63) and BulkCreate (client_bulk.go:1151) already do. The snapshot goes stale from the second inbound onward, but the identity being added is the same on every iteration, so its own entry can only ever match itself -- checkEmailsExistForClients accepts an email whose stored subId equals the incoming one, and an absent entry is accepted too. This is the database half of #6091. The dominant cost there is the other half -- one synchronous 10s-capped node round-trip per remote inbound, which multiplies again on chained nodes -- and that needs the push batched per node rather than per inbound; left for a separate change. |
||
|
Sanaei
|
aa60d54ea5 |
fix(wireguard): widen the client address pool past a full /24 (#6089)
allocateWireguardAddress scanned exactly one /24, so a WireGuard inbound was hard-capped at 254 clients with no way out -- the pool is not configurable anywhere in the UI or API. Fill the inbound's own /24 first, then widen to the enclosing /16 instead of failing. A wireguard inbound carries no interface subnet and xray routes purely by each peer's allowedIPs, so nothing constrains the wider address. Capped at /16 to keep the worst-case scan bounded; IPv4 only. |
||
|
Sanaei
|
a652cb8cea |
fix(clients): keep a client editable when its subId is already shared (#6065)
The subId collision check in Update ran on every save, unlike the email
check above it. Because Update defaults an omitted subId to the stored
one, any client already sharing a subId was rejected on every later edit
-- even a pure totalGB or expiry change that never mentions subId.
Gate the check on an actual change. Pre-existing duplicates are reachable
because SyncInbound has no such check, and
|
||
|
Sanaei
|
cd674c8d4f |
feat(sub): expose live online status and add ?format=info endpoint
Custom subscription templates only received the lastOnline timestamp, so template authors had to fake an online indicator by comparing it against the current time, and the page was a one-shot server render with no way to refresh usage without reloading the whole HTML. The template context (and window.__SUB_PAGE_DATA__) now carries isOnline, computed from the panel's own online-client tracking (local xray plus remote nodes) at render time. The subscription URL also answers ?format=info with the page view-model as JSON — minus the links, with emails deduplicated — so templates can poll live status cheaply. The shared view-model construction moved into buildSubPageData/subPageContext so the HTML page, the SPA payload and the info JSON cannot drift apart. Also documents the previously injected but undocumented announce template variable. |
||
|
Sanaei
|
b319dd0c3a |
fix(panel): align telegram icon with its label in home card actions
The .tg-icon override (display: inline-block; vertical-align: -2px) defeated the default .anticon flex centering that every other card action icon relies on, so the icon rendered ~2px below the @XrayUI text. Dropping the override lets AntD center it like its neighbors. |
||
|
Sanaei
|
8ef2eec3d1 |
fix(hosts): assign group ids to imported hosts and repair empty ones
Host rows created from a legacy streamSettings.externalProxy during inbound import got an empty group_id, and the one-time HostGroupIds seeder had already been gated off, so the UI rendered them under a synthetic fallback_<id> group the update/delete API could not resolve, failing every edit with "host group not found". Assign a real group id in externalProxyEntryToHost at creation, and replace the seeder with backfillEmptyHostGroupIds, an idempotent startup repair that runs on every boot so rows from older builds and restored backups are healed too. Also rename the leaked internal error "host group not found" to "host not found" since groups are not a user-facing concept. |
||
|
Sanaei
|
941c6116a9 |
chore(openapi): regenerate schemas with int64 formats on node fields
Output of make gen: the generator now stamps format int64 on the node status schema's 64-bit integer fields (timestamps, net counters, uptime), syncing the committed OpenAPI doc and generated schemas with the Go structs. |
||
|
n0ctal
|
c77608bc47 |
fix(nodes): make node API tokens write-only (#5613)
* fix(nodes): make node API tokens write-only * fix(nodes): keep token optional on edit for write-only API tokens NodeView no longer returns apiToken, so the edit form must consume hasApiToken and not require re-entering the token. Relaxes the form validation on edit, adds a keep-current placeholder, and adds the i18n key to all 13 locales. |
||
|
Sanaei
|
892c06c8bc |
Bug-label issue sweep: 16 fixes (#6083)
* fix(xray): block private-range egress in default freedom finalRules (#6037)
With domainStrategy AsIs the router never resolves domains, so a domain
with a private A record (e.g. 127-0-0-1.nip.io) sails past the
geoip:private routing block and freedom's allow-all finalRules let it
reach loopback services such as the xray gRPC API and metrics listener.
Prepend a block rule for geoip:private to the default template and add
the FreedomFinalRulesPrivateEgressBlock seeder so existing installs
still carrying the stock allow-only (or legacy private-only-allow)
finalRules are upgraded in place; customized rules are left untouched.
* fix(sub): version-gate unencrypted-outbound drops in outbound subscriptions (#6033)
Commit
|
||
|
Sanaei
|
16b9b3ce1c |
chore(deps): bump docs and frontend dependencies
Routine minor/patch updates: Next.js 16.2.11 + eslint-config-next, fumadocs, React 19.2.8, Storybook 10.5.3, and assorted tooling. Docs stays on ESLint 9 (^9.39.5): eslint-config-next pulls in eslint-plugin-react 7.37.5, whose newest release still calls the context.getFilename API that ESLint 10 removed, so eslint crashes on every file under ESLint 10. The frontend workspace already ran ESLint 10 without eslint-plugin-react and is unaffected. |
||
|
Yuri Khachaturyan
|
2b1308ca29 |
feat(notifications): add a consecutive-failure threshold for outbound.down alerts (#5968)
Problem: a flaky outbound produces hundreds of false-positive "outbound down" notifications overnight — each fires the moment xray's observatory reports a single failed probe, and the next successful probe fires an "up". applyObservatory forwarded every raw alive:true->false transition straight to EventOutboundDown; xray's observatory has effectively no hysteresis, and nothing on the panel side debounced it (the email/Telegram subscribers are pure formatters). Fix: debounce per outbound. outbound.down now fires only after outboundDownThreshold consecutive FAILED probes (new setting, default 3); outbound.up fires immediately on the first successful probe and only when a down was actually notified. The threshold gates the event itself, so email and Telegram share one knob (exposed next to the outbound.down toggle). The streak counts genuinely new probes (last_try_time advancing), not sampler polls — the sampler runs every 2s but the observatory re-probes per its probeInterval, so counting samples would trip the threshold instantly. outboundDownThreshold=1 reproduces the legacy notify-on-first-failure behaviour. Tuning the observatory's probe interval/timeout is not a workaround: those probes also drive the load balancer's outbound selection, so loosening them to quiet notifications would slow real failover away from a genuinely dead outbound. Notifications don't need observatory-grade latency, so the tolerance belongs at the notification layer, leaving the observatory (and balancer) untouched. Adds TestApplyObservatoryDebounce covering the threshold, probe-vs-sample counting, single-blip suppression and the legacy path. Co-authored-by: Yuriy Khachaturian <y.khachaturian@souzmult.ru> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Blazethan
|
9e117bbdd3 |
fix(clients): keep VLESS xtls-rprx-vision flow when inbound options reload (#5971)
The client form cleared the `flow` field whenever `showFlow` was false, but `showFlow` is derived from the inbound options list, which is transiently empty while the options query (re)loads (`inboundOptionsQuery.data ?? []`). During that window `showFlow` is a false negative, so the effect silently dropped a valid `xtls-rprx-vision` flow the user had picked for a Reality/TLS inbound and never restored it — the client was then saved with an empty flow and could not connect with XTLS Vision. Guard the clear so it only runs once the inbound options are actually available. Adds a regression test that reproduces the drop across an options reload. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Mr. Nickson
|
8cd71e07ea |
fix: refresh stale client_traffics row when an inbound-deleted client's email is reused (#6003)
* fix: refresh stale client_traffics row when an inbound-deleted client's email is reused AddClientStat's OnConflict was DoNothing on email, so once an inbound is deleted (DelInbound only removes the client_inbounds link, matching ClientService.Detach's intentional Detach-then-later-Attach behavior) the orphaned client_traffics row for that email survives untouched. Re-creating a client under the same email on a new inbound silently kept the old enable/expiry_time/reset/total/inbound_id instead of adopting the new client's config. Switch the conflict path to DoUpdates on inbound_id/total/expiry_time/ enable/reset. up/down stay excluded on purpose: every call for an already-attached identity carries the same config values (one call per inbound), so the refresh is a no-op for that legitimate multi-inbound share, while zeroing usage counters on each additional attach would erase real traffic. Fixes #5958 * fix: don't let AddClientStat clobber import's forced-enabled ClientStats rows github-actions[bot] review on #6003 found that AddInbound writes client_traffics twice for the same import payload: first inserting each ClientStats row (DoNothing, with Enable forced true by controller.importInbound), then calling AddClientStat once per Settings-derived client. With AddClientStat's OnConflict now DoUpdates, that second call was unconditionally overwriting enable (and total/expiry_time/reset/inbound_id) with the Settings.clients[].enable value — which still holds whatever the client had at export time, silently undoing the controller's "always import as enabled" behavior for any client disabled at export. Fix: track which emails were already seeded by the ClientStats loop and skip the AddClientStat call for those emails, leaving the import path's forced values as authoritative. Plain (non-import) creates are unaffected since ClientStats is empty there, so every client still goes through AddClientStat's refresh as before. Also updated a stale comment in addClientTraffic that still described AddClientStat as DoNothing. Added TestAddInbound_ImportForcedEnableSurvivesDisabledSettingsClient, which reproduces the exact regression (verified it fails without this fix) and passes with it. |
||
|
Seyed Ali Shahrokhi
|
79e65f63df |
fix(xray): validate generated egress targets (#5989)
* fix(xray): validate panel egress target Avoid generating a loopback panel bridge and routing rule when a saved panel outbound disappears after an outbound subscription refresh. Preserve routing unchanged and log the missing target instead. * fix(xray): guard node and mtproto egress Apply the fail-closed target check to every generated egress bridge. Skip node and MTProto bridge injection when a selected outbound disappears or the relevant JSON cannot be parsed. * test(xray): complete node egress coverage Cover tag and port collisions plus absent and malformed routing. Clarify the fail-closed bridge behavior in the panel and MTProto egress documentation. |