DEV Community

Kervie Sazon
Kervie Sazon

Posted on

Linux Networking Commands to Master

#beginners #cli #linux #networking

As a beginner in networking and platform engineering, there are five Linux commands that I must understand deeply:

  • ping
  • ip addr
  • ss
  • curl
  • dig

I realized that troubleshooting isn’t about memorizing commands — it’s about understanding where the problem lives.

ping — Is the Server Reachable?

ping helps answer the most basic question:

Can I reach this machine?

Example:

ping 8.8.8.8
Enter fullscreen mode Exit fullscreen mode

If I get replies, network connectivity exists.

If I get timeouts, the issue could be routing, firewall rules, or the server being down.

This is usually my first troubleshooting step.

ip addr — Who Am I on the Network?

Before checking anything else, I need to know:

  • Do I have an IP address?
  • Is my interface up?
  • What subnet am I in? 
ip addr
Enter fullscreen mode Exit fullscreen mode

If there’s no IP address assigned, nothing else will work.

This command confirms my server’s identity in the network.

ss — Is the Service Listening?

Even if the network works, the application might not be running.

ss -tuln
Enter fullscreen mode Exit fullscreen mode

If I expect a web server on port 80:

ss -tuln | grep 80
Enter fullscreen mode Exit fullscreen mode

If nothing shows up, the service is not listening.

This helps me determine whether the issue is network-related or application-related.

curl — Is the Application Responding?

ping checks connectivity.

curl checks whether the application responds.

curl http://localhost:80
Enter fullscreen mode Exit fullscreen mode

Possible results:

  • HTML output → Service is working
  • Connection refused → Service not running
  • Timeout → Network or firewall issue

This is how I test APIs and web services directly.

dig — Is DNS Working?

Sometimes the network is fine, but domain names don’t resolve.

dig google.com
Enter fullscreen mode Exit fullscreen mode

If I see an IP address in the answer section, DNS is working.

If not, the issue may be DNS configuration.

When something breaks, I should think like this:

  1. Do I have an IP? → ip addr
  2. Can I reach the target? → ping
  3. Is DNS resolving? → dig
  4. Is the service listening? → ss
  5. Is the application responding? → curl

Top comments (2)

Collapse
 
theminimalcreator profile image
Guilherme Zaia •

Essential commands indeed! A good flow like this makes troubleshooting efficient. Have you considered using traceroute as an additional step when ping fails? It can reveal where connectivity issues are occurring. Understanding the journey packets take is just as crucial! 🛣️

Collapse
 
sephyi profile image
Sephyi •

traceroute depends on ICMP responses at each hop, and many hops simply drop ICMP. Especially outside a data center context. Personally, I'd rather run mtr for ~10 minutes from both sides. MTR is essentially traceroute + continuous ping in a loop, so it aggregates packet loss and latency stats per hop over time. Much better for diagnosing intermittent issues than a single traceroute snapshot.