v2rayN with the sing-box Core (2026): What Changes, and the DNS Trap

Affiliate disclosure - this article contains a Contabo affiliate link. If you order a VPS through it we earn a commission at no extra cost to you. Everything below is taken from the v2rayN source code, its official wiki and the projects' release pages, checked on 2026-08-09. Version numbers and config field names change often; check them against the current docs before you rely on them.

Short answer: switch v2rayN to the sing-box core only if you need TUIC, AnyTLS or Naive - those are the three protocols the Xray core does not handle. Hysteria2 is not one of them, and Vision and REALITY work fine under sing-box. The switch is one setting, but it silently changes what the DNS fields mean, which is where most broken setups come from. If you are still choosing between the two engines rather than switching, start with our sing-box vs Xray comparison.

Which cores v2rayN can actually drive

The wiki lists eleven supported cores across four families: the V2Ray family (Xray, v2fly), the Clash family (mihomo), the sing_box family, and standalone ones such as hysteria2, naiveproxy, tuic, juicity, brook, overtls and shadowquic.

That list is easy to misread. In the code, only two cores act as the main core that v2rayN generates a configuration for: Xray and sing_box. The wiki's DNS page says the same thing in as many words. The rest are used through a custom configuration file - you supply the config, v2rayN runs the binary.

Windows packages already ship with the Xray, sing-box and mihomo binaries inside the zip. The other cores you download yourself and drop into bin.

Making the switch

Settings → Core Type Settings.

The resolution order matters more than the setting itself. On start, v2rayN first reads the core type recorded on the current server profile; only if that is empty does it fall back to the global core type. In practice that means you can leave your whole list on Xray and flip a single TUIC node to sing-box, without touching anything else.

What genuinely requires sing-box: three protocols

This one does not need to be argued, because v2rayN computes it. The code defines the protocols each core supports and then derives the sing-box-only set as the difference between the two:

So the answer is TUIC, AnyTLS and Naive. Nothing else.

Two beliefs you will meet in forum threads are worth correcting, because both are contradicted by the source:

• "Hysteria2 needs sing-box." It does not - Hysteria2 is in both lists, so the Xray core handles it. There are issues in the tracker reporting practical trouble with Hysteria2 under Xray, but a reported bug is not a missing capability.
• "sing-box can't do Vision or REALITY in v2rayN." It can. The sing-box outbound builder emits the Vision flow for VLESS and writes the REALITY block (public key, short ID) plus the uTLS fingerprint. The xtls-rprx-vision-udp443 variant is normalised to plain xtls-rprx-vision.

There is a documented chaining limitation, but it lands on the other core: with proxy chains, nodes using Xray cannot use TUIC or AnyTLS as the front or landing proxy.

The DNS trap - the part that actually breaks setups

If something worked on Xray and stopped working the moment you switched, this is almost certainly why. The two DNS fields do not have the same job under the two cores.

Under Xray these fields are a routing detail. Under sing-box they are your resolver. Copying a working Xray DNS configuration across is exactly how you end up with a node that will not even resolve its own hostname.

Bootstrap DNS must be an IP address

The rule is stated plainly in the documentation: if direct DNS or remote DNS is written as a domain, you must set a Bootstrap DNS, as an IP address. It is the resolver that resolves your resolver. Enter https://dns.google/dns-query as your remote DNS with no bootstrap and there is nothing left to look up dns.google with.

The related "add common DNS hosts" option hard-codes mappings for dns.google and cloudflare-dns.com, so a bootstrap failure does not take everything down with it.

Options that exist on only one core

Do not spend an evening looking for a checkbox that cannot be there:

• sing-box only, and only in TUN mode: FakeIP, and blocking SVCB/HTTPS queries. That second one also switches off ECH and HTTP/3 - the docs note ECH can interfere with per-domain split routing.
• Xray only: parallel DNS queries, and the optimistic cache.

For resolution strategy, UseIPv4 and UseIPv4v6 map to sing-box's prefer_ipv4, and UseIPv6/UseIPv6v4 to prefer_ipv6; ipv4_only and ipv6_only are also available. DNS hosts are written one per line as domain IP1 IP2. Unless you have a specific reason, the wiki's own advice is to import the default DNS configuration and leave it alone.

Two smaller behaviour changes

• routeOnly is forced on. Under the sing-box core it is enabled and cannot be turned off.
• Mux needs a protocol. Enabling multiplexing is not enough under sing-box; you also have to pick the multiplexing protocol - h2mux, smux or yamux.

Where the files live

Everything is relative to the application folder:

The zip builds are portable: everything stays inside the folder you extracted it to, so you can keep several independent copies side by side. If you set the environment variable V2RAYN_LOCAL_APPLICATION_DATA_V2 to 1, the base folder moves to %LOCALAPPDATA%\v2rayN instead.

Update before you troubleshoot anything

The current release at the time of writing is v2rayN 7.24.4, published on 30 July 2026, and its release notes flag it as an urgent security update: the built-in downloader in older versions could be exploited for a man-in-the-middle attack that served malicious files. The project tells every user to upgrade immediately. If you are on an older build, do that before you start debugging a proxy problem.

Windows assets ship as six zips - WPF (v2rayN-windows-64.zip) and Avalonia (v2rayN-windows-64-desktop.zip) builds, in x64, x86 and arm64 - alongside a public key file for verifying the signatures. Windows 10 or newer is required.

On the other side, sing-box's current stable release is v1.13.16, published 3 August 2026. One honest gap: neither the wiki nor the 7.24.4 release notes publish a compatibility matrix between v2rayN and sing-box versions, and the exact sing-box build bundled in the zip is not documented - you would have to inspect the binary to know it.

Should you switch?

Only for a reason. If your nodes are VLESS or VMess with REALITY, the Xray core is the most documented path and there is nothing to gain. Switch when you have a TUIC, AnyTLS or Naive node to run, or when you want FakeIP in TUN mode - and when you do, re-do your DNS settings from scratch rather than assuming your Xray ones carry over.

Running your own endpoint rather than a public node is a separate decision; if that is where you are heading, our anti-DPI and censorship-bypass guide covers what actually survives deep packet inspection.