Why "Just Follow the Screenshots" Often Goes Wrong
The problem with screenshot tutorials is that they can only tell you "click here, in this version, on this screen." The moment the interface changes, you switch clients, or your situation doesn't quite match the screenshot, you have nothing to fall back on. But if you understand the logic behind it, when the interface changes you can figure out for yourself what a new button probably does, instead of waiting for someone to take a fresh screenshot.
Truth is, this type of client really only revolves around four core concepts, and each one has a real-world equivalent you already understand. Spending a few minutes sorting them out is far more useful than memorizing ten screenshots — let's go through them in order.
Breaking It Down: Just Four Concepts
Let's start with the node. A node is a specific server address that the client uses to forward your traffic — think of it as an actual road: good conditions (low latency) mean smooth travel, bad conditions (high latency, timeouts) mean it's blocked or crawling. The "server list" in the app is really just a collection of candidate routes you've gathered, and running a speed test just checks which road is currently clear.
One road isn't enough on its own — if you had to manually ask for a new one every time (i.e. adding nodes by hand), that'd be a hassle. That's where the subscription comes in — it has the client periodically check "what roads are available right now" and automatically update your list with the results. This is also why almost every guide recommends using a subscription: it's not that adding nodes manually doesn't work, it's just unnecessary maintenance you don't need to take on.
Nodes and subscriptions solve "is there a road available" — next comes "who's actually using that road," which is the system proxy. Successfully connecting in the client doesn't automatically mean every app on your phone or computer starts routing through the node — that depends on how the system proxy toggle is set: the client is responsible for building the road, and the system proxy decides which traffic (which cars) actually gets on it. The good news is that most clients handle this step automatically after installation, so you don't need to configure it yourself.
The last concept — and the one that trips up beginners the most — is routing mode. Without any filtering, all traffic (including sites that never needed the proxy in the first place) gets crammed onto that one node's road, which is both slow and wasteful. That's why the client has a built-in set of rules (commonly known as PAC smart routing) that automatically figures out whether a given site needs the node or can just connect directly, like sorting cars headed to different destinations into separate lanes so they don't get in each other's way. For everyday use, the default smart routing mode is all you need, with no need to study how to write the rules yourself.
Two Common Misunderstandings, Explained With One Example
Once you understand these four concepts, the most common mistake is conflating "node" and "subscription." People often ask "why can't my subscription connect," but a subscription itself can't actually connect to anything — it's just an address used to fetch a list of nodes. What actually establishes the connection is one specific node contained within that subscription. A dead subscription means "this address can no longer fetch an updated node list," while a dead node means "this particular road is blocked" — these are two different levels of the problem, and conflating them turns simple troubleshooting into a mess. Once you're clear on the distinction, you can at least first figure out whether it's a subscription issue or a node issue when something goes wrong, cutting your search space in half instead of digging through every setting the moment something breaks.
It's clearer if you walk through the whole flow at once. Say you've just gotten a subscription address: the client visits that address (the subscription kicks in), gets back a list of nodes (nodes show up in the server list), you pick one and hit connect (the node starts working), the system proxy automatically takes over your browser's traffic (deciding who gets on the road), and PAC smart routing decides which sites should use the node and which should connect directly (assigning lanes). Every step maps to a concept we've already covered, so if something goes wrong at some step, you should now be able to roughly narrow down which part is the problem, instead of blindly trying everything from scratch and clicking through every setting.
This Logic Isn't Unique to v2rayN / v2rayNG
Nodes, subscriptions, system proxy, and routing mode aren't design choices unique to any one client — almost every mainstream proxy tool follows the same architecture, just with different wording and interaction details. In other words, once you understand this logic, you can pick up any other client quickly, without having to relearn the entire workflow from scratch every time you switch software — which is exactly why spending a few minutes on the concepts beats memorizing screenshots.
Once you know that "a node is a road, a subscription is an auto-updating route map, and routing mode assigns lanes," opening the client's interface again, you'll find every menu item maps to a concept you already understand — no more relying on memorized arrows pointing at screenshots. If you'd like to jump straight into the full step-by-step instructions, continue with the complete setup guide, which covers adding nodes, choosing a mode, speed testing, and troubleshooting in detail.