{{img:hero}}When a site won’t load in Safari, the hardest part is often the wording: DNS, TLS, timeouts, 404, 502, “connection reset.” This one-page cheat sheet translates the most common networking terms into plain English and points you toward the next sensible check.

Keep it nearby the next time “it’s just spinning.”

How to use this sheet: Find the term you see (error page, DevTools, a help desk message), read the “means” line, then do one small check from the “try” line.

In Safari on Mac, you can open the Web Inspector (for network errors) via Safari → Settings → Advanced → Show features for web developers, then use Develop → Show Web Inspector.

Quick map: where the problem can be

{{img:map}}Most web requests fail in a few predictable layers. Knowing the layer keeps you from guessing.

  • DNS: turning a name (example.com) into an IP address.
  • Connection: opening a path to that IP (routing/firewall).
  • TLS: the security handshake (certificates/encryption).
  • HTTP: the actual request/response (status codes, headers).
  • App/server: the site’s code and upstream dependencies (502/503/504, slow pages).

Speed metrics (what they actually say)

These aren’t just “performance numbers.” They usually point to where the delay is.

  • Latency (ms): how long a round trip takes between you and a server. High latency often feels like “everything is slow,” even if download speed is fine. Try: switch networks (Wi‑Fi to hotspot) to separate “your network path” from “the site.”
  • Jitter: how much latency varies from moment to moment. High jitter causes stuttery calls and “sometimes fast, sometimes stuck.” Try: move closer to Wi‑Fi, or test on wired/Ethernet if you can.
  • Packet loss (%): some data never arrives and must be resent. Even 1–2% can cause visible stalls. Try: restart the router, or test a different network to confirm it’s not just the site.
  • Bandwidth (Mbps): how much data per second can move. Low bandwidth shows up as “downloads crawl” more than “pages won’t open.” Try: pause other big uploads/downloads and retest.
  • Throughput: real-world achieved speed after overhead and conditions. If bandwidth is “good” but throughput is “bad,” congestion or packet loss is often involved.

DNS terms (name lookup problems)

{{img:dns}}DNS issues often look like “Safari can’t find the server” even though your internet is fine.

  • DNS / Resolver: the service that answers “what IP is this name?” (often your router/ISP, or a public resolver). Try: test the same site in another network; if it works there, your current DNS path is suspect.
  • DNS cache: saved lookups so your computer doesn’t ask every time. Try: if only one site is broken and others work, wait a few minutes or try another network before nuking everything.
  • TTL (time to live): how long a DNS answer is considered valid. Low TTL changes propagate faster; high TTL means old answers linger longer. Try: if a site just changed hosting, “it works for some people but not me” can be TTL-related—time often fixes it.
  • NXDOMAIN: DNS is saying “that name does not exist.” Usually a typo or a domain/config issue on the site owner’s side. Try: double-check the URL; if correct, it’s rarely a Safari problem.
  • DNS timeout: your computer asked DNS, but no answer arrived in time. Try: switch networks; if that fixes it, your DNS resolver/router/ISP path is likely flaky.

Connection + timeout terms (path problems)

These terms are about reaching the server at all, before the website even has a chance to respond.

  • Timeout: “I waited, nothing came back.” Could be DNS, connection, TLS, or the server. Try: check whether other sites load instantly; if yes, it’s probably specific to that site or route.
  • Connection refused: you reached the machine, but the port/app said “no.” Often a server configuration/firewall or a service that’s down. Try: retry later; not usually fixed by clearing browser data.
  • Connection reset: the connection was established, then abruptly closed. Can happen with flaky networks, aggressive firewalls, proxies, or a crashing server. Try: try another network or disable VPN/proxy to see if it’s path-related.
  • Proxy/VPN: an intermediate hop that can block, rewrite, or slow traffic. Try: temporarily turn it off and reload to isolate whether it’s the middlebox.
  • Firewall: rules that allow/deny traffic. If a site works on mobile data but not on your Wi‑Fi, it can be a local firewall/router rule. Try: test one device on the same Wi‑Fi vs hotspot.

TLS/HTTPS terms (security handshake problems)

{{img:tls}}TLS errors can feel scary, but most are either “wrong time,” “intercepting proxy,” or “certificate mismatch.”

  • TLS handshake: the negotiation that sets up an encrypted HTTPS connection. If it fails, the page may not load at all. Try: check system date/time; a bad clock breaks certificates fast.
  • Certificate: proof the site is who it claims to be. Try: if Safari warns you, don’t bypass casually—test on another network/device to see if it’s specific to your environment.
  • Certificate expired / not yet valid: often caused by incorrect Mac date/time, or a genuinely expired cert on the site. Try: fix date/time first; if correct, it’s likely on the site owner.
  • Name mismatch: the certificate doesn’t match the domain you’re visiting (wrong host, captive portal, or interception). Try: confirm you’re on the right domain; if on public Wi‑Fi, sign in to the captive portal first.
  • HSTS: a rule that forces HTTPS and prevents click-through on certain certificate errors. Meaning: Safari is intentionally strict for safety. Try: assume the network or site is misconfigured rather than trying to override it.

HTTP status codes (who’s “at fault”)

These come from the server (or a server in the middle). They’re often the clearest signal you’ll get.

  • 200 OK: the server says it worked. If the page still looks wrong, it’s likely content, caching, or JavaScript rather than “network down.”
  • 301/302 redirect: you’re being sent somewhere else. Too many redirects can mean a cookie/auth issue. Try: private window test to see if it’s session-related.
  • 304 Not Modified: “use your cached copy.” Not an error. If the cached copy is bad (rare), you may need a hard refresh or cache clear for that site.
  • 401 Unauthorized: you’re not authenticated (or credentials missing/expired). Try: sign in again; check if a VPN/proxy is stripping auth headers.
  • 403 Forbidden: the server understood you but won’t allow it (permissions, geo/IP blocks, WAF rules). Try: test off VPN; if it works, your IP/path may be flagged.
  • 404 Not Found: the server is up, but the specific URL doesn’t exist. Try: navigate from the homepage; don’t troubleshoot your network.
  • 429 Too Many Requests: you’re rate-limited. Try: wait, reduce automated refreshes, or sign in (some sites rate-limit anonymous traffic more aggressively).
  • 500 Internal Server Error: the server crashed or misbehaved. Try: nothing local usually fixes this; retry later or contact the site.
  • 502 Bad Gateway: a gateway/proxy couldn’t get a good response from an upstream server. Try: if it happens intermittently, it’s often a server-side dependency issue.
  • 503 Service Unavailable: server overloaded or in maintenance. Try: wait; if you manage the service, check capacity/health.
  • 504 Gateway Timeout: an upstream server took too long. Try: if it’s only on big pages/actions, the server is slow under load more than “your internet is broken.”

One-minute checklist (fast isolation)

When you’re stuck, don’t do ten things. Do three checks that separate “me” vs “network” vs “site.”

  • Try the same URL on a different network (hotspot is enough).
  • Try a Private Window (rules out cookie/session oddities and some extensions).
  • Temporarily disable VPN/proxy (rules out interception/routing issues).
  • Check Mac date/time if you see certificate/TLS warnings.
  • Note the exact status code (404 vs 503 changes the next step completely).

Takeaway: translate the term into a layer, then do one test

If you can label the problem as DNS, connection, TLS, or HTTP, you’re already 80% of the way to a calm next step. In Safari on Mac, a quick network switch + Private Window + VPN-off test usually tells you whether to keep debugging locally or wait for the site to recover.