How to build a VPS network

01The architecture

One idea does all the work: separate the fast part from the trusted part. Datacenter boxes are fast but their IPs are flagged as hosting. Residential boxes have trusted IPs but weak everything else. So you chain them.

02The entry relay

The relay terminates an encrypted tunnel and routes each inbound to the right exit. The current best-in-class approach for blending in is Reality — a TLS-camouflage layer (used with VLESS, usually plus the Vision flow) that borrows a real third-party site's TLS handshake, so there's no certificate or fingerprint of your own to detect.

Reality, briefly

• Vision flow (xtls-rprx-vision) — reduces the "TLS-in-TLS" tell that naive proxies leak.
• Borrowed handshake — Reality mimics the TLS handshake of a real, popular HTTPS site that isn't yours: dest is that site, serverNames the matching SNI your client presents — point both at the same real, unrelated site that stays up. The choice matters: weak or obscure ones get probed and blocked faster on hostile networks.
• One inbound per exit — give each exit its own port + keypair on the relay, and a routing rule sending that inbound's traffic to that exit. Clean, and you can add/remove exits independently.

03The residential exit

The exit's only job is to receive traffic from the relay and make the outbound connection from its home IP. Keep it dead simple: a single lightweight forward proxy such as gost, listening only for the relay. If the box exposes more than one egress IP, bind the proxy to the one you want.

A single-process proxy like gost multiplexes connections and won't fall over under the pool of idle tunnels a relay holds open — unlike fork-per-connection proxies, which starve their worker pool and hang. Run it under a supervisor that restarts on failure.

The deploy skill has the exact commands — the gost proxy unit and the lockout-safe firewall sequence (allow SSH, allow only the relay to the proxy port, enable, then prove a fresh login still works).

04Security

• Key-only SSH. Disable password auth everywhere. Residential images often ship with it on — turn it off after your key works.
• Least-exposure firewall. The exit exposes only SSH (to you) and the proxy port (to the relay). The relay exposes only its tunnel ports. Nothing else.
• Provider IP-whitelist modes. Some residential providers offer a firewall mode that admits only whitelisted source IPs — everything else is dropped at their edge. If yours does, whitelist just your relay. It's a strong second layer: the box becomes invisible to everyone but your own infrastructure.
• Rotate anything exposed. Emailed root passwords, any key that ever touched a chat or screenshot — rotate them. Treat the residential box as semi-trusted.

05Operations — don't lock yourself out

The failure mode that bites everyone: the box carries both your VPN and the path you manage it through. Break one, break both.

Verify from a clean vantage. Don't trust ping/nc from a machine behind its own tunnel or fake-IP proxy — they can report success that isn't real; run those from a neutral box. To prove the egress IP, curl through the proxy from the relay (the only host the exit's firewall admits) — if it returns the exit's home IP, the chain works. The deploy skill runs this egress check for you.

06Hard-won lessons

• Non-443 + weak SNI gets probed. On hostile networks, a fresh IP running a tunnel on an odd port with a flimsy borrowed SNI draws active probing and gets blocked — and piling many odd ports onto one IP only compounds the exposure. Strong SNI, ordinary 443, real backbone; keep the port surface small.
• Keep a second front door. Even done right, an entry IP can eventually be blocked — the address gets flagged, not your config, and no amount of tuning brings it back. Stand up a second entry relay on a different IP, provider and region, pointed at the same exit, so a block means switching lanes instead of going dark. One exit, several ways in.
• Don't tunnel TCP inside TCP on internal hops. If a relay-to-exit (or relay-to-transit) hop is carried over an SSH/TCP tunnel, your app's TCP rides inside the tunnel's TCP. Under load it melts down: one bulk upload head-of-line-blocks every other flow, and a small request that idles at ~0.7 s balloons to 2–5 s. Carry internal hops over a UDP transport (WireGuard) instead — each flow stays independent, so a big transfer no longer freezes your interactive traffic. On a lossy high-latency leg it also matters which congestion control the sender runs: loss-based CUBIC collapses on a few dropped packets and never recovers; switch every sender on that leg to BBR.
• Stealth belongs only on the border hop. The camouflage layer (Reality) is what lets you cross a censored border undetected — but it's only needed on the one hop that actually crosses it (client → entry relay). The internal hops that stay inside the destination country are never inspected, so run the fastest transport there (WireGuard), not the stealthiest. Encryption ≠ stealth: WireGuard is fully encrypted, it's just recognizable, which is fine where nobody's looking. Match the tool to the threat per hop.
• The ~2,000-IOPS cap is real. Budget residential tiers often throttle disk hard. Fine for a proxy (it barely touches disk) — just don't expect to run anything I/O-heavy on the exit.
• "vCPU" and "dedicated" aren't what they sound like — benchmark them. A cloud vCPU is a hardware thread, not a whole physical core (true across every major cloud), and "Dedicated CPU" means your threads aren't shared with other tenants — not that you get whole cores. So "2 dedicated vCPU" can be two hyperthreads on one physical core: load both at once and each collapses to roughly half, delivering ~1.1 cores of real work instead of 2. We measured exactly this — a "2 vCPU" box whose two cores together lost to another provider's single core, at a higher price — and a clean 0% steal never gave it away (steal only exposes other tenants stealing your time, not your own two vCPUs sharing one core). The only way to know real capacity: pin one CPU-bound process per core simultaneously (taskset -c) and check whether aggregate throughput actually doubles. If it barely moves, your "cores" share silicon — trust the measurement, not the spec sheet.
• Your speed test picks a server that flatters you — test off-net, and never once. A speed test geolocates by your exit IP and hands you the nearest server, which is very often a box run by the exit's own ISP. That measures a short, well-peered, uncongested path the rest of the internet does not get. We caught it costing 34 Mbit/s: one line read 115 Mbit/s against its exit ISP's own server and 81 against an independent server in the same city, with latency essentially unchanged (221→225 ms). Unchanged RTT plus collapsed throughput is the fingerprint of a bad exit→server leg, not a congested backbone. A second line, tested the same way, held ~100 on both — so the effect is per-exit, not universal, and you cannot predict which of your boxes has it. Practical rule: use the “Change Server” button, take the off-net figure as your working number, and treat the on-net one as a best case. Any single run is a rumour.
• Your speed test can be the bottleneck — size it to the pipe. A single TCP flow can only run at window ÷ RTT. On a 200 ms intercontinental path at 100 Mbit/s that means ~2.5 MB must be in flight before the connection ever reaches full speed — so a test that tops out at a 10 MB transfer spends most of it ramping and reports a fraction of the truth. We published 26–60 Mbit/s for lines that a parallel-stream test then clocked at 81–115, with nothing on the network changed. Two rules follow. Compute the bandwidth-delay product first (rate × RTT), then use parallel streams, or a transfer ≥10× BDP. And sanity-check the tool against a link with a known hard cap — ours cheerfully reported 8.1 Mbit/s on a line contractually capped at 8, which was the tell sitting in plain sight. The error even flips direction with BDP: single-stream tools read low on fat, far pipes and a little high on thin ones. Two corollaries: never pair a number from one tool with a number from another and call it a before/after — re-run the old tool the same day; and remember a multi-stream headline is not single-flow application throughput, so one git clone over that path will still crawl.
• One test file, not the device. Benchmark disks against a temp file, never a raw block device. And deprioritize benchmarks (nice/ionice) so they don't starve a live service.
• Watch your shell. Automation quirk that eats hours: some shells don't word-split unquoted variables (zsh), so a host list in a loop silently becomes one giant argument. Use explicit lists.
• Keep exits separate. Don't route your own management traffic through the very exit you're modifying. Keep a clean path in reserve.