Self-hosting a static IP on a VPS: the tradeoffs

Renting a VPS and running WireGuard to your home server is a common way to get a reachable public IP behind CGNAT. It works. The things worth weighing before you build it are the tradeoffs in how traffic gets forwarded — because the default, easy configuration quietly gives up something most self-hosters care about.

You lose your visitors' real IP addresses

This is the tradeoff that catches people. To get replies flowing back correctly over the tunnel, the simplest configuration uses SNAT (masquerade) on the VPS. SNAT rewrites the source address of every inbound packet to the tunnel's internal IP — so from your home services' point of view,every request looks like it came from the same internal address.

That breaks a lot of things you rely on:

• fail2ban and abuse blocking — you can no longer ban an offending IP, because every request shares one source.
• Per-IP rate limiting — one abusive client looks identical to all legitimate ones.
• Access logs and analytics — every log line shows the tunnel IP, not the real client.
• Geolocation and allowlists — source-based rules stop working.

You can preserve real client IPs, but it means avoiding SNAT and instead doing policy-based routing on the home side: mark the tunnel's inbound packets and add anip rule that sends their replies back through a dedicated route table. It works, but it's more moving parts to set up correctly and keep working across reboots and config changes.

The return-path problem

Underneath that is the core routing issue. Inbound traffic to the VPS public IP has to be DNAT'd down the tunnel to your home host — and the reply has to go back over the tunnel, not out your home ISP link. Left alone, the home host answers via its normal default route and the connection silently fails (asymmetric routing). Every working DIY setup solves this one of two ways: SNAT on the VPS (easy, loses client IPs) or policy-based routing at home (keeps them, more involved). There isn't a free lunch — you're picking which cost to pay.

Reverse proxy: simpler, but HTTP only

Running a reverse proxy (Caddy, Traefik, nginx) on the VPS avoids the L3 routing entirely for web traffic — it terminates HTTPS on the VPS and forwards to your service, and it can pass the client IP in a header. The ceiling is protocol: it carries HTTP and HTTPS only. Email, game servers, SSH on arbitrary ports, VoIP, and raw TCP/UDP don't fit, and TLS terminates on the VPS instead of your own machine.

Ongoing ownership

A self-managed VPS is a server you keep running: OS and WireGuard updates, firewall and security, monitoring, and re-fixing the routing when something changes. That maintenance is a recurring cost on top of the monthly fee. (One minor note: cloud VPS IPs sometimes carry a datacenter reputation that can affect deliverability for some use cases like email — worth checking for your provider and use case.)

The managed alternative

Get Real IP routes a dedicated public IPv4 to your server, router, or laptop over an outbound WireGuard tunnel (so it works behind CGNAT), with the routing handled for you:

• Real client IPs preserved — no SNAT flattening every visitor to one address.
• Any protocol, any port — HTTP/S, email, game servers, SSH, VoIP, raw TCP/UDP.
• Your server terminates TLS — traffic isn't decrypted by an intermediary; encryption to your services stays yours.
• Reverse DNS (PTR) control for the IP.
• Compatible with your own domain name (optional) — point an A record at the fixed IP to use your own hostname.
• No server to maintain — no OS, WireGuard, or routing to keep working.

Quick comparison

The DIY route trades money for time and control: you run the server and choose which routing tradeoff to accept. Get Real IP handles the routing — preserving client IPs, carrying any protocol, with no server to maintain.