Find terms by configuration scenario. Start by distinguishing protocols, cores, and clients, then see how subscriptions, proxy modes, and routing rules fit together.
Protocols define how two sides communicate; transports and security layers determine how a connection is carried and protected. Check each separately.
VMess is a proxy protocol in the Project V ecosystem. Its connection configuration includes user identity and server details. It is not the same as TCP or WebSocket: one protocol can use different transports. If an imported configuration will not connect, check the identity parameters, transport settings, and device time—not just the address and port.
VLESS is a lightweight proxy protocol that does not encrypt data on its own. It is typically used with security mechanisms such as TLS or REALITY. The user ID, flow control option, and security parameters must match the server. Simply changing the protocol name in an existing configuration to VLESS does not convert it.
Trojan typically relies on TLS to protect the connection and uses a password for authentication. The server address, password, server name, and certificate verification settings can all affect connectivity. If you see a certificate error, check the server name and device time first; disabling certificate verification is not a recommended routine fix.
REALITY is a transport security mechanism in the Xray ecosystem, not a standalone proxy protocol alongside VMess and VLESS. It is commonly configured with VLESS. Parameters such as the public key, short ID, and server name must match exactly. A client displaying these fields does not guarantee that its active core supports the combination.
The client provides the interface; the core handles communication. Check the active runtime component for supported features, not just the software name.
The core parses configuration, establishes connections, and applies DNS and routing logic. A graphical client handles importing, editing, and starting those configurations. A successful launch of the interface does not mean the core is running properly. When troubleshooting, distinguish interface errors from core logs, then check whether the core supports the protocol and transport parameters in use.
Xray is a core project with shared technical roots with V2Ray, with its own protocol and transport capabilities. v2rayNG uses the Xray core, and v2rayN can also call it to handle compatible connections. Features depend on the core version and client integration; support in one release does not imply support in every release.
V2Fly is a community project continuing V2Ray development and maintaining its core and related ecosystem. v2flyNG follows this core lineage. V2Fly and Xray share technical roots, but their feature sets are not identical. Choose based on the protocols and transports your configuration requires; do not assume their files are interchangeable.
sing-box is an independent proxy platform and core project that some v2rayN features can run. Its configuration format, rule syntax, and feature implementation differ from Xray's, so their configuration files cannot be used interchangeably. When switching cores in a graphical client, check that it can fully convert the current connection and routing settings.
First determine how traffic enters the client, then how it is handled. System proxy, PAC, and TUN operate at different levels.
System proxy registers a proxy endpoint with the operating system, allowing apps that follow system settings to send requests through the client. Some apps use their own network settings, so enabling the system proxy does not capture all traffic. If a browser still points to a stopped local proxy port after you exit the client, clear the leftover system proxy setting.
TUN mode captures traffic through a virtual network interface and passes it to the proxy component. It can cover apps that ignore system proxy settings, but usually requires extra permissions and appropriate routing and DNS configuration. It is not simply a broader system proxy switch. Watch for routing conflicts when using other virtual networking tools at the same time.
PAC uses a script to choose direct access or a proxy for apps that support automatic proxy configuration, usually based on the request URL or hostname. Only connections sent to the proxy continue through the core's routing rules. PAC deciding to connect directly and the core routing a connection directly are separate steps, so check each one when troubleshooting.
Switching cores changes the runtime component the client calls; it does not change the server or subscription source. Before switching, check that the target core supports the protocol, security mechanism, DNS settings, and rule format. If the configuration stops working, restore a known-good combination and review the logs first. Avoid changing several parameters at once, which makes the cause harder to identify.
A subscription is a way to update configurations; a node is an individual connection configuration. Managing configuration sources and choosing the active connection are separate tasks.
A subscription fetches a set of configurations from a URL and can later sync additions, removals, and parameter changes from that source. The URL may contain credentials, so protect it like a password and redact it from screenshots and shared logs. A failed update indicates a problem fetching or parsing the data; it does not prove that every imported connection is invalid.
Node is a common client term for an individual connection configuration, typically including the server address, port, authentication details, protocol, and transport parameters. The display name is just a label and may not accurately describe the server location or route quality. Check with a connection test and logs rather than relying on the name.
A share link usually has a protocol prefix such as vmess:// or vless:// and encodes a single connection configuration. It is convenient to import from the clipboard, but unlike a subscription, it typically does not keep syncing changes from its source. Copy the entire link: truncation by a messaging app, extra spaces, or incorrect escaping can all cause import errors.
Subscription groups organize URLs and imported configurations by source, making them easier to update, rename, and find. A group is not load balancing and does not guarantee an automatic switch when the current connection fails. Before editing an item imported from a subscription, check whether the next update will overwrite your changes. Save adjustments separately if you need to keep them.
Rules determine where connections go. Domain data, IP data, and the default outbound work together; they are not interchangeable.
Routing rules select direct, proxy, or other outbound routes based on conditions such as domain, IP, and port. Rules are commonly evaluated in order, so a broad rule near the top can prevent a more specific rule below it from taking effect. Unmatched traffic uses the default outbound. To troubleshoot a website's route, check both the rule order and the fallback policy.
In routing, GeoIP usually refers to categorized IP address ranges used by rules to determine the destination's classification. An IP address alone cannot reliably reveal a website's operator or every access route. A site's IP may change when it uses a content delivery network, and routing results also depend on the resolved address and dataset updates.
GeoSite is categorized domain-matching data that can route a group of related domains through the same outbound. Coverage depends on the specific dataset; it is not a real-time check of website status. A page may rely on multiple domains, so a match for its main domain does not mean images, sign-in, and media will use the same route.
Split tunneling sends different connections along different routes according to rules—for example, direct access for local network addresses and proxy access for specified domains. It is not the same as choosing a node after a speed test, and it does not automatically make every connection faster. Start with a clear default policy, add exceptions gradually, and use access results and logs to verify that rules match as expected.
Test results describe a specific route under specific conditions. Check connectivity, name resolution, and throughput separately instead of using one metric to judge everything.
Latency is the time a test request takes to receive a response, but different tools measure different parts of the connection. ICMP tests, TCP handshakes, and loading a webpage through a proxy are not directly comparable. Low latency does not guarantee high download speeds; sustained transfers also depend on bandwidth, congestion, server load, and the destination site's performance.
Real connection latency usually measures the time a client takes to send an actual request to a test target through the selected proxy configuration. The exact timing depends on the implementation. It is closer to real-world use than simply checking whether a port is reachable, but still reflects only that test target. A timeout may be caused by DNS, authentication, the handshake, or an unreachable destination; check the logs to narrow it down.
FakeDNS returns a synthetic IP for a domain and maintains a domain-to-address mapping so the proxy component can recover the domain during a later connection. The synthetic address is not the website's real server address; a compatible component must handle it. If DNS queries and connection traffic take different routes, the mapping may not be available, resulting in successful resolution but failed access.
A DNS leak typically means domain queries are not taking the expected route—for example, traffic goes through a proxy while DNS queries still go to the original resolver. Check system DNS, client DNS, and the browser's built-in encrypted DNS separately, as each may be active. Focus on where queries actually go instead of treating all local DNS resolution as a problem.