Adding an Extra IP to the Server and Connecting It to a Service

You've rebooted the server and the site won't come up. You run ip a and the extra IP you brought up yesterday with ip addr add has vanished. Or worse: the IP is still there, ping responds, but the browser on that domain gives an SSL_ERROR_NO_CYPHER_OVERLAP or NET::ERR_CERT_COMMON_NAME_INVALID error. These two problems share a common root: an extra IP isn't just an address on the network card, it's an entity that must be registered across several layers.

In this article we'll walk the full path: from bringing up the extra IP persistently, to binding a service to it, to the SSL certificate and email records. The focus is on Linux because almost all web servers live there.

Bring up the extra IP so it survives a reboot

The first thing most people do is this:

ip addr add 203.0.113.45/29 dev eth0

This command works and the IP responds immediately. But it's temporary. With the first reboot or even a restart of the network service, it's wiped and you're back behind the same error. If you're on Ubuntu with netplan, you need to write the block into the YAML file:

network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 203.0.113.44/29
        - 203.0.113.45/29
      routes:
        - to: default
          via: 203.0.113.41

On RHEL, AlmaLinux, and Rocky, you edit /etc/sysconfig/network-scripts/ifcfg-eth0 with IPADDR1=203.0.113.45 and PREFIX1=29. On plain Debian, you repeat the iface eth0 inet static block in /etc/network/interfaces. The differences between distros are real here, and if you guess wrong, you'll lose the server after a reboot; take a look at choosing a Linux server distro before touching the network file.

A point that differs in the datacenter

The extra IP you get from your provider is usually in the same main subnet, so it doesn't need a separate gateway. But if it's a different subnet (for example a separate /29 on another VLAN), you must add a specific route, otherwise packets leave the server and don't come back. The sign is that ping 8.8.8.8 from the server itself responds, but no one from outside can reach the new IP. Check this with tcpdump -i eth0 icmp on the server: if you see incoming packets but no outgoing ones, the problem is routing, not the firewall.

Connecting the extra IP to the web server

Now that the IP is persistent, the service must listen on it. If you have Nginx and the config is set to listen 80;, Nginx listens on all addresses and the extra IP is served automatically. This is the default behavior and is correct for most sites. But when you want the extra IP to serve only one specific site, you must write it explicitly:

server {
    listen 203.0.113.45:443 ssl;
    server_name shop.example.com;
    ssl_certificate /etc/letsencrypt/live/shop.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/shop.example.com/privkey.pem;
}

Apache is a bit different. There you add Listen 203.0.113.45:443 in ports.conf and then reference it in the VirtualHost with <VirtualHost 203.0.113.45:443>. If you drop this line, Apache gives no response on the new IP and you see nothing in the logs, because it never bound to that socket at all. To find out which port and which address each service is sitting on, the reference of common service ports is a good starting point.

This is where they make mistakes

A common error I've seen a lot: the person brings up the extra IP, sets the site on it, everything works, and then a few hours later users report that "the site won't open on mobile but it opens on the company Wi-Fi." The cause is usually that the extra IP isn't opened in the firewall. Run ufw status; if only port 443 is allowed on the main IP, traffic on the new IP is dropped and from the user's point of view it's a silent timeout, not a clear error. The command ufw allow 443/tcp without specifying an address covers all IPs. If you work with raw iptables, see Linux firewall commands for the exact chain syntax.

SSL certificate on the extra IP: where SNI surprises you

This is the point where many people get stuck. An SSL certificate is tied to a domain, not to an IP. So when you get an extra IP, you must make sure the domain's A record points to the new IP and then get the certificate. If you work with Certbot:

certbot certonly --webroot -w /var/www/shop -d shop.example.com

Before issuing, Certbot places a challenge file on the domain and reads it from outside. If DNS still points to the old IP, the challenge fails and you get the Timeout during connect message. Lower the A record's TTL to 300 seconds before starting so it propagates faster.

More importantly: if you serve multiple domains with different certificates on one IP, you depend on SNI. Old clients that don't send SNI see the first certificate on that IP and get a domain name error. The clean solution is for each sensitive domain to have its own dedicated IP. This is where the choice between shared and dedicated IP is real: for ordinary sites a shared IP is enough and has less cost and management, but if you have enterprise customers or provide services like payments and transactional email, choose a dedicated IP. On cloud infrastructure, separating this load is easier; cloud server lets you manage the IP separately from the machine and not reconfigure it again during migration.

Extra IP and email: don't forget the SPF record

If you use the extra IP for sending email, just bringing it up isn't enough. It must be registered in the domain's SPF record, otherwise recipients see your email as forged and it goes to spam:

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.44 ip4:203.0.113.45 -all"

If you use DKIM, the signing key must also be set on the same domain that sends from the new IP. A common mistake: you set the extra IP for sending but don't configure its rDNS. Most providers let you set the PTR from the panel; if you don't, Gmail shows your email with the "this sender is unverified" warning. The PTR must point to the same domain you announce in HELO.

How to make sure everything is set up correctly

Before you say you're done, run this checklist from outside the server, not from on it:

• ping 203.0.113.45 from another machine. If it doesn't respond, the problem is routing or an upstream firewall.
• curl -I --resolve shop.example.com:443:203.0.113.45 https://shop.example.com to make sure the web server responds on that IP.
• openssl s_client -connect 203.0.113.45:443 -servername shop.example.com to see the correct certificate.
• dig +short TXT example.com to verify SPF.

And finally, reboot the server once. Right now, not at night when traffic is low. If the IP doesn't come back after a reboot, it's better to find out now than tomorrow morning when the customer calls. For services that must come up automatically, make sure the relevant unit is enabled; the unit file in systemd explains which part is responsible for dependencies and automatic restart. If the service doesn't come up after a reboot and you can't figure out why, see Linux log file locations to know which file to open.

If you're on shared hosting and need a dedicated IP, this is done from the control panel and doesn't require root access; Linux hosting offers the dedicated IP option in the same panel. But on a dedicated server, all the steps above are your own responsibility.

Frequently asked questions

Why does the extra IP disappear after a reboot?

Because with the ip addr add command it's only registered in kernel memory and written to no configuration file. At boot, the operating system only brings up what's written in netplan, ifcfg, or interfaces. You must add the same IP to the distro's configuration file for it to persist.

Do I need a separate SSL certificate for the extra IP?

No, the certificate is tied to the domain, not the IP. If your domain's A record points to the new IP, the same certificate works. You just need to make sure the web server listens on that IP and the firewall has port 443 open.

How do I know the extra IP is really reachable from outside?

From another server or an online service, ping and then curl that IP. If you get a response from the server itself but not from outside, the problem is almost always routing or the firewall, not the web server configuration.

For email, is just setting the extra IP enough?

No. You must update the SPF record with the new ip4:, set the rDNS from the provider's panel, and if you have DKIM, keep the key on the same sending domain. Without rDNS, most large email services see your message as suspicious.