macOS networking from the command line

two macOS behaviours make a working network look broken to a command-line tool, and both are invisible to the usual checks from a terminal.

the resolver remembers a miss

after creating a record for a hostname that was queried before it existed, macOS's resolver keeps the negative answer: dig @1.1.1.1 shows the record while curl says "could not resolve host" and a browser agrees, because dig asks the server directly and the others go through the system resolver. dscacheutil -flushcache is not enough; sudo killall -HUP mDNSResponder is, or wait out the negative TTL. chromium can bypass the resolver for one test with --host-resolver-rules="MAP example.com 1.2.3.4".

local network privacy follows the launching app

"no route to host" to a LAN address while ping and TCP succeed from a terminal is macOS Local Network privacy, not the network. a process gets the permission of the app that launched it, so everything under a tmux server started by an app without the grant fails with EHOSTUNREACH for LAN addresses: the same Python TLS call to a Hue bridge failed inside tmux and succeeded from a permitted shell. restarting a long-lived daemon (an ADB server) from a permitted shell appears to fix it for the same reason. controllers on a Linux host on the LAN avoid the check.

related

• exposure — what the macOS application firewall does and does not block
• fly-custom-domains
• smart-home-control

sources

• new apex and wildcard records under a cloudflare zone, checked from macOS, 2026-09-17/18
• Hue bridge and Fire TV ADB control from tmux and from a permitted shell, smart-home control plane work, 2026-09