Wireshark Tutorial for Beginners: Understand HTTP, DNS, and TLS

Wireshark can turn network traffic into something you can inspect packet by packet—but a capture is only useful when you know what to look for. This Wireshark tutorial for beginners walks through a controlled capture and shows how to identify DNS lookups, TCP connections, and TLS traffic. You’ll also learn what HTTPS encryption hides and how to avoid common interpretation mistakes.

Key takeaways

• Capture only traffic you own or have explicit permission to inspect.
• Use a display filter to narrow packets after capturing; capture filters work differently and limit what gets recorded.
• DNS queries, TCP connection setup, and TLS handshakes provide different clues about a connection.
• HTTPS usually encrypts HTTP requests and responses, so a packet capture alone will not reveal their contents.

Set up a controlled Wireshark lab

Before capturing, choose a lab environment where you understand and control the traffic. A personal computer and its own network connection can be suitable for learning, but shared networks may carry other people’s private data. Do not capture or inspect someone else’s traffic without authorization.

1. Install Wireshark from its official website and open it with the permissions required for packet capture on your operating system.
2. Select the interface that carries your test traffic. On a typical computer this might be Wi-Fi, Ethernet, or a loopback interface for local-only traffic. Interface names and permissions vary by operating system.
3. Start a capture, generate one test action—such as opening a page or making a DNS lookup from your own device—and then stop the capture.
4. Save the capture only if needed, and protect it. Captures can contain sensitive information, even when the original connection uses encryption.

For a simple local HTTP test, you can run a server in a directory containing only non-sensitive test files:

python -m http.server 8000 --bind 127.0.0.1

In a second terminal, request the local server:

curl http://127.0.0.1:8000/

Capture on the loopback interface if your operating system exposes it. This example keeps the HTTP exchange on your own machine; it does not demonstrate HTTPS. Stop the server when you finish. The Python server is intended for simple testing, not as a production web server.

Display filters: find the packets you need

Wireshark’s display filter bar narrows the packets shown without removing them from the saved capture. Enter a filter and apply it to inspect matching packets. These are display filters, not capture filters: a capture filter is set before recording and can prevent packets from being saved at all.

Useful beginner display filters include:

The IP address and stream number above are examples; replace them with values from your capture. A filter for http will not reveal encrypted HTTPS content. Port numbers can help locate traffic, but a port alone does not prove which application protocol is in use.

Follow a DNS lookup

DNS translates a hostname, such as example.com, into information clients can use to connect to a service. To observe a lookup, start a capture on your own device and trigger a query using a tool such as nslookup example.com or your system’s DNS tools. Use a resolver and network you are allowed to use.

Apply the dns display filter. Select a query packet and expand the Domain Name System details in the packet details pane. Look for the queried name, query type, transaction identifier, and response. A response may contain an answer, an error, or no address record matching the requested type.

A few details matter when interpreting what you see:

• DNS commonly uses UDP on port 53, but it can also use TCP. Do not assume every DNS exchange is a single UDP request and response.
• A cached answer may mean no new query is sent for the hostname you test. Try a different permitted test name or wait for the relevant cache entry to expire; avoid repeatedly querying systems you do not control.
• DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS traffic between the client and resolver. A capture may show a connection to a resolver without exposing the DNS query in readable form.
• A packet capture can show what was transmitted on the observed interface, but it may not explain how an application chose a particular resolver or hostname.

Inspect the TCP connection

Many HTTP and TLS connections use TCP. Filter with tcp, then locate the packets associated with the conversation you want to study. Wireshark labels TCP stream numbers; use Follow → TCP Stream in the interface, or apply a filter such as tcp.stream eq 0 after replacing 0 with the stream number you found.

A typical TCP connection begins with a three-way handshake:

1. The client sends a SYN packet to request a connection.
2. The server responds with SYN, ACK.
3. The client sends ACK to complete the handshake.

After that, the endpoints exchange data. A connection may later close with FIN packets, or be interrupted with a reset (RST). Retransmissions, duplicate acknowledgments, and out-of-order packets can be useful clues when diagnosing a connection, but any one of them is not proof of a particular fault. Consider timing, direction, sequence numbers, and the whole conversation before drawing conclusions.

For a local test server on port 8000, tcp.port == 8000 can help isolate the exchange. Remember that TCP does not tell you what the application data means by itself; interpret it alongside the protocol and context.

Recognize HTTP and understand TLS visibility

On an unencrypted HTTP connection, Wireshark may decode request methods, paths, headers, and response status codes. The local test above is a safe way to see a basic HTTP exchange on your own machine. Avoid sending sensitive values in test requests: plain HTTP does not protect them in transit.

HTTPS uses TLS to protect application data. In a capture, you may be able to identify a TLS handshake and inspect some connection metadata, such as information offered by the client in its ClientHello. Exactly what is visible depends on the TLS version, negotiated features, and the capture point. With TLS 1.3, much of the handshake after ServerHello—including certificate messages—is encrypted. Encrypted ClientHello (ECH), when supported and used, can also limit visibility of the real server name. TLS 1.2 handshakes commonly expose more handshake details, but encrypted application data remains unreadable without appropriate session secrets.

In ordinary HTTPS traffic, Wireshark cannot show the HTTP page, request headers, or response body just from the packet capture. For an application you control, some browsers and clients can export TLS session keys for authorized debugging, and Wireshark can use those keys when configured. Treat a key log as highly sensitive: anyone who obtains it may be able to decrypt matching captured sessions. Do not collect or use session keys for traffic you are not authorized to inspect.

A practical inspection workflow

Use this sequence when you want to understand one test connection:

1. Define the question. For example: “Did my test client resolve the hostname?” or “Did the TCP connection complete?”
2. Choose a controlled test. Use your own device, a test service, and an authorized network. Keep the capture short.
3. Select the right interface. If you see no packets, check whether the traffic uses another interface, a VPN, or loopback.
4. Start capture and generate one action. A single request is easier to follow than a busy capture.
5. Apply a display filter. Start with dns, tcp, or tls, then narrow to an address, port, or stream.
6. Inspect packet details and the conversation. Correlate the DNS result, TCP handshake, and TLS exchange where visible. They may not all appear in one capture, especially if DNS was cached or encrypted.
7. Stop and review. Avoid treating a single packet as a complete explanation. Save the capture only when necessary and store it securely.

For a quick field-by-field explanation of a URL before you use it in a test, TidyURLs’ URL parser can help you inspect its components. Parsing a URL does not reveal encrypted traffic or replace network-level controls.

Common mistakes and troubleshooting

• Capturing on the wrong interface: Check active interfaces and account for VPNs, virtual adapters, and loopback traffic.
• Confusing filter types: dns is a display filter. Capture filters use a different syntax and are applied before packets are recorded.
• Expecting HTTPS to look like HTTP: TLS encrypts application data. Seeing TLS packets does not mean the HTTP content is available to read.
• Assuming a missing DNS packet means no lookup happened: The answer may have come from a cache, or DNS may be encrypted or outside the interface you captured.
• Treating port 443 as proof of TLS: Port numbers are conventions, not definitive protocol identification.
• Overinterpreting retransmissions: They indicate packet delivery or timing behavior that merits investigation, not a diagnosis by themselves.
• Leaving captures or key logs exposed: Remove test files when no longer needed and restrict access to anything that could contain private data or decryption secrets.

Conclusion

Wireshark is most useful when you ask a focused question and capture a controlled, short test. Begin with display filters, follow DNS and TCP exchanges, and use TLS packets to understand connection setup without expecting encrypted HTTP content to be visible. Keep authorization and capture-data privacy in mind throughout the process.

References

• Wireshark User’s Guide
• Wireshark Display Filter Reference