Fixing Fedora Captive Portal Issues on Public Wi-Fi

We have all experienced this situation: you visit a hotel, airport, café, or another public place, connect to the Wi-Fi network, and are asked to log in through a captive portal.

Normally, this is not a problem. Your browser opens automatically, the login page appears, and after accepting the terms or entering the required details, you can access the good old interwebs.

Unfortunately, I recently encountered a frustrating issue on Fedora.

The Problem

Whenever I connected to a public Wi-Fi network, Fedora attempted to load the following address:

1

http://fedoraproject.org/static/hotspot.txt

However, nothing happened.

No matter how many times I refreshed the page, the captive portal would not appear. Trying to open another website did not help either. The browser would simply continue waiting or redirecting without displaying the actual login page.

So, what can you do?

The Quick Workaround

One commonly recommended workaround is to open a website that uses plain HTTP rather than HTTPS:

1

http://example.com

Because captive portals need to intercept the initial connection, opening an HTTP website can sometimes force the network to redirect you to its login page.

This worked for me in some cases, but not consistently.

A more reliable option was Mozilla’s captive portal detection page:

1

http://detectportal.firefox.com/canonical.html

Opening this address triggered the captive portal correctly and allowed me to log in.

That solves the immediate problem, but nobody wants to search for or copy and paste the same URL every time they connect to public Wi-Fi.

The Permanent Fix

NetworkManager allows us to configure a custom connectivity-check URL. Configuration overrides can be placed inside:

1

/etc/NetworkManager/conf.d/

Create a new configuration file by running:

1
2
3
4
5
6
7

sudo tee /etc/NetworkManager/conf.d/99-captive-portal.conf >/dev/null <<'EOF'
[connectivity]
enabled=true
uri=http://detectportal.firefox.com/canonical.html
response=<meta http-equiv="refresh" content="0
interval=60
EOF

This tells NetworkManager to use Mozilla’s detection page instead of Fedora’s default connectivity-check address.

Reload NetworkManager

After creating the file, reload NetworkManager:

1

sudo systemctl reload NetworkManager

Verify the Configuration

To confirm that NetworkManager has loaded the custom settings, run:

1

NetworkManager --print-config | grep -A5 '^\[connectivity\]'

You should see output similar to this:

1
2
3
4
5

[connectivity]
enabled=true
uri=http://detectportal.firefox.com/canonical.html
response=<meta http-equiv="refresh" content="0
interval=60

Test the Connectivity Check

You can manually trigger a connectivity check with:

1

nmcli networking connectivity check

Possible results include:

1

full

This means that NetworkManager believes you have full internet access.

When connected to a network that requires authentication, the result may instead indicate limited or portal connectivity until you complete the login process.

Restart NetworkManager if Necessary

In some cases, reloading the service may not apply the change immediately.

Restart NetworkManager instead:

1

sudo systemctl restart NetworkManager

Restarting NetworkManager will temporarily disconnect your active network connections.

After reconnecting to the public Wi-Fi network, Fedora should use the new connectivity-check URL and trigger the captive portal more reliably.

Undoing the Change

To restore the default NetworkManager behaviour, remove the custom configuration file:

1

sudo rm /etc/NetworkManager/conf.d/99-captive-portal.conf

Then restart NetworkManager:

1

sudo systemctl restart NetworkManager

Final Thoughts

Captive portals can be surprisingly inconsistent. Different networks use different redirect mechanisms, and HTTPS makes automatic redirection more difficult because the connection is encrypted.

Opening a plain HTTP page such as http://example.com remains a useful quick workaround. However, changing NetworkManager’s connectivity-check URL provides a more convenient long-term solution when Fedora’s default check fails repeatedly.

Since applying this configuration, connecting to public Wi-Fi networks has been considerably less frustrating.