The scenario
You just finished setting up a new Fedora server or desktop. The default DHCP configuration worked fine during installation, but now you need a predictable address for remote access, container networking, or a local service. You try to SSH in after a reboot and the connection drops. The router handed out a new address. You need a static IP.
What is actually happening
Fedora ships with NetworkManager as the default network stack. It manages interfaces, profiles, and DNS resolution in one place. When you install Fedora, NetworkManager creates a connection profile for each interface you touch. That profile defaults to DHCP. DHCP means the router decides your IP address, subnet mask, gateway, and DNS servers. It is convenient for laptops and desktops that move between networks. It is unpredictable for servers and workstations that host services.
Switching to a static IP does not change the physical cable or the wireless card. It changes the connection profile. You tell NetworkManager to ignore the DHCP server and use the values you provide instead. The profile stores those values in a configuration file. NetworkManager reads the file on boot and applies the settings to the kernel network stack.
NetworkManager separates runtime state from persistent state. The runtime state lives in memory and changes instantly when you run nmcli connection up. The persistent state lives on disk in /etc/NetworkManager/system-connections/. When you modify a profile, you are editing the persistent state. You must activate the profile afterward to push the changes to the runtime state. This two-layer design lets you test configurations without breaking the live connection.
Fedora also supports systemd-networkd as an alternative. It is a lighter daemon that reads plain text configuration files directly. Most desktop and server installations stick with NetworkManager because it handles Wi-Fi, VPNs, and connection switching automatically. You only need systemd-networkd if you are running a minimal container or a stripped-down appliance where every megabyte of RAM matters.
Reboot before you debug. Half the time the symptom is gone.
Set a static IP with NetworkManager
NetworkManager uses a keyfile format for connection profiles. Each profile contains sections for connection metadata, IPv4 settings, IPv6 settings, and device bindings. You can modify these settings through the nmcli command line or by editing the file directly. The command line is safer because it validates syntax before writing to disk.
First, find the exact connection name. Interface names like eth0 or enp3s0 are hardware identifiers. Connection names are logical labels that NetworkManager uses. They often match the interface name, but not always.
Here is how to list your active connections and find the correct label.
nmcli connection show --active
# Lists only connections currently attached to an interface
# The first column shows the logical connection name
# The second column shows the hardware interface name
Pick the connection name from the first column. Replace wired-connection-1 in the next command with your actual label. The command below sets the IPv4 method to manual, assigns the address and subnet, defines the default gateway, and adds a DNS server.
sudo nmcli connection modify wired-connection-1 ipv4.method manual \
ipv4.addresses "192.168.1.50/24" \
ipv4.gateway "192.168.1.1" \
ipv4.dns "8.8.8.8"
# ipv4.method manual tells NetworkManager to ignore DHCP for this profile
# ipv4.addresses sets the IP and CIDR subnet mask in one string
# ipv4.gateway defines the default route for outbound traffic
# ipv4.dns adds a resolver. Add more with ipv4.dns2 or ipv4.dns3
NetworkManager writes the changes to disk immediately. The running interface still uses the old DHCP address. You need to reactivate the connection to apply the new settings. This drops the current network session for a few seconds.
sudo nmcli connection up wired-connection-1
# Deactivates the old profile and brings up the modified one
# The interface goes down and back up automatically
# NetworkManager reads the new values and programs the kernel
If you prefer editing the configuration file directly, NetworkManager stores profiles in /etc/NetworkManager/system-connections/. The files use a keyfile format. You can open the file with your editor, but you must set the correct permissions afterward. NetworkManager refuses to read profiles that are world-readable.
Here is how to edit the profile file safely.
sudo nano /etc/NetworkManager/system-connections/wired-connection-1.nmconnection
# Opens the persistent configuration file for the connection
# Look for the [ipv4] section near the bottom of the file
# Change method=dhcp to method=manual
# Add address1=192.168.1.50/24,192.168.1.1
# Add dns=8.8.8.8
After saving, fix the permissions and reload NetworkManager.
sudo chmod 600 /etc/NetworkManager/system-connections/wired-connection-1.nmconnection
# Restricts access to root only. NetworkManager drops profiles with loose permissions.
sudo nmcli connection reload
# Forces NetworkManager to re-read all files from disk
sudo nmcli connection up wired-connection-1
# Applies the updated configuration to the running interface
Run nmcli connection show wired-connection-1 to inspect the full profile. The output confirms every field you changed. Trust the package manager. Manual file edits drift, snapshots stay.
Verify the connection
Do not assume the change worked because the command returned no errors. NetworkManager can silently fall back to DHCP if the profile contains a syntax error or a conflicting setting. Check the actual interface state.
Here is how to confirm the kernel received the correct address and route.
ip -br addr show
# Shows interface name, state, and assigned IP addresses
# Look for your interface and verify the /24 subnet is attached
ip route show default
# Displays the default gateway route
# Verify it points to 192.168.1.1 and not a DHCP-assigned router
DNS resolution is the most common silent failure. The kernel route might be correct while the resolver still points to a DHCP server that no longer exists. Check the resolver configuration.
cat /etc/resolv.conf
# This file is usually a symlink managed by NetworkManager
# Verify nameserver 8.8.8.8 appears in the output
# If it points to 127.0.0.53, systemd-resolved is handling queries locally
Run a quick connectivity test to confirm end-to-end routing.
ping -c 4 192.168.1.1
# Tests Layer 3 reachability to your gateway
ping -c 4 fedoraproject.org
# Tests DNS resolution and outbound internet routing
Reboot before you declare the job done. A successful nmcli connection up only proves the runtime state works. The persistent state must survive a full boot cycle.
Common pitfalls and error messages
Static IP configuration fails in predictable ways. The errors usually point to a mismatch between your settings and the physical network.
The most frequent error is a subnet mismatch. If you assign 192.168.1.50/24 but your router lives on 192.168.0.x, the interface will come up but you will have no internet. NetworkManager will print a warning during activation.
Error: Connection activation failed: (7) No suitable device found for this connection.
This error means the connection profile is bound to a different hardware interface than the one you expect. Check the device.slave-type or connection.interface-name fields in the profile. Remove the hard interface binding if you want the profile to attach to any available wired port.
Another common issue is IPv6 interference. Fedora enables IPv6 by default. If you only configure IPv4, the interface will still request an IPv6 address via SLAAC or DHCPv6. Some corporate networks block IPv6 traffic and drop the connection entirely. Disable IPv6 if your network does not support it.
sudo nmcli connection modify wired-connection-1 ipv6.method disabled
# Stops NetworkManager from requesting or configuring IPv6 on this profile
# Prevents timeout delays while the system waits for an IPv6 lease
sudo nmcli connection up wired-connection-1
# Reactivates the interface with IPv6 turned off
SELinux rarely blocks network configuration, but it will stop you from running custom scripts that modify routing tables. If you see Permission denied when a systemd service tries to change network settings, check the audit log.
journalctl -t setroubleshoot | tail -n 20
# Shows SELinux denial summaries with human-readable explanations
# Look for avc: denied messages related to network configuration
Do not edit files in /usr/lib/NetworkManager/. Those are package-owned templates. Edit files in /etc/NetworkManager/. Package updates overwrite /usr/lib/ and destroy manual changes.
Run journalctl -xeu NetworkManager first. Read the actual error before guessing.
When to use NetworkManager versus systemd-networkd
Use NetworkManager when you need a unified interface for Wi-Fi, Ethernet, VPNs, and connection profiles. Use NetworkManager when you want GUI tools like GNOME Settings or KDE System Settings to manage your network. Use NetworkManager when you are running a standard Fedora Workstation or Server installation. Use systemd-networkd when you are building a minimal container image and need to save RAM. Use systemd-networkd when you prefer plain text configuration files without a daemon managing connection states. Use systemd-networkd when you are running a headless appliance that only ever connects to one static network.