Cheap residential boxes are slow and unreliable, and their networks are fragile. The fix is architecture: encrypt into a fast datacenter relay, hand off to the residential exit, and egress on a real home IP — with security and operations that don't lock you out of your own boxes.
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.
The client only ever talks to the relay. The relay forwards over a private hop to the exit, which makes the final connection — so the site sees the exit's home-ISP address, never the datacenter or you.
Your client only ever connects to the relay — a fast, stable datacenter box on a good backbone. It's the single public entry point.
The relay forwards your decrypted traffic over a private hop to a residential exit, which makes the final outbound connection.
The website sees the exit's home-ISP address — never the datacenter, never you.
▲ Why not connect straight to the residential box?
Residential IPs change, sit behind flaky home uplinks, and are often unreachable from the outside (CGNAT, inbound firewalls, provider whitelists). The datacenter relay gives you one stable, always-reachable front door; the residential box only ever has to make outbound connections.
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 proxies the TLS handshake of a real, popular HTTPS site that isn't yours. In config the target is dest (the site whose handshake is borrowed) and serverNames is the SNI your client presents — point both at the same real, unrelated site that stays up. A strong choice matters: weak or suspicious 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.
Give each exit its own port + keypair on the relay, plus a routing rule. Add or remove exits independently — a client picks its exit just by choosing which port to connect to.
✕ Ports are not free
Every new inbound port needs its firewall opened and the tunnel reloaded. Forget the firewall rule and the handshake silently fails with no error. On some networks, non-standard ports draw active probing — prefer ordinary-looking ones.
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.
# a minimal HTTP forward proxy, listening only for the relay
gost -L "http://0.0.0.0:PROXY_PORT"
# if the box exposes more than one egress interface/IP, bind to the one you want
gost -L "http://0.0.0.0:PROXY_PORT?interface=EGRESS_IP"
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.
▲ TCP only
An HTTP forward proxy carries TCP (via CONNECT for HTTPS) — not UDP. QUIC / HTTP-3 won't traverse it, so QUIC-heavy traffic silently fails or falls back to TCP. If you need UDP egress, use a SOCKS5/relay path that supports it, or have clients disable QUIC.
✕ Never leave the proxy open to the world
A no-auth proxy on a public IP will be found and abused within hours. Firewall the proxy port to accept only the relay's IP — nothing else should ever reach it.
ufw allow 22/tcp
ufw allow from RELAY_IP to any port PROXY_PORT proto tcp
ufw --force enable # allow SSH FIRST, or you lock yourself out
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.
▲ Whitelist = free stealth
When the exit only answers a single relay IP, scanners, probes and abuse traffic never even reach it. Fewer open doors than a datacenter box, on a residential line nobody's watching.
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.
✕ Never blindly stop the tunnel service
If your own management traffic rides through the same box, a bare stop can strand the service and cut your session before you can start it again — leaving you locked out until a console rescue. Changing an inbound only needs a brief restart, not a stop.
✓ Apply changes safely
Detached + self-healing. Run restarts detached (so a dropped session can't leave the service half-down), and have the script verify health afterwards and auto-restore the last-good config if the box comes back unhealthy.
Back up before you touch. Snapshot the config/DB before any edit; a one-line restore beats an hour of forensics.
Test the config first. Dry-run/validate the new config before you reload the live one — catch a typo before it takes the tunnel down.
Expect a brief blip. Any tunnel reload drops live connections for a second or two; they reconnect. Do it when you're not mid-session on that exit.
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 — but that has to run from the relay (the only host the exit's firewall admits), or temporarily whitelist your test box first:
# run FROM the relay: prove traffic really exits on the home IP
curl -x http://EXIT_IP:PROXY_PORT https://api.ipify.org
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. Strong SNI, ordinary port, real backbone.
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.
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.
▲ The whole thing, in one line
Fast where you can (datacenter relay), trusted where you must (residential exit), and never build an operation that can sever its own lifeline.