When your internet stutters during a video call, drops packets in an online game, or loads web pages inconsistently, most guides tell you to run a ping test or a traceroute. Those tools confirm that something is wrong — but they rarely show you exactly what is failing or where the breakdown happens inside your network traffic. That is where Wireshark changes the picture entirely.

Wireshark is a free, open-source packet analyzer that captures every piece of data moving through your network adapter in real time. Instead of sending a handful of test packets like ping does, Wireshark records the actual traffic your computer generates — including TCP handshakes, DNS queries, retransmissions, and dropped segments. If you want to use Wireshark to find packet loss on your home network in Windows, this guide walks through every step: installation, capture setup, reading output, applying display filters, and interpreting the results that matter.

No prior experience with packet analysis is required.

What Wireshark Shows That Ping and Tracert Cannot

Ping and tracert are useful starting points, but they operate with significant blind spots. Understanding those limits helps explain why Wireshark is the next logical step when basic tools give you inconclusive results.

When to Use Wireshark Instead of Ping or Tracert

Ping sends ICMP echo requests and measures round-trip time. It tells you whether a host is reachable and how long the reply takes. Tracert maps the hop-by-hop path your packets follow to a destination. Both tools are built into Windows and useful for quick checks — but neither one examines actual TCP sessions, DNS resolution behavior, or application-layer data.

If your ping results look normal but your browser still stalls, or your traceroute completes without any timeouts but streaming still buffers, the issue likely sits inside the TCP conversation itself — retransmissions, lost segments, slow DNS replies, or duplicate acknowledgments. These problems are invisible to built-in network diagnostic tools alone. Wireshark captures the raw conversation between your machine and the server, making these failures visible and measurable.

What Wireshark Cannot Do — Important Limits for Home Users

Wireshark only captures traffic that passes through the network interface on the machine where it is running. It does not monitor your entire home network from one device. It cannot see traffic on other devices unless your network is configured for port mirroring, which most home routers do not support.

It also cannot decrypt encrypted traffic (like HTTPS) without access to the session keys. You will see that a TLS connection exists, and you can analyze TCP-layer behavior around it, but you will not see the content inside. For diagnosing packet loss and DNS failures, this limitation rarely matters — the indicators you need (retransmissions, lost segments, DNS timeouts) are all visible at the TCP and UDP layers.

With those expectations set, the next step is getting Wireshark installed on your Windows machine with the correct capture driver.

How to Install Wireshark on Windows 11

Wireshark runs on Windows 10 and Windows 11 without any compatibility issues. The installation itself is straightforward, but there is one critical component that trips up most beginners — the packet capture driver.

What Npcap Is and Why You Must Install It

Wireshark does not capture packets on its own. It relies on a separate low-level driver called Npcap that interfaces directly with your network adapter. Without Npcap, Wireshark will open but no network interfaces will appear in the capture list — and you will not be able to record any traffic.

When you download the latest stable version from the official Wireshark download page, the installer bundles Npcap and offers to install it during setup. Leave that option checked. If you already have an older version of Npcap or the deprecated WinPcap installed, the installer will prompt you to update. Accept the update — older versions can cause capture failures on Windows 11.

If you ever need to reinstall or update Npcap separately, it is available directly from npcap.com. During Npcap’s own setup, make sure the option “Install Npcap in WinPcap API-compatible Mode” is checked, as some tools depend on that compatibility layer.

Common Wireshark Install Problems on Windows and How to Fix Them

The most frequent issue is launching Wireshark after installation and seeing zero interfaces listed. This almost always means Npcap did not install correctly. Uninstall Npcap from Windows Settings, restart your machine, then reinstall Npcap alone before reopening Wireshark.

Another common problem is a Windows SmartScreen warning blocking the installer. This happens because the executable is freshly downloaded. Click “More info” and then “Run anyway” — the installer is digitally signed and safe from the official source.

If Wireshark opens but crashes during a capture, check that your version matches your system architecture. Use the 64-bit installer on 64-bit Windows, which covers nearly all modern machines.

How to Start a Packet Capture on Your Home Network

Once Wireshark is installed and Npcap is running, you are ready to capture live traffic. The first decision — and the one most beginners get wrong — is choosing the correct network interface.

Which Network Interface to Select — WiFi or Ethernet

When Wireshark opens, the welcome screen displays every network interface on your system. You will typically see entries like “Wi-Fi”, “Ethernet”, “Loopback Adapter”, and possibly virtual adapters from VPN software or virtual machines.

Select the interface your computer is actively using to reach the internet. If you are connected through a cable, choose Ethernet. If you are on wireless, choose Wi-Fi. A simple way to confirm the correct one is to look at the small activity graph next to each interface name — the one with a moving waveform is carrying live traffic.

Selecting the wrong interface is the number one reason beginners see an empty capture with zero packets. If loopback or a virtual adapter is selected, Wireshark will only record internal system traffic, which is useless for diagnosing internet problems.

How to Start and Stop a Capture Correctly

Double-click the correct interface name, and the capture begins immediately. You will see rows of packets start filling the main window — each row representing a single network frame with a timestamp, source address, destination address, protocol, and a brief info summary.

To stop the capture, click the red square button in the toolbar or press Ctrl+E. Once stopped, the data remains in memory and you can apply filters, inspect individual packets, and analyze results. You can also save the capture as a .pcapng file for later analysis by going to File → Save As.

How Long to Capture — and When to Stop

For diagnosing intermittent issues like buffering or dropped connections, capture for at least two to three minutes while actively reproducing the problem. Open the web page that fails, start the video call that stutters, or begin the download that stalls — then stop the capture shortly after the issue occurs.

Capturing too long without a specific problem in focus creates a massive file full of normal traffic, making it harder to isolate the relevant packets. Short, targeted captures produce cleaner results. If you are investigating latency spikes or jitter, keep the session focused on the exact window where the symptom appears.

With a clean capture file in hand, the next step is understanding what Wireshark is actually showing you on screen.

How to Read the Wireshark Interface for the First Time

Wireshark presents a dense amount of information the moment a capture loads. For beginners, the screen can look overwhelming — thousands of rows, cryptic protocol names, and hex data filling the bottom of the window. The layout becomes manageable once you understand how the three main panels work together.

What the Three Main Panels Show

The Wireshark window is divided into three stacked panels, each showing a different level of detail for the same data.

The top panel is the packet list. Every row represents one captured packet, displayed in the order it was received. Each row includes a packet number, timestamp, source IP address, destination IP address, protocol type, packet length, and a brief description in the Info column. This panel is where you scan for patterns — clusters of retransmissions, DNS queries, or error responses.

The middle panel is the packet detail pane. When you click any row in the top panel, the middle panel expands the full protocol stack for that specific packet. You will see collapsible sections for Ethernet, IP, TCP or UDP, and application-layer protocols like DNS or HTTP. This is where you inspect individual header fields such as sequence numbers, acknowledgment numbers, TTL values, and flags.

The bottom panel displays the raw hex and ASCII dump of the selected packet. Most home network troubleshooting does not require reading raw hex, but it is useful for verifying exact byte-level content when something looks unusual in the detail pane above.

What the Color Coding in Wireshark Means

Wireshark applies color rules to the packet list by default. These colors are not decorative — they carry diagnostic meaning. Normal TCP traffic typically appears in shades of green or light purple. DNS traffic shows as blue. HTTP traffic is bright green.

The critical colors for troubleshooting are black with red text and dark red backgrounds. Black-highlighted packets usually indicate TCP errors — retransmissions, duplicate acknowledgments, or reset connections. Red coloring flags serious problems like malformed packets or unreachable destinations. If you see clusters of black or red rows in your capture, those areas deserve immediate inspection.

You can view or customize the full color rule set by navigating to View → Coloring Rules in the menu bar.

How to Use Expert Information to Find Problems Immediately

Instead of scrolling through thousands of packets manually, Wireshark provides a built-in diagnostic summary called Expert Information. Access it through Analyze → Expert Information from the top menu.

This window categorizes every notable event in the capture into severity levels: Chat (informational), Note (minor anomalies), Warning (potential issues), and Error (confirmed failures). For internet troubleshooting, focus directly on the Warning and Error tabs. Entries like “TCP Retransmission,” “TCP Previous Segment Not Captured,” and “DNS response not seen” will appear here if they exist in your capture.

Clicking any entry in the Expert Information window jumps directly to the corresponding packet in the main view, saving significant time. This single feature makes Wireshark far more approachable for beginners — you do not need to know what to search for manually when Expert Info highlights the problems for you.

How to Find Packet Loss in Wireshark

Packet loss does not always announce itself with a timeout or a disconnection. In many cases, your browser retries silently, your video call degrades slightly, or your download slows without any obvious error message. Wireshark exposes these hidden failures by flagging every TCP anomaly that indicates data did not arrive as expected. Understanding the three primary indicators — lost segments, retransmissions, and duplicate acknowledgments — is the core skill for using Wireshark to find packet loss on your home network in Windows.

What TCP Previous Segment Not Captured Means

When Wireshark displays “TCP Previous Segment Not Captured” in the Info column, it means a packet arrived with a sequence number that jumps ahead of what was expected. The packet before it — the one that should have carried the missing sequence range — never appeared in the capture.

This happens for two reasons. Either the packet was genuinely lost somewhere between the sender and your machine, or your system was too slow to capture it and Wireshark missed it during high-throughput traffic. On a home network with a reasonably modern computer, the first explanation is far more common. Clusters of these warnings, especially during active browsing or streaming, are a strong signal of real packet loss between your router and the remote server.

What TCP Retransmission Means and Why It Matters

A TCP Retransmission means the sender transmitted a packet, did not receive an acknowledgment within the expected time window, and sent the same data again. Wireshark labels these clearly in the Info column.

Occasional retransmissions are normal on any network. TCP is designed to recover from occasional drops. The problem starts when retransmissions appear frequently — dozens or hundreds in a short capture. That pattern indicates a persistent delivery failure, often caused by WiFi interference, a congested uplink, or a degraded path between your ISP and the destination. If you previously ran a ping test and saw request timed out errors while your internet still appeared to work, retransmissions in Wireshark confirm that TCP was silently compensating for those drops.

What Duplicate ACK Means in a Packet Capture

A Duplicate ACK occurs when the receiving side sends the same acknowledgment number more than once. This is the receiver’s way of telling the sender, “I am still waiting for a specific segment — I got later data, but the earlier piece is missing.” Three consecutive duplicate ACKs trigger a mechanism called fast retransmit, where the sender immediately resends the missing segment without waiting for a full timeout.

In Wireshark, duplicate ACKs appear as separate packets with identical acknowledgment numbers. Seeing them occasionally is harmless. Seeing them repeatedly alongside retransmissions confirms sustained packet loss within a TCP session.

The Exact Filter to Use — tcp.analysis.lost_segment

To isolate only the packets related to loss, type the following display filter into the filter bar at the top of the Wireshark window:

tcp.analysis.lost_segment || tcp.analysis.retransmission

This filter removes all normal traffic and shows only lost segments and retransmissions. You can also use tcp.analysis.duplicate_ack to add duplicate acknowledgments to the view. Combine them with the OR operator for a complete loss picture:

tcp.analysis.lost_segment || tcp.analysis.retransmission || tcp.analysis.duplicate_ack

Apply the filter and examine what remains. If the filtered view is nearly empty, your capture has minimal loss. If it contains hundreds of entries concentrated around specific time windows, those are the moments where your connection was actively degrading.

How to Count Packet Loss Rate from Wireshark Output

After applying the loss filter, look at the status bar at the bottom of the Wireshark window. It shows the total number of displayed packets versus total captured packets — for example, “Displayed: 87 of 4,230.” Dividing the displayed count by the total and multiplying by 100 gives a rough packet loss percentage.

In that example, 87 ÷ 4,230 × 100 ≈ 2.06% loss. Any value above 1% typically causes noticeable quality problems in real-time applications. Values above 3–5% affect even basic web browsing. This calculation is an approximation since not every flagged packet represents a unique lost segment, but it provides a practical measurement that is far more useful than the binary pass-or-fail result you get from a standard ping troubleshooting session.

How to Find DNS Problems in Wireshark

DNS failures cause a specific kind of frustration — pages refuse to load, browsers display “DNS_PROBE_FINISHED” errors, and yet your connection appears active. Wireshark lets you see the exact DNS query your computer sent, whether a response came back, how long it took, and what the response contained.

How to Filter Only DNS Traffic

Type the following display filter into the filter bar:

dns

This removes all TCP, HTTPS, and background traffic, leaving only DNS queries and responses. Every row in the filtered view represents either a request your computer sent to a DNS server or a reply it received back. This makes it easy to trace exactly what happened when a page failed to load.

What a Normal DNS Request and Reply Looks Like

A healthy DNS exchange consists of two packets. The first is a Standard Query sent from your machine to your configured DNS server, asking for the IP address of a domain — for example, example.com. The second is a Standard Query Response from the DNS server, returning the resolved IP address.

In the Info column, the query packet shows the domain name and the record type (usually A for IPv4 or AAAA for IPv6). The response packet shows the same domain followed by the resolved address. When both packets exist in close succession — typically within 10–50 milliseconds — DNS is working normally.

What a DNS Failure Looks Like in Wireshark

A DNS failure shows up in one of three ways. First, you may see a query packet with no matching response at all. The request left your machine, but nothing came back — indicating the DNS server was unreachable or dropped the request. Second, the response may return with a Server Failure (SERVFAIL) or Name Error (NXDOMAIN) code visible in the packet details. Third, you may see multiple identical queries repeated rapidly, meaning your system kept retrying because the first attempts failed.

If your capture shows unanswered DNS queries or repeated SERVFAIL responses, your DNS server is the bottleneck. Switching to a different DNS provider or troubleshooting your current configuration using a DNS server not responding fix guide is the logical next step.

How to See If Your DNS Is Slow or Not Responding

To measure DNS response time, click on a DNS query packet in the packet list, then locate the matching response. Wireshark shows the timestamp for both packets. Subtract the query time from the response time to get the DNS resolution delay.

Alternatively, Wireshark automatically calculates this for you. Click on the DNS response packet and expand the Domain Name System section in the detail pane. Look for the field labeled “Time” under the response — this shows the elapsed time since the matching query. Anything under 50 milliseconds is healthy. Values between 100–300 milliseconds indicate a slow DNS server. If the value exceeds 500 milliseconds or no response appears at all, DNS is actively contributing to your browsing problems.

How to Find High Latency Problems in Wireshark

Beyond packet loss and DNS failures, high latency in TCP connections causes sluggish page loads, delayed application responses, and poor real-time performance. Wireshark measures this latency directly from the captured traffic.

What RTT Means in Wireshark Packet Data

RTT stands for Round Trip Time — the total time a packet takes to travel from your machine to the destination server and for the acknowledgment to return. Wireshark calculates RTT automatically for TCP streams by tracking the delta between data segments and their corresponding ACKs.

You can view RTT data by selecting any TCP ACK packet and expanding the SEQ/ACK analysis section under TCP in the packet detail pane. The field labeled “iRTT” (initial round trip time) or “RTT to ACK” shows the measured value in seconds.

How to Spot High Round Trip Time in TCP Packets

Healthy connections to servers within your region typically show RTT values between 10–80 milliseconds. If your capture reveals RTT values consistently above 150 milliseconds for domestic servers, or above 300 milliseconds for international destinations, latency is high enough to cause visible performance problems.

To find the worst offenders, use Wireshark’s Statistics → TCP Stream Graphs → Round Trip Time option. This generates a visual graph of RTT across the entire capture, making spikes easy to identify. Sudden jumps in RTT often correlate with the exact moments where you experienced lag or buffering during the capture session.

The 6 Most Useful Wireshark Display Filters for Internet Problems

Display filters are the most efficient way to cut through thousands of captured packets and isolate exactly what matters. Below are six filters every home user should save for diagnosing internet issues. Type each one directly into the filter bar at the top of the Wireshark window and press Enter.

Filter 1 — Show Only Packet Loss

tcp.analysis.lost_segment

This shows every instance where Wireshark detected a missing TCP segment — a packet that should have arrived but never did. If this filter returns a significant number of results, your connection is experiencing active packet loss.

Filter 2 — Show Only DNS Traffic

dns

Isolates all DNS queries and responses. Use this when pages fail to load or resolve slowly. Pair it with the timestamp analysis described in the DNS section above to identify slow or unresponsive DNS servers.

Filter 3 — Show Only Retransmissions

tcp.analysis.retransmission

Displays every packet that TCP had to resend because the original was not acknowledged in time. High retransmission counts directly correlate with degraded performance in browsing, streaming, and real-time applications.

Filter 4 — Show Only Traffic to One IP Address

ip.addr == 8.8.8.8

Replace 8.8.8.8 with any destination IP you want to investigate. This filter narrows the view to all traffic exchanged with that specific host, making it easy to analyze a single connection in isolation.

Filter 5 — Show Only TCP Problems

tcp.analysis.flags

This is a broad filter that catches all TCP anomalies flagged by Wireshark — including retransmissions, duplicate ACKs, zero window conditions, and keep-alive failures. It serves as a general-purpose starting point when you are unsure what type of TCP issue is occurring.

Filter 6 — Show Expert Info Errors Only

_ws.expert.severity == error

This filter surfaces only packets that Wireshark’s Expert Information system classified at the Error severity level. It skips informational notes and minor warnings, showing only confirmed failures. This is the fastest way to jump directly to the most critical problems in any capture file.

Combining filters with the || (OR) or && (AND) operators lets you build custom views. For example, tcp.analysis.retransmission || dns displays both retransmissions and DNS traffic in one filtered view, which is useful when diagnosing multiple symptoms simultaneously.

What to Do After Finding Packet Loss or DNS Errors in Wireshark

Identifying the problem in Wireshark is the diagnostic half. The next step depends on what your capture revealed.

If your capture shows heavy retransmissions and lost segments concentrated on your WiFi interface, the issue is likely local. Switch to a wired Ethernet connection and run a second capture performing the same activity. If the retransmissions disappear, your WiFi environment is the cause — interference from neighboring networks, distance from the router, or an overcrowded channel. Changing your router’s WiFi channel or moving to the 5 GHz band often resolves this immediately.

If packet loss persists on a wired connection, the problem sits beyond your local network. Save the capture file and note the timestamps where loss clusters appear. This data gives your ISP concrete evidence of a degraded connection — far more actionable than saying “my internet feels slow.” Most ISP support teams can escalate a ticket faster when a customer provides specific packet loss percentages and retransmission counts with timestamps.

If your capture revealed DNS failures or slow responses, switch your DNS server to a public alternative like Google DNS (8.8.8.8) or Cloudflare DNS (1.1.1.1) through your Windows network adapter settings. Run another capture afterward to confirm the new server responds faster and without errors.

For a broader understanding of how packet loss, latency, and DNS resolution connect to your overall browsing experience, the internet connectivity explained guide covers the full picture.

When to contact your ISP:

• Packet loss exceeds 1–2% consistently on a wired connection
• Retransmissions appear in every capture regardless of destination server
• DNS queries to your ISP-assigned DNS server go unanswered repeatedly
• RTT values to regional servers exceed 150 ms on a wired connection

If your Wireshark captures show clean results — minimal retransmissions, fast DNS replies, and stable RTT — the issue likely exists on the remote server side or within a specific application, not your home network.

Frequently Asked Questions

How do I use Wireshark to check for packet loss?

Start a capture on your active network interface while reproducing the problem. After stopping the capture, apply the display filter tcp.analysis.lost_segment || tcp.analysis.retransmission to isolate only packets related to loss. Check the status bar for the count of displayed packets versus total packets to estimate a loss rate. You can also open Analyze → Expert Information to see a categorized summary of all TCP anomalies.

What does TCP previous segment not captured mean in Wireshark?

It means Wireshark received a packet with a TCP sequence number that skips ahead, indicating the segment that should have arrived before it was never captured. In most home network scenarios, this signals genuine packet loss — the missing segment was dropped somewhere between the sender and your machine.

What does retransmission mean in Wireshark?

A TCP retransmission means the sender transmitted a data segment, did not receive an acknowledgment within the expected timeout period, and resent the same data. Occasional retransmissions are normal. Frequent retransmissions indicate persistent delivery failures caused by network congestion, WiFi interference, or ISP-side problems.

How do I filter packet loss in Wireshark?

Use the display filter tcp.analysis.lost_segment to show only missing segments. To include retransmissions and duplicate acknowledgments, use the combined filter: tcp.analysis.lost_segment || tcp.analysis.retransmission || tcp.analysis.duplicate_ack. This gives a complete view of all loss-related events in the capture.

How do I check DNS problems using Wireshark?

Apply the display filter dns to isolate all DNS queries and responses. Look for queries that have no matching response, responses containing SERVFAIL or NXDOMAIN codes, or repeated identical queries indicating failed retries. Click on a DNS response and check the time delta to measure how long resolution took.

What is the best Wireshark filter for internet problems?

The filter tcp.analysis.flags catches all TCP anomalies in a single view — retransmissions, lost segments, duplicate ACKs, window problems, and reset connections. For a more targeted approach, tcp.analysis.retransmission focuses specifically on resent packets, and dns isolates name resolution issues. Combining both with tcp.analysis.retransmission || dns covers the two most common causes of internet trouble.

What does duplicate ACK mean in Wireshark?

A duplicate ACK occurs when the receiving side sends the same acknowledgment number multiple times, signaling that it received later data but is still missing an earlier segment. Three consecutive duplicate ACKs trigger a fast retransmit, where the sender immediately resends the missing data without waiting for a full timeout cycle.

Can Wireshark show me if my DNS is slow?

Yes. Click on a DNS response packet and expand the Domain Name System section in the packet detail pane. Wireshark displays the elapsed time since the original query was sent. Responses under 50 milliseconds are healthy. Anything above 200 milliseconds indicates a slow DNS server, and missing responses confirm the server is not replying at all.