# Difference Between v2fly, Xray, and sing-box Cores in v2rayN

> Understand the differences between v2fly, Xray, and sing-box cores in v2rayN. Learn which core supports classic and modern proxy protocols for optimal performance.

- Repository: [2dust/v2rayN](https://github.com/2dust/v2rayN)
- Tags: deep-dive
- Published: 2026-02-27

---

**v2rayN uses Xray for classic proxy protocols and sing-box for modern protocols like TUIC and AnyTLS, while the original v2fly core is deprecated and hidden from the UI.**

The 2dust/v2rayN repository is a Windows GUI client for V2Ray that abstracts multiple proxy engines behind a unified interface. Understanding the difference between v2fly, Xray, and sing-box cores in v2rayN is essential for troubleshooting connection issues and selecting compatible protocols.

## Core Types and Active Support Status

### v2fly (Legacy Compatibility Only)

The original `v2fly` core is defined in [`ServiceLib/Enums/ECoreType.cs`](https://github.com/2dust/v2rayN/blob/main/ServiceLib/Enums/ECoreType.cs) but is actively filtered out of the user interface. In [`MainWindow.xaml.cs`](https://github.com/2dust/v2rayN/blob/main/MainWindow.xaml.cs) at line 442, the UI explicitly excludes `ECoreType.v2fly` from the core-type picker dropdown, rendering it invisible to end users. The enum value remains in the codebase solely for backward compatibility with legacy configurations.

### Xray (Primary Engine for Standard Protocols)

**Xray** (`ECoreType.Xray`) is the default engine for traditional proxy protocols. According to [`ServiceLib/Global.cs`](https://github.com/2dust/v2rayN/blob/main/ServiceLib/Global.cs) (lines 307-317), the `XraySupportConfigType` array includes:

- VMess
- VLESS
- Shadowsocks
- Trojan
- Hysteria2
- WireGuard
- SOCKS
- HTTP

The binary is downloaded from the `XTLS/Xray-core` repository, as specified in the `CoreUrls` table at lines 570-576 of [`Global.cs`](https://github.com/2dust/v2rayN/blob/main/Global.cs).

### sing-box (Modern Protocol Engine)

**sing-box** (`ECoreType.sing_box`) supports the complete Xray protocol list plus exclusive modern protocols. The `SingboxSupportConfigType` array (lines 319-331) adds **TUIC** and **AnyTLS** to the Xray set. The exclusive sing-box protocols are computed programmatically at line 333 as `SingboxSupportConfigType.Except(XraySupportConfigType)`. The upstream source is `SagerNet/sing-box`.

## Protocol Support and UI Enforcement

While both cores share common protocol support, v2rayN enforces specific engine assignments through hardcoded logic in [`ConfigHandler.cs`](https://github.com/2dust/v2rayN/blob/main/ConfigHandler.cs) (lines 698-706). When creating servers via `AddHysteria2Server`, `AddTuicServer`, or `AddAnytlsServer`, the method explicitly sets `CoreType = ECoreType.sing_box`, preventing users from accidentally selecting an incompatible engine.

**Key distinction:** Xray handles classic proxy configurations, while sing-box is required for TUIC and AnyTLS connections. Hysteria2 appears in both support lists, but the UI defaults to sing-box for new Hysteria2 profiles.

## TUN Mode and Runtime Privileges

The cores diverge significantly in TUN (transparent proxy) handling. According to [`ServiceLib/Manager/CoreManager.cs`](https://github.com/2dust/v2rayN/blob/main/ServiceLib/Manager/CoreManager.cs) (line 108), when **Tun** mode is enabled, v2rayN automatically prefers sing-box because it provides a native TUN implementation. Xray only runs when TUN is disabled.

This architectural choice impacts process privileges on Linux. At lines 232-242, `CoreManager` wraps the sing-box process with `CoreAdminManager.RunProcessAsLinuxSudo` when TUN is active, because owning the TUN device requires elevated permissions. Xray runs under standard user privileges unless system-wide proxy settings demand otherwise.

## Configuration Generation Architecture

The difference between v2fly, Xray, and sing-box cores in v2rayN extends deep into JSON serialization. The `CoreConfigHandler.GenerateClientConfig` method (lines 113-152) branches based on `coreType`:

- **Xray path:** Invokes `V2rayFmt` services (`V2rayDnsService`, `V2rayRoutingService`) to generate standard V2Ray JSON schemas
- **sing-box path:** Invokes `SingboxFmt` services ([`SingboxDnsService.cs`](https://github.com/2dust/v2rayN/blob/main/SingboxDnsService.cs), [`SingboxRoutingService.cs`](https://github.com/2dust/v2rayN/blob/main/SingboxRoutingService.cs) at line 169) to produce sing-box compatible configurations with different field mappings for `mux`, `dns`, and routing objects

This means a VMess profile generates structurally different [`config.json`](https://github.com/2dust/v2rayN/blob/main/config.json) files depending on whether you select Xray or sing-box as the engine.

## How Core Selection Works at Runtime

The core selection logic follows a strict hierarchy defined in [`ServiceLib/Manager/AppManager.cs`](https://github.com/2dust/v2rayN/blob/main/ServiceLib/Manager/AppManager.cs) (lines 42-49) and executed by [`CoreManager.cs`](https://github.com/2dust/v2rayN/blob/main/CoreManager.cs):

1. **Profile Inspection:** `AppManager.Instance.GetCoreType(node, node.ConfigType)` checks the `ProfileItem.CoreType` property. If null, it defaults based on protocol (Xray for VMess/VLESS, sing-box for TUIC/AnyTLS).

2. **Binary Resolution:** `CoreInfoManager.GetCoreInfo(coreType)` (lines 56-108) retrieves the executable name (`Xray.exe` vs `sing-box.exe`) and download URL from the core registry.

3. **Configuration Building:** `CoreConfigHandler.GenerateClientConfig` selects the appropriate formatter service based on the `CoreType` enum value.

4. **Process Launch:** `CoreManager.RunProcess` executes the binary with the generated configuration. For sing-box with TUN enabled on Linux, it prepends a sudo wrapper via `CoreAdminManager.RunProcessAsLinuxSudo`.

### Practical Code Examples

**Creating an Xray-specific server:**

```csharp
var xrayProfile = new ProfileItem {
    ConfigType = EConfigType.VLESS,
    CoreType = ECoreType.Xray,
    Remarks = "Xray VLESS Server",
    Address = "example.com",
    Port = 443
};
await ConfigHandler.AddVlessServer(config, xrayProfile);

```

**Creating a sing-box exclusive TUIC server:**

```csharp
var tuicProfile = new ProfileItem {
    ConfigType = EConfigType.TUIC,
    CoreType = ECoreType.sing_box,  // Required for TUIC
    Remarks = "sing-box TUIC",
    Address = "tuic.example.com",
    Port = 443,
    Username = "user",
    Password = "secure_pass"
};
await ConfigHandler.AddTuicServer(config, tuicProfile);

```

**Runtime core detection:**

```csharp
var node = await AppManager.Instance.GetProfileItem(profileId);
ECoreType activeCore = AppManager.Instance.GetCoreType(node, node.ConfigType);
// Returns ECoreType.Xray or ECoreType.sing_box based on profile and protocol

```

## Summary

- **v2fly** is deprecated and hidden from the UI in [`MainWindow.xaml.cs`](https://github.com/2dust/v2rayN/blob/main/MainWindow.xaml.cs), retained only for legacy config compatibility.
- **Xray** handles VMess, VLESS, Shadowsocks, Trojan, and other standard protocols, generating traditional V2Ray JSON configs via `V2rayFmt` services.
- **sing-box** supports TUIC and AnyTLS exclusively, provides native TUN mode requiring sudo on Linux, and generates configurations via `SingboxFmt` services with different schema mappings.
- The UI enforces sing-box selection for TUIC/AnyTLS in [`ConfigHandler.cs`](https://github.com/2dust/v2rayN/blob/main/ConfigHandler.cs), while [`CoreManager.cs`](https://github.com/2dust/v2rayN/blob/main/CoreManager.cs) automatically selects sing-box when TUN mode is enabled.
- Both cores are downloaded from their respective upstream repositories (`XTLS/Xray-core` and `SagerNet/sing-box`) as defined in [`Global.cs`](https://github.com/2dust/v2rayN/blob/main/Global.cs).

## Frequently Asked Questions

### What happened to the v2fly core in v2rayN?

The v2fly core still exists as `ECoreType.v2fly` in [`ServiceLib/Enums/ECoreType.cs`](https://github.com/2dust/v2rayN/blob/main/ServiceLib/Enums/ECoreType.cs), but the UI explicitly filters it out in [`MainWindow.xaml.cs`](https://github.com/2dust/v2rayN/blob/main/MainWindow.xaml.cs) at line 442. It remains in the codebase solely to prevent crashes when loading legacy configuration files that reference the original core, but users cannot select it for new servers.

### Why does sing-box require administrator privileges on Linux?

sing-box requires elevated privileges only when TUN mode is enabled, as implemented in [`ServiceLib/Manager/CoreManager.cs`](https://github.com/2dust/v2rayN/blob/main/ServiceLib/Manager/CoreManager.cs) (lines 232-242). The TUN device (`/dev/net/tun`) requires root access to create and configure network interfaces. Xray does not require sudo unless performing system-wide proxy modifications, as it lacks native TUN support and relies on system proxy settings instead.

### Can I use Xray for TUIC or AnyTLS protocols?

No. According to [`ServiceLib/Handler/ConfigHandler.cs`](https://github.com/2dust/v2rayN/blob/main/ServiceLib/Handler/ConfigHandler.cs) (lines 698-706), the `AddTuicServer` and `AddAnytlsServer` methods explicitly set `CoreType = ECoreType.sing_box`. These protocols appear in `Global.SingboxSupportConfigType` but are absent from `Global.XraySupportConfigType`. Attempting to generate a TUIC configuration for Xray would result in an invalid JSON schema because `V2rayFmt` services do not implement TUIC field mappings.

### How does v2rayN decide which core to launch automatically?

The decision logic in [`ServiceLib/Manager/AppManager.cs`](https://github.com/2dust/v2rayN/blob/main/ServiceLib/Manager/AppManager.cs) (lines 42-49) checks the `ProfileItem.CoreType` property first. If the profile specifies a core explicitly, that engine is used. If null, the system defaults to sing-box for TUIC and AnyTLS protocols, and Xray for all other supported types. Additionally, [`CoreManager.cs`](https://github.com/2dust/v2rayN/blob/main/CoreManager.cs) (line 108) overrides the selection to sing-box whenever TUN mode is enabled, regardless of the profile's default setting.