Protocols
The protocol defines how proxy requests are expressed; the transport carries the data; the security layer protects the connection. Check the complete set of settings when choosing a configuration.
- VMess
- A proxy protocol in the Project V ecosystem, with authentication and data protection; modern configurations typically use AEAD authentication. Client and server settings, including the user ID, must match. A significant system clock difference can also cause authentication to fail. VMess is not a transport method: it can be paired with different transports.
- VLESS
- A lightweight proxy protocol that does not encrypt payloads itself and is typically deployed with TLS or REALITY. Set the user ID, flow control, transport, and security layer as required by the server; simply switching the protocol dropdown to VLESS is not enough. Compatibility depends on the complete configuration, not the protocol name alone.
- Trojan
- A proxy protocol that typically relies on TLS to protect connections and uses a password for authentication. Check the port, server name, and certificate validation as well as the password. A reachable address does not guarantee successful authentication. If certificate validation fails, check the name, system clock, and server certificate rather than disabling validation.
- Shadowsocks
- Often abbreviated as SS, this proxy protocol uses a shared key and a specified encryption method. Implementations from different generations may have different requirements for encryption methods, key formats, and core versions; keys in different formats are not interchangeable. When importing, check the encryption method and authentication fields, not just the address and port.
- REALITY
- A transport security solution in the Xray ecosystem, not a standalone proxy protocol alongside VLESS. Common client settings include PublicKey, ShortId, SNI, and a fingerprint; these must match the server, and whether ShortId can be left blank depends on the server. Public and private keys have different purposes: clients must not use the server's private key.
- XTLS Vision
- An Xray flow-control mode, usually shown in clients as
xtls-rprx-vision. It is neither a transport protocol nor a security layer and is commonly used with compatible VLESS configurations. Use it only when the server, transport, and core all support it; it is not a general speed boost for any server.
- Transport Protocol
- The method used to carry proxy protocol data. Common options include TCP and WebSocket, though available choices depend on the core and its version. Even with the same proxy protocol, different transports may prevent the two ends from communicating. Extra fields such as Path and Host only apply to specific transports and should not be copied across configurations blindly.
Cores and Ecosystem
The client provides the interface; the core handles connections. To check whether a feature is supported, look at both the client controls and the core actually in use.
- Project V
- An ecosystem of network proxy tools and related components, with V2Ray as a major part. “V2Ray client” usually means a graphical management app, not that every app uses the same core. Understanding this distinction helps separate interface features, configuration formats, and protocol implementations.
- V2Fly
- A community project that continues to maintain the V2Ray core, providing protocol handling, routing, DNS, and other capabilities. v2flyNG uses this core family as an Android option. Check the actual core version for feature support; do not copy fields from another core or infer compatibility from the client name alone.
- Xray
- A proxy core project with historical ties to V2Ray, with its own evolving features and configuration. Features such as REALITY and XTLS Vision require a compatible Xray core; v2rayNG uses this core family. The configuration structures are similar, but that does not guarantee that entire configurations are interchangeable.
- Core
- The component that handles protocols, establishes connections, and applies DNS and routing; the client manages the interface, subscriptions, and configuration. An option in the interface does not guarantee that the selected core can run it. If startup fails, check the core log first for unsupported fields, missing parameters, or port conflicts.
Client Features
Capturing traffic and choosing an outbound are separate tasks. System proxy or TUN determines how traffic enters the processing path; routing determines how it is forwarded afterward.
- System Proxy
- Uses the operating system's proxy settings to direct apps that honor them to the client's local proxy endpoint. Some apps use their own network settings and may ignore the system proxy, so it does not capture all traffic. If websites stop working after closing the client, check that the system proxy was restored, not just the server status.
- TUN Mode
- Routes network traffic into the client's processing path through a virtual network interface and routing settings, typically covering more traffic than the system proxy. It may require administrator permissions and correctly configured routes and DNS; enabling it does not mean every connection will use the proxy outbound. Check for route conflicts when using it alongside other virtual network tools.
- Inbound and Outbound
- Inbound accepts connections entering the core, such as a local HTTP or SOCKS proxy endpoint. Outbound sends connections onward to their destination, whether through a proxy, directly, or by blocking them. Routing rules use outbound tags to select how a connection is handled. An inbound listening port is not the remote server port; changing one does not change the other.
- Traffic Sniffing
- Uses handshake data from some connections to identify domain names or protocol clues for routing decisions. It does not decrypt application content and cannot identify every connection; the available information depends on the protocol and handshake. DNS and routing still need to be configured correctly. Sniffing is not a substitute for a complete domain resolution policy.
Traffic capture is not the same as proxy routing. An app captured by TUN may still connect directly under the routing rules. To verify its path, check the destination, matched rule, and outbound logs rather than just the mode toggle.
Subscriptions and Servers
Subscriptions provide and update configurations; servers are the individual connection profiles. Importing, updating, testing, and accessing a destination each verify a different step.
- Subscription
- A resource endpoint for downloading or updating server configurations in bulk. The client reads its contents and turns them into manageable profiles. Subscription links may contain credentials, so treat them as sensitive and avoid sharing them in screenshots or public documents. A successful update only confirms that content was retrieved and parsed; it does not prove every server is reachable or necessarily enable the system proxy.
- Server
- A common name for a server connection profile in a client, typically containing an address, port, authentication details, and transport settings. Different server names may point to the same infrastructure, and a region in the name does not prove its actual location or exit characteristics. Check connection tests, app access, and logs to assess availability; a profile appearing in the list is not enough.
- Subscription Group
- A way to organize subscription URLs and server profiles by source, making them easier to update, filter, or delete separately. Group names are for management; they are not routing policies, automatic switching, or load balancing. Before deleting a group or updating a subscription, check whether manual changes will be overwritten and use the client's backup feature if needed.
- Latency and Real Connection Latency
- “Latency” may measure only the time to establish a TCP connection; “real connection latency” usually sends a specific request through the selected proxy, making it closer to the app's traffic path. Test methods vary by client, and results depend on the destination, DNS, handshake, and timeout settings. Latency is not download speed. Check the test destination before concluding that a timeout means the server is down.
Routing and DNS
DNS resolution determines which addresses are returned; routing determines which outbound handles a connection. They affect each other, but are separate settings.
- Routing Rules and Split Tunneling
- Routes a connection to a specified outbound based on criteria such as domain, IP, port, or inbound tag. Common fields include
domain,ip, andoutboundTag. Rules are usually evaluated in order, and the default outbound handles connections that do not match. A rule may not match if the core sees an IP address instead of a domain name.
- GeoIP
- A collection of IP addresses grouped by region or network category for routing matches. It depends on the data file and how recently it was updated; it is not real-time geolocation and cannot replace domain categorization. Content delivery networks may return different addresses depending on network location, so a GeoIP tag alone may not accurately identify a service.
- GeoSite
- A collection of domains grouped by service or category, often used for domain routing or DNS policies. Categories, coverage, and available entries depend on the data file; not all sources use the same labels. If a rule fails to load, first check that the category exists and the file is readable, then check the domain matching method.
- FakeDNS
- Assigns a virtual IP to a domain, then restores the domain association when subsequent traffic enters the corresponding processing path. The returned address is not the real server address; DNS, mapping, and routing must work together. If an app connects to the virtual address outside the client, access may fail. Consider app and system DNS caches when switching approaches.
- DNS Leak
- A DNS query that bypasses the intended resolution path and goes to another resolver; judge it against a clearly defined configuration goal. System resolution, an app's built-in encrypted DNS, and core DNS may all be in use, so a correct website exit IP does not mean DNS followed the intended path. Check app settings, system resolvers, and core logs separately rather than relying on a single test.