How to Configure a Static IP Address on Ubuntu Server 24.04, 22.04, and 20.04

How Do You Configure a Static IP on Ubuntu Server?

Ubuntu Server uses Netplan to define persistent network configuration. A correct static configuration requires four core values: IP address, subnet prefix, default gateway, and DNS resolvers. The safest production workflow validates the network configuration before permanently applying it.

Why Does Ubuntu Server Need a Static IP?

A static IP gives a server a predictable network identity that remains consistent across reboots and DHCP lease changes. Servers that provide network-accessible services commonly require predictable addressing. Web servers, application servers, DNS servers, mail servers, VPN endpoints, monitoring systems, databases, and infrastructure nodes all benefit from stable addressing because other systems need a dependable destination for connections.

A DHCP-assigned address can change when a lease expires, a DHCP server changes its allocation, or infrastructure undergoes maintenance. That behavior works well for many client devices but creates operational problems when firewall rules, DNS records, reverse proxies, monitoring systems, load balancers, or application integrations depend on a specific server address.

For production infrastructure, however, a static IP should not be treated as merely an address typed into a configuration file. A production network configuration is a dependency chain consisting of addressing, subnetting, routing, DNS resolution, interface state, and the network-management backend. A mistake in any one of those layers can make a server unreachable even when the IP address itself looks correct.

What Is the Difference Between a Static IP and DHCP?

A static IP is an address explicitly configured on the server rather than dynamically assigned through DHCP. DHCP normally supplies an address and related network parameters dynamically, while static configuration makes those parameters persistent on the host.

A DHCP reservation provides another approach in which the DHCP server consistently assigns the same address to a particular device. That architecture can be preferable in some environments because the server remains a DHCP client while the network infrastructure controls the address allocation.

A manually configured static IP becomes particularly useful for dedicated infrastructure where administrators need predictable routing, firewall policies, monitoring targets, DNS records, or service endpoints. Ubuntu’s current networking documentation supports both temporary IP configuration and persistent Netplan-based configuration.

Which Ubuntu Versions Use Netplan for Static IP Configuration?

Modern Ubuntu Server releases use Netplan as the network configuration abstraction layer. Netplan reads YAML configuration and generates configuration for a networking backend such as systemd-networkd or NetworkManager.

Ubuntu 20.04, 22.04, and 24.04 use Netplan-based networking, although the installed Netplan version and surrounding infrastructure can differ between releases. Ubuntu’s current documentation continues to describe static IP configuration through Netplan and /etc/netplan/.

Ubuntu 24.04 deserves particular attention because it remains widely deployed across VPS, dedicated-server, cloud, hosting, and enterprise environments. The current Ubuntu documentation provides a static-address example using an interface, address, default route, and nameservers in a Netplan YAML configuration.

What Information Do You Need Before Assigning a Static IP?

You need the correct IP address, subnet prefix, default gateway, DNS servers, and network interface before changing a production server’s network configuration. A static IP configuration cannot be safely designed from the IP address alone.

The IP address identifies the server on the network, while the prefix determines which addresses belong to the local subnet. The default gateway determines where traffic travels when the destination exists outside the local subnet. DNS resolvers translate hostnames into addresses and therefore affect application connectivity even when the IP routing itself works correctly.

For example, an address such as 192.168.10.50/24 indicates an IPv4 address with a 24-bit network prefix. A traditional /24 IPv4 network contains 256 total addresses, with 254 normally usable host addresses after reserving the network and broadcast addresses.

How Do You Identify the Correct Network Interface?

The network interface is the physical or virtual device that actually carries the server’s traffic. Ubuntu interface names can vary between servers, so administrators should identify the real interface instead of assuming that it is always eth0.

Modern Linux installations frequently use predictable interface names such as ens3, ens18, enp1s0, or similar names. Cloud providers may expose a virtual Ethernet interface whose name differs from the naming convention used on physical servers.

This distinction matters because Netplan associates an IP configuration with a specific interface. A perfectly written YAML configuration assigned to the wrong interface can leave the intended interface unchanged and make the server appear disconnected.

Where Does Ubuntu Store Netplan Configuration?

Ubuntu stores persistent Netplan configuration in /etc/netplan/. Netplan processes YAML files from its configuration locations and uses them to generate configuration for the selected networking backend.

The exact filename can differ between installations. You may encounter files generated by the installer, cloud-init, a hosting provider, or an administrator. The important operational rule is to understand which configuration files exist and how their combined settings affect the final configuration.

Netplan’s get functionality can display the merged configuration, which is particularly useful when several YAML files exist. The official Netplan documentation states that the merged configuration is read from the /etc, /lib, and /run Netplan locations.

How Do You Configure a Static IP Using Netplan?

The core Netplan configuration defines the interface, disables IPv4 DHCP for that interface, assigns the static address, establishes the default route, and specifies DNS resolvers. Ubuntu’s current server documentation uses the addresses, routes, and nameservers fields for persistent static IPv4 configuration.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: false
      addresses:
        - 192.168.10.50/24
      routes:
        - to: default
          via: 192.168.10.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

The values above are examples rather than universal production values. The IP address, prefix, gateway, interface name, and DNS servers must match the actual network assigned to the server.

Why Should You Use the Default Route Instead of an Old Gateway Syntax?

Modern Netplan configurations can express the default route explicitly through the routes section. Ubuntu’s current networking documentation demonstrates the default gateway through a route containing to: default and a via gateway address.

This approach makes the routing intent explicit and aligns with the current Ubuntu documentation. Administrators maintaining older systems may encounter configurations using legacy gateway syntax, but new documentation should favor the currently documented route representation.

A default route determines where the kernel sends packets when no more specific route matches the destination. Without an appropriate default route, a server may successfully communicate with devices on its local subnet while failing to reach external networks.

How Does the Linux Kernel Use the Static IP?

The Linux kernel makes routing decisions based on the destination address and the system’s routing table. An IP address alone does not determine where an Internet-bound packet should travel.

Suppose a server owns 192.168.10.50/24. Traffic destined for another host inside 192.168.10.0/24 can normally travel directly through the local interface because the destination belongs to the connected subnet.

Traffic destined for an external address such as a public DNS resolver does not belong to that local subnet. The kernel therefore needs a default route pointing toward the appropriate gateway. The gateway then becomes the next network hop.

This explains an important troubleshooting pattern: a server can have the correct static IP while still having no Internet connectivity because its routing configuration is incorrect.

Why Does DNS Matter After the Static IP Works?

DNS resolution converts hostnames into IP addresses, but DNS does not determine whether the server itself has a valid route. A server can have working IP connectivity while DNS resolution remains broken.

This distinction makes DNS one of the most useful diagnostic boundaries. If a server can reach an external IP address but cannot resolve a hostname, the administrator should investigate DNS configuration rather than changing the IP address or gateway.

Ubuntu’s Netplan documentation supports configuring DNS addresses through the nameservers section.

How Should You Safely Apply a Static IP Change?

netplan try provides a safer mechanism for testing network changes because it can automatically roll the configuration back when the administrator does not confirm the change. The Netplan manual documents netplan try as a transactional-style test that automatically rolls back an unconfirmed configuration, with a default timeout of 120 seconds.

This behavior matters enormously when administrators work remotely over SSH. A malformed configuration can immediately terminate the administrator’s connection, leaving the server inaccessible until console access or automated recovery becomes available.

The operational sequence should therefore be validation, controlled application, connectivity verification, and confirmation rather than blindly replacing the active network configuration.

Why Is YAML Formatting Important in Netplan?

YAML uses indentation to represent configuration hierarchy. Incorrect indentation can prevent Netplan from interpreting the intended network structure correctly.

A network configuration can therefore fail because of a seemingly insignificant spacing mistake. The problem does not necessarily indicate a networking failure at the kernel level; the configuration may never reach the networking backend because Netplan cannot successfully parse or generate it.

Administrators should treat Netplan YAML as infrastructure configuration rather than ordinary text. Version-controlled configuration, careful validation, and a rollback strategy reduce the risk of remote lockouts.

How Do You Verify That the Static IP Is Actually Active?

A successful configuration requires more than seeing the expected address assigned to an interface. Static IP verification should confirm addressing, routing, DNS resolution, and external connectivity independently.

The first verification layer checks whether the expected address exists on the intended interface. The second confirms that the routing table contains the expected default route. The third tests reachability through the gateway or an external IP. The fourth verifies hostname resolution.

This layered verification prevents administrators from incorrectly declaring success based only on the presence of the static address.

What Does a Successful Static IP Test Actually Prove?

An interface-address test proves that the local interface has the expected address. An interface test does not prove that Internet routing or DNS resolution works.

A route test establishes that the kernel knows where external traffic should go. A gateway test establishes local next-hop connectivity. An external-IP test establishes broader network reachability. A DNS test establishes hostname resolution.

This layered approach is useful in production because it narrows failures to specific components instead of encouraging repeated changes to a configuration that may already contain the correct IP address.

Why Can a Static IP Work Locally but Fail Over the Internet?

A static IP can work on the local subnet while Internet traffic fails when the default route, upstream gateway, firewall, or provider-side routing is incorrect. Local reachability and Internet reachability represent different network paths.

A server might successfully communicate with its gateway while upstream routing drops packets. A cloud provider might require a specific gateway model or network configuration. A hosting provider might route additional addresses differently from the primary address. A firewall might permit local traffic while blocking outbound or inbound traffic.

This is why production troubleshooting should inspect the entire path rather than focusing exclusively on /etc/netplan/.

How Does a VPS Provider Change Static IP Configuration?

VPS networking can differ from a traditional physical LAN because the hypervisor and provider network control the virtual interface and upstream routing. A VPS’s static IP configuration must comply with the addressing and routing model supplied by the virtualization platform.

Some providers assign a primary address with a specific gateway and subnet. Others use routed addresses, virtual MAC addresses, point-to-point models, or provider-specific network requirements.

An administrator should therefore use the provider’s assigned network information rather than assuming that every VPS behaves like a home or office Ethernet network.

How Do Multiple Static IP Addresses Work on Ubuntu?

Ubuntu can associate multiple static addresses with a single network interface. Netplan supports multiple addresses on an Ethernet interface through the addresses configuration.

A server hosting multiple services may use several addresses for application isolation, SSL endpoints, mail infrastructure, dedicated services, or legacy compatibility. The network design must still account for routing, firewall policies, service bindings, reverse DNS, and provider-side address assignment.

Ubuntu’s official server documentation provides an example of assigning multiple static addresses to one interface and also describes address labels for identifying individual addresses.

Should You Disable DHCP When Using a Static IPv4 Address?

A manually assigned IPv4 address normally requires administrators to explicitly control DHCP behavior for that interface. Leaving DHCP enabled can create an unintended second address or conflicting network behavior depending on the configuration.

Netplan supports configurations where static addresses coexist with DHCP, but that architecture has a different purpose from a simple single-address static server. Ubuntu’s documentation explicitly demonstrates scenarios where an interface can have both a static address and a DHCP-provided address.

For a straightforward production server with one intentionally assigned static IPv4 address, the configuration should clearly express the desired addressing model.

How Does Netplan Connect to systemd-networkd?

Netplan acts as a configuration layer rather than the final network daemon. Netplan can generate configuration consumed by systemd-networkd or NetworkManager depending on the renderer.

This architecture matters during troubleshooting because an administrator may inspect the Netplan YAML and see the expected configuration while the underlying networking daemon behaves differently due to another configuration layer, interface state, provider automation, or conflicting files.

Ubuntu’s current documentation describes Netplan as the mechanism that defines network configuration while integrating with the primary Linux networking backends.

When Does NetworkManager Matter on Ubuntu?

NetworkManager matters when the server or system uses NetworkManager as the Netplan renderer. Netplan supports NetworkManager as a backend and can generate NetworkManager configuration from YAML.

Ubuntu’s documentation also notes that NetworkManager integration can expose network configuration through traditional NetworkManager tooling while Netplan remains part of the configuration architecture. Administrators should therefore determine which renderer manages the interface before diagnosing a conflict between Netplan, NetworkManager, and systemd-networkd.

How Should Cloud-Init Be Considered?

Cloud-init can influence network configuration on cloud and VPS systems. Cloud-hosted Ubuntu installations can receive network configuration during instance provisioning rather than relying exclusively on manually created files.

This matters because an administrator can manually change a Netplan file and later discover that provisioning or image automation recreates configuration. Production cloud environments should therefore document which system owns the network configuration before making permanent changes.

The correct solution is architectural ownership: one clearly defined mechanism should control the interface configuration rather than several automation layers competing for authority.

What Happens If You Configure the Wrong Gateway?

A wrong gateway can make a server appear healthy while preventing external communication. The default gateway must belong to a reachable network path appropriate for the server’s assigned subnet or provider routing model.

For example, assigning 192.168.10.50/24 and using 192.168.20.1 as the gateway normally creates a fundamental topology mismatch because the gateway does not belong to the directly connected /24 network.

Provider-specific routed configurations can behave differently, which is why administrators should not blindly apply traditional subnet assumptions to cloud or virtual infrastructure.

What Happens If You Configure the Wrong Prefix?

The subnet prefix determines which destinations the kernel treats as directly connected. An incorrect prefix can create incorrect routing decisions even when the IP address itself is valid.

A /24 network and a /16 network do not represent the same local address space. Changing the prefix changes which destinations the kernel considers directly reachable and which destinations require a router.

Subnet errors can therefore produce confusing symptoms where some systems remain reachable while others suddenly become inaccessible.

How Do You Troubleshoot a Server That Lost Connectivity After Netplan Changes?

A server that becomes unreachable immediately after a Netplan change should first be treated as a configuration or routing incident. The fastest recovery path is to use an out-of-band console, VPS console, rescue environment, or provider recovery mechanism rather than repeatedly changing the network configuration remotely.

Administrators should then inspect the effective Netplan configuration, interface state, assigned address, default route, DNS configuration, and backend status. The objective is to identify which layer failed instead of simply restoring the previous file without understanding the root cause.

For business-critical environments, this incident reinforces why network changes require rollback planning and controlled deployment.

Why Should Production Administrators Prefer netplan try for Remote Changes?

Remote network configuration carries a unique operational risk because the network connection used to perform the change can depend on the configuration being changed. netplan try exists specifically to reduce the risk of permanent remote network lockout.

The Netplan manual documents automatic rollback when a test configuration is not confirmed within the timeout period. The documented default timeout is 120 seconds.

For remote administration, this provides an important safety boundary: if the new configuration breaks connectivity and the administrator cannot confirm it, Netplan can revert the change instead of leaving the machine indefinitely unreachable.

How Does IPv6 Change the Static IP Design?

IPv6 introduces a separate addressing and routing model that should be considered independently from IPv4. Configuring a static IPv4 address does not automatically define an equivalent IPv6 architecture.

Ubuntu and Netplan support IPv6 addressing, and Router Advertisements can influence IPv6 configuration. The correct IPv6 design depends on the provider’s prefix delegation, routing model, firewall policy, and application requirements.

Production administrators should avoid disabling IPv6 merely because they are configuring IPv4 unless the environment has a documented requirement to do so.

How Should Firewalls Be Considered During Static IP Changes?

A static IP change can expose a firewall policy mismatch even when the network configuration itself is correct. Firewall rules frequently reference source or destination addresses, interfaces, ports, or network ranges.

If an application previously accepted traffic on one address and the server moves to another address, the service may remain operational while the firewall silently rejects traffic. This can make the network change appear to have failed when the actual problem exists at the security layer.

A production change should therefore include firewall validation whenever the server’s address, subnet, interface, or routing policy changes.

How Does DNS Need to Change When a Server Gets a New Static IP?

DNS records should reflect the server’s new address when clients reach the service through a hostname. Changing a server’s local IP configuration does not automatically update authoritative DNS records.

An A record may continue pointing to the previous IPv4 address while the server operates correctly on the new address. Users then reach the old endpoint even though local network tests succeed.

Reverse DNS also matters for some infrastructure services, particularly mail systems. The forward DNS record, reverse DNS record, application configuration, firewall rules, and provider-side address assignment should therefore remain consistent.

What Is the Difference Between an IP Configuration Problem and a DNS Problem?

An IP configuration problem prevents the host from communicating correctly at the network layer, while a DNS problem prevents reliable hostname resolution. Testing an external IP address separately from a hostname helps distinguish routing failures from DNS failures.

This distinction becomes especially important when administrators receive reports such as “the server has no Internet.” The actual problem might involve a missing default route, unreachable gateway, blocked outbound traffic, broken resolver configuration, or upstream DNS failure.

Infrastructure troubleshooting becomes faster when every test answers one specific technical question.

What Are the Most Common Static IP Configuration Mistakes?

The most common failures involve an incorrect interface, IP address, subnet prefix, gateway, DNS resolver, YAML structure, or conflicting network-management configuration. Most static-IP incidents result from configuration inconsistency rather than from a defect in the Linux networking stack itself.

Another common mistake occurs when administrators copy a configuration from another server without adapting its interface name, subnet, gateway, or provider-specific routing model.

A third failure occurs when administrators change a production network remotely without a rollback mechanism. The configuration might be technically valid but operationally unsafe because the administrator loses the only management path to the server.

How Can You Prevent Static IP Configuration Failures?

The most reliable prevention strategy is to treat network configuration as controlled infrastructure rather than an ad-hoc server change. Every production static-IP change should have a documented address plan, verified gateway, rollback path, console access, and post-change validation.

A good operational process records the current configuration before making changes, identifies the configuration owner, confirms provider requirements, validates the YAML, uses a reversible application method, and verifies addressing, routing, DNS, and application reachability afterward.

This process becomes especially important in hosting environments where one network mistake can affect websites, mail services, APIs, databases, monitoring, and customer-facing applications simultaneously.

How Does Static IP Configuration Affect Hosting Infrastructure?

Static addressing forms part of the foundation for predictable hosting infrastructure. Hosting environments depend on stable network identities for DNS, web services, mail delivery, monitoring, firewall rules, and remote administration.

A hosting provider may operate multiple public IP addresses across dedicated servers, VPS nodes, load balancers, mail servers, and DNS infrastructure. Each address can have different routing, reputation, reverse DNS, and security requirements.

This is where linux server management services become operationally valuable because the network configuration rarely exists in isolation from web-server, firewall, DNS, mail, monitoring, and security configuration.

How Does Static IP Configuration Affect Nginx and Apache?

Nginx and Apache can bind services to specific addresses, ports, or interfaces. A server IP change can therefore affect web-server virtual hosts and listener configuration even when the operating system network is functioning correctly.

A web server configured to listen only on an old address may stop responding after the IP changes. A configuration using wildcard listeners may continue working without modification.

Administrators should therefore validate the application layer after completing the operating-system network change instead of assuming that successful ping or routing tests prove that the website is operational.

How Does Static IP Configuration Affect Mail Servers?

Mail infrastructure depends heavily on consistent IP and DNS identity. Changing a mail server’s public IP can affect reverse DNS, SPF, DKIM-related infrastructure, reputation, firewall rules, SMTP listeners, and external delivery behavior.

A mail server migration therefore requires considerably more planning than simply assigning a new address. The new address may need appropriate reverse DNS, DNS updates, reputation monitoring, provider authorization, and mail-service validation.

This is one reason production network changes should be planned as service changes rather than isolated operating-system changes.

How Does Static IP Configuration Affect Monitoring?

Monitoring systems commonly identify infrastructure using addresses, hostnames, agents, or combinations of those identifiers. A server IP change can cause monitoring systems to report a healthy server as offline even when the server itself is functioning correctly.

Monitoring configuration should therefore be updated alongside the network change. Alert routing, SNMP targets, exporters, firewall rules, synthetic checks, and external monitoring services may all depend on the old address.

A mature infrastructure process updates observability configuration as part of the same change window.

How Does Static IP Configuration Affect Security?

A static IP does not make a server inherently more secure. Security depends on access controls, firewall policy, patching, authentication, service exposure, monitoring, and network architecture rather than whether an address is static.

However, stable addressing makes security policy more predictable. Firewalls can consistently identify management networks, monitoring systems can maintain fixed targets, and access-control policies can reference known infrastructure addresses.

The security benefit therefore comes from predictable infrastructure identity, not from the word “static” itself.

What Production Architecture Should You Use for Ubuntu Static IPs?

A production Ubuntu server should use a documented network design in which the provider or network team owns address allocation, Netplan owns host-level configuration, the appropriate networking backend owns interface state, the firewall owns traffic policy, DNS owns hostname mapping, and monitoring owns observability. Clear ownership prevents configuration layers from competing with one another.

This architecture becomes especially important in cloud environments where automation can modify networking after provisioning. Configuration management, cloud-init, Netplan, NetworkManager, systemd-networkd, firewall automation, and provider APIs should have clearly defined responsibilities.

The goal is not simply to make one server reachable today; the goal is to make its network state predictable after reboot, migration, scaling, patching, and infrastructure recovery.

What Does a Production Static IP Failure Look Like?

A realistic production failure can begin with a single incorrect gateway while every other server component remains healthy. An incorrect default route can make an otherwise healthy Ubuntu server lose external connectivity without causing CPU, memory, disk, or application failures.

Consider an illustrative production simulation involving three Ubuntu application servers behind an Nginx load balancer. One server receives a new static IP during maintenance, but its gateway is entered incorrectly. The interface comes up, the address appears correct, and local subnet communication works.

The load balancer then begins reporting intermittent backend failures because the application server cannot establish outbound connections to its database and external API dependencies. The monitoring system records 100% packet loss to the database endpoint from that node while CPU remains at 31%, memory remains at 58%, and disk utilization remains at 62%.

The engineering team isolates the problem by separating local routing from external routing. The server reaches its local gateway but cannot successfully reach the external dependency. The network team identifies the incorrect default route, restores the provider-assigned gateway, and validates the complete traffic path.

The simulated incident demonstrates an important engineering principle: resource health does not prove network health. CPU, memory, disk, application processes, and even local interface status can remain normal while routing is completely broken.

After remediation, the simulated node returns to normal application traffic, and the load balancer’s backend failure rate falls from the incident baseline of 18.6% to 0% after route correction and connection recovery. These figures are illustrative simulation metrics, not ACTSupport customer measurements.

What Lessons Does This Production Simulation Teach?

The primary lesson is that network troubleshooting must follow the packet path rather than the symptom. A website failure does not automatically mean that the web server is broken.

An application request can traverse DNS, a firewall, a load balancer, the server interface, the kernel routing table, an upstream gateway, another network segment, and finally the application dependency. A failure anywhere along that path can surface as a website timeout or application error.

This architecture-first troubleshooting model is particularly valuable for 24/7 server management services, where engineers must isolate faults quickly without introducing additional changes into a live environment.

How Does ACTSupport Approach Linux Infrastructure Management?

ACTSupport provides managed Linux, cloud, hosting, and server infrastructure support with continuous operational coverage. ACTSupport states that its managed server services include Linux administration, monitoring, security hardening, performance optimization, backups, and incident resolution.

The company’s server-management offering supports Ubuntu alongside other Linux environments and covers technologies including Apache, Nginx, MySQL, MariaDB, cPanel, Plesk, AWS, virtualization platforms, and cloud infrastructure.

For organizations that need infrastructure expertise beyond a one-time IP configuration, ACTSupport positions its engineers as an extension of internal IT teams, covering proactive monitoring, security, performance, migrations, and emergency troubleshooting.