Most developers start exactly the same way. You spin up a VPS, point your domain to it, and launch your project. For a while, that single IPv4 address does the job just fine.
But as traffic scales and you start stacking more applications on the same machine, relying on a single IP becomes a technical liability. If one application experiences a sudden traffic surge, gets targeted by a DDoS attack, or gets flagged by strict email filters, every other service sharing that address suffers the exact same consequences.
When You DON'T Need Extra IPs
Let's be realistic — not everyone needs to hoard IPv4 addresses. If you just want to host three different WordPress blogs, save your money.
- SNI (Server Name Indication). Modern web servers can host hundreds of SSL-secured sites on a single IP. They just check the domain name in the request header to serve the right certificate.
- Reverse Proxies. Tools like Nginx or HAProxy can take all incoming traffic on one IP and quietly route it internally to different local ports based on the domain.
If you just need organization, use Docker containers or virtual hosts. If you need network-level isolation or reputation management, get the extra IPs.
Why You Actually Need Extra IPs (And Why Ports Aren't Enough)
"Can't I just use different ports?"
Sure, you can run a web server on port 443 and a game server on 25565 on the same IP address. But what happens when a script kiddie hits your game server with a DDoS attack? Your web server gets dragged down with it.
This is the classic "noisy neighbor" problem. Before you start shelling out serious cash for entirely separate dedicated servers just to isolate one or two apps, you can simply split your traffic across multiple IPs on the same machine.
Saving Your Email Deliverability
If you send automated password resets and bulk marketing newsletters from the exact same IP, you are playing a dangerous game. One angry user marking your newsletter as spam can tank your IP's reputation. Suddenly, crucial transactional emails (like purchase receipts) start landing in your customers' junk folders.
By splitting the streams — for example, IP 1 strictly for system notifications and IP 2 for marketing — a blocklist on your marketing IP won't affect your business-critical emails.
Hardening Your Attack Surface
When everything sits on a single IP, your firewall rules are usually a messy compromise. You have to keep port 443 wide open for the internet, but you want your SSH and database ports locked down tightly.
With a multi-IP setup on your VPS, you can physically segregate your public and private attack surfaces.
For example, you can designate IP A as your public-facing web address and IP B as a hidden management gateway. You edit your sshd_config and database configs to only listen on IP B. Then, you set strict firewall rules dropping all traffic to IP B unless it comes directly from your home network or office VPN.
If bots scan your public web IP looking for open database ports, they won't find anything. The services literally aren't listening there.
This also saves your skin during a massive DDoS event. If someone floods your public IP, you can ask your provider to null-route (blackhole) it. The web server goes offline, but because your SSH access is bound to the secondary, untouched IP, you don't lose access to the server. You can still log in, check the logs, and manage the infrastructure instead of being completely locked out of your own machine.
How to Set It Up
Adding IPs requires knowing exactly what your provider handed you. You'll usually get the IP, the subnet mask (like /24 or /32), and sometimes a new gateway.
Before you start typing commands, find out what interface your system is actually using by running ip addr. If you blind-paste configurations for eth0 but your system uses ens3, you're going to knock your server offline.
Configuring on Modern Ubuntu (Netplan)
Most modern Ubuntu setups use Netplan. Don't bother with the old ip addr add terminal command unless you're just testing — it vanishes the second you reboot.
- Check your /etc/netplan/ directory for a .yaml file.
- Open it and add your new IP under the addresses block for your active interface.
It should look something like this:
network:
version: 2
ethernets:
ens3:
addresses:
- 192.0.2.10/24 # Your main IP
- 192.0.2.11/24 # Your new secondary IP
nameservers:
addresses: [8.8.8.8, 1.1.1.1]Test it first with sudo netplan try. If the system doesn't throw an error, lock it in with sudo netplan apply.
Configuring on CentOS / RHEL (nmcli)
If you are on a RedHat-based system, you'll use Network Manager. You can add a secondary IP to your existing connection with one line:
sudo nmcli con mod "System eth0" +ipv4.addresses "192.0.2.11/24"
sudo nmcli con up "System eth0"(Pay close attention to that + sign. Without it, you'll overwrite your main IP and lock yourself out of your own server).
Don't Forget to Bind Your Services
By default, software like Nginx or Apache will greedily listen on 0.0.0.0 (which means every IP attached to the server). To actually get the benefits of isolation, you have to tell your software which IP to use.
In Nginx, update your server block:
server {
listen 192.0.2.11:80;
server_name my-isolated-app.com;
}Verification and rDNS
Never assume your new setup works just because the terminal didn't complain. Ping out from the new interface to make sure the routing is functional: ping -I 192.0.2.11 google.com
Finally, if you are using that new IP for email, go straight to your hosting provider's dashboard and set up your Reverse DNS (PTR record). Major providers like Gmail will instantly drop your emails into the void if your rDNS doesn't match your mail server's domain.
Moving beyond a single IP setup is a massive step toward building mature, professional infrastructure. It takes a few minutes of careful configuration, but the stability it brings to your stack is entirely worth the effort.
Originally published at: https://blog.ishosting.com/en/multiple-ipv4-addresses-on-one-vps