I reach for tcpdump more than any other network tool, and most of my early captures were useless because I captured everything. The trick is deciding what you care about before you start. This is the handful of commands I actually use.

Start here

sudo tcpdump -ni any -c 50

Three flags do the heavy lifting. -n stops it from resolving every IP and port, which keeps the capture fast and readable. -i any covers all interfaces, and -c 50 stops after fifty packets so you are not stuck watching forever.

Filtering, because the firehose lies

# one host, either direction
tcpdump -ni any host 203.0.113.7

# everything EXCEPT that noisy host
tcpdump -ni any not host 10.0.0.8

# by port, by range, by service
tcpdump -ni any port 443
tcpdump -ni any portrange 8000-8010

# direction matters
tcpdump -ni any tcp and src port 22

Put quotes around any expression with spaces or parentheses, or the shell will helpfully split it into two arguments and you will capture nothing.

When you need to see the payload

# -A shows ASCII — perfect for HTTP and plaintext protocols
sudo tcpdump -ni any -A port 80

# -X gives you hex and ASCII side by side
sudo tcpdump -ni any -X port 51820

A word of caution: on a plaintext protocol, a capture file is the plaintext. Do not leave HTTP captures lying around where they do not belong.

Saving instead of watching

# write to a file with -w
sudo tcpdump -ni any -w /tmp/capture.pcap port 443

# bounded rotation: 10 files of 100 MB
sudo tcpdump -ni any -C 100 -W 10 -w /tmp/capture.pcap

# read the file later, same filters apply
tcpdump -nr /tmp/capture.pcap host 10.0.0.5

Watch on the terminal, record to a file, and analyze the file afterwards. The file does not scroll past you while you are trying to think.

Reading a line without squinting

14:03:22.118476 IP 10.0.0.8.54210 > 203.0.113.7.443: Flags [P.], seq 1:145, ack 1, win 501, length 144

Timestamp, then source and destination with ports, then the TCP flags. [S] starts a connection, [P.] carries data, [F.] closes it, [R] resets it. A conversation full of [R] is usually a firewall saying no — that single observation has solved most of my debugging sessions.

Two commands will get you through most "it does not work" moments: first check the packet even leaves (tcpdump -ni any -c 5 host TARGET), then check whether a reply comes back (tcpdump -ni any 'tcp[tcpflags] & tcp-syn != 0'). Where it stops is where the problem is.