Perché il tuo cloud privato funziona con il Wi-Fi ma non con i dati mobili?

Una cloud privata può funzionare perfettamente su Wi-Fi di casa e comunque fallire sui dati mobili. Questo di solito non significa che l'app della cloud privata sia rotta. Significa che il telefono sta usando un percorso di rete diverso.

A casa, il telefono può raggiungere un indirizzo IP locale, un nome host locale o un servizio di scoperta solo LAN. Su dati mobili, il telefono deve raggiungere la cloud privata tramite un dominio pubblico, IP pubblico, VPN, tunnel o altro percorso di accesso remoto. Se DNS, routing, certificati, domini attendibili, regole firewall o comportamento del carrier sono errati, il Wi-Fi funziona mentre i dati mobili falliscono.

Wi-Fi e dati mobili raggiungono la tua cloud privata in modi diversi

Il sintomo è familiare: l'app della cloud privata funziona su Wi-Fi di casa, il backup foto procede normalmente, la sincronizzazione file si connette e l'interfaccia web si apre dal telefono. Poi passi a 5G o LTE e vedi timeout, impossibile connettersi, login fallito, errore certificato o un'app che continua a caricare.

Su Wi-Fi, il telefono e la cloud privata sono nella stessa LAN. La connessione può usare un indirizzo locale come 192.168.1.50, un nome host locale o una scoperta automatica. Su dati mobili, il telefono è sulla rete del carrier. Deve raggiungere il server di casa tramite un percorso remoto, non lo stesso percorso locale.

Il successo su Wi-Fi dimostra solo che il percorso locale funziona. Il fallimento sui dati mobili significa che il percorso esterno manca, è bloccato, configurato male o incompatibile con la rete mobile. La risoluzione dei problemi dovrebbe separare l'accesso interno da quello esterno invece di considerarli come un'unica connessione.

L'app potrebbe usare un indirizzo locale che funziona solo a casa

La causa più comune è anche la più semplice. L'app della cloud privata potrebbe essere salvata con un URL come http://192.168.1.50:8080, https://cloud.local, https://nas.local, o un nome dispositivo assegnato dal router. Quegli indirizzi possono funzionare a casa e non funzionare altrove.

Gli intervalli IPv4 privati come 10.x.x.x, 172.16–31.x.x e 192.168.x.x sono destinati a reti private. Un indirizzo privato solo locale non è una destinazione pubblica su internet, quindi il tuo telefono non può raggiungerlo direttamente mentre è connesso ai dati mobili.

Se l'app mobile utilizza un URL solo LAN, non iniziare modificando a caso le impostazioni del firewall. Prima decidi se l'accesso mobile deve usare un dominio pubblico, una VPN o mesh VPN, o un tunnel. Senza uno di questi percorsi, il telefono sta cercando di raggiungere un indirizzo che esiste solo all'interno della tua casa.

URL Interno e URL Esterno Spesso Vengono Confusi

Molte configurazioni di cloud privato finiscono con due identità. L’URL interno funziona a casa, ad esempio http://192.168.1.50:8080. L’URL esterno dovrebbe funzionare dall’esterno, ad esempio https://cloud.example.com o un hostname di tunnel.

Questi due nomi possono puntare allo stesso servizio, ma non rappresentano lo stesso design di accesso. L’URL interno può usare un IP privato, DNS locale o un certificato autofirmato. L’URL esterno può richiedere DNS pubblico, HTTPS, un reverse proxy, port forwarding, routing VPN o un tunnel.

I problemi si presentano quando segnalibri, app mobili, client di sincronizzazione e scorciatoie del browser mescolano queste identità. Per i dati mobili, usa l’URL esterno se il servizio deve essere raggiungibile dall’esterno. Se vuoi mantenere tutto privato, connettiti prima tramite VPN e poi usa l’indirizzo LAN.

Il DNS può risolversi correttamente in Wi-Fi ma fallire su rete cellulare

Un dominio può funzionare a casa e fallire con i dati mobili perché il telefono interroga un sistema DNS diverso. A casa, il tuo router, Pi-hole, AdGuard Home o server DNS locale possono risolvere cloud.example.com a un IP interno. Con i dati mobili, il DNS dell’operatore o il DNS pubblico possono restituire una risposta diversa o nessuna risposta.

Questo è comune nelle configurazioni split DNS. All’interno della LAN, il dominio punta all’indirizzo privato per velocità e semplicità. Fuori dalla LAN, deve puntare a un IP pubblico, un nome accessibile via VPN o un endpoint di tunnel. Se il record esterno manca o è obsoleto, il telefono non riesce a trovare il servizio.

Non dare per scontato che un dominio sia corretto solo perché funziona in Wi-Fi. Prova lo stesso dominio con dati mobili e conferma dove si risolve. Se i risultati DNS interni ed esterni sono intenzionalmente diversi, documenta quel design in modo che le impostazioni dell’app non usino accidentalmente il nome sbagliato.

Domini Attendibili, URL Base e Reverse Proxy Possono Bloccare l’Accesso Mobile

A volte la richiesta mobile raggiunge il server, ma l’app continua a non funzionare. Potresti vedere un avviso di dominio non attendibile, errore host non valido, fallimento del login, loop di reindirizzamento o un problema di sincronizzazione WebDAV. Questo di solito significa che il percorso ha raggiunto il cloud privato, ma l’applicazione non si fida del nome o delle intestazioni proxy ricevute.

Il software per cloud privato spesso necessita di impostazioni esplicite per hostname e URL. Il riferimento alla configurazione di Nextcloud include impostazioni di dominio attendibile e URL base, e la sua documentazione sul reverse proxy copre il rilevamento URL del reverse proxy quando il rilevamento automatico di hostname, protocollo o webroot fallisce.

Se i dati mobili caricano la pagina di login ma il login, i reindirizzamenti, la sincronizzazione o i link di condivisione falliscono, controlla la configurazione dell'app. Il nome host esterno dovrebbe essere attendibile, l'URL pubblico dovrebbe corrispondere a quello inserito dagli utenti, le intestazioni proxy dovrebbero essere corrette e i reindirizzamenti da HTTP a HTTPS non dovrebbero riportare l'app a un indirizzo LAN privato.

I certificati HTTPS Spesso Rivelano un Progetto di Accesso Errato

L'accesso Wi-Fi può funzionare con un certificato autofirmato, un nome host interno o un avviso del browser che hai accettato manualmente mesi fa. Le app mobili possono essere più severe, specialmente quando sincronizzano file, foto, calendari o dati WebDAV in background.

I certificati HTTPS sono legati ai nomi. Se l'app si connette a 192.168.1.50, cloud.local, o un nome host diverso da quello del certificato, i client mobili possono rifiutare la connessione. Se un reverse proxy cambia in modo errato il nome host o il protocollo, l'app può anche fallire dopo il login.

Una configurazione esterna pulita usa un dominio pubblico stabile con un certificato valido e una configurazione di reverse proxy corrispondente. Una configurazione privata pulita usa prima VPN o mesh VPN, poi accesso interno. Mescolare indirizzi IP, nomi locali, nomi pubblici e certificati non corrispondenti rende l'accesso mobile inaffidabile.

Port Forwarding, VPN o Tunnel Devono Fornire il Percorso Mobile

Una cloud privata non diventa automaticamente raggiungibile dai dati mobili solo perché funziona con il Wi-Fi. Il traffico esterno necessita di un percorso intenzionale verso la rete domestica o verso l'endpoint del servizio.

Ci sono tre schemi comuni. Il port forwarding invia traffico pubblico specifico attraverso il router alla cloud privata. Una VPN o mesh VPN permette al telefono di unirsi prima a una rete privata. Un reverse tunnel consente al server di creare una connessione in uscita a un endpoint pubblico, poi i dispositivi mobili si connettono tramite quell'endpoint.

Per l'accesso a una cloud privata personale, VPN o mesh VPN sono solitamente la scelta più sicura iniziale. Per condividere un servizio direttamente con altri, un dominio pubblico con HTTPS, reverse proxy e un controllo accessi attento può essere appropriato. Per CGNAT o router bloccati, un tunnel può essere più pratico del port forwarding.

Il CGNAT può far sembrare corretto il port forwarding ma farlo comunque fallire

Il CGNAT è frustrante perché la configurazione domestica può sembrare corretta. Il cloud privato funziona con il Wi-Fi. Il firewall del server permette la porta. Il router ha una regola di inoltro. Ma i dati mobili non riescono comunque a raggiungere il servizio.

Il problema è che il tuo router potrebbe non avere un vero indirizzo IPv4 pubblico. RFC 6598 riserva 100.64.0.0/10 come spazio indirizzi condiviso usato per CGNAT. Quando il tuo ISP mette il router dietro un carrier-grade NAT, il traffico esterno potrebbe non raggiungere mai il router di casa, quindi la regola di port forwarding non ha nulla da inoltrare.

Confronta l’IP WAN mostrato dal tuo router con l’IP pubblico mostrato da un sito esterno di verifica IP. Se non corrispondono, o se l’indirizzo WAN è in range condivisi o privati, il port forwarding classico probabilmente non è la soluzione giusta. Usa un’opzione IP pubblica dall’ISP, una VPN mesh o un tunnel inverso.

Le reti mobili possono aggiungere problemi IPv6 e specifici dell’operatore

Alcuni problemi si presentano solo con i dati mobili. Lo stesso cloud privato può funzionare da un’altra rete Wi-Fi ma fallire su 5G o LTE. Oppure un operatore funziona mentre un altro no. Questo indica un problema oltre il router di casa.

Le reti mobili possono usare design solo IPv6, NAT64, CGNAT, DNS dell’operatore, politiche APN, filtri o proxy. Le indicazioni Apple su compatibilità rete mobile solo IPv6 ricordano che le reti mobili potrebbero non comportarsi come una LAN domestica dual-stack normale, specialmente se un’app o server presume un comportamento solo IPv4.

Se il problema si presenta solo con i dati mobili, prova più soluzioni. Usa lo stesso URL in un browser mobile, prova un altro operatore o hotspot, verifica i record DNS A e AAAA, conferma se il server supporta la famiglia di indirizzi usata e prova una VPN sui dati mobili. Se la VPN funziona, probabilmente il cloud privato è a posto; il problema è il percorso mobile pubblico.

Le app mobili possono comportarsi diversamente dai browser

Un browser su telefono e un'app mobile non si comportano sempre allo stesso modo. Il browser può aprire la pagina di login, mentre l'app non riesce a sincronizzarsi. Oppure l'app può funzionare con il Wi-Fi perché scopre il server localmente, ma fallire con i dati mobili perché la scoperta non è più disponibile.

Le app mobili possono memorizzare nella cache un vecchio URL del server, richiedere HTTPS, rifiutare certificati non corrispondenti, usare un endpoint WebDAV o API diverso dalla pagina del browser, limitare i dati in background o gestire i reindirizzamenti in modo differente. Alcune app memorizzano anche indirizzi server interni ed esterni separati senza renderlo evidente.

Testa sempre entrambi i percorsi. Apri l'URL esterno nel browser del telefono mentre sei con i dati mobili, poi prova l'app. Se anche il browser fallisce, il problema è probabilmente DNS, routing, TLS, CGNAT o configurazione del tunnel. Se il browser funziona ma l'app no, concentra l'attenzione sulle impostazioni URL dell'app, domini attendibili, certificati, percorsi WebDAV/API e cache dell'app.

VPN o Mesh VPN Risolvono Spesso il Problema Ripristinando il Percorso LAN

Se il cloud privato funziona su Wi-Fi ma non con i dati mobili, una VPN può essere una soluzione pulita perché cambia la posizione del telefono. Invece di raggiungere il cloud privato come un client esterno casuale, il telefono si unisce prima a una rete privata.

Gli strumenti Mesh VPN possono usare percorsi diretti o di relay a seconda delle reti coinvolte. Tailscale documenta l'accesso privato tramite connessioni dirette o relay, un contesto utile quando un dispositivo mobile deve raggiungere un server domestico senza esporre direttamente il cloud privato a internet.

Per l'accesso personale, questo è solitamente il modello meno confuso. L'app può usare l'indirizzo LAN interno o un nome DNS privato dopo che la VPN è connessa. Il cloud privato rimane fuori da internet aperto e il dispositivo mobile si autentica prima di raggiungere i servizi interni.

I Tunnel Inversi Sono Utili Quando Hai Bisogno di un URL Esterno Senza Aprire Porte

Un tunnel inverso è utile quando non puoi o non vuoi aprire porte in ingresso sul tuo router. Questo è comune con CGNAT, router ISP bloccati, internet in appartamento o utenti che preferiscono non esporre direttamente il router di casa.

Cloudflare Tunnel utilizza un tunnel in uscita per accesso remoto, dove il connettore all'interno della tua rete avvia la connessione verso l'esterno. I dispositivi mobili accedono quindi a un nome host pubblico che instrada il traffico attraverso il tunnel.

Questo può facilitare l'accesso ai dati mobili, ma deve comunque essere configurato con attenzione. Usa politiche di accesso, HTTPS, esposizione limitata dei servizi e separa le interfacce di amministrazione dai servizi pubblici rivolti agli utenti. Un tunnel risolve la raggiungibilità; non risolve automaticamente i permessi o la configurazione dell'app.

Un ordine pratico per la risoluzione dei problemi

Questo problema diventa complicato quando DNS, regole del router, certificati, impostazioni dell’app e reti mobili vengono modificati tutti insieme. Un approccio migliore è testare un livello alla volta.

Inizia scrivendo l’URL esatto che funziona su Wi-Fi. Decidi se è un IP privato, un nome host locale o un dominio pubblico. Poi disattiva il Wi-Fi e testa lo stesso URL su dati mobili. Successivamente, testa il dominio pubblico previsto, controlla il DNS pubblico, confronta l’IP WAN del router con l’IP pubblico, conferma se stai usando port forwarding, VPN o tunnel, quindi verifica il certificato TLS e le impostazioni del dominio attendibile.

Il risultato di solito indica il livello. Se browser e app falliscono entrambi, concentrati su DNS, percorso pubblico, CGNAT, certificato o tunnel. Se il browser funziona ma l’app fallisce, concentrati sulla configurazione dell’app, domini attendibili, endpoint WebDAV/API, reindirizzamenti e URL server memorizzati nella cache. Se la VPN su dati mobili funziona, il cloud privato è sano; il problema è il percorso esterno.

L’impostazione predefinita più sicura è un unico modello chiaro di accesso remoto

L’accesso al cloud privato diventa inaffidabile quando ci sono troppi ingressi a metà funzionanti: un IP LAN, un nome host locale, un nome DDNS, un URL di tunnel, un vecchio URL dell’app, un nome host di reverse proxy e un segnalibro che nessuno ricorda di aver creato.

Scegli un modello principale. Per l’accesso personale, locale più VPN è spesso la soluzione più pulita. Per l’accesso diretto all’app dall’esterno, usa un dominio pubblico unico, HTTPS valido, impostazioni corrette di dominio attendibile e un reverse proxy o tunnel sicuro. Per CGNAT, usa un tunnel o una VPN mesh invece di combattere con il port forwarding.

Meno punti di accesso mantieni, più semplice diventa la configurazione del telefono. Un cloud privato non dovrebbe richiedere un URL misterioso diverso per ogni rete. Nomi stabili, certificati corrispondenti e un metodo di accesso chiaro sono ciò che fa comportare in modo coerente Wi-Fi e dati mobili.

Conclusione finale

Se il tuo cloud privato funziona con il Wi-Fi ma fallisce con i dati mobili, il cloud privato stesso potrebbe essere a posto. Il Wi-Fi usa un percorso locale. I dati mobili necessitano di un percorso remoto. Il fallimento è solitamente causato da un URL solo locale, disallineamento DNS, mancanza di port forwarding, VPN o tunnel, CGNAT, disallineamento del certificato TLS, configurazione del dominio attendibile, comportamento IPv6/IPv4 o differenze nell'app mobile.

Inizia controllando quale URL usa l'app, se quell'URL è locale o pubblico, se il DNS pubblico risolve, se il router ha un IP pubblico reale e se HTTPS e domini attendibili corrispondono al nome esterno. Per accesso personale, VPN o mesh VPN sono di solito la soluzione più pulita. Per accesso esterno diretto, usa un dominio pubblico coerente, certificato valido e un percorso attentamente protetto.

Un affidabile private cloud NAS può ospitare file, foto, sincronizzazioni, backup e servizi di accesso remoto, ma l'accesso con dati mobili dipende comunque dal percorso di rete, dominio, certificato e configurazione dell'app.

FAQ

Perché il mio cloud privato funziona con il Wi-Fi ma non con i dati mobili?

Il Wi-Fi usa la tua rete locale, dove indirizzi IP privati e nomi host locali possono funzionare. I dati mobili usano la rete dell'operatore, quindi serve un dominio pubblico, VPN, tunnel o un altro percorso di accesso esterno.

Posso usare 192.168.x.x con i dati mobili?

No. Un 192.168.x.x L'indirizzo è privato e funziona solo all'interno della tua rete locale. Per usarlo con i dati mobili, connettiti prima alla rete di casa tramite VPN o mesh VPN.

Perché il mio dominio funziona a casa ma non su rete cellulare?

Il Wi-Fi di casa potrebbe usare un DNS locale che punta il dominio a un IP privato. Sul cellulare, il telefono usa DNS pubblico o dell'operatore, che potrebbe non avere lo stesso record o puntare all'endpoint sbagliato.

Perché il browser funziona ma l'app mobile no?

L'app potrebbe usare un'API o un percorso WebDAV diverso, memorizzare in cache un URL vecchio, richiedere un dominio attendibile, rifiutare un certificato o gestire i reindirizzamenti diversamente dal browser.

CGNAT influisce sull'accesso al cloud privato dai dati mobili?

Sì. Se il tuo ISP domestico usa CGNAT, il port forwarding potrebbe non raggiungere mai il router. In tal caso, usa un'opzione IP pubblico, VPN/mesh VPN o un tunnel inverso.

IPv6 può causare problemi di accesso con i dati mobili?

Può esserlo. Alcune reti mobili usano percorsi solo IPv6 o preferiscono IPv6. Se il tuo dominio, app o server domestico è solo IPv4 o ha record DNS errati, i dati mobili possono comportarsi diversamente dal Wi-Fi.

La VPN è meglio che aprire porte per un cloud privato?

Per l'accesso personale, di solito sì. VPN o mesh VPN mantengono il cloud privato fuori da internet aperto e permettono ai dispositivi attendibili di accedervi come se fossero sulla LAN di casa.

Cosa dovrei controllare prima?

Controlla l'URL salvato nell'app. Se è un IP locale o .local hostname, non funzionerà con i dati mobili a meno che non usi una VPN. Poi controlla DNS pubblico, CGNAT, HTTPS, domini attendibili e impostazioni dell'app.