Fixing Safari DNS Stalls via Cache and IP Tracking

Intermittent domain resolution stalls in Safari typically occur when the browser gets stuck translating a website's name into its numerical IP address, resulting in a frozen loading bar. This article provides a technical breakdown of how two specific troubleshooting steps—flushing the macOS DNS cache and toggling the "Limit IP Address Tracking" feature—directly resolve these bottlenecks by clearing corrupted local network data and resetting stalled privacy proxy connections.

The Role of the macOS DNS Cache

When you type a URL into Safari, macOS checks its local Domain Name System (DNS) cache before querying an external server. This cache stores recent domain-to-IP translations to speed up browsing. However, this local database can cause resolution stalls for several reasons:

  • Stale Records: A website may change its IP address before your local cache's Time-to-Live (TTL) timer expires, causing Safari to repeatedly attempt a connection to a dead server.
  • Network Switching: Moving between different Wi-Fi networks or disconnecting from a VPN can leave behind conflicting DNS routing information.
  • Daemon Glitches: The background process responsible for DNS on macOS, known as mDNSResponder, can occasionally experience memory leaks or state corruption, causing it to ignore new requests from Safari.

How Flushing the Cache Fixes It

Flushing the DNS cache forces macOS to wipe its temporary address book completely clean. When you run the terminal commands sudo dscacheutil -flushcache and sudo killall -HUP mDNSResponder, you accomplish two things:

  1. You delete all stored IP translations, eliminating any corrupted or outdated routing paths.
  2. You send a hang-up (HUP) signal to the mDNSResponder daemon, forcing it to restart cleanly and re-establish communication with your router's DNS servers.

The next time Safari requests a webpage, it bypasses the broken local data and fetches a fresh, working IP address directly from your configured DNS provider.

The Impact of "Limit IP Address Tracking"

"Limit IP Address Tracking" is a macOS network setting designed to hide your personal IP address from known trackers and protect your DNS queries. It uses an architecture similar to iCloud Private Relay, routing specific traffic and DNS lookups through encrypted proxies managed by Apple and its content delivery partners. While effective for privacy, this feature is a common culprit for Safari stalls due to the following mechanisms:

  • QUIC Protocol Blocks: The privacy relay relies heavily on the QUIC protocol (which uses UDP). Many local routers, corporate firewalls, and ISPs throttle or block UDP traffic. When this happens, Safari hangs while waiting for the blocked connection to time out before falling back to a standard connection.
  • Proxy Desynchronization: Your Mac maintains a secure tunnel to Apple's ingress proxies. If your local network drops briefly, this tunnel can enter a "zombie" state where macOS thinks it is connected, but the proxy is no longer responding to DNS requests.
  • Safari-Specific Routing: Because this feature is deeply integrated into WebKit (Safari's engine), Safari will stall when the relay fails, whereas third-party browsers like Chrome or Firefox—which do not use this specific Apple relay—will continue to work normally.

How Toggling the Setting Fixes It

Navigating to your Wi-Fi or Ethernet settings in macOS and toggling "Limit IP Address Tracking" off and back on (or leaving it off) resolves the stall by resetting the networkserviceproxy daemon.

  • Turning it off forces Safari to abandon the encrypted proxy tunnel entirely. DNS requests immediately revert to standard, unproxied channels via your local router, bypassing any QUIC blocks or congested Apple servers.
  • Turning it back on initiates a brand-new cryptographic handshake with Apple's relay servers. This tears down the unresponsive "zombie" tunnel and assigns your Mac a fresh, responsive proxy route, allowing Safari to resolve domains instantly again.