Story opener
You rebooted your Fedora machine after a routine update and the desktop loads, but every browser tab shows a connection error. Or you plugged in an Ethernet cable and the system refuses to recognize the link. Network failures on Linux rarely happen randomly. They follow a predictable stack from the physical cable up to the application layer. Work through that stack in order. You will isolate the broken layer before you waste time guessing.
What is actually happening
Linux networking is a pipeline. The kernel driver talks to the hardware. NetworkManager negotiates an IP address with your router. The routing table tells the kernel where to send packets. DNS translates names to addresses. The firewall decides what gets through. If any single stage drops the ball, your browser sees nothing but a timeout. Think of it like a postal system. A missing street address, a broken sorting machine, or a locked mailbox will all stop the letter from arriving. You need to check each checkpoint until you find the one that is actually blocking the flow.
Check the physical link and interface state
Start at the bottom. Verify that the kernel detects the network interface and that the hardware reports an active link. Fedora uses ip from the iproute2 package as the standard interface tool. NetworkManager relies on these same kernel states to decide whether to manage a connection.
Here is how to list every interface and check its operational state.
# Show all interfaces, their indices, and link state
ip link show
# Check for assigned IPv4 and IPv6 addresses
ip addr show
Look for state UP and LOWER_UP in the output. UP means the kernel has enabled the interface. LOWER_UP means the physical link detected a carrier signal. If you see state DOWN or NO-CARRIER, the cable is unplugged, the switch port is off, or the wireless radio is disabled. If the interface is administratively down but should be active, bring it up manually.
# Force the kernel to enable the interface
sudo ip link set eth0 up
# Verify the state changed to UP
ip link show eth0
If the interface stays down after running the command, the hardware or driver is failing. Check dmesg | grep -i eth for driver initialization errors. If the interface comes up but NetworkManager still ignores it, the daemon might have marked it as unmanaged.
Bring the interface up manually only if NetworkManager is completely unresponsive. Otherwise, let the daemon handle it.
Verify IP assignment and gateway reachability
An active link means nothing without an IP address and a route to the outside world. Fedora assigns addresses through DHCP by default. NetworkManager requests the lease and programs the kernel routing table. If the DHCP handshake fails, you will have a link but no connectivity.
Here is how to find your default gateway and test whether the router replies.
# Print the default route and extract the gateway IP
ip route show default
# Send four ICMP echo requests to the gateway
ping -c 4 $(ip route show default | awk '/default/ {print $3}')
A successful ping to the gateway proves your machine can talk to the local network. If the gateway responds but you cannot reach the internet, the problem lives outside your machine. Check your router, modem, or ISP status. If the gateway does not respond, the issue is local. Your DHCP client likely failed to obtain an address, or a local firewall rule is dropping ICMP.
Restart NetworkManager to force a fresh DHCP request. The daemon will tear down the stale connection and negotiate a new lease.
# Restart the network management daemon
sudo systemctl restart NetworkManager
# Wait ten seconds, then check the device status
nmcli device status
If nmcli shows connected but you still have no IP, check the connection profile. Run nmcli connection show and look for the ipv4.method field. It should read auto. If it reads manual, the profile is using a static address that does not match your network.
Reboot before you debug. Half the time the DHCP lease is stuck in a half-negotiated state and a fresh boot clears it.
Test DNS resolution
IP connectivity works, but fedoraproject.org times out. That points directly to DNS. Fedora ships with systemd-resolved as the default DNS stub resolver. It caches queries, supports DNSSEC, and forwards requests to the nameservers provided by DHCP. If the stub resolver is misconfigured or the upstream servers are unreachable, name resolution fails while raw IP traffic still flows.
Here is how to test whether your system can translate domain names to addresses.
# Query the local stub resolver for a domain
resolvectl query fedoraproject.org
# Bypass the local cache and query a public resolver directly
dig fedoraproject.org @1.1.1.1
If resolvectl returns Server returned error NXDOMAIN or times out, your local resolver is not forwarding correctly. If dig @1.1.1.1 succeeds, the problem is strictly in your local DNS configuration. Check /etc/resolv.conf. On modern Fedora systems, this file is a symlink to /run/systemd/resolve/stub-resolv.conf. Never edit the symlink target directly. Edit the NetworkManager connection profile instead.
# Check where resolv.conf actually points
ls -l /etc/resolv.conf
# View the active DNS servers for the current connection
resolvectl status
If the DNS servers listed under Current DNS Server are missing or point to 127.0.0.53 without upstream fallback, your DHCP lease did not include DNS information. Force a renewal by toggling the connection off and on with nmcli connection down <name> followed by nmcli connection up <name>.
Flush the DNS cache if you suspect stale records. Restarting the resolver service is cleaner than editing files by hand.
Inspect firewall rules and active zones
firewalld runs by default on Fedora Workstation and Server. It uses nftables under the hood and applies rules based on zones. The public zone allows SSH and DHCP by default but drops everything else inbound. Outbound traffic is allowed unless you explicitly restrict it. A misconfigured zone or a custom rule can silently drop packets without generating a visible error.
Here is how to list the active zones and verify what traffic is permitted.
# Show all rules for the currently active zones
sudo firewall-cmd --list-all
# List which interfaces belong to which zones
sudo firewall-cmd --get-active-zones
If you see target: DROP or target: REJECT on your active zone, inbound connections will be blocked. Outbound connectivity should still work. If outbound traffic is also failing, check for custom rich rules or direct rules that might be interfering.
# List any custom rich rules that override zone defaults
sudo firewall-cmd --list-rich-rules
# Check for direct rules injected by third-party tools
sudo firewall-cmd --direct --get-all-rules
Temporarily stopping the firewall is a valid diagnostic step, but only for a few minutes. Restore it immediately after testing.
# Stop the firewall runtime configuration
sudo systemctl stop firewalld
# Test outbound connectivity
ping -c 4 1.1.1.1
# Restore the firewall and reload the persistent rules
sudo systemctl start firewalld
sudo firewall-cmd --reload
Never leave the firewall disabled to test. Use a temporary policy or a targeted rule instead.
Read the system logs
When the above steps give you nothing, the logs hold the answer. Fedora uses systemd-journald to capture kernel messages, daemon output, and service state changes. NetworkManager writes detailed connection attempts, DHCP failures, and driver errors to the journal. Reading the logs saves you from guessing.
Here is how to pull recent NetworkManager logs with explanatory context.
# Show the last 50 lines of NetworkManager logs with extra context
journalctl -u NetworkManager -n 50 --no-pager
# Search the current boot for kernel-level network events
journalctl -b -k | grep -iE "(eth|wlan|dhcp|carrier)"
The -x flag adds explanatory text from man-pages when a known error code appears. The -e flag jumps to the end of the log. Most sysadmins type journalctl -xeu NetworkManager muscle-memory style because it combines state, logs, and context in one view.
If you see [FAILED] Failed to start NetworkManager.service during boot, your network configuration probably references a missing interface name or a conflicting static route. Check /etc/NetworkManager/system-connections/ for profiles that reference hardware you no longer have. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/.
Read the actual error before guessing. The kernel and daemon will tell you exactly what failed.
Verify it worked
Run a single command that exercises the full stack. A successful response proves the link, routing, DNS, and firewall are all cooperating.
# Fetch a small text file over HTTPS to verify full stack connectivity
curl -sI https://fedoraproject.org/ | head -n 1
A HTTP/2 200 or HTTP/1.1 200 OK response means your network is fully operational. If you get a timeout, retrace your steps from the bottom up. If you get a certificate error, your system clock is likely wrong. Fix the time with timedatectl set-ntp true and try again.
Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and what the error looks like
Network troubleshooting on Fedora trips up most users in three specific places.
The first is editing /etc/resolv.conf directly. Fedora's systemd-resolved overwrites this file on every boot or connection change. Your manual nameservers vanish. Use nmcli connection modify <name> ipv4.dns "1.1.1.1 8.8.8.8" instead.
The second is ignoring SELinux denials when running custom network scripts. If you write a daemon that binds to a non-standard port, setroubleshoot will log a denial. Check journalctl -t setroubleshoot for a one-line summary. Fix the context with semanage port or restorecon before disabling SELinux.
The third is conflating dnf upgrade with dnf system-upgrade. A routine dnf upgrade --refresh updates packages but does not change the kernel or network stack. A dnf system-upgrade download --releasever=42 pulls a new release and reboots into it. If your network breaks after an update, check whether you crossed a major release boundary. Driver ABI changes between releases can drop support for older hardware.
If the boot menu is gone, GRUB rescue is your friend, not your enemy.
When to use this vs alternatives
Use ip link and ip addr when you need to verify kernel-level interface state and IP assignment. Use nmcli when you need to manage connection profiles, toggle Wi-Fi, or change DNS settings persistently. Use journalctl -xeu NetworkManager when the daemon fails to bring up a connection or drops a link unexpectedly. Use firewall-cmd --list-all when outbound traffic works but inbound services are unreachable. Use resolvectl query when IP pings succeed but domain names fail to resolve. Stay on the default NetworkManager configuration if you only deviate from the defaults occasionally.