Se il rilevamento automatico del captive portal non funziona, e colpendo un dominio comune (come google.com), prova normalmente un dominio che non visita (e quindi non verrà memorizzato nella cache in qualunque posto). Prova ad esempio su borg.org.
Se ciò non ti dà ancora la pagina di destinazione, è tempo di misure estreme. Puoi ottenere maggiori informazioni sulla configurazione DHCP ottenuta con ipconfig getpacket en0 (o en1 o qualunque sia l'interfaccia Wi-Fi); guarda in particolare le righe "server_identifier" (il server che ha inviato le informazioni), "router" e "domain_name_server". Prova a colpire quelli nel tuo browser e verifica se ti arriva una pagina di destinazione.
Ancora niente? Quindi prova host www.cnn.com x.x.x.x dove x.x.x.x è il server dei nomi di dominio (se ce ne sono diversi, prova con ciascuno). Se torni a ricevere qualsiasi IP che non fosse già presente nell'elenco, provalo in un browser.
BTW, il motivo per cui a volte questo non funziona automaticamente è fondamentalmente che è tutto altamente non standard. I portali in cattività sono un trucco che qualcuno ha inventato per controllare l'accesso a una rete wireless in un modo che gli standard non hanno gestito. Un sacco di altri produttori hanno copiato l'idea, ma tutti lo hanno fatto in modo un po 'diverso, e ha dirottato le pagine web reali nel browser, ed era generalmente un casino. Quindi Apple ha costruito un sistema in macOS che tentava di rilevare i portali in cattività e visualizzare automaticamente la pagina di destinazione, in un modo che non ha dirottato il browser ... ma dal momento che ci sono così tante varianti sull'idea, è difficile da costruire un sistema che li gestisce tutti. E a volte l'amministratore di rete locale imposta le cose in modo strano, e ... fondamentalmente, è un trucco per aggirare un altro trucco, e di conseguenza ci sono molti modi per fallire. Francamente, sono piuttosto sorpreso che funzioni tutte le volte che fa.