Project V: the foundations of modular proxy tools
The Project V ecosystem builds on tools such as V2Ray, organizing inbound and outbound connections, routing, transport, and DNS into modular components. For users of graphical clients, this means one interface can manage different server types instead of requiring a separate app for each protocol. The client turns menu actions into a core configuration, and the core handles the actual connection. Understanding this division helps distinguish two checks: whether the interface saved your settings and whether the core supports them.
Projects in the ecosystem evolve independently, so menu names, default settings, and supported transports can change. Treat tutorial steps as a guide to finding features, and check the current client interface and server documentation for the final word. When you encounter an unfamiliar field, first identify whether it relates to protocol identity, transport, or security. Don't swap fields just because their names sound similar.
V2Fly and Xray: shared roots, independent development
The V2Fly community maintains V2Ray-related cores, while Xray has developed its own feature set from shared technical foundations. The two have overlapping protocol and configuration support, but that doesn't mean every field, extension, or default behavior is the same. For example, a REALITY configuration requires a core that explicitly supports it, along with compatible flow, fingerprint, public key, and other settings. Even if a feature appears in the graphical interface, check which core is actually running.
When migrating a configuration, keep the working entry and check what the destination core supports. Recognizing the same share-link format only means the importer understood some of the information; it doesn't guarantee a successful connection. If the server provider documents a specific core, follow that guidance. If you don't need an extension, there's no need to switch cores just because the name has changed.
Three clients: interface management and core execution
v2rayN is for desktop systems and brings server management, subscription updates, routing, and local proxy settings together. v2rayNG is for Android and uses the Xray core; v2flyNG is also for Android, with a different core and use case. All three are open-source clients. Open source means their code is available under each project's license; license terms, dependencies, and distribution requirements still need to be considered separately. Don't assume one project's license applies to the entire ecosystem.
When choosing a client, platform compatibility and protocol support matter more than appearance. On desktop, v2rayN lets you manage multiple server types in one interface. On Android, choose v2rayNG or v2flyNG based on the core required by your configuration. Installing multiple clients won't combine their subscriptions automatically, and you must check system proxy or VPN status separately.
VMess, VLESS, and REALITY: understand the settings layers
VMess and VLESS are proxy protocols; Trojan and Shadowsocks have their own authentication and transport conventions. REALITY is a transport security method and is commonly paired with VLESS, so these names aren't interchangeable options in a single menu. To identify a configuration, check its protocol, transport, and security settings together instead of relying on the share link's title.
Choosing the fastest option isn't as simple as comparing protocol names. Server load, network path, handshakes, connection multiplexing, and device resources all affect real-world performance. On mobile, background operation and network switching can also affect battery life and connection stability. Start with a combination explicitly provided by the server and fully supported by the client, then compare performance under the same conditions.
Subscription compatibility: import is only the first step
A subscription may contain a collection of individual share links or use a client-specific configuration format. Clients can interpret extended parameters differently, and conversion may omit flow, security, or transport settings. If only some entries stop working after an update, compare the original parameters with the logs to determine whether the import was incomplete, the core lacks support, or the server details have changed.
A subscription doesn't give a client support for additional protocols. Before copying the same URL into another client, check whether the server documentation provides a compatible format. If you share a screenshot for troubleshooting, hide the subscription URL, user ID, and authentication details. The protocol name, menu path, and sanitized error message are usually enough.
Update in order: back up, then verify what already works
Graphical clients and cores may update separately. A client update can change menus or how configurations are generated; a core update can affect feature support or field handling. Before updating, save subscription groups and manual configurations, and note your current proxy and routing settings. After updating, test a server that already worked before checking new features. Don't change the client, core, routing rules, and DNS all in the same test.
When something goes wrong, use the specific error to guide your checks. If startup fails, check the runtime environment. If the core rejects the configuration, check field compatibility. If the connection fails, check server parameters. If websites won't load, check traffic capture and routing. This separates “the app won't open,” “the server won't connect,” and “the app isn't using the proxy” into distinct problems instead of prompting repeated reinstalls.
Read the technical reference on protocols and cores →