Welcome aboard!
Always exploring, always improving.

Linux Server Network Troubleshooting: Six Common Scenarios and Solutions

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 response
  • curl 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:

  1. ip a – Verify that the network interface has an assigned IP address.
  2. ip route – Check for the existence of a default gateway.
  3. ping 8.8.8.8 – Test direct connectivity to a public IP (Google DNS).
  4. 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 with sudo 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 as 8.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:

  1. ss -lntup or netstat -lntup – Confirm if your service is listening on the expected port.
  2. ss -lntup | grep 8080 – Filter the output to check a specific port.
  3. iptables -L -n – Check legacy iptables rules for any blocked ports.
  4. firewall-cmd --list-all or sudo ufw status – Inspect active firewall settings.
  5. 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 on 0.0.0.0.
  • Open the port using sudo iptables -A INPUT -p tcp --dport 8080 -j ACCEPT or firewall-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:

  1. ip a – Confirm that each host has a correct IP and subnet mask.
  2. ip route – Validate routing table entries.
  3. ping <other_host_IP> – Check direct connectivity.
  4. arp -a – View ARP cache.
  5. sudo tcpdump -i eth0 icmp – Capture ICMP packets.
  6. 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:

  1. ping www.yoursite.com -c 4 – Measure latency.
  2. traceroute www.yoursite.com – Check path and hops.
  3. curl -w "@curl-format.txt" -o /dev/null -s http://your_site – Analyze response timings.
  4. 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, but curl 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:

  1. ss -lntup | grep <port> – Check service bind address.
  2. curl localhost:<port> – Local test.
  3. curl <public_ip>:<port> – Remote test.
  4. iptables -L – View firewall rules.
  5. firewall-cmd --list-all or ufw 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:

  1. On server: iperf3 -s
  2. 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!

Like(0) Support the Author
Reproduction without permission is prohibited.FoxDoo Technology » Linux Server Network Troubleshooting: Six Common Scenarios and Solutions

If you find this article helpful, please support the author.

Sign In

Forgot Password

Sign Up