Mac

Mac connected to Wi-Fi but no internet

Mac shows Wi-Fi but pages or apps fail? Separate DNS and routing faults from an app-specific VPN or content-filter problem, then test the matching fix.

Start here: Classify the failure

Run the two pings (raw IP, then a name).

Problem summary

A Wi-Fi icon only proves the Mac joined the access point. First compare a raw-IP ping with a hostname ping to separate routing from DNS. If Safari works but Firefox, Dropbox, Telegram, a VPN, or another app does not, the connection may be app-specific: check the app, a VPN, security software, and a second network before changing router or DNS settings. macOS 27 beta users reported that pattern, but a public-release regression has not been verified.

Operator snapshotEvidence first

First proof

Run `ping -c3 1.1.1.1` then `ping -c3 apple.com`.

Screen to open

ping -c3 1.1.1.1 ; ping -c3 apple.com

Expected signal

Both reply = routing + DNS work (suspect portal/clock); IP-only = DNS; neither = routing/DHCP.

Stop boundary

Entering credentials on a captive portal you can't verify is genuine.

Layer path

1'Connected, no internet' means the Wi-Fi radio link is up but a higher layer is broken. The layers, from the Mac outward: DHCP (do you have a real IP?), routing (can you reach the gateway and beyond?), DNS (can names resolve to IPs?), captive portals (is sign-in blocking you?), and TLS/clock (do HTTPS certificates validate?). The fix depends entirely on which layer fails.

2Two pings classify most of it instantly: pinging a raw IP (1.1.1.1) tests routing without DNS; pinging a name (apple.com) tests DNS on top of routing. IP-works/name-fails = DNS; both fail = routing/DHCP; both work but browsers fail = captive portal or clock. This turns a vague symptom into a decision.

3The non-obvious traps are the captive portal that never popped (often because custom DNS prevents the redirect) and a wrong system clock that makes every HTTPS certificate look invalid — so Terminal/ping work but secure sites fail. Both look like 'no internet' and neither is a Wi-Fi problem.

4If Safari succeeds but another app fails, a Mac-wide DNS or routing failure is less likely. Apple recommends checking VPN and third-party firewall, antivirus, parental-control, and content-filter software. Reports of this symptom on macOS 27 betas do not prove it affects the public release.

Runbook

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.

Isolate one failing app

Check: If Safari works but another app fails, record its error, compare a second network, and test any optional VPN or filter from its own controls.

Expected result: The result identifies whether the failure follows the app, network, or filter.

If not: Restore the filter after the test and ask an administrator before changing managed settings.

Did this solve your problem?

Your answer helps us improve this page.

No account or personal details. We store the page, answer, optional reason and day with a 90-day retention period. A random reference in this browser prevents repeat votes. Feedback privacy

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.

If: Safari works but Firefox, Dropbox, Telegram, or another app cannot connect.

Then: App-specific path, proxy, VPN, or security filter may be involved; a macOS 27 public-build bug is unverified.

Action: Compare another network, inspect the app's error, and briefly turn off an optional filter in its own app before restoring it. Ask an administrator on managed Macs.

Evidence

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).
Safari works; one other app times out.	Same destination in Safari and the app, app error, VPN/filter status, and a second-network test.	App configuration or third-party network filter.	Test the optional filter in its own app, restore it, then contact the app/vendor if still failing.

Reference

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 boundary

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.

Last reviewed

2026-09-18 · Reviewed by HomeTechOps. Rechecked 2026-09-18 against Apple's Wi-Fi, internet, and VPN/security-software guidance. Added an app-specific branch for Safari-working cases without claiming that beta reports prove a public macOS 27 regression.

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.
Safari-working/other-app-failing reports on macOS 27 were from beta builds and do not establish a regression in the public 27.0 release (checked 2026-09-18).

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.

Apple Support: If your Mac isn't connecting to the internet over Wi-FiUsed for Apple's supported Wi-Fi troubleshooting sequence — checking the connection, renewing the DHCP lease, and removing/re-adding the network — before any deeper reset.Apple Support: Solve internet connection problems on MacUsed for the built-in Network settings diagnostics, renewing DHCP, and the order Apple recommends for isolating a Mac-side vs router-side networking fault.Apple Support: Recommended settings for Wi-Fi routers and access pointsUsed for router security, band, naming, and access-point settings that affect mixed home devices.Apple Support: Check VPN and third-party security software for network issuesUsed for the app-specific VPN, firewall, antivirus, parental-control, and content-filter checks when one Mac app cannot connect.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Avoid unsafe electrical or data-loss steps.
4. Stop when the evidence says the risk moved.

FAQ

My Mac is connected to Wi-Fi but has no internet — how do I fix it?

First classify the failure: run `ping -c3 1.1.1.1` (an IP) and `ping -c3 apple.com` (a name). If the IP works but the name fails, it's DNS — flush it with `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` or set DNS to 1.1.1.1. If both fail, it's routing/DHCP — check for a 169.254 address and renew the lease. If both work but the browser doesn't, suspect a captive portal or a wrong clock.

Why does ping work but websites won't load on my Mac?

Two common causes. A captive portal (hotel/café Wi-Fi) hasn't shown its sign-in page — open `http://captive.apple.com` to force it. Or your system clock is wrong, which makes HTTPS certificates fail validation, so secure sites break while ping (which doesn't use TLS) still works. Check Date & Time is correct and automatic.

What does a 169.254 IP address mean?

It's a self-assigned link-local address the Mac uses when DHCP fails to give it a real IP — so it's 'connected' with no route to the internet. Renew the DHCP lease (Network → Wi-Fi → Details → TCP/IP), and if it keeps happening, reboot the router and make sure its DHCP pool isn't exhausted.

Should I change my DNS to fix no internet?

If the ping test shows names fail but IPs work, yes — flush the DNS cache first, and if that doesn't help set a known-good resolver (1.1.1.1 and 8.8.8.8) in Network → Wi-Fi → Details → DNS. If both ping tests fail, DNS isn't your problem; it's DHCP or routing.

Why does Safari work but another Mac app have no internet on macOS 27?

First try the same app on another network, then check its error and any VPN, firewall, antivirus, or content filter. Apple documents that these tools can affect network connections; temporarily turn off an optional filter in its own app and restore it after the test. Ask an administrator before changing a managed profile. Similar reports occurred on macOS 27 betas, but a public-build bug has not been established.

Get the deal & firmware alerts

Home Stack Field Notes: NAS deals, firmware changes worth acting on, restore-test reminders, and new decision guides — plus the capacity & backup sizing cheatsheets from our calculators. Unsubscribe anytime.

Subscribe on beehiiv

Problem summary

Layer path

Step-by-step runbook

Classify the failure

Fix the address layer

Fix DNS

Clear portal/clock traps

Test IPv6 last

Isolate one failing app

Did this solve your problem?

Decision tree

Evidence table

Commands and settings paths

Classify DNS vs routing

Flush the DNS cache

See which resolver the Mac is using

Confirm the default route / gateway

Hardware and platform boundary

Change only when

Evidence that matters

Evidence that does not matter

Avoid

Related problems

Last reviewed

Sources/assumptions

Source-backed checks

Get the deal & firmware alerts