Loading...

VONDS ©

Lab 66: Using curl and ping for Network Testing

Back to Lab Index

Validate service availability with layered checks: confirm basic reachability with ping, then validate HTTP behavior with curl. Capture status and redirect evidence so you can separate “network down” from “web app down.”

networking troubleshooting core

Scenario

A web service is reportedly down. Your job is to test both basic connectivity and HTTP-level behavior for example.com . You will verify ICMP reachability, make an HTTP request, inspect headers, and then follow the redirect to confirm the HTTPS endpoint is reachable.

Operator context

A host can be reachable while the web service is failing, or a web service can be healthy while ICMP is blocked by policy. Use ping and curl together to avoid false conclusions and produce actionable evidence.

Objective

  • Test basic reachability to example.com using ICMP.
  • Make an HTTP request and capture the response body.
  • Fetch HTTP headers to confirm status and redirect targets.
  • Follow redirects to validate the HTTPS endpoint.

Concepts

  • Layered validation: reachability (ICMP) versus service behavior (HTTP).
  • Why ping is useful but not authoritative (ICMP can be blocked while the service is healthy).
  • HTTP status codes and redirects as a first-pass health signal.
  • Header-only inspection to confirm Location and status without downloading full content.
  • Redirect following to validate the final HTTPS endpoint.
  • Evidence-driven troubleshooting: record results that are actionable for the next operator.

Walkthrough

Step 1 : Test basic connectivity to example.com.
Command 
ping -c 4 example.com

This tests whether the target responds to ICMP echo requests and provides packet loss and latency signals. If ICMP is blocked, treat this as “inconclusive,” not “down.” 

PING example.com (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=22.4 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=56 time=22.1 ms
64 bytes from 93.184.216.34: icmp_seq=3 ttl=56 time=21.9 ms
64 bytes from 93.184.216.34: icmp_seq=4 ttl=56 time=22.3 ms

--- example.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 21.900/22.175/22.400/0.199 ms
Step 2 : Make an HTTP request using curl.
Command 
curl http://example.com

This tests HTTP connectivity and prints the response body. Many sites redirect plain HTTP to HTTPS, which can show up as a 301 response. 

<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<p>Resource has moved to <a href="https://example.com/">https://example.com/</a></p>
</body>
</html>
Step 3 : Fetch headers to confirm status and redirect target.
Command 
curl -I http://example.com

Headers confirm the HTTP status code and the Location redirect target without downloading full content. 

HTTP/1.1 301 Moved Permanently
Location: https://example.com/
Content-Type: text/html; charset=UTF-8
Content-Length: 162
Date: Thu, 06 Nov 2025 10:15:42 GMT
Server: ECD (example)
Step 4 : Follow redirects from HTTP to HTTPS.
Command 
curl -L http://example.com

Following redirects validates the final destination content and confirms the HTTPS endpoint is reachable and serving responses. 

* Redirecting to: https://example.com/
* Successfully fetched via HTTPS
<!doctype html>
<html>
  <head>
    <title>Example Domain</title>
    <meta charset="utf-8" />
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
  </head>
  <body>
    <div>
      <h1>Example Domain</h1>
      <p>This domain is for use in illustrative examples in documents. You may use this
      domain in literature without prior coordination or asking for permission.</p>
      <p><a href="https://www.iana.org/domains/example">More information...</a></p>
    </div>
  </body>
</html>

Common breakpoints

ping fails but the web service might still be healthy

ICMP is often blocked by policy. If ping fails, validate HTTP behavior with curl before declaring the service down.

curl returns 301/302 and you assume the service is broken

A redirect is usually expected when HTTP is upgraded to HTTPS. Confirm the redirect target with curl -I and validate the final endpoint with curl -L .

You only test the body and miss header-level evidence

Use curl -I to capture status and Location without noise. This is often the most useful artifact for incident notes and escalation.

You test from one host and assume the whole service is down

A local DNS issue, proxy policy, or egress restriction can affect only the source you are testing from. When results are unexpected, validate from a second host or network.

Cleanup checklist

This lab is read-only. Cleanup is documenting results and saving the header evidence you would include in an incident update or ticket.

Commands 
ping -c 4 example.com
curl -I http://example.com
curl -L http://example.com
Success signal

You can state whether the host is reachable by ICMP, what HTTP status is returned, where the request redirects, and whether the HTTPS endpoint serves content.

Reference

  • ping -c <N> <host> : Sends N ICMP echo requests to test reachability and loss.
    • -c <N> limits the count so the test completes quickly.
  • curl http://<host> : Makes an HTTP request and prints the response body.
  • curl -I http://<host> : Fetches headers only (status line, redirect Location, metadata).
    • -I requests headers without downloading the full body.
  • curl -L http://<host> : Follows redirects until the final destination is reached.
    • -L is required when services enforce HTTPS or redirect to a canonical hostname.