Static IP addresses: when you need one and when you do not

Most servers do not need a dedicated address. They need a stable name, which is a DNS record, and the two get confused constantly. If your players and your users connect by hostname, the address underneath can change without anybody noticing - which is the whole point of having put a name in front of it. There are a handful of genuine cases where an address of your own stops being optional, and they are specific enough to list. Everything else is a line on an invoice.

This post separates the three things people mean when they say "static IP", works through the cases that really do require one, and covers the two problems that send people looking for one in the first place: a home connection whose address keeps changing, and a home connection that has no public address at all.

Static, dedicated and shared are three different things#

These words get used interchangeably and they describe different properties. Keeping them apart removes about half the confusion on its own.

A hosted server normally has an address that is static and public but shared. It will be the same address next month, the internet can reach it, and several other customers' servers answer on the same address on different ports. A home broadband connection is usually dynamic, public and dedicated to you for as long as you hold it - or, increasingly, not public at all.

Once you can say which of the three properties you actually lack, the remedy is usually obvious. Dynamic and you need stability: use DNS. Shared and you need exclusivity: that is the rare case worth paying for. Not public at all: nothing you buy from a hosting company fixes that, because the problem is at your ISP.

What a hostname solves, and what it does not#

A DNS record turns an address into a name, and names are free to change. play.example.com can point at one address today and a different one next week, and the only cost of the change is the TTL - the number of seconds a resolver is allowed to keep the old answer.

This solves the problem people usually bring to a static address:

• Players and users type a name they can remember rather than digits.
• Moving the server is a one-line edit rather than a message to everybody.
• You can run several services on names of their own and move them independently.
• Certificates are issued for names, which is what HTTPS actually requires.

What it does not solve:

• Anything that inspects the address rather than the name. An allow-list at a bank, a licence server, a corporate firewall rule: all of these see an address, and a hostname is not involved in the decision.
• Anything before DNS exists. A device that has to be configured with an address, such as some VPN clients and industrial equipment.
• Caching. A record with a one-hour TTL is stale for an hour after you change it. Lower the TTL a day ahead of a planned change and put it back afterwards. DNS records explained covers the timing, and connecting a domain to a game server is the ten-minute version of setting one up.

The question to ask before buying an address is therefore: does anything in my setup need to know a number, or would a name do? For the overwhelming majority of game servers, websites and applications, a name does.

When a dedicated address is genuinely required#

These are the cases. If you are not in one of them, you are buying reassurance.

Somebody else allow-lists you by address. A payment provider, a partner's API, a customer's corporate firewall, a managed database that only accepts connections from listed sources. Note carefully that this is about your outbound source address, which is not the same thing as the address your server is reached on. On a shared host, outbound traffic usually leaves from a shared address that you do not control and cannot promise will not change. If a contract depends on a fixed source address, that needs to be confirmed explicitly, not assumed.

You need a well-known port that is already in use. Ports are the mechanism that lets several tenants share an address, and that mechanism fails when the port number is not negotiable. Port 25 for inbound mail, port 53 for a public DNS server, port 443 for a protocol that is not HTTP and therefore cannot be routed by SNI. If your service must be on the default port and the default port is taken, you need an address where it is not.

You are sending mail and need the address's reputation and rDNS. Mail servers judge the sending IP, and they check that its reverse DNS matches the name it claims. Setting a PTR record requires control of the address, which you get only with a dedicated one. This is the single most legitimate reason to buy one - and it is worth saying plainly that RE:NODE does not host email, so if this is your case it is not a case for us. SPF, DKIM and DMARC explained covers the rest of the setup.

You are running your own nameservers. Glue records at the registrar are addresses, and they need to be stable.

A licence or an appliance is keyed to an address. Some commercial software ties its licence to an IP, and some hardware VPN configurations are written in addresses rather than names.

That is the list. Notice that none of the entries is "a game server".

When it does not matter#

The cases people ask about most are the ones where a dedicated address changes nothing at all.

A game server reached by hostname. Players type play.example.com:25565 or use an SRV record and never see an address. The connection string already contains a port, so sharing the address with other tenants costs nothing. Game server ports explained covers how the port allocation works and why the query port is part of the same question.

A website behind a reverse proxy. This used to be the strongest argument for a dedicated address, and SNI ended it. Since every browser in use sends the hostname in the TLS handshake, one address serves any number of certificates. A dedicated address for HTTPS in 2026 buys nothing. What a reverse proxy does has the mechanism.

Search rankings. There is no ranking benefit to a dedicated address, and there has not been for well over a decade. Anyone selling one on that basis is selling something else.

"So a neighbour cannot get my address blocked." For email this is a real concern. For a website or a game server it is largely theoretical: blocklists that matter to web traffic act on domains and behaviour, not on shared hosting addresses, and a volumetric attack aimed at a neighbour saturates the link whether the address is shared or not.

Hiding your server's address. A dedicated address is more identifiable, not less. If concealment is the goal, the answer is a proxy in front of the service, and for a UDP game even that is a serious undertaking.

Dynamic addresses at home, and dynamic DNS#

If you host from your own connection, the address you have today is on a lease. It changes when the router reboots, when the line resyncs, or on a schedule some ISPs run for no reason you will ever be told. Everything that was pointing at the old number stops working.

Dynamic DNS is the standard answer: a small client on your network notices the change and updates a DNS record through an API. The record's TTL is set low - 60 seconds is normal - so resolvers pick up the new answer quickly.

# What is my current public address, from two independent sources$ curl -4 https://ifconfig.co203.0.113.42$ dig +short myip.opendns.com @resolver1.opendns.com203.0.113.42# What does my hostname currently resolve to$ dig +short A home.example.com203.0.113.42

Most consumer routers have a DDNS client built in, under a name like Dynamic DNS or DDNS, with providers pre-listed. If yours does not, ddclient or inadyn on the server does the same job, and several DNS providers have a documented update API you can call from a five-line cron script.

What DDNS costs you, honestly:

• A gap at every change. Between the address changing and the record updating, the name points at somebody else's connection. A minute or two is typical; longer if the client only polls every fifteen minutes.
• Sessions do not follow. Players already connected are talking to an address, not a name. When it changes, they all drop and have to rejoin. Nothing about DNS prevents that.
• A stale cache somewhere. A resolver that ignores short TTLs, or a player whose client cached the address, will keep trying the old one.

For a private server for friends this is entirely workable. For anything with players who are not in your Discord, the churn is the reason people stop showing up. Self-hosting a game server at home versus renting weighs the whole trade honestly, including the cases where home hosting wins.

CGNAT: how to tell, and what to do about it#

There is a worse version of the problem, and it is increasingly common: your connection has no public address at all. Carrier-grade NAT shares one public address between many customers, and the "public" address on your router is actually inside the carrier's network. No port forward is possible, because the port is not yours to forward.

Diagnosing it takes thirty seconds. Find the WAN address in your router's status page and compare it with what a site like ifconfig.co reports. If they differ, there is a NAT between you and the internet that you do not control. A WAN address inside 100.64.0.0/10 is the definitive sign - that range is reserved for exactly this purpose. Addresses in 10.0.0.0/8 or 192.168.0.0/16 on the WAN interface mean the same thing.

# The address your router holds, from a machine on the LAN$ ip route get 1.1.1.1$ traceroute -n 1.1.1.1 | head -3

A first hop in 100.64.x.x followed by more carrier hops before anything public is the same finding from the other direction.

Your options, roughly in order of how well they work:

1. Ask the ISP for a public address. Many will provide one on request, sometimes free, sometimes as a small monthly charge or a business tariff. This is the clean fix and it is worth the phone call.
2. Use IPv6. CGNAT is an IPv4 shortage problem and IPv6 does not have it. The catch is that your players need IPv6 too, and many still do not, so an IPv6-only server excludes people silently. IPv6 and game servers covers how far that gets you today.
3. Relay through a machine that does have a public address. A small rented server with a WireGuard tunnel and a port forward will carry game traffic. It works, it adds a hop's worth of latency, and it is a second machine to maintain. Tunnelling services do the same thing for HTTP with less setup and generally will not carry UDP.
4. Rent the server instead. A hosted server has a public address as a matter of course, which is the whole reason this problem does not come up.

Living on a shared address#

If you are on shared hosting, some practical consequences follow and none of them are dramatic.

Your port is your identity. Two servers on one address are told apart by port number, which is why plans state how many allocations they carry and why adding one matters more than the address does.

Outbound traffic may leave from a different address than inbound arrives on. If something needs to allow-list you, test it rather than assuming the address you see in the panel is the one they will see.

Reverse DNS is not yours. dig -x 203.0.113.10 will return whatever the host set, if anything. You cannot change it, which matters for mail and for nothing else most people do.

Neighbours are a smaller problem than the internet suggests. On a properly run host, one container cannot see another's traffic, CPU is throttled to the share bought, and an out-of-memory container is stopped rather than left to drag the machine down. What a shared address genuinely exposes you to is collateral damage from a flood aimed at somebody else, and that is a property of the link rather than the address.

On RE:NODE, each server's address and port are shown on its page in the panel, ports are added and removed on the Network tab with query and RCON included in the count, and every server is its own container with its own hard CPU limit. A dedicated address is not something the catalogue lists, so if your case is one of the genuine ones above, ask first rather than ordering and hoping - the answer may well be that you do not need one, and it may be that we are not the right host for that particular requirement.

Moving, and why the name matters more than the number#

The day you change hosts, or change plans in a way that moves the server, the address changes. Everything that knew the number breaks; everything that knew the name follows a single DNS edit.

The routine:

1. Drop the TTL on the record to 300 seconds a day ahead of the move.
2. Wait out the old TTL so every cache has picked up the short one.
3. Move the data with both servers stopped.
4. Change the record, and leave the old server reachable for a few hours for anyone with a stale answer or a saved address.
5. Put the TTL back up once it is quiet.

Moving a server without losing players has the full version. The one irreversible part is the players who saved a raw address, which is the argument for handing out a name from the first day rather than the day you need it. Subdomains for servers is worth reading if you expect to run more than one.

FAQ#

Do I need a static IP for a game server?

Almost certainly not. Give the server a hostname and hand that out. The address can then change without anyone noticing, and players get something they can remember. A dedicated address adds nothing to a connection that already includes a port number.

What is the difference between a static IP and a dedicated IP?

Static means the address does not change. Dedicated means nobody else is using it. Hosted servers are typically on an address that is static but shared, which covers almost every requirement people have.

How do I know if I am behind CGNAT?

Compare the WAN address in your router's status page with what a public site reports as your address. If they differ, or if the router's WAN address is inside 100.64.0.0/10, you are behind carrier-grade NAT and port forwarding will not work.

Can I use dynamic DNS instead of a static address?

Yes, and for a home server it is the normal answer. A client updates a DNS record whenever the address changes, with a short TTL so it takes effect quickly. Expect a brief gap at each change and a disconnection for anyone currently connected.

Do I need a dedicated IP for an SSL certificate?

No. SNI lets one address serve any number of certificates, and every browser in use supports it. This requirement disappeared years ago and is still repeated on a lot of old pages.

Does a shared address put my server at risk from other customers?

Not in the way people expect. Containers are isolated and CPU is limited per server. The one real shared exposure is a volumetric attack aimed at the link, which affects everyone on it regardless of how the addresses are allocated.