Linux server network troubleshooting is an essential skill for every system administrator responsible for maintaining reliable services. When your server suddenly loses connectivity, experiences slow response times, or refuses to communicate with other machines, your first question often is: “Where’s the issue?” This comprehensive guide will walk you through six of the most frequent network problem scenarios on Linux, complete with practical commands to identify and fix each issue. By following these tips, you’ll be equipped to pinpoint the root causes faster, minimize downtime, and keep your systems running smoothly.
Scenario 1: Server Cannot Reach the Public Internet
Symptoms:
ping www.example.com
returns no responsecurl
reports “Could not resolve host”
When your Linux server can’t access the public internet, start by checking if it has a valid IP address and gateway. Without a proper IP configuration, your server is essentially invisible to external networks.
Commands to Run:
ip a
– Verify that the network interface has an assigned IP address.ip route
– Check for the existence of a default gateway.ping 8.8.8.8
– Test direct connectivity to a public IP (Google DNS).cat /etc/resolv.conf
– Inspect DNS settings for correct nameserver entries.
Troubleshooting Steps:
- If
ip a
shows no IP, the network interface may be down. Bring it up withsudo ip link set <interface> up
or restart the network service. - If pinging an IP works but domain names fail, it’s a DNS problem. Ensure
/etc/resolv.conf
lists a valid DNS server, such as8.8.8.8
. - Sometimes corporate or cloud environments restrict external access. In such cases, confer with your network engineer, as local restrictions may block all outbound traffic.
Scenario 2: Service Is Running but Unreachable
Symptoms:
- Web page or API request times out
- Application cannot connect to a specific port
A service that appears healthy but doesn’t accept external connections can be perplexing. Before blaming the application, verify if it’s listening on the correct interface and that firewall rules aren’t blocking traffic.
Commands to Run:
ss -lntup
ornetstat -lntup
– Confirm if your service is listening on the expected port.ss -lntup | grep 8080
– Filter the output to check a specific port.iptables -L -n
– Check legacy iptables rules for any blocked ports.firewall-cmd --list-all
orsudo ufw status
– Inspect active firewall settings.telnet localhost 8080
– Attempt to connect locally, or from a remote machine:telnet <server_ip> 8080
.
Troubleshooting Steps:
- If the service is bound only to
127.0.0.1
, reconfigure it to listen on0.0.0.0
. - Open the port using
sudo iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
orfirewall-cmd --add-port=8080/tcp --permanent && firewall-cmd --reload
. - Check cloud provider security groups.
- Restart the service and monitor logs for errors.
Scenario 3: Two Machines on the Same LAN Cannot Ping Each Other
Symptoms:
- Host A cannot ping Host B, yet Host B can ping the gateway
- Private network communication fails
Local network issues often boil down to misconfigured IPs, incorrect netmasks, or ARP table problems. Ensuring that both machines believe they’re on the same subnet is crucial.
Commands to Run:
ip a
– Confirm that each host has a correct IP and subnet mask.ip route
– Validate routing table entries.ping <other_host_IP>
– Check direct connectivity.arp -a
– View ARP cache.sudo tcpdump -i eth0 icmp
– Capture ICMP packets.cat /etc/hosts.deny
– Check for restrictions.
Troubleshooting Steps:
- Correct any subnet mismatch.
- Ensure ARP resolution is working.
- Check if
hosts.deny
blocks ICMP. - Capture packets to verify ICMP flow.
Scenario 4: Website Is Slow or Frequently Timing Out
Symptoms:
- Slow page loads or 504 Gateway Timeout
- Increased latency during peak hours
Website performance can degrade due to DNS delays, latency, or overload. These tools can help.
Commands to Run:
ping www.yoursite.com -c 4
– Measure latency.traceroute www.yoursite.com
– Check path and hops.curl -w "@curl-format.txt" -o /dev/null -s http://your_site
– Analyze response timings.netstat -antp | grep ESTABLISHED | wc -l
– Check active connections.
Note: Customize
curl-format.txt
with%{time_namelookup}
,%{time_connect}
,%{time_starttransfer}
.
Troubleshooting Steps:
- High latency may indicate network congestion.
traceroute
helps locate the delay point.- Use
curl
to isolate where delays occur. - Too many connections? Scale up or load balance.
Scenario 5: Service Listens Locally but Is Inaccessible Remotely
Symptoms:
curl localhost:port
works, butcurl public_ip:port
fails- Only local loopback connections succeed
This often means a service is bound to 127.0.0.1
or blocked by a firewall. Update configs accordingly.
Commands to Run:
ss -lntup | grep <port>
– Check service bind address.curl localhost:<port>
– Local test.curl <public_ip>:<port>
– Remote test.iptables -L
– View firewall rules.firewall-cmd --list-all
orufw status
– Inspect firewall state.
Troubleshooting Steps:
- Rebind service to
0.0.0.0
if needed. - Allow port through firewalls and routers.
- Check cloud security groups.
- Disable firewall briefly to test, then refine rules.
Scenario 6: Checking If Bandwidth Is Too Low
Symptoms:
- Throughput tests don’t saturate the link
- Slow file transfers even when idle
Use iperf3
to test bandwidth and find bottlenecks.
Commands to Run:
- On server:
iperf3 -s
- On client:
iperf3 -c <server_IP>
Troubleshooting Steps:
- Ensure same switch/router for local tests.
- Cross-region slowness? It may be ISP interconnects.
- Check for faulty cables, misconfigured VLANs, bad NICs.
- Upgrade equipment or ISP plan if needed.
Conclusion
Mastering Linux server network troubleshooting is about understanding common failure scenarios and applying the right diagnostic commands. Whether it’s a DNS misconfiguration, a misbound service, or a congested link, quick identification leads to faster resolution. Next time your server loses connectivity or performs poorly, use this guide to isolate the issue, correct underlying misconfigurations, and restore optimal performance. Happy troubleshooting!