Mac
Mac connected to Wi-Fi but no internet
Fix a Mac that shows full Wi-Fi but won't load anything — isolate DNS vs routing with ping, flush DNS, renew DHCP, handle IPv6 and captive portals, and the wrong-clock TLS trap that blocks HTTPS.
Problem summary
I'm here because my Mac says it's connected to Wi-Fi — full bars — but nothing loads: web pages time out, or some apps work and the browser doesn't. The Wi-Fi radio is fine here; the break is one layer up, in DNS, DHCP, IPv6, a captive portal, or even the Mac's clock. This page isolates exactly which layer is failing with a couple of `ping` tests, then gives the precise fix for each — so you're not blindly toggling Wi-Fi off and on.
Run `ping -c3 1.1.1.1` then `ping -c3 apple.com`.
ping -c3 1.1.1.1 ; ping -c3 apple.com
Both reply = routing + DNS work (suspect portal/clock); IP-only = DNS; neither = routing/DHCP.
Entering credentials on a captive portal you can't verify is genuine.
Layer path
Step-by-step runbook
Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.
Classify the failure
Check: Run the two pings (raw IP, then a name).
Expected result: You know whether it's DNS, routing/DHCP, or portal/clock.
If not: Pick the matching branch instead of toggling Wi-Fi.
Fix the address layer
Check: Confirm a real IP; renew DHCP if it's 169.254.
Expected result: The Mac has a valid address and route.
If not: If 169.254 persists, it's a router DHCP problem.
Fix DNS
Check: Flush the cache; set 1.1.1.1/8.8.8.8 if names still fail.
Expected result: Name resolution works and pages load.
If not: Check `scutil --dns` for a VPN/profile hijacking DNS if it doesn't.
Clear portal/clock traps
Check: Force `http://captive.apple.com`; verify Date & Time is correct.
Expected result: A stuck portal or a TLS-breaking clock is resolved.
If not: Clear custom DNS temporarily if the portal won't redirect.
Test IPv6 last
Check: If only some sites fail, set IPv6 = Link-local only and re-test.
Expected result: Half-configured network IPv6 is ruled in or out.
If not: Revert to Automatic afterward so IPv6 services keep working.
Decision tree
If: `ping 1.1.1.1` works but `ping apple.com` fails.
Then: DNS resolution is broken (stale cache or bad resolver).
Action: Flush DNS (`sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`); if still failing, set 1.1.1.1/8.8.8.8.
If: Both pings fail and the IP is 169.254.x.x.
Then: DHCP failed — no real address or route.
Action: Renew the lease; reboot the router; check the DHCP pool/reservation.
If: Both pings fail but the IP looks normal.
Then: Routing/gateway problem upstream of the Mac.
Action: Check `netstat -nr | grep default` and ping the gateway; if unreachable, it's the router/network.
If: Both pings work but browsers don't load anything (public Wi-Fi).
Then: A captive portal that never presented its sign-in page.
Action: Open `http://captive.apple.com`; clear custom DNS if the portal needs its own resolver.
If: Both pings work but only HTTPS sites fail.
Then: A wrong system clock invalidating TLS certificates.
Action: Set Date & Time correctly (and automatic); HTTPS validates again.
Evidence table
| Symptom | Evidence to collect | Likely layer | Next action |
|---|---|---|---|
| Pages time out; some apps work. | `ping 1.1.1.1` ok, `ping apple.com` fails. | DNS. | Flush DNS; set 1.1.1.1/8.8.8.8 if needed. |
| Nothing connects at all. | IPv4 is 169.254.x.x. | DHCP failure. | Renew lease; reboot router; check DHCP pool. |
| No internet; IP is valid; gateway unreachable. | `ping <gateway>` fails; `netstat -nr` shows a default route. | Routing/gateway/local network. | Reboot router; check cabling/uplink; treat as router-side. |
| Public Wi-Fi; both pings work; no pages. | No captive sign-in sheet appeared. | Captive portal not triggered. | Open `http://captive.apple.com`; clear custom DNS to allow redirect. |
| Ping works; HTTPS sites fail with cert errors. | Date & Time is wrong. | Clock/TLS validation. | Correct the clock (manual then automatic). |
Commands and settings paths
Classify DNS vs routing
ping -c3 1.1.1.1 ; ping -c3 apple.com
Where: Terminal on the Mac.
Expected: IP reply + name reply = both layers fine; IP-only = DNS; neither = routing/DHCP.
Failure means: The result tells you which fix to apply.
Safe next step: Branch to DNS, DHCP/routing, or portal/clock accordingly.
Flush the DNS cache
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Where: Terminal on the Mac (admin password required).
Expected: Clears stale/poisoned DNS entries; name resolution recovers.
Failure means: If names still fail, the resolver itself is bad.
Safe next step: Set 1.1.1.1/8.8.8.8 via DNS settings or `networksetup`.
See which resolver the Mac is using
scutil --dns
Where: Terminal on the Mac.
Expected: Lists DNS servers per interface — catches a VPN or profile overriding DNS.
Failure means: An unexpected resolver means something (VPN/profile) is intercepting DNS.
Safe next step: Disable the VPN/profile or set DNS explicitly to test.
Confirm the default route / gateway
netstat -nr | grep default
Where: Terminal on the Mac.
Expected: Shows the default gateway; you can then `ping` it to test local reachability.
Failure means: If the gateway is unreachable, the fault is the router/local network, not the Mac.
Safe next step: Reboot the router and verify the uplink before more Mac-side steps.
Hardware and platform boundary
Change only when
- Set a reliable DNS resolver (1.1.1.1 / 8.8.8.8, or a Pi-hole/AdGuard you run) network-wide on the router if DNS flakiness recurs across devices.
- Replace a router whose DHCP server repeatedly fails to lease addresses — chronic 169.254 results across devices is a router problem worth fixing at the source.
Evidence that matters
- A router with a healthy, correctly sized DHCP pool and working IPv6 (or cleanly disabled IPv6).
- A correct, automatically synced system clock so HTTPS validates.
- A known-good DNS resolver you can fall back to when the ISP's DNS misbehaves.
Evidence that does not matter
- Raw internet speed — bandwidth is irrelevant when DNS or routing is the failure.
- The Wi-Fi signal strength — the link is already up; this is a higher-layer problem.
- A new Wi-Fi adapter or mesh node — it won't fix DNS, DHCP, a portal, or the clock.
Avoid
- Entering credentials on a captive portal you can't verify is genuine.
- Leaving IPv6 forced to Link-local only permanently — it breaks IPv6-only services.
- Hard-coding DNS on the Mac and forgetting it when you move networks that need their own resolver.
Related tool/checklist
Use the linked tool when you need a guided plan from your exact symptoms instead of a static checklist.
NAS setup plannerRelated problems
Last reviewed
2026-06-02 · Reviewed by HomeTechOps. Reviewed against Apple's Wi-Fi connectivity and internet-troubleshooting guidance; built around the two-ping classification (raw IP vs name) to separate DNS, DHCP/routing, captive-portal, and clock/TLS failures, and is explicit that 'connected, no internet' is a higher-layer fault, not a Wi-Fi radio drop.
Sources/assumptions
- Assumes a Mac (including macOS Tahoe / macOS 26) that is associated to Wi-Fi but has no working internet; the Wi-Fi radio link itself is treated as up.
- Commands (`ping`, `dscacheutil`, `scutil --dns`, `networksetup`) follow Apple's documented behaviour; some require an admin password.
- Captive-portal and IPv6 behaviour vary by network; the steps isolate the failing layer rather than assuming a single cause.
Source-backed checks
HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.