Routes and load balancing
What a route is in CreateYourVPN, how to create one in a minute, why empty routes are useful, and how the system distributes users across servers.
A route is the bridge between your infrastructure and what the user sees. You manage servers and inbounds, while the user sees a short list of "servers" in their app — and every item in that list is actually a route.
A route = one line in the user's app
A route is a group of inbounds under one name in the client's subscription. The rule is simple:
One non-empty route = one item in the user's server list.
A route can hold a single inbound — or ten of them across different servers. The user never sees this: they pick "🇺🇸 USA", and which specific server they land on is decided by the load balancer — more on that below.
Meanwhile, the name the user sees is the name of the selected inbound: name your inbounds clearly ("🇺🇸 New York", "🇺🇸 Dallas") and that's exactly what the user will see.
When you connect your first server, the system creates a default route on its own and puts the first inbound into it — that's why everything works out of the box without a single setting. Routes come into play when you want more: multiple countries, a dedicated "streaming" route, and so on.
Creating a route
On the cluster page, in the "Routes" section, click "New route". The wizard has three sections:
- How clients see this route — the name (e.g.
🇺🇸 USA) and a flag. This is the route's "signboard". - Load-balancing algorithm — "Least loaded by traffic" (the default) or "Round-robin". The difference is explained below.
- Inbounds in pool — which inbounds belong to the route. This section is optional: you can create an empty route and fill it later by dragging.
An inbound can belong to only one route. If you pick an inbound that's already taken by another route, it moves to the new one. This is how the system guarantees that each entry point's traffic is governed by exactly one set of rules.
The topology diagram: routes at a glance
On the cluster page, routes are shown on a live diagram: servers with their inbounds on the left, route boxes on the right. Inbounds can be dragged with the mouse: grab an inbound, drop it into another route — done. There's also an "Unassigned" zone — drop an inbound there to detach it from all routes.
The route boxes themselves can be rearranged too (using the drag handle or the arrows) — that's purely visual ordering for your convenience.
Empty routes
A route without a single inbound is drawn with a dashed border and has no "pipe" to the distribution node — a hint that users can't see it. Empty routes make handy placeholders: create "🇯🇵 Japan" ahead of time, and when a Japanese server shows up, drag an inbound in — the route comes alive.
The opposite situation gets highlighted as well: if you have inbounds outside of any route, the panel warns you — "inbound(s) aren't in any route — clients can't see them yet".
Load balancing: who lands on which server
When a user requests a connection, for each route the system picks one inbound from the pool — live, based on fresh server metrics (the very ones from lesson 3). There are two algorithms:
"Least loaded by traffic" (default)
The system looks at how much spare bandwidth per user each server has left: it takes the channel capacity, subtracts the current traffic, and divides by the number of connected users. The server with the biggest headroom wins. It's fair balancing "by real load": a weak, saturated server won't get new users, even if it formally has fewer people on it.
The system estimates channel capacity on its own — from the observed peaks of real traffic (a peak gradually "cools down" if the server hasn't been loaded in a while).
"Round-robin"
A simple rule: a new user goes to the server that currently has the fewest people — adjusted by the server's coefficient. The coefficient is a weight: a server with a coefficient of 2.0 is treated as "twice as roomy" and will receive roughly twice as many users as a neighbor with 1.0. This lets you fairly load machines of different sizes.
If some server in the pool doesn't have a capacity estimate yet (say, the server is brand new and hasn't seen any traffic peaks), the route gracefully falls back to round-robin — so decisions are always made on the data that actually exists.
When rebalancing happens
Constantly — and automatically. The server choice is recomputed on every request using fresh metrics: if the load shifts, new users start landing on freer servers. At the same time, the system tries to keep the same pick for a given user when conditions are equal, so their "server" doesn't bounce back and forth.
And one more safety net: servers that monitoring considers unavailable are excluded from the selection — more on that in lesson 7.
Key takeaways
- A route is the "signboard" for a group of inbounds; a non-empty route = a line in the user's app.
- One inbound belongs to one route only. An inbound outside of any route is invisible to clients.
- Empty routes are a perfectly normal placeholder: a dashed box, hidden from users.
- Two algorithms: by spare bandwidth (smart, the default) and round-robin with weights.
- Balancing is live: recomputed on every connection using current metrics.