Captive Portal werkt niet op Mac: Hoe los je de hotel Wi-Fi loginpagina op

Een captive portal werkt doordat het je eerste onversleutelde webverzoek onderschept en beantwoordt met een redirect naar de inlogpagina van het netwerk in plaats van naar de site die je hebt opgevraagd. macOS weet van dit gedrag en voert een automatische connectiviteitscontrole uit zodra je verbinding maakt met een Wi‑Fi-netwerk. Als die controle een redirect krijgt in plaats van de verwachte respons, opent macOS een klein captive‑netwerkassistent‑venster met het portal erin.

Het niet verschijnen van de inlogpagina betekent vrijwel altijd één van twee dingen: of de connectiviteitscontrole kreeg nooit een schoon antwoord, of de redirect die hij had moeten ontvangen werd geblokkeerd, versleuteld of naar een plek gestuurd die het portal niet kon bereiken. De Wi‑Fi‑verbinding zelf is meestal prima. De onderhandelingen erbovenop zijn wat stuk is gegaan.

De gebruikelijke oorzaken, grofweg in volgorde van hoe vaak ze het probleem blijken te zijn: het portal kan een HTTPS‑verzoek niet onderscheppen, dus alles wat je in de browser opent faalt met een fout in plaats van te redirecten; een aangepaste of versleutelde DNS‑instelling, zoals DNS‑over‑HTTPS, een resolver van een derde partij, een Pi‑hole of NextDNS, voorkomt dat de redirect je ooit bereikt; een actieve VPN verpakt je verkeer voordat het het netwerk kan raken; het captive‑netwerkassistent‑venster werd te vroeg gesloten en komt niet vanzelf terug; gecachte DNS van een vorig netwerk wijst je Mac naar adressen die niet langer van toepassing zijn; een privé, gerandomiseerd Wi‑Fi‑adres verwart de sessietracking van het portal; of een contentfilter of firewall blokkeert stilletjes het verzoek van het portal.

Één ding om op te merken over die lijst: vrijwel elk item beschermt je privacy of veiligheid en doet precies zijn werk. Captive portals vertrouwen erop dat ze verkeer kunnen onderscheppen. Modern macOS, moderne browsers en moderne beveiligingstools zijn gebouwd om dat precies te voorkomen. Het conflict is structureel, niet een bug aan één van de kanten.

Vergeet het netwerk en sluit het opnieuw aan. Dit is de meest effectieve oplossing en duurt ongeveer vijftien seconden. Open de Wi-Fi-instellingen, verwijder het netwerk uit de lijst van bekende netwerken, en sluit er opnieuw verbinding mee vanaf nul. Het opnieuw verbinden dwingt macOS om zijn connectiviteitscontrole opnieuw uit te voeren, wat meestal genoeg is om de captive-network assistant terug te brengen.

Open een gewoon http://-adres in een browser. Als het assistentvenster niet verschijnt, kun je de redirect handmatig activeren, maar alleen met een onversleuteld verzoek. Typ geen normale sitenaam, browsers gebruiken tegenwoordig standaard HTTPS, en een HTTPS-verzoek kan niet door het portal worden doorgestuurd, waardoor je een verbindingsfout of een certificaatwaarschuwing krijgt in plaats van een inlogpagina. Typ het adres expliciet met http:// ervoor, en kies iets dat waarschijnlijk niet automatisch wordt geüpgraded. Twee veelgebruikte adressen hiervoor zijn http://neverssl.com en http://captive.Apple.com. Als het portal werkt, zou een van hen je direct naar de inlogpagina moeten sturen.

Verbreek je VPN-verbinding. Als een VPN verbonden is of automatisch verbindt, kan het portal niets onderscheppen, omdat je verkeer al versleuteld en getunneld is. Zet het volledig uit in plaats van alleen de sessie te beëindigen, log in en zet het weer aan. Veel VPN-clients hebben een auto-connect- of altijd-aan-instelling die binnen seconden opnieuw verbindt en je voortgang stilletjes ongedaan maakt.

Controleer de klok. Dit klinkt misschien niet gerelateerd, maar kost slechts tien seconden. Als de datum en tijd op je Mac significant verkeerd staan, faalt de certificaatvalidatie en weigeren portalpagina’s die HTTPS gebruiken voor het daadwerkelijke inlogformulier te laden. Zet datum en tijd terug op automatisch om dit op te lossen.

Als alle vier de methoden falen, ligt de oorzaak zeer waarschijnlijk bij DNS of een privacy-instelling, en de volgende twee secties behandelen die in die volgorde.

Captive portals vertrouwen meer op DNS dan de meeste mensen beseffen. Wanneer je Mac een adres opzoekt, antwoordt de DNS-server van het netwerk met het adres van de portal in plaats van het echte adres, en zo begint de redirect. Als je Mac niet de DNS-server van het netwerk vraagt, gebeurt die eerste stap nooit.

Dit is waarom handmatig geconfigureerde DNS zo vaak de oorzaak is. Als je je Mac hebt ingesteld op een resolver van een derde partij, of het wijst naar een Pi-hole thuis, of DNS-over-HTTPS of een service zoals NextDNS hebt geconfigureerd, gaan je zoekopdrachten naar een plek die het hotelnetwerk niet kan onderscheppen. De oplossing is om DNS tijdelijk terug te zetten op automatisch. In de netwerkinstellingen van macOS kun je de handmatig ingevoerde DNS-servers verwijderen, waardoor de Mac teruggaat naar wat het netwerk via DHCP levert. Log in, en zet je eigen instellingen weer terug. Versleutelde DNS geïnstalleerd via een configuratieprofiel moet mogelijk worden uitgeschakeld in plaats van bewerkt, maar het principe blijft hetzelfde.

Hoe weet je dat DNS het probleem is? Een goed signaal is dat een gewone http://-adres niet resolveert, in plaats van te redirecten, of meteen faalt in plaats van na een trage timeout. Een ander: de router of gateway laadt prima wanneer je het als een puur IP-adres typt, maar niets dat als naam wordt getypt werkt. Dat wijst op naamresolutie in plaats van connectiviteit.

De VPN-gevallen hebben hun eigen signatuur. Met een actieve VPN lijkt de verbinding vaak volledig gezond, de client kan zelfs een werkende tunnel melden, en toch laadt geen enkele site en verschijnt geen portal. Sommige VPN-clients hebben een captive-portal of hotspot-detectiemodus die kort onversleuteld verkeer toestaat zodat je kunt inloggen. Als die er is, schakel het dan in. Zo niet, verbreek volledig de verbinding, log in, en maak opnieuw verbinding.

Verouderde DNS van een vorige netwerk kan ook blijven hangen. Als je net bent overgestapt op een ander netwerk en de Mac lijkt te zoeken naar adressen die geen zin hebben voor waar je bent, dan helpt het legen van de DNS-cache. Dit doe je meestal via Terminal met sudo dscacheutil -flushcache gevolgd door sudo killall -HUP mDNSResponder, hoewel de exacte commando's kunnen variëren afhankelijk van macOS-versies. Als je liever geen commando's typt, herstart dan de Mac; dat doet hetzelfde, en het uit- en aanzetten van Wi-Fi wist een verrassend grote hoeveelheid.

Private Wi‑Fi Address. macOS gebruikt standaard een willekeurig hardware‑adres per Wi‑Fi‑netwerk, waardoor het veel moeilijker wordt voor netwerkbeheerders en anderen in de buurt om je apparaat over locaties en in de tijd te traceren. Het is een echte goede functie. Het verwart ook sommige captive portals, vooral die een betaalde of tijdgebonden sessie koppelen aan een hardware‑adres, en hotelnetwerken die hetzelfde apparaat telkens weer verwachten. Het symptoom is meestal dat je succesvol inlogt en daarna weer teruggestuurd wordt naar de inlogpagina, of dat een sessie die je gisteren hebt betaald je vandaag niet herkent.

Je kunt het Private Wi‑Fi Address uitschakelen voor een enkel netwerk in de Wi‑Fi‑instellingen van dat netwerk. Wees je bewust van de afweging: dit is geen instelling om wereldwijd uit te schakelen. Het uitschakelen voor één hotelnetwerk tijdens één verblijf is een afgewogen beslissing. Het overal uitschakelen geeft een stabiele identifier aan elk netwerk waarmee je ooit verbinding maakt. Als je het uitschakelt voor een portal, zet het dan weer aan, of vergeet het netwerk volledig zodra je vertrekt.

Versleutelde DNS en contentfilters. Dezelfde logica geldt voor DNS‑over‑HTTPS en DNS‑over‑TLS. Deze bestaan precies zodat het netwerk je zoekopdrachten niet kan zien of wijzigen, wat precies is wat een portal nodig heeft. Er is geen slimme manier om dat te omzeilen: voor het inloggen zelf heeft het netwerk een venster nodig. De juiste aanpak is een beperkte: terugvallen op automatische DNS, net lang genoeg om te authenticeren.

Contentfilters en ouderlijk toezicht vallen in dezelfde categorie. Alles dat DNS‑ en HTTP‑verzoeken inspecteert, herschrijft of blokkeert, kan de redirect van de portal stilletjes wegvallen, en omdat zulke tools zijn ontworpen om stil te falen, krijg je vaak geen foutmelding, alleen een pagina die nooit laadt. Als je er een gebruikt, voeg het dan toe aan je checklist voordat je ervan uitgaat dat het netwerk kapot is.

Browsergedrag. Browsers dwingen steeds vaker HTTPS af, blokkeren onveilige redirects en cachen agressief. Het proberen van een andere browser, of een privévenster, kan vaak al genoeg zijn om een portal te laten laden. Safari is vaak het meest meewerkend, omdat de captive‑network‑assistent op dezelfde engine is gebouwd.

Als je dit een paar keer hebt meegemaakt, wordt een patroon duidelijk: elke oplossing in deze gids houdt in dat je tijdelijk een verdediging uitschakelt. Zet de VPN uit. Geef je aangepaste DNS op. Laat je echte hardware-adres zien. Sta onversleuteld verkeer toe. Zet daarna, nadat je hebt ingelogd op een onbetrouwbaar netwerk, alles weer aan. De meeste mensen doen dat niet, en zo blijft een Mac drie dagen op hotel‑Wi‑Fi zitten met de beveiligingen uit, vanaf dinsdag.

Dat is de echte kostenpost, en het is de moeite waard dat te benoemen, want het antwoord is niet om de bescherming op te geven. Openbare Wi‑Fi is precies waar een Mac baat heeft bij strengere maatregelen dan thuis: minder apps die toegang krijgen tot internet, achtergrondservices die worden tegengehouden, en een helder overzicht van wat er daadwerkelijk communiceert op een netwerk dat je niet beheert.

De uitweg uit het conflict is tooling die weet wat een captive portal is, in plaats van tooling die je eromheen moet uitschakelen. Zo is NetMute's hotspotbescherming opgebouwd. Wanneer je Mac zich verbindt met een onbekend of openbaar netwerk, past hij automatisch een strenger profiel toe, en handelt hij captive portals af zodat de inlogpagina nog steeds laadt in plaats van geblokkeerd te worden. Je logt normaal in, en het strenge profiel blijft actief.

De rest van de app volgt hetzelfde principe. Netwerkprofielen zijn gekoppeld aan het Wi‑Fi‑netwerk waarop je bent, zodat je thuisregels en luchthavenregels echt verschillend kunnen zijn zonder dat je erover na hoeft te denken. De per‑app firewall blokkeert alles met één klik, en tijdelijke regels verlopen vanzelf, wat handig is als je één app voor een paar minuten wilt toestaan. De traffic monitor laat zien welke apps communiceren en waar.

NetMute is gratis te downloaden via de Mac App Store, en Premium is een enkele in‑app aankoop in plaats van een abonnement. Als je tijd doorbrengt op hotel‑ en luchthaven‑Wi‑Fi, zorgt een Mac die zichzelf aanscherpt en je toch door de login krijgt, dat het deel van het probleem dat geen checklist kan oplossen — namelijk het vergeten alles weer aan te zetten — wordt weggenomen.