155 Commits

Author	SHA1	Message	Date
MHSanaei	c5e1e54c75	fix(xray): keep XDRIVE storage and Vision flow within what xray-core runs ... xray-core opens an XDRIVE stream's storage only when the inbound starts listening, so a Google Drive inbound saved with the form's defaults (no folder, no secrets), a local one without a folder, or a template one whose template xray cannot use stopped xray and every other inbound with it. validateXDriveStorage applies the core's storage rules at save, on inbound add/update and on the xray template's inbounds and outbounds: the service must be local, Google Drive or template; local and Google Drive need a remoteFolder; Google Drive needs its three non-empty secrets; a template must pass newTemplateStorage's checks (put, get, list and delete urls, and a list namesRegex with one capture group). A VLESS client kept its xtls-rprx-vision flow when its inbound moved to a transport that cannot carry it, and GetXrayConfig only honoured DisableFlow, so the server demanded Vision there and refused every client. GetXrayConfig and the outbound form now apply the Vision gate, and that gate now follows the core in the backend, the subscription service and the frontend: TLS/REALITY on raw TCP, or VLESS encryption on any transport (xray runs Vision inside encryption.CommonConn whatever the transport, not only on XHTTP). The outbound modal passes the VLESS encryption into the gate and gates Mux on the effective flow.	2026-10-12 00:49:11 +02:00
MHSanaei	c20082d254	refactor(inbounds): drop the single-user shadowsocks inbound paths ... isSSMultiUser treated 2022-blake3-chacha20-poly1305 as a single-user inbound, and the inbounds page grew a row QR modal, a separate link panel in the info modal and a client-count skip for that case. The method is no longer allowed on inbounds, so every shadowsocks inbound carries clients and those paths cannot be reached: remove them along with the inbound-level QrCodeModal they alone opened.	2026-10-11 21:24:25 +02:00
MHSanaei	f1ed1a9b17	fix(inbounds): refuse 2022-blake3-chacha20-poly1305 on shadowsocks inbounds ... xray-core builds a Shadowsocks-2022 inbound with users only for the AES methods: the multi-user identity header is AES-only, so the config builder and the multi-user server both reject chacha20. Every panel inbound carries clients, so picking 2022-blake3-chacha20-poly1305 in the inbound form kept the whole core from starting; its links also failed on the client with "multi-key is not supported". The inbound form no longer offers the method and AddInbound/UpdateInbound reject it. Startup moves stored inbounds to 2022-blake3-aes-256-gcm, which takes the same 32-byte keys, so every stored key stays valid. Outbounds keep the method, since a single-key outbound to such a server works. The share-link generator drops the single-user branch that only this method reached.	2026-10-11 21:20:07 +02:00
MHSanaei	0466e8b0bd	fix(finalmask): refuse a salamander password xray-core cannot open ... xray-core needs a salamander (and gecko) password of at least 4 bytes (smPSKMinLen), but checks it only when a socket opens: xray run -test reports Configuration OK. On an inbound the listener then fails and Xray does not start at all, taking every other inbound down; on a client the dial fails. The panel saved any password, and the finalmask editor starts a new salamander mask with an empty one. maskcompat.CheckSalamanderPasswords applies the core's byte rule, pinned against the core's own ListenPacket, and every path that stores a finalmask refuses a short password: inbound add and update, hosts, the subscription's global finalmask, and the inbounds and outbounds of the Xray template. The editor flags it inline as it is typed.	2026-10-11 18:26:45 +02:00
MHSanaei	6321297f68	fix(finalmask): keep a single udphop mask last in every client finalmask ... xray-core reverses finalmask.udp and refuses, at dial time, a mask that dials its own socket (udphop) anywhere but the socket end: "incorrect index". xray run -test still says Configuration OK, so the failure only shows as a client that never connects. UDPHopClientMaskFix turned a global subJsonFinalMask hop and a host hop into udphop masks; the JSON subscription then appended both, leaving two hoppers with the first one misplaced, and a host mask merged after a global hop pushed it off the end too. A hand-ordered template outbound or an imported fm= could carry the same order. maskcompat.NormalizeUDPHop keeps the last-listed udphop alone at the end of udp, and runs wherever a client finalmask is produced: each JSON subscription endpoint, share-link fm=, the Go and frontend link importers and the template outbound heal in GetXrayConfig. The JSON subscription resolves competing hop ranges most specific first: a host hop wins over the inbound's own, which wins over the global default.	2026-10-11 18:02:12 +02:00
MHSanaei	c7d89ceac2	feat(outbounds): TLS for XDRIVE outbounds ... xray-core 26.10.10 dials an XDRIVE outbound's storage API with the stream's tlsSettings: their SNI, uTLS fingerprint and ALPN are what the API sees, which is the point of fronting it. canEnableTls kept XDRIVE out of the TLS-capable networks, so the security picker never offered TLS and switching a TLS outbound to XDRIVE silently reset it to none. canEnableOutboundTls admits a TLS-eligible protocol on xdrive and backs both the picker and the network-change cascade. Inbounds keep the plain predicate: their tlsSettings carry server certificates, not a client hello. Also restores the plain oxfmt / oxlint --fix lint-staged commands, reverting da6872a3: that hook change was not wanted.	2026-10-11 16:05:35 +02:00
MHSanaei	1c050f872a	feat(finalmask): header-custom variables, sudoku UDP mask and noise reset ranges ... xray-core 26.6 grew the finalmask surface the editor could not express, and the finalmask watch drops any key without a registered field, so a config written by hand lost these keys on the next save: - header-custom items can capture their bytes into a variable, reuse one or emit a transform expression; a Kind select keeps each item to exactly one kind, as the core requires, and only parsed JSON reaches transform; - TCP header-custom gains the errors group (the reply sent when a client group does not match), UDP header-custom its prefix/standalone mode; - sudoku is offered as a UDP mask, and share links keep it in fm=; - the noise reset is an Int32Range, so it now takes "60-120" as well. The new golden fixture is saved unchanged by the outbound editor and built by xray-core in TestGoldenStreamFixturesBuildInXray.	2026-10-11 15:27:19 +02:00
MHSanaei	ec0a57fc4f	fix(finalmask): hop client UDP through the udphop mask ... xray-core 26.9.9 dropped finalmask.quicParams.udpHop for the client-only "udphop" UDP mask {mode, interval, remoteIPs, remotePorts}. The panel kept writing the old key, so hysteria/xhttp outbounds and JSON-subscription clients silently stopped hopping ports. An inbound keeps quicParams.udpHop: it is panel metadata advertised as the link's mport, and a udphop mask on a listener fails with "udphop: client only". The conversion (maskcompat.UpgradeLegacyUDPHop, intervalRemote mode) runs only where a client config is produced: - UDPHopClientMaskFix seeder over hosts, sub-JSON finalmask, cached outbound-subscription outbounds and template outbounds (never inbounds); - GetXrayConfig heals template outbounds at build time; - the JSON subscription upgrades each generated client stream; - the Go and frontend link importers upgrade a legacy fm= param. The finalmask editor gains a side prop: the client side lifts the dead key on mount and offers a udphop mask editor (also for xhttp's HTTP/3 dial); the inbound side keeps the UDP Hop switch, labelled as advertised.	2026-10-11 11:20:34 +02:00
MHSanaei	b04039c2bd	feat(xray): add the MASQUE protocol and transport ... xray-core v26.10.10 serves MASQUE: CONNECT-IP over HTTP/3 or HTTP/2, always behind TLS, as an inbound and an outbound protocol riding a dedicated "masque" transport. The panel could not create either. Inbound: MASQUE is a multi-user protocol whose users log in with their email and password over Basic auth. The panel keeps the client's "password" like trojan and GenXrayInboundConfig hands it to the core as "pass", so the full-config path, the live AddInbound path and node pushes all emit what the core reads; one user with an empty pass makes the core refuse the whole inbound. Live user adds build a masque.Account from either key, client-only changes diff per user so a new client does not drop every connected tunnel, and client creation, copy, validation and edits key on the password. The address pool and MTU get form fields, TLS is mandatory, and the port check follows the core's listener choice: HTTP/2 on TCP when the ALPN offers h2, HTTP/3 on UDP when it offers h3 or not h2. Nodes may host MASQUE from v3.9.1, the first panel release that knows to rename the password. MASQUE has no share-link format, so links and Clash skip it; the JSON subscription builds the client's masque outbound with its email and password, and the subscription allowlist now lets a subId see MASQUE inbounds at all. The IP-limit job, client pages and traffic tracking list the protocol. Outbound: the form edits the server, remote DNS, and the transport's host, path, Basic credentials, headers and WARP block (enrolled key, endpoint public key, tunnel addresses), which xray-core refuses next to user/pass. The outbound test probes it through the core, since its default HTTP/3 dial is UDP.	2026-10-11 10:28:49 +02:00
MHSanaei	ca5983595b	feat(xray): add the XDRIVE transport ... xray-core v26.10.10 tunnels a stream through files in shared cloud storage ("network": "xdrive"): Google Drive, a local folder, or any HTTP storage API described by a template. The panel could not select it, and the stream schema rejected a pasted xdrive stream outright. The inbound and outbound forms now offer XDRIVE with one shared editor: service, folder, the three Google Drive secrets in the order the core reads them, a template JSON editor with its {secretN} values, the optional domain front (the stream-level address/port the storage client dials), and the core's tuning knobs with their defaults as placeholders. Switching an inbound to XDRIVE resets security to none, because the core would otherwise read the inbound's TLS/REALITY as the storage API's client TLS. XDRIVE has no share-link format, and a link carrying the storage secrets would print them into every QR code, so both link generators emit none for it; the JSON subscription already passes the stream through intact, and Clash drops the unknown transport.	2026-10-11 08:21:08 +02:00
MHSanaei	73a028f52d	feat(xray): update xray-core to v26.10.10 and adapt panel ... Move the three Xray binary pins (DockerInit.sh, both release.yml fetches) to v26.10.10, in lockstep with the xtls/xray-core module that 82c77111 already bumped to 701af60772cd. xdns finalmask (#7090): a domain now takes a "names" list instead of a single "name", and a resolver is an "addrs" list of udp:// or tcp:// URLs instead of {type, settings:{addr}}. The loader ignores the old keys rather than failing, so every mask the 26.9.30 seeder wrote would load with no domain and no resolver and the tunnel would carry nothing. maskcompat.UpgradeLegacyXdns now lifts both the pre-26.9.30 string lists and the 26.9.30 objects straight to names/addrs, dropping entries the old loader refused. A new seeder (XdnsFinalmaskNamesAddrsFix) reruns it over every stored finalmask, and the save path, GetXrayConfig, both link importers and the mask editor's mount lift go through it. Template outbounds now get the build-time heal too: a 26.9.30 template pasted after the seeder passes the save check, since the core loads that shape without error. The editor edits names and addrs as tag lists and no longer requires record types, which the core now defaults (TXT on a client, A/CNAME/TXT/AAAA on a server). The wire format did not change, but clients on an older core cannot read the new config shape. Lua scripts (#6823): dns.script, routing.script and dns servers[].id are new. The xray page parsed the dns block with a strict schema, so loading it dropped script and id and the next save deleted them; the schema now keeps both and the DNS server modal carries the id through an edit. The hot routing apply built routing in-process, and that build now resolves the script file from the panel's working directory, so a script beside the xray binary failed every rule change into a full restart and broke the node bridge. RoutingService cannot change the script anyway, so the panel no longer resolves it there. TLS client roots (#7105): the core now verifies against its bundled Mozilla roots instead of the OS store unless tlsSettings.useSystemCA is set. The outbound TLS form gets a switch for it, so an outbound to a server signed by a privately installed CA can opt back in.	2026-10-11 07:55:12 +02:00
Leslie Alexander	66234315e4	fix(panel): default TLS ALPN to http/1.1 for WebSocket transport (#6787) ... * fix(panel): default TLS ALPN to http/1.1 for WebSocket transport WebSocket bootstraps over HTTP/1.1: leaving ALPN at the schema default ['h2','http/1.1'] makes the server negotiate h2 and the WS handshake fails. See issue #6782. * style(frontend): keep comments within the two-line limit * style(frontend): keep comments within the two-line limit	2026-10-11 07:17:05 +02:00
MHSanaei	d7da64f2f0	fix(qr): hide the QR only for links carrying post-quantum keys ... A share link's QR is suppressed only when it carries a post-quantum key payload too large to scan: an ML-DSA-65 verify key (pqv) or an ML-KEM-768 VLESS-encryption auth key. isPostQuantumLink substring-matched "mlkem768" anywhere in the URL, so it misfired on: - every VLESS/Trojan REALITY link, since ce221c33 added the support-x25519mlkem768=true hint (235 chars, QR version 10); - every VLESS-encryption link authenticated by an X25519 key, whose value always starts with mlkem768x25519plus (321 chars, version 11); - any remark or host containing mlkem768 / mldsa65 / ML-KEM-768. All four QR surfaces (inbound QR, client QR, client info, public sub page) lost their QR button for those links. The detector now reads the query: a non-empty pqv, or an encryption whose auth key vlessEncryptionAuthKind classifies as ML-KEM-768. Closes #6730	2026-10-05 16:30:14 +02:00
Egor	0054e671f8	feat(tuic): implement native in-process Go TUIC v5 server (#6577) ... * feat(tuic): implement native in-process Go TUIC v5 server - Implement native TUIC v5 protocol server on pure Go using quic-go - Bridge decrypted TCP/UDP traffic into Xray-core via loopback SOCKS5 inbound - Support full Xray routing rules (geosite/geoip) and cascading outbounds - Implement atomic per-client traffic accounting with TotalGB and ExpiryTime - Add automatic legacy cleanup for older Rust tuic-server binaries, configs, and orphaned processes - Eliminate external Rust tuic-server downloads from install/CI scripts * fix(tuic): address traffic accounting, client reload, and socket lifecycle issues * fix(service): update checkTuicSocksReverseConflict to use bindAddr for listenOverlaps * fix(tuic): resolve traffic double-accounting, UDP fragmentation, and socket lifecycle issues * feat(tuic): complete native Go integration and address audit findings - Integrate an isolated QUIC fork pinned to a specific commit - Preserve original QUIC dependencies for Xray, Hysteria and Gin - Apply BBR, CUBIC and Reno to server connections and exported client profiles - Bridge Xray BBR with correct monotonic time and congestion type conversions - Handle congestion sender recreation after PMTU changes - Update congestion control for new connections without restarting the listener - Preserve existing connections and their selected congestion controller - Apply per-inbound log levels through the shared panel logger - Add lifecycle, authentication and TCP/UDP relay events without exposing secrets - Rate-limit repeated authentication and relay warnings - Support native and QUIC UDP relay modes on the same listener - Recover UDP associations after relay worker failures - Fix TCP relay cancellation, idle shutdown and half-close handling - Close active sessions when client credentials are revoked or disabled - Track traffic by immutable client statistics IDs across email and UUID changes - Prevent ambiguous accounting and duplicate UUIDs within TUIC inbounds - Persist pending traffic in a durable shutdown journal - Replay journal batches transactionally without duplicate accounting - Report server shutdown failures through the shared logger - Preserve legacy flat and nested TUIC settings compatibility - Normalize congestion controller values consistently across backend and frontend - Preserve controller, UDP mode and SNI in client links and subscriptions - Separate client profile options from server settings in the TUIC form - Keep certificate path autofill explicit when changing client SNI - Align UDP packet size validation with protocol limits - Simplify and localize TUIC field hints and certificate autofill messages - Add controller, TCP/UDP, logging and live settings update tests - Add accounting identity, journal replay and shutdown regression tests - Add relay recovery, session revocation and legacy frontend form tests * fix(service): alias the TUIC duplicate-UUID subquery for PostgreSQL < 16 syncInboundClients runs a COUNT(*) FROM (subquery) for every client sync, whatever the protocol. PostgreSQL before 16 rejects a FROM subquery with no alias, so on the distro PostgreSQL install.sh provisions (14 on Ubuntu 22.04, 15 on Debian 12) every client add or edit failed with SQLSTATE 42601. Reproduced against postgres:15 with the new env-gated test. * fix(database): create tuic_traffic_receipts through the model migration AddTuicTrafficBatch issued CREATE TABLE IF NOT EXISTS at runtime, a schema change outside db.go. The table was invisible to allModels and migrationModels, so x-ui migrate-db dropped the receipts and a retained journal could be counted twice after a SQLite to PostgreSQL move. It is now a GORM model in both lists, and the insert uses OnConflict DoNothing. * chore(tuic): skip the ICMP-dependent relay test on Windows, drop dead collectors Go disables SIO_UDP_CONNRESET on Windows, so a dead UDP bridge never fails a read there and TestAudit3UDPAssociationMustRecoverAfterBridgeReadFailure was red on every Windows run. Server.CollectTotalTraffic and Manager.CollectTraffic had no caller. * refactor(tuic): serve TUIC on apernet/quic-go instead of a personal fork The native server depended on github.com/poise52/quic-go, a personal fork of apernet/quic-go patched only to pick the congestion controller before the handshake. That put a second QUIC/TLS stack in the binary that no upstream security fix reaches. apernet/quic-go is already in the graph through xray-core and exposes SetCongestionControl, so BBR is now installed on each accepted connection with Xray's own congestion.UseBBR; the cross-module BBR adapter is gone. apernet ships New Reno as its only built-in sender, so a cubic setting is served as new_reno server-side (clients still get cubic in their profile). The test inspectors now read the sender under congestionMutex, which the post-handshake install writes under. Linux loopback, single stream through Xray: 2428 -> 3383 Mbit/s (bbr). --------- Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>	2026-10-03 02:56:02 +02:00
Farhan Zare	93847dd106	fix(sub): keep the spider settings in a reality spiderX seed's query (#6694) ... * fix(sub): keep the spider settings in a reality spiderX seed's query xray's REALITY client reads p, c, t, i and r from the spiderX query as its spider's own settings (padding, concurrency, times, interval, return). deriveSpiderX hashes the whole seed into a bare /path per client, so any query set on the inbound was dropped from every share link and JSON subscription, and the spider always ran with defaults. Keep the seed's query after the derived path. The hash input is unchanged, so every existing client's spx stays the same; only seeds that carry a query gain it. The frontend mirror and the cross-language vectors are updated together. * docs(sub): keep the deriveSpiderX comments within two lines Review feedback on #6694: the added lines pushed both doc blocks past the two-line cap.	2026-10-03 00:31:52 +02:00
MHSanaei	ed31ee432c	feat(inbounds): deploy AmneziaWG, TUIC and MTProto inbounds to nodes ... The node gate assumed a node-assigned sidecar row would never converge, because the master's reconcile loops only read node_id IS NULL rows. But a pushed row is local on the node's own panel, whose AmneziaWG, TUIC and mtg loops run it like any other; node-adopted rows of these protocols already worked. Only creating or cloning them from the master was blocked. Open the three protocols on both lists and fix what assumed the master's host for a node row: - A node older than the release that introduced the protocol (MTProto v3.5.0, AmneziaWG v3.7.0, TUIC v3.8.0) would hand it to Xray as-is, so add and protocol-changing update refuse it, and a node that has not reported its version yet. Dev builds ("dev+<sha>") track main and pass. - MTProto's routeXrayPort is a loopback port on the host running mtg. The master no longer allocates one, nor forwards a cloned source's, for a node row; the node allocates its own and node sync adopts it back. - AmneziaWG forwardedPorts were checked against the master's inbounds, web port and id-derived relay ports. A node row is now checked against its own node's inbounds; the node re-checks what only it knows. UpdateInbound restores the stored nodeId before that check. Verified on a docker master+node pair: AWG, routed MTProto and TUIC created and cloned from the master start on the node (interface, mtg, tuic-server); an AWG client added and an MTProto client edited on the master apply on the node; the node-chosen egress port survives edits. Closes #6306	2026-10-03 00:26:46 +02:00
Artem K	721de5adde	Fix fragment exports for older Xray clients (#6702) ... * Fix fragment exports for older Xray clients * fix(link): tolerate a finalmask without tcp in panel share links withLegacyFragmentRanges called finalmask.tcp.map unguarded, but stored rows reach the link generator unparsed and dropEmptyFinalMask deletes an empty tcp list on save. Any VMess/VLESS/Trojan/SS inbound with only UDP masks or quicParams threw a TypeError in the QR, info and export-links views. The Go counterpart already skipped a missing tcp. Also trims the Go helper's comment to the two-line cap and drops a []string branch no JSON-decoded finalmask can reach. --------- Co-authored-by: Artem K <a.kush@vkteam.ru> Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>	2026-10-02 17:38:44 +02:00
libmur-dev	ce221c33d0	fix(sub): carry REALITY ML-KEM hint in VLESS links (#6712) ... * fix(sub): carry REALITY ML-KEM hint in VLESS links Keep raw share links in parity with Clash subscriptions for Xray 26.9.8+. Preserve the URI hint through Go and frontend imports, expose it in the outbound editor, and update the documentation tooling. * fix(link): accept REALITY ML-KEM boolean aliases * test(frontend): isolate Happ preset notifications * fix(link): keep the ML-KEM hint out of Xray REALITY settings support-x25519mlkem768 is a Mihomo reality-opts option; xray-core's REALITYConfig (infra/conf/transport_security.go) has no such field and its JSON loader drops unknown keys silently. The PR also stored it as realitySettings.supportX25519Mlkem768 in Xray outbounds (form switch, Go and TS link import, docs outbound builders) and as an inbound settings default that is stripped before Xray and read by no link generator. The outbound switch therefore did nothing, and imported links carried a dead key into the JSON subscription. The share-link hint itself stays: Go, frontend and docs still emit support-x25519mlkem768=true on VLESS REALITY links and drop it on a TLS host override. --------- Co-authored-by: libmur-dev <333915961+libmur-dev@users.noreply.github.com> Co-authored-by: MHSanaei <ho3ein.sanaei@gmail.com>	2026-10-02 15:44:41 +02:00
MHSanaei	62423cacd1	feat(xray): update xray-core to v26.9.30 and adapt panel ... Bump xtls/xray-core to b26a91de4f (v26.9.30) and the three binary pins (DockerInit.sh, release.yml Linux + Windows) in lockstep. No deleted symbols; the sing and sing-shadowsocks indirect deps drop out with the SS2022 rewrite. XDNS finalmask (#6718) replaced its string lists with objects: domains are {name, types, edns0, lenLimit, labelLimit} and client resolvers {type, settings.addr}. The loader no longer parses the old lists, so a single stored xdns mask keeps the whole core from starting. The new leaf package internal/util/maskcompat converts them: "name[:type]" becomes a domain and "name[:type]+udp://addr" a domain plus a udp resolver. A bare name maps to TXT, the type legacy clients queried by default, and each converted domain keeps the 1232-byte EDNS0 the old code always used (without it the server caps answers at 512). It runs from: - the XdnsFinalmaskObjectsFix seeder, over inbound streams, hosts, the xray template, the global sub-JSON mask and cached subscription outbounds; - inbound save (normalizeStreamSettings) and GetXrayConfig, for rows that never went through the seeder; - both link importers, since fm= from an older panel carries the lists. The finalmask form edits the object shape (every key needs a registered field, or the finalmask watch drops it on save) and lifts legacy masks on open. The udp-mask golden fixture moves to the object shape, which TestGoldenStreamFixturesBuildInXray now builds through the core. The wire format changed as well, so pre-upgrade clients need the new core. WireGuard outbound (#6771) dropped settings.domainStrategy and the remoteDNS "local" mode. The endpoint lookup now follows sockopt.domainStrategy and in-tunnel targets the outbound's targetStrategy. The old key is silently ignored, which undid the IPv4-first endpoint lookup the WARP outbound depends on (#5205), and "local" now panics the core at startup because remoteDNS goes through netip.MustParseAddr. The WireguardDomainStrategyFix seeder moves a stored family preference to both keys (a value already set wins) and turns "local" into targetStrategy; the outbound form lifts legacy rows the same way and drops its select, the WARP modal writes the new placement, and the inbound form loses a field the server never read. ValidateOutboundConfig now refuses a non-IP remoteDNS entry, which conf.Build() lets through, on template save and for outbound subscriptions. Noise finalmask items accept type "exp" (#6862), a tag expression. The form offers it for noise items only: header-custom items go through the core's PraseByteSlice, which refuses it. TUN gained autoSystemDnsToGateway (Linux) and autoSystemWfpBlockLeak (Windows). Both pass through the settings schema so a value set in JSON survives the next form save. MASQUE (inbound, outbound, transport) and the XDRIVE transport are new protocols the panel does not offer yet; their new loader refusals only cover configs the panel never generates. The FakeDNS IPv6 pool default, the SS2022 rewrite (same gRPC account; emails are now deduped case-insensitively, as the panel already does), the restored udphop interval default and the rest change no panel-facing config.	2026-10-02 13:54:39 +02:00
MHSanaei	aee45ca3fe	fix(hosts): advertise Hosts in every WireGuard, AmneziaWG and TUIC config ... Invariant: an inbound's enabled Hosts are the endpoints every client config for it advertises, whichever surface renders that config. WireGuard and AmneziaWG broke it. Their raw generators ignored the externalProxy entries Hosts are injected as and always emitted resolveInboundAddress, so the raw subscription, the sub page .conf, the clients links API and "export all links" gave out the panel address while the JSON and Clash formats of the same inbound used the Host. advertisedEndpoints now states the fan-out once for mtproto, wireguard and amneziawg. The browser-built configs had the same gap. The Clients page WireGuard and AmneziaWG config blocks and QR panels, and its TUIC Clash config, used the panel hostname next to server links that already used Hosts; the Inbounds page peer configs, QR and export ignored them too. withMtprotoHostEndpoints becomes withHostEndpoints over a shared hostEndpointsFor mirror of the backend, the tunnel fan-outs render one config per Host, and the clients page waits for the hosts list the way the inbounds page does, so an empty list means "no hosts" rather than "not loaded yet".	2026-09-30 15:03:16 +02:00
MHSanaei	823db05966	fix(inbounds): keep the stored client list and enable on inbound save ... Invariant: saving an inbound's configuration never changes which clients it holds nor whether it is enabled; both have their own endpoints. The edit modal posts back the clients and the enable flag it loaded when it opened. A client added meanwhile (another admin, the bot, the API, LDAP) was detached and its stats deleted; a client deleted meanwhile came back with its credentials, restoring access that had been revoked; an inbound switched off meanwhile was switched back on. For every save but a master's node-sync push, UpdateInbound now takes the client list and enable from the row it re-reads inside the writer; this replaces the lifecycle-only carry from the previous commit. Client validation (renewal schedule, Hysteria auth, TUIC credentials) moves after that swap so it judges the clients actually saved: a protocol switch keeps the stored clients, and #6268's refusal must apply to them. The edit form no longer loads or sends clients, so neither the JSON editor nor validation sees a copy the server ignores, and the enable switch shows only when adding; the list toggle (/setEnable) covers existing inbounds. Tests that added or re-keyed clients through a panel inbound save pinned the old rule; they now drive the master-push path, where payload clients still apply.	2026-09-28 13:23:48 +02:00
mrchatam	6f40a75909	feat(inbound): excludeFromSub hides links without disabling (#6463) ... * feat(inbound): excludeFromSub hides links without disabling Add a per-inbound flag that omits subscription output while keeping the inbound enabled for Xray, auth, and traffic accounting. Fixes #6435. * fix(inbound): excludeFromSub review follow-ups gofumpt model.go, sync docs OpenAPI, keep excludeFromSub master-authored on node mirror, and exercise the legacy add-column migration path in tests. * fix(sub): keep excluded inbounds' clients in the usage header The excludeFromSub filter sat in getInboundsBySubId's SQL, so an excluded inbound's clients never reached seenEmails in the raw, Clash or JSON renderer. A client that lives only on a hidden inbound (one client per inbound sharing a subId) dropped out of the Subscription-Userinfo usage, quota and expiry and out of the info-node state, while the inbound kept serving it and counting its traffic. The query returns every enabled inbound again; each renderer skips an excluded inbound's links but still counts its clients, the same rule the Clash renderer already applies to external links it cannot express. --------- Co-authored-by: mrchatam <mrchatam@users.noreply.github.com> Co-authored-by: MHSanaei <ho3ein.sanaei@gmail.com>	2026-09-27 12:26:37 +02:00
MHSanaei	fd7b3559bc	feat(panel): add sponsor slots fed from sponsors.sanaei.dev ... Monthly sponsor placements need to change without cutting a panel release. Panels now read 3X/sponsors.json from the MHSanaei/sponsors repo (GitHub Pages on sponsors.sanaei.dev) and show active sponsors in four slots: an overview banner, a rotating sidebar card (max three), the login page and a new Sponsors page that also lists open placements. An entry shows only while enable is not false and until is in the future; links must be https and logos are png/webp/jpg by name only. The list is cached for an hour and the last good copy survives upstream failures; logos are proxied through /sponsors/logo/:name with failures cached, so CSP stays 'self' and admin browsers never reach a third party. Admins can hide a slot for 24h. Under XUI_DEBUG the panel reads a sibling ../sponsors/3X checkout so edits can be previewed before push.	2026-09-26 03:31:51 +02:00
Sanaei	14b92fbcff	fix(nodes): stop flagging a node on the other update channel as outdated ... A node's "update available" tag compares its reported panel version with the master's latest, and any non-semver side fell back to string inequality. A dev build reports dev+<sha> (config.GetPanelVersion), so a node moved to the dev channel from a master on the stable channel kept the tag forever; the reverse, a stable node under a master on the dev channel, was flagged too and the tag's default stable update installed nothing new. A dev label and a release tag carry no order, so the comparison now only decides within one channel; dev-to-dev still compares commits, which keeps a node on the current dev-latest commit untagged as config.go intends.	2026-09-15 21:21:36 +02:00
Sanaei	bc424f0968	fix(xray): stop a lone dns qType 0 from matching every query ... The core reads a dns rule's qType as a PortList, which drops a bare numeric 0 (infra/conf/common.go: `if number != 0`), and a rule with no qTypes matches every query. A stored `"qType": 0` therefore does not target query type 0: it drops, refuses or hijacks all DNS through that outbound. A qType the panel writes has to be read by the core as exactly the query types it names. Four writers broke that: - DNSOutboundLegacyKeysFix rewrote a lone blockTypes [0] into "qType": 0, so "block type 0" became "block everything" on upgrade. - That seeder shipped in v3.8.0 and is recorded as done, so fixing it does not reach installs that already ran it. DNSOutboundQTypeZeroFix spells any stored numeric qType 0 as "0" once, protocol id matched like the core. - The outbound form adapter turned a typed "0" into the number 0. - The Xray template editor saves raw JSON past that adapter; the save now applies the same rewrite. Each writer is pinned by a test that fails without its part. The rewrite and the repair compare policies as the pinned core builds them, and the repair runs through runSeeders over a database whose legacy-keys seeder already ran, on SQLite and PostgreSQL 16.	2026-09-15 16:00:05 +02:00
BlindMaster24	a5a4c9cd83	fix(panel): read an outbound protocol id the way the core does (#6522) ... * fix(panel): read an outbound protocol id the way the core does xray-core lowercases a protocol id before it resolves the handler, so a template that spells the direct outbound "Freedom" is that outbound. The outbound editor fell through to the vless default and rendered it as an empty vless server, and the Basics tab did not find it and appended a second "direct", which the core refuses to load with "existing tag found". * fix(panel): never leave the direct tag on two outbounds A "direct" tag held by a non-freedom egress made both Basics-tab setters push a fresh freedom outbound, and the core refuses a config whose tags repeat ("existing tag found: direct"). The tag is now checked on its own before anything is added, matching setDefaultOutboundTag. * fix(panel): disable the freedom controls when direct is held elsewhere When a non-freedom outbound holds the "direct" tag, both Basics setters drop the edit so the core never sees the tag twice, but the Freedom Strategy select and the Happy Eyeballs switch stayed enabled and snapped back with no sign of why. isDirectTagTaken now disables both controls in that state. The find-or-create-plus-guard was also copied into BasicsTab's happy eyeballs setter with no test of its own; ensureDirectFreedomOutbound now owns the lookup, the guard and the creation for both setters, so the existing helper tests cover that path too. --------- Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>	2026-09-14 15:59:34 +02:00
BlindMaster24	826e29e2de	fix(xray): place the freedom domain strategy where the core reads it (#6515) ... * fix(xray): place the freedom domain strategy where the core reads it freedom resolves through the socket layer, so xray-core reads sockopt.domainStrategy and treats both other placements as legacy: it warns on every config load for the outbound-root targetStrategy it migrates itself, and again for the settings-level domainStrategy it deprecates. The panel wrote exactly those two keys from its Freedom Protocol Strategy select, the outbound form card, and the IPv4 routing helper, so any install that had configured a strategy logged a deprecation warning on every start. The strategy now travels in streamSettings.sockopt everywhere the panel emits it: the Basics select, the outbound form (including the JSON tab, which shares the same adapter), the shipped default template, and the IPv4 outbound the routing helper injects. Reading mirrors the loader's own order — root targetStrategy, then the settings keys, then sockopt — so the card keeps showing the value the core would actually run with, and saving drops the legacy keys instead of leaving them behind. A seeder moves the keys for configs already stored in the database, following OutboundRemovedKeysFix. The shared outbound-root Target Strategy field is hidden for freedom, since the core migrates that key into the very sockopt value the card writes and two knobs for one value would race. Tests: placement round-trips and the migration table run through the real vendored core (a captured log handler proves the warning is gone after the rewrite and present before it), and the modal asserts freedom offers a single strategy field. * test(database): seed the template row the seeder test needs A fresh InitDB creates no xrayTemplateConfig row — the panel's setting defaults live in the service layer — so the test has to insert the legacy template itself and then assert the seeder's history gate stops a second pass from rewriting it. * fix(xray): keep one strategy control per outbound, seed the row in tests Review findings: the Transport tab's Sockopts block renders for freedom too, so its Domain Strategy select and the freedom card wrote one sockopt value between them and the card won on save — the field is hidden for freedom now, leaving the card as the single control. The seeder is also pre-marked on a fresh install so it does not run on the second start, and the seeder test seeds the template row itself (a fresh InitDB has none) and asserts the rewrite structurally instead of grepping for a key name that sockopt also uses.	2026-09-14 12:08:38 +02:00
mrchatam	5ad9df69b9	fix(link): restore mKCP seed and headerType on share-link import (#6480) ... * fix(link): restore mKCP seed and headerType on share-link import applyTransport / applyTransportParams ignored kcp query params that applyKcpShareParams emits, so re-imported outbounds lost seed and header and could not talk to the inbound. Mirror those fields (plus mtu/tti) into kcpSettings in both Go and TS importers. Fixes #6476 * fix(link): restore mKCP header/seed via finalmask mkcp-legacy * fix(link): split mKCP header and seed into separate masks on import Both importers folded a share link's headerType and seed into one mkcp-legacy mask {header, value}. xray-core's MkcpLegacy.Build ignores value once header is set (and reads it as the fake DNS domain for header=dns), so an imported outbound carried the header mask but no AES-128-GCM seed while the emitting inbound has both, and could not connect — the failure #6476 reports, now for every link carrying both params. Emit one mask per field, seed first: the finalmask array's first item is the innermost layer, which puts the header around the cipher as legacy mKCP did. Also bound mtu/tti to KCPConfig.Build's accepted ranges (mtu >= 21, tti 10..1000, decimal digits only on both importers) so a pasted link cannot fail the whole Xray config load, and look header types up as own properties so a prototype key such as "constructor" is not mapped. --------- Co-authored-by: mrchatam <287639636+mrchatam@users.noreply.github.com> Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>	2026-09-13 22:28:13 +02:00
BlindMaster24	8fc4fc0bf8	fix(link): rebuild shadowsocks tcp/http obfuscation on import (#6505) ... * fix(link): rebuild shadowsocks tcp/http obfuscation on import genShadowsocksLink encodes tcp/http obfuscation only as the SIP002 plugin=obfs-local;obfs=http;obfs-host=... parameter, deleting type, headerType, path and host in the process, because SIP002 clients ignore those and read `plugin` alone. ParseLink read none of them, so importing a link the panel had just exported produced a plain tcp outbound with header.type none: the obfuscation the inbound requires was gone, and the client could not connect to the very inbound the link came from. The plugin is now mapped back onto the header it stands for. Credentials and every other parameter are untouched, and other plugin values are left as they were because Xray has no equivalent for them. * fix(link): map the SIP002 plugin in both importers The panel parses share links twice: link.ParseLink in Go, which the external subscriptions use, and parseShadowsocksLink in outbound-link-parser.ts, which the Add Outbound button calls. Mapping the plugin in Go alone left the UI path still saving header.type none for a link the panel had exported itself, so one panel answered the same link with two different outbounds. The unencoded plugin=obfs-local;obfs=http;... form maps as well now: stdlib drops any query pair whose value holds a literal semicolon, and that is the shape clients which skip percent-encoding emit, so the raw query is read as a fallback when the parsed parameter is missing.	2026-09-13 19:58:27 +02:00
BlindMaster24	f3dba07e13	fix(link): read the vmess certificate checks on import (#6507) ... * fix(link): read the vmess certificate checks on import applyVmessTLSParams writes ech, vcn and pcs into the vmess share object, but parseVmess only read sni, fp and alpn back. Importing a link the panel had just exported therefore dropped all three: no pinned certificate, no verify-by-name, no ECH. On a server whose certificate is only trusted through a pin, the imported outbound falls back to public-CA verification against the system roots and cannot connect to the inbound the link came from. The url-param protocols already read the same three in applySecurity, and the core takes pinnedPeerCertSha256 as one joined string there, so the vmess path now fills them the same way. * fix(frontend): read the vmess certificate checks on import The panel parses share links twice: link.ParseLink in Go and parseVmessLink in outbound-link-parser.ts, which is what the Add Outbound button calls. Reading ech, vcn and pcs in Go alone would have made the two sides disagree on one link, leaving the UI path — the one an operator uses by hand — still dropping the pin the panel had just exported.	2026-09-13 19:58:10 +02:00
mrchatam	503b5df4b9	fix(link): preserve Shadowsocks TLS query params on import (#6467) ... * fix(link): preserve Shadowsocks TLS query params on import Mirror trojan/vless stream parsing so Xray-native type/security/sni/alpn/fp query params on ss:// links survive into streamSettings on both Go and TS importers. Fixes #6094 * fix(link): drop extra blank line so oxfmt passes --------- Co-authored-by: mrchatam <287639636+mrchatam@users.noreply.github.com>	2026-09-12 11:52:38 +02:00
mrchatam	958d7f138e	fix(frontend): fold sockopt v6only into V6Only on inbound load (#6453) ... Prevents duplicate keys and an unreachable switch when Advanced/API configs store lowercase v6only (#6421).	2026-09-12 11:51:52 +02:00
mrchatam	51e0afdd90	fix(inbounds): allow negative subSortIndex for subscription order (#6465) ... * fix(inbounds): allow negative subSortIndex for subscription order Preserve explicitly set negative indices so primary inbounds can sort ahead of the default without renumbering peers; keep 0/omitted → 1. * fix(inbounds): gofumpt model.go and trim subSortIndex comments --------- Co-authored-by: mrchatam <287639636+mrchatam@users.noreply.github.com>	2026-09-12 11:14:53 +02:00
mrchatam	8082ab4d74	feat(clients): show short HWID fingerprint in admin device list (#6464) ... * feat(clients): show short HWID fingerprint in admin device list Expose a 12-char prefix of the stored hwid_hash in the admin HWID list API and UI so admins can distinguish devices without querying the database. Full hashes and raw HWIDs remain unexposed. Fixes #6359 * ci: retrigger release matrix after 386 dependency download flake --------- Co-authored-by: mrchatam <mrchatam@users.noreply.github.com> Co-authored-by: mrchatam <287639636+mrchatam@users.noreply.github.com>	2026-09-12 11:13:22 +02:00
amae	6d96accd63	Feature/tuic v5 (#6337) ... * Feat(tuic): Implement native TUIC v5 protocol support via Rust sidecar daemon - Add internal/tuic package for official tuic-server sidecar lifecycle management, configuration generation, and graceful process control - Bridge decrypted TUIC QUIC traffic into loopback Xray SOCKS5 inbounds (63200+id) for traffic accounting, statistics, and routing rules - Implement periodic reconciliation job (cadence @every 10s) and immediate runtime synchronization on inbound/client mutations - Add TUIC inbound & multi-user client settings (UUID + Password authentication) in Web UI with SNI auto-fill and panel certificate loader - Integrate tuic:// subscription links and Clash.Meta (Mihomo) proxy generation for TUIC - Update install.sh to automatically download and install official tuic-server release for x86_64, aarch64, and armv7 - Add full localization for TUIC protocol across all 13 supported languages * Feat(install): Support custom repository and branch in install and update scripts * Ci(release): Enable publish-dev for feature branch and workflow dispatch * Feat(sub): Add TUIC to subscription resolution and client QR config generator - Add 'tuic' to getInboundsBySubId SQL allowlist to resolve TUIC inbounds in subscriptions and sub links - Enhance buildTuicProxy in Clash subscription generator with robust host and credentials resolution - Add tuicConfig.ts to generate standalone Clash/Mihomo YAML configuration - Add dedicated TUIC Config tab in ClientQrModal with QR code and .yaml download button - Add localization keys for TUIC config across all 13 supported languages * Fix(tuic): Exclude TUIC from native Xray inbounds and strip udp_relay_mode from server config - Exclude model.TUIC from native Xray inbounds in GetXrayConfig to prevent Xray startup failure - Remove udp_relay_mode from tuic-server JSON configuration builder - Update install.sh to install tuic-server binary to both xui_folder/bin and /usr/local/bin * Fix(install): Fallback to dev-latest when releases/latest is not present on fork * Feat(tuic): Add real-time online status and LastOnline tracking for TUIC clients - Track client activity by mapping client UUID in tuic-server logs to email - Integrate TUIC active clients into XrayTrafficJob to refresh local online clients - Bump LastOnline timestamp in database and broadcast live online status over WebSocket * Feat(tuic): Implement real-time traffic statistics and live speed reporting for TUIC - Collect precise I/O traffic deltas for tuic-server child processes via /proc/<pid>/io - Aggregate and attribute TUIC traffic deltas per client in tuic Manager - Integrate TUIC traffic deltas into XrayTrafficJob to update database and broadcast live speed * Feat(tuic): Finalize TUIC v5 integration with 1:1 traffic counting and orphan process cleanup - Use exact 1:1 byte delta accounting from /proc/<pid>/io - Add killStrayTuicProcesses to terminate orphan sidecars on panel startup - Fully integrate TUIC with subscriptions, live speed meter, and all 13 locales * Feat(frontend): Polish TUIC UI, support bulk operations, and update translations - Align TUIC inbound certificate form with standard 3X-UI layout (Set Default Cert, Clear) - Remove extra subtitle hint text from TUIC inbound form fields - Support TUIC in client bulk attach/detach and bulk add modals - Add TUIC badge color to client info modal, clients table, and host list - Update password tooltip across all 13 locales to include TUIC - Remove obsolete dead translation keys across all 13 locales * Chore(ci): Finalize TUIC v5 bundling across release workflow, Docker, and scripts * Feat(openapi): Update OpenAPI generator and schemas for TUIC types * Fix(backend): Address core review findings for TUIC types, port checks, and xray bridge * Refactor(traffic): Isolate proc reading with build tags and decouple TUIC metering into TuicJob * Feat(client): Add TuicServer to InboundOption, fix config export and clean share links * Fix(frontend): Register TUIC in multi-user helpers, tracked protocols, and tag derivation * Chore(openapi): Re-generate OpenAPI specification and sync Zod schemas * Chore(scripts): Add Alpine musl binaries, 386 and Windows packaging, and anchor pkill * Fix(review): Remove stale import, correct binary names, switch to musl, and drop unreachable relay gate * Feat(frontend): Show share link in Inbound Info and display UDP tag for TUIC * Docs: Add TUIC v5 configuration guide and link specifications * Docs(tuic): Correct Clash Meta configuration parameter to reduce-rtt * Fix(tuic): Generate client credentials on copy, enforce ID/password validation, and add i386 to DockerInit * Fix(tuic): drop unused relay, fix traffic accounting, and honor host endpoints - Drop unused loopback SOCKS relay and eliminate port collision with AmneziaWG - Correct inbound traffic calculation without double-counting - Drop heuristic client traffic division while retaining online tracking - Support externalProxy host fan-out and conditional parameters in share links - Scope orphan process termination to managed config directory * Fix(tuic): enforce client quotas, decouple Xray restart, and sync openapi schemas - Regenerate OpenAPI, Zod schemas, and TypeScript types without route_through_xray - Populate clientTraffics in TuicJob to enforce client quotas and first-use expiry - Split process I/O delta into up and down in Process.CollectTraffic - Remove SetNeedRestart from updateTuicInbound to prevent Xray session drops - Use InstanceFromInbound for default ALPN and UDP relay mode in tuic:// share links - Support allow_insecure on externalProxy host endpoints without parameter collision * Fix(tuic): attribute client traffic only on single-user inbounds and sync link defaults - Attribute I/O deltas to the client only when the inbound has exactly one configured client, avoiding false billing and disablings on multi-user inbounds - Aggregate client traffic by email in TuicJob so clients on multiple inbounds don't lose deltas - Match frontend genTuicLink defaults for alpn and udp_relay_mode with backend subscription links * Fix(tuic): gate client traffic by total sidecar clients and require client email * Fix(tuic): enforce inbound-only traffic limits and disable client totalGB * fix(tuic): restore delayed start, remove client totalGB rejection, and document linux-only limits * fix(tuic): anchor pkill, fix io baseline/split, escape yaml, and deduplicate start errors * fix(tuic): prevent traffic double-counting, ensure info log level for delayed start, and broaden pkill matching * fix(tuic): address review round 11 findings - internal/sub/json_service: skip tuic protocol in json subscription to prevent direct routing leak - internal/sub/clash_service: honor externalProxy/host row allowInsecure, sni, and alpn in buildTuicProxy - internal/web/runtime: decouple tuic inbound add/delete from xray restart - internal/tuic/config: restore user log-level options (warn, error) without forced info clamp - frontend/src/lib/xray/inbound-link: fix duplicate remark suffix and apply externalProxy TLS overrides - frontend/src/schemas/protocols/stream/external-proxy: propagate allowInsecure through host mapping - tests: add coverage for json sub skip, clash proxy overrides, and link generation * fix(tuic): meter inbound traffic through a UDP relay and bracket IPv6 binds Review repairs on the TUIC v5 sidecar integration: - Inbound traffic was read from the sidecar's /proc/<pid>/io rchar, but the kernel only counts read()/write() there and tuic-server moves its sockets with recvfrom/recvmmsg/sendmmsg/sendto, so an inbound's up/down stayed at 0 forever and inbound total limits never tripped (measured: 12 MiB relayed, rchar delta 0). The panel now owns the inbound's public UDP port with a small relay and runs tuic-server behind it on a loopback port, counting up/down exactly on every OS. tuic-server therefore logs 127.0.0.1 as every client's address; per-client attribution stays unsupported since QUIC is opaque. - Instance.BindTo formatted an IPv6 listen address as ":::8443", which tuic-server rejects with "invalid socket address syntax", so an inbound listening on "::" or any IPv6 literal never started. It now uses net.JoinHostPort; IPv4 output is unchanged. - The log level is passed to the sidecar as chosen. Online status, last-online and delayed start are read from its Info lines, so the Log Level field now says that Warn and Error switch them off for the inbound, and the docs say the same. - Drop two frontend tests that only exercised a getter and a set lookup, and strip the trailing blank line that made gofumpt fail on two of the new Go test files. * fix(tuic): harden tag updates, runtime routing, and relay stability --------- Co-authored-by: poise52 <equipoise52@gmail.com> Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>	2026-09-12 10:15:48 +02:00
Rouzbeh†	d5ab84e8d5	feat(amneziawg): add AmneziaWG as an outbound protocol (#6320) ... * feat(amneziawg): add AmneziaWG as an outbound protocol - AmneziaWG outbound protocol end-to-end: config schema, socks bridge, netstack, panel UI - Route amneziawg outbounds to HTTP probe in TCP mode (backend + frontend classifiers) with pinning test - Add 2-minute idle read deadline to pumpUDPEgress to reap idle egress sessions - Require SOCKS5 username/password auth on the egress server (reject NO-AUTH with 0xFF) with test - Bound the egress TCP tunnel dial with portForwardDialTimeout (10s), matching portfwd.go - Resolve UDP domain targets off the association's reader loop via deliverUDPDatagram; race-safe getOrDial starts the reply pump at session creation; client passed by value into resolver goroutines (pinned by TestEgressUDPDatagramDomainInterleavedClients) - Reconcile early-returns on an empty desired set and closes the egress listener; EgressBasePort (64900) is reserved against local inbound port conflicts like the internal API port, with pinning tests for both the port reservation (TestCheckPortConflict_EgressPortBlockedLocal) and the Reconcile empty-desired Close/Listen lifecycle (TestOutboundManagerReconcileEmptyDesiredClosesEgress) - Eliminate acceptLoop shutdown race by validating listener != nil and registering to tracked under s.mu before wg.Add; bound pre-auth handshake with deadline (pinned by TestEgressServerCloseDuringConcurrentAccepts) - Support AAAA and dual-stack domain resolution in tunnel DNS resolver with v6 default fallback (DefaultTunnelDNSServerV6); add DNS field to frontend protocol form; avoid unneeded cache flushes on unchanged SetStack ticks * fix(amneziawg): resolve IPv6-only DNS default fallback and validate required keys - Default to IPv6 tunnel DNS on IPv6-only outbounds with blank dns - Require non-empty secretKey and peer publicKey in ValidateAmneziaWGOutbound - Add end-to-end IPv6 tunnel domain resolution test and test empty key rejection - Trim comment blocks exceeding 2 lines across modified files - Fix Storybook test execution on environments with POSIX locale Co-Authored-By: Claude Code <noreply@anthropic.com> --------- Co-authored-by: rqzbeh <rqzbeh@users.noreply.github.com> Co-authored-by: Claude Code <noreply@anthropic.com> Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>	2026-09-10 14:50:48 +02:00
Sanaei	d0edbcec81	feat(xray): update xray-core to v26.9.9 and follow the udpHop move ... Bump xtls/xray-core to 52a412d9e2f5 (v26.9.9) and the three binary pins in DockerInit.sh and release.yml in lockstep. Upstream moved UDP port hopping out of finalmask.quicParams.udpHop and into a standalone "udphop" UDP mask with a different shape (mode / interval / remotePorts / remoteIPs). The old key is gone from QuicParams, and since the config loader ignores unknown fields it is now silently dropped rather than rejected — port hopping just stops. The panel adapts where that key was live: - Both link importers rebuilt quicParams.udpHop from the standard mport param, so an imported hysteria2 link produced an outbound that no longer hops. They now emit a udphop mask in intervalremote mode, which is what the old key did. The mode is required: UDPHop.Build() rejects an empty or unknown one. - validFinalMaskUDPTypes and UdpMaskTypeSchema learn "udphop", otherwise the Go link generator strips the mask from every link and sub, and Zod strips it on the next form round trip. - mport generation (Go and frontend) reads the mask first and keeps reading the legacy key, so inbounds stored before the upgrade still advertise their range. On an inbound the old key was always inert — only hysteria's dialer consumed it — so nothing regresses server-side and no migration is needed. udphop stays out of the mask dropdown on purpose: it is client-only in core, which refuses to wrap a server socket, and that form is shared with the inbound editor.	2026-09-09 01:53:00 +02:00
DuQi	47d2303334	fix(inbounds): reject missing TLS certificates before saving (#6429) ... An inbound could be saved with security "tls" and a certificate row carrying neither a file path nor inline content. Nothing rejected it, so the row reached xray-core, whose readFileOrString fails with "both file and bytes are empty" and takes the whole config build down with it — every other inbound included. Validate the credentials on both sides of the wire. validateInboundTLSCertificates follows xray's file-over-inline precedence, requires a private key for every non-verify certificate and insists on at least one server certificate, so a verify-only CA list no longer passes as a server config. The inbound form's Zod schema enforces the same rules per field and serializes only the editor mode the operator actually used, and a failed save jumps to the Security tab naming the certificate row that broke. On update the guard is scoped to a real TLS edit. A row already stored incomplete is grandfathered: it stays editable, and only a save that breaks a previously valid block is refused. A sub-node stores whatever the master pushes, and Remote.UpdateInbound falls back to AddInbound when the node does not yet hold the tag, so a grandfathered row could otherwise never be deployed or re-seeded — the rejection is swallowed to a logger.Debug line and the node stays on a stale config while the panel shows the client as cut off. The controller now marks a node-sync request (mTLS or a node-sync token) on a per-request copy of InboundService, and the guard steps aside for it on both add and update: the row was judged where the operator acted, and a node that refuses it only falls out of sync. Operator and admin-token saves are held to the guard as before. The security union is parameterised on its tlsSettings branch instead of copied, and tlsCertUsesFiles is the one file-vs-inline inference shared by the form schema and the adapter, so the mode the editor opens in and the pair of fields the save serializes cannot drift apart.	2026-09-08 18:08:24 +02:00
YoungReckless4	3cd3836d77	fix(amneziawg): account for S4 junk in the default tunnel MTU (#6376) ... * fix(amneziawg): account for S4 junk in the default tunnel MTU amneziawg prepends S4 random bytes to every transport packet (device.NewOutboundElement) and, unlike content padding and random trailers, never clamps them against the tunnel MTU. A full-size packet therefore lands on the wire at MTU + 60 + S4 bytes: 20 IPv4 + 8 UDP + S4 + 16 transport header + 16 poly1305 tag. With the 1420 default that overflows a 1500-byte link once S4 exceeds 20, and GenerateObfuscation31 draws S4 from 12..27 inclusive -- so roughly 44% of newly created inbounds fragment every full-size packet they send. Measured on a live pair of interfaces, predicted against observed: MTU 1380 S4 12 -> 1452 on the wire (fits) MTU 1420 S4 12 -> 1492 (fits) MTU 1420 S4 20 -> 1500 (exactly at the limit) MTU 1420 S4 21 -> 1501 (fragments) MTU 1420 S4 27 -> 1507 (fragments) EffectiveMTU now subtracts S4 from the default; an explicit MTU is untouched. Client configs carry the same number. They previously omitted the MTU line whenever the server had no explicit value, which left the client on its own 1420 default and fragmented the client-to-server direction even after the server side was fixed -- silently, and only in one direction. All three emitters (the Go subscription text and the two TypeScript ones) now agree, which is what the existing parity test exists to protect. * fix(amneziawg): rebuild the device when S4 changes the derived MTU Addresses review feedback on the previous commit. Deriving the default MTU from S4 made a construction-time-only property depend on a hot-reloadable input, but addressFingerprint -- ensureLocked's only rebuild trigger -- still hashed the raw inst.MTU. S4 is a UAPI field, so an S4-only edit took the in-place IpcSet branch and the gVisor netstack kept the MTU derived from the old S4 while all three client emitters already advertised the new one. Every panel-created inbound leaves mtu unset, so that was the normal case, not an edge one: with S4 raised far enough the fragmentation this fix exists to remove came straight back, and stayed until a panel restart or an unrelated address edit. Folding EffectiveMTU into the fingerprint fixes it. An explicit MTU still takes the in-place branch on an S4 edit, since it does not move the interface MTU. Also trims four comment blocks to the 2-line cap in CLAUDE.md, and points NewDevice's doc comment at EffectiveMTU instead of the deleted defaultMTU.	2026-09-08 16:55:32 +02:00
Amirmohammad Sadat Shokouhi	5a63d5d468	fix(mtproto): use hosts for public share links (#6369) ... * fix(mtproto): use hosts for public share links Generate MTProto subscription, client, copy, QR, and export links from managed Hosts so reverse-proxied public ports are advertised correctly. Migrate the redundant legacy custom share address into a Host and keep old imports compatible. Closes #5126. * fix(mtproto): keep host share links lossless and consistent Address review on the MTProto hosts share-link change. The migration no longer drops a legacy custom share address: an unrelated (or disabled) Host stopped suppressing it, so only a Host already advertising the same address does. An imported address now clears the same validation the strict normalizer applies to every other protocol before it becomes a Host. Panel and subscription agree on the endpoint a Host advertises: a portless host string inherits the inbound port rather than the group's, and a port-only host inherits the inbound address instead of emitting server=%3A8443. LinksForClient prefers host endpoints for every protocol, the way getSubs and inboundLinks already do, so the client-links API no longer ignores managed hosts. * fix(mtproto): migrate legacy share address past unusable hosts The seeder skipped the conversion whenever any Host already carried the address, including one that is disabled or excludes the raw sub type. hostEndpoints drops those, so nothing advertised the address afterwards and the marker committed with no way back. The duplicate check now mirrors that same predicate. UpdateInbound cleared a legacy MTProto shareAddr without the Host conversion AddInbound runs, so re-applying an inbound definition through the API dropped the public address silently. Both paths share one capture helper now. Refresh the generated clients API reference for the summary reworded in the previous commit. * fix(inbounds): wait for the hosts list before building mtproto links The page destructured only `hosts` from useHostsQuery, and that list reads empty both while /panel/api/hosts/list is in flight and after it fails. withMtprotoHostEndpoints then returns the inbound untouched, so Copy, QR and Export advertise the internal listen port — the endpoint this branch exists to replace. It is worse than not fixing it: the seeder has already moved a legacy custom share address into a Host, so the fallback is the panel's own hostname instead of the operator's address, and the Go generators reading the same rows from the DB stay correct, so the two disagree for one inbound. Fold the query into the page's existing readiness gate, the same way useInbounds and HostsPage already consume that hook, so an empty list means "no hosts" rather than "not loaded yet". The error branch fires only when nothing is cached, so a refetch failing on window focus does not blank a page whose host rows are still perfectly usable. --------- Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>	2026-09-08 15:36:57 +02:00
Sanaei	2ec6c73613	feat(xray): update xray-core to v26.9.8 and adapt panel ... Bump xtls/xray-core to 37ceb8b4b6 (v26.9.8) and the three binary pins (DockerInit.sh, release.yml Linux + Windows) in lockstep. No deleted symbols; the impact is entirely on the JSON config surface. Outbound "proxySettings" is now refused by the config loader (moved to streamSettings.sockopt.dialerProxy) and a freedom outbound rejects sockopt.addressPortStrategy. Either key in a stored template would keep the core from starting after the upgrade, so a new OutboundRemovedKeysFix seeder rewrites xrayTemplateConfig once: proxySettings.tag becomes sockopt.dialerProxy (an existing dialerProxy wins) and addressPortStrategy is dropped from freedom outbounds. Template saves and outbound subscriptions already run through the vendored loader, so the new refusals surface there with the core's own message. REALITY no longer applies a built-in minClientVer (26.3.27) when the field is empty. The form placeholder and the min/max hints in all 13 locales now say that empty means no minimum. New upstream keys the Zod schemas would otherwise strip, with form support where a sibling field already had it: - blackhole response type "custom" with base64 customResponseData - realm finalmask ipMode (dual/v4/v6) and portMapping (UPnP / NAT-PMP) - quicParams brutalDisableLossCompensation, disableChromeParrot, disableGSO, disableStatelessReset - hysteria masquerade proxy xForwarded - wireguard outbound remoteDNS - routing rule localOS freedom.domainStrategy is only deprecated upstream (auto-migrated to sockopt.domainStrategy with a warning) and is left untouched.	2026-09-08 13:49:32 +02:00
duqigit	2ddcf53020	Feature/fix external subscription client expiry (#6333) ... * fix(sub): honor client expiry for external links * fix(ui): show client expiry on external links * fix(sub): address external expiry review	2026-09-03 22:32:05 +02:00
kuzzrus	bd1c27b03d	fix(amneziawg): H1-H4 generator + queue-depth throughput fixes (#6330) ... * fix(amneziawg): stop H1-H4 generator misclassifying transport packets Both the Go generator and its frontend mirror picked a random *range* per H1-H4 field with only a minimum width enforced (no maximum). amneziawg-go's packet classifier only ever compares a fixed-size ciphertext prefix against these bounds, so a wide range buys no DPI resistance -- the boundaries themselves are never observable on the wire. It does cost real throughput: with randomTrailers on (the default here), the handshake-size checks relax from == to >, so a wide H-range misclassifies a proportional fraction of ordinary transport packets as handshakes and silently drops them (amnezia-vpn/amneziawg-go#183). A single value per field is strictly safer than any range, with no obfuscation trade-off. Live-tested: narrowing H1-H4 alone took AmneziaWG upload from 2-3 Mbit/s to 200+ Mbit/s on one box, and ~20 Mbit/s to 120-156 Mbit/s on another, single-variable, no other change. * fix(amneziawgnet): raise tunQueueDepth to absorb slow-start bursts 1024 was sized for a single-connection buffering problem (the gVisor-to-amneziawg-go TUN handoff channel needing slack for the download direction). tcpip.Stack.Stats() during a real many-connection download (20-28 concurrent TCP flows, e.g. a segmented speed test) showed SlowStartRetransmits jump by ~770 in a single second the moment CurrentEstablished crossed ~20 -- consistent with many connections' simultaneous slow-start growth briefly exceeding 1024 outstanding packets and gVisor treating the resulting silent drops as real network loss. * fix(amneziawg): trim comment blocks to the repo's 2-line cap Review feedback: four comment blocks in the previous commits exceeded CLAUDE.md's 2-line-per-block hard rule (up to 13 lines). Trimmed each to the one non-obvious fact plus the amneziawg-go#183 reference; the fuller rationale already lives in the commit message. Also refreshed the stale H1-H4 range example in docs/content/docs/en/config/amneziawg.mdx to match the new single-value generator output.	2026-09-03 21:50:23 +02:00
MRVX	47964afbc5	fix(clients): render all tunnel configs for multi-inbound client (#6346) (#6349) ... When a client belongs to multiple AmneziaWG or WireGuard inbounds (e.g. across remote nodes), findAmneziaWGInbounds and findWireguardInbounds only returned the first matching inbound. Consequently, ClientInfoModal and ClientQrModal rendered only one config block, making other inbounds' configs unreachable. - Add findAmneziaWGInbounds and findWireguardInbounds returning all matching inbounds - Add formatTunnelConfigMeta helper to unify label, fileName, and qrRemark resolution - Support addressOverride in buildWireguardClientConfig from tunnelAllowedIPs - Render all tunnel configs in ClientInfoModal and ClientQrModal with node remarks - Distinguish download filenames with inbound remark suffix to avoid collisions - Add component integration tests covering multi-inbound modal rendering	2026-09-03 17:03:48 +02:00
Rouzbeh†	540caa4e93	fix(hysteria): standard geco share links and persistent uTLS None (#6325) ... - Export standard gecko obfs query params in hysteria2 share links - Enforce packet size bounds across Go and TypeScript link handlers - Persist uTLS None explicitly and initialize new TLS inbounds to chrome - Tear down stackTun safely without closeMu deadlock against WriteNotify Co-authored-by: rqzbeh <rqzbeh@users.noreply.github.com>	2026-09-03 16:35:07 +02:00
Kuzz007	effcccceac	feat(amneziawg): add native AmneziaWG protocol support (#6105) ... * feat(amneziawg): add native AmneziaWG protocol backend AmneziaWG (WireGuard plus DPI-resistant obfuscation) needs no Docker here — it runs as a genuine kernel interface via awg-quick/awg, managed the same way internal/mtproto manages mtg: one Inbound row is one desired Instance, and a Manager reconciles running interfaces toward the database every 10s (internal/web/job/amneziawg_job.go) plus immediately after a client edit (applyLocalAmneziaWG). Clients reuse model.Client verbatim (the same PrivateKey/PublicKey/ PreSharedKey/AllowedIPs fields WireGuard already uses), so bulk operations, the QR/share-link modal and subscriptions come from the shared inbound infrastructure instead of a parallel implementation. internal/amneziawg owns the obfuscation param generator/validator (ported from coinman-dev/3ax-ui, upgraded to AmneziaWG 2.0's S3/S4 padding and I1 signature packet) and the exec wrapper around awg-quick/awg, with fingerprint-based reconcile (noop / reload-via- syncconf / full restart) mirroring mtproto.Manager so a same-protocol edit doesn't force an unnecessary interface bounce that would drop every peer's connection. Frontend and install.sh's DKMS/awg-tools setup are tracked separately; this is backend-only. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(amneziawg): add frontend support and fix a Go->Zod generator gap Wires the amneziawg protocol through the panel UI the same way every other protocol is registered: a Zod settings schema (nested {server, clients}, matching the Go JSON exactly), the protocol enum, the inbound-form's per-protocol fields component and its tab-visibility allowlist, the default-settings factory, the client schema dispatcher, and the sniffing-capability exclusion (no Xray inbound exists for amneziawg, same as mtproto). Client key/allowedIPs fields are reused rather than duplicated: since AmneziaWG clients are wire-identical to WireGuard clients (same model.Client fields), ClientFormModal renders one shared field block for both, switching only the visible label by which protocol is active. The private-key input also gets a live public-key sync via a new useEffect, because unlike WireGuard's Xray-native inbound (which re-derives its public key at runtime and never stores one), AmneziaWG's server.publicKey is a real persisted field the Go backend reads directly — free-typing a new private key without this would silently save a mismatched keypair. Adds a downloadable per-client .conf (amneziawgConfig.ts, mirroring wireguardConfig.ts) with the obfuscation lines, and an InboundOption.AwgServer field on the Go side so the config builder gets the full server block in one round trip. Along the way, running tools/openapigen surfaced a real bug: it doesn't flatten anonymously-embedded Go structs the way encoding/json does, so ServerSettings embedding Obfuscation20 produced a Zod schema with a nested `obfuscation20` key that never matches the real wire JSON. Fixed by un-embedding (flat fields + an accessor method) and registering internal/amneziawg in the generator's own package list, which had been silently emitting a dangling schema reference. English and Russian translations are complete; the other 10 locale files still fall back to English for the new keys. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(amneziawg): complete frontend parity for the Inbounds list page The Clients page (form, CRUD, QR/config) already worked from the prior commit; this closes the remaining gap on the Inbounds side and in a couple of protocol allowlists that a plain search for existing wireguard/mtproto handling turned up. lib/xray/inbound-link.ts gets amneziawg-specific link/config builders (genAmneziaWGLink/genAmneziaWGConfig, plus the *s fan-out variants) mirroring the wireguard ones — AmneziaWG has no legacy peers-array to fall back to, so these read settings.clients directly and add the obfuscation lines every client must share with the server. Wired into genInboundLinks generically, and into three consumers that call the wireguard builders directly rather than through that dispatcher: QrCodeModal, InboundInfoModal, and InboundsPage's bulk export. ClientInfoModal, ClientBulkAddModal, and the bulk attach/detach modals each had their own protocol allowlist that needed amneziawg added alongside wireguard/mtproto. Two real gaps surfaced by grepping every remaining 'wireguard' / Protocols.WIREGUARD hit in frontend/src rather than trusting the checklist was exhaustive: - useInbounds.ts's TRACKED_PROTOCOLS gates the deactive/depleted/ expiring/online client counts shown per inbound on the list page; without amneziawg those counts would silently read zero. - inbound-tag.ts is an explicit client-side mirror of the Go backend's port_conflict.go (the file says so itself: "Keep in sync"). It still only special-cased wireguard for UDP, so an amneziawg inbound would have fallen through to the TCP default and disagreed with the backend's own port-conflict math. Also finishes translating the AmneziaWG UI strings into the 11 locale files that were still falling back to English (ar-EG, es-ES, fa-IR, id-ID, ja-JP, pt-BR, tr-TR, uk-UA, vi-VN, zh-CN, zh-TW), matching en-US/ru-RU key-for-key (26 new keys, verified by count in every file). Not run anywhere: npm run typecheck / build. This machine has neither Node nor npm, so nothing here has compiled — reviewed by hand plus brace/paren balance checks and cross-referencing the generated Zod/TS types. Treat this as needing a real typecheck before shipping. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * docs(install): note that AmneziaWG kernel module install is still manual Tracked separately (not yet ported into this script) — see coinman-dev/3ax-ui's install_amneziawg for the reference approach (ppa:amnezia/ppa). Also serves as a real, path-filter-matching change to get the previous empty commit's CI trigger to actually fire — release.yml's push trigger is paths-scoped and an empty commit changes no files, so it never matched. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(amneziawg): add a button to randomize obfuscation parameters Mirrors the existing key-regenerate button next to the private key field. Client-side randomization matches the ranges/constraints of GenerateObfuscation20's "default" preset (internal/amneziawg/params.go) closely enough for a form suggestion — the user can still hand-edit any field afterward. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(install): auto-install the AmneziaWG DKMS module + amneziawg-tools Ports install_amneziawg from coinman-dev/3ax-ui's install.sh, adapted to this script's broader distro coverage and NONINTERACTIVE convention: - Ubuntu/Debian/Armbian: ppa:amnezia/ppa (primary, tested path), with a reachability pre-check for the Launchpad PPA host — often blocked by hosting providers, especially Russian VPS — so a flaky network skips the feature instead of hanging apt through several retries. - Fedora/RHEL-family, Arch/Manjaro/Parch: best-effort fallback to plain wireguard-tools (+ AUR amneziawg-dkms via yay/paru when available), with a manual-install pointer. - Everything else: manual-install pointer only. Also installs ndppd and persists IPv4/IPv6 forwarding (for the future IPv6/NDP phase, not yet wired into the panel) and adds a Secure Boot warning at the end of the run, since a DKMS-built module is unsigned and won't load while it's enabled — a common trap on cloud VPS images. Never fatal: the panel installs and runs fine either way, an AmneziaWG inbound just won't bring up its tunnel until the module is present. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(amneziawg): resolve all 3 real CI failures (typecheck/lint/codegen) Found by checking the fork's Actions tab after the last two pushes — the release build passed (it doesn't run these checks) but the separate CI workflow caught three real issues: - golangci-lint (noctx): every internal/amneziawg/manager.go exec.Command call is now exec.CommandContext with a 30s timeout, so a hung awg-quick/awg invocation can't block the reconcile job indefinitely (mirrors internal/mtproto/process.go's own CommandContext usage). - tsc --noEmit: frontend/src/schemas/client.ts's hand-maintained InboundOptionSchema (used by the useClients hook, separate from the auto-generated one in generated/) never got an awgServer field added when the AmneziaWG frontend work was done — every read of inbound.awgServer.* in amneziawgConfig.ts was typing as {}. Added AwgServerOptionSchema, nested (not flattened like wg*) to match what amneziawgConfig.ts already expects. Also guarded server.publicKey in inbound-link.ts's genAmneziaWGLink against the schema's optional type. - codegen staleness: frontend/public/openapi.json is produced by a Node script (gen:api) this machine can't run; hand-applied the exact diff the CI failure log already showed (amneziawg protocol enum entry, ServerSettings schema, InboundOption.awgServer, one example payload), verified as valid JSON. Also confirmed independently by this run: install_amneziawg (previous commit) installed and loaded the DKMS module successfully on both amd64 and arm64 CI runners. The two "Deploy Smoke Tests" failures are unrelated to this change — this fork has only ever published the dev-latest pre-release, and GitHub's /releases/latest API deliberately excludes pre-releases, so the smoke test's no-argument install path (which resolves "latest") has nothing to find. Not a regression; needs an actual tagged release whenever that's wanted. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(amneziawg): Phase 2a — IPv6 support + NDP proxy Adds native dual-stack IPv6 to AmneziaWG inbounds, ported from coinman-dev/3ax-ui's approach: - ServerSettings gets ipv6Enabled/ipv6Subnet/ipv6ExternalInterface; Instance carries the server's own IPv6 address (first host of the subnet) alongside its IPv4 one. - defaultAmneziaWGClients allocates an IPv6 host address per client (second AllowedIPs entry) when the server has IPv6 enabled, reusing allocateWireguardAddress — which needed a real fix along the way: it always suffixed "/32" regardless of address family, which is wrong for an IPv6 host address (needs /128). Now family-aware. - generateServerConfig's PostUp/PostDown gains IPv6 forward-accept rules, proxy_ndp sysctl, and one `ip -6 neigh add/del proxy` entry per enabled peer with an IPv6 address — the lightweight per-client method, not the ndppd-daemon whole-subnet method (not worth the config-file-management complexity at this scale; ndppd itself is still installed by install.sh in case that changes later). - ValidateIPv6Subnet rejects a malformed subnet before save. - Frontend: ipv6Enabled/ipv6Subnet/ipv6ExternalInterface fields on the AmneziaWG inbound form, EN+RU translations, openapi.json/generated/* regenerated (the latter via `go run ./tools/openapigen`, pure Go). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(amneziawg): fill in IPv6 fields missed by the Phase 2a commit Two real gaps the CI caught (both new fields, both my miss): - inbound-defaults.ts's createDefaultAmneziawgInboundSettings() built a server object literal predating ipv6Enabled/ipv6Subnet/ ipv6ExternalInterface — AmneziawgServer's inferred type now requires them (zod .default() fields are non-optional post-parse), so this didn't typecheck at all. - openapi.json's ipv6Enabled property was missing the description the real generator attaches (the Go doc comment covering all three IPv6 fields is attached to the first one) — a one-line diff, but git diff --exit-code doesn't care how small. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(amneziawg): Phase 2b — per-client port-forwarding Admins can now set a per-client ForwardedPorts string (e.g. "80, 443, 8000-8100") that gets DNAT'd + FORWARD'd to that peer's tunnel address via iptables rules in PostUp/PostDown, ported and simplified from coinman-dev/3ax-ui's shared/portfwd. Two decisions worth flagging for future readers: - The iptables --comment tag on each rule is awg-fwd-<fnv32a(email)>, not the raw client email. Email is admin/API-supplied free text that ends up embedded in a shell-executed PostUp/PostDown line; a hash can never carry a shell metacharacter through where raw interpolation could. - The reconcile manager gained a third fingerprint (portFwdFP, next to the existing structural/peers ones). `awg syncconf` only touches the WireGuard peer table — it never re-applies PostUp/PostDown iptables rules — so a port-forward-only change has to force a full awg-quick down+up bounce, same as a structural change, rather than the lighter sync a plain peer add/remove can use. Also fixes a real pre-existing bug found while wiring up IPv6 client allocation in the previous commit's spirit: allocateWireguardAddress always suffixed "/32" regardless of address family, which produced invalid host bits for IPv6 (needs "/128"). ForwardedPorts flows through model.Client -> model.ClientRecord (gorm column wg_forwarded_ports, auto-migrated) -> ToRecord/ToClient/ MergeClientRecord, mirroring the awgServer field's earlier lesson that new fields need checking against a second, hand-maintained persistence-layer struct. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(amneziawg): route a client's traffic through Xray via the Routing page Every enabled AmneziaWG inbound gets its own Xray TPROXY bridge automatically, with no toggle to enable first: a loopback dokodemo-door inbound (sockopt.tproxy) tagged with the AmneziaWG inbound's own real tag, so it's already selectable in the existing Routing page's inbound-tag picker — the same trick the mtproto sidecar's own bridge already relies on (InboundService.GetInboundTags is a plain, protocol-blind SELECT over every inbound row's tag, no dedicated UI plumbing needed). internal/amneziawg's defaultPostUpDown TPROXYs every peer's traffic into that bridge unconditionally; the bridge's port is derived deterministically from the inbound's id (EgressPortForInbound) so the kernel-side reconcile loop and the Xray-config generator never need to negotiate a runtime value between them. injectAmneziawgEgress never generates a routing rule itself — whether a client's traffic goes anywhere beyond Xray's default routing is entirely up to whatever rules the admin adds through the existing Routing UI (pick the AmneziaWG inbound's tag as source, optionally a specific peer's IP via that page's own Source-IP field, and an outbound), exactly the same workflow as routing any other protocol. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(amneziawg): recover orphaned interfaces after an ungraceful exit Two gaps left an AmneziaWG interface stuck outside the manager's control after a crash (kill -9/OOM/panic skips StopAll): - ensureRestart's teardown was gated on the in-memory `exists` map, which is always empty on a fresh process, so a survived interface never got interfaceDown before interfaceUp tried `ip link add` against a name the kernel already had — failing forever and never populating m.ifaces, so traffic accounting silently stopped and the inbound could never be removed. Gate on isInterfaceUp instead, which checks real kernel state rather than this process's own bookkeeping. - An inbound deleted from the database entirely while the panel was down has no entry in `desired` ever again, so it never reaches the per-id cleanup loop in Reconcile (which only walks m.ifaces). Add a one-time sweepOrphansLocked scan of configDir, mirroring mtproto.Manager.sweepOrphansLocked, that tears down and removes any leftover interface/config not in the current desired set. Found by the automated review on MHSanaei/3x-ui#6105 (Finding 1). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * i18n(amneziawg): backfill IPv6/obfuscation/port-forwarding keys in 11 locales Only en-US/ru-RU ever got these 9 keys as each AmneziaWG feature landed (the regenerate-obfuscation button, then Phase 2a's IPv6 fields, then Phase 2b's per-client ForwardedPorts) — the other 11 locale files were never backfilled, so i18next has been silently falling back to English for all of them since Phase 1. Cosmetic-only (never broke anything), but now closed for every shipped locale. * fix(amneziawg): resolve 7 Medium findings from the automated PR review Each is independently reproducible; fixed together since one review pass found all of them. - manager.go: the shared "ip rule add fwmark" policy route had no existence check, so it duplicated in "ip rule show" on every interface bounce (which hostRulesFingerprint forces on any client add/remove/ re-IP). Now checked via "ip rule list | grep -q ..." first. (Finding 2) - params.go: ExternalInterface, IPv6ExternalInterface, and subnetIp/ subnetCidr are interpolated unescaped into a shell-executed PostUp/ PostDown line, but only obfuscation and the IPv6 subnet were validated before save. Added ValidateInterfaceName (a strict charset+length pattern) and ValidateSubnetIPv4 (netip.ParsePrefix), wired into normalizeAmneziaWGSettings. (Finding 3) - amneziawg_job.go: IsAwgInstalled() existed but nothing ever called it, so a host without awg/awg-quick (the Docker image, RHEL, Arch, a failed install.sh PPA step) logged a reconcile failure every 10s forever. Now checked once an inbound actually needs it, warning once instead of spamming. (Finding 4) - client_inbound_apply.go: the WireGuard/AmneziaWG credential carry-forward (added so a metadata-only client edit doesn't rotate keys) never covered ForwardedPorts, so a partial edit -- an API call or Telegram-bot toggle that omits the field -- silently wiped a client's port-forwarding spec. Carried forward and written back the same way the key fields already are. (Finding 5) - manager.go: hostRulesFingerprint keyed each peer on its IPv4 address only, and structuralFingerprint omitted IPv6Enabled/IPv6ExternalInterface entirely, so an IPv6-only change could pick the syncconf reload path (which never re-runs PostUp, leaving a stale NDP-proxy entry) or be a complete no-op. Both fingerprints now cover the IPv6 fields. (Finding 6) - port_conflict.go: the AmneziaWG egress bridge (injectAmneziawgEgress) binds 127.0.0.1:63100+id with no collision check anywhere, since it isn't a database row the ordinary port-conflict query can see -- same blind spot the reserved Xray API port already has its own check for. Added the equivalent check for the AmneziaWG bridge port. (Finding 7) - install.sh: install_amneziawg ran unconditionally for every install/ update, building a DKMS kernel module and enabling host-wide IPv4/IPv6 forwarding whether or not the feature is ever used. Gated behind a new should_install_amneziawg (XUI_INSTALL_AMNEZIAWG=true/false, or an interactive y/N prompt defaulting to no). Also replaced the deprecated apt-key adv with a dedicated keyring + signed-by= on the Debian branch, and guarded its sources.list appends against duplication on a retried install. (Finding 8) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(amneziawg): make the Xray TPROXY bridge a per-inbound opt-in Addresses Finding 10 from the automated PR review: an always-on TPROXY bridge makes every AmneziaWG tunnel hard-depend on Xray being up (all traffic, including DNS, drops whenever Xray restarts), and forces a full awg-quick down+up bounce on any client add/remove/re-IP, permanently losing the syncconf fast path. Adds ServerSettings.RouteThroughXray (off by default): - defaultPostUpDown only emits the TPROXY/policy-route rules when it's on; a plain AmneziaWG tunnel now has zero Xray dependency out of the box. - structuralFingerprint covers it (toggling it changes whether PostUp/ PostDown contain any TPROXY rules at all -- structural, not a per-peer host-rule). hostRulesFingerprint's IPv4 tracking is now itself conditional on RouteThroughXray (and IPv6 tracking on IPv6Enabled), so an instance that never uses either keeps the syncconf fast path for a plain peer re-IP. - injectAmneziawgEgress only creates a bridge for inbounds that opted in; checkAmneziawgEgressConflict (the Finding-7 fix) now parses each candidate through InstanceFromInbound so a non-routed inbound's port is correctly never treated as reserved. - New inbound-level Switch in the AmneziaWG form; the actual outbound decision is still made entirely through the panel's stock Routing page, same as before -- only whether the bridge exists at all is now a choice. Translation keys added to all 13 locales in the same commit this time, not backfilled later (see Finding 9's lesson). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(amneziawg): resolve 4 Low findings from the automated PR review - manager.go: serverAddress assumed subnetIp always ends in ".0"; a base like "10.8.1.5" was used verbatim as the server's own address, eventually colliding with peer allocation (which starts at .2 upward). Now derives the first host of the actual subnetIp/subnetCidr network via netip, matching serverAddressV6's own approach. A /32 base (no host bits at all) is still used as-is. (Finding 12, partial -- the /16 pool-widening half of this finding only exists on the upstream-pr/amneziawg branch's merged client_wireguard.go, not here; handled separately on that branch.) - manager.go: ensureLocked carried the previous per-peer traffic counters (`last`) forward even through a full restart, but awg-quick down+up resets the kernel's own counters to zero -- the next CollectTraffic computed a large negative delta (clamped to 0), silently discarding real traffic. Extracted the decision into nextTrafficBaseline: only a reload (syncconf) preserves the baseline. (Finding 13) - portfwd.go: exported ForwardedPortsInclude; inbound_amneziawg.go's new checkForwardedPortsConflict uses it to reject, at save time, a client's forwardedPorts that would DNAT the panel's own port or another enabled inbound's port to the tunnel client -- portForwardLines has no destination restriction, so this collision was previously silent. Wired into both the single-client update path and the add-client path (client_inbound_apply.go), plus normalizeAmneziaWGSettings for the whole-inbound save path. (Finding 14) - inbound.go: InboundOption.AwgServer sent the whole ServerSettings struct including PrivateKey to GetInboundOptions callers -- a shared, admin-wide dropdown-filling endpoint the frontend's own AwgServerOptionSchema never reads that field from. Redacted it before assigning. (Finding 11) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(amneziawg): don't widen the peer address pool past AmneziaWG's own subnet Completes Finding 12 from the automated PR review (the serverAddress half of this finding was already fixed on main and cherry-picked here). This half is specific to this branch: allocateWireguardAddress's /16 pool-widening fallback is an independent addition from upstream's own main that this branch inherited during the cherry-pick rebase -- it doesn't exist on the fork's own main at all, so this fix can't be cherry-picked the normal way and is committed directly here. Widening is safe for WireGuard's own Xray-native inbound (AllowedIPs isn't tied to a strict kernel interface subnet), but AmneziaWG's kernel interface Address is exactly the configured subnet -- an address allocated from the containing /16 once the /24 fills up would be silently unroutable. allocateWireguardAddress now takes an explicit allowWidening bool: WireGuard's own caller passes true (unchanged behavior), AmneziaWG's passes false (fails loudly on exhaustion instead). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * docs(docker): note that AmneziaWG doesn't work in this image Investigated: the image is Alpine-based, and AmneziaWG's own packaging (DKMS module + amneziawg-tools) doesn't target Alpine/musl at all -- unlike the Debian/Ubuntu/Fedora/Arch paths install.sh already handles, there's no package to apk add even with full host network/capabilities. The panel already degrades gracefully (IsAwgInstalled() logs one warning instead of retrying forever), so no code change is needed -- just made the reason explicit at the point where a user would reach for cap_add/ network_mode to try to work around it. * fix(sub): include amneziawg inbounds in subscription links getInboundsBySubId's SQL protocol allowlist never had 'amneziawg' added, so every AmneziaWG client was silently excluded from all three subscription formats (plain/individual links, JSON, Clash) and from the Telegram bot's QR/individual-link buttons, which fetch through the same path. genAmneziaWGLink itself was already fully implemented and already wired into GetLink's dispatch switch -- it just never got a chance to run. Same bug shape as the earlier TRACKED_PROTOCOLS frontend gap: a hardcoded protocol list one entry short. Found while investigating whether the Telegram bot needed AmneziaWG- specific client-management code -- it doesn't (the bot itself is fully protocol-agnostic), but this is the actual root cause of "can't share an AmneziaWG client's config via the bot." Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(inbound): enforce node-eligibility server-side, not just in the UI Investigated multi-node interaction with AmneziaWG: the master's own reconcile (DesiredAmneziaWGInstances) and Xray config generation (injectAmneziawgEgress, the GenXrayInboundConfig protocol skip) all correctly filter on NodeID IS NULL, so a node-assigned AmneziaWG (or MTProto) inbound would never be managed by the master. But nothing stopped one from being created that way: NODE_ELIGIBLE_PROTOCOLS (frontend/src/pages/inbounds/form/InboundFormModal.tsx) only hides the node picker client-side -- a direct API call could set nodeId on an AmneziaWG inbound, which every node then reconciles as an ordinary local inbound (nodes run the identical binary, full cron suite included), leaving it running unmanaged and untracked by the master's own AmneziaWG bookkeeping. Added isNodeEligibleProtocol (inbound_protocol.go), mirroring the frontend's allowlist, and enforced it in both AddInbound (the actually exploitable path -- nodeId comes straight from the request) and UpdateInbound (defense in depth; NodeID is already restored from the stored row there before this check, so it mainly guards against a protocol change on an existing node-hosted inbound). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(amneziawg): allow TPROXY-marked traffic through a default-deny INPUT chain TPROXY never rewrites a packet's own destination address, only the routing decision. A default-deny firewall whose INPUT chain sanity-checks "is this destination actually local" (UFW's ufw-not-local, via addrtype --dst-type LOCAL, is a concrete example) silently drops the redirected packet before Xray's socket ever sees it -- RouteThroughXray looked fully configured (TPROXY rule present and counting, Xray listening with IP_TRANSPARENT set) yet every peer's traffic vanished with no trace on either side. Adds an idempotent, never-torn-down "iptables -I INPUT 1 -m mark --mark <fwmark> -j ACCEPT" alongside the existing shared policy route, so this works regardless of which firewall manager owns the rest of the INPUT chain. * fix(frontend): give AmneziaWG the same UDP tag and its own tag color The Inbounds list only special-cased isWireguard/isHysteria for the "UDP" network badge, so an AmneziaWG row showed just the bare protocol tag with no transport badge next to it. Added the missing isAmneziawg flag (mirrors isWireguard exactly) and wired it into the same branch. Client-row protocol-color maps in ClientsPage/HostList had no amneziawg entry, silently falling back to grey -- ClientInfoModal already had amneziawg: 'yellow' from earlier work, these two just never got it. * feat(logs): show which AmneziaWG client an access-log line belongs to The dokodemo-door TPROXY bridge every AmneziaWG peer's traffic is routed through has no per-user identity, so Xray's own access log never carries an "email:" token for these lines -- the Access Logs modal showed a blank Email column for every in-*-udp row, even though every other protocol's rows show the client normally. The peer's decapsulated tunnel IP does survive as the log's "from" address, and that IP deterministically maps to exactly one configured peer. Builds a "<inbound tag>|<ip>" -> email index from the same AmneziaWG inbounds already parsed elsewhere (amneziawg.InstanceFromInbound), and fills in Email from it whenever the raw log line didn't have one. * fix(amneziawg): enable sniffing on the TPROXY bridge Domain-based Routing rules could never match RouteThroughXray traffic: an AmneziaWG peer resolves DNS itself, through the tunnel, before ever sending a packet, so the decapsulated traffic TPROXY hands to the bridge is already a bare destination IP with no domain name attached at the network layer. Every other inbound recovers this via sniffing (confirmed working for the stock wireguard inbound, which does have it configured); the bridge never got a sniffing block at all, so only tag/IP/network-based rules could ever match it -- any domain rule above it in the list was silently unreachable. * docs: add an AmneziaWG config page and list it as a supported protocol Closes the PR checklist gap: the feature shipped with zero mention on the docs site. Mirrors reality.mdx's structure (key settings, setup steps, config excerpt) and notes the Docker/multi-node/Telegram-bot caveats the PR itself is honest about not having confirmed. * fix: address the fresh review round on PR #6105 (8 findings) 1. hostRulesFingerprint didn't account for ForwardedPorts when RouteThroughXray was off, so re-IPing a peer with port-forwarding configured left stale DNAT rules pointing at an address the next peer could be handed. 2. Server/client config values (keys, email, I1) were never validated for control characters before being written into the generated .conf; a newline could smuggle a PostUp hook into awg-quick's parser. Added ValidateConfigValue at save time and a sanitizeConfigValue backstop at render time. 3. checkForwardedPortsConflict didn't scope to node_id IS NULL, so a port used only on a different node produced a false collision; also hoisted the panel-port/inbounds lookup out of the per-client loop (portConflictContext) so N clients cost one query, not N. 4. PostDown commands were ";"-joined and abort on the first failure; appendOrTrue makes teardown best-effort so an external firewall flush can't leave DNAT rules to accumulate across bounces. 5. The "ip rule list | grep -q" existence check could SIGPIPE under pipefail and re-add a duplicate rule; switched to grep -c >/dev/null. 6. Ported the vpn:// share-link format (base64url of the plain .conf text, matching the real AmneziaVPN app) onto this branch -- it had only ever landed on our own fork's main, so this PR branch was still on the old amneziawg://+query-params scheme our own docs no longer described. Also corrected the docs' install.sh claim (opt-in/ interactive, not automatic) and stale pre-opt-in comments in route_egress.go. 7. install.sh: Arch's ndppd install used pacman -Syu (full system upgrade) instead of -Sy like every other call in the script; and should_install_amneziawg re-prompted on every `x-ui update` even when awg was already installed. 8. CollectTraffic could clobber a concurrent restart's freshly-reset (empty) traffic baseline with stale pre-restart counters, since getPeerStats runs lock-free; now checks pointer identity before writing back. sweepOrphansLocked permanently disabled itself on a transient os.ReadDir failure instead of allowing a retry. go build/vet/test and frontend typecheck/lint/build/vitest all pass. * fix(install.sh): check the live sysctl value, not sysctl.conf text Reviewer feedback (cherts, PR #6105): grepping /etc/sysctl.conf for the setting name is unreliable -- many distros split sysctl config across /etc/sysctl.d/*.conf, and /etc/sysctl.conf can be a symlink into that directory, so the check can miss an already-active setting (harmless duplicate append) or match a disabled/commented line (forwarding silently stays off). Query the live value via `sysctl -n` instead, which is accurate regardless of which file set it. Applied the same fix to both the IPv6 and IPv4 checks for consistency. * fix: update inbound_amneziawg.go to the split buildInboundForLocalRuntime Same fork-only-file blind spot as the one caught on our own main after the 3.6.0 sync: upstream split buildRuntimeInboundForAPI into buildInboundForNodePush / buildInboundForLocalRuntime (part of the node-sync client-deletion fix, 5bc81dfd), updating every call site it could see. This file doesn't exist upstream, so it kept calling the old name even after the branch merged in that commit. * fix(frontend): recognize AmneziaWG's vpn:// scheme in share-link labels The shared link-tag/label helper (used by the client info modal, QR modal, and subscription page) had no entry for the vpn:// scheme AmneziaWG links use, so it fell through to the generic fallback: a plain "Vpn" tag with no color, and an empty remark/port that made the row's title fall back to "Link N" instead of the inbound's actual name:port — unlike every other protocol, which shows its real tag and label. vpn:// links are base64url of a plain .conf text (matching the real AmneziaVPN app's own share-link format), not a structured URL, so there's no query string or #hash to read a remark/port from. Decode the payload and pull the remark/endpoint back out of the .conf text directly instead. * fix(xray): force a full restart for TPROXY inbounds, never hot-add them Real incident: an AmneziaWG inbound with RouteThroughXray enabled lost all internet on that connection after a migration. Root-caused on the live box -- iptables TPROXY counters were incrementing (packets correctly redirected to 127.0.0.1:63110), but nothing was actually listening there (ss showed nothing on that port) until a full `systemctl restart x-ui`, after which the bridge came up immediately. Xray-core's gRPC AddInbound reports success for a new sockopt.tproxy inbound (internal/amneziawg's own Xray egress bridge is the only kind this fork ever generates) but doesn't reliably bind a working listener for it outside of process startup -- the bridge silently never comes up, and RouteThroughXray traffic goes nowhere until the next full restart happens to occur for an unrelated reason. diffInbounds already has this exact defensive pattern for REALITY inbounds ("a gRPC remove+add does not reliably rebuild the REALITY authenticator"), just never extended to TPROXY, and only in the already-existing-then-changed branch -- the "brand new inbound" branch had no such guard at all, which is exactly the path a freshly-enabled RouteThroughXray bridge takes. Added inboundUsesTproxy and wired it into both branches. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(amneziawg): flag Xray for resync when a peer edit changes qualifying state Real production bug, root-caused on iiadmin-vps: updateAmneziaWGInbound/ AddInbound/DelInbound only ever updated the kernel interface via amneziawg.GetManager() -- they never called SetNeedRestart the way every other protocol's mutation path does (client_crud.go, inbound.go, etc. all do). injectAmneziawgEgress's TPROXY bridge inbound depends on InstanceFromInbound finding at least one qualifying peer plus RouteThroughXray, so an edit that flips that (first peer added, last one removed, RouteThroughXray toggled on) previously required a full panel restart before the bridge actually got created, with no error anywhere: the kernel interface would handshake fine, but traffic redirected into the bridge's TPROXY port went nowhere because nothing was listening there. diffInbounds/inboundUsesTproxy already correctly force a full restart for a brand new TPROXY inbound (bdee0a20) -- that part was never the bug. The gap was entirely upstream: nothing ever told Xray a resync was even needed. * fix(clients): reject AllowedIPs already used on another WireGuard/AmneziaWG inbound defaultWireguardClients/defaultAmneziaWGClients only ever checked uniqueness against their own inbound's client list, so two inbounds sharing a subnet (same protocol or not) could silently hand out or accept the same address -- the exact scenario behind a real duplicate-IP incident where a WireGuard and an AmneziaWG client both ended up on the same address. otherTunnelAllowedIPs now collects every address already claimed on every other tunnel inbound and folds it into both the auto-allocation pool and the manual-entry collision check, naming the other inbound in the error when it fires. * fix(frontend): add the missing AmneziaWG config download on the sub page The subscription page already gave WireGuard links their own "Config" block (copy/download/QR of the actual .conf, via wireguardConfigFromLink reversing the wireguard:// query params) but had no equivalent for AmneziaWG's vpn:// links -- its isWireguardLink gate never matched them, and no reverse-parse helper existed for this page specifically. Every other surface (InboundInfoModal, ClientInfoModal, ClientQrModal) already had this parity; this was the one page that didn't. Fixed by adding amneziawgConfigFromLink (inbound-link.ts), simpler than its WireGuard counterpart since a vpn:// payload already *is* the plain .conf text -- just base64url-decode it, no query-param reconstruction needed -- and wiring it into SubPage.tsx alongside the existing WireGuard block, reusing the same pages.clients.amneziaWgConfig label the other three surfaces already use. * fix(xray): force a full restart for password-auth SOCKS5 hot-apply Real production incident: editing a client under an AmneziaWG inbound left its embedded SOCKS5 relay's settings byte-different (a new account list), and Xray's gRPC remove+add hot swap silently dropped the account for a peer whose email contained non-ASCII characters -- its tunnel kept handshaking fine but all its traffic got rejected at the SOCKS5 layer, while every other peer on the same relay was unaffected. A full restart (reading the same JSON straight from disk) always produced the correct account list. socks isn't in userDiffableProtocols (that only covers vless/vmess/trojan's clients+email shape, not accounts+user), so any settings drift on this inbound fell through to the generic remove+add path. Forces a restart instead, the same defensive choice already made for REALITY and TPROXY -- scoped to auth:"password" specifically so the other, noauth SOCKS5 bridges (panel/node/mtproto egress) keep the cheaper hot path. * Fix Attach reusing one identity's address across wg/awg inbounds ClientService.Attach deliberately copies one identity's stored AllowedIPs into every WireGuard/AmneziaWG inbound it's attached to in the same call, so the same person gets the same tunnel address on every protocol they use. Its loop calls addInboundClient once per inbound, and each of those independently computes otherTunnelAllowedIPs -- so by the second inbound in the batch, the first inbound's just-written copy of this identity's own address looked like a cross-inbound collision against itself. Real production symptom this caused: detaching then re-attaching a client to both wg and awg failed with "wireguard: allowedIPs entry X is already used by a client on inbound 'awg' (#N)" -- the exact address the identity is supposed to keep, rejected as if it belonged to someone else. Add a selfEmails exclusion to otherTunnelAllowedIPs and populate it from the client(s) being processed at the one real call site. Safe unconditionally: ClientRecord.Email is globally unique, so a match can only ever be this same identity's own entry on a sibling inbound, never a genuine different client's address. Reproduced the underlying mechanism live (manual entry correctly rejected as a cross-inbound collision; fresh auto-allocation correctly avoided a used address) before writing the fix, to confirm the guard itself works and the bug is specifically in how Attach's per-inbound calls interact with it. * Attach: allocate fresh when re-attaching with no active tunnel The previous fix (82cc69f5) made Attach's own address-reuse correctly not collide with itself across inbounds -- but it still always reused an identity's stored AllowedIPs verbatim, even when that identity currently has zero WireGuard/AmneziaWG attachments at all. A real report from testing this live: an identity fully detached from both its wg and awg inbounds, then re-attached, got its old address back even though several lower addresses were free -- because nothing about being fully detached ever cleared the stored value Attach copies from. Add hasTunnelAttachment, checked once against the identity's CURRENT inbound set before Attach's loop runs: if none of its current inbounds is WireGuard/AmneziaWG, clear the stored AllowedIPs so this attach allocates fresh (matching what a brand-new client would get) instead of resurrecting an address nothing reserves anymore. Left alone when the identity already has an active tunnel elsewhere, so extending it to a second protocol still keeps a consistent address. * Fix TestOtherTunnelAllowedIPsExcludesSelfEmail's own test setup CI caught this: the "genuinely different client" (other@wg) was seeded onto the SAME inbound passed as excludeID, which otherTunnelAllowedIPs already excludes entirely regardless of the selfEmails fix -- so the assertion that its address is still reported could never have passed, proving nothing either way. Move it onto the sibling inbound alongside shared@id, which is what the test actually needs to exercise (two clients on one sibling, one excluded by email, one not). * Attach: never inherit an address that doesn't fit the target inbound hasTunnelAttachment (from the earlier fix, commit 51067f16) only asked "does this identity have ANY tunnel attachment", treating that as license to reuse its stored address verbatim on every inbound being attached. Real production case this missed: an identity's stored address came from WireGuard's own fallback subnet (10.0.0.0/24, used when that inbound has no other clients to infer a base from), then got attached to a second, AmneziaWG inbound configured for a completely different subnet (10.8.1.0/24). defaultAmneziaWGClients's already-set-AllowedIPs branch only checks for collisions, never subnet membership, so the mismatched address was accepted silently -- producing a peer that can never actually connect, since an AmneziaWG address must fall inside the kernel interface's own configured subnet to be routable at all. Add addressesFitAmneziaWGInbound, checked per inbound inside Attach's loop: if the inherited address doesn't fit the SPECIFIC inbound being attached, clear it just for that one so it gets a fresh, valid allocation instead, while other already-attached inbounds keep their existing values. WireGuard has no equivalent strict subnet requirement (allocateWireguardAddress can widen to a fallback pool for it), so this only ever constrains AmneziaWG targets. * Give WireGuard an explicit, admin-configurable subnet field WireGuard previously had no configurable subnet at all -- only an implicit one, either inferred from existing clients' own addresses (wireguardAllocationBase) or a hardcoded 10.0.0.0/24 fallback when none exist yet. AmneziaWG, by contrast, has always had a real server.subnetIp/subnetCidr field in its settings, editable in the UI. User request: give WireGuard the same treatment. Backend: explicitWireguardSubnetBase reads an optional subnetIp/ subnetCidr pair from the inbound's own settings JSON (mirroring AmneziaWG's defaultAmneziaWGSubnetBases). defaultWireguardClients checks it first; only when unset does it fall back to today's inference-from-existing-clients behavior, so an inbound saved before this field existed keeps working exactly as it always has. Frontend: subnetIp/subnetCidr added to WireguardInboundSettingsSchema and the inbound form (mirroring AmneziaWG's own field layout/labels), with a real default (10.0.0.0/24, the same value the backend already fell back to) seeded for newly created inbounds so the field starts populated and editable rather than blank. Translated across all 13 locales. This also structurally closes the class of bug fixed in 82cc69f5/291c47b3: with wg and awg subnets explicit and independently controllable, an admin who wants matching addresses across both protocols can configure them to actually agree, instead of one silently inheriting the other's incompatible range. * Split the client edit form's AllowedIPs into per-protocol fields A client attached to both WireGuard and AmneziaWG shared one AllowedIPs form field with a dynamically-switching label, so its two genuinely different addresses could never both be shown or edited correctly. Worse, Update/Create broadcast that one shared value to every attached wg/awg inbound with no subnet-fit check, so an ordinary edit save could silently overwrite one protocol's address with the other's -- the same bug class already fixed for Attach, but reachable from any client edit. model.Client gains an optional AllowedIPsByInbound map so a caller can send distinct values per inbound; Update/Create honor it and, when it's absent, clear a shared value that doesn't fit an AmneziaWG inbound's own subnet instead of writing it through. A new TunnelAllowedIPsByInbound read path feeds the real per-inbound address to the client edit form via GET, which now renders two separate, correctly-labeled fields whenever both protocols are attached (unchanged single dynamic field otherwise). * Regenerate openapi.json for the new allowedIPsByInbound field Follow-up to 878ee839: gen:zod (frontend/src/generated) was already regenerated and committed, but gen:api (frontend/public/openapi.json) wasn't, so CI's codegen drift check failed. * Fix build breakage from merging upstream main: Update() gained a limitHwid param Two of our own AllowedIPs tests (not present upstream, so the merge never flagged them as conflicting) still called the old 3-arg Update(inboundSvc, id, client) -- upstream's hardware-ID-limit feature added a required limitHwid parameter that every other caller in this package already passes. Also drop createDefaultInboundSettings from InboundsPage.tsx: the merge conflict resolution kept the import, but upstream's clone-payload refactor (buildClonePayload, inbound-clone.ts) already calls it internally now -- this file doesn't need it directly anymore. * Fix real bug: AmneziaWG clients rejected as "empty client ID" in 3 places Three switch statements on inbound.Protocol handle "wireguard" explicitly (checking client.PublicKey) but fall through to the default case for "amneziawg" (checking client.ID, which AmneziaWG clients never set -- they use PublicKey/Email like WireGuard, not the VMess/VLESS UUID field). This is what the 4 AllowedIPs tests were actually catching: UpdateInboundClient's newClientId derivation hit this same default branch, so every Update() on an AmneziaWG client returned "empty client ID" before ever reaching the AllowedIPs logic being tested. Fixed by adding "amneziawg" alongside "wireguard" in each switch: addInboundClient's per-client validation, UpdateInboundClient's newClientId derivation, and AddInbound's per-client validation (the third one wasn't hit by these tests, but has the identical bug -- creating a brand-new AmneziaWG inbound with a client attached would fail the same way). * refactor(amneziawg): rename Obfuscation20 to Obfuscation31, drop the dead mobile preset Mechanical rename ahead of the AmneziaWG 3.1 parameter work: the type, generator and prose all said 2.0, and the "mobile" generator preset was reachable only from its own test. No behavior change. * feat(amneziawg): AmneziaWG 3.1 obfuscation parameters (backend + generated schemas) Adds the 3.1 parameter surface to the inbound settings and both Go config emitters: I2-I5 signature packets, HeaderProtectionKey (base64 32-byte, shared server<->client), ContentPaddingAddition, the five handshake-timing randomization ranges (RekeyAfterTime/RekeyTimeout/RejectAfterTime/ KeepaliveTimeout/MaxHandshakeAttempts), and the RandomTrailers/ DisableCookies switches. Freshly generated sets fill everything except I2-I5 (matching Amnezia's own generator) with jittered ranges bracketing WireGuard's stock timing constants; every reject window starts >= 30s above the rekey window by construction. Empty fields stay off the wire, so blanking a field disables just that feature. Validation generalizes the H1-H4 range checker for the new uint32-range fields, requires min 1 on timers, cross-checks rekey-vs-reject, and demands a real 32-byte base64 header-protection key. The manager warns once per process when the installed awg tools predate 3.1 but an inbound uses 3.1 parameters (awg-quick rejects unknown keys with a generic error otherwise); apply still proceeds. Requires amneziawg-tools v3.1.20260812+ / module or amneziawg-go v3.1.20260814+ on the host. * feat(amneziawg): emit and randomize 3.1 parameters in the frontend Both client-config emitters (the vpn:// link builder and the clients-page .conf builder) now carry the 3.1 [Interface] lines in the same order as the Go emitters. The obfuscation randomizer moves out of InboundFormModal into a shared lib/xray/amneziawg-obfuscation.ts that also fills the new fields, and createDefaultAmneziawgInboundSettings switches from static values to that generator — a fresh inbound now really gets the unique fingerprint the docs promise instead of the same jc=5/jmin=10 set on every install. Schema parse-time defaults for the new fields stay ''/false on purpose: real values come only from the generator, so resaving an inbound never mutates its stored parameters. A new parity test pins the hand-written AmneziawgServerSchema to the generated ServerSettings key set, so a field added on one side can no longer silently vanish from configs. * feat(amneziawg): 3.1 form fields and translations Inbound form gains inputs for I2-I5, HeaderProtectionKey (filled by the existing obfuscation Regenerate button), ContentPaddingAddition, the five timing ranges, and the RandomTrailers/DisableCookies switches; the MTU input picks up the min=1 its schema already enforced. All 13 locales get the 19 new keys and drop the "2.0" branding from the s3/s4/i1 labels. * docs(amneziawg): document 3.1 parameters; install.sh kernel/version notes The AmneziaWG page's obfuscation section moves from the 2.0 to the 3.1 parameter set: table rows for I2-I5, HeaderProtectionKey, ContentPaddingAddition, the timing-randomization ranges and the RandomTrailers/DisableCookies switches, a requirements callout (tools v3.1.20260812+, module/awg-go v3.1.20260814+, Linux 6.7+ for the DKMS path), and a sample client .conf that matches what the panel actually emits (including the DNS defaults and PersistentKeepalive it always had). install.sh warns before a DKMS build on a pre-6.7 kernel and after any install that left pre-3.1 amneziawg-tools on PATH. Also updates the hosts API operation paths ({id} -> {groupId}) in the stale ru/zh/fa reference pages: syncing docs/public/openapi.json for the new AmneziaWG schema fields surfaced that rename, which had never been copied over, and the docs build fails on paths missing from the spec. * fix(amneziawg): reject control characters and canonicalize 3.1 range values Adversarial review of the 3.1 work surfaced a validation gap: base64.DecodeString silently ignores CR/LF, so a header-protection key that picked up a line wrap in transit decoded to a valid 32 bytes, passed validation, and was emitted verbatim into every client config — where the orphan second line breaks the import while the server (whose emitter strips control chars) keeps running with the correct key. The key and range validators now reject control characters outright. Also from the same review: range values are canonicalized on save ("110 - 140" -> "110-140", whitespace-only collapses to feature-off, closing a case where the server conf rendered an invalid blank-value line the client emitters omitted); the rekey/reject invariant is now enforced against WireGuard's 120s/180s defaults when only one side is set; and the structural fingerprint joins on "\n" instead of "|", which is a legal I1-I5 character and made adjacent free-text fields join-ambiguous. * fix(install): resolve latest release tag via web redirect to dodge API rate limits The non-interactive install smoke test resolved the release version through the unauthenticated GitHub API (api.github.com/.../releases/latest), which allows only 60 requests/hour per IP. The test installs twice in one run, and on shared CI runner IPs the second call gets rate-limited, returns no tag_name, and install.sh treats an empty version as fatal (exit 1) — the same "Failed to fetch x-ui version" real users hit behind CGNAT/shared addresses. resolve_latest_tag() now reads the tag from the github.com releases/latest web redirect (not subject to the API rate limit), falling back to the API only if the redirect yields nothing. Verified with the real deploy/test/smoke-noninteractive.sh (two installs, both green). * fix(amneziawg): three review findings on #6105, plus a comment trim 1. A peer's allowedIPs reached the generated .conf unvalidated and unsanitized, unlike email/publicKey/preSharedKey which normalizeAmneziaWGSettings already guards. A newline in an entry let a following "[Interface]" re-open the interface section, whose "PostUp = ..." awg-quick then runs as root on the next apply. Reproduced end to end against generateServerConfig. The save path now rejects and canonicalizes through normalizeWireguardAllowedIPs, and the render path sanitizes as a backstop for rows predating the validation (an upgrade, a restored backup, a direct DB edit). H1-H4 get the same render-time sanitize, and the two NIC name fields a plausibility check, since stripping control characters alone would still let a shell metacharacter into a root-executed PostUp line. 2. EgressPortForInbound is 63100 + inbound id, so an id past 2435 derives a port above 65535 -- and Xray rejects the whole generated config over one invalid port, taking every other protocol down with it. It now reports ok=false past the range, and both the Xray bridge and its TPROXY rules are skipped instead of emitting an impossible port. 3. The downloadable AmneziaWG .conf read ClientRecord.allowedIPs, a single shared column that holds the WireGuard address for an identity attached to both protocols -- the exact ambiguity tunnelAllowedIPs was added to resolve for the edit form. The info and QR modals already hydrate that field, so they now pass this inbound's own address to the builder. Also trims the comment blocks in the files touched here to the 2-line guidance in CLAUDE.md: internal/amneziawg alone carried 423 comment lines in over-long blocks against 118 for the comparable internal/mtproto, and is now at 110. Every non-obvious constraint is kept (the kernel S1/S2 rule, why PostDown is best-effort, why grep -c and not -q, why the fingerprints split three ways); the narration is gone. Two hot_diff.go comments pointed at an internal/amneziawgnet package and an injectAmneziawgnetSocks function that exist nowhere in the tree; the checks themselves are unchanged. * feat(logs): add an AmneziaWG log view to the overview The overview has an access-log view for Xray but nothing for AmneziaWG, so when a tunnel misbehaves there is no way to see it from the panel at all. A kernel tunnel logs no per-request lines, so the equivalent view is built from the two things it does expose: - Live per-peer activity from `awg show <iface> dump`, joined to the client email through the desired peer set: last handshake, endpoint, allowed IPs, cumulative transfer and online state, newest handshake first. - The panel's own AmneziaWG event lines (interface up/down, awg-quick failures, the pre-3.1 tools warning), which are what actually explain a peer being absent from the table. POST /panel/api/server/amneziawglogs/:count serves both, with the same count + filter contract GetXrayLogs uses, and the modal mirrors XrayLogModal's toolbar, auto-update, mobile cards and download. The action-bar button is gated on a new status.amneziawg.configured, which stays true while an inbound exists but its interface is down -- exactly when the event lines matter. Verified against a running panel: the endpoint returns the peer table and real event lines ("awg/awg-quick not found on PATH", "create config dir: permission denied"), and count and filter both narrow as documented. One of those lines surfaced a Debugf that had been rendering as "for inbound1:amneziawg:"; fixed here since it is now user-visible. * fix(amneziawg): stop double-counting a routed inbound's traffic injectAmneziawgEgress tags its Xray bridge with the AmneziaWG inbound's own tag, so the stock Routing page can target it. Xray therefore reports that bridge's bytes under the inbound's tag, and XrayTrafficJob feeds them to AddTraffic -- which accumulates -- on top of the same bytes AmneziaWGJob already reported from `awg show dump`. An inbound with routeThroughXray on counted roughly twice its real traffic, which also inflates the quota checks that read the same counters. The awg counters are the complete measure: every peer, whether or not TPROXY routed it, and the same wire bytes the per-client totals are built from, so they stay and the Xray rows are dropped. Per-client stats were never affected -- a dokodemo-door bridge has no per-user identity, so Xray emits no user>>>email rows for it. Filtering happens before every consumer, so the DB totals, the external traffic inform and the dashboard's live speed all read one source per inbound. The set of bridge tags now comes from a predicate shared with injectAmneziawgEgress itself, with a test that pins the two together -- naming one tag too few doubles the traffic again, one too many makes real traffic vanish. * fix(amneziawg): align the three .conf emitters on one peer field order The panel builds an AmneziaWG client .conf in three independent places, and they disagreed: buildAmneziaWGClientConfig put PresharedKey right after PublicKey (wg-quick(8)'s own order, and what both WireGuard emitters on the clients side already use), while genAmneziaWGConfig and the Go amneziaWGConfigText put it after Endpoint. A user comparing a subscription link against a downloaded .conf sees the difference immediately, and the generators are exactly the kind of parallel implementation CLAUDE.md warns about drifting. Moves the two outliers onto the wg-quick order. Also drops the stray trailing newline that only appeared when PersistentKeepalive was set, so a config now always ends on its last set field whichever that is -- the same shape all three emitters produce for the same client. Parsing is unaffected either way (the format is order-insensitive, and the AmneziaVPN app reads it as a flat key-value bag), so this changes only the rendered text. Adds a test on each side that pins the peer block's field order, since nothing previously asserted it. * refactor(amneziawg): switch to the embedded amneziawg-go/gVisor architecture Replaces the kernel-module (DKMS) + awg-quick + TPROXY backend with the fork's own embedded design: amneziawg-go runs in-process over a userspace gVisor netstack, and each peer's decapsulated traffic relays into its own loopback Xray SOCKS5 inbound, so Xray's native stats/sniffing/routing work for free instead of through hand-rolled bridges. No kernel module, no DKMS, no Secure Boot conflicts, works the same in a container as on bare metal. - internal/amneziawgnet: new package (Device/UAPI, gVisor netstack, TCP/UDP forwarding, SOCKS5 relay, peer identity, IPv6 host-alias egress identity, per-client port-forwarding) - amneziawg-go v3.1.20260814 + gvisor. - internal/amneziawg: keep the reusable protocol-shape types/validation (Instance/Peer/Obfuscation, InstanceFromInbound); drop the OS-shellout half (awg-quick, TPROXY policy routing, NDP proxy, peer-stats parsing). - internal/web/service: rewire the 5 integration points (job, runtime, client-apply, web shutdown, xray config) from the old manager to the new one; the AmneziaWG log view is rebuilt on the embedded Device's own UAPI dump (extended to carry endpoint/AllowedIPs) instead of `awg show dump`. - install.sh: drop DKMS/ndppd/TPROXY/Secure-Boot installer code (~250 lines) - an entire recurring class of installer fragility goes away. - frontend: drop the now-meaningless routeThroughXray toggle (the relay is always on); keep the field in the Zod schema, unexposed, so it isn't silently stripped from stored settings on next save - two regression tests deliberately depend on the Go struct still carrying it. - docs/i18n: rewrite amneziawg.mdx for the new architecture; drop the dead routeThroughXray translation keys across all 13 locales. Real production throughput (embedded core datapath, isolated bench, same box the kernel-module path was measured on): ~296 Mbit/s up, ~640 Mbit/s down, vs. 414.69 MB/s (~3.3 Gbit/s) for the kernel module on the same hardware - a real gap, tempered by this being single-stream/no-SOCKS5-hop and most VPN traffic being latency-bound rather than throughput-saturating. * fix(amneziawg): restore the branch's own Obfuscation31 shape + 2 CodeQL findings The previous push's wholesale-copy of types.go/params.go from the fork's main branch pulled in that branch's own independent (and incompatible) naming for the same AWG 3.1 feature set: Obfuscation20/GenerateObfuscation20 instead of this branch's already-shipped Obfuscation31/GenerateObfuscation31, and a missing CanonicalizeUintRange -- broke every Go CI job (the whole matrix fails to compile when any one package doesn't, which is why govulncheck/ golangci/postgres-durable-first/race all failed identically, not just go-test). Restores params.go/params_test.go verbatim from this branch's own last commit (a strict superset of validation: it already cross-checks rekey vs. reject timing windows, which the copied version never did) and folds the 3.0/3.1 fields (HeaderProtectionKey, ContentPaddingAddition, the 5 timing fields, RandomTrailers/DisableCookies) into Obfuscation31 itself, matching the original struct exactly instead of as separate top-level Instance fields. instance.go, the two amneziawgnet call sites, and 7 amneziawgnet test files updated to match. Also drops the one test (sanitizeConfigValue) that only ever served the retired kernel-module .conf writer -- correctly not ported, so the test testing it shouldn't have been copied either. Also fixes 2 CodeQL findings the same push surfaced: a clamped uint64->int64 conversion for the new log view's live byte counters (server.go), and an unneeded len+len sum feeding a slice pre-size in the v6-egress outbound merge (xray.go) -- append already grows correctly without it. * chore(amneziawg): regenerate frontend schemas for updated doc comments npm run gen was missed after the previous commit's types.go doc-comment edits (Obfuscation20 -> Obfuscation31, ValidateHeaderProtection -> ValidateObfuscation in the prose) -- openapigen bakes those comments into the generated schema's description field, so the committed frontend/src/generated/schemas.ts and openapi.json still had the old wording. codegen's git-diff-exit-code check caught it correctly. * fix(amneziawg): narrow 2 test fixtures that collided with MaxForwardedPorts TestCheckForwardedPortsConflict_CollidesWithEnabledInboundPort and ..._NoCollisionWhenPortsDontOverlap used "8000-8100"/"9000-9100" as their ForwardedPorts fixture -- 101 ports each, one over MaxForwardedPorts (100). The cap check (checkForwardedPortsConflict, added this session alongside the SOCKS-phantom-port check) fires first, so both tests got "more than 100 forwarded ports" instead of ever reaching the collision logic they're actually testing. The cap itself has its own dedicated boundary test already; these two just needed a narrower range that still covers/misses port 8080 as intended -- 8075-8085 and 9075-9085, 11 ports each. * fix(amneziawg): checkAmneziawgnetSocksConflict had no receiver in its new home My merge-conflict resolution kept this as a method call (s.checkAmneziawgnetSocksConflict) inside checkPortConflictTx, a plain function with no *InboundService receiver -- upstream's #6225 fix moved the port-conflict check out of the (s *InboundService) method and into this new tx-scoped free function, and I didn't notice the call site needed to change shape too. CI caught it immediately (undefined: s); nothing in this specific package can be locally verified past internal/database's own unrelated, pre-existing CGO build issue on this dev machine. Since the signature had to change either way, folded in the fix already flagged as a separate follow-up: checkAmneziawgnetSocksConflict now takes the caller's db handle instead of fetching its own via database.GetDB(), so it actually runs inside the same serialized transaction #6225 introduced -- previously it sat right next to that race fix without benefiting from it. * fix: address the review findings on the embedded AmneziaWG PR 5 blocking findings: - Floor S3/S4 at 12 in both obfuscation generators (Go and frontend) and reject a hand-edited value below that when HeaderProtectionKey is set -- IpcSet requires it, and ~39% of previously-generated sets violated it silently. - Guard PrivateKey/PrimaryDNS/SecondaryDNS/remark against newline injection in the AmneziaWG .conf builder (both the Go subscription-link path and the frontend downloadable-config path) -- unguarded, any of them could inject an arbitrary config line into a subscriber's client. - Bound the derived AmneziaWG SOCKS relay port to <= 65535 once an inbound's id is known, and check the reverse direction (does the relay port collide with an existing inbound's port) on both create and update -- previously only port -> relay collisions were checked, not relay -> port. - Gate injectAmneziawgV6Egress on the same V6AliasesActive predicate desiredV6Aliases already uses, so the two can't disagree about whether a peer's IPv6 identity is actually active at the OS level. 2 minor findings: - Fix the forwarded-ports cap check's off-by-one (a spec covering exactly the cap was rejected as if it were over it). - Correct docker-compose.yml's stale comment describing the retired DKMS/kernel-module architecture. * chore: retrigger CI build (armv5) failed on a transient Go module proxy network error (INTERNAL_ERROR stream reset on sagernet/sing), unrelated to this PR's changes. * docs: fix doc comments still describing the retired DKMS/awg-quick design A few doc comments (and one illustrative test log line) survived the embedded-architecture cutover unchanged and now contradict the code they sit next to: - internal/amneziawg/types.go's package comment claimed this package still owns a Manager that reconciles OS-level interfaces via awg-quick/DKMS -- that Manager was removed; the reconcile loop lives in internal/amneziawgnet now, and this package is protocol-shape-only. - internal/amneziawg/params.go's ValidateObfuscation/ValidateConfigValue comments cited "awg-quick up" / "awg-quick executes as root" as the reason to validate -- the server itself never calls awg-quick in this architecture; the same value still reaches a real rendered .conf that a client app or an admin's own awg-quick CLI applies downstream, so the validation is still warranted, just for a different consumer. Mirrored the same fix in inbound_amneziawg.go's matching comment and its test's comment. - internal/amneziawgnet/manager.go's Manager doc comments (x3) pointed readers at "internal/amneziawg.Manager" for comparison -- that type no longer exists in this diff at all. Repointed at internal/mtproto.Manager, the pattern this was actually modeled on and the one that's still real. - Swapped one test's illustrative "awg-quick up awg2 failed" log line for a message shaped like this architecture's actual amneziawgnet logging, so a reader skimming the test doesn't wonder whether the server still shells out to awg-quick. No behavior change. * fix(docs): re-run codegen for xray-settings.mdx after conflict merge The automated conflict-resolution hand-merge for this generated file was content-correct but didn't byte-match a real regen (different YAML long-string folding style). Re-ran npm run gen + docs' gen:api and kept that canonical output instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(amneziawg): drop the dead access-log email backfill amneziawgEmailIndex keyed peers by "<tag>|<tunnel IP>", a scheme built for the retired TPROXY bridge where the peer's decapsulated tunnel address survived as the access log's from-address. The embedded architecture relays through a loopback SOCKS5 dial, so every AmneziaWG log line's from-address is 127.0.0.1:<ephemeral> and the lookup could never match: the index was rebuilt on every log view just to miss. Remove the index, its GetXrayLogs wiring and its test. If per-line emails are wanted back, the relay would have to publish a local-port->email registry for the viewer to resolve loopback sources. * fix(api): generate AmneziaWGLogs/PeerActivity schemas instead of hand-writing them The amneziawglogs endpoint's response structs were missing from openapigen's StructAllow, so they were silently absent from every generated schema/example, the endpoints.ts entry carried a hand-written response, and AmneziaWGLogModal.tsx duplicated the shapes as local interfaces - the exact drift the allowlist rule exists to prevent. Allowlist both structs with example tags, point the endpoint at the generated schema, import the generated types in the modal, and sync docs/public/openapi.json. * chore(amneziawg): drop the unreferenced quiccapture package Nothing imports internal/amneziawg/quiccapture and no route exposes it; its package doc justifies the code as a port of frontend/src/lib/xray/i1Generators.ts, which does not exist in this repository, and promises an API round-trip that also does not exist. 1,110 lines of unreachable code with misleading provenance claims. Revert this commit to bring the package back when the live-capture I1 feature and its frontend counterpart actually land. * fix(clients): re-run cross-inbound conflict checks on the serialized writer The new client-level checks - cross-inbound AllowedIPs collisions and AmneziaWG forwardedPorts conflicts - read a fresh DB snapshot, decide, and only then enter runSerializedTx, while lockInbound only serializes writers on the SAME inbound. Two concurrent client creates on two different tunnel inbounds both passed the read and both committed, yielding two peers with one address: the exact check-then-claim race 81cfd857 (#6225) closed for AddInbound, which this PR's own checkAmneziawgnetSocksReverseConflict already cites. Keep the pre-tx pass for fail-fast UX and re-validate inside the transaction, where the single writer makes the answer authoritative. The race test drives two goroutines at two inbounds and demands exactly one winner; it fails with committed=2 when the in-tx re-check is removed. * fix(amneziawg): hot-apply depletion disables like mtproto does applyTrafficMutationBatch special-cases MTProto so a quota/expiry depletion cuts the sidecar immediately, but AmneziaWG fell through to runtime AddUser/RemoveUser - explicit no-ops for this protocol - so a depleted peer kept tunneling until the next 10s reconcile tick. Route it through applyLocalAmneziaWG, whose own contract (re-read committed settings, filter depleted clients, push to the interface) is exactly this case; the comment claiming it mirrors applyLocalMtproto is now true for the depletion path too. * fix(amneziawg): persist cleared DNS fields instead of resurrecting defaults PrimaryDNS/SecondaryDNS marshaled with omitempty, so clearing them persisted settings with no key at all - and the frontend re-parses stored settings through a Zod schema whose .default('8.8.8.8') / .default('8.8.4.4') fire on missing keys, silently repopulating the form on every load and re-persisting the defaults on the next save. Blank is a documented, meaningful state (no DNS line in client configs); drop omitempty so a cleared value survives the round-trip. The regression test normalizes a server block with cleared DNS and fails when the keys are dropped. * fix(amneziawg): accept cleared numeric obfuscation/subnet fields in the form AntD InputNumber emits null when cleared, Zod .default() only replaces undefined, and unlike wireguard.ts - whose optionalClearedInt comment documents exactly this failure mode - the AmneziaWG schema declared subnetCidr and jc/jmin/jmax/s1-s4 as bare z.number() defaults. Clearing any of the eight fields made safeParse reject the null and block the save until the user retyped a value. Absorb null into undefined while keeping each field's schema default, so a cleared field refills its documented default and legacy blobs with absent keys behave as before. * fix(amneziawg): guard the third .conf emitter against newline injection The review-round fix added the newline guard to amneziaWGConfigText (Go) and buildAmneziaWGClientConfig, but genAmneziaWGConfig in inbound-link.ts - the third of the three emitters its own comment says must not drift - still rendered privateKey/primaryDns/secondaryDns/remark unescaped, so a newline there injected a config line (e.g. a rogue PostUp) into the inbound form's downloaded .conf. Add the same guard, plus the regression tests the original fix shipped without: all four fields on the Go and both frontend emitters go red if any guard is removed. * test(amneziawg): pin the S3/S4 floors the TS drift guard claims to mirror The test's docstring says it mirrors internal/amneziawg/params_test.go, but it asserted S3>=8/S4>=4 while the Go test and both generators pin 12/12 - the floor ValidateObfuscation enforces whenever a header protection key is set, which this generator always sets. A regression narrowing the TS floors into 8-11/4-11 would have passed the drift guard and produced configs the backend rejects on save. * docs: restore the pia repo-map entry and document the AmneziaWG subsystem Merging main dropped CLAUDE.md's internal/pia/ bullet (added by #6272) while resolving the repo-map conflict - the package itself is untouched. Restore it, add the missing map entries for the two packages this branch introduces (internal/amneziawg/, internal/amneziawgnet/), bump the cron count, and give amneziawg_job its row in architecture.md's 5.4 table. * chore(amneziawg): correct comments stranded by the architecture pivot ae77c7e9's cutover to the embedded gVisor path deleted the kernel-module code but left several comments describing it in the present tense: hot_diff.go cited the removed service.amneziawgEgressStreamSettings and wrongly claimed AmneziaWG is the only sockopt.tproxy source (tunnel's TProxy mode is the live one the guard protects), socks_config.go pointed at the deleted EgressBasePort/EgressPortForInbound, manager.go referred to the deleted Manager and its fingerprinting as live code, web.go's cron registration claimed the job scrapes traffic (its own doc says it does not), and types.go capped ContentPaddingAddition at uint16 when validation and upstream both use uint32. * style(lint): satisfy gofumpt/goimports so make verify is green json_service.go's two 'Tag: "proxy"}' literals came in with main's own cc245a90 formatting commit and fail the repo's gofumpt gate for everyone; the import grouping in inbound_amneziawg.go is from the serialized-writer fix on this branch. --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com> Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>	2026-08-24 02:41:15 +02:00
Kuzz007	1250fbb734	feat(clients): allow removing a single HWID device (#6265) ... * feat(clients): allow removing a single HWID device Only "list" and "clear all" existed for registered HWID devices, so freeing one slot under a client's HWID limit meant clearing every device and waiting for the ones you kept to re-register. Adds a per-device delete: DELETE /panel/api/clients/hwids/:email/:id, scoped to the client's own sub_id (device ids are a global auto-increment, not per-subID, so this also prevents deleting another client's device), plus a delete button next to each device in the existing HWID modal. Addresses MHSanaei/3x-ui#6245. * feat(clients): surface HWID limit + device log in the client info card Mirrors the existing IP-limit row/eye-icon-modal pattern that's already in this card. The HWID devices modal reuses the same list/clear-all/per-device-delete UI already shipped for the edit form's own HWID modal, so a device can be removed without opening the edit form at all. * i18n: add HWID single-delete strings to all 13 locales deleteHwid/deleteHwidConfirm/hwidDeleted were only added to en-US and ru-RU in the previous commit; backfilling the other 11 locales the project's own translation set covers. * fix(clients): address automated review of HWID single-delete PR - ClientInfoModal: use the existing dateLabel() helper (Jalali-aware) for HWID first/last-seen instead of a raw dayjs format, matching every other timestamp in the same modal. - Add okText/cancelText to the delete-device Popconfirm in both ClientInfoModal and ClientFormModal so all 13 locales get a translated confirm dialog instead of Antd's English default. - deleteHwid controller: stop reusing the success toast key on both error paths, which rendered a red "Update successful" toast on a real (not just theoretical) failure such as a stale HWID modal. - Trim DeleteClientHwid's doc comment to the repo's 2-line cap and correct it: deletion is scoped by sub_id, which can span more than one ClientRecord, not strictly "this client only". - Add TestDeleteClientHwid covering cross-sub_id id rejection, unknown id rejection, and a real successful delete. * chore: retrigger CI (previous run stuck installing Playwright Chromium) * fix(clients): address the arbiter review on the HWID single-delete PR - Extract the HWID device list into a shared frontend/src/lib/clients/ hwid-log.ts type/normalizer, a shared useClientHwids hook, and a shared ClientHwidListModal component, mirroring the existing IP-log pattern. ClientInfoModal and ClientFormModal both render the same component now, so the two copies can no longer drift the way they already had (different date formatting, different tag styles). - Add a Popconfirm to the HWID "Clear all" button (previously unconfirmed, unlike the per-device delete right next to it) — closes the confirm/no-confirm asymmetry the review flagged as the main risk. - Sync docs/public/openapi.json with the two hwids paths and regenerate clients.mdx. Scoped to just those two paths rather than a full copy from frontend/public/openapi.json: the docs copy is far enough behind on unrelated paths (a host-group API rename) that a full sync breaks the Next.js build on locale pages referencing the old shape — out of scope for this PR. * fix(clients): trim HWID list comment blocks to 2 lines Repo convention caps comment blocks at 2 lines; both were 1 line over. * chore: retrigger CI build (arm64) and build (armv6) failed on a transient Go module proxy network error (INTERNAL_ERROR stream reset), unrelated to this PR's changes.	2026-08-21 14:17:05 +02:00
Sanaei	b9eda09da9	chore(frontend): update dependencies and adapt to oxlint 1.79 ... npm install was failing with ERESOLVE: the lockfile pinned storybook 10.5.7 and vitest 4.1.10 as peers while package.json asked for ^10.5.9 and ^4.1.11, and npm would not move either. Neither npm update, a targeted install, nor --package-lock-only broke the cycle, so node_modules and package-lock.json were regenerated from scratch (601 packages, 0 vulnerabilities). oxlint 1.79.0 then promoted five React Compiler rules into the correctness category, flagging 101 pre-existing sites. 1.78.0 exits 0 on the same tree, so nothing in our code changed - the rule set grew. They are fixed rather than suppressed: - refs (31): latest-value ref writes moved out of render into an effect. onlineClientsRef turned out to be write-only and is gone; expireDiffRef and trafficDiffRef were replaced by reading the values directly. - set-state-in-effect (55): reset-on-open modals now adjust state during render; where an effect mixed a synchronous reset with an async fetch, the reset moved to render and the effect kept only the request. useMediaQuery became useSyncExternalStore. - preserve-manual-memoization (11): optional-chained deps the compiler cannot match, hoisted to locals or dropped where the memo wrapped a string concat. - purity (3): Date.now() in render replaced by a state-backed clock, which also refreshes the expiry tag every 60s instead of freezing it until the next unrelated re-render. - immutability (1): applyClientStatsEvent merged websocket traffic into DBInbound rows in place; it now rebuilds only the rows it touches. Two things fell out of that. clientCount is derived with useMemo instead of an imperative rebuildClientCount() called from five sites, which also fixes a staleness bug where changing the expiry or traffic threshold left the counts alone until some later rebuild. statsVersion existed only to force a re-render after an in-place mutation, is meaningless now that rows are replaced, and nothing read it, so it is removed. Also adds a lint:fix script - oxlint --fix was previously only reachable through the lint-staged hook.	2026-08-19 17:48:28 +02:00
Sanaei	92fb94d856	Move to TypeScript 7 and the oxc toolchain (oxlint + oxfmt) (#6262) ... * chore(frontend,docs): move to TypeScript 7 and replace ESLint with oxlint TypeScript 7 is the native Go port and ships no programmatic compiler API, so typescript-eslint cannot run at all: it peer-pins typescript >=4.8.4 <6.1.0 (canary too) and hard-crashes with "typescript-eslint does not support TS 7.0". Upstream support is tracked in typescript-eslint#10940 and targets TS >=7.1. Rather than wait, or carry Microsoft's side-by-side alias (which keeps a second TS 6 install alive purely to feed the linter), both projects move to oxlint, which never depended on the TypeScript API. Typecheck drops from ~9.7s to ~2.2s and 167 packages leave frontend/. oxlint has no no-restricted-syntax, so the #6121/#6127 cleared- InputNumber guard is reimplemented as a JS plugin in frontend/tools/oxlint/. It was verified to still fire in pages/settings/** and pages/xray/** and to stay exempt in *Modal.tsx. The type-aware @deprecated sweep survives too, as `npm run lint:deprecated`: oxlint's type-aware mode runs on oxlint-tsgolint, which drives the TS 7 typescript-go checker, so the TS 7 move is what makes it possible. Behaviour is preserved rather than tightened. jsx-a11y/prefer-tag-over-role is off in both configs because it was never part of the recommended sets ESLint actually ran, and oxlint honours the existing eslint-disable comments, so no source churn was needed. Two real fixes fell out of the stricter linting: - outbound-link-parser.test.ts used `out?.streamSettings` behind an `as` cast, which hid the optional chain from ESLint and would throw on a null parse; the rest of the file already used `out!`. - InputAddon's conditional role/tabIndex/onKeyDown is genuinely accessible but oxlint cannot evaluate it, so it gets a scoped disable. * chore(docs): replace Prettier with oxfmt oxfmt is the oxc project's Prettier-compatible formatter, so this pairs with the oxlint move and drops the last JS-based tool from the docs toolchain. The swap is behaviour-preserving. Running Prettier and oxfmt over the same files, with the existing .prettierrc.json settings migrated via `oxfmt --migrate=prettier`, produces byte-identical output on every file. (Comparing them outside the project directory is misleading: Prettier silently falls back to its defaults when it cannot find its config, which looks like a mismatch but is not one.) The 18 files reformatted here were already failing `pnpm format:check` before this change — Prettier wanted the exact same edits. The check is not part of docs-ci.yml, which is why the drift went unnoticed. .prettierignore becomes ignorePatterns in .oxfmtrc.json, keeping the deliberate MDX exclusion: reflowing MDX prose merges headings into paragraphs and collapses lists inside Steps/Callout components. Both that and the generated fumadocs-openapi reference output were verified untouched. oxfmt is pinned to 0.63.0 rather than latest. pnpm 11's built-in minimumReleaseAge policy rejects same-day releases, and 0.64.0 would have made pnpm silently append 20 waiver lines to pnpm-workspace.yaml. * style(frontend): adopt oxfmt and format src frontend/ has never had a formatter, so this reformats 344 of 497 files in src/. The change is purely whitespace, quoting and line wrapping — no logic is touched. It is kept in its own commit so it does not bury the TypeScript 7 / oxlint migration or the git blame for the code itself. Settings match docs/ and the code as it was already written: single quotes, semicolons, trailing commas, 2-space indent, 100 columns. That was measured rather than assumed — src/ was already uniformly single-quoted and 2-space indented, with p90 line length at 75. Formatting is scoped to src/ (mirroring `oxlint src`) and .oxfmtrc.json ignores src/generated. Both matter: `make gen-check` compares src/generated and public/openapi.json, and `make msw-worker-check` byte-compares public/mockServiceWorker.js against the installed MSW runtime, so reformatting any of them breaks the gate. Reflowing also moves `eslint-disable-next-line` comments off the line they guard, which broke two suppressions that had been silently correct before: - clone-inbound-modal.test.tsx: the object literal became multi-line, leaving `} as any;` four lines below its no-explicit-any disable. - ClientsPage.tsx: the useMemo dependency array moved onto its own line, out from under its exhaustive-deps disable. Both comments were relocated onto the line they actually guard, and verified to still suppress by removing them and watching the errors return. * ci: enforce formatting in CI and make verify Adding oxfmt in the previous two commits gave both projects a formatter but nothing that checks it, which is how docs/ had already drifted to 18 unformatted files: docs-ci.yml runs typecheck, lint, test and build, but never format:check, so Prettier's complaints were only ever visible to whoever ran it by hand. Wire `format:check` into the frontend job in ci.yml and the docs job in docs-ci.yml, and add a `format-check` target to `make verify` so the local gate keeps mirroring CI as the Makefile header promises. Verified the step actually bites rather than passing vacuously: adding a badly formatted line to a source file in each project makes both `make format-check` and `pnpm format:check` fail, and reverting it makes them pass again. No workflow referenced ESLint or Prettier by name — they all invoke the package scripts — so the tooling swap needed no other CI changes. * ci: trigger CI on Makefile changes The path filters listed **.go, go.mod, go.sum, frontend/**, .nvmrc and ci.yml itself, but not the Makefile — so a change to the canonical task runner that ci.yml is meant to mirror could land without any job running. The previous commit, which edits both, only triggers because it happens to touch ci.yml too. * fix(frontend): replace deprecated Ant Design 6 APIs in the geo components `npm run lint:deprecated` reported five uses of props Ant Design 6 has deprecated. All five are gone, and the matching runtime warnings no longer appear in the test output. Tag `bordered={false}` becomes `variant="filled"` and Space `direction` becomes `orientation`; both are the one-to-one replacements named in antd's own deprecation messages, and `direction`/`orientation` share the same Orientation type. Input `addonAfter` is the one that is not a rename. It becomes a `Space.Compact block` wrapping the Input and the browse Button, which is antd's documented migration. `block` keeps the field filling its form row as the addon did. Note this is a deliberate visual change: the button used to be a borderless `type="text"` icon sitting inside the addon's grey box, and is now a regular button whose border joins the input. The tooltip, aria-label, ref, id and onBlur wiring are unchanged, so the react-hook-form binding in RuleFormModal and the existing tests still address it the same way. Only these five were deprecated. The other `bordered` props in the tree sit on QRCode, Table, Descriptions and Alert, where the prop is not deprecated, and these were the only two Space `direction` uses in the codebase. * fix(frontend): restore lint rules lost in the oxlint migration, and test the guard Addresses the review on #6262. The frontend config re-enabled only no-explicit-any and no-unused-vars and left the rest of tseslint's recommended set to oxlint's correctness category. It does not cover all of it. Confirmed by linting one probe file against both configs: docs/ (which enumerates the rules) reports all nine, frontend/ reported four. So ban-ts-comment, no-empty-object-type, no-namespace, no-require-imports and no-unsafe-function-type had silently stopped being enforced — a `// @ts-ignore` or a `namespace` block would have landed unflagged. The ten rules are now mirrored from docs/.oxlintrc.json, and src/ still passes. The #6121/#6127 guard was 57 lines of hand-written AST walking with no test. It now has one: fixtures for the three banned shapes plus an onNumber()-wrapped control, asserting the rule fires three times and that .oxlintrc.json still wires it to the right paths. Verified it fails for the right reason by making walk() enumerate nothing, which is the silent-death mode the review described — the traversal depends on Object.keys() seeing AST children as own enumerable properties. The fixtures deliberately violate the rule, so their oxlint config is named guard.oxlintrc.json rather than .oxlintrc.json: oxlint discovers nested configs by directory, which would otherwise turn the fixtures into three lint errors. The test passes it explicitly with -c. Also from the review: - lint and format now cover tools/ as well as src/, so the one piece of hand-written lint logic in the repo is no longer the least covered file in it. - lint-staged runs oxfmt before oxlint --fix. Formatting became a hard CI gate in this PR while the hook only ran the linter, so a commit could pass the hook and fail CI on formatting alone. - .oxfmtrc.json ignores public/, so the artefacts that make gen-check and make msw-worker-check byte-compare stay safe even if oxfmt is invoked without a path argument. - The MDX and generated-reference rationales that .prettierignore carried are back as comments in docs/.oxfmtrc.json — oxlint and oxfmt both accept JSONC, so relocating them was unnecessary. Not applied: the review also suggested restoring ../internal/web/dist to the ignore lists. Both tools reject `..` patterns outright ("patterns are resolved within the config file's directory"), and being outside frontend/ it is unreachable anyway.	2026-08-19 15:36:27 +02:00
n0ctal	b8903fadf4	feat(clients): renew on a calendar day instead of a rolling interval (#6239) ... * feat(clients): renew on a calendar day instead of a rolling interval Auto-renew advances the expiry by a fixed number of milliseconds, so a client set to 30 days drifts against the calendar: renewing on 31 January lands on 2 March, and by the end of the year the billing day has wandered a fortnight from where the operator's own plan resets. Add a per-client renewal day. When set, the expiry steps whole calendar months at midnight in the panel's time zone. A month too short for the chosen day renews on its last day and the following month returns to the chosen one, so the 31st does not decay into the 28th permanently. Zero keeps the interval mode, so existing clients are untouched. The interval branch now also refuses a zero step. It is unreachable while the selection filter holds, but that loop runs on the single traffic writer, and a zero interval there would hang every panel mutation behind it. * fix(clients): persist the calendar renewal day on the client record resetDay lived only in the inbound settings JSON and client_traffics, so every path that rebuilds a client from the clients table wrote it back as zero: an ordinary edit, an attach to a second inbound, a traffic reset on a disabled client. Calendar mode turned itself off during normal use and the operator only found out a month later. Adds reset_day to ClientRecord and threads it through ToRecord, ToClient, applyClientRecordMerge and the record update map, so the value survives the round trip. The clients page filter and ClientSlim now recognise the mode, nodeClientRenewed classifies a calendar renewal as a renewal, the node snapshot merge carries reset_day, and the service layer rejects a day outside 0-31 rather than clamping it silently. Also renames the label keys to renewOnDay to keep them apart from the existing renewDays, translates them and the new RESET_DAY subscription placeholder in all 13 locales, adds the field to the bulk-add modal, and drops the stray internal/web/dist/.gitkeep build stub. * fix(clients): let the billing day be changed after creation ClientService.Update writes the record columns directly only for a client with no inbounds. The normal path goes through SyncInbound and applyClientRecordMerge, which this change had not extended, so moving a client from the 20th to the 5th updated the inbound settings JSON while clients.reset_day kept the old value and the renewal kept using it. The existing test did not catch it: it asserted the day survived an unrelated edit, and it survived precisely because nothing on that path ever wrote it. TestClientEditChangesTheBillingDay moves the day and then switches calendar mode off again; removing the record write turns it red. * chore: drop the accidentally committed dist build stub internal/web/dist/.gitkeep is what make dist-stub creates locally. Committing it changes fresh-clone behaviour for everyone: today a bare go build fails loudly on //go:embed all:dist, which is the documented signal to run the stub target; with the file present the build succeeds and the panel serves an empty dist instead. --------- Co-authored-by: n0ctal <n0ctal@users.noreply.github.com> Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>	2026-08-18 12:46:00 +02:00