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

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 but is actively filtered out of the user interface. In 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 (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.

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 (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 (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, 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 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 (lines 42-49) and executed by 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:

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:

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:

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, 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, while 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.

Frequently Asked Questions

What happened to the v2fly core in v2rayN?

The v2fly core still exists as ECoreType.v2fly in ServiceLib/Enums/ECoreType.cs, but the UI explicitly filters it out in 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 (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 (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 (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 (line 108) overrides the selection to sing-box whenever TUN mode is enabled, regardless of the profile's default setting.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}