How to Analyze Network Traffic Using Wireshark

You are a backend engineer debugging a silent production failure where your microservice cannot complete a TLS handshake with an external payment API. Every log line on your side says "Connection reset by peer," and the vendor insists their endpoint is healthy. You need to capture the raw wire traffic, isolate the failing handshake, and prove whether the packet drop happens locally, in transit, or on the vendor's side.

Why Your Logs Are Lying to You

Application logs show you what your code tried to do; packet captures show you what actually happened on the wire. When a socket drops unexpectedly or an API client throws a cryptic SSL/TLS error, high-level abstractions hide the TCP flags, sequence numbers, and cipher negotiation details you need to diagnose the root cause.

Wireshark is the industry-standard GUI analyzer for inspecting these packets. This guide takes you from zero visibility to diagnosing handshake failures, slow database queries, and unexpected payload modifications using Wireshark 4.2+ on Linux, macOS, or Windows.

Capturing Traffic Without Flooding Your Screen

Before you can analyze packets, you need to capture them cleanly. If you open Wireshark and click "Start Capture" on your primary interface (en0 or eth0), your screen will drown in mDNS noise, Spotify heartbeats, and background telemetry.

CLI Capture via Tshark

For headless servers or remote debugging, use tshark (Wireshark's CLI companion) to write a clean circular buffer capture file. Run this command on your local machine or staging server:

sudo tshark -i eth0 -b filesize:10240 -b files:5 -w /tmp/debug_session.pcapng host api.paymentvendor.com and port 443

• -i eth0: Specifies the target network interface.
• -b filesize:10240: Rotates the capture file when it hits 10MB.
• -b files:5: Keeps a rolling window of the last 5 files (prevents disk space exhaustion).
• -w /tmp/debug_session.pcapng: Writes output in the modern .pcapng format, preserving interface metadata.
• host api.paymentvendor.com and port 443: BPF (Berkeley Packet Filter) syntax to capture strictly relevant traffic.

Open the resulting /tmp/debug_session.pcapng file inside the Wireshark GUI.

Navigating the Three-Pane Layout

When you open your capture in Wireshark, you are greeted by three distinct panes. If you do not configure these correctly, you will waste hours scrolling.

1. The Packet List (Top Pane)

Every row is a single packet. Columns display the frame number, relative timestamp, source and destination IP, protocol, length, and info summary.

Right-click the header row, select Column Preferences, and add these two columns immediately:

• Source Port (tcp.srcport)
• Destination Port (tcp.dstport)

Without port numbers visible, debugging multi-threaded client applications connecting to identical internal IPs is impossible.

2. The Packet Details (Middle Pane)

Clicking any packet in the top pane breaks it down into an expandable OSI-model tree: Frame, Ethernet II, Internet Protocol, Transmission Control Protocol, and Application Layer (e.g., TLS or HTTP).

3. The Packet Bytes (Bottom Pane)

Displays the raw hexadecimal and ASCII representation of the packet payload. This is where you verify if binary payloads match your expected struct serialization.

Filtering Noise with Display Filters

Display filters hide packets you do not care about without deleting them from the capture buffer. Type these directly into the filter bar at the top of the GUI.

Pinpointing the Faulty Handshake

To isolate your failing TLS handshake with the payment API, combine protocol and IP filters:

ip.addr == 192.0.2.45 && (tls.handshake.type == 1 || tls.handshake.type == 2 || tcp.flags.reset == 1)

• ip.addr == 192.0.2.45: Filters for traffic moving to or from the vendor's IP.
• tls.handshake.type == 1: Client Hello.
• tls.handshake.type == 2: Server Hello.
• tcp.flags.reset == 1: Captures TCP RST packets, exposing sudden connection teardowns.

Finding Re-transmissions and Latency Spikes

If your application is experiencing random latency spikes when querying PostgreSQL, check for packet loss and TCP retransmissions:

tcp.analysis.retransmission || tcp.analysis.out_of_order

If Wireshark flags packets with these filters, your network path (or cloud provider security group) is dropping packets under load, forcing TCP window resets and slow-starts.

Following TCP Streams and Decoding TLS

Application payloads are often encrypted, making direct reading impossible. However, you can reconstruct entire TCP conversations and even decrypt TLS sessions if you have the right keys.

Following the TCP Stream

Right-click your API connection packet, select Follow -> TCP Stream.

Wireshark opens a dedicated window showing the complete bidirectional conversation. Client data is color-coded in red; server responses are in blue. This view instantly reveals whether the server returned a clean HTTP 500 JSON payload or if the connection dropped mid-stream during an incomplete chunked transfer encoding block.

Decrypting TLS Traffic for Local Testing

If you are debugging your own application on a staging server and need to see the cleartext JSON request body passing over HTTPS, configure Wireshark to use your session keys via NSS key logging.

1. Export the SSLKEYLOGFILE environment variable in your terminal before starting your development application:

   export SSLKEYLOGFILE=/tmp/tls_keys.log
   node app.js  # or python app.py, go run main.go, etc.
   

2. Open Wireshark, go to Preferences -> Protocols -> TLS.
3. Under (Pre)-Master-Secret log filename, browse and select /tmp/tls_keys.log.
4. Open your capture file. Wireshark will now automatically decrypt all HTTPS payloads, letting you read raw JSON requests and responses in the Packet Details pane.

Note: Never use this in production environments as it exposes cryptographic material to disk storage.

Troubleshooting Common Analysis Roadblocks

Filter syntax returns a red background

If your display filter turns red, your syntax is invalid. Common mistakes include using single quotes for strings (use double quotes: http.host == "api.example.com") or confusing the assignment operator (=) with the comparison operator (==).

Missing packets on a local interface

If you are capturing traffic running on localhost (127.0.0.1) on macOS or Linux, standard interfaces might not catch loopback traffic. On macOS, select the lo0 interface. On Linux, select the any interface or lo. Additionally, ensure you run Wireshark with permissions to access raw packet sockets (e.g., via sudo or by configuring dumpcap capabilities).

Packet capture files are too large to open

If a .pcapng file exceeds 2GB, Wireshark may consume all available RAM and crash. Instead of opening it directly in the GUI, use editcap to split the file on the command line before analysis:

editcap -c 50000 huge_capture.pcapng split_capture.pcapng

This command chunks the file into pieces containing 50,000 packets each.

Alternatives and Prevention

While Wireshark is unmatched for deep-packet forensics, keeping it running continuously in production is inefficient and an unnecessary security risk.

For continuous production monitoring, rely on eBPF-based observability tools like Cilium, Pixie, or standard metrics from Prometheus and Envoy sidecars that track TCP retransmissions, connection timeouts, and TLS error rates at the kernel level. Save Wireshark for what it does best: cracking open complex, low-level network failures when all high-level instrumentation fails.