Client balancer (Xray JSON)
The client balancer gives users one entry in the subscription that always works well. When one of the hosts gets weak or goes down, there is nothing to reconfigure: the client measures the latency of every host and keeps traffic on the two best ones. The panel assembles this config automatically, nothing changes on the nodes, and the original hosts are not deleted. While the balancer lives they are hidden from the subscription: dead entries would only confuse users. Removing the balancer brings back both the nodes and the entries.
The entry lives in the script menu: 4. Node extensions → Client balancer.
How it works
Section titled “How it works”The subscription shows one entry with the balancer name, and it has no address of its own: the client connects straight to the hosts inside the balancer.
-
Open 4. Node extensions and pick
Client balancer:Node Extensions 1.Selfsteal node template disguise the node as a regular website 2.Node Plugins extra features for the node 3.SSH access to remote machines saved servers and running commands on them 4.Server routing Russian domains through the bridge to the exit server, the rest directly 5.Client balancer one subscription entry instead of a host list 0.Exit Select action (0-5):5
-
No balancers yet, create the first one:
Client balancer Details in the wiki: https://wiki.egam.es/configuration/client-balancer/ No balancers configured 1.Create a balancer 0.Exit Select action (0-1):1
-
Pick who will use the balancer. The examples below follow Xray JSON, the Mihomo variant is described in the subsection later:
Who will use the balancer? 1.Xray JSON v2rayN, Happ and other full Xray config clients 2.Mihomo Clash Meta, Stash and the like: an auto-picking group in the subscription 0.Exit Select action (0-2):1
-
Pick the preset. The examples below follow “Always the fastest”:
How should the client pick a host? 1.Always the fastest the client measures latency and keeps traffic on the two best hosts 2.Main with backup traffic uses the main hosts, the first backup takes over when they are unreachable 0.Exit Select action (0-2):1
-
When no inbound offers two fitting hosts (the common picture right after add-node, where every node carries a profile of its own), the wizard offers hosts from all inbounds on its own. When fitting inbounds exist, it lists them as in the subsection below. Pick the main hosts, numbers are entered comma separated:
No inbound offers 2 fitting hosts: hosts will be picked across all inbounds and gathered onto a dedicated profile Main hosts: the selection order is kept in the client config 1.Germany (de-1.example.com) — Germany / VLESS 2.Estonia (ee-1.example.com) — Estonia / VLESS Host numbers, comma separated (1-2):1,2
-
The hosts sit on different inbounds, so the wizard offers to gather them onto a dedicated profile. The old profiles and hosts stay exactly as they are and wake up once the balancer is removed:
The picked hosts sit on different inbounds. A dedicated profile will be created for the balancer, the nodes switch to it, and the old profiles and hosts stay exactly as they are: they wake up once a node returns. Removing the balancer sends the nodes home automatically [?] Proceed with a dedicated profile? (y/n): y Creating a dedicated profile Balancer and moving the nodes onto it... Nodes are on profile Balancer, the old profiles are untouched
-
Enter the name. This is what users see in their subscription, Enter picks “Auto”:
Name in the subscription (Enter picks Auto):Germany+Estonia Creating the Xray JSON subscription template: CB balancer Template created Hiding a copy of host Germany... Copy hidden: Germany Hiding a copy of host Estonia... Copy hidden: Estonia Writing the balancer config into the template... Config written Creating the wrapper host Germany+Estonia... Wrapper host ready Hiding the sleeping original hosts... Original hosts hidden: 2. They return to the subscription once the balancer is removed Done: subscriptions of type Xray JSON now show host Germany+Estonia with 2 main hosts inside Regular subscriptions and Xray Checker never see it, that is by design The original hosts sleep hidden from the subscription while their nodes serve the balancer: remove it and both the nodes and the entries come back on their own
When the hosts already share one inbound
Section titled “When the hosts already share one inbound”A balancer needs no dedicated profile when its hosts live on one inbound: it takes the existing one and the nodes are never touched. The wizard lists the fitting inbounds, the “Across inbounds” option gathers the hosts onto a dedicated profile instead:
Every eligible host already sits on one inbound: Germany / VLESS Inbound for the balancer: hosts must live on one inbound, and it must be in the squads of the users who should get the balancer 1.Germany / VLESS — eligible hosts: 3 2.Across inbounds the hosts are gathered onto a dedicated profile the nodes switch to 0.Exit Select action (0-2):1
From there the host picker shows only that inbound, and the dedicated-profile question is never asked.
A balancer for Mihomo
Section titled “A balancer for Mihomo”With Mihomo things are simpler: hosts from any inbound qualify, no dedicated profile and no hidden clones. The wizard adds a ready group into the default Mihomo template, and it appears in the subscription next to the plain host list. The user switches to it once in the client:
Who will use the balancer? 1.Xray JSON v2rayN, Happ and other full Xray config clients 2.Mihomo Clash Meta, Stash and the like: an auto-picking group in the subscription 0.Exit Select action (0-2):2 How should the client pick a host? 1.Always the fastest the client measures latency and keeps traffic on the two best hosts 2.Main with backup traffic uses the main hosts, the first backup takes over when they are unreachable 0.Exit Select action (0-2):1 Main hosts: the selection order is kept in the client config 1.Germany (de-1.example.com) — Germany / VLESS 2.Estonia (ee-1.example.com) — Estonia / VLESS Host numbers, comma separated (1-2):1,2 Name in the subscription (Enter picks Auto):My Mihomo Adding group My Mihomo to the Mihomo template... Done: Mihomo subscriptions now show group My Mihomo The client measures latency itself and keeps traffic on the best host of the group
The presets turn into native Mihomo groups: “Always the fastest” becomes url-test, “Main with backup” becomes fallback with your host order. The group re-probes its hosts every 30 seconds. Adding and removing hosts rebuilds the group, teardown removes it from the template and touches nothing else.
Presets
Section titled “Presets”One pool, every host equal. The balancer spreads connections across the two best hosts by measured latency (leastLoad, expected: 2). Fit for a set of similar servers where any of them is a fine choice.
Two groups. Traffic goes through the main hosts; when all of them are unreachable, the client falls back to the first backup host. Fit for a main line abroad plus one entry that survives regional blocks: the backup sits idle until it is actually needed.
Xray balancers cannot chain into each other (fallbackTag names an outbound), so the fallback is the first host of the backup group. Reorder by removing and re-adding hosts when a different one should be first.
Picking every host as a main is not allowed: the wizard keeps at least one host for the reserve and warns when fewer than two eligible hosts leave no room for two groups.
The client re-probes the pool every 30 seconds, so switching to the reserve fits into one probe. Connections that were already riding the dead host live until their own timeout.
Hosts that already carry a job of their own are never offered to a balancer: VLESS Route hosts of the server routing module (they are personal exits, and the routing module may rewire them) and wrappers of other balancers.
Several balancers
Section titled “Several balancers”There can be as many balancers as you need, each with its own host list, its own Xray JSON template and its own entry in the subscription. Five nodes of Germany gather into a balancer “Germany”, five nodes of Finland into another “Finland”, and the user sees both entries under different names.
With a cross-inbound build each one gets its own profile: the first takes “Balancer”, the second automatically “Balancer 2”, and so on. Tearing one down never touches the other, and wrappers of neighbouring balancers never appear in the host picker, so an accidental duplicate record is impossible.
The module menu lists every balancer at once with its mode. Pick a number and its own menu opens with a live status and five actions:
Client balancer Details in the wiki: https://wiki.egam.es/configuration/client-balancer/ Balancers configured: 2 1.Germany • mode: fastest of the pool 2.Finland • mode: main with backup 3.Create a balancer 0.Exit Select action (0-3):
The balancer and server routing
Section titled “The balancer and server routing”The modules work together because they answer different questions: the balancer on the client picks the entry point, server routing after the entry decides where traffic goes. Russian domains travel through the bridge to the exit server, everything else leaves the entry node directly.
A uniform pool
Section titled “A uniform pool”Build a pool of nodes with the same routing and nothing breaks: the nodes stay on their own profiles with their own rules, and the balancer simply picks the fastest among them. No dedicated profile is even created.
A mixed pool
Section titled “A mixed pool”Do not gather nodes with and without routing “Across inbounds”. The dedicated profile inherits the rules of the first picked host, including the reference to the RU list file, and that file is not mounted on every node: a node without it cannot load the config and drops from the panel. Once the balancer is torn down, the node comes back on its own. Personal VLESS Route exits never join a pool at all: server routing may rewire them, so the module never offers them.
Managing
Section titled “Managing”The per-balancer menu shows a live status and five actions:
Balancer Germany+Estonia Details in the wiki: https://wiki.egam.es/configuration/client-balancer/ hosts: 2 main mode: fastest of the pool wrapper host is in place Xray JSON template is in place 1.Show hosts live list from the panel with a check that nothing is lost 2.Add hosts a hidden copy of each host joins the config 3.Remove a host the hidden copy is deleted, the original stays as is 4.Rename clients will see the new name in the subscription 5.Remove the balancer wrapper, hidden copies and template are deleted, original hosts stay 0.Exit Select action (0-5):
Show hosts checks the stored list against the panel:
Main: Germany (de-1.example.com) Estonia (ee-1.example.com) Every host is in place
Add hosts takes candidates from the balancer’s own inbound. A balancer built on a dedicated profile answers plainly:
No eligible hosts leftA balancer on a real inbound has a list to offer, and every new clone joins the config:
Hosts to add: the selection order is kept in the client config 1.Frankfurt (de-3.example.com) — Germany / VLESS Host numbers, comma separated (1-1):1 Hiding a copy of host Frankfurt... Copy hidden: Frankfurt Refreshing the template config... Writing the balancer config into the template... Config written Hosts added: 1
Remove a host deletes the hidden copy and rebuilds the config. The last backup can go, the last main hosts cannot:
Which host to remove? 1.Germany (de-1.example.com) — Main 2.Estonia (ee-1.example.com) — Main Select action (0-2):1 At least 2 main hosts must stay, tear the whole balancer down instead Host removed, config refreshed
Rename changes the entry name in the subscription:
New name (Enter keeps Germany+Estonia):Europe Host renamed to Europe
Remove the balancer puts everything back: the wrapper, all hidden copies and the template are deleted, the original hosts were never touched. Nodes borrowed by a dedicated profile return home on their own:
[?] Remove balancer Europe? The wrapper host, hidden copies and the template will be deleted, the original hosts stay (y/n): y Tearing down balancer Europe... Returning the nodes to their own profiles... The nodes are back on their profiles Balancer removed, original hosts untouched