Proxies

Bring your own exits. Umbra tests them, assigns one per Account, and rotates them on your rules.

What it's for

Umbra doesn't sell exits. You bring your own pool of proxies; Umbra tests each one, hands a single exit to each Account, and rotates them only on the rules you set. The result is that every Account browses from its own place, and no two Accounts share an IP by accident.

Come here when you first set up, when you add capacity before a drop, or when one Account's exit goes bad mid-week.

The Connections page: a result strip above a table of exits with host, port, credentials, country, ISP and speed.
The Connections page. One exit failed its last test — see Health, below.shot-proxies · Connections page: result strip reading All 4 · Good 2 · Slow 1 · Failed 1 with a '1 needs attention' chip and the Target chip; the table below listing gw.iproyal.com:12323 (142 ms), uk2.brightdata.io:22225 (working · 9d), res.webshare.io:9021 (failed)

Add your proxies

Add or paste your exits

Add one exit at a time, or paste a block in host:port:user:pass form. A proxy's password never crosses into a browser Session — the stored record only carries whether a password is set, not the secret itself.

Group them (optional)

Tag exits into groups — by provider, region, or the job they're for — so you can assign and rotate a whole group at once. To re-organise in bulk, tick the exits and use Move to group in the selection bar: it changes the group and nothing else — test results, region readings and credentials all stay exactly as they were.

When anything on the page needs a human — failed, blocklisted, or tested too long ago — a needs attention chip appears in the result strip with the count. Press it and the table shows exactly those exits; fix or re-test them and the chip retires itself.

Test them

Run a test (next section). Until an exit is tested, Umbra knows nothing about where it comes out.

Don't reuse a burned exit

An exit that browsed for an account carries that account's history with the site. Delete a banned Account, scroll the list, and hand its old exit to a fresh Account, and you've given the new one a head start on the same fate — a reused exit tends to burn faster.

So Umbra remembers every exit that has ever been attached to an Account, and keeps that memory even after you delete the Account. A used exit is marked in red everywhere you can pick a proxy — the Account's own picker, the per-Session picker in the address bar, and the Connections list — so the warning is in front of you at the moment you choose, not after. The mark never says which Account held it; it only says this one has been used.

To see the history — which Account names an exit carried and when, so you can rebuild one you've lost from the record — open the exit and read Previously attached to.

Test before you trust

Testing an exit does two jobs at once. It confirms the exit actually answers, and it reads back where that exit comes out — its country, city and time zone. Those readings are what Umbra later copies onto any Account you place behind the exit, so its clock and locale match the place it appears to browse from.

Prove it doesn't leak

Testing confirms an exit answers. Verify goes further: it opens a throwaway session routed through that exit and runs a WebRTC leak check on it — the same class of leak that can surface your real address around a proxy. Umbra never runs this check on a direct connection; if the exit can't be routed, the verify refuses rather than probing your real network.

No leak seen
Every address WebRTC surfaced matched the tested exit. Nothing pointed back at you.
Not probed
The exit answered, but the leak probe couldn't run — so nothing is proven either way. Test again and re-verify.
Couldn't confirm
WebRTC surfaced a public address that isn't your real one but isn't the tested exit either. A rotating exit does this; re-test and verify again to confirm.
Leaking
WebRTC surfaced your real or LAN address. Sessions on this exit can be deanonymised — replace it before a drop.

Health at a glance

The Speed cell prints the last reading, and the result strip above the table sorts every exit into Good, Slow, Failed, Blocked or Not tested — click one to show only those. The state decides whether an exit can be handed to an Account.

A figure, e.g. `142 ms`
Answered its last test, and that is how long it took. Its region readings — country, city, time zone — are current and usable for alignment. Once the test is more than a week old the cell carries its age (142 ms · 9d) — "142 ms, as of nine days ago" is a different fact from "142 ms", and the difference matters most right before a drop. Re-test to clear it. An exit that answered without a usable figure reads working instead, with the same ageing.
never tested
Added but never tested. It can still be assigned, but nothing is known about where it comes out or whether it answers.
failed
Failed its last test. Its region readings are cleared, and it is excluded from every assignment. (Elsewhere in the app — on an Account carrying one — the same exit shows as a Dead exit chip.)
blocked
Found on a public blocklist. Excluded from assignment, for the same reason as a failed one.

Assigning and rotating exits

Umbra spreads your pool evenly — one exit per Account — and rotates on the trigger you choose: on launch, on a timer, or when a health check finds an exit has died. A Session that's holding a live cart is never rotated out from under you.

What "eligible" really means

Every place that picks an exit — first assignment, rotation, de-link, and bulk distribute — runs the same eligibility rule. That one shared rule is why a dead or blocklisted exit is never handed out anywhere.

If a bulk distribute can't cover every Account, it doesn't force a bad assignment — it leaves the uncovered Accounts exactly as they were and tells you the shortfall. Read that banner: an Account it couldn't cover keeps whatever exit it had, including none at all.