4 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
GrigoriyandSTRENCH0	d7698ec7aa	feat(xray): browse geosite/geoip categories from routing rules (#6165) ... * feat(xray): browse geosite/geoip categories from routing rules Routing rules made you type category names from memory: nothing showed which categories a database actually contains, what is inside one, or whether a name resolves at all — a typo only surfaced when Xray refused the config. The panel now reads Xray's .dat databases itself and exposes them over four endpoints: databases in the asset folder, a database's categories, one page of a category's rules, and validation of the tokens already in a rule. The reader walks the protobuf wire format directly rather than decoding into Go structs, because a 10 MB geosite.dat holds well over a million domains and materialising them costs ~284 MB where streaming costs ~19 MB. Only the category index is cached, entry pages are scanned on demand, and scans are serialised, so twenty concurrent requests peak at 87 MB instead of 1 GB. A database's type is decided by its contents, not its file name, since custom .dat files are named freely. In the rule form, the source-IP, IP and domain fields gain a database button opening the browser: search over categories, a preview of what a category holds, and a multi-select that merges into the field. Plain domains, CIDRs and categories the panel does not know are left untouched; categories already present come back ticked, and unticking one removes it from the rule. * fix(xray): read geo databases through os.Root and match codes verbatim CodeQL flagged the database read as a path built from a user-supplied value, and it was right about the shape of it. The file name arrives in a request; resolve() rejects traversal and stats the file through an os.Root, but the read itself went through a joined path with os.ReadFile. That left the symlink defence incomplete: the stat could pass while the read followed a link planted — or swapped in — afterwards. Reads now go through the same root, so a request-supplied name never becomes a path this code resolves on its own, and the size limit is applied to the opened file rather than to a separate stat of it. Lookup no longer trims the category code either. It backs the routing-token validator, and the core matches codes verbatim: "geosite: cn" will not start Xray, so repairing that space here hid exactly the typo the validator exists to report. * fix(xray): address review findings on the geo category browser Asset folder. The browser read config.GetBinFolderPath() unconditionally, but the core honours a preset XRAY_LOCATION_ASSET and only falls back to the bin folder (ensureXrayAssetLocation). On an install pointing at a shared asset directory the panel listed an empty folder and reported perfectly valid geosite:/geoip: tokens as missing — the validator warning about a correct config. The directory is now resolved with the core's precedence. Paging. Serving one page read and rescanned the whole database, so walking category-ads-all re-read it per page. The index now records each category's byte range and a page reads only that record through the os.Root handle, with the current category's records held for the duration of a paging session. Profiling that also showed the real cost was not the read but the slice of payload pointers built per call — a category holds a hundred thousand of them — so records are now walked with a callback instead. Ten pages over category-ads-all: 239 MB allocated, now 4.3 MB. Cached failures. Any error from reading a file was latched under the file's size+mtime, so a transient ENOMEM or EMFILE marked a healthy database as damaged until it changed on disk. Only deterministic failures are cached. Wrong kind. A geoip: token typed into a domain field parsed as a plain domain and was waved through, though the core cannot resolve it as one. It is now reported, with its own reason and wording. Frontend. The category filter fed the query key on every keystroke, so each character triggered a request that re-scanned the database; it is debounced now. GeoTokenInput accepts and forwards a ref, so React Hook Form can focus these three fields on a validation error again. A failed validation shows that it failed instead of rendering the same empty state as "no issues". Also drops an unreachable branch in the token-count guard and corrects the categories endpoint docs, where limit is unbounded by default. --------- Co-authored-by: STRENCH0 <17428017+STRENCH0@users.noreply.github.com>	2026-08-15 17:12:59 +02:00
Grigoriy	d2efe9b022	fix(sub): include native WireGuard clients in Clash and JSON subscriptions (#5676) ... The Clash (buildProxy) and JSON (getConfig) subscription generators had no WireGuard branch, so a native WireGuard inbound's clients were silently dropped: buildProxy hit its default nil case, and getConfig emitted a config with no proxy outbound. Only the raw subscription (genWireguardLink) and external-link Clash path handled WireGuard. Add a WireGuard case to both generators, mirroring genWireguardLink: the peer public key is derived from the inbound secretKey, while the private key, tunnel address (mihomo ip/ipv6, Xray settings.address), pre-shared key and keep-alive come from the client. The peer routes the full tunnel (0.0.0.0/0, ::/0), which both mihomo and Xray also default to. Field names verified against the mihomo WireGuardOption source (private-key, public-key, pre-shared-key, persistent-keepalive, ip, ipv6, mtu, dns) and the Xray wireguard outbound schema (secretKey, address, peers[].publicKey/endpoint/ preSharedKey/keepAlive/allowedIPs, mtu).	2026-07-09 00:52:46 +02:00
Grigoriy	cb5b3a803a	fix(wireguard): build peers in GenXrayInboundConfig so node reconcile keeps clients (#5684) ... Adding a WireGuard client on the master broke every WireGuard connection on the sub-node until Xray was manually restarted on the node. Adding the same client directly on the node worked. Root cause: the panel stores WireGuard clients under the settings key `clients` (the shape every other protocol uses), but xray-core's wireguard inbound is configured with `peers`. The `clients`->`peers` conversion lived only in the full-config generation path (XrayService.GetXrayConfig), which runs on a full Xray restart. The live gRPC AddInbound path goes through (*Inbound).GenXrayInboundConfig, which passed the WireGuard settings verbatim - with `clients` and no `peers`. Why the master path broke it and the node path did not: - Adding on the node is a single safe operation: AddInboundClient -> AddUser -> AlterInbound{AddUser} -> wireguard.Server.AddUser, which appends one peer via IPC without touching the others. The inbound is local (NodeID == nil), so nothing is marked dirty and no reconcile runs. - Adding on the master does two things: it pushes the client to the node (the same safe hot-add, which succeeds), and it marks the node dirty. The reconcile then pushes panel/api/inbounds/update/:id to the node, whose InboundService.UpdateInbound applies it live via DelInbound + AddInbound (buildRuntimeInboundForAPI -> Local.AddInbound -> GenXrayInboundConfig). That re-adds the wireguard inbound with zero peers, wiping the device and dropping every connected client. A manual restart regenerated the full config, converted clients to peers, and restored them - hence "only a restart fixes it". Fix: convert WireGuard `clients` to `peers` in GenXrayInboundConfig itself, the single chokepoint for every live AddInbound (create, edit, node reconcile). WireguardClientsToPeers always rebuilds `peers` from `clients` (matching GetXrayConfig field for field) and drops the `clients` key. It does not gate on `peers` being absent: the panel seeds every WireGuard inbound with an empty `peers: []` placeholder (frontend inbound-defaults), so a "skip if peers present" guard would match that placeholder and make the conversion never run, leaving the live path emitting zero peers. The conversion stays idempotent by removing `clients`, so a second call - or an inbound with no `clients` - is a no-op, leaving the full-config path unaffected. This also fixes plain WireGuard inbound edits on a standalone panel, which went through the same peerless rebuild.	2026-07-09 00:52:03 +02:00
3 people	f90e4a6962	fix(panel): use the hosting node address for WireGuard client configs (#5679) ... * fix(panel): use the hosting node address for WireGuard client configs The clients page rendered a node-managed WireGuard inbound's config with the master panel's host in Endpoint instead of the hosting node's address, so the copied/QR config pointed at the wrong server. The subscription path already resolves this via resolveInboundAddress; the UI generator did not. Expose the share-host resolution inputs (node address, listen, share-address strategy/address) on InboundOption and route buildWireguardClientConfig through the same canonical resolver the inbounds-page share links use, extracted as resolveShareHost. This also brings local inbounds with a shareable listen or a listen/custom share strategy into parity with the subscription Endpoint; the common listen=0.0.0.0 case still falls back to the panel host. * fix(frontend): keep a raw fallback host and refresh node-fed inbound options Code review of the WireGuard node-endpoint change surfaced two gaps. resolveShareHost normalized its last-resort fallbackHostname, so a panel reached via a hostname the share-host grammar rejects (underscore label, trailing-dot FQDN) emitted a broken 'Endpoint = :51820'; the fallback now stays verbatim when normalization empties it. Node mutations only invalidated the nodes query, leaving the staleTime-Infinity inbound options cache serving an edited node address until the sync job broadcast (never, for disabled/offline nodes); they now invalidate the options key too. Also folds the ShareHostFields projections into direct structural passes, elides the default node shareAddrStrategy so omitempty drops it, and replaces the nullable node-address scan with COALESCE. --------- Co-authored-by: STRENCH0 <17428017+STRENCH0@users.noreply.github.com> Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>	2026-07-03 01:12:32 +02:00