Network diagnostics on Fedora
You try to load a website and the browser hangs. The spinner turns for a minute, then returns a timeout error. You restart the router, but the problem persists. You need to know if the issue is your DNS configuration, a broken link in your local network, a congested route at your ISP, or a failure at the destination server. Guessing wastes time. Fedora provides tools to isolate the failure layer by layer.
How network failures break down
Network connectivity relies on three distinct steps. First, the system must translate a domain name into an IP address using DNS. Second, the local interface must be active and have a valid route to the gateway. Third, packets must traverse the network path without being dropped or blocked.
Think of sending a physical package. DNS is the address lookup service. If the address is wrong, the package never leaves the warehouse. The local interface is your mailbox. If the mailbox is closed, the courier cannot pick up the package. Routing is the truck route. If a bridge is out halfway to the destination, the package gets stuck. Packet loss is a damaged truck that drops packages at a specific sorting facility.
Use the right tool for each step. dig checks the address. ip checks the mailbox. mtr and traceroute check the route.
Install the diagnostic tools
Fedora includes basic networking utilities, but the full diagnostic suite requires a few packages. bind-utils provides dig. mtr and traceroute are separate packages. Install them together to avoid missing dependencies later.
sudo dnf install traceroute mtr bind-utils
# bind-utils provides dig for DNS queries.
# mtr combines ping and traceroute for continuous monitoring.
# traceroute maps the path to a destination.
# dnf resolves all dependencies automatically. No manual library installs needed.
Run dnf upgrade --refresh periodically to keep these tools updated. The refresh flag forces dnf to fetch fresh metadata, ensuring you get the latest security fixes for network utilities.
Verify DNS resolution with dig
DNS failures are the most common cause of "site not loading" errors. If the domain name does not resolve to an IP address, no amount of routing analysis will help. dig queries DNS servers directly and shows the raw response, bypassing browser caches and application-level resolvers.
Here is how to check if a domain resolves correctly using the system's default resolver.
dig example.com
# Queries the default DNS server configured by systemd-resolved.
# Returns the A record and full DNS response headers.
# Look for status: NOERROR in the output.
# A status of SERVFAIL or NXDOMAIN indicates a DNS problem.
If dig returns status: SERVFAIL, the upstream DNS server is unreachable or returning errors. This is not a local network issue. The error usually looks like this in the terminal output.
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
To rule out a broken local resolver, query a public DNS server directly. If the public server works, the problem is your local DNS configuration or the ISP's DNS servers.
dig @8.8.8.8 example.com
# Queries Google Public DNS directly, bypassing local resolver.
# If this succeeds but the default query fails, your local DNS is broken.
# Use this to isolate DNS issues from routing issues.
Fedora uses systemd-resolved to manage DNS. The system resolver listens on 127.0.0.53 and forwards queries to the servers provided by NetworkManager. Check the active configuration with resolvectl.
resolvectl status
# Shows the current DNS servers for each interface.
# Displays the cache state and fallback DNS servers.
# Use this to verify which upstream servers your system is actually using.
Do not edit /etc/resolv.conf manually on Fedora Workstation. The file is managed by systemd-resolved and is often a symlink to /run/systemd/resolve/stub-resolv.conf. Manual edits get overwritten on reboot or network change. Use nmcli or resolvectl to modify DNS settings. Files in /etc/ are user-modified, but some are managed by services. Respect the management boundaries.
Check DNS first. A wrong IP address makes every subsequent ping look like a routing failure.
Check local interfaces and routing
If DNS resolves correctly, verify that the local network interface is active and has a valid route. A disabled interface or missing default gateway stops all traffic before it leaves the machine.
Here is how to inspect interface states and the routing table.
ip link show
# Lists all network interfaces and their operational state.
# Look for state UP on your active interface.
# State DOWN means the interface is disabled or the cable is unplugged.
# Fedora uses iproute2. Avoid deprecated tools like ifconfig.
ip route show
# Displays the kernel routing table.
# The default route determines where traffic goes when no specific route matches.
# Verify the default gateway matches your router's IP address.
If the interface shows state DOWN, bring it up with nmcli. If the default route is missing, check your NetworkManager connection profile.
nmcli connection up <connection-name>
# Activates the specified NetworkManager connection profile.
# Restores the interface state and applies IP configuration.
# Replace <connection-name> with the name shown in nmcli connection show.
Check the interface state before blaming the internet. A DOWN interface stops all traffic locally.
Analyze path and loss with mtr
Once DNS and local configuration are verified, use mtr to analyze the network path. mtr combines the functionality of ping and traceroute into a continuous monitor. It sends probes to each hop and reports packet loss, latency, and jitter over time.
Here is how to run mtr in report mode for a concise summary.
mtr -c 50 --report example.com
# Sends 50 probes per hop and prints a summary report.
# The Loss% column shows packet loss at each router.
# High loss at an intermediate hop indicates a congested or broken link upstream.
# Loss only at the final hop usually indicates a problem with the destination server.
Focus on the Loss% and Avg columns. A loss of 0% with low average latency means the path is healthy. If loss appears at hop 3 and persists through hop 10, the issue is upstream at hop 3. If loss appears only at the last hop, the destination server is dropping packets or is overloaded.
Run mtr for at least 30 seconds. A single spike is noise. Consistent loss is a problem.
Trace routes through firewalls with traceroute
Standard traceroute uses UDP or ICMP probes. Many intermediate routers and firewalls block these probes to reduce noise or for security reasons. When you see * * * in the output, the router is likely dropping the probe, not the actual traffic. This can make it look like the path is broken when it is actually working.
Here is how to use TCP-based tracing to bypass firewall blocks.
sudo traceroute -T -p 443 example.com
# Uses TCP SYN packets instead of UDP or ICMP.
# Targets port 443, which is rarely blocked by intermediate firewalls.
# Requires sudo to craft raw packets for the TCP handshake.
# This method often reveals the true path when standard traceroute fails.
If traceroute -T shows a complete path with reasonable latency, your connection is fine. The * * * in standard mode was just a firewall hiding the hop. TCP tracing mimics a real HTTPS connection, so firewalls usually allow it through.
If you see asterisks, switch to TCP mode. The path exists, but the router is hiding.
Common pitfalls and error patterns
Network diagnostics often trip up on edge cases. Recognizing these patterns saves time.
ICMP blocking is common. Many corporate networks and ISPs block ping requests. If ping fails but mtr shows 0% loss on the TCP path, ICMP is blocked. Do not assume the network is down just because ping returns no reply.
DNS caching can cause stale data. If a site moved to a new IP but you still see the old IP, your resolver might be caching the old record. Flush the cache with resolvectl.
resolvectl flush-caches
# Clears the DNS cache in systemd-resolved.
# Forces fresh queries for all domains on the next request.
# Use this after DNS records change to avoid stale data issues.
SELinux denials rarely affect network tools, but they can block custom scripts from binding to sockets. If a diagnostic script fails with permission errors, check journalctl -t setroubleshoot. SELinux denials appear there with a one-line summary. Read the denial before disabling SELinux. The solution is usually a file context fix or a policy module, not disabling the security framework.
Read the error code. SERVFAIL means the server is broken, not your network. NXDOMAIN means the name does not exist. REFUSED means the server rejected the query. Treat each code differently.
Tool selection matrix
Use dig when you need to verify DNS resolution or check specific record types like MX or TXT. Use ping when you want a quick check of basic IP reachability and latency. Use mtr when you suspect packet loss or latency spikes and need to identify the exact hop causing the degradation. Use traceroute when you need to map the full route or when firewalls block standard probes and you require TCP-based tracing.