How to Use the macOS tcpdump Command to Analyze Network Traffic

The Need for Low-Level Network Analysis on macOS

When troubleshooting complex network issues on a Mac—such as failing API calls, unexpected connection drops, or suspected malicious traffic—high-level tools like the browser’s Network Inspector or Activity Monitor often lack the necessary detail. They show that a connection failed, but they don’t show the exact packets, flags, and sequence numbers being exchanged.

For deep, packet-level inspection, macOS administrators and developers must turn to tcpdump. Built into macOS natively, tcpdump utilizes the libpcap library to intercept and analyze raw network traffic traversing the system’s network interfaces.

Step 1: Identifying the Target Network Interface

Before capturing traffic, you must determine which physical or virtual network interface your Mac is using for the connection in question. Unlike Linux, where interfaces are typically named eth0 or wlan0, macOS uses the en prefix.

To list all available interfaces and their current IP addresses, use the ifconfig command:

ifconfig -u

The -u flag restricts the output to interfaces that are currently “Up”. Typically, en0 is the primary Wi-Fi interface, while en1 or en2 might represent a wired Ethernet adapter or a Thunderbolt bridge. For this guide, we will assume the active interface is en0.

Step 2: Executing a Basic Capture

Because tcpdump puts the network interface into promiscuous mode (allowing it to see all traffic, not just traffic destined for its own MAC address), it requires root privileges.

To start a basic capture on en0, open the Terminal and run:

sudo tcpdump -i en0

Your screen will immediately flood with packet data. To stop the capture, press Ctrl+C. This raw output is generally too fast and noisy to be useful, which is why filtering is critical.

Step 3: Utilizing Berkeley Packet Filter (BPF) Syntax

tcpdump relies on Berkeley Packet Filter (BPF) expressions to selectively capture only the traffic you care about. This drastically reduces the CPU load and makes the output human-readable.

Filtering by Host

If you are debugging a connection to a specific remote server (e.g., an API endpoint at 93.184.216.34), you can filter by that host:

sudo tcpdump -i en0 host 93.184.216.34

Filtering by Port and Protocol

To monitor all incoming and outgoing HTTPS traffic on port 443:

sudo tcpdump -i en0 tcp port 443

You can combine conditions using logical operators (and, or, not). For example, to capture all web traffic (HTTP and HTTPS) originating from a specific host:

sudo tcpdump -i en0 src host 192.168.1.50 and \(tcp port 80 or tcp port 443\)

Note: The parentheses must be escaped with backslashes in the bash/zsh shell to prevent them from being interpreted as a subshell.

Step 4: Inspecting Packet Contents (Hex and ASCII)

By default, tcpdump only displays the packet headers (Source IP, Destination IP, TCP Flags, Sequence numbers). To debug application-layer protocols (like unencrypted HTTP or DNS), you need to see the actual payload.

Use the -X flag to print the contents of each packet in both Hexadecimal and ASCII formats:

sudo tcpdump -i en0 -X udp port 53

This command is exceptionally useful for viewing raw DNS queries and responses in plaintext.

Step 5: Writing Captures to a PCAP File

For prolonged troubleshooting or complex analysis, reading packets as they scroll by in the Terminal is impossible. Instead, you should save the capture to a file and analyze it later using a graphical tool like Wireshark.

Use the -w (write) flag to output the raw packets to a .pcap file:

sudo tcpdump -i en0 -w ~/Desktop/network_capture.pcap tcp port 443

When running in write mode, tcpdump will not print packets to the screen. It will run silently until you press Ctrl+C. You can then open the resulting network_capture.pcap file in Wireshark for deep, visual protocol dissection.

Conclusion

Mastering tcpdump on macOS provides developers and system administrators with absolute visibility into the network stack. By leveraging BPF syntax to filter out noise, capturing raw payloads, and exporting data to PCAP files, you can definitively prove whether a network failure is caused by a local application bug, an aggressive firewall, or a remote server drop.