Blog

A failed request can generate dozens of packets, while the useful evidence may be limited to a DNS reply with no address, a TCP reset, repeated retransmissions, or an HTTP error from the server. Wireshark turns that packet stream into a timeline you can use to see where a connection failed.

Use Wireshark only on networks, devices, and services you own or are explicitly authorized to administer. Packet captures may include sensitive information such as internal hostnames, cookies, request paths, and unencrypted application data. For practice, use a home lab, a test virtual machine, or a request deliberately sent to a local service.

Start with a precise symptom

Wireshark works best when you give it a narrow question. “The network is slow” can mean DNS delays, Wi-Fi loss, server processing, congestion, or an application issue. Turn that complaint into an observable event:

• A website name does not resolve.
• An application cannot reach a particular server or port.
• A page takes a long time to begin loading.
• A connection works intermittently.
• A file transfer stalls or resets.

Write down the approximate time, the affected device, the destination name or address, and one action that reliably triggers the problem. Start a capture, reproduce the issue once, then stop. An open-ended capture usually produces a large file dominated by unrelated background traffic.

Choose the correct interface and capture safely

On Wireshark’s welcome screen, active interfaces have a moving traffic graph. Choose the interface carrying the troubled connection: Wi-Fi for wireless traffic, Ethernet for a wired connection, or a virtual adapter in a lab. If you capture on the wrong interface, it may appear empty even though the application is communicating normally.

Start the capture, run the test, and stop it promptly with the red square button. Short captures are easier to review, share securely with an authorized support team, and archive with useful notes.

Capture filters versus display filters

These features do different jobs. A capture filter decides what Wireshark records. You must set it before starting, and traffic excluded from the capture cannot be recovered later. A display filter changes only what you see after the packets have been collected. For most beginners, it is safer to capture a short session and investigate it with display filters.

A narrow capture filter can help when the environment is noisy or the fault is easy to target. For example:

• host 192.0.2.25 records traffic to or from one test host.
• port 53 records DNS traffic.
• tcp port 443 records TCP traffic for HTTPS ports, though it does not decrypt HTTPS.

Addresses in 192.0.2.0/24 are documentation examples; replace them with addresses from your authorized environment. Avoid broad, long-running captures on shared networks, since they can collect far more information than the troubleshooting task requires.

Read the packet list as a timeline

Wireshark’s main window has three panes. The packet list at the top shows packets in time order. The packet details pane in the middle expands protocol fields, while the lower bytes pane shows raw bytes alongside their decoded form. Begin with the packet list, then expand the protocol layer related to the suspected failure.

Useful columns include time, source, destination, protocol, length, and info. If a field would help you compare packets, right-click it in the details pane and add it as a column. TCP stream identifiers, for example, can make several interleaved web connections easier to separate.

Do not treat a packet as suspicious without considering where the capture was taken. A client-side capture can show that a request left the client, but it cannot prove how the remote server handled it. A server-side capture may show the incoming request while missing trouble on the client’s Wi-Fi link. The strongest conclusions come from comparing the trace with application logs, server metrics, and captures taken at an authorized, relevant point.

Apply display filters to isolate the conversation

Enter display filters in the bar near the top of Wireshark. The bar turns green when the filter is valid. Display filters do not alter the capture file; they simply hide packets that do not match.

To isolate one TCP exchange, select a packet from the connection, right-click it, and choose Conversation Filter, then TCP. This is often simpler than entering a stream number yourself. The filtered view lets you follow the handshake, request, response, and connection close without unrelated traffic in the way.

Troubleshoot common failures step by step

1. DNS lookups that fail or take too long

Filter with dns, reproduce the lookup, and find the query for the name you are testing. Expand the Domain Name System section to inspect the query name, response code, answers, and response time.

A normal sequence is a query followed quickly by a response containing one or more records. A response code such as NXDOMAIN means the responding DNS server says that name does not exist. Repeated queries with no reply may point to a reachability problem, an incorrect resolver address, packet loss, or an overloaded or unavailable resolver. Do not decide on the cause from a single symptom; first check whether the packets leave the client and whether replies return.

DNS often uses UDP, but TCP may appear for large answers or retries. Modern encrypted DNS can prevent Wireshark from showing queried domain names. That is expected and generally beneficial for privacy.

2. A TCP service cannot be reached

For a normal TCP connection, look for the three-way handshake:

1. The client sends SYN.
2. The server replies with SYN, ACK.
3. The client replies with ACK.

If the client sends several SYN packets and no SYN, ACK arrives, the server may be unreachable, the address may be incorrect, a firewall may be silently dropping traffic, or return traffic may be failing. A prompt RST means that a host actively rejected or terminated the connection. This often happens when no service is listening on the requested port, though policy devices and applications can also send resets.

Wireshark shows symptoms, not a final verdict. Compare the trace with authorized checks of the target service, firewall rules, routing, and server logs. A timeout alone does not prove that a firewall is blocking traffic.

3. A connection is slow or stalls

First, separate network delay from application delay. In a TCP stream, look at the time between the completed handshake and the first application response. A long quiet period after the client sends a request, with no retransmissions, may indicate server-side processing or an upstream dependency. Repeated retransmissions, duplicate acknowledgments, or long waits for acknowledgments can indicate loss, congestion, or an unstable path.

Use Statistics → Conversations to find active endpoint pairs and their byte counts. Statistics → IO Graphs can plot traffic volume or filter-specific events over time. A graph may show retransmission bursts that line up with a user-visible stall, but it cannot identify on its own whether the loss happened at the client, in the network, or at the server.

4. HTTP and HTTPS application errors

For plain HTTP in a local training environment, the http filter can reveal methods, host headers, paths, response codes, and response timing. A 404 response confirms that the web server replied but could not find the requested resource. A 500 response means the server returned an internal error, so server logs are the appropriate next source of evidence.

HTTPS encrypts HTTP content, so a standard capture usually reveals connection metadata rather than readable URLs, headers, or page content. Do not attempt to defeat encryption on systems you do not control. In an authorized lab, controlled TLS decryption can help debug an application you operate, but decrypted captures need careful handling because they may contain credentials and session data.

Use expert analysis as a clue, not a diagnosis

Wireshark’s Analyze → Expert Information groups events such as retransmissions, resets, malformed packets, and protocol notes. It is useful for triage in a large capture, but its labels are based on what Wireshark can infer from the packets it sees. Packet loss before the capture point, local adapter offloading features, and incomplete captures can all affect those inferences.

For a focused TCP stream, Follow → TCP Stream can reconstruct bidirectional payloads when they are not encrypted. Treat that output as sensitive operational data. Save it only when necessary, store it securely, and redact it before attaching it to a ticket or sharing it outside the approved troubleshooting group.

Build a repeatable troubleshooting record

A capture is much more useful when it has context. Use File → Save As and prefer the modern .pcapng format unless another tool requires a different format. Keep a short text note with the capture point, local time zone, test action, affected application version, relevant IP addresses, and whether the failure occurred.

Before sharing an authorized capture, reduce exposure. Save only the necessary packet range or use a display filter before exporting selected packets. Review visible names, addresses, cookies, tokens, and payload content. Packet anonymization can help, but it may also damage protocol relationships needed for analysis. Keep the original access-controlled and follow your organization’s retention rules.

After making one approved change, such as correcting a DNS resolver setting or restarting a service, repeat the same test. Capture the same short window, apply the same filter, and compare the traces. For example, a failed sequence of repeated SYN packets may become SYN, SYN-ACK, ACK, followed by the expected application exchange.