Start by distinguishing protocols, cores, and clients, then look at the settings. Each entry explains what a term means, what to check when configuring it, and where it can be confused with something else. Copy a term's anchor link to jump straight to its explanation.
A protocol defines how two endpoints exchange data. Transport and security are separate concerns. Match all three when importing a profile; the protocol name alone is not enough.
VMess is a proxy protocol in the Project V ecosystem. Modern implementations use AEAD authentication, so some fields in older guides may no longer apply. Check the user ID, server port, transport, and security layer; don't copy settings from another protocol. A significant device clock offset can also affect authentication, so sync the system clock first when troubleshooting.
VLESS keeps authentication and forwarding lightweight but does not encrypt traffic on its own; it is often paired with TLS or REALITY. A VLESS label does not guarantee that every client supports the transport and flow-control combination used. When entering a profile manually, check the security type, server name, and flow field as well as the user ID—not just the address and port.
Trojan typically protects connections with TLS and authenticates with a password. The server address can be an IP or a domain, but the server name used for certificate validation must still match the server configuration; the two may differ. For handshake errors, check the password, port, certificate, and device clock rather than disabling certificate validation.
Shadowsocks uses a pre-shared key to establish a proxy connection. Share links commonly begin with ss://. The client and server must use the same encryption method and password; key format requirements can vary by method. Even if a client supports SS, check that it supports the specific method used by the node. Don't assume it supports any optional plugins or extensions either.
The graphical interface manages settings; the core handles connections. To determine whether a node will work, check both the client and the core it actually runs.
Project V refers to the project and tool ecosystem built around V2Ray, not a particular desktop app or subscription service. Its modular design separates components such as inbound and outbound connections, routing, and transport. In everyday usage, a “V2Ray client” usually means a graphical app that manages these capabilities; that does not mean its configuration files are interchangeable with those of every other app.
V2Fly continues the community-maintained V2Ray implementation, providing a proxy core and related features. v2flyNG is an Android client option built on this core ecosystem. Whether a configuration works depends on the version and supported fields. In particular, don't pass Xray-specific security mechanisms or flow-control settings to V2Fly unchanged.
Xray originated from V2Ray and has since developed its own feature set and configuration path. REALITY and XTLS Vision are common examples. v2rayNG uses the Xray core; on desktop, check which core the client actually uses. The two cores have similar configuration structures, but that doesn't mean every field, default, or behavior is identical.
The core handles protocols, routing, DNS resolution, and data forwarding. The client interface creates configurations, manages subscriptions, and displays logs. Being able to save a setting in the interface does not mean the active core supports it. After switching cores, check that the configuration is accepted and confirm startup in the logs; don't rely only on whether a toggle appears enabled.
How traffic is captured, where DNS queries go, and how tests are run all affect the results. Check the current mode before testing so you don't compare numbers that mean different things.
The system proxy sets a local proxy address and port in the operating system. Apps that follow this setting send their connections to the client. Some apps use their own network configuration and may ignore the system proxy. Unlike TUN, it does not capture traffic at the network layer. If apps lose connectivity after the client exits, first check whether the system proxy still points to a local port that is no longer active.
TUN receives IP packets through a virtual network interface and handles connections according to the client's routing and DNS settings. It usually requires system permissions and may conflict with other virtual adapters or routing software. Enabling TUN does not mean all traffic uses the same remote outbound, nor does it guarantee faster speeds; the actual path depends on rules, exclusions, and core capabilities.
Latency is the time from starting a test to receiving a response, but ICMP, TCP connection, and HTTP request tests measure different stages. A successful TCP connection to a port does not prove that proxy authentication or access to the destination site works. When comparing nodes, use the same test method and destination, and look at multiple results. A single low reading does not indicate download bandwidth or long-term stability.
“Connection latency” usually means the time to reach a specified test address through the selected proxy, rather than just probing the server port. Results may include DNS, proxy handshake, TLS, and the destination site's response time; the exact timing depends on the client. A failed test could also mean the test address is unavailable. Check actual browsing and logs before concluding that a node is down.
FakeDNS returns synthetic addresses for domains and stores the address-to-domain mappings so later connections can recover domain information for routing. A synthetic address is not the destination site's real address and usually won't work outside the client that maintains the mapping. If access fails after changing or disabling the mode, you may need to clear app and system DNS caches and reconnect.
A DNS leak occurs when domain lookups go to an unintended resolver instead of following the configured resolution policy. A browser's encrypted DNS, the system resolver, and the client's DNS can each use different paths, so routing application traffic through a proxy does not prove DNS queries take the same route. When troubleshooting, first define the expected path, then check app settings, client rules, and where queries actually go.
Subscriptions fetch multiple configurations; share links usually describe a single node. These are different types of input, so identify what you have before importing it.
A subscription URL is usually a fetchable address that provides a set of nodes for the client to update over time. Opening the URL in a browser does not guarantee its response format is supported by the client. If importing fails, check the update message and format compatibility. The URL may contain access credentials, so hide it before sharing screenshots, logs, or support requests.
A node is a selectable connection profile in a client, usually containing a server address, port, protocol, authentication details, and transport parameters. Its name is only a display label and does not prove its location, route, or performance. One server can offer multiple profiles; deleting a node from the client does not delete the remote service.
Share links encode connection parameters as text with a protocol prefix, such as vmess://, vless://, or ss://. They can usually be imported from the clipboard; a QR code is simply another way to carry the same content. A single-node link generally won't update automatically when the provider changes the profile. Links may also contain authentication details, so don't post them publicly.
Subscription conversion parses content in one format and outputs it in another that a different client can read. Conversion changes only how settings are represented; it cannot give a core support for protocols it does not implement, and it may drop flow-control or transport extension fields. Submitting a subscription to an online converter may expose its connection credentials. Prefer a format supported natively by your client.
Traffic routing is the strategy; rules are the conditions that implement it. Whether a rule matches also depends on whether the connection carries domain information and whether the data file includes the relevant category.
Routing rules select an outbound for a connection based on conditions such as domain, IP, port, or inbound tag. Rules are usually evaluated in order; a broad rule near the top can prevent more specific rules below it from taking effect. Unmatched traffic follows the configured default behavior. When troubleshooting, check the conditions, order, and outbound tag—not just whether a domain appears in a list.
GeoIP groups IP ranges by region or purpose for use in routing rules. It is not a live device locator, and data can lag behind changes in address allocation. Different data sources may also disagree. Whether a domain-based connection is resolved to an IP for matching depends on the DNS strategy; don't assume every GeoIP rule triggers automatically.
GeoSite groups domains by service, purpose, or other categories so you can reference related sites together. The available categories and domains depend on the data file in use; same-named groups from different sources may differ. A site may rely on additional domains for sign-in, images, or APIs, so matching its main domain may not cover every request on the page.
Traffic routing is the overall strategy of sending connections through different outbounds—such as direct, proxy, or block—according to rules. “Global” and “rules” are simplified labels in the client interface; their actual scope depends on the active traffic-capture mode. Existing long-lived connections may keep using their old route after rules change. Start a new request and check the logs to confirm that it uses the intended outbound.
A security layer, authentication mechanism, or flow-control option is not the same as a proxy protocol. After choosing the right protocol, make sure these settings also match the server.
TLS encrypts traffic and authenticates the peer. Multiple proxy protocols can use it. Clients usually validate the certificate against a server name. The connection address and validation name can differ, but both must match the server configuration. An expired certificate, name mismatch, or incorrect device clock can cause a handshake failure. Find the cause rather than treating skipped validation as a standard fix.
REALITY is often paired with VLESS. It is a transport security mechanism, not a standalone proxy protocol alongside VLESS. Check the server public key, server name, short ID, and applicable fingerprint settings; exact fields depend on the version in use. Simply switching the security option to REALITY is not enough: confirm that the core supports it and that the parameters come from the same server configuration.
XTLS Vision is a flow-control option in Xray that reduces redundant encapsulation overhead for eligible TLS traffic. It is not a standalone proxy protocol and does not guarantee faster performance in every app or network. The client's flow setting must match the server and selected transport; don't add this field to an arbitrary node in an attempt to speed it up.
AEAD combines content encryption with message authentication to protect confidentiality and detect tampering. Associated data can be authenticated without being encrypted. Different protocols may use this mechanism at different stages, so don't copy an AEAD setting from one protocol to another. When importing a profile, keep its original method and parameters; you don't need to create a separate node named AEAD.