Testing Connectivity with Essential Linux Utilities: An Admin‘s Guide

Do you manage Linux servers? Do websites randomly go offline? Do apps lose connections to databases? Do remote servers disappear without warning?

We‘ve all been there. Network issues can cause no end of headaches!

The first step in any diagnosis is confirming if basic connectivity exists between endpoints. Getting a handle on this right away saves you countless hours troubleshooting application code or hunting down server failures.

In this guide, I‘ll equip you with 6 must-know Linux utilities guaranteed to help track down connectivity problems faster.

We‘ll cover:

  • telnet – Test manually connecting to TCP services
  • nc – Swiss army knife TCP/IP networking tool
  • wget – Check connecting to web servers
  • curl – Multi-purpose connection testing
  • nmap – Port scanning and service discovery
  • ping/ping6 – Confirm network reachability

I‘m Chandan Kumar, a Linux infrastructure expert and author with years of experience using these tools to diagnose nasty network issues!

So let‘s get started making connectivity troubleshooting way easier for you!

Telnet: Your Direct Line to Any TCP Service

Before we worry about specific applications, websites or hardware, we need to check basic socket connectivity. Can we establish TCP handshakes between endpoints?

That‘s where good ol‘ telnet comes in handy. Telnet allows creating a raw bidirectional flow for sending and receiving data directly over TCP.

Originally created in 1969, it predates even FTP for directly checking connectivity to services using TCP streams.

To use telnet for connectivity checks, specify the target server address and TCP port:

telnet 22

This tries connecting directly to on port 22 (SSH).

  • If the connection succeeds, you‘ll get interactive access to the raw service protocol for sending text. This allows basic communication confirming the port is listening and accepting connections as expected.

  • If the port refuses connections or a firewall blocks access, telnet will timeout or error immediately. Indicating issues reaching the service.

For example, let‘s demonstrate connecting to SSH on a server:

$ telnet server01 22
Trying server01...
Connected to server01.
Escape character is ‘^]‘.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3

Login as: root

The "Connected" message and SSH protocol greeting confirm we‘ve successfully established connectivity to the target system.

While great for quick checks, telnet has some downsides:

  • Telnet transmits all data (including passwords) in plaintext over the wire
  • Increasingly disabled on modern Linux distros causing issues finding the client
  • Limited to checking TCP services only

So while handy, you may want some alternatives…

When to use telnet

Despite some limitations, telnet excels at manual interactively testing connectivity to TCP networking services.

You have an application losing connections to a database on 3306? Try telnet dbhost 3306 to check the basics.

Website failing? Ensure TCP port 80/443 connectivity exists with telnet before diving deeper.

Any scenario where an TCP client can‘t reach a TCP server, telnet helps confirm if basic socket connectivity exists.

nc – Networking Swiss Army Knife

If telnet seems risky or you want to test more than just TCP services, it‘s time to pull out the big guns – nc!

nc (or netcat) is like a versatile Swiss Army knife for connecting to network services. The "TCP/IP swiss army knife", as the original author called it.

First released in 1995, nc implements a simple yet highly customizable TCP, UDP and UNIX socket client and server. All with handy command line flags for scripting tests.

Let‘s see basic nc syntax for connectivity checking:

nc [options] destination_host destination_port

The bare command tries connecting to the given port on the target server. If successful, it returns an interactive session.

We can add the -vz parameters to do a pure connection test without sending/receiving data:

nc -vz 22

On success you‘ll see output like:

nc: Connected to

Nice and clean!

For even more flexibility, consider adding timeout durations, retrying failed tests, and writing custom application layer requests using nc.

I encourage spending time digging into nc‘s man pages – with over 120 flags it can tackle almost any networking scenario!

Below is a handy comparison of some key advantages over telnet:

Feature telnet nc
TCP tests Yes Yes
UDP tests No Yes
Custom app requests No Yes
Port scanning No Yes
Scriptable Hard Easy
Encrypted No Using wrappers

So while telnet gets the TCP job done, nc adds many useful extras!

Unleash the power of nc

Any scenario where telnet falls short, it‘s worth reaching for nc instead:

  • Testing UDP-based services like DNS queries
  • Need to script automated connectivity testing
  • Crafting custom application layer data for deeper testing
  • Binding ports and proxying connections for further diagnosis

Getting familiar with nc arguments transforms it from a simple scanner to an indispensable connectivity toolkit.

wget: Download Websites for Connectivity Checks

So we‘ve covered utilities focused on specific networking protocols. Now what about checking connectivity to web applications and sites?

That‘s where good old wget comes to the rescue!

Released in 1996, wget began life as a handy utility for mirroring websites by…you guessed it – getting content from the world wide web!

But beyond simply downloading websites, wget contains highly customizable options tailored for web connectivity testing as well.

Executing a simple wget against a website will attempt first establishing TCP connections on port 80/443:

wget example.com

On success, wget then issues an HTTP GET request for the index page and starts downloading the response content.

Any network timeouts, DNS failures, TLS handshakes issues or HTTP protocol errors will cause wget to report the failure. Indicating connectivity problems reaching the website.

Consider enriching the connectivity check with some additional flags:

wget -S --spider example.com
  • -S – print response headers to stdout rather than downloading content
  • --spider – don‘t download body content after getting headers

This tests connectivity without pulling down full site data – perfect for checks.

For example, testing successful connectivity to a secure site might display:

$ wget -S --spider example.com
Connecting to example.com (
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Thu, 02 Mar 2023 22:11:35 GMT

Getting headers back confirms your client can reach the website. Any errors indicate breaks in connectivity preventing access.

Here are some key things to consider around using wget:

Pros Cons
Easy website connectivity testing Only supports HTTP/HTTPS
Customizable flags for connectivity-focused checks More than you need for testing one site
Helper tools for parsing output No built-in port scanning features

So turn to wget when you specifically need to test web application availability from a Linux host.

Wgetting to the bottom of web issues

Nothing hurts worse than an angry call that a website is down!

Before falling down a rabbit hole of application errors, check basic connectivity with wget:

wget -S --spider website_url

No response? Check DNS lookups, then pivot to nc or nmap for ports 80/443 testing next.

Getting headers back? The web server is likely reachable and you can investigate HTTP-level application issues on the server side or client browsers.

Don‘t forget to try both HTTP & HTTPS in case one protocol is misbehaving!

curl: The All-in-One Connectivity Tool

Our last broad connectivity toolkit is the venerable curl client. Released in 1997, curl aimed to provide a single unified command line interface supporting many application protocols:

  • FTP
  • Telnet
  • LDAP
    *…and more!

This Swiss army knife design makes curl perfect for quickly swapping between protocols to test connectivity:

curl protocol://destination_host[:port]

Simply change the protocol prefix and destination port to test anything curl supports:

  • Web UI not loading? Try curl https://mysite.com
  • Mail server offline? Check with curl smtp://mail.myco.com
  • FTP files not transferring? curl ftp://storage:21

On success, curl will print header information from the destination server confirming TCP and application handshakes completed properly.

Any errors indicate connectivity issues or protocol mismatches preventing communication.

Now of course many Linux distributions have native utilities for the above protocols – httpd, ftp, email clients, etc.

So why use curl instead?

  • Doesn‘t transmit additional data for tests only
  • Flexible protocol support from single command
  • Easy to manipulate requests for troubleshooting
  • Helper libraries to parse, format and validate responses

Curl wraps up all the fundamentals for convenient connectivity verification across common application services.

Curl up with versatility

With support for nearly any application protocol, curl should be your go-to for quickly pivoting connectivity tests:

  • Web app not loading? Try both curl http:// and curl https:// prefixes
  • Emails failing to send? Check curl smtp:// responses
  • Unsure if LDAP integration is working? Info from curl ldap:// will tell you

Getting headers back confirms the service is reachable. Errors indicate network or application faults preventing connectivity.

Curl does it all – complement more protocol specific tools with curl for versatile high level testing.

nmap: Pinpoint Port Access

Thus far we‘ve covered flexible clients for testing connectivity across protocols. But what about discovering services and methodically probing ports?

For that we need something designed for targeted port scanning and network mapping – enter nmap!

First released in 1997, nmap revolutionized discovery and security auditing of networks. Quickly scanning ranges for open ports and fingerprinting services.

The name "nmap" even stands for "Network Mapper"!

While extremely versatile, we‘ll focus on using core nmap functionality for basic connectivity verification:

nmap -p destination_port destination_host 

This tests if we can establish TCP connections to the given port on the target server.

For example, probing SSH on a backend system:

nmap -p 22 backend01

Nmap then prints output indicating the discovered state:

Host: backend01 ()    Port: 22/tcp  State: open

An "open" state means nmap successfully connected confirming the port accepts traffic.

Other potential results include:

  • filtered – Firewall is blocking access
  • closed – Nothing listening on the target port
  • no response – Host could be offline or unreachable

This straightforward probing with nmap can decisively check connectivity status on specific ports quickly.

Some additional advantages over other scanners:

  • Fast parallel scanning of multiple hosts
  • Output formats from simple to detailed
  • Advanced host discovery and OS fingerprinting
  • Custom network packets for penetration testing
  • Scripting engine for automating checks
  • Granular output control for connectivity focus

Nmap has far more features we can‘t cover fully here! But even just basic TCP port scanning proves invaluable.

Map your connectivity strategy

firewall got you locked down?

nmap -p 80,443

Find open web ports to identify accessible servers.

Databases refusing connections?

nmap -p 3306 dbhost 

Verify if MySQL port allows traffic before debugging queries.

Full stack not working?

Scan all application related ports on involved hosts to check connectivity at each layer, then work bottom up!

Nmap fits neatly into any methodology needing port level visibility for connectivity troubleshooting.

Ping & Ping6: Test Basic Reachability

Last but not least, we arrive at the venerable ping!

Introduced all the way back in 1983, ping began life as command simply sending ICMP echo requests to check basic reachability.

Over 35 years later, ping remains a staple in every networking toolkit for the first basic connectivity check – is the remote host even awake?

ping continues this legacy by sending ICMPv4 or ICMPv6 echo requests to check if a target IP host responds:

ping destination_host_or_ip

Replies indicate a basic level of connectivity and availability. Whereas request timeouts or destination unreachable errors show serious network issues exist dropping traffic.

There is also a separate ping6 variant specifically for testing IPv6 connectivity:

ping6 ipv6_address_or_hostname 

The same principles apply – responses mean IPs are routable, errors show problems.

Some key ping considerations:

  • Quick first check before TCP/UDP service tests
  • Subject to false negatives if ICMP blocked
  • Requires hostname resolution if not using IPs
  • IPv4 vs IPv6 network issues may differ

So treat no ping replies as hints of unreachability, not conclusive proof. Follow up with nmap scans for deeper investigation.

Pinging the first domino

About to spend way too long troubleshooting why that database server can‘t be reached?

Start simple:

ping db01

No response? Check DNS, then ping the IP address instead to test layers.

Ping timing out? Verify local network hardware, switches and firewalls aren‘t dropping traffic.

Getting replies back? Database running on unusual port? Quick nmap scan will check.

Basically any network connectivity scenario begins with simple ping checks as a fast first step. From there explore further guided by responses vs errors!

Let‘s Recap: Connectivity Testing Best Practices

After all that, here is a handy table summarizing the Linux connectivity tools we covered for your next outage:

Utility Key Features When To Use
telnet Manually interact with TCP services Verify connectivity to known TCP ports
nc Custom TCP/UDP connectivity client Anything complex or non-TCP
wget Test HTTP/HTTPS web connectivity Websites failing to load
curl Flexible cross-protocol connectivity client Rapidly pivot between app protocols
nmap Port scanning and service identification Find open ports or fingerprint apps
ping ICMP echo checks First step in any diagnosis

I suggest getting cozy with all 6 tools – each bring unique strengths complementing the others. Memorize this table, bookmark this post, but most importantly practice using them!

The best troubleshooters turn tools into instincts through experience across many battles!

To conclude, let‘s walk through a high-level scenario demonstrating how these utilities can systematically narrow down connectivity issues:

"The app server can‘t reach the database and pages won‘t load!"

  1. ping app + db servers – are they online?
  2. nc attempt connections from app to db on 3306 port – firewall blocking?
  3. nmap scan web ports (80/443) between components- traffic allowed?
  4. curl simulate HTTP requests from app to web tier – back end connectivity okay?
  5. wget check DNS resolution and get index from browsers – clients hitting web heads?

Combine critical thinking with the right tools at each stage and problems become puzzles. Rinse, repeat across many high stress outages to gain sysadmin zen!

Hopefully this introduction to Linux connectivity troubleshooting proves valuable in your infrastructure adventures. Let me know which utilities you find most indispensable!

But for now…happy networking!