← Back to blog

Xray or sing-box: choose a core by capability, not fashion

v2rayN is the interface; a core makes the connection. Select by protocol, TUN and routing needs rather than assuming one core is always faster.

Steps

  1. Check whether both cores support the exact protocol and options in your profile. Use the project-tested core when only one does.
  2. For common VLESS/VMess over system proxy, keep the default first. Compare sing-box when you need its TUN, process routing or protocol features.
  3. Test the same profile for connection, DNS, UDP and resume from sleep under each core—not just one latency number.
  4. Record why you selected a core and avoid unrelated automatic switching while troubleshooting.

Why this matters

The same share link can produce different defaults and advanced behavior across cores. Capability and repeatable stability matter more than the name.

How to verify

Required protocols work, rules match correctly, sleep recovery succeeds and logs contain no unsupported-field warnings.

Things to watch

Changing the core cannot repair an expired account, wrong server certificate or invalid parameters. Keep the original core as a control.

Official references

Supported coresv2rayN repository