Look up terms by setup task and distinguish protocols, cores, and proxy modes. Start with what each concept does, then match it to the options in your client—there’s no need to memorize every term at once.
Setting up a client? Keep this glossary open and follow the subscription import guide step by step. Menu names may vary slightly by version, so refer to the interface you see.
First, distinguish how a connection authenticates from how its data is carried. The same protocol can use different transports, so the protocol name alone does not tell you whether the full configuration is compatible.
VMess is a proxy protocol in the Project V ecosystem. It authenticates with a user ID, and modern implementations typically use AEAD. The client and server must use matching protocol parameters; a significant system clock offset can also interfere with authentication. If a connection fails, first check that the imported configuration is complete and the system clock is correct. Don’t change encryption options based on the protocol name alone.
VLESS is a lightweight proxy protocol that does not provide full transport encryption on its own. It is usually paired with TLS or REALITY. Seeing VLESS in a subscription tells you the protocol type, but you still need to check the transport, security layer, and flow control settings. Stick with the combination provided by the subscription instead of copying parameters from another server.
Trojan typically uses TLS for transport and password-based authentication. In addition to the server address, port, and password, the server name and certificate validation can affect the connection. If you see a certificate error, check the address, system clock, and server name first. Disabling certificate validation weakens authentication and should not be a routine fix.
REALITY is a transport security mechanism in the Xray ecosystem, commonly used with VLESS. It is not a different subscription link format. The client must match the server-provided public key, server name, short ID, and other parameters; some configurations also require flow control settings. If an older client does not recognize these fields, check whether the client and core support them instead of deleting the fields and trying to connect.
Transport describes how proxy protocol data travels over the network, such as directly over TCP or carried over WebSocket. It is a different layer from proxy protocols such as VMess and VLESS. With WebSocket, fields such as the path and Host may be required. Check the server settings before changing them; keeping only the address and port may not be enough.
The interface manages settings; the core handles connections. Understanding the difference helps pinpoint whether a problem lies with subscription management, configuration generation, or core runtime.
Project V is the open-source proxy ecosystem built around V2Ray, including protocol implementations, configuration mechanisms, and related tools. Graphical clients, proxy cores, and subscription services each have distinct roles—they are not the same product. Downloading a client prepares the software, but connecting still requires a working server configuration with valid parameters.
Xray is a proxy core project derived from V2Ray. It handles protocols, routing decisions, and outbound connections; REALITY is one of the related technologies in its ecosystem. Whether a client can use a feature depends on the core version it actually runs and whether its interface supports the required settings. When troubleshooting, note both the client and core versions rather than relying on the app name alone.
V2Fly is a community project that maintains the V2Ray core and related components, continuing the V2Ray protocol and configuration ecosystem. V2Fly and Xray share some underlying concepts, but their features, fields, and support timelines are not identical. When using clients such as v2flyNG, choose configurations based on the core’s actual capabilities; don’t assume every Xray configuration will work as-is.
Graphical clients provide interfaces for subscription management, server selection, log viewing, and proxy settings. Common examples include v2rayN, v2rayNG, and v2flyNG. A client usually converts interface settings into a runtime configuration, then calls the core to process traffic. A client opening normally does not mean the core started successfully; check the runtime logs if something goes wrong.
A proxy core is the runtime component that accepts inbound traffic, matches rules, and establishes outbound connections. A port conflict, unsupported configuration field, or insufficient permissions can prevent it from starting. If the client lists servers but every request fails, check the core’s status before troubleshooting the remote server. This helps avoid mistaking a local runtime error for a server issue.
A subscription fetches configurations, a server entry represents one connection configuration, and a test result reflects performance under specific conditions. Understanding these separately makes updates and troubleshooting clearer.
A subscription link is a URL used to retrieve a set of server configurations. The client reads the response and creates selectable server entries. The URL usually contains access credentials, so copy it in full and store it securely—never share it in screenshots, chat logs, or public pages. Updating a subscription fetches the configurations again; it does not select an active server or enable the system proxy.
A server usually means one connection configuration in the client’s list, including its address, port, protocol, authentication details, and transport settings. Its name is just a label and does not prove the server’s location or actual network route. After selecting a server, confirm the proxy entry point and routing mode. A listed entry is not necessarily usable right now.
A subscription group is a container for managing server configurations by source, typically storing notes, a subscription URL, and automatic update settings. Groups help distinguish multiple sources and prevent confusion when updating server entries. An update may overwrite content managed by that source, so understand how your client handles updates before making manual changes. Manage custom configurations separately if you need to keep them.
Latency is the time from starting a test to receiving a response. Results depend on the test method, target, and current network conditions. A port check, a request test, and actual browsing experience are not interchangeable—and lower latency does not guarantee faster downloads. When comparing servers, use the same method and target, and check more than once rather than drawing conclusions from a single result.
Real connection latency generally means the time measured when accessing a specified test URL through a proxy. This is closer to an application request than simply checking whether the server port is open. Results still depend on the test URL, DNS resolution, and timeout settings, and do not represent the experience on every website. If a test fails, check the logs to determine whether the proxy handshake failed, the destination was unreachable, or the test service did not respond normally.
First check whether a request enters the core, then see which rule it matches. “Which traffic gets captured” and “which outbound connection it uses” are two separate questions.
Routing rules choose an outbound connection based on criteria such as domain, destination IP, port, or inbound connection. Common actions are direct, proxy, and block. Rules are often evaluated in order, so an early broad rule can prevent a later, more specific rule from taking effect. After adding a custom rule, verify which rule matches using logs or a real request instead of checking only that the rule was saved.
Split tunneling sends different requests through different outbound connections—for example, connecting directly to some services and through a proxy to others. It typically relies on domain and IP classification and is affected by DNS resolution, rule order, and the default outbound connection. If an app does not connect as expected, first check whether its traffic enters the core, then inspect the rules. Don’t assume the classification data is at fault.
GeoIP is a set of IP addresses, often organized by region or purpose, that can be used as destination criteria in routing rules. It reflects classifications in the rule data, not a live measurement of a server’s physical location. When a site uses a content delivery network, its resolved IP may change, so GeoIP matches also depend on the resolution result and data version.
GeoSite is a set of domains categorized by region, service, or purpose, often used to choose a routing path based on the site. It differs from GeoIP in what it matches: domains rather than IP addresses. If only the destination IP is available, a domain rule may not match directly. Consider DNS, traffic sniffing, and the inbound method to understand how the match is made.
In a client, global proxy usually means a routing mode that sends traffic entering the core through the proxy by default. It does not automatically capture traffic from every app on the device; apps that ignore the system proxy may still use their own network path. To capture more traffic, look into TUN mode or the app’s own proxy settings rather than repeatedly switching global mode.
System proxy and TUN determine how traffic enters the client; DNS and sniffing affect how domain information is used for routing. Change one type of setting at a time to make it easier to undo changes.
The system proxy registers a proxy address and port with the operating system, allowing apps that honor the setting to send requests through the client. Some apps use their own proxy settings or ignore the system proxy entirely, so enabling it may not affect every connection. If a stale local proxy address remains after you close the client, apps may lose network access. Check and restore the system proxy settings if that happens.
TUN mode routes matching traffic to a proxy component through a virtual network interface, often to capture traffic from more apps. It usually requires additional permissions, and its behavior also depends on routing, DNS, and exclusion rules. If the device is also running other virtual network adapters or VPN tools, routing conflicts may occur. Test TUN on its own first, then re-enable other components one at a time.
FakeDNS returns synthetic IP addresses to apps, then restores the corresponding domains when connections enter the associated proxy chain. This helps with routing and connection handling. These addresses are not the destination server’s real public IPs and cannot be used without the corresponding handling mechanism. After changing or disabling this mode, old DNS cache entries may still affect access; follow the client’s guidance to clear the cache and reset connection state.
A DNS leak occurs when domain lookups take a resolution path outside the intended policy, such as when an app bypasses the configured resolver and sends its own queries. Whether a leak has occurred depends on the DNS policy you expect; a test page showing a particular region is not enough to draw a conclusion. Check system DNS, browser secure DNS, core resolution settings, and how TUN handles DNS separately.
Traffic sniffing attempts to extract domain names and other details from protocol data at the start of a connection to help with routing decisions. It does not decrypt HTTPS content and cannot identify domains in every encrypted connection. Whether the detected information is used only for routing or to override the connection destination depends on the configuration. Understand what the client’s options do before changing them.