Wi-Fi connected, but no internet: diagnose the path

This focuses on a connected Wi-Fi indicator with websites that will not load, with branches for missing adapters and authentication failures. For first-time connection, see the Wi-Fi guide. The goal here is locating the failing stage rather than trying every fix.

Interface names, network names, and outputs are teaching examples. Replace wlp2s0 and gateway addresses with your own results. These checks have not been run on your network.

1. What happens between connecting and opening a website?

System recognizes the adapter
  → Radio enabled; access point discovered
  → Wireless authentication succeeds
  → Address, routes, and DNS settings obtained
  → Routes carry traffic; name lookup finds servers
  → Browser connects and completes website or guest-network authentication

NetworkManager manages connections and their settings; the bar and nmtui are controls. Drivers expose the adapter, DNS resolves names, and routes select where traffic goes. DNS itself needs connectivity: this is a diagnostic outline, not a strict software call graph. Component responsibilities

Connected does not guarantee that every website works. Browsers also have proxies, DNS settings, extensions, and permissions; wireless association may be fine.

2. Make comparisons and preserve the starting state

Record the network, start time, exact browser error, and whether this followed suspend, an update, docking, or enabling a VPN.

Comparison	What it helps establish
Another website on this computer	One failing website suggests a site or app issue first
Another browser	Failure in only one suggests its settings
Another device on the same network	Several failing devices make network-side causes worth investigating
This computer on a phone hotspot	Success proves it works under at least one set of conditions; band, authentication, and driver compatibility differences remain possible

Save outputs before reconnecting or restarting hardware. That distinguishes a symptom disappearing from its cause being confirmed.

3. Is the adapter present and unblocked?

These query state without changing connection settings:

nmcli device status
nmcli radio wifi
rfkill list

Abbreviated teaching output:

DEVICE    TYPE      STATE         CONNECTION
wlp2s0    wifi      connected     Home-WiFi
enp3s0    ethernet  disconnected  --

wlp2s0 is the device name; Home-WiFi is the connection profile name. Device queries below need the former.

Result	Next step
Wi-Fi device connected	Inspect addresses and routes
Device disconnected	Connect through the panel or nmtui; record authentication errors
unavailable or unmanaged	Inspect radio blocks, service, and management state; do not immediately install another manager
No Wi-Fi row	Investigate adapter detection and service; changing DNS cannot reveal missing hardware
Soft blocked: yes	Check software airplane mode or radio controls
Hard blocked: yes	Check hardware switch, firmware, or platform state; software may not clear it

Query the service:

systemctl status NetworkManager --no-pager

active (running) proves only that the service runs. An inactive service, unmanaged device, and missing driver are different problems. This source uses NetworkManager; older iwd instructions are not automatically applicable. Installation source

4. Connected: did you get a usable address?

Replace the device name:

nmcli -f GENERAL,IP4,IP6 device show wlp2s0

Simplified example:

GENERAL.DEVICE:       wlp2s0
GENERAL.STATE:        100 (connected)
IP4.ADDRESS[1]:       192.168.50.23/24
IP4.GATEWAY:          192.168.50.1
IP4.DNS[1]:           192.168.50.1

Field	Meaning	Does not prove
ADDRESS	Your address on this network; /24 is the prefix length	Internet access
GATEWAY	Next hop for other networks	That the gateway itself can reach the internet
DNS	Name servers reported for this connection	That they answer or every app uses them

On an ordinary home IPv4 DHCP network, missing addresses or the expected gateway calls for checking address assignment and profile settings. A lone 169.254.x.x address does not establish ordinary internet connectivity; compare the network requirements and another device.

Missing IPv4 is not always a fault: some networks use IPv6. Inspect IP6 and IPv6 routes rather than treating an IPv4 probe as a complete test.

5. Where does traffic actually go?

ip route
ip -6 route
ip route get 1.1.1.1

The first two display routes. The last asks the local system how it would route to an IPv4 destination, without sending a probe there. An example:

1.1.1.1 via 192.168.50.1 dev wlp2s0 src 192.168.50.23

via is the next hop, dev the interface, and src the chosen local address. A VPN interface means not every outside-network failure should be blamed on Wi-Fi. Policy routing and multiple interfaces can make the main table alone insufficient. Route query reference

Optionally probe your actual gateway and an outside IPv4 address:

ping -c 3 192.168.50.1
ping -c 3 1.1.1.1

The first address belongs only to the example: substitute your gateway. These send up to three probes each.

Result	Reasonable interpretation
Both respond	Those IP probe paths work; investigate name resolution and applications
Gateway responds, outside address does not	Investigate uplink, VPN, or policy; the target may also reject ICMP
Neither responds	Inspect local connection, routes, and probe restrictions; timeout alone does not prove a broken driver

Successful ping does not prove HTTPS works. Failed ping does not prove all internet access is down. Combine it with real websites and another device’s results.

6. Name resolution or browser behavior?

Query a domain through the system’s name-resolution path:

getent ahosts omarchy.org

Returned addresses show this lookup obtained a result. It may come from cache or another name source; this does not isolate one DNS server. No result may also reflect failed network requests. Browser secure DNS or proxies can behave differently. getent reference

Combination	Next investigation
Outside IP probes work, several system name lookups fail	DNS or the system resolver path
System lookup works, only one browser fails	Proxy, secure DNS, extensions, exact browser error
Only one domain fails	Compare other domains before changing system-wide DNS
Certificate date error	Check system time and error; DNS does not explain every TLS failure

Omarchy provides Setup → Network → DNS. If evidence justifies testing another provider, record the original provider and custom values, change only that setting, and repeat the same lookup and website test. Without improvement, restore the original settings through the same entry point, including an original automatic/DHCP policy. Resetting is not the same as restoring your earlier custom values. Official networking

7. Guest-network and authentication branches

Ask for NetworkManager’s connectivity assessment:

nmcli networking connectivity check

This triggers a connectivity probe without changing the connection configuration. portal indicates detected guest authentication, limited means the probe did not establish full connectivity, and unknown can mean probing is not configured or cannot decide. full is not a promise that every website works. nmcli definitions

Use the hotel’s or guest network’s provided login entry point. If no page appears, try an ordinary HTTP detection page supplied by the network operator. Do not bypass certificate warnings to complete login.

If association never succeeds and passwords keep being requested, confirm SSID, keyboard layout, password, and network type. Enterprise or campus 802.1X may need an identity and certificate settings from its administrator, not just a Wi-Fi password.

8. When to restart, and what counts as success

For a connection that worked recently and failed after suspend or unplugging hardware, record state then try the official Update → Hardware → Wi-Fi entry. It interrupts connections; finish network transfers first. Repeat the same failed check and website test afterward.

Inspect logs near the failure:

journalctl -b -u NetworkManager --since "10 minutes ago" --no-pager

Insufficient permissions may hide logs; empty output is not proof of no errors. Keep device state, timing, network type, and hotspot comparisons. Inspect names, addresses, and identities before sharing publicly.

Success means association works, the websites you need load, experiment settings are restored, and reconnecting still works. If the adapter disappears only after suspend, continue with sleep diagnosis. Do not experiment by disabling the firewall, enabling a second manager, or changing DNS and drivers together.

Sources and scope

Reviewed on 2026-10-12: Omarchy networking, hardware troubleshooting, nmcli, route queries, and getent. Examples target NetworkManager and contain illustrative data. VPNs, enterprise authentication, and IPv6 require interpretation of the actual network policy.