Look up terms by configuration layer, from protocols to subscriptions. Understand what each term does, then find the corresponding setting in v2rayN or v2rayNG.
Protocol type, transport, and security are separate settings and cannot be used interchangeably.
VMess is a proxy protocol in the Project V ecosystem that uses a user ID for authentication and includes its own data protection. After importing a server entry, keep its transport and security settings along with the address and port. A significant system clock discrepancy can also affect authentication, so if a connection fails, check both the device time and the configuration source.
VLESS is a lightweight proxy protocol that does not encrypt traffic on its own and is usually paired with security mechanisms such as TLS or REALITY. Sharing a user ID does not mean a VMess entry can be converted to VLESS. Use the server-provided combination of address, port, flow control, and transport security; do not fill in settings based on the protocol name alone.
Trojan typically runs over TLS and uses a password for authentication. The password, server name, and certificate validation each serve a different purpose; setting one does not replace the others. If you see a certificate error, check the domain and system time rather than routinely disabling certificate validation.
REALITY is a transport security mechanism in the Xray ecosystem, not a standalone proxy protocol alongside VLESS. Entries using it typically include parameters such as a public key, server name, short ID, and fingerprint; the exact fields depend on the configuration. Save the original entry before making changes, confirm that the current core supports the feature, and do not combine parameters from unrelated entries.
Transport determines how proxy data is carried, for example over TCP, WebSocket, or gRPC. It is distinct from protocol types such as VMess and VLESS. WebSocket paths and headers, as well as gRPC service names, may need to match the server. Changing transport requires server-side support; it is not simply a speed setting.
The software name identifies the entry point; the core determines how the configuration is executed.
Project V is a networking tools ecosystem built around the V2Ray project, covering foundational capabilities such as proxy protocols, routing, and connection handling. It is neither the name of a GUI client installer nor a subscription service. When reading documentation, distinguish ecosystem-level concepts from settings actually exposed by your client.
Xray is a proxy core developed from the V2Ray project, with its own evolving protocol and configuration capabilities. v2rayNG uses the Xray core; in v2rayN, available features depend on the selected core and client support. Core updates and interface updates are separate, so check each independently when troubleshooting rather than relying on the client name alone.
V2Fly is a community project that continues to maintain V2Ray, and v2flyNG uses this core family. V2Fly and Xray share some history and concepts, but their supported features, fields, and defaults are not identical. When moving between environments, verify protocol and transport support instead of assuming a configuration will work unchanged.
The proxy core is the execution component responsible for protocol handling, routing, DNS queries, and outbound connections. The client interface can launch even if the core has not started successfully; a local port conflict or incompatible configuration can still prevent it from running. Check the core status and logs first, then determine whether the issue involves the remote connection.
v2rayN, v2rayNG, and v2flyNG provide graphical interfaces for saving servers, updating subscriptions, and adjusting connection settings. The interface typically translates options into core configuration, so labels may not exactly match the underlying fields. See the client downloads to choose an installer, or the client comparison to compare use cases.
First check how traffic reaches the client, then assess test results and connection settings.
The system proxy setting registers a local proxy address with the operating system and affects only apps that follow it. In v2rayN, “System proxy → Set system proxy” configures this entry point, but apps may use their own proxy settings or connect directly. If the system proxy is not restored before closing the client, apps may keep trying to reach a local port that is no longer listening.
TUN mode captures and handles traffic through a virtual network interface, making it useful for apps that ignore system proxy settings. In v2rayN, “Enable Tun” also involves permissions, system routing, and DNS. Enabling it does not mean every request will use the proxy outbound. First confirm the basic connection works, then check the virtual interface and split-tunneling results one by one.
Per-app proxy determines which apps' traffic is captured by the client. In v2rayNG, distinguish between “proxy only selected apps” and “bypass selected apps”: the same checked list can produce opposite results. Captured traffic still passes through routing rules, so it is not guaranteed to use the remote proxy outbound.
Mux attempts to carry multiple logical connections over fewer underlying connections, changing how connections are established and carried. It is not a universal speed boost; results depend on the protocol combination, server support, and network conditions. When adjusting “Mux” in v2rayNG, change only this setting at a time and compare stability under the same app usage.
Real connection latency measures how long it takes to reach a test target through the proxy connection, usually involving more steps than a TCP handshake. Tcping mainly reflects the TCP connection to the target port, while a download speed test measures actual throughput; these results are not interchangeable. A real connection test can also fail because of the test target or DNS, so check logs and real-world app access as well.
Traffic entry, rule matching, and domain resolution are connected steps, not a single switch.
Routing rules select an outbound based on conditions such as domain, IP, or port, sending requests to a direct, proxy, or blocked route; this is commonly called split tunneling. Rules are often evaluated in order, so a broad rule near the top can override a more specific one below. When changing routing in v2rayN, check the rule order and the default outbound for requests that match no rule, not just individual rules.
GeoIP is a tagged collection of IP addresses used to match destination addresses in routing rules. Its coverage depends on the data file loaded; it is not a real-time determination of request origin or service ownership. If the destination is a domain, whether it is resolved to an IP first also depends on the domain strategy. A GeoIP rule may therefore not match every expected request immediately.
GeoSite is a tagged collection of domains. For example, geosite:private can match the private-domain set in a supported data file. GeoSite handles domain conditions, while GeoIP handles address conditions; they are not interchangeable. If rules behave unexpectedly, first confirm the tag exists, then check whether the request still includes domain information for matching.
FakeDNS returns a synthetic IP to the app and stores a mapping between that address and the domain, allowing later connections to recover the original domain. It is not a regular public DNS address, and changing just one DNS server is not enough to configure it. DNS interception, traffic capture, and address restoration must work together. After disabling it, watch for synthetic addresses cached by the system or apps.
A DNS leak occurs when domain lookups take an unexpected route—for example, when they are meant to use a specified channel but instead go through the system's default resolver. A normal-looking browser exit IP does not mean DNS is following the expected path. Check system DNS, client DNS, encrypted DNS in the browser, and TUN capture separately; do not draw conclusions from a single web test.
Subscriptions fetch configurations; server entries describe connections. A successful update does not guarantee a successful connection.
A subscription URL retrieves a set of server configurations and can be requested again later to refresh them. It may contain access credentials, so redact the full URL and related parameters before sharing screenshots or logs. A regular web URL is not necessarily a subscription URL, and opening one in a browser does not mean a client can parse the returned configuration format.
A “server entry” usually means a set of remote connection parameters saved in a client, including the address, port, protocol, authentication, and transport settings. It does not necessarily correspond to a separate physical server, and its display name is just a label. To check whether two entries are the same, compare their actual connection parameters—not just their names, region labels, or position in the list.
A share link packages a single server configuration as text, such as a string beginning with vmess:// or vless://. Copy it and import it through the client's clipboard import option. The imported entry is usually a snapshot of the configuration at that time and does not update automatically from its source. Links may contain authentication details, so treat them as sensitive and do not post them in public forums.
Subscription groups organize subscription URLs and server entries by source, making it easier to update, filter, and troubleshoot them separately. The “Subscription Group” menu in v2rayN is a management entry point; a group name does not imply automatic speed testing or switching. Keep configurations from different sources separate, and save existing filters before changing them to avoid hiding valid entries.
A subscription update fetches and parses the subscription content again, which may add, replace, or remove server entries. A successful update only confirms that the configuration was retrieved and parsed; it does not guarantee the remote server is reachable. If an update fails, first distinguish an inaccessible URL from an unexpected response or a parsing error. Check the update method in v2rayN's “Subscription Group” menu, then use the logs to identify the failing step.