Learn the difference between protocols, cores and clients, then make sense of subscriptions, routing and DNS settings.
Select a category to jump to its section. Each term has an address-bar anchor you can link to directly. If similar setting names are confusing, check which client and core you're using before reading the explanation.
Configure a client step by step →The protocol defines how proxy communication is structured; the transport defines how its data is carried. They are separate settings.
VMess is a proxy protocol in the Project V ecosystem, with authentication and data protection mechanisms. After importing a configuration, check the user ID, transport and security layer—not just the server address and port. Don't guess additional identifiers for older configurations; use the details provided by the server and check what the current core supports.
VLESS is a lightweight proxy protocol that does not provide full transport encryption on its own. It is often paired with a security layer such as TLS or REALITY. Two configurations using the same protocol are not necessarily interchangeable: flow control, transport and security parameters must also match. Importing a link only confirms that the client recognizes its format, not that all connection requirements are met.
Trojan typically protects connections with TLS and uses a password for authentication. This is the node's authentication password, not the client's local management password. If a connection fails, check the target domain, certificate verification and transport settings as well as the credentials. Re-entering the password won't resolve every handshake issue.
In client settings, the transport layer usually means how proxy protocol data is carried, such as over TCP, WebSocket or gRPC. This is not a strict use of the networking model's layer terminology. WebSocket paths and Host values, as well as gRPC service names, each serve a specific purpose and must match the server. Changing the transport is not simply a performance tweak; an arbitrary change can break the connection.
The graphical interface manages configuration; the core handles connections. A feature works only if both layers support it.
Project V is a modular network proxy ecosystem, and V2Ray is one of its major implementations, with capabilities such as protocol handling, routing and DNS. In everyday searches, “V2Ray client” often refers to a GUI manager, but the interface and core are not the same thing. When troubleshooting, note the client name and the core it actually launches to avoid confusing interface issues with connection problems.
Xray is an independent proxy core project with historical ties to V2Ray. It handles connection setup, protocol processing and routing. v2rayNG uses the Xray core; on desktop, check the client's settings to see which core is active. Supported protocols and parameters depend on the core version, so don't assume advanced options work the same way after switching cores.
V2Fly is a community project that continues to maintain the V2Ray core and related components. v2flyNG is an Android client that uses this core ecosystem. V2Fly and Xray do not evolve in exactly the same way, and an extension parameter recognized by one core may not work with the other. Check what the configuration requires instead of swapping cores based on similar names.
A GUI client provides controls for importing subscriptions, selecting nodes, managing routes and switching proxy modes, while the core handles the actual connections. v2rayN is available for Windows, macOS and Linux; v2rayNG and v2flyNG are for Android. Menus can differ between clients, so don't assume a desktop system proxy option works the same way on mobile.
Compare clients →A subscription is a source of configurations; a node is an individual connection profile. Test results are only a snapshot.
A subscription lets a client retrieve and update a set of connection profiles from a link. It is neither a proxy protocol nor an active connection by itself. After importing, update the list, select a node and choose a suitable proxy mode. Subscription links may contain credentials, so hide the full link before sharing screenshots, logs or support requests. Never post it publicly.
See how to import a subscription →A node is a connection profile in a client, usually containing a server address, port, protocol, authentication details and transport parameters. The name in the list is just a label; it doesn't tell you the node's actual location, availability or performance. After selecting a node, make sure the core is running and app traffic is reaching the client.
Subscription groups organize subscriptions and nodes by source or purpose, making them easier to update, filter and manage separately. Updating a group may replace its subscription contents, and manually edited node settings may be overwritten on the next update, depending on the client. Keep manual configurations separate from automatically updated subscription content if you need them to persist.
Latency measures how long a particular test takes. A TCP probe and “real connection latency,” measured by accessing a test URL through the proxy, are different metrics. The latter is also affected by DNS, the handshake, the test target and current network conditions. A lower probe result doesn't mean higher download throughput. If a test fails, first distinguish an unavailable node from an unreachable test URL.
First check whether traffic reaches the client. Then check which outbound the rules send it to.
Routing directs requests through a proxy, directly to their destination or blocks them based on domains, IP addresses or other criteria. In common configurations, rules are checked in order, so an earlier match affects what happens next. If no rule matches, the default outbound applies. Global mode doesn't necessarily capture traffic from every app; rules can't affect traffic that never reaches the client.
GeoIP is rule data that groups IP addresses by geographic region or other sets, and can be used to choose an outbound for a destination. It isn't a real-time location service, and address assignments may be inaccurate due to data updates or changes in service deployment. For domain requests, routing domain strategy also determines whether and when a domain is resolved before matching its IP address.
GeoSite groups domains by site, service or purpose so routing rules can match a set of destinations at once. A label doesn't guarantee complete coverage of a service; the same service may use additional domains for sign-in, static assets or content delivery. If only part of a page fails to load, check the logs for unmatched requests instead of immediately sending all traffic through the same outbound.
The system proxy uses the operating system's proxy settings to route traffic from apps that follow them, but some apps ignore these settings. TUN mode receives traffic through a virtual network interface and usually requires routing, DNS and permissions; its coverage depends on the implementation. First confirm the connection works in ordinary proxy mode, then enable TUN to avoid adding more variables to troubleshooting at once.
Troubleshoot proxy modes →Encryption protects data in transit; authentication verifies who you're connected to. Disabling verification is not a configuration fix.
TLS protects data in transit and verifies the peer's identity, and is commonly configured as the security layer for proxy connections. A certificate name mismatch, an expired certificate or a significantly incorrect local clock can cause a handshake to fail. TLS protects the relevant connection, but doesn't guarantee that the destination service is trustworthy or replace the app's own account and data security measures.
REALITY is a transport security mechanism in the Xray ecosystem, not a standalone subscription format or a type of GUI client. Match the public key, server name, short ID and other parameters to the server's requirements, and make sure the client and core support them. Simply changing the security layer name in a regular TLS configuration to REALITY won't make the connection work.
SNI is an extension in the TLS handshake that specifies the target server name, helping the server select the right service and certificate for an address. It can differ from the IP address used for the connection, but must still meet the server's configuration and authentication requirements. For domain-related errors, check the server name against the configuration source; don't enter an unrelated site's domain.
allowInsecure is an option in some configurations that controls whether TLS certificate verification is skipped. Enabling it weakens peer authentication. It won't fix an incorrect SNI, certificate chain or system clock, or make incompatible protocols work together. If you see a certificate error, find its cause first; skipping verification is not a general-purpose fix for everyday use.
DNS resolution, connection setup and local listening are separate stages. Check each one independently.
DNS resolves domain names to IP addresses and other records, often before an app connects. The operating system, browser and proxy core may use different resolution paths, so routing web traffic through a proxy doesn't mean DNS queries follow the same path. To troubleshoot, first identify which component is resolving names and where it sends queries, then check the results and the outbound used for the connection.
FakeDNS assigns synthetic IP addresses to domain names and keeps a mapping so the proxy core can recover the domain when it receives a subsequent connection. This supports routing and connection handling. The returned address is usually not the real server address, so don't use it to determine server location. After enabling FakeDNS, make sure the relevant traffic returns to the core that knows the mapping; otherwise, resolution may succeed while connections fail.
A DNS leak occurs when domain queries use a different resolver or network path than intended. To determine whether one has occurred, first define the expected path; resolver names shown by a test page alone aren't enough to draw a conclusion. System DNS, browser Secure DNS and TUN DNS interception settings can all affect the result, so check what happens to actual queries.
A local listening port is where the client accepts connections from apps on the same machine. Some interfaces use 10808, but check your current settings. The proxy type, address and port configured in an app must match the active listener; don't mix up HTTP and SOCKS endpoints. After changing a port, also check the system proxy and any manually configured apps. If another process is using the port, the core may fail to start.