Protocols & Transports
Protocols, transports, and security layers are different settings. A complete configuration often requires all three, so the protocol name alone does not tell you which other parameters to use.
- Protocols & TransportsVMess
- A proxy protocol in the Project V ecosystem that authenticates connections using parameters such as a user ID. VMess is not a specific transport; the same protocol can use different transports and security settings. After importing, check the server address, port, user ID, and transport parameters. A significantly inaccurate system clock can also cause authentication to fail.
- Protocols & TransportsVLESS
- A lightweight proxy protocol that does not encrypt traffic on its own and is typically used with security mechanisms such as TLS or REALITY. The user ID, transport, and flow control settings must match the server. Seeing VLESS does not mean a configuration will work; confirm that the selected core supports the combination.
- Protocols & TransportsTrojan
- A proxy protocol typically based on TLS and password authentication. Besides the server and port, configuration includes the password, server name, and certificate verification. If the connection fails, check authentication and the security layer separately rather than assuming every error is caused by a wrong password.
- Protocols & TransportsTLS
- A security protocol that encrypts connections and verifies the identity of the other party. It is also one of the foundational technologies used by HTTPS. The server name, certificate chain, and system clock all affect verification. For certificate errors, check the name and clock first; do not treat “skip certificate verification” as a general long-term setting.
- Protocols & TransportsREALITY
- A transport security mechanism in the Xray ecosystem, not a standalone node protocol. Common settings include the server name, public key, and short ID; missing any of them can prevent the handshake. Support varies by core and version, so an option with the same name in the client does not guarantee compatibility.
- Protocols & TransportsWebSocket
- A bidirectional transport that can carry proxy protocol data; it is not the same as VMess or VLESS. Check the path, Host, and whether TLS is enabled. Paths are generally case-sensitive, and omitting the leading slash when copying one can change the request target.
Cores & Ecosystem
A setting being available in the interface does not mean the core can use it. When troubleshooting protocol support, first check which core the configuration actually uses.
- Cores & EcosystemProject V
- A project ecosystem built around modular network proxy tools, with V2Ray as one of its best-known components. In everyday conversation, “V2Ray” can refer to the wider ecosystem, but a specific configuration still depends on the core and client. Check the software name in a guide to avoid mixing steps from different projects.
- Cores & EcosystemV2Fly
- A community-maintained project in the V2Ray ecosystem that provides core implementations and related documentation. v2flyNG is an Android graphical client built around this core family. Check the capabilities of the core in use; do not assume that proprietary settings work across different cores.
- Cores & EcosystemXray
- An open-source proxy core project that grew out of V2Ray, with its own evolving protocol implementations and features. v2rayNG uses the Xray core, and v2rayN can also manage configurations for it. When troubleshooting an unavailable feature, check both the client version and the version of the core actually in use.
- Cores & EcosystemCores and clients
- The core handles protocols, connections, DNS, and routing; the client imports configurations, manages subscriptions, and provides a graphical interface. Updating the client does not necessarily update every separately installed core component. To choose software, start with a comparison of three clients, then check the core requirements for your configuration.
Subscriptions & Nodes
First determine whether you have an updateable URL or a single connection configuration. Then choose Add subscription or import from clipboard to avoid using the wrong option.
- Subscriptions & NodesSubscription URL
- A URL that returns a set of connection configurations. Updating a subscription fetches and parses its contents again. It often looks like an HTTPS URL, such as
https://example.com/your-subin a tutorial, but the format of the URL does not guarantee that the returned data is compatible. Real subscription URLs may contain credentials; hide the full URL before sharing screenshots, asking for help, or posting logs.
- Subscriptions & NodesNode
- A common term for a selectable connection configuration in a client, usually containing a server address, port, protocol, and authentication details. A node's name is just a label; it does not confirm its location, availability, or connection quality. If entries share a name, distinguish them by subscription group and actual settings, not just their display names.
- Subscriptions & NodesConnection latency
- The time measured when the client connects using the selected configuration and accesses a test endpoint; the exact method depends on the client. Results depend on DNS resolution, the handshake, the endpoint's response, and current network conditions. This is not download speed. A single timeout does not prove the configuration is broken; first check the test endpoint and proxy settings.
Routing & Traffic Rules
Traffic capture determines which connections enter the client; routing determines how they are handled once inside. Review traffic rules, rule data, and outbound tags together.
- Routing & Traffic RulesRouting rule
- A configuration that matches connections by criteria such as domain, destination IP, port, or inbound, then sends them to a specified outbound. Rules are usually evaluated in order; a broader rule placed first may override more specific conditions later. When making changes, identify what should match, confirm that the outbound tag exists, and check how unmatched traffic is handled.
- Routing & Traffic RulesTraffic routing
- Using rules to send different connections through different paths, such as sending local network destinations directly and another set of destinations through a proxy. The system proxy or TUN captures traffic at the entry point; routing happens after traffic enters the core. If an app never sends traffic through the client, changing routing rules alone usually will not help.
- Routing & Traffic RulesGeoIP
- Rule data that matches destinations against IP address ranges, often used to represent a region or a special-purpose address range. It depends on the current data file and referenced entries, matching the destination IP against the address ranges in those entries. Whether a domain is resolved first can also affect whether IP-based rules match.
- Routing & Traffic RulesGeoSite
- Rule data that matches destinations against domain collections.
geosite:cnis a common reference. Which domains and categories a collection contains depends on the rule data installed locally; the name alone does not guarantee its contents. Referencing a missing collection can prevent a configuration from loading, so check the source and compatibility before updating rule data.
- Routing & Traffic RulesOutbounds and outboundTag
- An outbound defines how a connection is handled as it leaves the core, such as direct, proxied, or blocked. In a routing rule,
outboundTagpoints to a defined outbound tag. A tag nameddirectonly means direct when it is linked to a direct outbound. When copying rules, check the tags as well as the matching conditions.
- Routing & Traffic RulesDNS leak
- A situation where domain lookups are handled by a resolver or network path other than the one intended. An app's built-in encrypted DNS, system DNS, and core DNS may all be active, so check each layer. Before drawing conclusions, identify which resolver should handle the lookup and which outbound should carry it; the resolver's name alone is not enough.
Client & System Settings
First connect using a traffic capture method that meets your needs, then adjust DNS, virtual adapters, and local network access one at a time. Changing one variable at a time makes issues easier to isolate.
- Client & System SettingsSystem proxy
- Registers a local proxy address and port with the operating system so apps that honor system settings use the proxy. Not all apps read this setting, so an app may still connect directly even when the system proxy is enabled. This handles traffic capture at the entry point; routing rules determine whether traffic is direct or proxied once it enters the core.
- Client & System SettingsTUN mode
- A mode that uses a virtual network interface to capture traffic covered by the capture rules and pass it to the core. It typically involves system permissions, routing, and DNS settings, and may conflict with other virtual adapters. Whether to enable it depends on how the target apps support proxies; more enabled options are not necessarily better.
- Client & System SettingsFakeDNS
- A mechanism that returns synthetic addresses for domains and stores the domain-to-address mapping, allowing later connections to be associated with their domains. It relies on coordinated DNS resolution and traffic capture, so it should not be enabled in isolation. After disabling it or switching approaches, old DNS cache entries may remain; follow the client documentation to clear or handle them.
- Client & System SettingsLocal listening port
- The port a client uses to provide a local proxy entry point, such as HTTP or SOCKS; it is different from the remote server port. When configuring an app's proxy manually, enter the actual listening address, port, and protocol. If another program is already using the same address and port, the core may not be able to start the listener.
- Client & System SettingsAllow connections from the local network
- Allows other devices on the local network to access the proxy listener on this device; it does not make every device use the proxy automatically. Reachability also depends on the listening address, firewall, and network isolation settings. This usually does not need to be enabled for local use. If sharing access, limit who can connect and make sure the network is trusted.