If you come across an unfamiliar field in v2rayNG, look it up by category, then return to the original menu to check the setting. This guide also covers equivalent concepts in desktop v2rayN. Menu names may vary slightly between versions.
Open the node editor and check the protocol, authentication fields, transport and security settings in order. All four sets of parameters must match the server; changing only the protocol name is not enough.
VMess is a proxy protocol with authentication and encryption. Common fields include the user ID, encryption method and alterId. When importing an older configuration, check that the alterId meets the server requirements; never reuse a value from another node without verification. A significantly incorrect device clock can also affect authentication, so enable automatic date and time if a connection fails.
VLESS is a lightweight proxy protocol that does not provide VMess-style data encryption. It is typically used with TLS or REALITY. Seeing encryption: none in the node editor does not mean the entire connection is unencrypted; check the security layer too. Support for a particular combination depends on the core and its version, not just the client name.
Trojan typically runs over TLS and uses a password for authentication. When editing a node, make sure the password, server address, port and TLS settings all match the server. Do not enter the password in the user ID field. For a handshake error, check the system clock, server name and certificate first; disabling certificate verification is not a substitute for troubleshooting.
Shadowsocks is configured primarily with a server address, port, password and encryption method. Both ends must support the same method. Some newer methods also require a particular key format, so not every string is a valid password. If an imported node has all its fields but still will not connect, first confirm that the current core supports the method instead of repeatedly changing the local proxy mode.
TLS encrypts connections and authenticates the server; SNI specifies the target server name during the handshake. In the client, this field may appear as “Server Name” or serverName and should typically match the certificate and server configuration. The connection address can be an IP, but that does not mean you should change SNI to the same IP.
REALITY is a secure transport mechanism in the Xray ecosystem, not a proxy protocol alongside VLESS. A common setup pairs VLESS with REALITY. When importing a node, check the server-provided public key, server name, short ID and fingerprint settings. A regular TLS configuration cannot be converted to REALITY by changing just the security type, and you should not guess the required parameters.
The transport setting in the node editor determines how the proxy protocol is carried over the connection. Common options include TCP, WebSocket and gRPC. Fields such as the WebSocket path and Host, or the gRPC service name, must match the server. Two nodes using the same protocol but different transports cannot simply share these settings. This menu category does not map exactly to the “transport layer” in networking textbooks.
Check the About screen or logs to see which core the client is actually using. If a field is reported as unsupported, first identify the core applying the configuration, then decide whether to adjust the configuration or update the client.
Project V is a modular networking tools ecosystem, and V2Ray is the name of one of its core projects. In everyday use, V2Ray is also often used as shorthand for this type of configuration ecosystem. It is neither a single protocol nor the full name of a particular Android app. When following a guide, check whether it refers to the client, the core or a specific protocol such as VMess; instructions for different layers are not interchangeable.
Xray is a family of cores that handle protocols, routing and connections. v2rayNG uses Xray to apply configurations. Being able to import a link does not mean the core supports every extension field it contains. To check compatibility, note the client version, core version and error in the logs, especially when using REALITY or newer transport settings.
V2Fly is a community project that continues V2Ray development. Its core is commonly called v2fly, and v2flyNG is an Android client built on this core family. Although it shares roots with Xray, that does not mean every protocol extension and configuration field is identical. Before switching core families, check what your nodes require and keep a copy of the original configuration so you can restore it.
A GUI client provides interfaces for subscriptions, node editing, mode switching and logs, then passes the configuration to a core. On Android, use v2rayNG or v2flyNG; on Windows, macOS or Linux, use v2rayN. A client is not a node service: you still need to import a working connection configuration after installation. Menu locations for the same setting may also differ between clients.
Save the URL in subscription group settings, run an update and check the node list. Fetching a subscription, connecting to a node and accessing a service in an app are three separate stages to verify.
A subscription URL lets a client fetch a set of node configurations; it is not a regular webpage URL. In v2rayNG, enter and save it in subscription group settings, then return to the menu and run an update. Treat the URL as sensitive because it may contain personal access credentials. Hide identity parameters in the full URL before sharing screenshots, logs or support requests.
A node is a set of remote connection settings saved in the client, usually including an address, port, authentication details, protocol and transport parameters. Its display name is only a label; it does not guarantee a physical location, connection quality or availability. Nodes can come from a subscription or be imported individually from a share link. When troubleshooting, check the actual fields and logs rather than relying on the name.
Subscription groups organize configurations from different sources; an update fetches the latest node data from the source. Nodes may be added, removed or renamed, and manual changes to subscribed nodes may be overwritten. To keep custom settings, export them or save them as a separate configuration first. If the list is empty, check the update log, URL and response format.
Latency is the time measured by a specific test. A TCP connection test and a test that loads a webpage through a proxy measure different things. Real connection latency typically accesses a test address through the proxy, but whether it includes DNS resolution, the handshake and other stages depends on the client. Compare results using the same test method and target address. A lower number does not mean faster downloads, and a timeout does not necessarily mean every destination is unreachable.
In routing settings, distinguish between “what to match” and “which outbound to use when a match is found.” DNS resolves addresses; routing selects the path. They affect each other but are not the same setting.
Routing rules match connections by domain, IP, port or other conditions, then select an outbound such as proxy, direct or block. Traffic splitting uses these rules to send different traffic along different paths. In common Xray routing configurations, rules are checked in order, so the first match affects what happens next. Before adding a rule, confirm its outbound tag exists and place specific conditions appropriately to avoid an earlier, broader match.
GeoIP is a categorized collection of IP addresses that routing rules can reference in forms such as geoip:private. It reflects the address ranges in the loaded data file, not real-time geolocation, and does not prove a server's physical location. Whether a domain connection matches an IP rule also depends on the resolution result and domainStrategy.
GeoSite is a categorized collection of domains used to match groups of related domains in routing rules. A category name must exist in the currently loaded data file; a category copied from another configuration may not be available. If a service is not routed as expected, check the actual domain being accessed and the list's coverage rather than assuming a match based on the service's display name.
In routing, domainStrategy controls how domains are handled during matching: AsIs matches the original domain; IPIfNonMatch attempts resolution if no rule matches; IPOnDemand resolves when an IP rule requires it. A field with the same name elsewhere in a configuration may have different meanings and accepted values. This is not a simple “faster” switch and does not directly determine the DNS server used by every app.
Local DNS refers to the client's ability to handle domain queries on the device; “local” does not mean every answer comes from an offline cache. After enabling the relevant setting in v2rayNG, the actual query path also depends on VPN traffic capture, DNS routing and upstream resolver settings. Apps with built-in encrypted DNS may use a separate path, so check the logs rather than relying only on whether the toggle is on.
FakeDNS returns synthetic IP addresses to apps, then maps them back to the original domains when subsequent connections reach the core, preserving domain-based handling. It requires DNS requests, traffic capture and compatible core settings; entering a public resolver address alone will not enable it. If an app still has an old address cached after switching modes, you may need to reconnect or clear the relevant cache.
A DNS leak generally means domain queries are not following the expected path—for example, queries expected to go through a proxy are handled by another resolver path. Check the client's DNS settings, the outbound used for queries, and any encrypted DNS built into the browser or app. Resolver names shown by test sites are clues, not proof of the actual connection path or resolver location; verify against the configuration and logs.
First check whether app traffic is reaching the client, then check the node and routing. Traffic capture and proxy routing are separate layers: traffic captured by VPN or TUN can still be routed directly by a rule.
A system proxy is a set of proxy address and port settings provided by the operating system to apps. Desktop v2rayN can use it to direct apps that honor these settings to a local proxy. Some apps use their own network stack or proxy settings and will not follow the system proxy automatically. If a browser works but another app does not, check which traffic is captured before assuming the node is faulty.
Android clients typically use the system VPN service to capture selected traffic; the first time you start one, you must approve the system permission request. Desktop v2rayN's TUN mode captures traffic through a virtual network interface. Neither connects you to a separate commercial VPN service; the node and routing rules still determine where traffic goes. Desktop TUN may require additional permissions and can conflict with other traffic-capture tools.
Per-app proxy controls whether each app's traffic is handled by the client and is typically used with Android VPN mode. First check whether the setting means “only selected apps are included” or “selected apps bypass the proxy”; the same selection has the opposite effect in each mode. Apps included in the client are still subject to routing rules, so selecting an app does not guarantee every connection uses a proxy node.
An inbound receives traffic passed to the core by apps, such as a local SOCKS or HTTP listener. An outbound determines whether traffic is sent through a remote proxy, directly or by another method. Routing uses fields such as outboundTag to reference an outbound tag; this tag is a configuration identifier, not a protocol name. If you change the local listening port, update any apps where you entered the proxy manually. When the listener is for local use only, keep its listening scope restricted.
Once you understand a field, return to the relevant setup steps and verify it. Keep the original configuration, change one setting at a time and note the actual errors in the logs.
Starting from an empty list? Follow these steps in order: save the subscription, update it, select a node and test the connection. You do not need to change advanced routing settings first.
View the user guideCheck your device platform and core requirements before choosing a client. If the subscription is empty, startup fails or an app bypasses the proxy, look up the issue by symptom.