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.comreturns no responsecurlreports “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 ashows no IP, the network interface may be down. Bring it up withsudo ip link set <interface> upor restart the network service. - If pinging an IP works but domain names fail, it’s a DNS problem. Ensure
/etc/resolv.conflists 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 -lntupornetstat -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-allorsudo 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 ACCEPTorfirewall-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.denyblocks 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.txtwith%{time_namelookup},%{time_connect},%{time_starttransfer}.
Troubleshooting Steps:
- High latency may indicate network congestion.
traceroutehelps locate the delay point.- Use
curlto isolate where delays occur. - Too many connections? Scale up or load balance.
Scenario 5: Service Listens Locally but Is Inaccessible Remotely
Symptoms:
curl localhost:portworks, butcurl public_ip:portfails- 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-allorufw status– Inspect firewall state.
Troubleshooting Steps:
- Rebind service to
0.0.0.0if 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!

FoxDoo Technology







