Relays through an entry node

A relay is a port on one node, the entry, that passes the encrypted traffic of a server on another node, the exit, on to it unchanged. People whose network blocks the exit's address connect to the entry instead; the entry hands their bytes to the exit, and the exit does everything else. Nothing is decrypted on the way: the session still runs from the person's phone to the exit.

The entry node forwards with the kernel (one nftables table of its own, mistgate_relay, with a DNAT rule per relay), so it costs almost no CPU or memory. It holds no keys of the relayed server.

When it helps#

So a relay is a tool for a block that is by address or by network, not by country, and for an entry that people can reach. The dialog shows three hints before you pick: how the country check sees the exit, whether the entry reaches the exit (known when the TSPU probe runs from that entry), and whether people reach the entry. "No data" means unknown, not fine.

What the entry's country sees#

• It sees: the addresses of the people who connect (home and mobile lines are tied to a person there), the time, the amounts, and the address of the exit.
• It does not see: sites, contents or keys. The session is encrypted from the phone to the exit. The entry's own operator sees only what any operator sees: connections to an address.
• A seized entry yields the table "port → exit address" and whatever the node stores for its own servers. It holds nothing about where people go.

A relay in a country with censorship is under that country's law: its hoster may have to identify you and give access to the server. A relay sees addresses and amounts, not contents. The hoster can also close the server; a relay goes with one click, and nothing on the entry says where people go. This is not legal advice: decide for yourself whether the entry's country is acceptable for you and your users.

How it works#

1. You pick a server of another node and a port on the entry (by default the exit's own port, if it is free on the entry).
2. The panel checks the leg: the entry node tries the exit's server (for TCP the port must answer as Mistgate's own server; for UDP the exit counts the packets it receives).
3. The relay is switched on: the entry's agent installs the forward.
4. The panel checks the path: a third node (never the entry or the exit; the panel itself only when no node can) reaches the exit's server through the entry's port.
5. Only then is the relay Works, and only then does the second server appear in subscriptions. A relay that fails either check is switched off again and the dialog says which stage failed.

Accounting stays on the exit: traffic, quotas, speed limits, devices and torrent protection work per person as before. The exit sees the entry's address instead of the person's. The traffic crosses the entry twice (from people and to the exit), so the entry's own traffic limit and load count both, and the latency is the person to the entry plus the entry to the exit. MTU does not change.

Add a relay#

1. Update the entry node's agent if Updates says so: older agents cannot forward ("Update the node agent to add relays"). The server's firewall must allow forwarded traffic; if it drops it (FORWARD policy DROP, as UFW and Docker set by default) the relay stays down and the card says so.
2. Open the node people cannot reach: Nodes → that node → Ways in → Add a way in…. When the node is dark, the dialog starts: "From Russia, de1 does not open on MTS. Give those people another way in — the node and its keys stay the same."
3. Choose Through another node: "People connect to a node their network sees; it passes their traffic to de1 unchanged." The best choice is hinted ("Good fit: msk1, seen from MTS"). IPv6 entry is greyed out for now, with the reason.
4. Pick the entry (Through which node). Good fits: seen from MTS come first, then Other nodes; each shows its country code, whether people see it and, where the TSPU probe runs from it, whether it reaches de1. A node that already passes servers of de1 says "Already passes on 2 servers of de1".
5. Tick the servers to relay. Each has a port on the entry (auto is the exit's port if free, else a free one). A server that cannot be relayed is grey with the reason.
6. Check and turn on runs both checks and switches the relay on. Only check runs the leg and adds the relay switched off; turn it on with Turn on in its row within 15 minutes, or check again (switching on needs a leg check that passed less than 15 minutes ago). The dialog shows the progress and the result per server; Back returns to the choice of the node.
7. The row shows Works, checked 3 min ago, or Not turned on with the stage: leg (the entry cannot reach the exit's server: a block, a route, the exit's firewall), path (the port on the entry is not reachable from outside: the entry's firewall or hoster, or FORWARD dropped). Check now repeats the checks; Turn off and Remove stop the forward on the entry.

You can start from the entry as well: the entry node → Ways in → the group Reached through msk1 → Relay another node…. It is the same dialog, with the servers of every node instead of one.

On the exit node, each relay is a lane Through msk1 on the Ways in tab; on the entry node it is a row in the group Reached through msk1 ("→ DE de1"). Removing a profile from a node, or retiring a node, also removes the relays that depend on it; the dialog says how many.

Supervision#

Every relay that is on joins the client-eye check rounds as a target of its own: the panel connects through the entry's forwarded port with the exit's profile and credentials, as an app would, and reads 64 KB through it, so a transfer that starts and then stops counts as a freeze.

• The relay row shows the last round: "Through the relay: works, 182 ms, 4 min ago", or the stage that failed.
• It also shows the bytes and packets that went through the forward since the entry's agent installed it, and when the agent read them. Older agents without counters show nothing.
• After two failed rounds in a row a relay_down alert opens on Health: "Relay de1 via msk1 is down". It names the stage in words: leg, the entry does not reach the exit; entry, the forward on the entry is not installed; path, nothing comes through from outside through the entry; freeze, the transfer stalls after the first kilobytes. The alert's Open the way in button opens the exit node's Ways in tab on that lane.
• The alert gives way while the exit's own check alert or a node_down of either node is open, and closes when the relay works again. Telegram sends it too.

The panel's own checks run from the panel's server, outside the entry's country, so they catch a broken leg or a stall on the panel's path, not a freeze that the TSPU applies to people inside the country; for that, look at the bsbord and kl!ck reports on Reachability.

The second server in subscriptions#

For each relay that works, a person gets a twin of the exit's server right after it in their subscription: the same keys, SNI and certificate pin, with the entry's address and the relay's port. Its name ends with the entry's country code: 🇩🇪 DE · VLESS · via RU (in a Russian subscription через RU, in a Chinese one 经 RU), cut to fit Happ's 30-character limit. It appears in every format (link list, Mihomo YAML, Xray JSON, sing-box JSON); in a Mihomo group it is one more entry of the same selector.

• Who gets it: everyone who may use the exit's server and may use the entry node. There is no new setting; restrict it with the person's node choice.
• When: at the subscription's next refresh (12 hours by default). A relay that is off or failed has no twin.
• What people see: a second server to pick when the first does not connect. Nothing changes for the servers they already use.

What it cannot pass on#

A relay works over IPv4 only: the entry's forward uses IPv4 on both sides.

With MCP#

Admin tokens read and manage relays: relays_list, relay_candidates and relay_check read and test, relay_plan / relay_apply make, switch, move and delete (always with the owner's approval). Nothing shows a node's address. See MCP.