Trace route, DNS, and path

“The internet is broken” is five different failures wearing the same coat. Test the path in layers. First inspect DNS configuration and answers, then the selected route, then the destination port, then the application protocol. Each command below answers exactly one question, and the first one that fails names your problem.

Walk the layers

Which resolver is the Mac actually using?

scutil --dns | head -15

Read resolver #1 and its nameserver[0] entries. This is the ground truth, whatever you think you configured.

Does the name resolve?

dig example.org

Check status: NOERROR in the header and the ANSWER SECTION for the returned address. NXDOMAIN means the name itself fails; an unexpected IP means you are being answered by the wrong resolver.

Where does traffic leave the machine?

route -n get default

Read gateway and interface. Traffic going out en0 when you expected the VPN’s utun interface explains a lot of “works off VPN, fails on VPN” cases.

Can we reach the port?

nc -vz example.org 443
# Connection to example.org port 443 [tcp/https] succeeded!

That succeeded! line proves DNS, routing, and the TCP handshake all work. A timeout here with working DNS points at a firewall or a dead host.

Does the application layer answer?

curl -v https://example.org/

-v shows the TLS handshake, the certificate, and the HTTP status. A certificate name mismatch or an HTTP 503 lives here, above everything you tested before.

Stop at the first failing boundary

Fix where the failure is, not where habit points. Changing DNS cannot fix a local listener, and flushing caches cannot repair a TLS name mismatch. If dig succeeds and nc succeeds, stop touching DNS.

One more distinction: networkQuality measures capacity and responsiveness of the connection. Useful when everything works but feels slow — a different investigation than the layered reachability walk above.