Linux Connected to Wi-Fi but No Internet? Try These Fixes

If your taskbar shows full Wi-Fi bars, your laptop says “connected,” and yet every website times out, you already know how frustrating this is. Linux connected to Wi-Fi but no internet is one of the most common headaches new Linux users run into, and honestly, even people who’ve run Linux for years still hit it after a kernel update or a router firmware change.

I ran into this myself a few months back on a Dell laptop with a Realtek RTL8821CE card — Wi-Fi showed “connected,” the signal bars were full, and yet nothing loaded. It turned out the firmware hadn’t loaded properly after a kernel update, and dmesg showed the exact error within seconds of looking. That’s the thing about this problem: it feels mysterious the first time, but it’s almost always traceable to one of five specific layers once you know where to check.

The good news: this problem almost always comes down to one of five things — DNS, IP assignment, drivers, routing, or a firewall rule getting in the way. In this guide I’ll walk through exactly how to diagnose which one it is, with commands you can copy-paste, sample outputs so you know what “broken” actually looks like versus “working,” across Ubuntu, Fedora, Debian, Linux Mint, Arch, and openSUSE.

Why Your Linux Machine Connects to Wi-Fi But Shows No Internet

“Connected” only means your device successfully authenticated with the router and got assigned to the network. It says nothing about whether traffic can actually leave that network and reach the wider internet. Those are two completely separate layers, and Linux (unlike Windows, which bundles a lot of this into one opaque “Network diagnostics” wizard) exposes each layer separately — which is actually a good thing once you know where to look.

In practice, the “connected but no internet” state on Linux breaks down into a handful of root causes:

• DNS resolution is broken — your machine can reach IP addresses directly but can’t turn “google.com” into one
• No valid IP address or gateway was assigned — a DHCP hiccup left you with a self-assigned 169.254.x.x address
• The Wi-Fi driver or firmware is flaky — common with Realtek and some Broadcom chips on newer kernels
• A firewall or VPN client is silently dropping traffic
• The router itself has no WAN connection, but still happily hands out local IPs
• A captive portal (hotel Wi-Fi, airport Wi-Fi, office guest network) is blocking you until you log in through a browser

Let’s go through the checks in the order that actually finds the problem fastest, rather than the order most forums list them in.

Step 1: Confirm It’s Not Just Your Router

Before touching your Linux config, rule out the simplest explanation. Grab your phone, connect to the same Wi-Fi network, and try loading a page. If your phone also can’t get online, the problem is your router or your ISP, not Linux — reboot the router and check the ISP’s status page before doing anything else.

If your phone works fine but your Linux box doesn’t, you’ve confirmed it’s local to your machine, and it’s time to dig in.

Step 2: Check What IP Address You Actually Got

Open a terminal and run:

ip addr show

Look at the interface tied to your Wi-Fi adapter (usually named something like wlan0, wlp2s0, or wlo1). A working connection looks like this:

3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 192.168.1.42/24 brd 192.168.1.255 scope global dynamic wlp2s0

A broken DHCP lease looks like this instead:

3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 169.254.23.11/16 brd 169.254.255.255 scope link wlp2s0

That 169.254.x.x address is a dead giveaway — your machine failed to get a lease from the router’s DHCP server and gave itself a fallback address. That’s your answer right there — this is a DHCP failure, not a DNS or driver issue.

Fix it by requesting a fresh lease:

sudo dhclient -r wlp2s0
sudo dhclient wlp2s0

On distros using NetworkManager (which is most desktop distros today), it’s cleaner to just do:

nmcli connection down "Your-WiFi-Name"
nmcli connection up "Your-WiFi-Name"

If you get a proper address like 192.168.1.x or 10.0.0.x, DHCP is working fine and you move to the next check.

Step 3: Check the Default Gateway and Routing Table

A valid IP doesn’t guarantee you have a route out. Run:

ip route

You should see a line starting with default via 192.168.1.1 (or whatever your router’s local address is). If that line is missing entirely, your machine has no idea where to send traffic once it leaves your local subnet — which explains why you’re “connected” but stuck.

Try pinging the gateway directly:

ping -c 4 192.168.1.1

If that fails too, the problem is between your machine and the router — check Step 5 on driver issues. If the gateway responds but nothing beyond it does, ping a public IP directly to bypass DNS entirely:

ping -c 4 1.1.1.1

This one command tells you a lot. A working reply looks like:

64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=14.2 ms

If pinging 1.1.1.1 works but pinging google.com doesn’t, you’ve isolated the problem to DNS — skip straight to Step 4. If even 1.1.1.1 fails and you just get Destination Host Unreachable or 100% packet loss, your router has no working WAN connection, or there’s a firewall rule blocking outbound traffic (Step 6).

Step 4: Fix DNS Resolution (the Most Common Culprit)

This is genuinely the single most frequent cause of “connected but no internet” on Linux, especially after a fresh install or a distro upgrade. Modern distros route DNS through systemd-resolved, and it occasionally ends up pointing at a resolver that isn’t responding, or /etc/resolv.conf gets left in a broken state after a VPN disconnects.

According to the systemd-resolved man page, this service manages a local stub resolver and per-link DNS configuration — which is exactly why a bad handoff from your router or a leftover VPN entry can leave that stub pointing nowhere.

Check what’s actually in there:

cat /etc/resolv.conf

If it’s empty, or only lists an internal address like 127.0.0.53 and resolution is still failing, check systemd-resolved‘s status:

resolvectl status

Look for which DNS servers are actually assigned per interface. If none are listed, or they’re unreachable, you can force known-good DNS servers temporarily:

sudo resolvectl dns wlp2s0 1.1.1.1 8.8.8.8
sudo resolvectl flush-caches

For a permanent fix, edit your NetworkManager connection to use custom DNS instead of whatever the router hands out:

nmcli connection modify "Your-WiFi-Name" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli connection modify "Your-WiFi-Name" ipv4.ignore-auto-dns yes
nmcli connection up "Your-WiFi-Name"

I’d recommend Cloudflare (1.1.1.1) or Google (8.8.8.8) here simply because they’re fast and rarely go down — Cloudflare in particular publishes its own 1.1.1.1 public DNS documentation if you want to see uptime claims and setup details for other devices too. Any reliable public resolver works. If DNS starts working immediately after this, your router’s own DNS forwarding was the actual problem the whole time — very common on cheap or older consumer routers, and on ISP-supplied modems that double as routers.

Step 5: Rule Out a Driver or Firmware Problem

If pinging the gateway itself fails, or your Wi-Fi disconnects and reconnects in loops, the wireless driver is a likely suspect. This shows up disproportionately on laptops with Realtek RTL8821CE/RTL8852-series chips and some older Broadcom BCM43xx cards, particularly right after a kernel upgrade — this was exactly the issue I hit on my own machine, and it’s a well-documented pattern across Realtek chipsets specifically.

Check what chipset and driver you’re running:

lspci -k | grep -A 3 -i network

or, for USB Wi-Fi adapters:

lsusb

Check the kernel log for driver errors right after connecting:

sudo dmesg | grep -i -E "wlan|wifi|firmware"

A broken firmware load shows something like:

[    5.201134] rtw_8821ce 0000:03:00.0: failed to load firmware
[    5.201289] rtw_8821ce 0000:03:00.0: failed to request firmware

If you see repeated firmware failed to load or microcode timeout messages, the driver or firmware package is out of date or missing. On Ubuntu and Debian-based systems, install the extra firmware package:

sudo apt update
sudo apt install linux-firmware

On Fedora:

sudo dnf install linux-firmware

On Arch, the Arch Wiki’s Wireless network configuration page is genuinely the best single reference for this — it documents chipset-specific quirks and out-of-tree driver packages (like rtl8821ce-dkms-git) that fix chips the mainline kernel doesn’t fully support yet. This is one area where Arch and Fedora, which ship newer kernels faster, tend to actually have better out-of-box Wi-Fi support than older-kernel LTS releases — ironic, since people assume “stable” distros are always more reliable.

Step 6: Check the Firewall Isn’t Silently Blocking You

It’s easy to forget you enabled a firewall rule months ago that’s now blocking outbound DNS or HTTPS. Check what’s active:

sudo ufw status verbose      # Debian/Ubuntu/Mint
sudo firewall-cmd --state    # Fedora/RHEL-based
sudo iptables -L -n          # any distro, low-level view

If you’re not actively relying on a restrictive firewall policy, temporarily disable it to test:

sudo ufw disable

If internet access comes back immediately, you know the firewall config is the issue, and you can go back and add a proper allow rule instead of leaving it off permanently.

Step 7: Check for a VPN or Proxy Leftover

If you use a VPN client and it disconnected badly (crashed, or the laptop slept mid-connection), it can leave behind routing rules or a DNS override that never gets cleaned up. Run:

ip route

and look for unexpected routes pointing at a tun0 or wg0 interface that shouldn’t still exist. Killing the VPN process and restarting NetworkManager usually clears this:

sudo systemctl restart NetworkManager

Step 8: Watch Out for Captive Portals

If you’re on public Wi-Fi — a hotel, café, airport, coworking space — the network might require you to log in through a browser page before it lets any real traffic out. Linux doesn’t always pop this login page automatically the way phones do. Try manually opening a plain HTTP (not HTTPS) page like http://neverssl.com in your browser; captive portals usually intercept unencrypted HTTP and redirect you to their login screen, whereas they often just silently drop HTTPS requests.

Comparison Table: Symptom to Likely Cause to Fix

Distro-Specific Notes (Ubuntu, Fedora, Debian, Mint, Arch, openSUSE)

Most modern desktop distributions — Ubuntu, Fedora Workstation, Linux Mint, Pop!_OS, and openSUSE — use NetworkManager as the default network manager, so the nmcli and resolvectl commands above apply almost identically across all of them. A few distro-specific quirks worth knowing:

• Ubuntu 24.04 LTS and Ubuntu 26.04 LTS (“Resolute Raccoon”): Netplan sits on top of NetworkManager for desktop installs. If nmcli changes don’t stick after a reboot, check /etc/netplan/*.yaml for a conflicting renderer setting, then run sudo netplan apply. Canonical’s own Netplan documentation is the most reliable reference if you need to troubleshoot the YAML directly.
• Fedora 44 (current stable) and Fedora 45: Fedora tracks newer kernels aggressively, which generally means better Wi-Fi chipset support out of the box, but it also means driver regressions show up here first after a kernel bump. If Wi-Fi that worked yesterday breaks after dnf update, check if a newer kernel was installed and try booting the previous kernel entry from GRUB to confirm.
• Debian stable: Ships older, more conservative kernels, so it’s less likely to hit brand-new driver bugs, but also less likely to support very recent Wi-Fi chipsets without manually adding firmware-linux-nonfree from the non-free repo.
• Linux Mint: Built on Ubuntu’s base but uses its own network applet; the underlying fixes are identical to Ubuntu’s.
• Arch Linux and Manjaro: No default DNS stub unless you explicitly install and enable systemd-resolved or NetworkManager; check systemctl status NetworkManager first, since a minimal Arch install may not even have it running.
• openSUSE: Uses wicked on some server installations instead of NetworkManager — if nmcli commands return “not running,” check systemctl status wickedd instead.

Advanced Diagnostics (When the Basics Don’t Fix It)

If you’ve gone through every step above and you’re still stuck, it’s time to trace the actual path your traffic is taking.

mtr google.com

mtr combines ping and traceroute into one live view, showing exactly which hop your packets are dying at. A healthy run shows 0% loss all the way down the hop list; a broken connection shows 100% loss starting at a specific hop. If packets die at hop 1 (your router), the problem is local. If they die a few hops into your ISP’s network, it’s genuinely an ISP-side outage, and no amount of Linux configuration will fix it.

For a deeper look at what’s actually happening on the wire, tcpdump shows raw packet flow on the interface:

sudo tcpdump -i wlp2s0 port 53

This filters to just DNS traffic (port 53), so you can watch in real time whether your DNS queries are even leaving the machine, and whether you’re getting responses back. If you see outgoing queries but zero replies, that’s confirmation the DNS server you’re pointed at isn’t answering — not a Linux-side bug at all.

How to Prevent This From Happening Again

A few habits that meaningfully cut down how often this problem recurs:

• Set a reliable, fixed DNS server (1.1.1.1 or 8.8.8.8) instead of relying on your router’s forwarding, which tends to be the flakiest link in the chain
• Keep linux-firmware updated alongside kernel updates, don’t let them drift apart
• Avoid holding a VPN connection open across sleep/wake cycles if your client doesn’t reconnect cleanly
• After any kernel update on a laptop with a known finicky Wi-Fi chipset, check dmesg for firmware warnings before assuming everything’s fine

Frequently Asked Questions

Wrapping Up

Most of the time, Linux connected to Wi-Fi but no internet comes down to a broken DNS resolver or a DHCP hiccup — not some deep, mysterious system failure. Work through the checks in order (IP address, routing, DNS, driver, firewall, VPN, captive portal) and you’ll almost always land on the actual cause within a few minutes, without needing to reinstall anything or dig through forum threads for hours. That was true in my own case with the Realtek firmware issue, and it holds true across almost every version of this problem I’ve seen reported since.

If you want to go deeper on any single piece of this, the official documentation linked throughout this guide — the Arch Wiki, Netplan docs, and systemd-resolved’s man page — are worth bookmarking for future reference.

Disclaimer: This guide is intended for general troubleshooting purposes. Commands that modify network configuration, firewall rules, or DNS settings can affect connectivity on shared or production systems — always double-check settings relevant to your specific distro version and network environment, and back up configuration files before editing them.

About the Author

Linuxano Editorial Team

Administrator

We're Linux users who test hardware across Ubuntu, Fedora, Arch, and other distributions to find what actually works. Every laptop, GPU, keyboard, and WiFi adapter we review gets real-world testing on our own systems. No sponsored hype—just honest compatibility data to help you make informed buying decisions. Because nothing's worse than hardware that doesn't work with your Linux setup.

Visit Website View All Posts