7 Linux Checks I Run Before Blaming the Network

Read here.

"The network is down."

If you've spent enough time troubleshooting Linux systems, you've probably heard that phrase more times than you can count.

Ironically, the network often isn't the problem.

A web server refuses connections, a database becomes unreachable, or an API starts timing out, and the network is usually the first suspect. Hours are spent inspecting firewalls, packet captures, routing tables, and DNS records, only to discover the real issue was a crashed service, a full filesystem, or a process that never opened its listening port.

Over the years, I've adopted a simple rule:

Never blame the network until you've ruled out everything that can imitate a network problem.

This mindset has saved me countless hours during production incidents. Before I launch tcpdump or start tracing packets, I perform seven quick Linux checks. Together, they eliminate the majority of false network alarms and point the investigation in the right direction.

1. Is the Service Actually Running?

A surprising number of "network issues" begin with an application that isn't running.

Users can't reach your website.

SSH connections fail.

The monitoring system reports the service as offline.

Before inspecting routes or firewalls, verify the service itself.

systemctl status nginx

systemctl status nginx

or

systemctl status apache2

systemctl status apache2

For databases:

systemctl status postgresql

systemctl status postgresql

Look for clues like:

• failed startup
• crash loops
• missing configuration files
• permission errors
• dependency failures

If the service never started, no amount of networking expertise will make it reachable.

2. Is Anything Listening on the Expected Port?

A running process doesn't necessarily mean clients can connect.

Applications must successfully bind to a listening socket.

One command answers this immediately:

ss -tulpn

ss -tulpn

Example:

tcp LISTEN 0 511 0.0.0.0:80

tcp LISTEN 0 511 0.0.0.0:80

If your application should expose port 8080, but ss shows nothing, you've already narrowed the problem considerably.

Possible causes include:

• configuration errors
• incorrect bind address
• port conflicts
• startup failures

Until a process listens on the expected port, the network isn't your bottleneck.

3. Can the Server Reach Itself?

Before testing external connectivity, test locally.

For web applications:

curl http://localhost

curl http://localhost

or

curl http://127.0.0.1

curl http://127.0.0.1

If local requests fail, the issue exists entirely inside the machine.

That eliminates:

• routers
• switches
• load balancers
• VPNs
• Internet connectivity

If localhost works but remote clients fail, your investigation can move outward toward networking.

Think of localhost as your control experiment.

4. Are System Resources Healthy?

Infrastructure problems frequently disguise themselves as networking failures.

A server under heavy resource pressure becomes slow enough that clients assume packets are being dropped.

Check CPU load:

uptime

uptime

Check memory:

free -h

free -h

Check disk usage:

df -h

df -h

Check inodes:

df -i

df -i

Watch for:

• disks at 100%
• exhausted memory
• excessive swapping
• high load averages
• inode exhaustion

I've seen production APIs become "unreachable" simply because the filesystem was full and the application couldn't write log files anymore.

The network was perfectly healthy.

5. Are DNS Problems Masquerading as Connectivity Problems?

Users often report:

"The server is offline."

In reality:

Only DNS failed.

Test hostname resolution.

dig api.example.com

dig api.example.com

or

host api.example.com

host api.example.com

Compare that with a direct IP test.

curl http://203.0.113.15

curl http://203.0.113.15

If the IP works while the hostname fails, you've isolated the problem to DNS rather than connectivity.

Experienced engineers separate name resolution from network transport because they're completely different systems.

6. What Do the Logs Say?

Linux rarely fails silently.

Applications, services, and the kernel leave evidence behind.

Inspect recent service logs.

journalctl -u nginx

journalctl -u nginx

System-wide errors:

journalctl -p err -b

journalctl -p err -b

Kernel events:

journalctl -k

journalctl -k

Or:

dmesg

dmesg

Typical findings include:

• permission denied
• certificate loading failures
• segmentation faults
• out-of-memory events
• failed dependencies

Many "network outages" become obvious after reading only a few log entries.

7. Verify the Routing Table

Only after the previous checks pass do I begin examining networking itself.

Start with the routing table.

ip route

ip route

Example:

default via 192.168.1.1 dev eth0

default via 192.168.1.1 dev eth0

Confirm:

• default gateway exists
• correct interface is used
• expected subnet appears
• static routes are present

Then verify interface status.

ip addr

ip addr

Finally, inspect connectivity.

ping

ping

or

tracepath

tracepath

or

traceroute

traceroute

At this stage, if the service is healthy, resources are available, logs show no failures, DNS works, sockets are listening, and routing appears correct, then the investigation can legitimately move toward firewalls, switches, routers, or upstream providers.

Now you're debugging the network, not assuming it's guilty.

A Real Example

A development team once reported that their API had become unreachable after a deployment.

Their first conclusion:

"Something changed in the firewall."

Before reviewing firewall rules, we ran the checklist.

Service status

Running.

Listening ports

Nothing on port 8080.

The deployment introduced a configuration typo that caused the application to bind to 127.0.0.1 instead of 0.0.0.0.

The service was alive.

The network was healthy.

Remote clients simply couldn't reach a socket that was only accepting local connections.

The fix required changing one configuration value, not rebuilding firewall rules or replacing network hardware.

The entire investigation took less than ten minutes because we started with evidence instead of assumptions.

Why This Workflow Works

Experienced Linux administrators don't troubleshoot from the outside in.

They troubleshoot from the inside out.

The machine itself provides the highest-quality evidence.

If the application isn't running, packets won't help.

If no socket is listening, routing doesn't matter.

If the disk is full, changing firewall rules accomplishes nothing.

Every check removes an entire category of possible failures.

That's what makes troubleshooting efficient.

My Pre-Network Checklist

Whenever someone says, "It's probably the network," I mentally run through this list:

1. Is the service running?
2. Is it listening on the expected port?
3. Does localhost work?
4. Are CPU, memory, and storage healthy?
5. Is DNS resolving correctly?
6. Do the logs explain the failure?
7. Is routing configured correctly?

Most incidents are solved before I even open a packet capture.

Final Thoughts

Networking is one of the most complex layers of any Linux system, but it's also one of the most frequently blamed without evidence.

In reality, many "network problems" originate in application configuration, service management, resource exhaustion, or simple operational mistakes.

The fastest troubleshooters aren't the ones who know the most networking commands, they're the ones who eliminate impossible causes before chasing unlikely ones.

The next time an application becomes unreachable, resist the temptation to blame the network immediately.

Run these seven checks first.

More often than not, the answer is already waiting inside the server.