Frequently Asked Questions

Pick the endpoint with the lowest latency from your location. Our latency test page measures the round-trip time from your browser to every endpoint — run it and choose the one with the smallest number. Generally the geographically closest endpoint wins.

Yes — this is one of the simplest ways to make a local project accessible to anyone. If you're running something on 127.0.0.1:4321 (a dev server, an AI app, a side project), Get Real IP turns that into 134.49.x.x:4321 — a real public address anyone on the internet can reach.

No need to learn Nginx, Docker, cloud platforms, or DNS configuration. Just install WireGuard, paste the config we give you, and your local ports are reachable at your public IP. It takes about 5 minutes.

See the Put Your Localhost on the Internet guide for step-by-step instructions.

Yes. Our concentrators are dual-stack, so if your ISP gives you working IPv6 you can establish the WireGuard tunnel over your IPv6 connection. The endpoint hostname resolves on both IPv6 and IPv4, and WireGuard picks IPv6 automatically when it's available, falling back to IPv4 otherwise.

Connecting over IPv6 is slightly more efficient: your device gets a real end-to-end IPv6 path to the concentrator, avoiding the NAT that the IPv4 transport has to traverse — whether that's your own home NAT or your ISP's CGNAT. Either way your dedicated static IPv4 address works exactly the same; this only affects how the tunnel itself reaches us.

Yes. You can subscribe to multiple IPs on a single tunnel, then route each of those IPs to a different computer on your network. The tunnel runs on one device (often your router or a small always-on box), and traffic for each public IP is forwarded to whichever internal host you assign it to. See the Policy-Based Routing guide for step-by-step setup.

IPv6 makes this even easier. Your tunnel includes a dedicated IPv6 range of 2⁶⁴ addresses — enough for every device you'll ever own. You can configure your home network to hand out addresses from within this range and route them over the tunnel, so multiple computers get their own public IPv6 addresses at the same time without needing a separate subscription for each.

No — and this is by design. We route your static IP directly to your device. We are not a middlebox and we do not filter or inspect your traffic. The entire point is that you get a real public IP with full control over what runs on it.

This means you are responsible for your own firewall. Any port that isn't protected by software on your device (or your router) is reachable from the internet. If you're running services you don't want exposed, make sure they're protected before connecting.

Most operating systems include a built-in firewall:

• Ubuntu / Debian — ufw
• Fedora / RHEL — firewalld
• Windows Defender Firewall
• macOS Firewall
• Router-level: pfSense, OPNsense, and GL.iNet all have built-in firewall/NAT rules

The exception is outbound port 25, which we block by default on our end to prevent abuse by spammers — see the question above.

Yes. By default the tunnel routes all your traffic (inbound and outbound) through your static IP, but if you'd rather keep your normal ISP for browsing and downloads and only use the tunnel for incoming connections, you can. For Linux and macOS we provide ready-made "incoming-only" config downloads — just pick that option when you download your config and it's set up for you, no manual routing required.

Under the hood this uses policy-based routing: packets arriving from the tunnel get marked, and a separate routing table sends replies back the same way, while your normal outbound traffic keeps using your default route. Our Linux and macOS configs handle this automatically. On other platforms or on a router, you set the same rules up yourself.

The reason this is needed: your OS won't automatically send replies back via the tunnel just because the inbound packet arrived that way — without the policy rules, replies leak out your ISP connection with the wrong source IP and the connection breaks. The incoming-only configs (or the guide below) take care of exactly that.

See the Policy-Based Routing guide for step-by-step instructions on Linux (fwmark + ip rule), BSD/pfSense/OPNsense (pf reply-to), and other routers. There's also an advanced section covering multiple IPs routed to different LAN hosts.

Same endpoint location: Yes. If both tunnels are on the same endpoint (e.g. both on turnpike), we can move IPs between them, merge two tunnels into one, or split a tunnel's IPs across new tunnels. Use the contact form to request this and we'll handle it for you.

Different endpoint locations: No. IPs are tied to the subnet of their endpoint location and can't be moved between locations. If you need an IP at a different endpoint, you'll need to create a new tunnel there.

Yes. By default, all our IP reassignment records in ARIN's WHOIS database are marked as a private customer — your name and address are not published. If you'd like your information to appear on the WHOIS record for your IPs, contact us and we'll update it.

This can be useful if you want GeoIP databases to associate your IP with a specific location, or if you're running a business and want your organization name visible on the IP registration. Most residential users prefer the default private record.

First, cancel all your IPs and tunnels from the dashboard using "do not renew." Once your billing period ends and your resources are deactivated, contact us to request full account deletion.

We'll remove your account data from our systems. Payment records may be retained separately for tax and legal compliance.

Use the contact form and select "Feature Request" as the category. Describe what you're trying to do and why it would be useful. We read every submission and use them to prioritize the roadmap.

Some things we've heard interest in: expanded endpoint locations (West Coast, Europe, Asia), a reverse proxy option (like rathole or frp) instead of WireGuard, HTTP/SOCKS proxy access, IPv6 support, managed firewall rules, or API access for programmatic IP management. Even if it's on this list, let us know — the more people ask for something, the sooner it gets built.