A Sysadmin’s Guide to Setting Static IP in Linux

When you're setting a static IP in Linux, you're essentially editing a network configuration file. The exact file depends on your distribution—it could be in /etc/netplan/ on modern Ubuntu systems or lurking in /etc/sysconfig/network-scripts/ on an older CentOS box. The goal is the same: give your server a permanent, predictable address.

While dynamic IPs are perfectly fine for your desktop at home, they introduce a level of chaos that's unacceptable for servers needing constant, reliable availability.

Why a Static IP Is Non-Negotiable for Your Linux Servers

Before we even touch a single command, let's get one thing straight: a static IP is the bedrock of any serious server infrastructure. In a professional setting, predictability is king. When your web servers, databases, or internal apps need to talk to each other, they depend on having a fixed address to connect to. A dynamic IP, handed out by a DHCP server, can vanish and change after a reboot or when its lease expires.

Just imagine your company's critical application, running on a high-performance ARPHost bare metal server, suddenly going offline. Or picture your entire team getting locked out of a shared database because its IP address changed overnight. These aren't just minor inconveniences; they create downtime, grind operations to a halt, and can lead to very real financial losses.

The Business Case for Static IPs

Setting a static IP is far more than just a technical chore; it's a fundamental business practice that directly reinforces reliability and security. Here’s a breakdown of the tangible benefits:

• Service Reliability: Mission-critical services demand a constant address. A web server needs a static IP so its DNS records can consistently point traffic to the right machine. An email server or a Virtual PBX phone system simply can't function reliably if its address is always changing.
• Simplified Firewall Management: Security rules are almost always tied to IP addresses. A static IP lets you craft precise, permanent firewall rules that grant access to specific services from trusted locations, which massively strengthens your security posture.
• Accurate DNS Resolution: DNS records exist to map a human-friendly domain name to a machine's IP address. A static IP makes this mapping permanent. With a dynamic IP, you're constantly risking DNS pointing to an old, incorrect address, rendering your services completely inaccessible.

A core concept behind any static IP setup is understanding how network addressing works. For a great deep dive into how networks are segmented, Purple offers an insight into subnet masking that helps clarify these principles.

In managed hosting environments like those at ARPHost, static IPs are standard procedure, not an afterthought. They form the very foundation of a stable network architecture, ensuring that every component—from a secure VPS to a complex Proxmox private cloud—remains consistently accessible and manageable.

Ultimately, mastering how to set a static IP in Linux is a foundational skill. It's what transforms a generic machine into a reliable, production-ready server ready to power your business-critical operations. To learn more about building resilient systems, check out our guide on what network redundancy is and why it matters.

Configuring Static IPs on Ubuntu and Debian Systems

If you're working with Debian-based systems like Ubuntu, you'll run into two main ways to lock in a static IP. Modern releases (think Ubuntu 17.10+ and Debian 10+) have embraced Netplan, a slick tool that uses simple YAML files for network configuration. But you'll still find countless servers out there running the classic ifupdown package, which relies on the good old /etc/network/interfaces file.

Honestly, you need to know both. As a sysadmin, you'll manage everything from a brand-new high-availability VPS to an older dedicated machine, and being fluent in both methods is non-negotiable.

As the diagram shows, any machine that acts as a server needs a reliable, unchanging IP address. Client devices, on the other hand, are perfectly happy grabbing a dynamic one from DHCP.

The Modern Approach with Netplan

Netplan is a game-changer because it simplifies network management down to a single, declarative syntax. You write one YAML file, and it handles generating the necessary backend configurations for either NetworkManager or systemd-networkd. It's clean and efficient.

First things first, you need to find your network interface name. Just run ip a or nmcli dev status in your terminal. You're looking for something like eth0, ens3, or enp0s3.

Netplan's configuration files live in /etc/netplan/. You might see a default file already there, maybe named 01-netcfg.yaml or 50-cloud-init.yaml. A good habit is to create your own file with a higher number, like 99-custom-static.yaml, to make sure its settings are applied last and override any defaults.

Before you touch anything, always back up the original configuration. A quick cp command is all you need. If you're a bit rusty with file operations, our guide on how to edit a file in Linux is a great refresher.

Here’s a practical example of a Netplan configuration for a static IPv4 address:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: no
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
          addresses: [8.8.8.8, 1.1.1.1]

Pro Tip: YAML is extremely picky about indentation. Always use spaces, not tabs. A single misplaced space can cause the whole thing to fail. The standard is two spaces for each level of indentation.

Once you’ve saved the file, it's time to test and apply the new settings.

1. Test the configuration: sudo netplan try
2. Apply the configuration: sudo netplan apply

That try command is a lifesaver. It applies the settings for 120 seconds and automatically reverts them if you don't confirm. This simple step can prevent you from accidentally locking yourself out of a remote server.

The Classic Method Using /etc/network/interfaces

For older Debian or Ubuntu systems—or any server still configured with ifupdown—your destination is the /etc/network/interfaces file. This method is more direct, but it doesn't have the clean abstraction that Netplan offers.

You'll want to make sure ifupdown is actually installed and managing your interfaces. Then, pop open /etc/network/interfaces with your favorite text editor.

Here’s how you'd set up the exact same static IP using the traditional approach:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto ens3
iface ens3 inet static
    address 192.168.1.100
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameservers 8.8.8.8 1.1.1.1

Let’s quickly break this down:

• auto ens3: This line tells the system to bring the ens3 interface up automatically on boot.
• iface ens3 inet static: Here, we're defining the interface and telling it to use a static IPv4 address.
• address, netmask, gateway: These are the bread and butter of your IP configuration.
• dns-nameservers: This sets your DNS resolvers. Just be aware that this line requires the resolvconf package to be installed to work correctly.

After saving your changes, you need to restart the network interface. Be very careful doing this over SSH, as a typo could easily disconnect you.

sudo ifdown ens3 && sudo ifup ens3

To finish, verify that your new IP address is live with ip a show ens3. The output should show the static IP you just configured, confirming everything worked as expected.

Setting Static IPs on RHEL, CentOS, and Fedora

When you're working in the Red Hat ecosystem—whether it's RHEL, CentOS, AlmaLinux, or Fedora—NetworkManager is the tool of the trade. It's the standard for a reason. While you can interact with it in a few ways, we'll zero in on the two methods you'll actually see in the wild.

The modern, and frankly better, approach uses the nmcli command-line tool. The old-school way involves editing the classic ifcfg configuration scripts directly. Both get the job done, but one is clearly built for the future.

Getting comfortable with nmcli is non-negotiable for managing headless servers, especially in environments like a Proxmox Private Cloud. When there's no GUI, efficient command-line skills are what separate the pros from the amateurs.

Using nmcli: The Modern Standard

The nmcli (NetworkManager Command-Line Interface) tool is the preferred way to handle networking on modern RHEL-based systems. It’s powerful, easy to script, and—best of all—applies changes on the fly without needing a full network restart. That's a huge win for server uptime.

First things first, you need to know what you're working with. Find the name of the network connection and the device you want to configure.

nmcli connection show

This command spits out a list of all your network profiles. Look for something like Wired connection 1 or, more commonly, a name matching your interface, like ens18. For the rest of this guide, we'll pretend our connection is named ens18.

Now, let's lock in a static IPv4 address. The following commands will flip the connection from DHCP to static, then set the IP address, gateway, and DNS servers in a few clean steps.

# Switch the connection to a manual (static) IP setup
sudo nmcli con mod ens18 ipv4.method manual

# Assign the IP address and subnet mask (e.g., /24)
sudo nmcli con mod ens18 ipv4.addresses 10.10.20.50/24

# Set the default gateway
sudo nmcli con mod ens18 ipv4.gateway 10.10.20.1

# Set your DNS servers (you can add more, just separate them with a space)
sudo nmcli con mod ens18 ipv4.dns "8.8.8.8 1.1.1.1"

Once you've run those, you need to tell NetworkManager to apply the changes. The quickest way is to bounce the connection.

sudo nmcli con down ens18 && sudo nmcli con up ens18

This simple command deactivates and then reactivates the interface, making your new static IP live. You can check your work instantly with ip addr show ens18.

Configuring a Static IPv6 Address with nmcli

Adding a static IPv6 address is just as straightforward. In fact, you can have both IPv4 and IPv6 addresses assigned to the same interface—a common setup in today's data centers.

# Set the IPv6 method to manual
sudo nmcli con mod ens18 ipv6.method manual

# Assign the static IPv6 address and its prefix length
sudo nmcli con mod ens18 ipv6.addresses "2001:db8:1:1::50/64"

# Set the IPv6 default gateway
sudo nmcli con mod ens18 ipv6.gateway "2001:db8:1:1::1"

# Set the IPv6 DNS servers
sudo nmcli con mod ens18 ipv6.dns "2606:4700:4700::1111 2606:4700:4700::1001"

Just like with IPv4, a quick nmcli con down ens18 && nmcli con up ens18 will apply the new settings.

Why ARPHost Excels Here

In a multi-server setup like our Dedicated Proxmox Private Clouds, consistency is king. Scripting nmcli commands lets us provision network settings across dozens of VMs quickly and without human error. Our fully managed IT services team uses these automated best practices to guarantee your entire private cloud is configured perfectly from day one.

The Traditional ifcfg Script Method

If you're managing older systems or just prefer editing config files by hand, the ifcfg scripts are your go-to. You'll find them sitting in /etc/sysconfig/network-scripts/, with a file named after your interface, like ifcfg-ens18.

Before you touch anything, make a backup. A single typo in this file can knock your server completely offline.

Here’s what a properly configured ifcfg-ens18 file for a static IP should look like.

TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none  # This is the key part! Change from 'dhcp' to 'none' or 'static'
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
NAME=ens18
DEVICE=ens18
ONBOOT=yes      # Make sure this is 'yes' so the interface comes up on boot

# --- Static IP Configuration ---
IPADDR=10.10.20.50
PREFIX=24       # Or you could use NETMASK=255.255.255.0
GATEWAY=10.10.20.1
DNS1=8.8.8.8
DNS2=1.1.1.1

Let's quickly break down the most important lines:

• BOOTPROTO=none: This is critical. It tells NetworkManager to keep its hands off and not request an IP via DHCP.
• ONBOOT=yes: Without this, your interface won't activate automatically when the server reboots. A classic "gotcha."
• IPADDR, PREFIX, GATEWAY, DNS1: These are the bread and butter—your static IP, subnet, router, and DNS servers.

After you save your changes, you have to tell the system to reload the configuration. You can either restart the whole service (sudo systemctl restart NetworkManager) or, more elegantly, use nmcli con reload && nmcli con up ens18.

Whichever method you pick, the final, absolutely essential step is to verify that your settings persist across a reboot. A server that loses its IP after restarting is a ticking time bomb. For robust server solutions built for stability from the ground up, check out ARPHost's secure VPS hosting bundles designed for serious production workloads.

The Universal Approach with Systemd-networkd

If you're juggling a diverse mix of Linux environments, switching between tools like Netplan and NetworkManager can be a real headache. For a powerful, distribution-agnostic method that just works across most modern systems, systemd-networkd is your best friend. It provides a consistent, predictable way to configure networking, which is why it’s a favorite for automated deployments and custom IT solutions.

Instead of wrestling with YAML or interactive command-line tools, systemd-networkd uses simple .network configuration files stashed away in /etc/systemd/network/. This file-based approach is incredibly reliable for scripting and perfect for provisioning bare metal servers or virtual machines where a standardized networking layer is non-negotiable.

Creating Your First .network Configuration File

Before you dive in, you need to make sure no other network management service—like NetworkManager or networking.service—is active. You have to disable them to prevent conflicts. Once that’s handled, you can create your new configuration file. It's a good practice to name it with a priority prefix, like 10-static.network, to control the order in which files are applied.

Let's walk through setting up a static IPv4 address for an interface named enp0s3. Just open a new file with your favorite text editor:

sudo nano /etc/systemd/network/10-static.network

Now, drop in the following configuration. The structure is dead simple, using sections like [Match] to target an interface and [Network] to apply the settings.

[Match]
Name=enp0s3

[Network]
Address=192.168.122.10/24
Gateway=192.168.122.1
DNS=8.8.8.8
DNS=1.1.1.1

Let's quickly break down what this does:

• [Match]: This section tells systemd-networkd exactly which network device to configure. We're matching by its Name.
• [Network]: This is where the magic happens.
  • Address: Sets the static IP and subnet mask using CIDR notation.
  • Gateway: Defines the default gateway for your network.
  • DNS: Specifies your DNS servers. You can list multiple entries, and they'll be used in order.

This method is exceptionally clean and leaves very little room for ambiguity, which is critical in any production environment.

Enabling and Activating Systemd-networkd

Once you've saved your .network file, the changes won't take effect until you enable and start the systemd-networkd service. It’s a quick two-step process that applies your settings immediately and makes sure they stick around after a reboot.

First, enable the service to start automatically on boot:

sudo systemctl enable systemd-networkd

Next, start the service to apply your new configuration right now:

sudo systemctl start systemd-networkd

To confirm everything is working, just run the ip a command and check the enp0s3 interface. You should see the static IP you just defined. For DNS, you’ll also want to make sure systemd-resolved is running, as it’s the component that handles nameserver lookups.

Why ARPHost Excels Here

When deploying custom IT solutions, like a hybrid environment linking on-premise hardware with a Proxmox private cloud, a consistent networking layer is absolutely crucial. Our managed services team uses tools like systemd-networkd to build robust, automated pipelines for server provisioning. This guarantees every machine, whether it’s a $5.99/month VPS or part of a dedicated cluster, is configured correctly and reliably, every single time. Request a managed services quote to see how we can automate and secure your infrastructure.

Troubleshooting Common Network Configuration Issues

Setting a static IP is usually straightforward, but when it goes wrong, you can find yourself completely locked out of your server. It happens to everyone, from junior admins to seasoned pros. The key is to stay calm and work through the problem methodically instead of making frantic, random changes that only make things worse.

The classic heart-stopping moment is losing all network connectivity right after hitting "apply." Another common frustration is when your perfectly set static IP vanishes after a reboot, forcing the server back to an old address or leaving it with none at all. The good news? These problems are almost always fixable and usually boil down to just a few common slip-ups.

Diagnosing Loss of Connectivity

If your server drops off the face of the earth right after you set a static IP, the culprit is often a simple typo. Before you panic, re-read your configuration file. A single incorrect digit in the gateway address is a classic mistake that will immediately cut your server off from the outside world. Did you mistype the IP address or subnet mask? The basics are the first place to look.

Another issue I see a lot involves conflicting network managers. Modern Linux distros often have multiple tools that can manage network interfaces, like NetworkManager, systemd-networkd, and the classic ifupdown. If two of these are active and trying to control the same ethernet port, they'll fight, leading to unpredictable results or a total loss of connection. Make sure only one service is enabled and configured for your primary network device.

Ensuring Settings Persist After a Reboot

It’s a uniquely frustrating experience: you configure a static IP, confirm it works beautifully, and then it’s gone the next time you restart the system. This almost always points back to a mistake in the configuration file that tells the system how to initialize the network at boot time.

Here are the usual suspects for non-persistent settings:

• Incorrect ONBOOT Parameter: On RHEL-based systems using ifcfg files, the ONBOOT=yes line is non-negotiable. If it's missing or set to no, the interface simply won't come up automatically.
• Cloud-Init Overwrites: If you're on a cloud VPS, a service called cloud-init often handles initial network setup. Sometimes, it's configured to re-apply its default settings on every single reboot, completely wiping out your manual changes. You'll need to dig into its configuration and disable the network module to make your static IP stick.
• Forgetting to Restart Services: After you edit the config files, you have to tell the network service to reload them. Forgetting this step means your changes are only active in the current session and will be lost on the next reboot. You can learn more in our guide on how to properly restart a Linux service.

Pro Tip for Remote Management: When changing a static IP over SSH, always have a backup plan. For ARPHost VPS or Bare Metal customers, this means having the VNC or IPMI console open in another window. If you lock yourself out, this direct console is your lifeline for fixing the typo without having to open a support ticket.

Avoiding IP Address Conflicts

An IP address conflict happens when two different machines on the same network are assigned the exact same IP. This causes chaos, leading to intermittent connection drops or knocking both devices offline entirely. The best prevention is good housekeeping. Keep a simple spreadsheet or use an IP Address Management (IPAM) tool to track every static IP you assign.

This becomes absolutely critical in complex setups like a Dedicated Proxmox Private Cloud, where you might be juggling dozens of virtual machines. At ARPHost, our fully managed IT services include meticulous network documentation to ensure our clients' infrastructure stays stable, secure, and free of these kinds of conflicts.

Scaling Network Management with Fully Managed Services

Setting up a static IP on a single server is one thing. But what happens when you're managing an entire fleet? The complexity explodes when you're responsible for dozens of virtual machines in a Proxmox private cloud or a cluster of high-availability VPS instances.

At that scale, you need a strategy that's both scalable and completely error-proof. Manual configuration isn't just slow—it's a direct threat to your operational stability.

Think about it. A single typo in an IP address might cause a small hiccup on one machine. But if that same typo gets baked into a deployment script, you could bring an entire application stack offline, damaging revenue and user trust. The real goal is to get human hands out of the process entirely.

From Manual Tweaks to Automated Provisioning

Instead of SSHing into every new server to hammer out network settings, a managed services approach automates network provisioning from the get-go. This ensures every new instance, whether it's a small web server or a new node in a dedicated private cloud, is configured correctly and consistently the moment it spins up.

This isn't just about speed; it's about reliability. The process typically includes:

• Centralized IP Address Management (IPAM): This eliminates the nightmare of IP conflicts by creating a single source of truth for all network assignments. No more guessing games or outdated spreadsheets.
• Consistent Firewall Policy Application: Pre-defined, best-practice firewall rules are applied to every new server automatically. Nothing gets deployed naked and exposed.
• Guaranteed Configuration Integrity: Automation tools enforce network settings across the board, preventing that slow, silent "configuration drift" that causes so many mysterious outages down the line.

When you're scaling up, it's also critical to plan for major shifts, like switching Managed Service Providers without downtime, to keep services running smoothly during the transition.

At ARPHost, our fully managed IT services are designed to handle all of this for you. We take care of the meticulous details of network provisioning, security hardening, and ongoing monitoring. This frees up your team to focus on what they do best: deploying applications, not fiddling with network interfaces.

Why ARPHost Excels Here

For any business focused on growth, offloading granular network management is a powerful strategic move. Our expert team becomes a true extension of yours, implementing robust and resilient network architectures for everything from bare metal servers to complex Proxmox environments. We make sure your infrastructure is stable, secure, and ready to handle whatever you throw at it.

Let us handle the complexity of setting static IPs and managing network policies across your entire server fleet. With ARPHost's proactive management, you can build your business on a digital foundation that's grounded in reliability and industry best practices.

Ready to stop worrying about server configurations? Explore ARPHost's fully managed IT services at arphost.com/managed-services/ and let our experts build a resilient network for your business.

Common Questions and Quick Answers

When you're knee-deep in configuration files, a few questions always seem to pop up. Here are some quick answers to the most common ones I hear from admins setting up static IPs.

Can I Set a Static IP Without a Gateway?

Technically, yes, but it's not very useful. Without a default gateway, your server can only talk to other devices on its local network segment. It’s completely cut off from the internet and any other external networks, which pretty much defeats the purpose for any production server.

How Do I Find My Network Interface Name?

The most reliable command is ip a (or its longer version, ip addr show). This spits out a list of all network interfaces on your system. You're looking for a name like eth0, ens3, or enp0s3—just ignore the loopback interface, which is always named lo.

What Happens If Two Devices Have the Same Static IP?

That's when you get an IP address conflict, a nasty networking headache that causes intermittent—or total—connectivity loss for both devices. It's a surprisingly common issue, especially in environments with lots of VMs, like a Proxmox private cloud, where manual assignments can easily overlap.

An IP conflict is almost always a failure of process. It’s a classic symptom of poor documentation or miscommunication between team members. This is where managed services really prove their worth—a good provider maintains a bulletproof IP allocation scheme, preventing these frustrating, hard-to-diagnose errors from ever happening.

Do I Need to Reboot the Server After Changing the IP?

Thankfully, no. In most modern Linux systems, a full reboot is overkill. Tools like nmcli, Netplan, and systemd-networkd are smart enough to apply changes by just restarting the network service itself. For example, running sudo netplan apply or restarting a specific connection with nmcli gets the job done without taking your secure web hosting bundles offline. Think of a server reboot as a last resort, not a standard step.

At ARPHost, we believe managing your infrastructure shouldn't be a struggle. Our fully managed IT services and hosting platforms—from high-availability VPS to dedicated bare metal servers—are engineered with these best practices built-in, so your network is always stable, secure, and performing at its best.

Ready to ditch the configuration headaches? Explore our secure VPS bundles starting at just $5.99/month and let our experts handle the heavy lifting.