Open Wireshark on a busy network and you get thousands of rows in a few seconds. The difference between scrolling for twenty minutes and finding the answer in two is usually one well-typed filter. What follows are the display and capture filters that keep earning their place — the ones that come up again and again in troubleshooting, traffic analysis, and a first pass at something that looks off.

Know Which Kind of Filter You Are Typing

Wireshark has two filter languages, and mixing them up is the most common beginner frustration.

• Capture filters run before packets are written to the file. You set them in Capture Options, and anything they reject never reaches the capture. Whatever is dropped is gone for good.
• Display filters run against an existing capture and can be changed as often as you like. Nothing is thrown away; you just change what you are looking at.

The syntax differs too. Capture filters use Berkeley Packet Filter syntax — host, port, net, joined with and, or, not. Display filters use comparison operators and symbols: ==, !=, &&, ||, !. So a capture filter reads port 53, while the equivalent display filter is udp.port == 53.

When you are unsure, capture more than you think you need and filter while reading. Disk space is cheap. A packet that was never recorded is not.

The Display Filters You Will Type Most

• ip.addr == 192.168.1.10 — every packet to or from that host, both directions. Use ip.src == or ip.dst == when you only care about one side.
• ip.addr == 10.0.0.0/8 — whole subnets work, which is handy when you do not know the exact host yet.
• tcp.port == 443 or udp.port == 53 — one port, either direction. Add a host with && to narrow it down.
• tcp.stream eq 4 — a single conversation. Find the number by right-clicking any packet and choosing Follow, then TCP Stream.
• dns, http, tls, arp, icmp, dhcp — protocol names on their own are valid filters. That is often all you need.
• http.response.code >= 400 — server-side errors without the noise of successful requests.
• tls.handshake.type == 1 — TLS Client Hello packets, which show what a client asked for even when everything is encrypted.
• tcp.len > 0 — only packets actually carrying application data, no bare acknowledgements.
• !arp && !icmp — strips the chatter so the real traffic is easier to see.

The filter bar turns green when the syntax is valid and red when it is not, which saves a lot of guessing. Autocomplete appears as you type field names.

Filters for Troubleshooting Broken or Slow Connections

Connection attempts and failures

• tcp.flags.syn == 1 && tcp.flags.ack == 0 — every attempt to open a TCP connection. If you see a SYN with no SYN/ACK reply, the path or the service is the problem.
• tcp.flags.reset == 1 — connections killed abruptly, often by a firewall, a load balancer, or a closed port.
• icmp.type == 3 — destination unreachable messages, which sometimes explain a silent timeout.

Performance problems

• tcp.analysis.flags — the single most useful shortcut in Wireshark. It shows retransmissions, duplicate acknowledgements, zero-window events and other problems Wireshark has already spotted.
• tcp.analysis.retransmission — packets sent again because no acknowledgement arrived. Frequent retransmissions point at loss or congestion.
• tcp.analysis.zero_window — the receiver told the sender to stop because its buffer was full. That usually means the problem is on the receiving application, not the network.

Name resolution

• dns.flags.response == 0 — outgoing queries only.
• dns.flags.rcode != 0 — failed lookups. If a site is slow to start, check here before blaming the web server.

Filters for a First Look at Something Suspicious

These are starting points, not verdicts. A filter tells you where to look, and the packets themselves tell you what happened.

• arp — a burst of ARP traffic is worth a look. Duplicate address warnings and constant repeated requests can indicate a misconfiguration or a spoofing attempt on a flat network.
• tcp.flags.syn == 1 && tcp.flags.ack == 0 && ip.src == 203.0.113.5 — replace the address with a host you are curious about. Many SYNs to many ports from one source is the shape of a port scan.
• tcp.port == 445 or tcp.port == 3389 — file sharing and remote desktop traffic on a network where neither should exist.
• http.request.method == "POST" — form submissions and login attempts in clear text.
• frame contains "passwd" — searches packet payloads for a string. It is case-sensitive, so try variants, and remember it only works on protocols that send data unencrypted.
• dns.qry.name contains "example" — follow a specific domain or keyword through DNS queries, including queries that never get a useful answer.
• tls.handshake.extensions_server_name contains "example.com" — shows hostnames in TLS handshakes even though the session content stays encrypted.

Capture only on networks you own or have explicit permission to monitor. Grabbing credentials or personal data from someone else's traffic is not troubleshooting.

Capture Filters That Keep Files Manageable

Long captures on a busy link produce enormous files. A capture filter applied up front keeps them workable.

• host 192.168.1.10 — one machine, both directions.
• net 192.168.1.0/24 — one subnet.
• port 53 — DNS only, useful for a quick resolver check.
• tcp port 443 and host 192.168.1.10 — combine terms with and, or, and not.
• not port 22 — everything except your own SSH session, which otherwise fills the file with your keystrokes.
• ether host 00:1a:2b:3c:4d:5e — a single MAC address, handy on switched networks.

Once a capture is running, these cannot be changed. If you realise mid-capture that the filter was too tight, stop and restart.

Habits That Make Filtering Faster

You do not have to memorise field names. Right-click a field in the packet details pane and choose Apply as Filter, or Prepare as Filter, to build the expression for you. The arrow keys in the filter bar cycle through filters you have already used, and the bookmark icon saves the ones you want to keep permanently.

The same display filter syntax works on the command line, which matters when you are working on a server without a graphical interface. Reading a saved file with tshark -r capture.pcap -Y "tcp.analysis.retransmission" gives you the same answer, and it is far easier to script than clicking through a window.

Build a Cheat Sheet You Actually Use

Keep a plain text file and add a filter only when it has helped you solve something, with one line explaining the situation. Within a month that file will be more useful than any generic list, because every entry maps to a problem you have already met.

A good way to practise: capture a few minutes of your own browsing, then work through it in order. Find the DNS query that resolved the site, the TLS Client Hello that followed, and the TCP stream carrying the response. Follow that sequence once or twice and the filters stop being things you look up and start being reflexes.

Photo: Bru-nO / Pixabay