Project V: Ecosystem & Core Roles
Client names, core names, and connection protocols describe different layers. Understanding how they relate makes configurations easier to maintain than copying an entire setup.
Project V is a useful starting point for understanding the V2Ray ecosystem. The original V2Ray combined protocol handling, transport, routing, and other capabilities in a configurable networking tool. The community later developed multiple projects with different maintenance goals. V2Fly continues community development of V2Ray, while Xray has built its own features and implementation on related technology. They share a history, but they are not interchangeable names for the same program, and not every configuration is guaranteed to be compatible.
A graphical client sits above the core. Users save subscriptions, select servers, and edit rules in the interface; the client then generates or organizes the runtime configuration for the relevant core. That's why clicking “Update subscription” does not create a corresponding field in the core's JSON, and “Set system proxy” is not a remote server protocol option. When consulting documentation, first determine whether it covers an interface setting, a core field, or a server-side parameter. This can save a lot of trial and error.
The client and the core are separate layers
v2rayN is designed for desktop use, bringing server profiles, subscription groups, system proxy, and routing settings together, with options for multiple cores. v2rayNG is for Android and primarily uses the Xray core; v2flyNG offers an Android client based on V2Fly. All three are open-source clients, but similar project names do not mean their menus, configuration storage, or feature sets are identical.
When choosing a client, start with your device platform, then check the server requirements. If your connection profile relies on Xray-specific features, verify that the client's core supports them. If you have a V2Fly configuration, check field compatibility before migrating. Simply copying one client's configuration file into another client's directory does not guarantee that all settings will work.
Learn how clients and cores relate →
Protocols, Transports & Security
VLESS, VMess, and Trojan describe connection protocols; WebSocket and gRPC describe transport methods; TLS and REALITY are part of the connection's security configuration. They are not interchangeable options in a single list. Check the protocol, server address, port, authentication parameters, transport, and security layer in each connection profile. A mismatch in any one of them can cause the handshake to fail.
VLESS does not encrypt data by itself; deployments need an appropriate security layer. Import links often fill in some parameters automatically, but check that the server name, transport path, and related options are complete. If a connection fails, compare each setting with the server requirements first. Changing several options at once makes it hard to tell which change affected the result.
Understand protocol and configuration boundaries →
Open-source licenses & usage
Open source means a project's source code is available under the terms of its license. Use, modification, and distribution must follow the applicable terms. Clients, cores, and their dependencies may use different licenses, so the ecosystem does not share a single license. For everyday use, project documentation explains where features come from. If you repackage or redistribute software, check requirements for retaining license texts and copyright notices.
Clients and remote services should also be considered separately. Installing software does not provide a server, account, or subscription; the service behind a subscription URL determines its contents. Whether a client is open source and how a remote service records data are separate questions. For business use, assess the server's source, access permissions, and intended use—not just the client name.
About this site and its content →
Updates & Configuration Maintenance
Client updates, core updates, subscription updates, and rule data updates solve different problems. Client updates affect the interface and configuration generation; core updates affect protocol implementations; subscription updates sync connection profiles; rule data updates may change domain or address classifications. When a connection fails, identify which layer changed most recently. Repeating all four update operations is not a substitute for troubleshooting.
Keep a recoverable record when maintaining configurations. Back up custom rules and essential parameters before making changes; afterward, check startup logs, the local listener, and actual app traffic. Automatic updates can reduce repetitive work, but you still need to verify the results. For long-lived custom JSON, check that fields remain supported after core changes, and remove outbound tags that are no longer referenced.
View JSON configuration references →
From successful import to a working connection
For your first setup, follow the same verification sequence: import a subscription and confirm that servers appear in the list; select one, connect, and check the error log; configure an app to use the local proxy and verify real traffic; then add split routing and TUN. A successful import only means the profile could be parsed—it does not prove the server is reachable. Likewise, a successful core startup does not mean your browser is using the proxy. Verify each result separately.
When reading logs, focus on where the error occurs. For a DNS resolution failure, check DNS; for a connection timeout, check the destination address and port; for a handshake failure, compare the protocol and security layer; for a local port conflict, deal with duplicate processes. Logs may contain addresses and authentication details, so redact them before sharing. Troubleshooting one layer at a time is more reproducible than repeatedly changing servers, reinstalling the client, or modifying every setting.
Commonly Confused Configuration Concepts
Subscriptions vs. share links: A subscription URL usually retrieves a set of connection profiles; a share link usually describes a single connection. Use the matching import option, rather than judging by whether a link contains a long string. A URL may contain access credentials, so protect it like account information. See the subscription glossary entry for details.
System proxy vs. split routing: The system proxy determines where compatible apps send traffic; routing rules determine which outbound the core uses after receiving it. Even with a direct-connection rule, an app may still send its request to the local listener first. And enabling the system proxy does not mean every app will follow it. See routing and outbound tags for details.
Traffic sniffing vs. DNS: Sniffing can identify domain information from some connections to help match routing rules, but it cannot identify a domain in every case or replace a complete DNS setup. If a domain rule does not match, check inbound settings, resolution behavior, and rule order instead of repeatedly toggling sniffing. See the inbound configuration guide for related fields.
TUN vs. connection quality: TUN changes how application traffic enters the client; it will not fix server timeouts or incorrect protocol settings. If a regular proxy cannot connect, fix the underlying connection before enabling a virtual interface. In complex network setups, also check whether other VPN software or virtual interfaces are affecting routes. See the TUN mode glossary entry for details.