Table of Contents
By Khimananda Oli | Last reviewed: August 2026
When a production server loses connectivity or an application times out, effective Ubuntu network troubleshooting is the difference between minutes of downtime and hours of guessing. Modern Ubuntu releases rely on Netplan and systemd-resolved rather than legacy interfaces files, making older tutorials obsolete for current deployments. This guide provides a systematic, layer-by-layer methodology to isolate faults from the physical interface up to DNS resolution.
ip link, confirming IP assignment via netplan status, testing Layer 3 reachability, and validating DNS through resolvectl. Always check UFW rules and systemd journal logs to distinguish between configuration errors and external infrastructure failures.How do you verify physical and data link connectivity in Ubuntu?
Before touching IP configurations, you must confirm the kernel sees the hardware and that the data link layer is operational. A common mistake in initial server setup is assuming the interface is up simply because the cable is plugged in. In virtualized environments like AWS EC2 or local KVM/Proxmox labs, interface names are predictable (e.g., enp3s0, eth0), but misconfigured cloud-init scripts can leave them administratively down.
Start by inspecting the interface state. The ip link command is authoritative here; ifconfig is deprecated and may not show all relevant flags.
ip link show dev enp3s0You are looking for two specific states: UP (administratively enabled) and LOWER_UP (physical carrier detected). If you see NO-CARRIER, the issue is physical: bad cable, switch port shutdown, or hypervisor vNIC detachment. If the interface is DOWN, bring it up with sudo ip link set enp3s0 up and investigate why Netplan didn't activate it at boot.
For deeper diagnostics, especially when troubleshooting MTU mismatches or duplex negotiation failures on bare metal, use ethtool:
sudo ethtool enp3s0 | grep -E "Speed|Duplex|Link detected"In cloud environments, ethtool output is often limited. Instead, rely on cloud provider metadata and monitoring dashboards to verify underlying host networking health. If the link is stable but packets aren't flowing, proceed to IP configuration validation.
How do you debug Netplan configuration errors on Ubuntu 24.04?
Since Ubuntu 18.04, Netplan has replaced /etc/network/interfaces as the primary network configuration abstraction. A frequent pain point during Ubuntu network troubleshooting is YAML syntax errors or incorrect renderer selection (networkd vs. NetworkManager). Netplan acts as a compiler: it reads YAML from /etc/netplan/*.yaml and generates backend-specific configs.
Validating configuration without breaking connectivity
Never apply changes directly to a remote server without a safety net. Use the built-in validation and rollback features:
- Edit your config:
sudo nano /etc/netplan/01-netcfg.yaml - Validate syntax:
sudo netplan generate(returns non-zero on error) - Apply with timeout:
sudo netplan apply --timeout=60
The --timeout flag is critical for remote administration. If your change breaks SSH access, Netplan automatically reverts to the previous working configuration after 60 seconds. This prevents lockouts that would otherwise require console access via IPMI or cloud VNC.
Checking applied state versus desired state
A subtle issue in 2026-era Ubuntu is that netplan apply may succeed while the backend fails to configure the interface correctly. Verify the actual runtime state:
netplan status --allThis shows the merged configuration across all YAML files and highlights discrepancies between what Netplan intends and what the system has. Pay attention to the "Renderer" field; mixing networkd and NetworkManager stanzas in different files causes unpredictable behavior. For servers, always standardize on networkd.
Common Netplan pitfalls
- Indentation errors: YAML is whitespace-sensitive. Two spaces per level, never tabs.
- Missing DHCP identifier: On some cloud providers, DHCP fails without explicitly setting
dhcp-identifier: mac. - Route metric conflicts: Multiple default routes with identical metrics cause asymmetric routing. Always set explicit metrics for multi-homed hosts.
- DNS search domain ordering: systemd-resolved respects the order in
search:blocks; incorrect ordering breaks internal service discovery.
Why is DNS resolution failing despite working ping connectivity?
This is arguably the most common scenario in modern Linux networking. You can ping 8.8.8.8 but cannot resolve hostnames. The culprit is usually systemd-resolved, which manages DNS stub listeners, caching, and DNSSEC validation. Traditional tools like nslookup bypass the system resolver entirely, giving misleading results during Ubuntu network troubleshooting.
Always use resolvectl (or its alias systemd-resolve) to query the actual system resolver:
resolvectl query example.com
resolvectl statusThe status output reveals which DNS servers are configured per-interface, whether DNSSEC is active, and if any queries are being rejected due to validation failures. If DNSSEC is causing issues with legacy internal zones, you can temporarily disable it per-link in Netplan:
network:
ethernets:
enp3s0:
dhcp4: true
nameservers:
addresses: [10.0.0.2]
search: [internal.corp]
# Disable DNSSEC for legacy internal DNS
dnssec: falseAnother frequent issue is stale /etc/resolv.conf symlinks. On a properly configured system, this should be a symlink to /run/systemd/resolve/stub-resolv.conf. If something (like a poorly written Ansible playbook) overwrites it with a static file, systemd-resolved is bypassed entirely. Restore it with:
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.confFor applications that don't use glibc (e.g., Go binaries compiled without CGO), they read /etc/resolv.conf directly. Ensure the stub resolver is listening on 127.0.0.53 and that the file points there. Tools like journalctl log parsing help identify repeated NXDOMAIN or SERVFAIL responses indicating upstream DNS problems.
How do you diagnose routing and firewall blocks on Ubuntu servers?
When link, IP, and DNS all check out but traffic still fails, the problem lies in routing or packet filtering. This is especially common after migrating workloads or applying security hardening via UFW firewall configuration.
Verifying the routing table
Use ip route get to simulate how the kernel will route a specific packet. This is more reliable than reading the full table because it accounts for policy routing, source address selection, and interface binding:
ip route get 1.1.1.1 from 10.0.1.5
ip route get 10.0.2.100 iif enp3s0If the command returns "unreachable" or selects the wrong source IP, you have a routing asymmetry. In multi-NIC setups (common in compliance environments separating management and data planes), missing return routes cause silent drops. Add explicit routes in Netplan:
routes:
- to: 10.0.2.0/24
via: 10.0.1.1
metric: 200
table: 100Debugging UFW and nftables
UFW is a frontend; the actual filtering happens in nftables (or iptables-legacy on older installs). When troubleshooting, check both layers:
sudo ufw status verbose
sudo nft list ruleset | grep -A5 "chain ufw-user-input"A subtle gotcha: UFW rules are order-dependent, and ufw allow appends to the end. If a broad deny rule exists earlier, your new allow rule never matches. Use ufw insert 1 allow ... to place rules at the correct position. Also verify that UFW is actually active and enabled at boot:
sudo systemctl status ufw
sudo ufw show addedFor complex debugging, enable kernel-level packet tracing to see exactly where drops occur:
sudo nft monitor trace
# Trigger traffic, then filter output for your source/dest IPThis shows every rule evaluation step. If packets traverse INPUT chains but never reach ACCEPT, you've found your block. Remember that Docker and Kubernetes manipulate iptables/nftables directly; UFW may show "allowed" while container networking rules silently drop traffic. Always cross-reference with iptables -L -n -v or nft list ruleset when containers are involved.
What tools provide real-time network performance visibility?
Troubleshooting isn't just about fixing broken connectivity; it's also about diagnosing intermittent latency and throughput issues. Static checks miss transient problems. Incorporate these tools into your diagnostic toolkit for comprehensive Ubuntu network troubleshooting.
| Tool | Primary Use Case | Key Advantage Over Legacy Tools |
|---|---|---|
mtr | Path analysis with loss/latency per hop | Combines ping + traceroute continuously; identifies intermittent hop degradation |
ss -tunap | Socket state inspection | Faster than netstat; shows timer info, cgroup, and BPF filters |
bpftrace | Kernel-level TCP retransmit/reason tracing | Zero-overhead observability; sees drops before userspace |
tcpdump | Packet capture for protocol analysis | Essential for TLS handshake failures, MTU issues, and application-layer bugs |
iperf3 | Bandwidth and jitter testing | Tests actual throughput independent of application; validates NIC/driver performance |
For persistent issues, integrate continuous monitoring. Tools like Netdata for real-time Linux monitoring provide per-interface bandwidth, error counters, and TCP stack metrics without manual intervention. Set alerts on interface error rates and retransmission percentages; these often degrade long before complete failure occurs. In production, correlate network metrics with application latency using distributed tracing to distinguish network-induced delays from application processing bottlenecks.
Systematic Ubuntu Network Troubleshooting Workflow
Effective Ubuntu network troubleshooting follows a deterministic path: verify link, validate Netplan config, test routing, confirm DNS resolution, and audit firewall rules. Resist the urge to skip layers; most "mysterious" outages trace back to a missed fundamentals check. Document each step's output in your incident postmortem — future you (and your on-call team) will thank you. If you're managing multiple servers or need help establishing repeatable diagnostic runbooks, reach out to discuss infrastructure reliability consulting tailored to your environment.
