Your Linux server is running, the application is up, and the service shows active (running) — but users still cannot connect.
What do you check first?
This is where Linux networking commands become extremely useful.
A Linux administrator does not always need a graphical monitoring tool to find a network problem. With a handful of commands, you can check the server's IP address, network interface, routing table, DNS resolution, open ports, connectivity, and active connections directly from the terminal.
The important part is not memorizing dozens of commands. It is knowing which command to use when something goes wrong.
1. ip – The Command You Will Use Most:
If you manage modern Linux systems, start with the `ip` command.
The ip utility is part of the iproute2 networking tools and can work with network interfaces, IP addresses, routes, network namespaces, tunnels, and more.
Check IP addresses
ip addr
A shorter version is:
ip a
Example:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
inet 192.168.10.20/24
This tells you that the interface has the IP address:
192.168.10.20
with a /24 prefix.
For administrators, this is usually the first command to run when someone says:
"The server is not reachable."
Check a specific interface
ip addr show eth0
or:
ip link show eth0
Check whether an interface is up
ip link
Look for:
UP
LOWER_UP
If the interface is DOWN, the server may not have network connectivity through that interface.
You can bring an interface up with:
sudo ip link set eth0 up
The ip link family of commands is specifically used for network device configuration.
2. ip route – Find Where Traffic Is Going
Having an IP address does not automatically mean the server knows where to send traffic.
Check the routing table with:
ip route
Example:
default via 192.168.10.1 dev eth0
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.20
The important line is:
default via 192.168.10.1
This is the server's default gateway.
Why is this useful?
Suppose:
ping 192.168.10.50
works, but:
ping 8.8.8.8
fails.
One possibility is a routing or gateway problem.
You can also ask Linux which route it would use for a particular destination:
ip route get 8.8.8.8
This is particularly useful on servers with multiple network interfaces or multiple routes.
3. ping – Check Basic Connectivity
ping is probably the first networking command most Linux administrators learn.
ping 192.168.10.1
For a limited test:
ping -c 4 192.168.10.1
The -c 4 option sends four packets and then stops.
Test an external IP
ping -c 4 8.8.8.8
This can help determine whether the server can reach an external IP address.
Test a hostname
ping -c 4 google.com
This tests more than basic connectivity because the hostname must first be resolved to an IP address.
However, don't treat a failed ping as absolute proof that a server is unreachable.
Many production servers and firewalls block ICMP, while still allowing HTTP, HTTPS, SSH, or other application traffic.
4. ss – Check Listening Ports and Connections
A service can be running but still be unavailable to users.
For example, Apache may show:
systemctl status httpd
as running, but that does not tell you whether it is actually listening on the expected port.
This is where `ss` is useful.
The ss command displays socket information and can show TCP and UDP connections, listening sockets, ports, states, and more.
Show listening TCP ports
ss -lnt
Example:
State Local Address:Port
LISTEN 0.0.0.0:22
LISTEN 0.0.0.0:80
LISTEN 0.0.0.0:443
This tells you that the server is listening on:
• 22 – SSH
• 80 – HTTP
• 443 – HTTPS
Show the process using the port
sudo ss -lntp
This is one of the most useful commands when troubleshooting web servers.
For example:
LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("httpd",pid=1256))
Now you know which process owns port 80.
Check established connections
ss -tn
You can also look specifically for SSH:
ss -tn sport = :22
The ss command supports filtering by TCP state, source/destination address, and source/destination port, making it much more useful than simply dumping every connection.
5. hostname – Quickly Identify the Server
When you work with several Linux servers, knowing which machine you are logged into matters.
Run:
hostname
For more detailed information:
hostnamectl
Example:
Static hostname: web-server-01
Operating System: Red Hat Enterprise Linux
Architecture: x86-64
This sounds simple, but it can save you from making a very expensive mistake when multiple production servers look almost identical.
6. nmcli – Manage NetworkManager from the Terminal
On Linux distributions using NetworkManager, nmcli provides a command-line way to inspect and manage network connections.
List available connections:
nmcli connection show
Show active connections:
nmcli connection show --active
Display device status:
nmcli device status
Example:
DEVICE TYPE STATE CONNECTION
eth0 ethernet connected System eth0
lo loopback connected lo
Display detailed information
nmcli device show eth0
This can expose information such as:
• IP address
• Gateway
• DNS
• Interface state
• Connection details
For administrators working with RHEL-based systems, nmcli is especially useful when diagnosing NetworkManager-managed configurations.
7. traceroute – Find Where the Path Breaks
Sometimes a server can reach the internet, but a particular destination cannot be reached.
traceroute helps identify the path packets take toward a destination.
traceroute example.com
A typical result may look like:
1 192.168.10.1
2 10.10.0.1
3 203.0.113.10
4 ...
Each line represents a hop between the source and destination.
When should you use it?
Use traceroute when:
• A remote server is unreachable
• Traffic appears to stop somewhere in the network
• You suspect a routing problem
• You want to understand the path to a remote system
Depending on the distribution, the command may need to be installed separately.
8. dig – Troubleshoot DNS
A website may be accessible by IP address but fail when using its hostname.
That immediately makes DNS worth checking.
Use:
dig example.com
Look for the ANSWER SECTION.
For example:
example.com. 300 IN A 93.184.216.34
This tells you that the DNS query returned an IPv4 address.
Query a specific DNS server
dig @8.8.8.8 example.com
This is useful when you suspect that the configured DNS server is having problems.
Check the configured resolver
On many modern Linux systems:
cat /etc/resolv.conf
You may see:
nameserver 192.168.10.1
DNS problems are often confused with general network problems. dig helps separate the two.
9. nslookup – Another DNS Troubleshooting Tool
nslookup is another familiar tool for DNS queries.
nslookup example.com
Example:
Name: example.com
Address: 93.184.216.34
For newer troubleshooting workflows, many administrators prefer dig because it provides more detailed DNS information, but nslookup is still useful for quick checks.
10. curl – Test the Application, Not Just the Network
Imagine this:
ping example.com
works.
The route is correct.
DNS works.
But the website still does not respond.
Now test the actual HTTP service.
curl http://example.com
For headers only:
curl -I http://example.com
Example:
HTTP/1.1 200 OK
Content-Type: text/html
This is much closer to what a web browser is actually doing.
Test a local web server
curl http://localhost
If this works:
<html>
...
</html>
but this fails:
curl http://192.168.10.20
you have a useful clue.
The web service may be working locally, while something related to interface binding, firewall rules, routing, or external access is preventing remote connections.
11. tcpdump – See the Packets
When normal commands do not provide enough information, tcpdump can show what is actually happening on the network interface.
For example:
sudo tcpdump -i eth0
This captures packets arriving at or leaving eth0.
Capture HTTP traffic
sudo tcpdump -i eth0 port 80
Capture traffic from a specific host
sudo tcpdump -i eth0 host 192.168.10.50
Why is tcpdump powerful?
Suppose a client says:
"I am connecting to port 80, but the server doesn't respond."
You can run:
sudo tcpdump -i eth0 port 80
If you see incoming packets, the request is reaching the server.
If you see nothing, the problem may be somewhere before the server.
This distinction can save a lot of troubleshooting time.
12. arp / ip neigh – Check Local Network Neighbors
On modern Linux systems, you will commonly use:
ip neigh
Example:
192.168.10.1 dev eth0 lladdr 00:11:22:33:44:55 REACHABLE
This displays the neighbor/ARP information known to the system.
You can think of it as Linux asking:
"What MAC address should I use when I want to communicate with this IP address on the local network?"
The ip utility includes neighbor management as part of its networking functionality.
13. hostname -I – Get the Server IP Quickly
Sometimes you don't need the full output of ip addr.
Use:
hostname -I
Example:
192.168.10.20
It is handy for quick checks and scripts.
For detailed troubleshooting, however, use:
ip addr
because it provides interface state, addresses, and additional information.
A Practical Linux Network Troubleshooting Sequence:
When a Linux server cannot communicate with another system, don't randomly run commands.
Work from the bottom up.
Step 1: Check the interface
ip link
Is the interface UP?
Step 2: Check the IP address
ip addr
Does the interface have the expected IP address?
Step 3: Check the route
ip route
Is there a valid default gateway or route to the destination?
Step 4: Test the gateway
ping -c 4 192.168.10.1
Step 5: Test the destination IP
ping -c 4 192.168.10.50
Step 6: Test DNS
dig example.com
Step 7: Test the application
curl -I http://example.com
Step 8: Check listening ports
sudo ss -lntp
Step 9: Check the packet flow
sudo tcpdump -i eth0
This approach is much more effective than immediately changing firewall rules or restarting network services.
Linux Networking Commands Cheat Sheet:
A Simple Way to Remember Them
You don't need to memorize every option of every command.
Remember what question each command answers:
What is my network configuration?
ip addr
Is my interface working?
ip link
Where will traffic go?
ip route
Can I reach the destination?
ping
Is the service listening?
ss -lntp
Can DNS resolve the name?
dig
Does the application respond?
curl
Where is the traffic going?
traceroute
Are packets actually reaching the server?
tcpdump
That small set of commands covers a surprisingly large portion of everyday Linux networking troubleshooting.
Final Thoughts:
Linux networking becomes much easier when you stop treating connectivity problems as a single issue.
A failed website request could be caused by a down interface, incorrect IP address, missing route, DNS failure, blocked port, inactive service, firewall rule, or an application that is listening only on localhost.
The key is to troubleshoot each layer instead of guessing.
Start with:
ip addr
ip route
ping
ss
dig
curl
Then move to tools such as traceroute and tcpdump when you need deeper visibility.
Once these commands become part of your daily workflow, the terminal becomes more than a place to run services — it becomes one of your best network troubleshooting tools.
Author:
Adhav Maldhan
Adhav Maldhan
Expert trainer and consultant at SevenMentor with years of industry experience. Passionate about sharing knowledge and empowering the next generation of tech leaders.