WebRTC e WebSocket bloccati su *.cloud.wowza.com: guida completa per superare il test video‑streaming (porte 80, 443, 1935) su Windows

Il test di video‑streaming dell’esame online fallisce? Di solito la causa è un blocco delle connessioni WebRTC/WebSocket verso il dominio *.cloud.wowza.com sulle porte 80, 443, 1935. In questa guida trovi una procedura completa, concreta e verificabile per sbloccare il traffico necessario e superare il controllo preliminare.

Indice

Contesto e sintomi

Molti servizi di proctoring remoto usano un backend basato su Wowza Cloud: il browser stabilisce un canale WebRTC per video/audio e uno o più WebSocket per segnalazione e telemetria. Se esiste un filtro di rete (firewall di Windows, antivirus con firewall integrato, proxy/VPN aziendali, software di parental‑control o filtraggio DNS) che blocca o ispeziona queste connessioni, il “video‑streaming test” segnala errori come:

ICE Connection Failed o ICE Disconnected.
WebSocket connection failed / Handshake error.
Timeout nella prova di camera/microfono o flusso video che resta nero.
Messaggi generici di “rete bloccata” solo durante il test, mentre la normale navigazione web funziona.

Il servizio, nello scenario descritto, necessita di comunicare con *.cloud.wowza.com sulle porte TCP 80, TCP 443 e TCP 1935 (quest’ultima storicamente usata dal protocollo RTMP come fallback). Il traffico è in uscita dal tuo PC verso Internet.

Checklist rapida (consigliata)

Passo	Cosa fare	Perché serve
1. Verificare il browser	Usa l’ultima versione di Chrome, Edge o Firefox. Disattiva estensioni che bloccano WebRTC (ad esempio uBlock, Privacy Badger) e qualsiasi estensione “anti‑WebRTC”.	Le estensioni possono impedire la creazione dei canali WebRTC o la lettura dei dispositivi.
2. Controllare firewall/antivirus di terze parti	Disattiva temporaneamente il firewall integrato nell’antivirus oppure crea un’eccezione che consenta traffico in uscita verso `*.cloud.wowza.com` sulle porte `80`, `443`, `1935`.	Questi software spesso intercettano i WebSocket e possono bloccarli o ispezionarli.
3. Configurare Windows Defender Firewall	Metodo GUI: Pannello di controllo → Sistema e sicurezza → Windows Defender Firewall → Impostazioni avanzate → Regole in entrata → Nuova regola (Porta) → TCP 80, 443, 1935 → Consenti connessione → profili necessari → nome alla regola. Nota: il traffico richiesto è in uscita; se nella tua rete le uscite sono ristrette, crea anche una regola analoga in Regole in uscita.	Apre esplicitamente le porte richieste ed evita blocchi locali o criteri restrittivi.
4. Verificare proxy o VPN obbligatori	Se l’esame richiede traffico diretto, disattiva VPN/Proxy o configurali per il passthrough di WebRTC e WebSocket (senza ispezione TLS).	Alcuni proxy non gestiscono correttamente WebSocket “secure” o bloccano UDP/TCP non standard.
5. Escludere problemi di rete domestica	Passa a cavo Ethernet, riavvia modem/router, prova da hotspot mobile per capire se il blocco è a livello di router/ISP.	Aiuta a distinguere un problema del PC da un filtro sull’infrastruttura di rete.
6. Testare la configurazione	Apri `https://test.webrtc.org` e verifica che ICE Connectivity e Data Channels risultino “Succeeded”. Prova anche `https://websocketstest.com`.	Conferma che WebRTC e WebSocket funzionino prima di riprovare l’esame.

Come funziona la connessione e dove può rompersi

Capire i passaggi aiuta a localizzare il blocco:

Segnalazione (signaling): il browser apre un WebSocket (in genere su 443) verso il backend del fornitore (*.cloud.wowza.com) per scambiare le offerte/risposte SDP e i candidati ICE.
Stabilimento dei canali WebRTC: il browser tenta la connettività punto‑punto. In reti restrittive, il traffico “media” può attraversare il server TURN del provider su 443 o 80 come fallback TCP.
Streaming: se tutto va a buon fine, la sessione rimane attiva su canali DTLS/SRTP o (in scenari legacy) su RTMP via 1935.

I blocchi classici avvengono quando:

Un firewall locale impedisce le connessioni del browser su 443/80/1935.
Un proxy con ispezione TLS non supporta l’upgrade a WebSocket o ne sostituisce i certificati, causando errori di handshake.
Un software di sicurezza filtra WebRTC o “anonimizza” gli IP locali rompendo i candidati ICE.
La rete blocca UDP 443 e consente solo HTTP(S) via TCP, costringendo a fallback instabili.

Verifiche sul browser

Aggiornamento e profilo pulito

Aggiorna Chrome/Edge/Firefox all’ultima versione disponibile. Per scartare interferenze di estensioni e cache, usa una finestra in navigazione in incognito con tutte le estensioni disattivate, oppure crea un nuovo profilo temporaneo.

Estensioni che interferiscono

Disattiva estensioni che bloccano WebRTC o manipolano i permessi camera/microfono. Anche i content blocker (uBlock, AdGuard, ecc.) possono impedire l’apertura dei WebSocket ai domini del provider. Dopo le prove, riattiva una alla volta per individuare l’eventuale responsabile.

Diagnostica interna

Chrome/Edge: digita chrome://webrtc-internals o edge://webrtc-internals per leggere log, candidati ICE e stato delle connessioni.
Firefox: digita about:webrtc per statistiche e log.
Policy del browser: in ambienti aziendali verifica chrome://policy/edge://policy per criteri che limitano WebRTC o i WebSocket.

Antivirus e suite di sicurezza

Molte suite includono un firewall e un modulo di ispezione HTTPS. Per test:

Disattiva temporaneamente solo l’ispezione HTTPS e il firewall della suite.
In alternativa crea un’eccezione per il browser (Chrome/Edge/Firefox) che consenta traffico in uscita su 80/443/1935 verso qualsiasi destinazione (o, se possibile, verso *.cloud.wowza.com).
Ripeti il test. Se passa, riattiva i moduli mantenendo l’eccezione esclusivamente per la durata dell’esame.

Buona pratica: evita di disattivare l’intera protezione in tempo reale; limita la deroga al modulo che crea l’incompatibilità.

Windows Defender Firewall: configurazione dettagliata

Windows per impostazione predefinita consente il traffico in uscita. Tuttavia, in PC aziendali o con criteri restrittivi, le uscite possono essere bloccate. Ecco come creare regole mirate e reversibili.

Metodo grafico

Apri: Pannello di controllo → Sistema e sicurezza → Windows Defender Firewall → Impostazioni avanzate.
Seleziona Regole in entrata → Nuova regola… → Porta → TCP → Porti locali specifici: 80,443,1935 → Consenti la connessione → applica ai profili necessari (Privato/Pubblico/Dominio) → dai un nome, ad esempio “Wowza In TCP 80‑443‑1935”.
Importante: se il tuo profilo blocca le uscite, crea anche la corrispondente regola in Regole in uscita con gli stessi parametri e nome “Wowza Out TCP 80‑443‑1935”.
Se preferisci legare la regola al programma (più sicuro), crea una nuova regola di tipo Programma puntando a chrome.exe, msedge.exe o firefox.exe, e limita ai protocolli/porte richieste.

Metodo PowerShell (amministratore)

Crea regole in uscita per Chrome (ripeti per Edge/Firefox sostituendo il percorso del programma):

# Percorsi predefiniti (verifica sul tuo PC)
$Chrome = "C:\Program Files\Google\Chrome\Application\chrome.exe"

Regole OUT per Wowza sulle porte richieste

New-NetFirewallRule -DisplayName "Wowza Out TCP 443 (Chrome)" -Direction Outbound -Action Allow -Program $Chrome -Protocol TCP -RemotePort 443
New-NetFirewallRule -DisplayName "Wowza Out TCP 80 (Chrome)"  -Direction Outbound -Action Allow -Program $Chrome -Protocol TCP -RemotePort 80
New-NetFirewallRule -DisplayName "Wowza Out TCP 1935 (Chrome)" -Direction Outbound -Action Allow -Program $Chrome -Protocol TCP -RemotePort 1935

Regole IN (di solito non necessarie, ma utili se ci sono criteri molto restrittivi)

New-NetFirewallRule -DisplayName "Wowza In TCP 443 (Chrome)" -Direction Inbound -Action Allow -Program $Chrome -Protocol TCP -LocalPort 443
New-NetFirewallRule -DisplayName "Wowza In TCP 80 (Chrome)"  -Direction Inbound -Action Allow -Program $Chrome -Protocol TCP -LocalPort 80
New-NetFirewallRule -DisplayName "Wowza In TCP 1935 (Chrome)" -Direction Inbound -Action Allow -Program $Chrome -Protocol TCP -LocalPort 1935

Per rimuovere le regole dopo l'esame:

Get-NetFirewallRule | Where-Object DisplayName -like "Wowza *" | Remove-NetFirewallRule

Nota: le regole per programma sono più sicure di quelle “globali” per porta, perché limitano la deroga all’app necessaria. Windows Firewall non consente di filtrare direttamente per FQDN dalle proprietà standard della regola; per questo, in scenari casalinghi, la strategia “per programma” è il miglior compromesso tra sicurezza e funzionalità.

Proxy, VPN e reti aziendali

Se usi una VPN aziendale o il PC carica le impostazioni proxy via PAC/Group Policy, la connessione può attraversare componenti che:

non supportano correttamente l’HTTP Upgrade richiesto dai WebSocket;
impongono l’ispezione TLS, sostituendo certificati e rompendo l’handshake;
bloccano 1935 per policy;
filtrano UDP 443 o impediscono connessioni dirette richieste da WebRTC.

Azioni consigliate (scegline una o più, in base alle policy locali):

Disattiva la VPN/proxy durante l’esame se le policy lo consentono; in alternativa usa il profilo split‑tunnel con esclusione di *.cloud.wowza.com.
Chiedi all’amministratore di escludere dall’ispezione TLS il dominio *.cloud.wowza.com e di consentire i WebSocket su 443.
Se esiste un proxy autenticato, verifica che il browser lo usi correttamente (le finestre in incognito possono usare profili diversi).

Su Windows, controlla rapidamente le impostazioni proxy in Impostazioni → Rete e Internet → Proxy. Se vedi un script PAC, è probabile che il traffico passi dal proxy aziendale: in quel caso serve un’esclusione amministrativa.

Rete domestica: cosa verificare

Usa cavo Ethernet durante l’esame per evitare jitter e perdita di pacchetti che possono far fallire la fase ICE.
Riavvia modem/router per ripulire NAT e cache di DNS.
Prova un hotspot 4G/5G: se funziona da cellulare, il blocco è sul router domestico o sull’ISP.
DNS: se usi DNS con filtro famiglia/sicurezza, disabilita temporaneamente la protezione o crea un’eccezione per il dominio richiesto.

Strumenti di test e diagnosi

Prima di ripetere il test dell’esame, verifica i mattoni di base:

https://test.webrtc.org: deve indicare “Succeeded” per ICE Connectivity e Data Channel.
https://websocketstest.com: verifica che il socket si apra con successo sia in ws che in wss (se previsto dal test).

Comandi utili su Windows

# Verifica connettività TCP verso le porte richieste
Test-NetConnection cloud.wowza.com -Port 443
Test-NetConnection cloud.wowza.com -Port 80
Test-NetConnection cloud.wowza.com -Port 1935

Controlla la reachability DNS e il percorso (utile se c'è un proxy/ISP che filtra)

nslookup cloud.wowza.com
tracert cloud.wowza.com

Pulisci cache DNS locale e resetta lo stack Winsock

ipconfig /flushdns
netsh winsock reset

Controlla rapidamente lo stato dell'ora di sistema (TLS richiede orario corretto)

w32tm /query /status

Interpretazione rapida:

Se Test-NetConnection su 443/80 restituisce TcpTestSucceeded: True ma il test WebRTC fallisce, sospetta un’ispezione TLS o un blocco specifico dei WebSocket.
Se falliscono sia 443 che 80, è probabile un firewall in uscita o un proxy obbligatorio che rifiuta connessioni dirette.
Se fallisce 1935 ma passano 80/443, il servizio potrebbe comunque funzionare grazie ai fallback; prova il test dell’esame.

Risoluzione dei casi più comuni

Errore WebSocket durante l’handshake

Cause: antivirus con ispezione HTTPS, proxy che non supporta l’upgrade, certificati sostituiti. Soluzioni:

Escludi *.cloud.wowza.com dall’ispezione TLS nel filtro HTTPS o disattiva temporaneamente il modulo.
Se c’è un proxy forward, assicurati che il browser lo utilizzi e che sia abilitato il supporto WebSocket.
Controlla l’orario di sistema (differenze >5 minuti possono far fallire TLS).

ICE failed / impossibile stabilire i canali WebRTC

Cause: rete che blocca UDP o NAT restrittivo; estensioni che “oscurano” gli IP locali; firewall aziendale che consente solo HTTP via proxy. Soluzioni:

Disattiva estensioni “anti‑WebRTC”.
Usa rete cablata o hotspot mobile; se con hotspot funziona, chiedi al tuo ISP/IT lo sblocco o l’uso di un profilo di rete senza filtri.
Assicurati che almeno TCP 443 diretto sia consentito: molti servizi TURN camuffano il traffico su 443 per attraversare i filtri.

RTMP su 1935 bloccato

Alcune reti bloccano esplicitamente 1935. Se il test fallisce solo per questa porta ma il servizio supporta fallback WebRTC su 443, potresti riuscire comunque a sostenere l’esame. In caso contrario, chiedi un’eccezione esplicita al tuo amministratore.

Sicurezza e buone pratiche

Limita le aperture al tempo strettamente necessario, rimuovendo le regole firewall al termine.
Preferisci regole per programma rispetto a regole globali per porta.
Evita whitelist generiche su “tutto il traffico uscente”: mantieni l’eccezione mirata a 80/443/1935.
Se usi un PC aziendale, non forzare modifiche non consentite: richiedi una deroga formale via IT (spesso tramite GPO).

Procedura guidata completa

Chiudi tutte le app che usano camera/microfono (Teams, Zoom, OBS) per evitare conflitti.
Aggiorna il browser e avvia una finestra in incognito senza estensioni.
Controlla l’orario e sincronizzalo se non è esatto.
Pulisci DNS/Winsock con i comandi indicati sopra e riavvia il PC.
Configura Windows Defender Firewall (GUI o PowerShell) come descritto, aggiungendo almeno le regole in uscita per il browser.
Disabilita temporaneamente l’ispezione HTTPS e il firewall della suite antivirus oppure crea le eccezioni mirate.
Controlla proxy/VPN: se presenti, disattivali o configura lo split‑tunnel/esclusioni per *.cloud.wowza.com.
Prova su rete alternativa (hotspot) per escludere problemi del router/ISP.
Esegui i test: test.webrtc.org deve risultare “Succeeded” nelle voci principali; websocketstest.com deve aprire la connessione.
Riprova il test dell’esame. Se supera la verifica, ripristina le protezioni non indispensabili lasciando solo le eccezioni necessarie durante l’esame.

Domande frequenti

Devo davvero aprire le “Regole in entrata”?

Per la maggior parte degli utenti no, perché la connessione è in uscita. Tuttavia, in ambienti bloccati o con firewall personalizzati, creare anche la regola in entrata evita interazioni impreviste. L’opzione più sensata resta una regola in uscita per programma sul browser.

Posso limitare l’eccezione al solo dominio `*.cloud.wowza.com`?

Windows Defender Firewall non consente un filtro FQDN comodo dall’interfaccia standard delle regole; alcuni prodotti di terze parti sì. Per questo si preferisce legare la regola al programma e alla/e porta/e.

Il mio ISP applica filtri “famiglia”: possono interferire?

Sì. I filtri DNS/HTTP famiglia possono bloccare le WebSocket sicure o le chiamate WebRTC. Disattivali per la durata dell’esame o crea un profilo senza filtri.

Dopo l’esame voglio ripristinare tutto: come faccio?

Se hai creato regole con il prefisso “Wowza …”, esegui:

Get-NetFirewallRule | Where-Object DisplayName -like "Wowza *" | Remove-NetFirewallRule

Suggerimenti aggiuntivi

Diritti di amministratore: alcune modifiche (nuove regole firewall) richiedono un account amministratore.
PC aziendale/rete scolastica: contatta l’amministratore; potrebbero esserci GPO che sovrascrivono le regole locali.
Cache e certificati: svuota la cache DNS (ipconfig /flushdns) e verifica l’orologio di sistema; TLS sui WebSocket può fallire se l’orario è errato.
Fallback logistico: se nulla funziona, chiedi all’ente dell’esame un’alternativa (client desktop dedicato o sede con rete dedicata).

Riepilogo operativo

Per superare il test di video‑streaming del proctoring:

Usa un browser aggiornato e senza estensioni che interferiscono.
Consenti dal firewall in uscita le porte 80, 443, 1935 per il browser.
Evita ispezioni TLS e proxy che non supportano i WebSocket.
Verifica con test.webrtc.org e websocketstest.com prima di tornare al portale dell’esame.

Seguendo questi passaggi, elimini i blocchi che impediscono la connessione al servizio di streaming e permetti il superamento del test preliminare dell’esame online.

Appendice: esempio di policy minima “a tempo” per un esame

Se devi sostenere un esame in una finestra oraria precisa e il tuo ambiente è molto restrittivo, prepara uno script che:

crei le regole in uscita per il browser sulle porte 80/443/1935;
disattivi temporaneamente l’ispezione HTTPS nel tuo antivirus;
ripristini automaticamente lo stato originale al termine.

Un semplice promemoria testuale da tenere sul desktop può essere sufficiente; evita automatismi invasivi se non necessari.

Appendice: interpretare i log di webrtc‑internals

candidate pair state: succeeded: connettività OK; eventuali blocchi residui sono a livello di applicazione (WebSocket, autorizzazioni camera/microfono).
iceConnectionState: failed: blocco a livello di rete; prova hotspot o chiedi sblocco.
setRemoteDescription error / DTLS failure: ispezione TLS o certificati “rompighiaccio”; controlla antivirus e proxy.

Appendice: controlli di base sull’hardware

Concedi i permessi di camera e microfono al browser.
Chiudi software che monopolizzano la webcam.
Usa cuffie per ridurre l’eco (alcuni sistemi di proctoring lo richiedono).

Conclusione — Un test di video‑streaming che fallisce raramente dipende dall’hardware: nella maggior parte dei casi è un tema di rete. Con pochi interventi mirati su browser, firewall di Windows, eventuale antivirus/firewall di terze parti e impostazioni proxy/VPN, puoi ristabilire le connessioni WebRTC/WebSocket verso *.cloud.wowza.com su 80, 443, 1935 e tornare a sostenere l’esame senza intoppi.

Buono studio e in bocca al lupo per l’esame!