Skip to main content

Ubiquiti UniFi guest portal not redirecting: causes and fixes

This guide isolates a UniFi guest portal redirect failure by following the guest state, redirect, pre-authorisation route and controller authorisation in sequence. It gives venue IT teams a sourced method to address guest-network versus Hotspot confusion, external portal hand-offs, current UniFi OS account requirements and DNS isolation testing.

By Marketing TeamPublished
📖 12 min read3,061 words3 worked examples9 key definitions

Listen to this guide

View podcast transcript
PART 1 If your UniFi guest portal has stopped redirecting, do not start by rebuilding the SSID. Start by locating the broken hand-off. A working external portal depends on four actions in sequence: the guest joins the SSID, UniFi treats the device as an unauthorised Hotspot guest, the redirect reaches the external service, and that service changes the client to authorised. One failed hand-off leaves a guest connected but offline. For a hotel, retail estate, stadium or conference centre, this is an operational incident. The WiFi network may still broadcast. Access points may still be healthy. Guests may receive an address and appear connected. None of that proves captive access is working. The first distinction is between a guest network and a Hotspot. A guest VLAN or isolated SSID provides segmentation. A Hotspot adds the access-control state and, when enabled, Captive Portal. Ubiquiti documents that a Hotspot can apply to a WiFi SSID or an entire network or VLAN. For an SSID, check the WiFi configuration, where Hotspot Portal and Captive Portal must be enabled. If the interface moved after an application update, use current vendor documentation rather than an old screenshot. Use a fresh guest device for the first controlled test. A previously authorised phone can make a broken path look healthy, while cached portal behaviour can make a healthy path look broken. Connect to the affected SSID and inspect client state in UniFi. In Ubiquiti's documented external authorisation flow, a device that connects to an SSID with Hotspot and Captive Portal enabled begins as a guest with authorised set to false. That is the starting point. If it is absent, you are not yet testing the portal workflow. Now trigger a normal web request from that unauthorised device. The expected external flow redirects the request to the external portal server. This divides the incident cleanly. If no redirect occurs, return to the Hotspot configuration, client state and pre-authorisation access. If the redirect appears but the page cannot load, focus on the route from the guest segment to the external service. If the page loads but the guest remains offline after submission, focus on authorisation back to the controller. This is the point to be precise about the pre-authorisation allow list. It is not a copy of websites the guest should browse after joining. It is the controlled set of routing paths that must remain reachable before authorisation. Purple's UniFi guidance links blank screens after form completion to guest rules blocking traffic needed to finish the login process. Review the Pre-Auth ACL and post-authorisation settings, then declare the essential target routing paths. Do not invent a static list from an old deployment. Use the portal provider's current support guidance. For a Purple deployment, the integration uses controller API login rather than a RADIUS background authentication channel. Purple needs to reach the controller, authenticate with the dedicated account, and receive authority to approve the guest. Purple's guidance says the account must be local to the controller, have administrator write rights, have two-factor authentication disabled, and not be forced to change its password. A read-only account can authenticate but cannot complete guest authorisation. An interactive challenge cannot complete an automated request. This matters when a venue moves to current UniFi OS. Purple distinguishes current UniFi Network from the older standalone controller model. On a hardware-console estate, create the integration account in the primary UniFi OS dashboard, not only inside the Network application. For self-hosted UniFi OS Server, Purple says the account must exist at the root OS container layer so the front-end proxy can validate it before routing to Network. If a previously working deployment was updated, check this identity and controller-classification boundary before changing the WiFi design. For a UDM Pro investigation, follow the same discipline. Verify the external controller address or stable name, firewall path, controller classification in the external service and the local API administrator account. Do not assume a legacy controller path still applies because an older integration did. Before moving on, pause at the portal hand-off. Ubiquiti documents that a successful redirect supplies the external portal with access point MAC address, client MAC address, original destination and SSID. The external service uses the client MAC to locate the client object, obtains the client ID and sends an authorisation request to the UniFi Network API. Once that succeeds, the client state becomes authorised. Your three log checks are: did the redirect reach the provider, did the provider recognise the client, and did authorisation result in authorised true? PART 2 The next suspected cause is DNS. This is where teams can lose a day by declaring that Pi-hole, secure DNS or an upstream filter has broken UniFi. The primary documentation does not prove that a particular DNS product is the cause of a UniFi redirect failure, so treat it as an isolation test, not a verdict. Confirm which resolver the affected guest segment receives. Confirm that the external portal destination resolves and pre-authorisation policy permits the route. Then test the approved DNS path under change control. If the redirect returns, compare DNS responses and policy decisions before making a permanent change. A captive portal has both a network control plane and a device experience. Apple documents that iOS and macOS send a probe when joining a network to detect captive interception and display the sign-in page. A missing automatic window therefore does not prove that UniFi cannot redirect a browser request. Record the device, operating system, whether it is a fresh session, and the result of a normal web request. That separates a device-detection issue from a network redirect issue. The efficient incident workflow has a fixed order. First, confirm Hotspot and Captive Portal on the affected SSID or network. Second, confirm the client has entered the unauthorised guest state. Third, test whether the redirect reaches the external portal. Fourth, validate pre-authorisation paths and the DNS route that the guest actually uses. Fifth, inspect the provider response and authorisation attempt. Sixth, confirm the controller reports authorised. Finally, test normal internet access and clear the session before repeating. A hotel shows why this sequence matters. Imagine a 200-room property where guests join branded WiFi, but the external sign-in page is blank. Reception sees the SSID and concludes that WiFi is available. The network team starts with one fresh phone. The device is unauthorised, so the Hotspot state is present. It attempts to load the sign-in page but cannot complete it. The team reviews pre-authorisation requirements against the provider's current documentation, validates DNS resolution from the actual guest segment, and retests. The measure is observable: the device reaches the page, submits it, becomes authorised and reaches the internet. Now take a retail estate after a controller update. Store teams report that shoppers connect but never see the sign-in page. An engineer finds that the SSID is isolated but does not have Hotspot and Captive Portal enabled in the current UniFi layout. The correction is not to loosen the guest firewall. It is to restore the intended Hotspot configuration and test the unauthorised state. This is a representative case, not a statement about every UniFi release. Verify your estate through Ubiquiti's guide. For a stadium or conference venue with an external provider, another symptom is common. The sign-in page loads and accepts the form, but attendees remain offline. Here, the redirect and pre-authorisation path have passed. Check the external authorisation transaction. Confirm that the provider received redirect parameters, matched the client, contacted the controller and that the client changed to authorised. For Purple, review the local API account, write privileges, two-factor authentication, password-change setting, public reachability and controller classification. This turns a vague complaint into an evidence chain your internal team, MSP and provider can work through together. Avoid several failure patterns. Do not allow a broad guest rule merely to make the page appear. It can obscure the control point and conflict with your segmentation design. Do not copy a pre-authorisation list from another venue. Do not test only with an already authorised device. Do not classify every missing pop-up as a DNS issue. And do not change external credentials without checking whether an application update, account role or controller classification changed the integration path. For venue operators, the handover record should be small but complete. Store the current SSID or network name, portal provider, controller type, owner of the external API account, approved pre-authorisation requirements, DNS path, and a repeatable fresh-device test. After an update, run the same test before peak trading, a match day or a major conference. That lets you detect a broken authorisation path before guests report it at reception. The closing recommendation is straightforward. Work from guest state to redirect, from redirect to external service, and from external service back to controller authorisation. That sequence matches Ubiquiti's documented external Hotspot flow. Use Purple's UniFi support article for current integration requirements rather than preserving an old controller assumption. Keep DNS filtering in the investigation, but only as a measurable path to test. With that approach, you can restore the guest experience without weakening the network or rebuilding a deployment that was not the problem. PART 3 A few rapid-fire questions to close. Does a guest network automatically show a sign-in page? No. Segmentation and a Hotspot Captive Portal are separate checks. Confirm the affected SSID or network has the Hotspot and Captive Portal function enabled. What belongs in a pre-authorisation allow list? Only the essential routes needed to complete your chosen guest sign-in process before authorisation. Take that current list from the portal provider, and validate it from the actual guest segment. Does Pi-hole break a UniFi hotspot? Do not assume so. Treat the DNS layer as a testable dependency. Record the guest resolver, test resolution and the approved DNS route, then compare evidence before changing a filter policy. Why can the sign-in page appear but access still fail? Because the redirect phase and the authorisation phase are different. Check that the external service recognised the client and that the UniFi controller recorded authorised true. What is the quickest safe test after a controller update? Use one fresh device. Confirm the unauthorised guest state, open a normal web request, complete sign-in, confirm authorised state and then confirm internet access. For Purple, include the dedicated local API account and current controller classification in that test. The practical next step is to keep this sequence in your venue runbook. Test the guest state, redirect, pre-authorisation route, external provider response and controller authorisation in that order. Capture the result before an event, a peak trading period or a major hotel arrival window. If one stage fails, escalate with that evidence rather than a generic report that the guest WiFi has stopped working. That gets the right team to the right fault boundary sooner.

Part of our core series: Captive Portal Guide

Ubiquiti UniFi guest portal not redirecting: causes and fixes

Un Captive Portal UniFi di solito smette di reindirizzare perché l'SSID non è più un Hotspot attivo, l'utente ospite non si trova nello stato non autorizzato, i percorsi di pre-autorizzazione richiesti non riescono a raggiungere il servizio esterno, o il portale non riesce a comunicare l'autorizzazione a UniFi. Verifica questi passaggi esattamente in questo ordine 1 2 3 .

Quali condizioni devono essere soddisfatte affinché avvenga il reindirizzamento ospite UniFi?

Questa è una guida per la risoluzione dei problemi di una configurazione precedentemente funzionante. Non ti verrà chiesto di ricostruire la tua rete WiFi ospiti da zero. Al contrario, la guida procede dal dispositivo ospite verso il controller, per poi tornare indietro attraverso il servizio esterno. Questo ordine previene un errore comune: modificare un SSID, un firewall o un'impostazione DNS prima di sapere quale passaggio ha effettivamente fallito.

Ubiquiti definisce un Hotspot come la funzionalità che può essere applicata a un SSID WiFi o a un'intera rete o VLAN. Il Captive Portal viene poi abilitato all'interno di quella configurazione Hotspot. Di conseguenza, una VLAN ospiti, un SSID ospiti o una policy di isolamento della rete non dimostrano di per sé che il flusso di reindirizzamento sia attivo. Se l'interfaccia utente dell'applicazione UniFi Network è cambiata dopo un aggiornamento, conferma lo stato attuale di Hotspot e Captive Portal seguendo la documentazione ufficiale di Ubiquiti, invece di fare affidamento sulla posizione storica del menu. 1

Per un portale esterno, Ubiquiti descrive un percorso utente preciso. Un dispositivo si connette a un SSID configurato con Hotspot e Captive Portal. Inizia come GUEST con authorised: false. Quando tenta di effettuare una richiesta web, UniFi lo reindirizza al server del portale esterno. Il server riceve i dettagli identificativi del client e dell'access point, ottiene l'ID del client UniFi, quindi richiede l'autorizzazione tramite l'API Network. Un flusso completato correttamente si traduce in authorised: true. 2

Cosa osservi su un nuovo dispositivo Limite da esaminare per primo Prove da raccogliere Prossima azione sicura
Il dispositivo si connette, ma non entra mai nello stato di ospite non autorizzato Attivazione dell'Hotspot SSID o assegnazione di rete e stato del client Ripristina la configurazione pianificata di Hotspot e Captive Portal, quindi esegui nuovamente il test. 1 2
Il dispositivo non è autorizzato, ma non appare alcuna pagina di accesso esterna Reindirizzamento e percorso di pre-autorizzazione Risultato della richiesta del browser, policy ospiti e percorso DNS Verifica i percorsi di instradamento di pre-autorizzazione richiesti confrontandoli con le linee guida attuali del provider del portale. 3
La pagina appare, ma il processo non si completa Raggiungibilità del servizio esterno Esito della richiesta dal segmento ospiti e registro degli eventi lato provider Isola il percorso degli ospiti verso il servizio esterno prima di modificare le impostazioni del controller. 2 3
Il modulo viene completato, ma l'accesso rimane bloccato Autorizzazione del controller Evento di autorizzazione del provider esterno e stato del client UniFi Verifica se il servizio esterno è in grado di autorizzare esattamente quel client e se UniFi segnala authorised: true. 2

Ubiquiti UniFi guest portal not redirecting: causes and fixes - redirect diagnostic flow

La regola diagnostica: non considerare la condizione "connesso al WiFi" come la condizione di successo. La condizione di successo è un client di test non autorizzato che raggiunge il servizio di accesso previsto, completa il relativo processo, mostra authorised: true e quindi riceve l'accesso previsto. 2

Di cosa hai bisogno prima di iniziare l'isolamento dei guasti?

Utilizza un dispositivo di test fresco e non autorizzato. Un dispositivo già autorizzato è uno strumento diagnostico scadente perché potrebbe saltare il passaggio che devi esaminare. Registra lo SSID o il nome della rete, l'ora del test, il tipo di dispositivo, il sistema operativo e se il dispositivo visualizza una richiesta di accesso automatica o solo un normale risultato del browser. Apple afferma che iOS e macOS inviano un probe al primo accesso a una rete per rilevare l'intercettazione del Captive Portal e visualizzare una pagina di accesso. Ciò significa che la mancanza di una finestra automatica è un indizio utile, ma non è una prova conclusiva che il gateway non possa reindirizzare una normale richiesta del browser. 4

Tieni il test circoscritto. Non iniziare aggiungendo ampie regole di accesso per gli ospiti. Non eliminare un'integrazione funzionante. Non copiare un elenco di consentiti di pre-autorizzazione da un'altra struttura. È necessario stabilire il percorso effettivo dell'ospite e la fase esatta in cui si interrompe. Se il problema riguarda più sedi, esegui lo stesso test con un dispositivo fresco in ciascuna di esse. Una differenza tra i siti è più utile di una teoria su un aggiornamento del controller condiviso.

Per una distribuzione Purple, tieni aperto l'articolo corrente UniFi Integration: Best Practices & Common Questions durante il test. Purple utilizza un login API diretto del controller anziché un canale di autenticazione in background RADIUS. L'account API dedicato deve quindi essere locale rispetto al controller, avere diritti di scrittura come amministratore, avere il 2FA disabilitato e non richiedere la modifica della password. Purple documenta anche diversi requisiti di posizionamento dell'account per le console hardware e per il UniFi OS Server self-hosted. 3

Come si isola il passaggio non riuscito?

Inizia dal livello di accesso. Conferma che lo SSID WiFi interessato, o la relativa configurazione dell'intera rete, sia ancora impostato come Hotspot con Captive Portal abilitato. Ubiquiti documenta l'attuale percorso WiFi-SSID e documenta separatamente un percorso Hotspot Zone per una configurazione dell'intera rete o VLAN. Questa distinzione è la risposta alla comune confusione UniFi guest network vs hotspot. Una rete ospite isolata può essere il segmento corretto e non riuscire comunque ad avviare il flusso di lavoro di accesso se la funzione Hotspot non è attiva. 1 Successivamente, ispeziona il client appena connesso. Devi verificare lo stato non autorizzato documentato, non una semplice associazione wireless. Se lo stato non è presente, torna alla configurazione del Hotspot e al SSID o alla rete selezionata. Non procedere con il DNS, un provider esterno o un'integrazione UDM Pro finché questa fase non è corretta. Un servizio esterno non può autorizzare un ospite che non è mai entrato nel flusso dell'Hotspot esterno. 2

Quindi attiva una normale richiesta web dallo stesso dispositivo. Se la richiesta raggiunge il servizio esterno, conserva il risultato come prova. In caso contrario, concentrati sul percorso di pre-autorizzazione del segmento ospiti. Purple connette gli ospiti solo al completamento del loro processo esterno, e le sue linee guida di supporto associano una schermata vuota dopo l'invio del modulo a regole per gli ospiti che bloccano il traffico web nascosto necessario per completare l'accesso. Verifica l'ACL di Pre-Auth e le impostazioni di post-autorizzazione. Dichiara i percorsi di instradamento di destinazione essenziali tratti dalla documentazione corrente del provider. 3

In questa fase, mantieni preciso il termine allow list. Non si tratta di un elenco di destinazioni web generali per un ospite autorizzato. È l'insieme di percorsi richiesti prima dell'approvazione, come il servizio esterno e gli elementi necessari per completare la transazione di accesso. L'articolo di supporto di Purple è la fonte autorevole per i propri requisiti correnti. Inserisci il link all'articolo di supporto nel tuo ticket di incidente e registra la data della versione, anziché incorporare un elenco copiato e non aggiornato in un runbook. 3

Come si verifica l'autorizzazione del portale esterno e il percorso UDM?

Se la pagina di accesso si carica, la tua indagine passa dall'intercettazione all'autorizzazione. Ubiquiti afferma che il reindirizzamento passa l'indirizzo MAC dell'access point, l'indirizzo MAC del client, l'URL originale richiesto e il SSID al portale esterno. Il servizio esterno può utilizzare l'indirizzo MAC del client per ottenere l'ID del client dall'API di rete, quindi emettere una richiesta di autorizzazione. La conferma lato controller è lo stato authorised: true del client. 2

Ubiquiti UniFi guest portal not redirecting: causes and fixes - external authorisation path

Esamina le prove in questo ordine. In primo luogo, il provider ha ricevuto un reindirizzamento per il client interessato? In secondo luogo, ha identificato lo stesso client elencato da UniFi? In terzo luogo, ha inviato una richiesta di autorizzazione? In quarto luogo, UniFi ha segnalato il client come autorizzato? Questa sequenza fornisce a un team IT locale e a un MSP un record di incidente condiviso. Inoltre, interrompe il ciclo improduttivo in cui una parte afferma che "il portale si è caricato" mentre l'altra sostiene che "il firewall è a posto".

La questione relativa al UDM Pro guest portal richiede la stessa verifica, con un ulteriore controllo sulla classificazione del controller. Le linee guida di Purple indicano che le implementazioni attuali su console hardware UniFi e su versioni moderne di UniFi OS Server devono utilizzare l'opzione di integrazione UniFi Network corrente, mentre solo le applicazioni controller standalone meno recenti e non aggiornate utilizzano la selezione legacy. Sulle console hardware, Purple suggerisce di creare l'account dedicato nella dashboard principale di UniFi OS. Se un'implementazione è stata aggiornata, migrata o riclassificata, riesamina la posizione di quell'account e la classificazione dell'integrazione prima di modificare i criteri del firewall per gli ospiti. 3

Le linee guida di supporto di Purple identificano inoltre la raggiungibilità del controller come un confine separato. Se il servizio esterno non riesce a raggiungere il tuo controller al suo indirizzo pubblico stabile o FQDN attraverso il percorso approvato del firewall, l'autorizzazione non può essere completata. Verifica l'indirizzo registrato per l'integrazione, il relativo percorso in entrata e le regole di consenso approvate dal provider. Segui l'articolo di supporto per i passaggi di implementazione correnti e appropriati per la versione, anziché riprodurre i valori di connessione in una checklist locale. 3

Got questions about your specific setup?

Our team works with venue operators, IT managers, and network engineers across 80,000 venues. Book a 20-minute call and we will show you how others like you solved it.

Cosa va storto e come risolvere il problema?

La rete ospite è isolata, ma la pagina di accesso non si avvia mai

Gestisci questo problema come una verifica dello stato dell'Hotspot prima di un incidente DNS. Conferma se l'SSID WiFi o la rete interessata ha la funzione Hotspot e Captive Portal abilitata. Ubiquiti separa esplicitamente una configurazione Hotspot solo WiFi da una configurazione dell'intera rete o VLAN. Ripristina la configurazione desiderata, riconnetti un nuovo dispositivo e conferma che UniFi registri ora un ospite non autorizzato prima di testare qualsiasi collegamento esterno. 1 2

Il reindirizzamento fallisce prima che la pagina esterna venga caricata

Gestisci questo problema come un test del percorso di pre-autorizzazione. Acquisisce il resolver DNS del dispositivo ospite, il risultato della risoluzione di destinazione e l'esito del browser. Successivamente, confronta le regole degli ospiti con i requisiti attuali del provider del portale. Le linee guida di Purple sono specifiche: quando un ospite visualizza una schermata vuota dopo l'invio del modulo, le impostazioni della Pre-Auth ACL o di post-autorizzazione potrebbero bloccare il traffico necessario per completare il processo. Non sostituire una policy di pre-autorizzazione mirata con un ampio accesso internet per gli ospiti. 3

La pagina esterna si carica, ma l'ospite rimane offline

Questo è un limite di autorizzazione. Convalida l'identità del client nell'evento del provider, la richiesta del provider a UniFi e lo stato finale del client del controller. Il flusso esterno di Ubiquiti distingue il reindirizzamento dalla successiva azione di autorizzazione tramite API. Il caricamento di una pagina dimostra che la prima fase è avvenuta, ma non prova che il client sia stato successivamente contrassegnato come autorizzato. 2

Un aggiornamento di UniFi Network o di UDM ha modificato il percorso previsto

Non dare per scontato che una configurazione legacy del controller corrisponda ancora all'integrazione corrente. Purple distingue un moderno deployment UniFi Network da un controller standalone precedente e documenta linee guida separate per la creazione di account per console hardware e UniFi OS Server self-hosted. Verificare nuovamente l'account locale dedicato, la sua autorizzazione di scrittura, lo stato della 2FA, l'impostazione di modifica della password e la classificazione dell'integrazione. Quindi eseguire nuovamente il test con un nuovo dispositivo. 3

Pi-hole o il filtraggio DNS a monte possono bloccare l'hotspot UniFi?

Può far parte dell'analisi, ma non dovrebbe essere la conclusione senza prove. Le fonti primarie approvate non stabiliscono che Pi-hole sia la causa di un errore di reindirizzamento UniFi. Tratta il DNS come un percorso misurabile. Conferma il resolver fornito al segmento guest, verifica se la destinazione del servizio esterno si risolve, testa il percorso DNS approvato sotto controllo delle modifiche e confronta i risultati. Il probe del dispositivo Apple è un altro motivo per registrare sia l'esperienza di accesso automatico sia una normale richiesta del browser. 4

Come si dimostra che la soluzione funziona prima del successivo periodo di punta?

Utilizza una verifica di rilascio ripetibile. Dovrebbe seguire lo stesso percorso di un vero ospite, non un semplice controllo di connettività del solo controller. Per prima cosa, dissocia la rete o utilizza un nuovo dispositivo di test. In secondo luogo, connettiti all'SSID interessato. In terzo luogo, conferma che il client non è autorizzato. In quarto luogo, avvia una normale richiesta web. In quinto luogo, conferma che il servizio esterno riceva il reindirizzamento. In sesto luogo, completa il processo di accesso approvato. In settimo luogo, conferma lo stato authorised: true e testa il normale accesso. 2

Esegui la verifica prima degli arrivi di punta in una struttura del settore Hospitality , prima di un periodo di campagna nel Retail , prima di un evento nei Transport o prima che aumenti la domanda dei visitatori nell' Healthcare . Conserva il risultato come registro operativo: esito positivo o negativo a ogni passaggio, tipo di dispositivo, classificazione del controller ed eventuale modifica applicata. Questo è molto più fruibile rispetto a un generico avviso di "guest WiFi non disponibile".

Scenario di esempio reale: incidente della schermata vuota in un hotel

Un hotel da 200 camere segnala che gli ospiti si collegano all'SSID del brand ma visualizzano una pagina di accesso vuota. L'ingegnere di turno utilizza un nuovo dispositivo e conferma lo stato authorised: false, il che significa che la fase di Hotspot è presente. La pagina inizia a caricarsi ma la transazione non si completa. L'ingegnere confronta i percorsi di pre-autorizzazione guest con le attuali linee guida di supporto del provider, convalida il resolver effettivamente assegnato al segmento guest e ripete il test. La condizione di completamento misurabile è che il dispositivo completi l'accesso, passi a authorised: true e raggiunga l'accesso previsto. 2 3

Scenario di esempio reale: punti vendita retail dopo la modifica del controller

Un team retail segnala che gli acquirenti si connettono a un SSID isolato ma non vedono mai la pagina di accesso dopo una modifica del controller. L'ingegnere non inizia con il DNS. Conferma che il SSID è isolato, quindi verifica se le opzioni Hotspot e Captive Portal sono abilitate nella configurazione UniFi corrente. Dopo aver ripristinato lo stato Hotspot desiderato, riconnette un nuovo dispositivo e verifica lo stato non autorizzato documentato prima di testare il servizio esterno. Il risultato osservabile è un evento di reindirizzamento seguito da uno stato di autorizzazione completato. 1 2

Scenario di esempio reale: guasto dell'autorizzazione esterna in una sede congressuale

La pagina di accesso di una sede congressuale si carica e accetta il modulo ospite, ma i partecipanti rimangono offline. Il team registra l'indirizzo MAC del client e controlla l'evento del provider esterno per il reindirizzamento. Successivamente convalida che il provider abbia riconosciuto lo stesso client, inviato la richiesta di autorizzazione e che UniFi registri authorised: true. Per un'integrazione Purple, verificano anche l'account API locale, i diritti di scrittura, l'impostazione 2FA e la classificazione corrente del controller. Il risultato atteso è una catena di prove tracciabile, non una supposizione sulla causa. 2 3

Una volta chiuso l'incidente, utilizza lo stesso controllo di rilascio nel tuo processo operativo Guest WiFi. La sezione Guest WiFi fornisce il contesto del servizio, mentre WiFi Analytics può aiutare i team operativi a monitorare l'esperienza post-ripristino. Per i controlli operativi adiacenti, consulta Guest WiFi Management: Smart Authentication & Segmentation , Cloud Wifi Management: Secure Enterprise Connectivity 2026 , la guida Cisco Meraki splash page not working: a troubleshooting flowchart e WiFi 7 Venue Deployment: Infrastructure Readiness for Stadiums and Hospitality Sites .

Domande frequenti

Ho bisogno di una VLAN guest e di un UniFi Hotspot per mostrare una pagina di accesso?

No. Ubiquiti documenta un Hotspot sia su un SSID WiFi che su un'intera rete o VLAN. La condizione fondamentale è che il relativo SSID o rete abbia la funzione Hotspot e Captive Portal abilitata. Una VLAN guest isolata è una scelta di segmentazione. Non stabilisce di per sé lo stato di client non autorizzato né avvia un reindirizzamento esterno. 1 2

Cosa dovrebbe essere inserito in una lista di pre-autorizzazione UniFi?

Solo i percorsi necessari per completare il processo di accesso guest selezionato prima dell'approvazione. Purple collega schermate vuote post-modulo a regole guest che bloccano il traffico necessario per completare l'accesso. Verifica l'ACL di pre-autorizzazione e le impostazioni di post-autorizzazione confrontandole con la documentazione attuale del tuo provider. Non copiare un elenco di domini da un altro sito o aggiungere un accesso a internet non protetto solo per caricare la pagina. 3

Perché il portale guest UniFi ha smesso di funzionare dopo un aggiornamento dell'applicazione?

Verifica lo stato dell'Hotspot, la classificazione del controller e l'account di integrazione prima di modificare la rete. La documentazione attuale di Ubiquiti distingue la configurazione dell'Hotspot da una rete guest generale. Purple distingue inoltre le attuali integrazioni di rete UniFi dalle implementazioni con controller autonomi legacy, con linee guida diverse per gli account per console hardware e UniFi OS Server auto-ospitato. Esegui nuovamente il test con un dispositivo pulito dopo ogni correzione. 1 3

Perché un portale esterno si carica sul mio UDM Pro ma non autorizza l'ospite?

Una pagina caricata dimostra la fase di reindirizzamento, non la fase di autorizzazione finale. Verifica che il provider esterno abbia ricevuto l'identità del client, trovato la corrispondenza con il client UniFi, inviato una richiesta di autorizzazione e che il controller mostri authorised: true. Per Purple, verifica anche che l'account locale dedicato disponga dei permessi di scrittura, non abbia la 2FA e non presenti modifiche obbligatorie della password. 2 3

Pi-hole interrompe il reindirizzamento dell'hotspot UniFi?

Non dare per scontato che sia così. Le fonti primarie approvate non identificano Pi-hole come una causa principale comprovata per UniFi. Testa il resolver effettivo del segmento guest, la risoluzione di destinazione e il percorso DNS approvato sotto il controllo delle modifiche. Registra sia la richiesta automatica del dispositivo che il risultato di un normale browser, poiché i dispositivi Apple utilizzano un probe di rete captive quando si connettono. 4

Devo sostituire i miei access point UniFi per risolvere un errore di reindirizzamento?

No, non come prima misura. Il flusso esterno documentato indica una sequenza di passaggi di configurazione e autorizzazione: stato dell'Hotspot, stato del client non autorizzato, reindirizzamento, elaborazione esterna e approvazione del controller. Individua il passaggio non riuscito con un nuovo dispositivo di test prima di considerare una sostituzione hardware. 1 2

Riferimenti

Key Definitions

Captive Portal

The Hotspot sign-in function that controls a guest's access before approval. In UniFi, it is enabled within a Hotspot configuration. [1]

Check it when the guest SSID is present but a fresh device never begins the sign-in flow.

Guest network

A network or VLAN used to separate guest traffic from other network traffic. It is not, by itself, proof that a Captive Portal is active.

Use the distinction to avoid confusing isolation with the external sign-in workflow.

Hotspot

The UniFi feature that can apply to a WiFi SSID or an entire network or VLAN and forms the basis for Captive Portal control. [1]

Verify it first when no fresh guest receives a redirect.

Unauthorised client state

The initial state in Ubiquiti's documented external Hotspot flow, where the guest is marked authorised false. [2]

This is the first controller-side confirmation that the external redirect path should be under test.

Pre-Auth ACL

The UniFi access-control area used to declare routes required before a guest completes the sign-in process. [3]

Review it when a form submission or sign-in hand-off leads to a blank or incomplete page.

External portal server

A third-party service that receives the UniFi redirect and can authorise the guest through the Network API. [2]

It is the boundary to inspect when a guest reaches the sign-in service but does not obtain access.

Controller API account

A dedicated account used by an integration to authenticate to the UniFi controller and change guest access state. Purple requires a local account with write rights and no interactive authentication challenge. [3]

Review it when the external service reaches the controller but cannot approve the guest.

Authorised true

The client state returned after the documented external authorisation process completes. [2]

Use it as a measurable completion point before declaring the incident fixed.

DNS path

The resolver and name-resolution route supplied to the guest segment before access is approved.

Test it as a controlled dependency when the external service destination does not resolve or load from the affected guest segment.

Worked Examples

Representative hotel incident: guests join the branded SSID, but the sign-in screen is blank.

Use a fresh device to confirm the unauthorised guest state. If the state is present but the sign-in process will not complete, compare the actual guest pre-authorisation path with the external provider's current requirements, validate the assigned DNS path, then retest. The acceptance condition is a completed sign-in, authorised true in UniFi and expected access. [2] [3]

Representative retail incident: shoppers connect after a controller change, but no sign-in page appears.

Confirm that the SSID remains a Hotspot with Captive Portal enabled in the current UniFi configuration. Verify the fresh device enters the unauthorised state before diagnosing DNS or the provider. The acceptance condition is a redirect event followed by completed controller authorisation. [1] [2]

Representative conference-venue incident: the external form submits, but attendees remain offline.

Trace the authorisation transaction. Confirm the external provider received the client identity, matched that client, sent the authorisation request and that UniFi shows authorised true. For Purple, review the local API account, write permission, 2FA, password-change setting, controller reachability and classification. [2] [3]

Got questions about your specific setup?

Our team works with venue operators, IT managers, and network engineers across 80,000 venues. Book a 20-minute call and we will show you how others like you solved it.