NAT or your own IPv4: what one forwarded port can and can't do

Most people discover what NAT means about ten minutes after they buy it. Nginx starts fine, curl localhost returns the page, and then the browser on their laptop just spins. Nothing is broken. The server simply has no public IPv4 of its own, and the only inbound door it has is a single forwarded port for SSH.

That one door turns out to be enough for a surprising amount of work, and nowhere near enough for some very common things. If you're still choosing between the two kinds of plan, our older piece Dedicated IP or NAT VPS asks the one question that settles it. This article is about living with the answer: what a NAT server can do in practice, where it hits a wall, and how to get out when you outgrow it.

What you actually get

A NAT server has a private address behind our gateway. The dashboard shows you a host and a personal port, and you connect like this:

ssh -p 20123 root@host

That port is mapped to port 22 inside your server. Every other inbound port on IPv4 is closed from the outside, and there's no option to forward more. Outbound is a different story: the server can reach anything on the internet, apart from the SMTP ports 25 and 465, which are closed on every plan, NAT or not. The full rules are in Network & ports.

One more detail that matters for some people: the outbound address isn't your own. Traffic leaves through an address you don't control, so you can't set reverse DNS for it and you can't build a sender reputation on it.

What runs fine behind one port

Anything that starts the conversation itself. That's a bigger category than it sounds:

• Bots that poll. A Telegram bot on long polling, a Discord bot on its gateway connection, a trading bot talking to an exchange API. All outbound.
• AI agents. An agent that calls model APIs, browses, writes files and runs code doesn't need anyone to call it. It needs CPU, memory and a connection out.
• Workers and scrapers. Anything pulling jobs from a queue, crawling pages or syncing data on a schedule.
• Build boxes and runners. CI runners usually register with the server and pull work, so they're happy on NAT.

For this kind of load the cheapest plan is honestly fine. Nano is $3 a month for 2 vCPU, 1 GB of RAM and 15 GB of disk; Small is $8 for 4 vCPU, 4 GB and 35 GB. There's a whole page about NAT plans if you want the full list.

Where one port isn't enough

The wall is anything where someone else has to start the connection.

A website is the obvious one. Browsers connect to port 443 (and 80 for the redirect), and on a NAT plan those ports don't exist from the outside. You can't run it on a non-standard port either, at least not in any way visitors will accept.

Your own domain with HTTPS runs into the same wall twice. You can point a DNS record at the gateway's address, but nothing arriving there is forwarded to your server except your SSH port. And the usual way to get a free certificate checks your server on port 80 or 443.

Webhooks fail quietly. Payment notifications, a bot platform pushing updates, a Git server announcing a new commit: they all need to reach you. The bot that worked fine on long polling stops working the moment you switch it to webhooks.

VPN endpoints, game servers and mail servers need inbound ports by definition. So does anything you'd like a colleague to open in a browser.

The workarounds, honestly

IPv6. New Linux servers get a public IPv6 address, and on NAT plans it reaches the server directly on any port. If every client of your service is yours (your laptop, your other servers, a monitoring probe with IPv6), this works well. For a public website it doesn't: a share of visitors still sit on networks without IPv6 and will simply never load the page. Windows plans are IPv4-only for now.

A tunnel. You can run a small agent that holds an outbound connection to a relay somewhere else, which forwards public traffic back down the tunnel. It works, and for a demo or an internal dashboard it's reasonable. For anything that matters you've added a third party in the middle of every request, plus another thing that can break at 3 a.m.

An SSH tunnel for yourself. If the only person who needs the admin panel is you, don't expose it at all. Forward it over the SSH port you already have:

ssh -p 20123 -L 8080:localhost:8080 root@host

Then open http://localhost:8080 on your machine. It's the most underrated trick on a NAT server, and it's more secure than putting the panel on the internet anyway.

My honest take: IPv6 and SSH tunnels are good tools. A permanent public service routed through a tunnel because the server has no IPv4 is usually a sign you've outgrown NAT.

Moving to your own IPv4 without reinstalling

You don't have to rebuild anything. Open the server in the dashboard, choose Upgrade plan and pick a dedicated-IP plan of the same size or bigger. The server reboots once and comes back with its own public IPv4, its disk and everything you installed. Ports 80, 443 and whatever else you open in your firewall become reachable, and SSH moves to the normal port 22. The details are in Changing your plan.

A few things are worth knowing before you click:

• You pay the pro-rated difference for the rest of the current period, from your balance. Nano-IP is $8 a month against $3 for Nano; Small-IP is $16 against $8.
• It needs a free address in your server's location. If there isn't one right now, the dashboard says so before anything is charged.
• If you hand-edited the network configuration inside the server, check it after the reboot. On a stock image it's applied for you.
• Take a backup first. It's one reboot, but it's still your data.

Where NAT doesn't fit, and where IPv4 doesn't either

NAT is the wrong choice for anything public-facing, for anything that receives webhooks, and for anything that needs a fixed address someone else allowlists. Don't spend days engineering around that. The price gap between Nano and Nano-IP is $5 a month.

But a dedicated IPv4 isn't magic either. It won't make a website that blocks data-centre addresses let you in, and it won't fix a scraper that gets rate-limited, because those decisions are about the network you're in, not about who else uses the address. And if your whole project is a few bots and an agent, buying an IPv4 you'll never accept a connection on is money for nothing.

If you're planning the move to a bigger setup anyway, moving a VPS without downtime covers the order of operations, and how to read VPS specs helps when you compare plans.