Start with choosing a client and importing a subscription, then check the actual fields for routing and DNS settings.
VMess
VLESS
Trojan
Shadowsocks
REALITY
Settings — v2rayN
Core: GeneralCore: DNSRouting
Local listening port10808
Allow connections from the local network
Enable traffic sniffing
Domain strategyIPIfNonMatch
Multiplexing (Mux)
TLS fingerprintchrome
CancelOK
CLIENT / SYSTEM
Choose a client and operating system
Check your operating system and processor architecture before choosing a client. v2rayN is the main desktop option; on Android, consider v2rayNG with its Xray core. If you need V2Fly compatibility, check which features v2flyNG supports. The client provides the interface, but protocol support depends on the selected core.
The desktop edition uses a cross-platform interface, while the classic WPF edition retains a familiar desktop workflow. Both work well for managing subscriptions, editing nodes, and viewing logs; choose whichever suits your preferences.
Check the system requirements before installing. If you already have a setup, export any subscription groups and routing rules you want to keep so the new environment doesn't overwrite them.
Use the chip information in About This Mac to choose the Apple Silicon or Intel installer. Processor architecture and operating system are separate criteria; don't rely on the file extension alone.
After installation, import a working node and confirm the client can make a request before enabling the system proxy. If browsers and other apps behave differently, check whether each app follows the system proxy settings.
v2rayNG uses the Xray core; v2flyNG is an alternative based on V2Fly. Most modern devices use arm64. If you're unsure of the architecture, check your device details before trying a universal installer.
Approve the system VPN prompt when connecting for the first time. If the connection drops in the background, check battery optimization and background app restrictions; don't mistake a system process being stopped for a subscription or protocol error.
Choose a deb or rpm package based on your distribution, and distinguish x64 from arm64. A desktop GUI client makes it easy to manage nodes in one place; you don't need to set up a command-line service just to manage subscriptions.
After installation, check your desktop environment's proxy settings and local listening port. Some apps require the proxy address to be entered separately; enabling the system proxy doesn't guarantee every process will use it.
Inbound, routing, outbound. Follow the request path through the config.
FIELDS / CAPABILITIES
Protocol, transport, and routing settings
The protocol name in a share link describes only part of the configuration. Authentication, transport, security layers, and routing rules each serve a different purpose. Use the index below to distinguish them, then check the relevant configuration reference. Don't copy an entire example from another core into your current client.
Protocol fields and node settings
VMess, VLESS, Trojan, and Shadowsocks use different authentication and encryption schemes. After importing a node, check its protocol, server address, port, and authentication details. VLESS does not encrypt traffic on its own, so it is usually paired with TLS or REALITY. VMess settings cannot be applied directly to VLESS. Unlike tools that only offer a connection toggle, a GUI client lets you inspect node settings field by field, though support ultimately depends on the core. The same protocol name does not mean transport and security settings can be omitted.
TLS, REALITY, and WebSocket belong to different configuration layers. TLS and REALITY provide secure transport, while WebSocket carries the data. Check the server requirements first, then verify fields such as serverName, fingerprint, and path. Toggling TLS alone won't make an arbitrary node work with a different connection setup. Unlike simplified interfaces that choose settings automatically, clearly exposed fields make handshake errors easier to diagnose. Client and server settings must match, and certificate verification should normally remain enabled.
Routing sends traffic to a specified outbound based on matching domains, addresses, or ports; it doesn't automatically pick the fastest node for each app. Rules are usually checked in order, so an earlier match affects what happens next. Put specific exceptions before broad rules. domainStrategy controls when domains are resolved for routing decisions; it isn't the client's overall DNS configuration. Rule-based routing can handle more specific needs than a global toggle, but check that each outboundTag exists and test the change with a new request.
Manage subscription URLs and share links separately
A subscription link fetches a group of nodes; an individual share link imports one connection's settings. After adding a subscription, run an update to load the parsed node list. Subscription groups are easier to refresh than manually maintained nodes, but remote updates may overwrite local edits. Base64 is an encoding format, not encryption. If import fails, check the link format, subscription response, and core compatibility separately. Don't paste subscription URLs containing access credentials into public conversion tools.
Reuse node settings; configure local access separately
Desktop and mobile clients can use the same node settings, but they connect to the system differently. Desktop clients typically use a local SOCKS or HTTP listener with the system proxy, while Android clients usually route traffic through the system VPN interface. Rather than copying the entire runtime config to another device, import the node and then adjust local ports, routing, and DNS for that device. File paths, permissions, and background restrictions also vary. Cross-platform support means similar management workflows, not identical local settings.
Installing a client is only the first step. For an initial setup, use a node from a trusted source with complete settings to test the full connection path before adding complex routing rules. This makes it easier to isolate issues with the node, client settings, or app connectivity.
01 / IMPORT
Import a subscription and check its nodes
Add a group in subscription management and enter the subscription URL, then save and update it. For a single share link, use the import-from-clipboard option. If the list is empty, check for extra spaces in the copied text and whether the subscription requires valid credentials; a webpage URL isn't necessarily a subscription URL.
After importing, open a node's details and check its protocol, server address, port, and transport. The node label is just a name for identification; it doesn't indicate the actual route, availability, or encryption. If you made manual changes, note them before refreshing the subscription.
02 / ROUTE
Select a node and configure traffic routing
Set the node you want to test as active, then choose a routing mode for your needs. Before enabling the system proxy on desktop, check that the local listening port isn't already in use. On Android, approve the VPN prompt. The system proxy only affects apps that follow it; this doesn't mean all traffic is routed through the client.
For your first run, keep the rules clear and simple. If you need to switch to an access method such as TUN, check permissions, routing, and DNS behavior separately. Don't change transport, security, and routing settings all at once, or it'll be hard to tell what caused the result.
03 / VERIFY
Make a new request and check the logs
Open a test page you're allowed to access and check whether the client logs show the corresponding connection. A successful TCP test only confirms that a connection can be made to a port; it doesn't prove authentication, the TLS handshake, or the full request succeeded. A real connection test and a download speed test measure different things, too.
If the browser still can't connect, check its proxy settings first, then look in the logs for DNS resolution, connection timeouts, or handshake errors. Change one thing at a time, save and reload the config, then test with a new request. Before sharing logs for help, remove subscription URLs, credentials, and other personal information.
Understand core capabilities before checking client settings.
PROJECT V / V2FLY / XRAY
How open-source cores and clients fit together
A search for “V2Ray” can turn up project names, core names, and client names. They refer to different layers: the project ecosystem provides the technical foundation, the core handles connections, and the GUI client organizes nodes and settings into a working configuration. Understanding these distinctions helps you judge whether a guide applies to your setup.
Project V: the shared background to the configuration model
V2Ray originated in the Project V ecosystem. Inbounds receive app traffic, routing determines where it goes, and outbounds connect to destinations. This structure keeps protocol and traffic policies separate. Many GUI clients still use these concepts, so understanding inbounds, outbounds, and routing transfers more easily across environments than memorizing a button's location in one interface.
Similar configuration structures don't mean every field is interchangeable. When reading an older guide, check which core it covers, the protocol combination, and its scope. Interface labels may change with updates, but tracking where a request enters, which rules match it, and which outbound sends it remains a reliable way to troubleshoot.
V2Fly and Xray: related projects, separate development
V2Fly continues the community development of V2Ray, while Xray grew from related code and introduced its own protocol and transport capabilities. They share a history but differ in configuration support. For example, check REALITY and XTLS Vision settings against Xray's supported features. Both cores using JSON doesn't mean one will recognize the other's fields.
If a client lets you switch cores, treat that as more than a performance choice. Recheck whether the selected core supports the node protocol, security layer, and fields such as flow. If you see an “unknown field” or unsupported protocol message, check the core selection before repeatedly changing the server address.
Three clients: separate roles for the UI and core
v2rayN, v2rayNG, and v2flyNG are all open-source GUI clients. v2rayN is for desktop use and manages nodes, subscriptions, and routing; v2rayNG runs the Xray core on Android; v2flyNG offers an alternative based on V2Fly. Subscription groups and interface preferences saved by a client aren't necessarily the same files as the runtime config read by its core.
All three clients are free to use, but they don't provide remote nodes or network service. Subscription links and node settings must come from a service you have permission to use. Choosing software, choosing a core, and choosing a connection service are three separate decisions; one name shouldn't stand in for the others.
Open-source licenses and updates: check each component
Open source means the source code is available under the applicable license terms; use, modification, and redistribution must still follow each project's license. V2Fly's main code uses the MIT License, and Xray-core uses MPL-2.0. Clients and bundled components have their own licenses. A license describes rights and obligations; it doesn't guarantee the safety of any runtime configuration.
Clients, cores, and rule data may follow different release schedules. Before upgrading, note the current core selection and back up routing and DNS settings; afterward, verify with the same test request. If only one site has a problem, check its rules and DNS resolution first. If all connections fail, troubleshoot step by step: local access, node settings, and core status.
READING / RECENT NOTES
Subscription formats and connection diagnostics
Once the basic connection works, look into format conversion, protocol differences, and test results. These three articles cover commonly confused concepts through specific fields and measurement methods. Consult them when you run into the corresponding configuration issue.
A TCP handshake, a request completed through a proxy, and a sustained download measure different stages. Learn why the results aren't directly comparable and how to assess a node using logs, real connection tests, and actual browsing.
Compare the two protocols by authentication, timing requirements, and security layers, and learn what UUID and alterId do. First identify which layer each field belongs to, then determine which settings must come from the node provider and which aren't interchangeable.
Understand the differences between subscription responses, runtime configs, and single-node share links, and learn which import option to use. Check the target client's supported formats before converting; a successful encoding doesn't mean the config is compatible.