feat(wireguard): support WireGuard as an Xray inbound - #672
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughXray now parses and indexes WireGuard inbounds, while the dashboard sanitizes, validates, renders, and auto-generates WireGuard-specific settings. Subscription preparation defaults missing pre-shared keys to empty strings, and usage-statistics handling receives comment and syntax updates. ChangesWireGuard inbound support
Usage statistics processing cleanup
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Dashboard
participant XrayConfig
participant WireGuardKeyHelper
participant InboundIndexes
Dashboard->>XrayConfig: submit sanitized WireGuard inbound
XrayConfig->>WireGuardKeyHelper: derive public key from secret key
XrayConfig->>InboundIndexes: register WireGuard tag and settings
Possibly related PRs
Suggested labels: Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
is ther any changes require in https://github.com/PasarGuard/node_bridge_py ? |
no change required |
|
Synced with upstream main and dropped the WireGuard stats workaround, see PasarGuard/node#64 for the root cause.
Also fixed a Python 2-style Verified end-to-end in Docker: panel + node + xray v26.7.11, real WireGuard client, traffic through the tunnel, used_traffic updates correctly on the user, no pubkey mapping involved. |
|
@coderabbitai review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
app/core/xray.py (1)
419-425: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winNarrow the exception clause and validate the port.
Catching
ValueErroris safer than a broadException, which could mask unexpected errors likeTypeError. Additionally, explicitly validating that theportkey exists ensures consistency with how other inbounds handle missing ports via_handle_port_settings.♻️ Proposed refactor
- try: - public_key = get_wireguard_public_key(secret_key) if secret_key else "" - except Exception: - public_key = "" - settings = self._create_base_settings(inbound) - settings["listen_port"] = inbound.get("port") + try: + public_key = get_wireguard_public_key(secret_key) if secret_key else "" + except ValueError: + public_key = "" + settings = self._create_base_settings(inbound) + + if "port" not in inbound: + raise ValueError(f"{inbound['tag']} inbound doesn't have port") + settings["listen_port"] = inbound["port"]🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/core/xray.py` around lines 419 - 425, In the public key setup around get_wireguard_public_key, catch only ValueError instead of broad Exception. Replace the direct inbound port assignment in the settings construction with the existing _handle_port_settings validation so missing or invalid port keys follow the established inbound behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@app/core/xray.py`:
- Around line 419-425: In the public key setup around get_wireguard_public_key,
catch only ValueError instead of broad Exception. Replace the direct inbound
port assignment in the settings construction with the existing
_handle_port_settings validation so missing or invalid port keys follow the
established inbound behavior.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 4a7b9aea-3791-4b86-a901-f2790949bb36
📒 Files selected for processing (2)
app/core/xray.pyapp/jobs/record_usages.py
Recognize a `wireguard` protocol inbound inside an Xray core so its tag is exposed (via /api/inbounds) and users can be assigned to it, and attribute its per-user traffic/online state. Xray now ships a first-class WireGuard inbound with a UserManager (XTLS/Xray-core#6360), so WireGuard can be served through the same Xray core as the other protocols — in addition to the existing standalone WG backend (CoreType.wg). This is purely additive. - app/core/xray.py: `_read_wireguard_inbound` registers a WG-in-Xray inbound (interface/listen_port/address/mtu/public key) alongside the vmess/vless/trojan/shadowsocks/hysteria readers. - app/jobs/record_usages.py: the Xray WG inbound reports per-user stats keyed by the peer's hex public key; map that back to the panel user id so WG traffic and online state are recorded like any other protocol.
The merged xray-core PR (XTLS/Xray-core#6360) matches WireGuard peers on Email like every other inbound, and the node already sends str(user.id) as the Email for WireGuard users (app/node/user.py, serialize_user) same as vmess/vless/trojan/shadowsocks/hysteria. So UsersStat has always arrived keyed by the plain user id for WireGuard too — the pubkey->uid cache in _get_wg_pubkey_to_uid() was solving a problem that didn't exist, added under the assumption that WireGuard's xray-side Email held the peer's public key. Also fixes an unrelated Python 2-style `except ValueError, TypeError:` in _process_users_stats_response that would have crashed the job at runtime, and drops the now-unused base64 import. Verified end-to-end: real WireGuard client -> xray wireguard inbound -> record_user_usages correctly attributes traffic to the user's id with no mapping step.
|
Rebased onto the latest
Local CI is green: |
|
One more fix: creating a host for a WireGuard inbound returned 500.
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
2 participants
What
Lets the panel treat a
wireguardinbound inside an Xray core as a first-class inbound: its tag is exposed (so users can be assigned and subscriptions generated for it), and its per-user traffic / online state are recorded. Purely additive — the standalone WireGuard backend (CoreType.wg) is untouched.Why
Xray now ships a first-class WireGuard inbound with a UserManager (XTLS/Xray-core#6360, in v26.6.27). That makes it possible to serve WireGuard through the same Xray core as VLESS/VMess/Trojan/Shadowsocks — gaining Xray routing, sniffing, unified stats, and transport obfuscation (finalmask) for WG clients — as an alternative to the kernel WG backend. For the panel to use it, the Xray config reader must recognize a
wireguardinbound, and usage recording must map WG stats back to panel users.How
app/core/xray.py— add_read_wireguard_inbound, dispatched from_read_inboundwhenprotocol == "wireguard". Surfaces the inbound tag (appears in/api/inbounds) and captures public params (listen port, address, mtu, derived public key).app/jobs/record_usages.py— Xray's WG inbound reports per-user stats keyed by the peer's hex public key (user>>>{hex_pubkey}>>>traffic) rather than the numeric{id}. Add a cached{hex_public_key -> user_id}map and translate those stat names before recording, so WG traffic and the online indicator attribute to the right user. Non-WG stats unaffected (the map is only consulted for non-numeric stat names).Compatibility / notes
Testing
ruff checkpasses on the changed files;py_compileclean.used_trafficclimbs andonline_atupdates each cycle; 15-minute soak, no disconnects, no client/server errors.Summary by CodeRabbit
New Features
Bug Fixes
UI/Validation
Sanitization