Ever connected to public Wi-Fi and been hit with a weird login page or a button that says “I accept the terms” before you can browse?
That’s called a captive portal – a gatekeeper page that pops up when you connect to open networks in trains, hotels, cafés, airports, or universities. These portals are used to:
– Ensure terms of service are acknowledged (legal coverage)
– Optionally request email/phone for marketing
– Track and rate-limit traffic
– Monetize internet access (e.g., by tiered plans)
They’re a necessary part of the public Wi-Fi experience – but when they don’t play well with your setup, they can block your access entirely.
That’s exactly what happened to me on a TGV Lyria train to Paris, and here’s how I fixed it with a simple – and slightly geeky – trick.
The Setup
I was on a high-speed train, connected to the TGV Lyria onboard Wi-Fi, trying to get online using:
– A Linux laptop running Kubuntu
– Multiple browsers: Chrome, Brave, Vivaldi
– No VPN, no custom DNS, and no ad blockers enabled
The captive portal appeared automatically and loaded this page:
https://captive.tgv-lyria.com/portal/en/success
It said:
“You’re almost there! To enjoy the Internet and onboard services, please click below.”
Clicking “I access the internet” looked promising, but…
The Infinite Loop!!!
Every time I clicked the button, I was redirected back to the same page. No error, no internet, no feedback. Just a loop. The browser’s network tab showed that requests were going through, but the final redirect didn’t “unlock” internet access.
Meanwhile, my phone worked perfectly. I accepted once, and boom – access granted.
What I Tried First
As a browser developer and Linux user, I tried all the usual suspects:
– Manually accessing https://neverssl.com
– Disabling all extensions
– Clearing cookies and site data
– Flushing DNS with sudo resolvectl flush-caches
– Testing with curl and inspecting headers
– Capturing logs in the browser’s network tab
Still no luck. The portal kept looping, and no internet connection was established.
The Fix: Pretend You’re on a Phone
Out of frustration, I opened Chrome DevTools (F12), clicked the “Toggle Device Toolbar”, chose Phone mode, and reloaded the captive portal page.
Browsed again to https://captive.tgv-lyria.com/ , accepted. 🎉 It worked instantly.
Clicking the button now finalized the login and gave me full internet access.
Why This Works (The Geeky Explanation)
Captive portals are often built with minimal effort, targeting the majority of users (phones + tablets). So what happens under the hood?
The portal detects your User-Agent string to decide how to render or respond
- On mobile devices, it sometimes:
– Sends a slightly different flow (fewer checks)
– Uses mobile-only JavaScript handlers
– Assumes faster auth success or different cookie handling - On desktop browsers, especially on Linux, things can break due to:
– Unsupported browser versions or forks
– Case-sensitive JS bugs
– Network interfaces behaving differently (e.g., no fallback to DNS hijack detection)
– Cookie path mismatches
In my case, it seems the button’s click event didn’t complete some JS action expected on mobile. The redirect worked – but their backend never acknowledged the session.
But What About Windows or macOS?
This is where it gets interesting. Most regular users on Windows and macOS won’t experience this – at least not as often. Why?
Windows 🪟 (>=8):
– Has a built-in captive portal detection service
– Opens a mini Internet Explorer/Edge WebView when Wi-Fi connects
– Automatically triggers a probe to https://www.msftconnecttest.com/
– Automatically handles redirects without relying on the user’s browser
macOS 🍎:
– Uses Captive Network Assistant, a lightweight WebKit window
– Triggers HTTP probes (e.g., to https://captive.apple.com)
– Seamlessly opens the portal in a floating window, sandboxed and simplified
Both systems emulate a mobile-like behavior under the hood.
That’s why portals like TGV Lyria – likely tested mostly on phones – work well there.
Linux 🐧, on the Other Hand…
Most Linux distros lack native captive portal detection.
Unless you’re running something like NetworkManager with connectivity-check enabled, you won’t be auto-redirected. And even then:
– There’s no standard login window
– You’re relying fully on your browser
– Some browsers (like Chromium) won’t follow redirects from HTTP to HTTPS automatically if the chain looks suspicious
Plus, if you use privacy-friendly distros, hardened DNS, or even DNS-over-HTTPS… you’re likely bypassing the portal altogether until you open something like https://neverssl.com.
Final Thoughts
Captive portals are everywhere – and they rarely get love from developers. Most are built with minimal testing, especially for Linux users or non-mainstream setups.
But sometimes, all it takes is a tiny trick like pretending your browser is a phone to bypass their assumptions and get online. Next time you’re stuck in a train, airport, or café – fake it ‘til you make it.
