Command-Line Network Diagnostics: DNS, Ports, TLS, and HTTP

Hello! Last time, you traced a conventional HTTPS request through DNS, TCP, TLS, and HTTP. Now you’ll turn that model into a troubleshooting routine: test each stage from the command line, record what succeeded, and avoid treating one successful check as proof that the whole application works.

Allow about 40 minutes, including the short video, readings, and time to try the commands. The examples use example.org; substitute an application hostname and path when testing a service you operate.

Check the DNS answer

Start with the exact hostname in the failing URL. For an IPv4 address record, run:

dig example.org A

In the ANSWER SECTION, an A record supplies an IPv4 address. Also inspect the response status, the SERVER that answered, and the record’s TTL (time to live). If the application may use IPv6, check that separately:

dig example.org AAAA

Watch the selected portions of Learn Linux TV’s How to Use the dig Command in Linux | DNS Lookup Tutorial for a demonstration of reading an address-record answer and directing a query to a chosen resolver.

The screenshot below is a useful reference for full dig output. Its NOERROR status and one answer show that this particular DNS query received an address record; they say nothing about whether a web server accepted a connection.

For a quick address check, dig +short example.org A is convenient. Do not rely on short output alone when diagnosing a failure: it omits the status that helps distinguish, for example, a nonexistent name (NXDOMAIN) from a successful response containing no A record (NOERROR with no A answer). A server failure (SERVFAIL) is different again.

If you suspect a resolver-specific problem, compare the default query with one sent to another approved, reachable resolver:

dig @YOUR_RESOLVER_IP example.org A

Replace YOUR_RESOLVER_IP before running it. Different answers can reflect caching or DNS configuration; they are a reason to investigate, not automatic proof that either answer is wrong. On a Linux client, getent ahosts example.org is also useful: unlike a direct dig query, it asks through the operating system’s name-resolution configuration and can reveal what an application using that path is likely to obtain.

Test whether a port accepts TCP connections

An address is only a destination to try. To test a TCP listener on the usual HTTPS port, use nc (netcat):

nc -vz -w 3 example.org 443

Here, -z checks the connection without sending application data, -v requests diagnostic output, and -w 3 limits the wait on common nc implementations. Options vary between versions, so check nc -h if yours rejects them.

Interpret the result narrowly:

• Connected: something accepted TCP on that address and port. It might be a load balancer, not the application process.
• Connection refused: the attempted connection was actively rejected; a missing listener is one possible cause.
• Timed out: no usable connection was established within the wait. Filtering, routing, or an unresponsive destination may be involved.

None of these results validates a TLS certificate or tests /health. A service can accept TCP and fail at the next stage. Conversely, if nc is unavailable, the verbose curl request later in this lesson can show whether its TCP connection completed, though it performs additional checks too.

Validate TLS, not just the open port

For HTTPS, a successful TCP connection is followed by TLS. The most practical certificate test is usually an ordinary curl request without disabling verification: curl checks whether it trusts the issuing CA and whether the certificate matches the hostname in the URL.

Read curl’s certificate-verification documentation before interpreting a failure.

Try a verified request with verbose diagnostics:

curl -v --connect-timeout 3 --max-time 10 https://example.org/ -o /dev/null

Look for the address curl tries, whether it reports a connection, and whether certificate verification succeeds. --connect-timeout limits connection setup; --max-time limits the entire transfer. Verbose output can expose request headers or other sensitive details, so review it before sharing or saving it.

To inspect the certificate presented by a particular TLS endpoint, OpenSSL can initiate a handshake using the intended hostname:

openssl s_client -connect example.org:443 \
  -servername example.org \
  -verify_hostname example.org \
  -verify_return_error </dev/null

-servername sends the hostname for SNI, allowing a shared endpoint to choose the appropriate certificate. -verify_hostname checks the certificate against that name, while -verify_return_error makes verification errors fail the handshake rather than merely reporting them. Inspect the verification result and certificate details; remember that OpenSSL and curl can use different trust-store configurations.

If your service uses a private CA, test with its trusted CA certificate rather than turning checks off:

curl --cacert /path/to/ca.pem https://YOUR_HOSTNAME/

Replace both placeholders. Avoid curl -k or --insecure as a production “fix”: it suppresses the very verification needed to know you reached the intended service securely.

Ask for an HTTP response

Once TLS succeeds, test the actual URL and method associated with the reported failure. Curl’s tutorial introduces several useful ways to see the response.

Use -i to include response headers with a normal GET request:

curl -i --connect-timeout 3 --max-time 10 https://example.org/

For your own service, replace / with the path users actually request, such as /health. The status and headers help identify what the endpoint returned; inspect the body when it contains relevant error detail. curl -I sends a HEAD request, which is useful for headers but is not an equivalent test if the failing request is GET: some endpoints handle the two methods differently.

For a concise, repeatable check that does not print the body:

curl -sS -o /dev/null \
  -w 'HTTP=%{http_code} IP=%{remote_ip}\n' \
  --connect-timeout 3 --max-time 10 \
  https://example.org/
printf 'curl_exit=%s\n' "$?"

Read the HTTP status and command exit status separately. By default, curl can exit successfully after receiving an HTTP 404 or 503: the transfer worked, even though the endpoint reported an error. If no HTTP response arrived, the displayed HTTP code may be 000; use the exit status and diagnostics to investigate why. An HTTP 200 confirms only what that request to that endpoint returned, not that every dependency or user journey is healthy.

When DNS is suspect but you know a specific destination IP, curl can test that IP while keeping the intended HTTPS hostname:

curl --resolve YOUR_HOSTNAME:443:YOUR_IP https://YOUR_HOSTNAME/health

Replace all placeholders with values for your service. This directs curl to the chosen IP while retaining the URL hostname for TLS verification and the HTTP request. It is more informative than requesting https://YOUR_IP/ and ignoring a name mismatch. If a proxy is configured, check curl’s verbose output before interpreting this as a direct connection test.

Put the evidence together

A useful troubleshooting note records the target, command, observation, and last successful stage. For example, if DNS returns an address and nc connects, but verified curl reports a hostname mismatch, investigate the certificate served for that hostname—not DNS propagation or HTTP status codes. If verified curl receives 503, DNS, the client-facing connection, and TLS worked for that request; the response may still have come from a front-end proxy rather than the application.

Keep the tools’ scopes in view: dig tests a DNS query, nc tests a TCP connection, OpenSSL and verified curl test aspects of TLS, and curl reports the HTTP exchange. Run them from the client environment experiencing the problem when possible. A successful check from your laptop does not establish that a production host has the same DNS answer, route, trust store, or access policy.

Key takeaways

Test the request in layers, but do not overclaim from any single result. Inspect full DNS status when resolution fails; treat an open port as TCP evidence only; keep TLS verification enabled and check the intended hostname; then test the relevant HTTP method and path while distinguishing HTTP status from curl’s exit status.

Next, you’ll use these observations to isolate a connectivity failure across an EC2 instance, its operating system, AWS network controls, routes, and DNS.