Mac Network Diagnostics: A Terminal Commands Cheat Sheet for a Broken Connection

A dead connection and a connection that only looks dead produce the same blank browser tab. The way through it is not to guess but to walk the stack from the machine outward, one command per layer, reading each result before moving up: is the Wi-Fi link associated, do you hold an IP, can you reach your own router, can you reach the internet by raw address, does a name resolve, and where does the path stop. The most common case, where Wi-Fi shows connected in the menu bar but nothing loads, is exactly the one this order pins down, because it forces the question of which check is the first to fail. Every command below is built into macOS and was run on 26.5.2; the ones that already have a dedicated guide are linked rather than repeated.

wdutil — read the Wi-Fi signal, channel, and link state

wdutil reports the state of the wireless link. sudo wdutil info dumps it in one shot, and the fields worth reading are SSID, RSSI and Noise (signal against background noise), Tx Rate, Channel, Security, and PHY Mode. An empty SSID, or a radio that reads as off, means the link never associated, and nothing further up the sequence will work until it does. For a deeper read of those fields — RSSI, Noise, and SNR, decoding the channel, and what the command can and can’t do — see the dedicated wdutil guide.

sudo wdutil info

One caveat before sharing that output: on 26.5.2 it auto-redacts MAC Address, SSID, and BSSID to <redacted>, but it still prints your IPv4/IPv6 addresses and DNS servers in clear, so those need removing by hand. If you reach for the old airport -I here out of habit, it is gone on 26.5.2 — the binary in its private framework no longer exists and which airport finds nothing, so wdutil is the current tool for this:

$ ls /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport
No such file or directory
$ which airport
airport not found

ifconfig and networksetup — show interfaces and your IP address

An associated radio with no address still gets you nothing. ifconfig en0 shows the Wi-Fi interface:

$ ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether <redacted>
	inet 10.x.y.z netmask 0xffffff00 broadcast 10.x.y.255
	inet6 <redacted> prefixlen 64 secured
	status: active
# hardware and IP addresses redacted; the fields and status line are untouched

The line that decides this step is inet. A normal private address (10.x, 192.168.x, or 172.16–31.x) with status: active means DHCP handed you a lease. An address that starts 169.254. is self-assigned: the radio associated but the router never answered DHCP, which is the quiet cause behind most “connected, but no internet” reports. No inet line at all means the interface never came up. networksetup -getinfo "Wi-Fi" prints the same IP, subnet, and router in a friendlier layout, and networksetup -setairportpower en0 off then on is a faster Wi-Fi bounce than clicking through System Settings. There is no ip command here — that one belongs to Linux — so ifconfig remains the tool.

ping — test reachability and packet loss

ping sends ICMP echoes and reports how many come back. It runs until Control-C on macOS, so bound it with -c. Two targets answer two different questions. Start with your own router, which separates the local network from everything beyond it — find its address, then ping it:

$ route -n get default | grep gateway
    gateway: <gateway>
$ ping -c 3 <gateway>
64 bytes from <gateway>: icmp_seq=0 ttl=64 time=4.741 ms
64 bytes from <gateway>: icmp_seq=1 ttl=64 time=4.733 ms
64 bytes from <gateway>: icmp_seq=2 ttl=64 time=5.002 ms

3 packets transmitted, 3 packets received, 0.0% packet loss
# gateway address redacted; timings untouched

Zero loss with low, steady times means the local network is fine and the fault is somewhere upstream; loss or no reply here points at Wi-Fi quality or the router itself, not your ISP. Then ping a raw public address, which skips DNS entirely and tells you whether the internet is reachable at all:

$ ping -c 3 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=0 ttl=115 time=118.791 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=119.664 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=144.090 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 118.791/127.515/144.090/11.726 ms

Read the 0.0% packet loss line first — a healthy link can still sit at a hundred milliseconds to a distant address, so loss matters more than the round-trip figure. If 8.8.8.8 answers but named sites won’t load, the connection is intact and DNS is the next place to look.

dig — resolve a name and check DNS

If raw addresses work but names don’t, DNS is the layer. dig +short gives just the answer; the full form shows the record:

$ dig +short apple.com
17.253.144.10
$ dig apple.com | grep -A1 'ANSWER SECTION'
;; ANSWER SECTION:
apple.com.		482	IN	A	17.253.144.10

The number before IN (here 482) is the record’s remaining TTL in seconds. An empty answer, or a timeout, while ping 8.8.8.8 still works, confirms the resolver rather than the connection. Aim dig at a public resolver to split the two apart:

$ dig @1.1.1.1 +short apple.com
17.253.144.10

If @1.1.1.1 answers but your default resolver doesn’t, the configured DNS server is the problem, not the network. If names instead resolve to addresses that are stale after a change you made, that is a cache issue rather than a lookup one, and clearing it is its own procedure — see the DNS cache guide.

traceroute — trace the path and find where it stops

When reachability is patchy rather than absent, traceroute shows which hop it degrades at. Its first surprise trips up almost everyone: the default probe on macOS is a UDP packet to a high port, and many routers don’t answer those, so a working path prints rows of asterisks:

$ traceroute -n apple.com
traceroute to apple.com (17.253.144.10), 64 hops max, 40 byte packets
 1  <first-hop>  5.007 ms
 2  *
 3  *
 4  *
# first-hop address redacted

Asterisks read like a dead network but usually mean the middle routers declined the UDP probe, not that traffic isn’t flowing. Changing the probe type is the next move. -I sends ICMP echo, the same thing ping uses; -P tcp sends TCP, which often draws a reply where UDP gets silence:

$ sudo traceroute -n -P tcp apple.com
traceroute to apple.com (17.253.144.10), 64 hops max, 40 byte packets
 1  <first-hop>  7.095 ms
 2  17.253.144.10  4.863 ms

Here TCP reached the destination at the second hop while both the UDP default and -I stopped at the first, which tells you the endpoint is reachable even though the hops between stay hidden. That hiding is the real lesson: behind a filtering gateway or a VPN, everything past the first hop can stay blank no matter which probe you pick, so asterisks describe how the intermediate routers treat probes, not proof your own traffic is failing.

When it’s slow, not broken (and the deeper guides)

A connection that works but feels slow is a different question from a broken one, and the rest of the built-in tools branch off from here rather than sit on the sequence above. For how responsive the link stays under load — Apple’s own RPM measurement, which a plain speed test won’t show — see the networkQuality guide. When a specific port is held or a local server won’t bind, lsof finds the process on it. The routing table this page only glanced at, the route and netstat -rn output, has its own route and netstat guide, including the Windows-versus-macOS split that catches people coming from route print. And clearing a stale resolver cache, the follow-on to the dig step, is in the DNS cache guide. The order above is for deciding whether the connection is broken at all, and if so, which layer to blame first.