# XrayUI: a native WinUI 3 front end for the Xray core

> XrayUI is a Windows desktop client for the Xray core, written in C# with WinUI 3 and published for x64 and ARM64. It puts a graphical shell around the protocol set Xray already supports, adds TUN mode and geo routing rules, and leaves the actual node configuration to subscription links.

**PhoenixNil/XrayUI-dev** — Lightweight native Windows GUI client for Xray core, built with WinUI 3

- Repository: https://github.com/PhoenixNil/XrayUI-dev
- Website: https://www.xrayui.site
- Stars: 673 · Forks: 67
- Language: C#
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/phoenixnil-xrayui-dev

## A desktop shell over a core you did not write

XrayUI presents itself as a native Windows GUI client for the Xray core, built with WinUI 3 and described as a fast and lightweight proxy client. The distinction in that sentence matters. XrayUI is not a protocol implementation, it is the control surface around one: a Windows desktop application that manages the core process and the connections it carries.

The primary language is C#, and the repository layout is typical of a WinUI 3 project. App.xaml and App.xaml.cs sit at the root next to MainWindow.xaml, with Controls/, Converters/, Helpers/, Models/, Services/, Strings/, Styles/, ViewModels/ and Views/ directories below it. The csproj file is named XrayUI-dev.csproj and the solution is XrayUI-dev.slnx, the newer solution format that Visual Studio now writes.

For a Windows user who already has nodes configured, this is a way to stop editing configuration files. The README is short, so the shape of the interface comes mostly from the feature list and the directory names: a main window, view models for the screens, services for the things the app talks to, and a Strings directory that suggests localised resources.

The audience is Windows 11 and Windows 10 desktop users. There is no Linux or macOS build mentioned anywhere, and the topic tags name windows, windows11, winui and winui3 explicitly.

## Seven protocol families and a TUN mode

The feature list names the protocols directly: Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard and Chain Proxy. That is a wide spread of transports, and it maps closely onto what the Xray core itself speaks, which is the clearest sign that this client sits on top of an existing implementation rather than reimplementing protocol behaviour.

Chain Proxy deserves attention because it is not a single protocol. It routes one outbound through another, and exposing it in a GUI means the client has to model multi-hop configuration in a way a single-node form cannot.

TUN mode is the other feature with real consequences. Instead of only handling traffic that applications explicitly send to a local proxy port, a TUN setup captures traffic at the network interface level and routes it through the core. In practice that means traffic from applications that ignore proxy environment variables still gets handled, and it also means the client has to interact with the operating system network stack in a way that raises the stakes of a misconfigured setup.

Routing is the third area: custom routing rules with geoip and geosite, which let traffic be sent to different outbounds based on the destination's country or site category rather than by address alone.

## Subscription import and auto-connect do the daily work

Three features in the list are about what happens after install rather than about protocols: subscription import and update, auto-start on boot, and auto-connect.

Subscription import is the load-bearing one. Rather than adding servers one at a time by hand, a user points the app at a subscription and the node list is populated from it. The update half of the feature means the list can be refreshed later without re-entering anything. This is also the strongest dependency in the design: the client does not need you to configure individual servers, but it does need a subscription source, and the nodes it shows are only as good as that source.

Auto-start on boot and auto-connect together mean the client can restore a working state after a restart without any interaction, which is what you want for a machine that is always on. Auto-connect combined with TUN mode is the combination with the most operational weight, since a connection that is established automatically at every boot is also one that will be running when something goes wrong.

Theme and protocol color customization sit alongside these in the list, along with AI Unlock Status Detection, a check that reports whether the current configuration passes the checks a service applies to detect access from certain networks.

## Building it needs Visual Studio, Windows 10 1809 and a Rust toolchain

The README documents two build routes and states its prerequisites clearly. Building XrayUI requires Visual Studio and Windows 10 version 1809 or later, and publishing the application also requires the Rust toolchain. The Rust requirement points at the updater-rs directory in the repository, which is a separate Rust component that the publishing step builds.

In Visual Studio you open XrayUI-dev.slnx, select a target platform such as x64 or ARM64, and build the solution.

The PowerShell route is the same thing from a terminal, one build for the target framework and one publish for the runtime:

```bash
dotnet build -c Release -p:Platform=x64
dotnet publish -c Release -r win-x64 -p:Platform=x64
```

The ARM64 variant swaps both the platform property and the runtime identifier:

```bash
dotnet build -c Release -p:Platform=ARM64
dotnet publish -c Release -r win-arm64 -p:Platform=ARM64
```

That pairing of a C# application with a Rust updater is the detail to plan around. Even if you never touch the updater, the publish step expects the Rust toolchain to be present, and the README sends first-time WinUI 3 developers to the Windows App SDK installation instructions before starting.

## Services, ViewModels and a Rust updater in one repository

Based on the repository layout, the application is organised along standard WinUI 3 lines. Views/ and Controls/ hold the XAML user interface, ViewModels/ holds the presentation logic, Converters/ holds the value converters that bridge view models to XAML bindings, and Strings/ holds the string resources that point to localisation rather than hardcoded strings in the markup.

Services/ is where the application's behaviour toward the outside world would live, and given the subject it is where process management for the Xray core, configuration handling and subscription fetching belong. Imports.cs at the repository root is a single shared import file, a common pattern in C# projects for keeping using directives in one place.

The updater-rs directory is the odd one out, since a Rust component in an otherwise C# repository cannot be compiled by the dotnet CLI alone. A separate XrayUI.Tests/ project sits alongside for tests, and app.manifest sits at the root for application manifest settings such as the requested execution level, which matters for a program that installs a network interface driver.

The Apache-2.0 licence covers the project, and the README credits the LinuxDo community.

## What the README does not tell you

The documentation is thin in a few places that matter to anyone running this on a work machine. There is no description of the underlying configuration format, no explanation of where XrayUI stores its settings on disk, and no section on log files or troubleshooting, even though a network client that silently fails to route traffic is hard to debug. The README also does not document a command line interface, which limits the project for scripted or remote management.

The download route is the releases page, and the release history shows steady cadence with recent versions: 1.19 published on 2026-09-28, 1.18 on 2026-07-26 and 1.17 on 2026-07-13. The last push was on 2026-10-09.

Against the alternative of running the Xray core directly with a hand written configuration, the difference is exactly the scope of the GUI. The core is configured with a JSON file that you can version, diff and template; XrayUI replaces that with a desktop application whose state is managed through subscription links and interactive controls. The win is that node management becomes a normal desktop task. The loss is that the configuration stops being a text artefact you can read and check, which is a real cost if you need to audit what the client is doing on a shared or managed machine.

It is also a Windows-only answer to a cross-platform problem, so a Linux workstation or a headless server is outside what this project covers.

## Conclusion

Adopt XrayUI if you run Windows and want to manage Xray nodes through a native desktop interface rather than editing JSON configuration by hand, especially on ARM64 hardware where published ARM64 builds are provided. Skip it if you need a headless server, a Linux or macOS build, or a documented configuration schema you can script against, since the project publishes Windows builds only and the README does not document the underlying config format. Before deploying it, read XrayUI-dev.slnx and the Services directory in the repository to see where the core process and configuration live, and check the release page for the binary matching your architecture. The last push was on 2026-10-09 and release 1.19 was published on 2026-09-28.

## FAQ

### What protocols does XrayUI support?

The feature list names Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard and Chain Proxy. TUN mode is also supported, alongside custom routing rules based on geoip and geosite.

### How do I build XrayUI from source on Windows?

You need Visual Studio and Windows 10 version 1809 or later, and publishing also needs the Rust toolchain. Open XrayUI-dev.slnx and build, or run dotnet build -c Release -p:Platform=x64 followed by dotnet publish -c Release -r win-x64 -p:Platform=x64.

### Does XrayUI support ARM64 Windows devices?

Yes. The build instructions list an ARM64 option with the platform property set to ARM64 and the runtime identifier set to win-arm64, and Visual Studio users pick the target platform when they open the solution.

### Can I add nodes manually in XrayUI?

The documented node flow is subscription import and update, which populates the node list from a subscription source and refreshes it later. The README does not describe a separate manual entry procedure for individual servers.

## Sources

- [License: Apache-2.0](https://github.com/PhoenixNil/XrayUI-dev/blob/main/LICENSE)
- [PhoenixNil/XrayUI-dev on GitHub](https://github.com/PhoenixNil/XrayUI-dev)
- [Project website](https://www.xrayui.site)
- [README](https://github.com/PhoenixNil/XrayUI-dev/blob/main/README.md)
- [Releases](https://github.com/PhoenixNil/XrayUI-dev/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/phoenixnil-xrayui-dev