Steps
- Check whether both cores support the exact protocol and options in your profile. Use the project-tested core when only one does.
- For common VLESS/VMess over system proxy, keep the default first. Compare sing-box when you need its TUN, process routing or protocol features.
- Test the same profile for connection, DNS, UDP and resume from sleep under each core—not just one latency number.
- 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.