Wireshark Part 04 — Why does this website or API fail?

Series index · Previous: Performance · Next: Plaintext exposure

18 September 2026 · Official documentation source-checked; exercises have not been run on THL hardware. Expected observations below are teaching expectations, not measured results. Menu wording varies by platform and release.

Question: Is the failure in name resolution, connection setup, TLS, or the application? Outcome: A short timeline showing the last successful stage and what additional evidence is needed.

Wireshark is useful when a browser reports only “connection failed” or an API client times out. Legitimate analysis correlates your own request with packets and application logs. The same visibility can be misused to profile someone else’s browsing or inspect private content using stolen session secrets. This exercise covers your own client, an ordinary request, and optional secrets generated by your own test process. It does not authorize collecting another user’s traffic or obtaining their keys.

Prepare the capture point

Use an already configured Wireshark installation on your computer. Close unrelated applications and avoid signed-in browser sessions. Capture on the interface carrying your request; a VPN may require an appropriate virtual interface. You need permission for the capture environment, even when investigating your own application.

For a repeatable baseline, use the single public-page request below. For an actual API investigation, substitute an approved test endpoint with dummy data. Do not send production tokens. Save captures in a private folder outside automatic cloud synchronization.

Trace one request

1. Open Capture → Options, select your active interface, and enter the capture filter port 53 or port 443. Start the capture. This deliberately narrow example can miss nonstandard ports and does not isolate a particular application. If your test uses another port, adjust the scope before starting.

2. In PowerShell, make one request:

   curl.exe --http1.1 --output NUL --show-error --write-out "HTTP %{http_code}\n" "https://example.com/"
   

   Stop the capture immediately afterward and retain the HTTP status or error printed by curl. Save through File → Save As. Forcing HTTP/1.1 makes this baseline easier to compare with TCP-based TLS. It does not reproduce a browser’s HTTP/2 or HTTP/3 behavior. curl command reference

3. Apply dns in the display-filter bar. If a query exists, expand Domain Name System and compare its answer addresses with subsequent connections. An empty result could mean caching, encrypted DNS, or a different capture path; it is not proof that resolution failed.

4. Apply tcp.flags.syn == 1 or tcp.flags.reset == 1. Select the relevant connection, expand Transmission Control Protocol, and note Stream index. Replace the filter with tcp.stream == N, substituting its number. Identify the connection attempt, response, and any reset. A reset identifies a packet carrying that flag, not the business reason for rejection. TCP fields

5. Apply tls.handshake.type == 1 and inspect Transport Layer Security → Handshake Protocol: Client Hello. The filter tls.handshake.extensions_server_name locates packets with decoded server names. Some names may be absent or protected; an outer name is not necessarily the intended private destination. ECH encrypts the inner ClientHello. TLS fields, ECH specification

6. Start a new capture and repeat the request with your normal browser if that is the failing client, then stop and save it separately. Use quic or udp.port == 443 to look for a possible QUIC path. UDP port 443 alone does not prove QUIC, and TCP filters cannot diagnose its streams. QUIC uses TLS but protects its application data; decoding its Initial exchange does not expose later HTTP content. QUIC fields, QUIC security specification

Optional: inspect HTTPS from your own test process

If the application layer is essential, a supported Python build can explicitly log secrets for this one test client. Save this as tls-lab.py in a private lab folder and run it there while capturing:

import ssl
import urllib.request

context = ssl.create_default_context()
if not hasattr(context, "keylog_filename"):
    raise SystemExit("This Python build lacks TLS key logging support")
context.keylog_filename = "tls-lab.keys"
with urllib.request.urlopen("https://example.com/", context=context) as response:
    print(response.status)

Start a fresh capture, run python tls-lab.py from that private folder, then stop and save the capture separately. Certificate checking remains enabled. Key logging is a feature of the client and its TLS library; setting SSLKEYLOGFILE does not make every browser or application export secrets. Python TLS contexts

In Wireshark, open Edit → Preferences → Protocols → TLS, set (Pre)-Master-Secret log filename to the absolute path of tls-lab.keys, and apply. Use http.request or http.response if HTTP/1.x is decoded. A complete matching capture and usable session secrets are required; decryption can still fail. Wireshark TLS configuration, HTTP fields

Interpret, fix, and finish

Successful TLS followed by encrypted traffic does not prove the API succeeded. A visible HTTP error narrows the problem but may still require server logs. Conversely, a missing handshake could mean capture began too late. Record facts separately from hypotheses.

Fix the confirmed layer: correct DNS configuration, investigate connection rejection, repair certificate or trust configuration, or inspect the application’s response handling. Do not disable certificate validation as a permanent fix. Protect key logs like the decrypted content; remove the TLS preference afterward and dispose of the lab secrets under your retention policy.

Completion exercise: Produce four timestamped entries—resolution evidence, transport evidence, TLS evidence, and application evidence. Mark unavailable stages “not observed,” give one plausible alternative explanation, and name the next log or measurement that would resolve it.