REFERENCE / CONFIGURATION CONCEPTS
Use the name to identify the configuration layer. Protocols define connection negotiation; the core handles connections and routing; the client manages imports, selection, and system integration. Options in the same interface may belong to different layers.
PROTOCOL / TRANSPORT SECURITY
Distinguish proxy protocols from transport security, then check the complete set of settings provided by the server.
VMess is a proxy protocol in the Project V ecosystem. It uses a user ID for authentication and handles the corresponding data encapsulation. It is not a transport type: configurations labeled VMess can use different transport settings. If authentication fails, check the user ID, system time, and server requirements—not just the server address.
VLESS is a lightweight proxy protocol with no independent data-encryption layer. Connection security is typically provided by TLS, REALITY, or similar mechanisms. When you see VLESS, also check the transport type, server name, and security settings. Some combinations require specific core features; importing a share link does not guarantee the current core can connect.
Trojan typically protects connections with TLS and uses a password for proxy authentication. The server name, certificate validation, and transport settings must match the server; a correct password alone is not enough. If you see a certificate error, check the system time, server name, and server certificate. Disabling certificate verification is not a good long-term fix.
REALITY is a transport security mechanism in the Xray ecosystem, not a standalone proxy protocol alongside VMess and VLESS. A connection must match server-provided parameters such as the public key, server name, and short ID; the exact fields depend on the configuration format. Simply selecting REALITY while keeping unrelated settings usually will not produce a working configuration.
PROJECT / CORE
Project names describe the technology behind a client; client names describe the interface you use. They are not interchangeable.
Project V provides the background for understanding V2Ray's modular proxy architecture, which separates traffic reception, rule matching, and traffic forwarding. Graphical clients build on this system to manage servers and integrate with the operating system. When reading technical documentation, check whether it covers project architecture, core configuration, or the client interface.
Xray grew out of V2Ray and later developed its own protocol and transport features. v2rayNG uses the Xray core, but the available options also depend on how the client integrates it. Choose a core based on the features your server requires; shared history does not mean Xray and V2Fly configurations are interchangeable.
V2Fly is a community project continuing V2Ray development, and v2flyNG uses a core from this family. It shares history with Xray, but features, configuration syntax, and support may differ. For custom configurations, check which core and configuration version the documentation covers. Do not assume an example for another core will work as-is.
The core is the software component that handles protocol negotiation, proxy connections, routing, and related DNS logic. A graphical client saves settings, starts the core, and displays logs, so an open interface does not mean the core is running successfully. If startup fails, check the core log for invalid fields or port conflicts before changing client settings.
SUBSCRIPTION / SERVER PROFILE
Importing creates a configuration entry; updating and testing the connection are separate steps.
A subscription lets a client fetch and update a set of server configurations from a specified URL. It is not a universal top-level core configuration key. The response may contain encoded links or another client-compatible format; an unsupported format can cause parsing to fail. Subscription URLs may include access credentials, so treat them as sensitive information and keep them out of screenshots, public logs, and shared documents.
A server profile is a common client term for a remote proxy connection configuration, usually containing an address, port, authentication details, protocol, and transport settings. Its name helps identify it in a list but does not tell you the server's actual location or performance. Different names can point to the same server, so compare connection settings rather than labels.
A share link encodes a single server configuration as a URI, which a client parses into a selectable profile. Unlike a subscription URL, it does not keep a list updated; importing a single link usually will not pick up later changes. Copy the entire link. Missing query parameters, altered special characters, or extra text can cause parsing errors.
A subscription update requests the URL again, then parses and syncs the server configurations. A successful update does not mean a profile has passed a connection test. Syncing may overwrite manual changes to subscription entries, so back up important edits or save them as separate profiles. If an update fails, distinguish a request error from an invalid response or unsupported format; repeatedly deleting all groups is unlikely to help.
MATCH / DISPATCH
Rules define what matches, outbounds define how traffic is handled, and rule data provides reusable sets of matching criteria.
Routing rules select an outbound based on conditions such as domain, destination address, port, or inbound. They are commonly configured under routing.rules. Rules are usually checked in order; a broad condition near the top can prevent a more specific rule below it from matching. Make sure the target outbound tag exists, and consider how the domain resolution strategy affects matching.
Traffic routing directs traffic to paths such as direct, proxy, or block based on its characteristics, usually through routing rules. It does not mean all connections go through the same remote server or that the client automatically picks the fastest one. To verify routing, test destinations expected to go direct and through the proxy separately, then check the logs for the outbound actually used.
GeoIP rule data groups IP addresses by region or other categories for address matching. Results depend on the data source and update frequency; they are not precise proof of a server's physical location. Domain and address rules can also behave differently depending on the resolution strategy, so adding a GeoIP entry alone may not produce the expected routing.
GeoSite is domain-matching data organized by site or category, and its sets can contain different types of domain rules. It matches domain information, not every IP address a site ultimately connects to. Before using it, confirm that the current data file includes the category you need. If matching behaves unexpectedly, check whether the client preserves or restores the domain information needed for routing.
RESOLUTION / NETWORK STACK
DNS resolution and application traffic are related but separate paths; check each one independently.
DNS resolves domain names into addresses and other records. DNS queries can take a different path from subsequent application connections. The operating system, browser, client, and remote server may all take part in resolution, so changing DNS in one place may not affect every app. To troubleshoot, first identify which component makes the query and which resolver it uses, then check whether the request follows the expected route.
FakeDNS assigns virtual addresses to domain names and keeps a mapping so the original domain can be identified when later traffic enters the proxy processing chain. These virtual addresses are not the real addresses of destination servers; FakeDNS must work with DNS interception and the traffic entry point. After disabling it, apps may still have old mappings cached, so clear the DNS cache or restart the app before testing again.
A DNS leak occurs when a DNS query is handled outside the expected DNS path. First define the expected behavior before deciding whether a leak occurred. A connected proxy does not prove that every DNS query is controlled, and a browser's encrypted DNS may use a separate route. Check system and app settings alongside DNS logs rather than relying on a single website test.
TUN mode receives IP traffic through a virtual network interface and passes it to the client's network stack. This can help with apps that do not support the system proxy. Actual coverage depends on routing, permissions, exclusions, and DNS settings; it does not guarantee all traffic goes through the proxy outbound. Before enabling it, turn off conflicting traffic-capture tools and make sure you know how to disable the mode and restore network access.
CLIENT / CONNECTION TEST
Traffic capture, latency tests, and traffic entry points describe different stages. No single status can verify the whole setup.
A system proxy registers a proxy address and port with the operating system for apps that honor the setting. It does not automatically capture all network traffic. Some apps use their own proxy settings; others connect directly, so check them individually. If webpages stop loading after the client exits, check whether the system proxy still points to a local port that is no longer listening.
Latency is a time measurement recorded for a test against a particular target under specific conditions. It may measure network round-trip time, TCP connection setup, or an application request. These methods cover different stages and their results are not directly comparable; latency also does not predict download throughput. When comparing servers, use the same test method, target, and network, and look at repeated results rather than the single lowest value.
Real connection latency usually means the time taken by a test request sent through the selected proxy. The exact measurement depends on the client implementation and test URL. It covers more than a basic port-reachability check, but still reflects only that particular request. After a successful test, verify routing, DNS, and access behavior in the apps you actually use.
An inbound is where the core receives application traffic, commonly through a local SOCKS or HTTP listening port. Its configuration is under inbounds. It describes how the client receives requests on the local device, not the remote server's port. For local-only use, check the listening address. Before exposing it on other network interfaces, define access controls and understand the exposure risk.
An outbound defines how the core sends traffic to the next hop or destination: through a remote proxy, directly, or by blocking it. Its configuration is under outbounds. Routing rules typically refer to a specific outbound using outboundTag, so the tag must match exactly. If traffic reaches the core but is not forwarded as expected, check both the matched rule and the outbound connection settings.