Wireshark Packet Analysis: A Practical Guide to Reading Network Traffic

When an application is slow, a connection keeps failing, DNS behaves strangely, or a server appears unreachable, looking only at application logs is sometimes not enough.

You may need to see what is actually moving across the network.

That's where Wireshark becomes useful.

Wireshark lets you capture and inspect network packets so you can investigate communication between devices, applications, and services.

But the difficult part isn't installing Wireshark.

The difficult part is knowing:

• what traffic matters
• which packets to filter
• what TCP is telling you
• how DNS requests appear
• how to follow a conversation
• how to distinguish a network problem from an application problem

This guide focuses on that practical workflow.

The Mental Model

Don't think of Wireshark as:

"A tool that shows thousands of packets."

Think of it as:

Network traffic
      ↓
Packets
      ↓
Protocols
      ↓
Fields
      ↓
Filters
      ↓
Evidence
      ↓
Diagnosis

The goal isn't to stare at packets.

The goal is to use packets to answer a question.

Before Opening Wireshark

Start with a question.

For example:

Why can't my application connect to the API?

Or:

Is the client actually sending a DNS request?

Or:

Is the TCP connection being established?

Or:

Is the server responding slowly?

A useful investigation might look like:

Application problem
       ↓
Check network communication
       ↓
Capture traffic
       ↓
Filter relevant packets
       ↓
Inspect protocol details
       ↓
Find where communication changes
       ↓
Form a hypothesis

That is much more useful than capturing everything and hoping you discover something.

Capture Your First Traffic

Open Wireshark and look at the available network interfaces.

You may see interfaces such as:

Wi-Fi
Ethernet
Loopback

Choose the interface carrying the traffic you want to investigate.

Start a capture.

Then generate a small amount of traffic.

For example, open a website or make a request from your terminal:

curl https://example.com

Stop the capture after a few seconds.

You may now have hundreds or thousands of packets.

Don't panic.

The next step is filtering.

Capture Filters vs Display Filters

This distinction is extremely important.

Wireshark has two different filtering concepts.

Capture Filter

A capture filter limits what gets captured.

Conceptually:

Only capture traffic matching X

This can reduce the amount of traffic collected.

Display Filter

A display filter works on packets already captured.

Conceptually:

Capture everything available
        ↓
Hide packets that aren't interesting

For example:

tcp

shows TCP packets in the captured traffic.

This distinction matters because a display filter does not delete the packets that don't match it.

You are simply changing what is displayed.

Your First Display Filters

Start with:

tcp

Now you should primarily see TCP traffic.

Try:

udp

to focus on UDP packets.

Try:

dns

to focus on DNS traffic.

And:

http

to look for HTTP traffic when HTTP packets are present in the capture.

The important idea is:

Huge capture
     ↓
Filter
     ↓
Smaller investigation

Filter by IP Address

Suppose you are investigating:

192.168.1.20

You can filter packets involving that address:

ip.addr == 192.168.1.20

You can narrow it further.

Source address:

ip.src == 192.168.1.20

Destination address:

ip.dst == 192.168.1.20

This is extremely useful when your capture contains traffic from many devices.

Instead of asking:

"What is happening in this capture?"

you can ask:

"What is this particular host doing?"

Filter by Port

Suppose your API runs on:

3000

You can use:

tcp.port == 3000

For HTTPS traffic:

tcp.port == 443

For DNS over traditional UDP:

udp.port == 53

You can combine conditions.

For example:

ip.addr == 192.168.1.20 && tcp.port == 443

Now you're narrowing the investigation to HTTPS-related TCP traffic involving that host.

Understanding a Packet

Click a packet.

Wireshark typically gives you several levels of information.

You may see something conceptually like:

Frame
Ethernet
Internet Protocol
Transmission Control Protocol
Application Protocol

Each layer provides different information.

Think about it like this:

Application
    ↓
TCP / UDP
    ↓
IP
    ↓
Ethernet / Wi-Fi

You don't need to memorize every field.

Instead, learn to ask:

Which layer contains the evidence I'm looking for?

The TCP Handshake

One of the most useful things to recognize is the TCP three-way handshake.

Conceptually:

The basic sequence is:

Client → SYN
Server → SYN/ACK
Client → ACK

If this succeeds, the TCP connection can proceed.

This gives you an important troubleshooting clue.

What If the Handshake Fails?

Imagine you see:

Client → SYN
Client → SYN
Client → SYN

but you don't see the expected response.

That doesn't immediately tell you the exact cause.

But it gives you a direction.

Possible areas to investigate include:

• routing
• firewall rules
• server availability
• security groups
• incorrect destination
• service not listening
• network filtering

The packet capture provides evidence.

You still need to interpret that evidence in the context of the system.

Find DNS Requests

DNS is another excellent place to start when troubleshooting.

Filter:

dns

You might see a DNS query for:

api.example.com

and a response containing an address.

Conceptually:

This lets you separate two different problems.

Problem A

The application never receives a useful DNS response.

Possible area:

DNS

Problem B

DNS works, but the application cannot establish the connection.

Possible areas:

TCP
Routing
Firewall
Server

This is why packet analysis can be so useful.

It helps you locate where the failure begins.

A Realistic Troubleshooting Example

Imagine your Node.js application calls:

https://api.example.com

but the request keeps timing out.

Instead of immediately changing application code, investigate the network.

Step 1: Find DNS

Use:

dns

Check whether the hostname is resolved.

Step 2: Find the destination

Identify the resulting IP address.

For example:

203.0.113.20

Step 3: Filter the host

ip.addr == 203.0.113.20

Step 4: Look for TCP

tcp

Step 5: Inspect the connection

Look for:

SYN
SYN/ACK
ACK

Now you have a much clearer picture.

Follow a TCP Conversation

When you find an interesting TCP packet, Wireshark can help you follow the conversation.

The exact menu placement can vary by version, but the idea is:

Interesting TCP packet
        ↓
Follow conversation
        ↓
Inspect the stream

This can be much easier than manually searching through hundreds of packets.

Instead of looking at individual packets, you're looking at the broader conversation.

This is particularly useful when debugging:

• application connections
• API requests
• long-running TCP sessions
• protocol behavior
• connection resets

TCP Retransmissions

Another useful signal is retransmission.

You may encounter a display filter such as:

tcp.analysis.retransmission

Retransmissions can indicate that packets weren't successfully acknowledged as expected.

But don't make this mistake:

Retransmission
     =
Network is definitely broken

That's too simplistic.

A packet capture is evidence, not a complete diagnosis.

You need to understand:

• how often retransmissions occur
• where they occur
• whether the application is affected
• whether latency or packet loss is involved
• whether the behavior is expected in the environment

TCP Resets

Another useful filter is:

tcp.flags.reset == 1

A TCP reset can indicate that a connection was abruptly rejected or terminated.

Again, don't automatically label it a security incident.

A reset can occur for legitimate reasons.

For example:

Client
  ↓
Connection attempt
  ↓
Server / network behavior
  ↓
RST

The important question is:

Why did the reset happen in this particular connection?

Context matters.

Reading HTTP Traffic

If your environment uses unencrypted HTTP, you can inspect application-layer information directly.

For example:

http

may reveal requests and responses.

You may be able to see information such as:

GET /api/users
Host: example.com

and the corresponding response.

This can be useful when learning how HTTP works.

However, modern production applications commonly use HTTPS.

HTTPS Changes What You Can See

With encrypted HTTPS traffic, you should not expect to simply read the HTTP request body in a normal capture.

You may still observe useful network metadata and protocol behavior, but encryption changes what application content is directly visible.

This is an important lesson:

Packet capture
      ≠
Automatic access to decrypted application data

Encryption exists specifically to protect application data in transit.

For authorized debugging environments, there are controlled ways to analyze encrypted traffic when the appropriate keys or debugging configuration are available.

Use Filters Instead of Scrolling

One of the biggest beginner mistakes is manually scrolling through packets.

Don't.

Use filters.

For example:

dns

then:

tcp

then:

ip.addr == 192.168.1.20

then:

tcp.port == 443

Then combine them when necessary:

ip.addr == 192.168.1.20 && tcp.port == 443

The goal is to continuously reduce noise.

Useful Display Filters

Don't try to memorize all of these immediately.

Learn them as answers to questions.

A Better Way to Learn Filters

Instead of memorizing:

tcp.analysis.retransmission

remember:

"I suspect packets are being retransmitted. What filter would show me retransmissions?"

Then search the filter reference or use Wireshark's filter-building tools.

The skill is knowing what you're trying to isolate.

Packet Analysis for Developers

Wireshark isn't only for security professionals.

Developers can use it too.

Suppose your frontend calls:

https://api.example.com/users

and the request feels slow.

Your application logs might show:

Request started
Request finished

But Wireshark can help investigate the network side:

DNS
 ↓
TCP connection
 ↓
TLS
 ↓
Application traffic
 ↓
Response

This gives you another debugging layer.

Your problem might be:

Application

or:

Network

or:

DNS

or:

Server

Packet analysis helps separate those possibilities.

Wireshark for SOC Analysts

For a security analyst, packet analysis can support investigations such as:

• unusual DNS activity
• unexpected connections
• suspicious hosts
• protocol anomalies
• repeated connection attempts
• unexpected destinations
• unusual traffic patterns

But packet analysis should be combined with other evidence.

For example:

Packet capture
      +
Endpoint logs
      +
DNS logs
      +
Firewall logs
      +
Authentication logs

Together, these can provide a much stronger investigation.

Don't Confuse Observation With Conclusion

Suppose you observe:

A workstation
     ↓
connects to
     ↓
an unfamiliar IP

That is an observation.

It does not automatically mean:

The workstation is compromised.

You still need to investigate:

• what application generated the connection
• whether the destination is legitimate
• when the connection occurred
• how frequently it happens
• what other telemetry says

Good analysts separate:

Evidence

from:

Conclusion

A Simple Investigation Workflow

When something looks suspicious or broken, use:

This prevents random packet hunting.

Karyvio Practice Lab

Build a small local lab.

Run a simple web server.

For example:

python -m http.server 8000

Then open:

http://127.0.0.1:8000

Capture the traffic with Wireshark.

Now investigate:

tcp.port == 8000

Look at:

• source port
• destination port
• TCP flags
• sequence information
• packet timing
• HTTP request
• HTTP response

Then stop the server.

Run the request again.

Compare what changed.

This is a much better learning exercise than memorizing Wireshark filters.

Another Practice Challenge

Create a simple API.

For example:

Node.js API
    ↓
localhost:4000

Capture traffic while calling:

curl http://127.0.0.1:4000/health

Then filter:

tcp.port == 4000

Try to identify:

Client
   ↓
TCP connection
   ↓
HTTP request
   ↓
HTTP response

Now repeat the experiment with an incorrect port.

For example:

curl http://127.0.0.1:4999/health

Compare the packet behavior.

The goal is to see how a successful and unsuccessful connection differ.

Common Beginner Mistakes

Capturing Too Much

If you capture an entire busy network, you can quickly become overwhelmed.

Start with a focused question.

Filtering Too Late

Don't spend ten minutes scrolling.

Filter early.

Confusing Capture and Display Filters

Remember:

Capture filter
→ controls what gets captured

Display filter
→ controls what you see

Assuming Every Anomaly Is an Attack

Unusual does not automatically mean malicious.

Investigate before concluding.

Ignoring Context

One packet rarely tells the entire story.

Look at the conversation.

Looking Only at IP Addresses

Also consider:

• ports
• protocols
• timing
• TCP flags
• DNS
• application behavior

Wireshark vs Nmap

If you're learning cybersecurity, these tools complement each other.

Think of them as different viewpoints.

Nmap
  ↓
Discover exposure

Wireshark
  ↓
Inspect communication

For example:

Nmap
→ Port 443 is open

Wireshark
→ Observe the traffic using that connection

This combination makes your network understanding much stronger.

What to Learn After Basic Packet Analysis

Once you are comfortable with basic captures and filters, move into:

Ethernet
   ↓
ARP
   ↓
IP
   ↓
TCP / UDP
   ↓
DNS
   ↓
HTTP / HTTPS
   ↓
TLS
   ↓
Application protocols

Then study:

• TCP connection behavior
• retransmissions
• latency
• DNS failures
• HTTP status codes
• TLS handshakes
• network segmentation
• firewall behavior
• packet capture analysis

Don't rush into advanced protocol analysis before understanding the basics.

Your Wireshark Learning Checklist

You should eventually be comfortable doing all of these:

□ Select the correct interface
□ Start and stop a capture
□ Apply a display filter
□ Filter by IP
□ Filter by port
□ Identify TCP traffic
□ Identify DNS traffic
□ Understand a TCP handshake
□ Find retransmissions
□ Find TCP resets
□ Follow a conversation
□ Inspect protocol layers
□ Save a capture
□ Explain what the packets show
□ Separate evidence from assumptions

If you can do these without blindly copying commands, you have a solid foundation.

Final Takeaway

Wireshark becomes much easier when you stop treating it as a packet viewer.

Treat it as an investigation tool.

Start with a question:

What am I trying to find?

Then:

Capture
   ↓
Filter
   ↓
Inspect
   ↓
Follow
   ↓
Compare
   ↓
Verify

A packet by itself is just data.

A series of packets can reveal:

• whether a connection was attempted
• whether a server responded
• whether DNS worked
• whether TCP completed its handshake
• whether retransmissions occurred
• where communication changed

That is the real value of Wireshark.

Don't learn Wireshark by memorizing filters. Learn it by asking better network questions.