Emergency access: when the network blocks everything
Emergency access (OLCRTC) in CreateYourVPN: a backup channel disguised as a video call for allow-list networks — what it costs your servers, what turns on automatically with Pro, and what to tell your users in advance.
Everything so far assumed one thing: that the network still lets your servers through. A route picks a server, an inbound makes the connection look like an ordinary HTTPS visit, multihop stretches the path across countries — all of it needs traffic to leave the device at all.
Sometimes it doesn't. A network switches to an allow-list: a short list of approved services works, and everything else — your VPN included — simply doesn't get through. Emergency access (OLCRTC) is built for exactly those hours.
What it is — and what it isn't
Emergency access is a backup channel, not a second protocol. The normal connection stays exactly what it was: VLESS + Reality on your own servers. Emergency access reuses those same servers, but wraps the traffic inside a video call on a service the restricted network still permits — from the outside it looks like an ordinary video conference.
Three consequences follow, and all three are worth knowing before you promise anything:
- The user starts it by hand, only when nothing else works. There is no automatic failover: the normal connection doesn't quietly "switch over".
- It is slow. About 14 Mbit/s down, under 1 Mbit/s up, 175–235 ms latency. Comfortable for reading and video, useless for uploads, video calls and gaming.
- It is temporary. A session lives up to 12 hours and then stops on its own; one session per user at a time; to continue, the user starts a fresh one.
The feature is experimental. It depends on an external video service being reachable from the restricted network, so it does not work in every country or on every network. Present it to your users as insurance against hard blocks — not as a guaranteed capability.
How it looks from the user's side
- They create a fresh video call in a supported service — Yandex Telemost, WB Stream or Jitsi Meet.
- They hand over its link: pasted into the Emergency access block in their cabinet, or emailed to a personal request address. Both paths do the same thing — and the email one keeps working when your storefront itself is blocked.
- One of your servers joins that call as a guest. About a minute later they get a connection link starting with
olcrtc://and a QR code. - They import it into olcbox, the emergency client, and connect.
Both things the user needs — the client app and the request address — have to be in place before the block. Under an allow-list, app stores and download pages are usually unreachable, and the cabinet page where the address is shown may be gone too. A user who learns about emergency access during the block has already missed it.
Emergency access
The page for your users: how it works, which services are supported, what to do during a block.
Installing the emergency client
Where to download olcbox for Android, iPhone, Windows, macOS and Linux — and why to do it in advance.
What it takes on your side
- A Pro subscription — €0.99 per month. That's the tier emergency access comes with; Max has it too, along with everything else (lesson 13).
- An emergency route. The servers of routes marked as emergency form the pool that sessions land on. On your first subscription the system marks one for you — the route with the most working inbounds — and raises the cluster switch along with it.
- Servers. They take part by default, and the runtime installs and updates itself in the background: nothing to install over SSH.
So in the common case there is nothing to set up: you subscribe, and emergency access is on. The manual controls exist for when you want them — which routes make up the pool, the session cap per server, and switching a specific server out.
How it differs from a normal route
- The user doesn't pick a country. They never see the pool — you express the geo intent by choosing which routes to mark as emergency. Mark several and the pool merges them: if one has no suitable server, the session goes to another.
- Multihop routes don't take part. Emergency sessions only use direct routes.
- A session costs real CPU. Packing traffic into a video stream measured at about 15% of one core and 31 MB of RAM (on a ~5 Mbit/s video session) — far more than one more VPN user. A rough ceiling is 3 sessions per core: 3 on a single-core box, 6–7 on two cores, 12–14 on four.
Max concurrent sessions left empty means no limit. On a weak server that is a trap: emergency sessions will eat the CPU your regular users are paying for. On single-core machines set the number explicitly.
Which of your users can actually use it
The requirements are stricter than they look, and this is where support questions come from:
- A verified email. Users you created by hand without an email address cannot request access at all.
- An active account. Paused, expired, traffic-limit-exhausted and awaiting-first-payment accounts (everyone who signed up themselves and hasn't paid yet) are rejected.
The complaint you'll hear is "I asked and nothing happened". Start with the account status and the call link they used; for the email path, check that they sent it from their account address with only the link in the message.
Remember
- Emergency access is a lifeline for allow-list networks, not a second protocol and not a replacement for the normal connection.
- The traffic runs over your own servers, disguised as a video call the user creates themselves.
- Slow, up to 12 hours, one session per user, started manually.
- With Pro it turns itself on: a route gets marked as emergency, the cluster switch goes up, servers take part by default.
- One session ≈ 15% of a CPU core — set an explicit capacity on weak servers.
- Users need a verified email, an active account, and the client installed in advance.
Next
Emergency access is what happens when the network breaks. The next lesson is about the other half — how the system notices when your servers break.