01 / PROTOCOL
The protocol defines the parameter structure; it is not the transport
A protocol is the basic set of rules the client and remote service use to interpret data. VMess includes its own identity and timestamp checks; VLESS uses a leaner authentication structure and is often combined with different security layers. Trojan configurations typically focus on the password, server name, and certificate-related parameters, while Shadowsocks relies on its encryption method and password to define the connection. After importing a node, verify the protocol type first, then check that protocol’s required fields instead of judging by the node name alone.
Protocols and transports such as TCP, WebSocket, and gRPC belong to different layers. Changing the protocol does not automatically fix transport parameters. When the client reports a format error, compare the protocol, port, user identifier, transport, and security layer as one set.
Read the protocol selection guide →
02 / SUBSCRIPTION
A subscription supplies a node list; it is not a single connection switch
A subscription URL retrieves a group of nodes and their updates. After adding the URL, you must run an update before the client reads the remote content and writes it to the local list. A successful update only means the format was readable; it does not mean every node can connect. After choosing a node, run a real connection test and confirm that the system proxy is active by visiting a webpage or checking your public endpoint.
Multiple subscriptions can be named and managed separately. Before updating, make sure the URL is complete from end to end, with no spaces or line breaks introduced during copying. An expired subscription, an empty response, or an unsupported format can all appear as no new nodes or unchanged old nodes; check these three possibilities in order.
See how to import a subscription →
03 / ROUTING
Routing matches conditions first, then hands traffic to the selected outbound
Routing rules do not change the node itself; they decide whether a connection goes through the proxy, connects directly, or is blocked. Common conditions include domains, IP addresses, ports, network types, and processes. Rules are usually evaluated in order, so a broad rule near the top may capture traffic before a more specific rule runs. When diagnosing routing results, check both the rule content and its order, along with the associated outbound tag.
New users can start with the client’s preset mode and add custom rules after confirming a stable basic connection. After changing rules, test the target website, commonly used apps, and local network resources separately; do not infer the state of all traffic from a single page.
Review routing and traffic-splitting terms →
04 / STREAM SETTINGS
Transport parameters must match the server configuration field by field
streamSettings describes the underlying network type, security layer, and additional parameters. TCP, WebSocket, and gRPC use different field structures; enabling TLS or REALITY also adds settings such as the server name, fingerprint, public key, short ID, or path. A mismatch in any one of these can cause a failed handshake, an immediate disconnect, or repeated timeouts.
Use a consistent order when checking them: network type, security type, server name, path or service name, then extra identifiers. Avoid changing several fields at once; even if the connection returns, you will not know which change made the difference.
Compare transport layers →
05 / CORE
The client provides the interface; the core handles connections and routing
v2rayN, v2rayNG, and v2flyNG are graphical clients. The bundled core does the actual work of parsing configuration, establishing connections, and applying routes. Xray and V2Fly share technical roots and have highly similar core configuration concepts, but support for newer protocols, transport extensions, and certain fields is not identical. Importability and operability are separate questions: a client may recognize a link format even when the current core lacks the required capability.
Choose a client based first on your platform, then on the protocol required by the node. Client updates can also change core capabilities. When an older configuration behaves differently in a new environment, check field compatibility rather than copying every advanced parameter from another core.
Learn about the core families →