How to troubleshoot a Linux network outage

A Linux network outage is easiest to diagnose when checks follow the packet path instead of starting with service restarts. The first failed layer is the useful evidence, whether it is interface state, IP addressing, default routing, gateway neighbor discovery, upstream reachability, resolver output, or local firewall policy.

The command sequence uses ip for link, address, route, and neighbor state, ping for simple reachability, and getent for the same name-service path that normal applications use. These checks are read-only except for generated ICMP traffic, so they preserve the outage state long enough to decide which layer needs a fix.

Run the checks from the affected host, container, network namespace, or VPN session. Capture the output before changing routes, resolver settings, firewall rules, or interface state, and avoid restarting networking over SSH unless console or out-of-band access is available.

Steps to troubleshoot a Linux network outage:

Check whether the affected interface has carrier.
```
$ ip -brief link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             02:00:00:00:00:10 <BROADCAST,MULTICAST,UP,LOWER_UP>
```
DOWN, missing LOWER_UP, or the wrong interface name points to a local link, cable, virtual switch, VLAN, or driver problem before routing or DNS is involved.
Related: How to check network interface link state in Linux
Check the assigned IP addresses.
```
$ ip -brief address show
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.0.2.40/24 fe80::20/64
```
A link can be UP without a usable address. Missing IPv4 or IPv6 addresses usually shifts the repair toward DHCP, static network configuration, VPN assignment, or the container/network namespace that owns the interface.

Inspect interface counters for drops or hardware errors.

$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 02:00:00:00:00:10 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
       27436250    1265      0       0       0       0
    TX:  bytes packets errors dropped carrier collsns
          46661     608      0       0       0       0

Rising errors, dropped, or carrier counters while the outage is active can point to media, driver, switch-port, or overload trouble even when the interface still shows UP.

Check the default route.
```
$ ip route show default
default via 192.0.2.1 dev eth0 proto dhcp src 192.0.2.40 metric 100
```
No default route means the host may reach only local subnets. Multiple defaults are normal on multi-homed systems only when metrics or policy routing choose the intended path.
Related: How to check the default route in Linux
Confirm the route selected for a known external IP address.
```
$ ip route get 1.1.1.1
1.1.1.1 via 192.0.2.1 dev eth0 src 192.0.2.40 uid 1000
    cache
```
Use a numeric IP so DNS does not hide the route decision. An unexpected dev, src, or gateway usually points to route metrics, policy routing, VPN split tunneling, or a stale static route.

Test the default gateway.

$ ping -c 3 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.437 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.065 ms
64 bytes from 192.0.2.1: icmp_seq=3 ttl=64 time=0.047 ms

--- 192.0.2.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2077ms
rtt min/avg/max/mdev = 0.047/0.183/0.437/0.179 ms

Replace 192.0.2.1 with the gateway from the default route. If gateway ICMP is blocked by policy, use a gateway-supported management or application probe instead.
Related: How to check gateway reachability in Linux

Check the neighbor entry for the gateway.
```
$ ip neigh show to 192.0.2.1
192.0.2.1 dev eth0 lladdr 02:00:00:00:00:01 REACHABLE
```
INCOMPLETE or FAILED means the host cannot resolve the gateway to a link-layer address, which usually moves the investigation to ARP/NDP, VLAN tagging, virtual switching, or same-segment filtering.

Test reachability beyond the gateway with a known IP address.

$ ping -c 3 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=63 time=6.59 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=63 time=6.08 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=63 time=9.16 ms

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2011ms
rtt min/avg/max/mdev = 6.077/7.275/9.156/1.346 ms

Gateway success with external-IP failure points upstream of the host, such as the router, provider edge, VPN, cloud route table, or egress firewall. If ICMP is filtered, test the affected application protocol instead of treating ping loss alone as proof.

Check name resolution through the system resolver.
```
$ getent ahosts example.com
172.66.147.243  STREAM example.com
172.66.147.243  DGRAM
172.66.147.243  RAW
104.20.23.154   STREAM
104.20.23.154   DGRAM
104.20.23.154   RAW
```
IP reachability with failed getent output points to resolver configuration, upstream DNS reachability, split-horizon DNS, search domains, or DNSSEC validation.
Related: How to check DNS resolution in Linux
Tool: DNS Record Lookup
Inspect the resolver configuration.
```
$ cat /etc/resolv.conf
# Managed by the local resolver service.
nameserver 127.0.0.53
options edns0 trust-ad
search example.net
```
A stub resolver such as 127.0.0.53 is normal on many systemd-resolved hosts, but the upstream DNS servers still need to be reachable. Use the affected hostname, not only a public test name, when private DNS or VPN search domains are involved.
Inspect local firewall policy after link, route, and resolver checks pass.
```
$ sudo nft list ruleset
table inet filter {
    chain output {
        type filter hook output priority filter; policy accept;
    }
}
```
On legacy hosts, sudo iptables -S may be the relevant view instead. Look for output-chain drops, DNS blocks, VPN kill-switch rules, or interface-specific matches tied to the first failed check.
Related: How to check firewall status in Linux
Related: How to list open ports on Linux
Fix only the first failing layer.

Missing carrier or addresses belongs to interface, DHCP, static config, or VPN repair; missing or wrong routes belong to routing repair; gateway neighbor failures belong to the local segment; external-IP failure after gateway success belongs upstream; DNS failure after IP success belongs to resolver repair; firewall drops belong to policy repair.

Do not flush firewall rules, restart all networking, or bounce the only remote interface as a first response. Those actions can hide the original failure and can disconnect the active session.
Repeat the failed check and the original application test after the repair.

Retest from the repaired layer outward. A fixed route should pass ip route get and a gateway or external-IP probe; a fixed resolver should pass getent ahosts for the affected hostname; an application outage should pass the same package download, monitoring check, SSH connection, or service request that first exposed the problem.