Curl: Diagnosing HTTP Latency, Inspecting TLS Handshakes, and Automating API Workflows in Production

In moments like this, graphical consoles and abstracted monitoring dashboards are too sluggish and too high-level to be useful. You need a tool that operates directly at the boundary of your operating system's network socket—a deterministic, surgical diagnostic tool that tells you exactly where every single millisecond of your request went.

That tool is curl. If you only ever use one advanced diagnostic command during an active network incident, make it this one:

curl -s -o /dev/null -w "\nDNS: %{time_namelookup}s | TCP: %{time_connect}s | TLS: %{time_appconnect}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" https://api.internal.infra.net/healthz

Run that single line, and within a fraction of a second you will see precisely where the bottleneck lies: whether domain resolution is lagging, whether the TCP handshake is crawling over a saturated link, whether the cryptographic exchange is stalling, or whether the backend server is taking hundreds of milliseconds before returning its first byte of data.

At the heart of this venerable utility sits libcurl, a rock-solid C library written by Daniel Stenberg in 1996. While modern application runtimes—from Python to Node.js and Go—bundle their own HTTP client libraries, they frequently wrap socket behaviour in layers of abstraction that mask kernel buffer delays, connection pool exhaustion, and intermediate proxy glitches. Operating directly above the operating system's POSIX networking primitives, curl offers unfiltered clarity and forensic control over every phase of a network transfer.

1. The Anatomy of a Request: Deconstructing libcurl's Engine

To diagnose network trouble effectively, an engineer must mentally unpack what happens between pressing Return on a command and receiving the final byte of data. Modern cloud architectures rarely connect a client directly to a single bare-metal server; instead, requests navigate deep proxy chains, dynamic DNS resolvers, Content Delivery Networks (CDNs), and service meshes.

When a request travels across this pipeline, it moves through four distinct operational phases:

1. Application-Layer Name Resolution: The hostname is translated into an IPv4 (A) or IPv6 (AAAA) address through system resolvers (getaddrinfo), caching daemons (systemd-resolved), or DNS-over-HTTPS (DoH) endpoints.
2. Transport Layer Connection Establishment: The operating system executes the TCP three-way handshake (SYN, SYN-ACK, ACK), subject to kernel routing tables, network interface metrics, and firewall connection tracking (conntrack).
3. Cryptographic Negotiation: The client establishes the TLS record layer, verifies X.509 certificate chains, submits Server Name Indication (SNI) headers, and agrees on protocol features via Application-Layer Protocol Negotiation (ALPN) as defined in RFC 8446 (TLS 1.3).
4. Application Protocol Exchange: The client dispatches HTTP request verbs and headers, streams binary payloads, and ingests response frames in accordance with RFC 9110 (HTTP Semantics).

By default, running curl against a URL simply dumps the raw response body into your terminal. It discards diagnostic timing, conceals transport errors if a partial body was received, and forgets state the moment the process terminates. Transforming curl into a professional diagnostic and automation engine requires understanding its low-level flag taxonomy.

2. Core Operational Primitives: The Command Syntax Taxonomy

Rather than memorising dozens of disconnected switches, it helps to group curl's operational flags into functional subsystems:

3. Five Real-World Production Use Cases

The following five scenarios represent genuine production engineering challenges, moving from live latency triage to secure, resilient automation.

Use Case 1: Granular Latency Profiling and Sub-Millisecond Transfer Telemetry

The Problem

During peak traffic, an upstream API gateway reports that calls to an internal telemetry service are timing out after two seconds. The network engineering team suspects the cloud provider's inter-region routing, while the backend software team suspects database lock contention. You need empirical data to prove where the delay originates.

The Command

Create a reusable telemetry format template, curl-timing-format.txt, leveraging libcurl timing variables available in modern releases, as documented in the curl manpage:

\n
=== METRIC ENGINE TELEMETRY [Target: %{url_effective}] ===\n
  HTTP Return Code:               %{http_code}\n
  HTTP Version Used:              %{http_version}\n
  Remote IP:Port Resolved:        %{remote_ip}:%{remote_port}\n
  Local Socket IP:Port:           %{local_ip}:%{local_port}\n
------------------------------------------------------------\n
  Phase 1: DNS Resolution:        %{time_namelookup}s\n
  Phase 2: TCP Connect:           %{time_connect}s (Duration: %{time_connect} - %{time_namelookup})\n
  Phase 3: TLS Handshake:         %{time_appconnect}s (Duration: %{time_appconnect} - %{time_connect})\n
  Phase 4: Pre-Transfer Setup:    %{time_pretransfer}s\n
  Phase 5: Time To First Byte:    %{time_starttransfer}s (Server Latency: %{time_starttransfer} - %{time_pretransfer})\n
------------------------------------------------------------\n
  Phase 6: Total Transaction:     %{time_total}s\n
  Data Volume Transferred:        %{size_download} bytes\n
  Average Download Speed:         %{speed_download} bytes/sec\n
============================================================\n
\n

Execute the transaction against the target endpoint, discarding the standard output body to /dev/null while capturing stderr and telemetry:

curl -s -S -o /dev/null \
  --config <(echo "-w @/etc/curl/curl-timing-format.txt") \
  --http2 \
  "https://api.internal.infra.net/v2/telemetry/healthz"

Realistic Terminal Output

=== METRIC ENGINE TELEMETRY [Target: https://api.internal.infra.net/v2/telemetry/healthz] ===
  HTTP Return Code:               200
  HTTP Version Used:              2
  Remote IP:Port Resolved:        10.240.12.88:443
  Local Socket IP:Port:           10.240.100.14:48922
------------------------------------------------------------
  Phase 1: DNS Resolution:        0.002143s
  Phase 2: TCP Connect:           0.014210s (Duration: 0.014210 - 0.002143)
  Phase 3: TLS Handshake:         0.048912s (Duration: 0.048912 - 0.014210)
  Phase 4: Pre-Transfer Setup:    0.049102s
  Phase 5: Time To First Byte:    0.342190s (Server Latency: 0.342190 - 0.049102)
------------------------------------------------------------
  Phase 6: Total Transaction:     0.342880s
  Data Volume Transferred:        142 bytes
  Average Download Speed:         414 bytes/sec
============================================================

Line-by-Line Explanation

• Phase 1: DNS Resolution (0.002143s): The system resolver looked up the hostname in 2.14 milliseconds, proving local DNS caching (systemd-resolved or local resolver) is healthy.
• Phase 2: TCP Connect (0.014210s): Subtracting DNS time reveals a transport round-trip time of 12.06ms, exactly matching expected intra-region VPC baseline latency.
• Phase 3: TLS Handshake (0.048912s): Cryptographic negotiation completed in 34.70ms (roughly one round-trip under TLS 1.3 plus certificate verification).
• Phase 5: Time To First Byte (0.342190s): Subtracting pre-transfer setup (0.049102s) demonstrates that the server spent 293.08ms doing internal processing before returning its first byte.
• Phase 6: Total Transaction (0.342880s): Total time elapsed from command invocation to final socket teardown.

What the Admin Does Next

Because network transport, DNS, and TLS accounting consumed less than 50ms combined, the network layer is cleared. The administrator immediately directs investigation to the application layer: inspecting database query logs, checking connection pool exhaustion, and profiling backend worker threads rather than filing a network ticket.

Use Case 2: Troubleshooting TLS Handshakes, SNI Misconfigurations, and Custom CA Chains

The Problem

Your infrastructure team is rolling out an updated internal root certificate and migrating microservices to a new cluster. Suddenly, inter-service API calls report SSL certificate problem: self-signed certificate in certificate chain. You must verify whether a specific backend host (10.0.4.15) has the correct certificate chain installed, without altering public DNS records or modifying global trust stores.

The Command

Use --resolve to pin the IP resolution directly to a specific backend host. This bypasses global DNS while preserving the Server Name Indication (SNI) and Host headers needed for TLS negotiation. Then, enforce specific protocol and trust constraints:

curl -v -s -S -o /dev/null \
  --resolve "api.enterprise.internal:443:10.0.4.15" \
  --cacert "/etc/ssl/certs/InternalEnterpriseRootCA.crt" \
  --tlsv1.3 \
  --tls-max 1.3 \
  --trace-time \
  "https://api.enterprise.internal/v1/health"

Realistic Terminal Output

09:14:02.102914 * Added api.enterprise.internal:443:10.0.4.15 to internal resolve list
09:14:02.103410 * Connecting to hostname: api.enterprise.internal
09:14:02.103445 * Connecting to IP: 10.0.4.15 port: 443
09:14:02.105120 * Connected to api.enterprise.internal (10.0.4.15) port 443
09:14:02.105901 * ALPN: curl offers h2,http/1.1
09:14:02.106230 * TLSv1.3 (OUT), TLS handshake, Client hello (1):
09:14:02.106260 * CAfile: /etc/ssl/certs/InternalEnterpriseRootCA.crt
09:14:02.106275 * CApath: none
09:14:02.119830 * TLSv1.3 (IN), TLS handshake, Server hello (2):
09:14:02.120450 * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
09:14:02.120510 * TLSv1.3 (IN), TLS handshake, Certificate (11):
09:14:02.121820 * Server certificate:
09:14:02.121860 *  subject: C=US; O=Enterprise Architecture; CN=api.enterprise.internal
09:14:02.121885 *  start date: Aug 10 00:00:00 2026 GMT
09:14:02.121900 *  expire date: Aug 10 00:00:00 2027 GMT
09:14:02.121930 *  common name: api.enterprise.internal (matched)
09:14:02.121960 *  issuer: C=US; O=Enterprise Architecture CA; CN=Internal Root Authority
09:14:02.121980 *  SSL certificate verify ok.
09:14:02.122100 * TLSv1.3 (IN), TLS handshake, Finished (20):
09:14:02.122210 * TLSv1.3 (OUT), TLS handshake, Finished (20):
09:14:02.122280 * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF
09:14:02.122310 * ALPN: server accepted h2

Line-by-Line Explanation

• 09:14:02.102914 * Added ... to internal resolve list: The --resolve flag pre-populates curl's address table, preventing DNS lookups and sending the socket straight to 10.0.4.15.
• 09:14:02.106230 * Client hello (1): The client initiates cryptographic negotiation, including SNI for api.enterprise.internal.
• 09:14:02.106260 * CAfile: Identifies the local certificate authority file used to validate the server's certificate chain.
• 09:14:02.121980 * SSL certificate verify ok: The server's leaf certificate and intermediate certificates match the provided root CA.
• 09:14:02.122280 * SSL connection using TLSv1.3: The cipher suite is negotiated under modern TLS 1.3 standards (TLS_AES_256_GCM_SHA384).
• 09:14:02.122310 * ALPN: server accepted h2: Confirms that the server supports multiplexed HTTP/2 transport over this connection.

What the Admin Does Next

Having proven that node 10.0.4.15 holds a valid certificate and supports HTTP/2, the administrator iterates across remaining backend addresses (10.0.4.16, 10.0.4.17) to find whichever host is serving the outdated intermediate certificate, updating the misconfigured server before safely enabling production traffic.

Use Case 3: Resilient REST/JSON Pipeline Automation with Error-Resilient Ingestion

The Problem

In automated provisioning scripts, engineers often pipe HTTP JSON responses directly into tools like jq. However, when an API returns an HTTP 4xx or 5xx error, standard curl commands either succeed with exit code 0 (piping unparseable error HTML/JSON into downstream scripts) or, if using -f / --fail, suppress the server's error message entirely, leaving the engineer with no diagnostic details.

The Command

Use --fail-with-body (introduced in curl 7.76.0) to preserve the server's error message on disk while ensuring the command still returns a non-zero exit code on failure:

#!/usr/bin/env bash
set -euo pipefail

API_ENDPOINT="https://api.infra.service/v2/nodes/provision"
AUTH_TOKEN=$(cat /run/secrets/service_token)

# Construct JSON payload dynamically
PAYLOAD=$(cat <<EOF
{
  "node_id": "srv-iad-441",
  "zone": "us-east-1a",
  "instance_type": "c6g.4xlarge",
  "tags": {"environment": "production", "owner": "sre-core"}
}
EOF
)

# Stream payload through curl directly to parsing engine
RESPONSE_FILE=$(mktemp)
HTTP_CODE=$(printf '%s' "${PAYLOAD}" | curl -s -S \
  --request POST \
  --url "${API_ENDPOINT}" \
  --fail-with-body \
  --header "Content-Type: application/json" \
  --header "Accept: application/json" \
  --header "Authorization: Bearer ${AUTH_TOKEN}" \
  --header "X-Correlation-ID: $(uuidgen)" \
  --data-binary @- \
  --output "${RESPONSE_FILE}" \
  --write-out "%{http_code}" || EXIT_CODE=$?)

EXIT_CODE=${EXIT_CODE:-0}

if [ "${EXIT_CODE}" -ne 0 ]; then
  echo "[CRITICAL FAILURE] HTTP Transaction Aborted with Exit Code: ${EXIT_CODE}" >&2
  echo "[CRITICAL FAILURE] Upstream HTTP Response Code: ${HTTP_CODE}" >&2
  echo "[CRITICAL FAILURE] Raw Server Response Payload:" >&2
  cat "${RESPONSE_FILE}" >&2
  rm -f "${RESPONSE_FILE}"
  exit "${EXIT_CODE}"
fi

echo "[SUCCESS] Transaction Completed (HTTP ${HTTP_CODE}). Ingesting JSON..."
jq '.data' "${RESPONSE_FILE}"
rm -f "${RESPONSE_FILE}"

Realistic Terminal Output

[CRITICAL FAILURE] HTTP Transaction Aborted with Exit Code: 22
[CRITICAL FAILURE] Upstream HTTP Response Code: 409
[CRITICAL FAILURE] Raw Server Response Payload:
{
  "error": "ConflictError",
  "message": "Node 'srv-iad-441' already exists in cluster registry.",
  "timestamp": "2026-08-16T09:14:22.912Z",
  "remediation": "Choose a unique node_id identifier."
}

Line-by-Line Explanation

• PAYLOAD=$(cat <<EOF ...): Creates the JSON payload string without needing intermediate temporary files.
• --fail-with-body: Instructs curl to return exit code 22 on HTTP errors (>= 400) while preserving the response body in ${RESPONSE_FILE}.
• --data-binary @-: Tells curl to read standard input as an unmodified binary stream, avoiding newline stripping or corruption.
• --header "X-Correlation-ID: $(uuidgen)": Injects a unique distributed tracing ID to link client logs with backend logs.
• if [ "${EXIT_CODE}" -ne 0 ]; then: Catches the non-zero exit code and prints the server's structured error message to stderr before terminating.

What the Admin Does Next

Because the script captured the 409 ConflictError and the explanation that srv-iad-441 is already registered, the administrator updates the automated workflow to generate a dynamic hostname suffix or checks the provisioning database to see if an earlier provisioning job crashed mid-run.

Use Case 4: Multi-Stage Stateful Authentication Across Redirect Chains

The Problem

Automating interactions with enterprise identity providers, single-sign-on (SSO) gateways, or management consoles often requires completing a two-step handshake: submitting login credentials, capturing authentication cookies across multiple 302 Found redirects, and re-submitting those cookies to fetch private data. Plain requests lose this session state.

The Command

Use -c / --cookie-jar to record cookies received during login, and -b / --cookie to send them in subsequent requests while using -L / --location to follow redirects:

#!/usr/bin/env bash
set -euo pipefail

COOKIE_JAR=$(mktemp)
trap 'rm -f "${COOKIE_JAR}"' EXIT

BASE_URL="https://auth.datacenter.internal"
TARGET_RESOURCE="https://auth.datacenter.internal/api/v1/cluster/status"

# Stage 1: Authenticate against the IdP, receive session cookies, and serialize state
echo "[AUTH STEP 1] Dispatching primary authentication payload..."
curl -s -S -o /dev/null \
  --request POST \
  --url "${BASE_URL}/login" \
  --cookie-jar "${COOKIE_JAR}" \
  --header "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "username=sre_automation" \
  --data-urlencode "password_file=@/run/secrets/idp_pass" \
  --data-urlencode "realm=infrastructure" \
  --fail

# Inspect the serialized cookie engine storage securely
echo "[AUTH STATE] Inspecting received session cookies..."
awk '!/^#/ && NF {printf "Domain: %-30s Path: %-10s Cookie: %-15s Value: %s\n", $1, $3, $6, $7}' "${COOKIE_JAR}"

# Stage 2: Access protected target resource across redirect chains using stored cookies
echo "[AUTH STEP 2] Traversing redirect chain with stored session cookies..."
curl -s -S \
  --location \
  --cookie "${COOKIE_JAR}" \
  --cookie-jar "${COOKIE_JAR}" \
  --header "Accept: application/json" \
  --fail-with-body \
  --output /tmp/cluster_status.json \
  "${TARGET_RESOURCE}"

echo "[AUTH STEP 2] Success. Ingestion payload sample:"
head -n 5 /tmp/cluster_status.json

Realistic Terminal Output

[AUTH STEP 1] Dispatching primary authentication payload...
[AUTH STATE] Inspecting received session cookies...
Domain: .datacenter.internal           Path: /          Cookie: IDP_SESSION     A994FF21BCAE44910023
Domain: auth.datacenter.internal       Path: /api       Cookie: CSRF_TOKEN      e8b7c4a1-09df-4a92
[AUTH STEP 2] Traversing redirect chain with stored session cookies...
[AUTH STEP 2] Success. Ingestion payload sample:
{
  "cluster_state": "HEALTHY",
  "active_nodes": 128,
  "quorum_status": "MAINTAINED",
  "epoch": 19482
}

Line-by-Line Explanation

• trap 'rm -f "${COOKIE_JAR}"' EXIT: Guarantees that sensitive temporary session tokens on disk are deleted whenever the script exits.
• --cookie-jar "${COOKIE_JAR}": Writes all incoming Set-Cookie headers into a standard Netscape-formatted cookie store.
• --data-urlencode: Properly escapes form parameters, safely reading the password from a secure file without exposing it in process tables.
• --location (-L): Instructs curl to follow HTTP 301, 302, or 307 redirect headers automatically.
• --cookie "${COOKIE_JAR}": Reads existing cookies from disk and sends matching tokens based on the target domain and path.

What the Admin Does Next

Now that authentication and stateful redirects work smoothly, the administrator embeds this pattern into an automated cluster-health auditing job, configuring it to run in memory-backed storage (/dev/shm) to ensure session tokens never touch physical disks.

Use Case 5: Fault-Tolerant Automation: Timeouts, Exponential Backoff, and Rate Governance

The Problem

Unattended maintenance jobs and continuous deployment pipelines frequently fail due to fleeting network hiccups, temporary 503 service restarts, or unthrottled downloads that saturate production bandwidth. An automated script must be resilient against transient errors without getting stuck in infinite loops.

The Command

The following command applies connection timeouts, maximum execution limits, exponential backoff, rate limiting, and defensive exit code handling:

#!/usr/bin/env bash
set -euo pipefail

PACKAGE_URL="https://storage.cdn.internal/packages/v3/kernel-core-6.6.tar.gz"
TARGET_OUTPUT="/var/cache/downloads/kernel-core-6.6.tar.gz"

echo "[INGRESS] Commencing hardened network ingestion..."

curl -s -S \
  --fail \
  --connect-timeout 5 \
  --max-time 60 \
  --retry 5 \
  --retry-delay 2 \
  --retry-max-time 120 \
  --retry-all-errors \
  --limit-rate 5M \
  --output "${TARGET_OUTPUT}" \
  "${PACKAGE_URL}" || {
    EXIT_STATUS=$?
    echo "[CRITICAL] Ingress failed permanently with exit code ${EXIT_STATUS}." >&2
    case ${EXIT_STATUS} in
      6)  echo "[REASON] Could not resolve host name (DNS failure)." >&2 ;;
      7)  echo "[REASON] Failed to connect to host (Connection refused/firewall drop)." >&2 ;;
      28) echo "[REASON] Operation timeout reached." >&2 ;;
      56) echo "[REASON] Failure in receiving network data (TCP Reset)." >&2 ;;
      *)  echo "[REASON] Other libcurl engine failure." >&2 ;;
    esac
    exit ${EXIT_STATUS}
  }

echo "[INGRESS] Download successfully finalized and throttled to 5MB/s ceiling."

Realistic Terminal Output

[INGRESS] Commencing hardened network ingestion...
Warning: Transient problem: HTTP error 503. Will retry in 2 seconds. 5 retries left.
Warning: Transient problem: HTTP error 503. Will retry in 4 seconds. 4 retries left.
[INGRESS] Download successfully finalized and throttled to 5MB/s ceiling.

Line-by-Line Explanation

• --connect-timeout 5: Limits initial TCP and TLS handshake attempts to 5 seconds, preventing hangs on unresponsive IPs.
• --max-time 60: Enforces a hard 60-second limit on the total transaction.
• --retry 5 --retry-delay 2: Retries up to 5 times using exponential backoff (2s, 4s, 8s, 16s...), preventing retry storms on recovering servers.
• --retry-all-errors: Extends retry logic from HTTP 5xx responses to include transient network resets and drops.
• --limit-rate 5M: Uses a token-bucket rate limiter to cap download speeds at 5 Megabytes per second, protecting shared network links.
• case ${EXIT_STATUS}: Interprets standard curl exit codes for clear operational logging.

What the Admin Does Next

The administrator includes this hardened invocation in the server provisioning baseline (cloud-init or deployment agents), confident that temporary network interruptions will resolve themselves without aborting the entire build.

4. Key Pitfalls, Security Vulnerabilities, and Defensive Operating Rules

When running curl in production, several subtle pitfalls can cause security breaches or silent operational failures:

1. Process Table Credential Leaks (-u / --user)

Passing credentials via -u username:password exposes them in plaintext to any user or logging tool reading /proc (such as ps -ef or system monitoring daemons).

# Insecure: Cleartext credentials visible in process listings
curl -u "admin:secretpassword" https://api.internal/

# Secure: Credentials passed via headers or environment streams
echo "secretpassword" | curl -H "Authorization: Bearer $(cat /run/secrets/token)" https://api.internal/

2. Argument Injection via Dynamic URLs

Concatenating unsanitized shell variables directly into curl commands can lead to argument injection. If a variable begins with a hyphen (for example, -o /etc/shadow), curl will interpret it as a flag rather than a URL.

# Insecure: Variable could contain arbitrary flags
curl -s "${USER_SUPPLIED_URL}"

# Secure: The double-dash delimiter signals the end of command-line flags
curl -s --fail -- "${USER_SUPPLIED_URL}"

3. Masked Failures in Piped Shell Scripts

By default, curl exits with status 0 even when a web server returns a 404 Not Found or 500 Internal Server Error. Piping an unchecked download directly into a shell interpreter can cause disaster:

# Insecure: An HTTP 500 error page gets executed as a shell script
curl -s https://config.internal/bootstrap.sh | bash

# Secure: -f causes curl to fail immediately on HTTP errors
curl -fsSL "https://config.internal/bootstrap.sh" | bash

4. Bypassing Validation with --insecure (-k)

Using -k or --insecure disables SSL/TLS certificate validation entirely, exposing your infrastructure to machine-in-the-middle attacks and spoofing.

Instead of turning off security, specify your organization's custom certificate authority directly with --cacert /etc/ssl/certs/internal-ca.crt or install the root authority into the operating system trust store.

5. Production Takeaway & Operational Doctrine

To maintain reliability across production systems, keep these five core operational rules in mind:

6. Authoritative Technical References

1. curl Official Manual & Reference Documentation — Daniel Stenberg et al., authoritative command-line flag manual and option references.
2. libcurl C API Architecture and Internal State Machine — Internal architectural guide covering multi-socket processing, non-blocking transfers, and protocols.
3. RFC 9110: HTTP Semantics — Internet Engineering Task Force (IETF) standard defining HTTP methods, headers, status codes, and payload processing.
4. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 — Specification defining modern cryptographic handshakes, ALPN parameters, and record layers.
5. man7 Linux Programmer's Manual: curl(1) — POSIX system reference manual for the Linux implementation of the curl utility.
6. ArchWiki cURL Reference & PKI Best Practices — Practical operational guidelines for certificate management, proxy setups, and network scripting.

Today's Takeaway

Open your terminal right now, paste the command below, and run it against any website or internal service you use:

curl -s -o /dev/null -w "DNS: %{time_namelookup}s | TCP: %{time_connect}s | TLS: %{time_appconnect}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" https://www.google.com

In under five seconds, you will see a clean, millisecond-by-millisecond breakdown of your connection. Add that one-liner to your shell configuration (~/.bashrc or ~/.zshrc) as an alias—alias curltimes='curl -s -o /dev/null -w "DNS: %{time_namelookup}s | TCP: %{time_connect}s | TLS: %{time_appconnect}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s\n"'—and the next time an API or website feels sluggish, you will know the exact cause before your kettle has even boiled.