Xray vs sing-box: Stealth vs Performance for VPN Builders

If you are building a VPN product for markets with serious censorship, you will land on this question quickly: do you build on Xray-core or sing-box? The answers online are mostly unhelpful, either vendor blogs talking up whichever core they sell, or forum threads that declare a winner without saying for what.

We work with both. They are excellent and they are not interchangeable. This is a comparison by an engineering team, framed around the decision you are actually making: which core fits the product you are shipping. We will keep the claims grounded in what the projects document, and we will be clear about what is hype, what is conditional, and what depends on your specific market.

First, Get the Layers Straight

Most confusion in this space comes from mixing up four different things. Before comparing cores, separate them cleanly, because Xray and sing-box are only one of these layers.

• Protocols and transport features: VLESS, VMess, Trojan, Shadowsocks, REALITY, XTLS Vision, Hysteria2, TUIC. These are the rules for how traffic is carried and disguised.
• Cores (engines): Xray-core and sing-box. These implement the protocols. They are the part you embed or run on a server.
• Panels: Marzban, 3x-ui, Hiddify-Manager. These are server-side management UIs that sit on top of a core.
• Client apps: Hiddify, v2rayN, NekoBox, V2Box, Happ. These are user-facing apps that drive a core.

Xray-core and sing-box are cores. They both implement many of the same protocols. So “Xray vs sing-box” is not “VLESS vs Hysteria2” and it is not “Marzban vs Hiddify.” It is a comparison of two engines that can often speak the same protocols, with different design priorities. Keep that frame and the rest is clear.

What Each One Is

Xray-core

Xray-core (XTLS/Xray-core) is a proxy core that describes itself as “the best v2ray-core,” which is literally true in lineage: it is a fork of the original v2ray-core. It implements VLESS, VMess, Trojan, Shadowsocks, and, most importantly for censored markets, the REALITY transport and the XTLS Vision flow. It is written in Go, runs on the major desktop and server platforms plus Android, and is MPL-2.0 licensed. As of June 2026 it is actively maintained, with frequent releases and a large user base.

Xray’s defining contribution is anti-detection. REALITY and XTLS Vision are XTLS-project work, and they are the current reference for making proxy traffic resist the kind of deep packet inspection and active probing used by sophisticated censors. If your priority is staying unblocked in a hostile network, Xray is the lineage that protocol was born in.

sing-box

sing-box (SagerNet/sing-box) describes itself, accurately, as “the universal proxy platform.” It is a single Go engine that speaks a wide protocol set: VLESS, VMess, Trojan, Shadowsocks, Hysteria2, TUIC, WireGuard, and more, including REALITY and ECH, with a system-level TUN inbound for full-device routing. It runs across Linux, Windows, macOS, Android, and iOS, and is GPLv3 with an additional condition (read the license before redistributing).

sing-box’s defining contribution is unification and reach. Instead of one core per protocol family, it gives you one engine that handles almost everything, with strong cross-platform support including native mobile and a clean TUN implementation. If your priority is a single, consistent engine across every platform you ship, that is sing-box’s design center.

Head to Head

Neither core “wins” in the abstract. They optimize for different things. Here is how they compare on the dimensions that matter when you are building a product.

Protocol and transport support

Both implement the core proxy protocols (VLESS, VMess, Trojan, Shadowsocks) and both support REALITY. The practical differences:

• sing-box ships a broader built-in set in one engine, notably first-class Hysteria2 and TUIC (QUIC-based protocols useful on lossy or UDP-friendly networks) and WireGuard, plus its TUN inbound. Its supported inbounds and outbounds are version-specific, so pin a version when you build.
• Xray is the home of REALITY and XTLS Vision and tends to lead on the newest anti-detection transport work, including newer transports like XHTTP.

If your product hinges on the latest stealth transport, Xray usually has it first. If your product needs one engine that speaks the widest set of protocols including QUIC-based ones, sing-box covers more ground in a single binary.

REALITY and anti-detection

REALITY is the reason this comparison matters for censored markets. Per the official documentation, REALITY is “a modified form of TLS that uses the appearance and handshake characteristics of a target site as camouflage,” designed to “eliminate the detectable TLS fingerprint on the server side,” and it can “point to other people’s websites, no need to buy domain names, configure TLS server.” Paired with the XTLS Vision flow, which removes the detectable TLS-in-TLS pattern, it is the strongest current approach to resisting fingerprinting and active probing.

Both cores implement REALITY. Xray is where it is developed, so it is reasonable to expect Xray to track REALITY changes most closely. sing-box implements it as part of its universal set. For a product whose entire value is staying unblocked, building on the core that originates the stealth work is a defensible default, with sing-box a strong choice when you want REALITY plus everything else in one engine.

A hard caveat that belongs in every honest version of this comparison: no protocol guarantees censorship bypass. REALITY raises the cost of detection; it does not make traffic permanently invisible. Effectiveness depends on the censor’s capabilities, the donor site and SNI you choose, active-probing resistance, your server IP reputation, and timing. REALITY deployments do get graylisted and blocked over time, which is why survivability (IP rotation, fallback, careful donor selection) is part of the job, not a one-time config.

Performance and resource use

This is where vendor claims get loose, so be careful. Both are efficient Go engines. Real-world performance depends heavily on configuration, transport, hardware, and network, not just the core. Treat any blanket “X is faster” claim with suspicion unless it specifies the protocol, transport, and test conditions.

What you can say responsibly: both projects have had specific, documented memory and resource issues at particular versions and conditions, and both actively fix them. For example, sing-box has closed reported memory or goroutine leaks such as issue #4105 and #3421, and Xray-core has an open report of high iOS memory use in issue #5944 along with merged leak fixes. These are issue-specific, tied to versions and conditions, and should not be read as “core X leaks memory.” The honest takeaway is that on constrained targets, especially an iOS Network Extension with a tight memory budget, you test your real configuration on-device rather than trusting a benchmark blog.

Platform coverage, especially mobile

This is often the deciding factor for app builders.

• sing-box supports iOS and Android directly and is built with mobile in mind, with a clean TUN inbound for full-device VPN behavior. If you are embedding a core into native iOS and Android clients, sing-box’s cross-platform story is a real advantage.
• Xray-core runs on Android and the desktop/server platforms; on iOS it is typically integrated through additional work rather than a first-class mobile target.

For a product where the same engine should drive every platform with minimal divergence, sing-box’s reach is the simpler path. For a server-side or desktop-centric deployment focused on stealth, Xray’s platform set is rarely a constraint.

Configuration model

Both use JSON configuration, but the schemas differ, and they express routing and outbound selection differently. sing-box’s configuration is built around its universal model (selectors, URLTest for latency-based selection, rule sets). Xray’s configuration follows its inbound/outbound/routing model. Neither is harder in the abstract, but they are not drop-in compatible, so a team standardizes on one to avoid maintaining two mental models. If you already operate panels or clients tied to one core’s config, that inertia is a legitimate input to the decision.

Ecosystem: panels and clients

The surrounding tools matter because you rarely run a bare core.

• The panel ecosystem (Marzban, 3x-ui, x-ui) is largely Xray-centric: these panels manage Xray-core under the hood. If you want a mature server-side management UI today, the Xray side has more options.
• The client ecosystem is split: Hiddify is built on sing-box; v2rayN drives both Xray and sing-box; NekoBox is sing-box based; several others wrap Xray.

So if your operational plan leans on an existing panel, that often points toward Xray. If your plan is your own cross-platform client, sing-box’s unified engine is attractive.

Maintenance and licensing

Both are actively developed as of June 2026, with frequent releases. License matters if you redistribute: Xray-core is MPL-2.0; sing-box is GPLv3 with an additional permission/branding condition. Read the actual license files before you ship a closed-source product on either, and treat licensing as a question for your own counsel.

The Comparison, Summarized

Dimension	Xray-core	sing-box
Identity	Proxy core, fork of v2ray-core; home of REALITY	Universal proxy platform, one engine for many protocols
Anti-detection	Leads (REALITY, XTLS Vision, newer transports first)	Strong (implements REALITY + broad set)
Protocol breadth	Broad, stealth-focused	Broadest in one binary (incl. Hysteria2, TUIC, WireGuard, TUN)
Mobile (iOS + Android)	Android first-class; iOS via extra work	iOS and Android both first-class
Panels	Xray-centric (Marzban, 3x-ui, x-ui)	Fewer dedicated panels
Clients	Many Xray-based	Hiddify, NekoBox, v2rayN, others
Config	Inbound/outbound/routing JSON	Universal JSON (selectors, URLTest, rule sets)
License	MPL-2.0	GPLv3 + additional condition

(Stars, releases, and supported-protocol lists move continuously; verify against the repos at build time.)

When to Pick Which

A simple way to decide:

• Pick Xray when stealth is the product. You are serving heavily censored markets, you want the core that originates REALITY and the latest anti-detection transports, and you plan to run a mature panel (Marzban or 3x-ui) on the server side.
• Pick sing-box when unification and reach are the product. You want one engine across iOS, Android, and desktop, you value first-class Hysteria2/TUIC/WireGuard and a clean TUN, and you are building your own cross-platform client.
• Either is defensible when your needs are mainstream. If you are not fighting sophisticated DPI, both will serve you well, and the decision comes down to your platform plan, your panel choice, and which config model your team prefers.

Many serious operations end up using both in different places: Xray on stealth-critical server nodes behind a panel, sing-box inside a unified cross-platform client. That is not indecision, it is using each engine where its design pays off.

What This Means If You Are Embedding a Core

If you are building native apps and embedding one of these cores, three practical points:

1. The core is not the whole client. You still build the iOS NetworkExtension Packet Tunnel Provider or the Android VpnService layer around it, including reconnect logic, kill switch, and per-app routing. The core handles the protocol; the platform layer handles being a real VPN app.
2. Memory discipline matters on iOS. The Network Extension runs under a tight memory budget. Whichever core you embed, profile your actual configuration on-device. This is exactly the constraint behind the iOS memory issue reports linked above.
3. Plan for the arms race. If you serve censored markets, your protocol and transport choices are not permanent. Build so you can update cores, rotate IPs, and switch transports without shipping a new app every time.

FAQ

Is Xray or sing-box better?

Neither is better in general. Xray-core leads on stealth and anti-detection and is the home of the REALITY transport, with a mature server-side panel ecosystem. sing-box is a universal engine that speaks the widest protocol set in one binary, with first-class iOS and Android support and a clean TUN inbound. Choose by priority: stealth and panels point to Xray; one unified cross-platform engine points to sing-box.

Do both support REALITY?

Yes. REALITY is developed in the XTLS/Xray project, and both Xray-core and sing-box implement it. Building on Xray means tracking REALITY at its source; building on sing-box means REALITY alongside a broader protocol set in one engine. Neither makes traffic permanently invisible; REALITY raises detection cost and still requires survivability work like IP rotation.

Which is better for an iOS and Android VPN app?

sing-box has the more direct advantage here, because it supports iOS and Android as first-class targets with a single engine and a clean TUN implementation. Xray can be used on mobile too, but iOS typically needs extra integration work. Either way, you still build the platform layer (NetworkExtension on iOS, VpnService on Android) around the core.

Are the memory leak reports a reason to avoid one of them?

No. Both projects have specific, version-tied memory or resource issue reports, and both fix them actively. These are conditions at particular versions, not a general property of either core. On constrained targets like an iOS Network Extension, profile your real configuration on-device rather than relying on any general claim.

Can I use both?

Yes, and many operations do. A common pattern is Xray behind a panel on stealth-critical server nodes, with sing-box inside a unified cross-platform client. Use each where its design strengths apply.

Choosing the Core Is the Start, Not the End

The Xray versus sing-box decision comes down to what your product is fighting. If it is sophisticated censorship, Xray’s stealth lineage and panel ecosystem are the natural center of gravity. If it is platform fragmentation, sing-box’s universal engine and mobile reach win. For mainstream products, either is a sound foundation and the decision falls to your platform and operational plan.

Whichever you choose, the core is one piece of a working VPN product. You still need the native clients, the control plane, the server network, and the operational discipline to keep it all unblocked and approved on the stores.

If you are scoping a VPN product and want help choosing a core, designing the protocol and obfuscation strategy, and planning the testing that goes with it, DigitalD.tech can help. We build across both Xray-core and sing-box and ship the modern anti-censorship stack (VLESS with REALITY, Hysteria2, Shadowsocks, and AmneziaWG) in native iOS and Android clients. For the protocol fundamentals, see our comparison of VPN protocols, and when you are ready to talk specifics, get in touch with your target markets.