How to choose a server and location

The server is the foundation, and it's where people most often get it wrong before the first command. Let's work through the selection logic: location, host, IP whiteness, spreading across networks. Without it, any perfect config sits on a rotten foundation.

This material covers the engineering of your own network infrastructure and is educational in nature. Complying with the laws of your own jurisdiction is on you.

The main rule of 2026: exit only abroad

Let me start with what defines everything else. Exit nodes — the ones through which client traffic actually flows to the internet — are kept only abroad. Not because it's "freer" there, but because the regulator sends Russian hosts lists of VPN-server IPs and demands blocks. There are already precedents: providers get a subnet and give you a day to remove the service.

Hence the split of roles by geography:

• Exit nodes — abroad. Low-ping-to-Russia locations: Germany, Finland, the Netherlands. Poland also gives good ping and a white exit.
• Panel, bot, relay / cascade entry point — can be in Russia. No client exit traffic flows through them, so there's no abuse risk.

If you put an exit node on a Russian host, the question isn't "will it get blocked" but "when." And on top of that, someone else's traffic will flow through your exit — and the server owner will answer for it.

Different providers and different ASNs

The second rule beginners ignore and then lose the whole fleet overnight: nodes must live in different ASNs (autonomous systems — roughly, different providers and different subnets).

The reason is that blocking is often done not by a single IP but by a whole subnet. If all your nodes are with one host at adjacent addresses, they get wiped out in one move. If they're scattered across different networks, they fall one at a time rather than all at once, and you have time to migrate. It's cheap insurance that will one day save the whole service.

IP whiteness: the silent killer

Here's where half of beginners burn out. They grab a "cheap" IP, layer a perfect Reality on it — and it works every other time. The cause is a dirty subnet: the address has been on blacklists for six months because someone made noise on it before you, or it's a known proxy subnet that filters recognize on sight.

The key thing to understand: IP whiteness is decided before production, not after. You need to check the address before putting it into service:

• not on blacklists, not in a flagged proxy subnet;
• reachable from Russian mobile networks, not just from home internet — mobile operators have stricter inspection, and an IP that pings from home may not work on mobile under an "allowlist."

A true white IP is exactly the one that gets through even mobile "jammers" while also not sitting on blacklists. That's an expensive and valuable resource; you gather them separately and guard them. Sourcing white addresses for the right subnets is a big topic of its own (for this we have a tool called MultiRoller), but remember the principle right away: a dirty IP kills any config.

Resources: how much hardware you actually need

This is where beginners overpay. The requirements are modest:

• Entry/exit node — 1 vCPU and 1–2 GB RAM handle dozens to hundreds of clients. Xray is undemanding.
• Panel — a separate VPS, 1–2 vCPU and 2 GB RAM. Put the panel on 2 GB with headroom: on 1 GB it starts with swap and risks running out of memory.
• Iron rule: panel and nodes go on different machines and different IPs. Never keep the brain and the traffic on one address.

A single node on 1–2 GB serves many clients, so as you grow, the per-client cost falls — you scale not by amount of hardware but by smart distribution.

Hosts: what to look at

A "best top forever" is impossible — the market shifts, and what's alive today is under a block tomorrow. So first, the criteria to choose by yourself:

• For exit — a foreign host whose subnets show up in block lists less often. Niche European providers are often better than mass-market ones precisely because their networks aren't in the spotlight.
• For Russian infrastructure (panel, relay, bot) — a provider with ruble payment and hourly billing, so you can shut down excess without losses.
• Payment and anonymity — wherever possible, crypto or SBP without extra ties to your identity.
• Never your only node with one host. Even a good provider has sudden blocks and outages. Always keep a reserve in a different AS.

And so you don't start from scratch — the ones I've run myself or keep on my radar. This isn't an ad or a forever-top, just a starting point: check they're still relevant and read fresh reviews for your case.

• For exit (abroad): niche Europeans are usually whiter than mass-market ones. I look at Netcup and Contabo (Germany), PQ.hosting (multi-location, takes crypto), Zomro (Netherlands), 4VPS. Big Hetzner has subnets long known to the filters, so I take it for the panel and tests rather than a white exit.
• For the Russian part (panel, relay, bot): Selectel, Timeweb, RuVDS, FirstVDS — rubles, hourly billing, quick start. Beget works fine for light Russian entries.
• Anonymous payment: where possible, crypto; of the above, PQ.hosting and some of the Europeans accept it.

Mixed reviews for a host are normal in this niche. The question isn't "is it perfect" but "do I have a backup if it lets me down."

Hygiene that saves money

A couple of things that aren't about tech but about your wallet:

• Delete unnecessary and stopped VPSes. An idle server keeps ticking on the bill — it's the main silent killer of margin.
• Monitor your hosting balances. Hit zero and the server gets shut down, clients are left without a channel, and you find out from the stream of negativity.
• Secrets — only in a secure place, never in plaintext in a repository.

What's next

Server picked, roles separated, IPs white — you have a foundation. Next in this section is the start checklist: concrete verification steps before you stand up your first server — this time with commands. And after it — installing the panel, which we'll hook this server up to. Remember the main thing: a perfect config on a rotten foundation still falls, so choosing the server isn't a formality but the first real decision.