What My Own Wi-Fi Traffic Looked Like Under Wireshark (And Why 88% of It Wasn't Even TLS)

I've used the internet every day for years without ever actually looking at what leaves my laptop when I open a webpage. So I decided to fix that: install Wireshark, capture a few minutes of completely normal browsing on my home Wi-Fi, and see what's really going on underneath.

What I found surprised me. I expected mostly HTTPS/TLS traffic. Instead, the biggest chunk of data wasn't TLS at all — it was a protocol I barely knew existed.

This post walks through the setup, what I captured, and the three things that changed how I think about "just browsing the web."

Problem Statement

The goal was simple: capture live traffic from a normal browsing session and actually understand it — not just glance at packet counts, but dig into protocols, DNS behavior, top talkers, and anything that looked off. Before this, Wireshark was just an icon I'd never clicked.

Step-by-Step Walkthrough

1. Getting Wireshark Running

I installed Wireshark on Windows 10 and let it install Npcap alongside it — without that driver, no network interfaces show up in the capture list at all. After a restart, I opened Wireshark and picked my Wi-Fi interface, since that was the only one showing live activity in the little traffic graph next to each interface.

2. Generating Some Normal Traffic

Before starting the capture, I closed every other app so the capture wouldn't get flooded with unrelated noise. Then I hit record and did a few ordinary things over 2–3 minutes:

• Opened https://www.wikipedia.org over HTTPS
• Opened http://neverssl.com on purpose, just to see what plain unencrypted traffic looks like
• Ran a couple of terminal commands:

ping 8.8.8.8
nslookup github.com

• Played a short YouTube video for about 15 seconds

Then I stopped the capture and saved it. The final file held 11,272 packets — way more than I expected from a few minutes of "light" browsing.

3. Breaking Down the Protocols

Instead of scrolling through thousands of rows one by one, I used:

Statistics → Protocol Hierarchy

This gives a percentage breakdown of every protocol in the capture, by both packet count and byte volume — which turned out to be the most important view in the whole exercise.

I expected most of the data to be standard HTTPS over TCP. Instead, when I checked the Percent Bytes column, almost 88% of all the data in the capture wasn't TLS/TCP — it was QUIC, a newer transport protocol that runs over UDP instead of TCP. YouTube and other Google services use it now instead of the classic TLS-over-TCP combo, mainly because it's faster to set up and handles packet loss better.

That also explained something odd: TCP accounted for a decent chunk of packets (13.4%) but almost no bytes (0.3%). Those were mostly handshake and acknowledgment packets — the real weight of the video traffic was moving through QUIC the entire time without me noticing anything different.

4. Looking at DNS Queries

To isolate just the questions my laptop was asking (not the responses), I used this filter:

dns.flags.response == 0

Some of the domains that showed up:

• www.youtube.com
• googleads.g.doubleclick.net
• yt3.ggpht.com
• en.wikipedia.org

What caught me off guard was that opening one YouTube video triggered lookups for six different domains within about 20 seconds: the main YouTube domain, a Google accounts domain, a thumbnail CDN, an ad-tracking domain, and the actual video CDN host. Most of these were CDNs and analytics services I never directly asked for.

My DNS server was my home router (192.168.1.1), and every query went out in plain text over UDP port 53. That means anyone on the same network — or my ISP — could see exactly which sites I was visiting, even though the sites themselves were encrypted over HTTPS.

5. Finding the Top Talkers

Next I checked:

Statistics → Conversations

Unsurprisingly, my own machine was in every conversation, but the heaviest single connection by far was the YouTube video CDN — video streaming pulls dramatically more data than loading a text-based page ever does.

6. Checking for Anything Unusual

I filtered for retransmissions with:

tcp.analysis.retransmission

A few things stood out:

• A handful of retransmitted TCP segments, most likely from a weak Wi-Fi signal in my room
• A batch of RST packets — mostly my own laptop tearing down idle keep-alive connections
• Constant SSDP broadcast traffic from my router, plus an mDNS announcement from another device on the same network
• Background traffic to Microsoft telemetry endpoints even though I wasn't running any Office apps

Nothing here looked malicious. But it was a solid reminder of how much a device "talks" in the background even when it feels idle.

How to Verify

If you want to reproduce this yourself:

1. Install Wireshark + Npcap and pick your active network interface
2. Start a capture, then browse normally for 2–3 minutes (mix of HTTPS, an unencrypted site, a DNS lookup, and some streaming)
3. Stop the capture and open Statistics → Protocol Hierarchy — check the Percent Bytes column, not just packet counts
4. Filter with dns.flags.response == 0 to see outbound DNS questions only
5. Open Statistics → Conversations to find your top talkers
6. Filter with tcp.analysis.retransmission to spot connection issues

What I Learned

1. Almost everything is encrypted now — but DNS and SNI still leak where you're going. HTTPS hides the content, not the destination.
2. A single page visit is never one connection. It's a dozen or more, quietly firing off to CDNs, trackers, and third-party services.
3. Filters are what make Wireshark usable. Without them, 11,000+ packets are just noise; with the right filter, the same data tells a clear story.

If I had more time, I'd capture traffic from a single specific app in isolation and compare how differently apps behave on the wire — especially privacy-focused apps versus ad-supported ones.

Common Mistakes

Mistake	Why It Trips People Up	Fix
Assuming HTTPS traffic is always TCP/TLS	QUIC (UDP-based) is now common for major services like YouTube and Google	Always check Protocol Hierarchy by bytes, not assumptions
Judging traffic volume by packet count	Packet count and byte volume tell very different stories (see TCP handshake vs QUIC video)	Sort by Percent Bytes, not Percent Packets
Skipping Npcap during install	Wireshark shows zero interfaces without it	Always let the installer add Npcap, then restart
Scrolling raw packet lists manually	Thousands of packets are unreadable without structure	Use Statistics menus and display filters from the start
Ignoring "idle" background traffic	Devices talk constantly even without active use	Check Conversations and DNS logs even during "quiet" periods

Conclusion

Before this, I thought of the internet as just "pages loading." After actually watching the packets, it feels more like a noisy background conversation that never really stops. Encryption protects what you're sending, but not where you're sending it — and that gap is exactly what tools like Wireshark make visible. If you've never opened it before, I'd genuinely recommend spending twenty minutes capturing your own traffic. It's a strangely eye-opening exercise.