You need a fixed address
You just finished building a home server, a media box, or a development workstation. You want to SSH into it reliably, or you need to forward ports on your router. You plug it in, and DHCP hands it 192.168.1.105. A week later, the router reboots, the lease expires, and the machine gets 192.168.1.112. Your SSH bookmarks break. Your port forwards point to thin air. You need a static IP.
What's actually happening
NetworkManager handles network configuration on Fedora. It does not just toggle interfaces on and off. It manages connection profiles. Each profile stores every detail about a link: the IP method, the gateway, the DNS servers, the VLAN tags, and the security keys. When you plug in a cable or connect to Wi-Fi, NetworkManager matches the hardware to a profile and applies it. By default, that profile tells the kernel to ask a DHCP server for an address. Switching to a static IP means editing that profile so the kernel stops asking and starts using the values you provide.
Think of DHCP like a hotel front desk assigning rooms on a first-come basis. A static IP is like signing a lease for a specific unit. The address stays yours until you explicitly change it. NetworkManager keeps two states in sync: the runtime state (what is active right now) and the persistent state (what is saved on disk). When you modify a profile, you are editing the persistent state. The running connection does not change until you deactivate and reactivate the profile. This separation prevents accidental network drops while you are still typing commands.
Fedora stores every connection profile in /etc/NetworkManager/system-connections/. You never edit those files directly. The nmcli command reads and writes them safely, handles syntax validation, and triggers the daemon to reload the configuration. Manual file edits drift, snapshots stay.
The fix with nmcli
The terminal gives you the most reliable way to edit these profiles. First, find the exact name of the connection profile you want to change. NetworkManager often names wired connections generically on first boot.
Here is how to list your saved profiles and match them to physical interfaces.
nmcli connection show
# Lists all saved profiles with their UUIDs and active state
nmcli device status
# Shows which physical interface is attached to which profile
Note the NAME column. It will usually be Wired connection 1, enp3s0, or something similar. Replace the placeholder in the next command with your actual profile name.
Here is how to switch the profile from DHCP to a fixed address and apply the network parameters.
nmcli connection modify 'Wired connection 1' \
ipv4.method manual \
# Switches the profile from DHCP to a fixed address
ipv4.addresses 192.168.1.50/24 \
# Sets the IP and subnet mask in CIDR notation
ipv4.gateway 192.168.1.1 \
# Points traffic destined for outside the subnet to your router
ipv4.dns '8.8.8.8 1.1.1.1'
# Provides primary and secondary DNS resolvers
NetworkManager writes these values to disk immediately. The running connection still uses the old DHCP lease. You must deactivate and reactivate the profile to apply the new settings.
Here is how to drop the current link and reload the modified profile.
nmcli connection down 'Wired connection 1'
# Drops the current link and clears the old DHCP lease
nmcli connection up 'Wired connection 1'
# Reads the modified profile and applies the static configuration
Changes made with nmcli connection modify persist across reboots automatically. NetworkManager reads the profile directory on startup and applies whatever is saved. No extra daemon configuration is required.
Reboot before you debug. Half the time the symptom is gone.
Verify it worked
Confirm the kernel accepted the new address and routing table. The ip command shows the live state, while nmcli shows the saved profile. Check both to ensure runtime and persistent states match.
Here is how to inspect the active interface and routing table.
ip addr show dev enp3s0
# Replace enp3s0 with your actual interface name
# Look for the inet line matching your static IP
ip route show
# Verify the default route points to your gateway
nmcli -f ipv4.addresses,ipv4.gateway,ipv4.dns connection show 'Wired connection 1'
# Confirms the saved profile matches what you just typed
Run ip addr first. Read the actual output before guessing.
Common pitfalls and what the error looks like
Static IP misconfigurations usually fall into three categories: address conflicts, routing loops, or DNS failures.
If you pick an IP already handed out by DHCP, two machines will claim the same address. ARP tables get confused. Packets bounce between devices. You will see intermittent drops or complete connectivity loss. NetworkManager will not stop you from saving the profile. It assumes you know your subnet. Check your router's DHCP lease table before picking an address. Pick an IP outside the DHCP pool, or shrink the DHCP pool to leave room for static assignments.
If the gateway or subnet mask is wrong, the machine can reach local devices but cannot leave the network. The terminal will show the interface as UP and RUNNING, but ping 8.8.8.8 will hang. Check your router's admin page for the correct gateway and subnet size. The /24 in 192.168.1.50/24 means the first three octets define the local network. Change it to /16 or /8 only if your network actually uses that mask.
DNS failures look like successful pings to IP addresses but failed curl or ssh commands to hostnames. NetworkManager passes the DNS servers to systemd-resolved. If you mistype the DNS field, the resolver has nowhere to send queries. Fedora ships with systemd-resolved handling DNS caching and forwarding. When you set ipv4.dns in NetworkManager, those servers get injected into the local resolver automatically. You do not need to edit /etc/resolv.conf. That file is a symlink managed by systemd. Manual edits disappear on the next reboot.
When the profile contains invalid syntax or references a missing device, activation fails with a clear message:
Error: Connection activation failed: No suitable device found for connection 'Wired connection 1' (device enp0s3 not available because device is strictly unmanaged).
This error means NetworkManager is ignoring the interface entirely. Check /etc/NetworkManager/NetworkManager.conf for unmanaged-devices rules, or verify that another network manager like systemd-networkd is not claiming the interface. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/.
If you need to see why a connection failed to activate, run journalctl -xeu NetworkManager. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style. It reads better than raw logs.
Check the gateway before you blame the firewall. Routing failures masquerade as dropped packets.
When to use this vs alternatives
Use nmcli when you need a repeatable, scriptable way to configure network profiles across multiple machines. Use nmtui when you prefer a terminal-based menu interface but still want NetworkManager to handle the backend. Use the GNOME Settings GUI when you are configuring a personal desktop and do not need to document the exact commands. Use systemd-networkd directly when you are running a minimal server image without NetworkManager and want the lowest possible dependency footprint. Stay on NetworkManager if you are switching between Wi-Fi, Ethernet, and VPNs on the same system.