Il messaggio "Connessione rifiutata" nell'app mobile ownCloud di solito indica un problema di connettività prima ancora che inizi l'autenticazione: il telefono ha raggiunto un indirizzo, ma nessun dispositivo ha accettato la connessione sull'endpoint di rete richiesto. La formulazione esatta può variare a seconda della versione di Android o iOS, quindi è bene considerare il messaggio come un sintomo piuttosto che come una diagnosi.
Scenario puramente illustrativo: immaginiamo una piccola azienda di design chiamata Northstar Studio. Il suo personale si connette normalmente tramite https://cloud.example.com/owncloudl'app mobile ownCloud. Dopo una modifica del reverse proxy, diversi telefoni segnalano "Connessione rifiutata". L'interfaccia web di ownCloud funziona ancora dal laptop di un amministratore in ufficio, ma non tramite connessione dati cellulare. Questo scenario fittizio verrà utilizzato in tutta la guida per mostrare come si integrano i passaggi per la risoluzione dei problemi; non si tratta di una descrizione di un'implementazione reale o di un risultato di test.
Non iniziare reimpostando la password dell'utente. Una password errata, un token scaduto o un problema OAuth si verificano dopo che il client è in grado di comunicare con il server. Una connessione TCP rifiutata è più comunemente associata a host o porta errati, server web o proxy arrestati, una regola del firewall o un servizio in ascolto solo su un'interfaccia interna.
La documentazione attuale di ownCloud per dispositivi mobili conferma che le app sono configurate con l'URL del server ownCloud. La documentazione WebDAV di ownCloud afferma inoltre che le app per dispositivi mobili dovrebbero utilizzare l'URL e la cartella di base, ad esempio example.com/owncloud, anziché inserire manualmente un endpoint WebDAV. Consultare la documentazione sull'accesso WebDAV di ownCloud .
Nell'esempio di Northstar, l'URL previsto è https://cloud.example.com/owncloud. Verifica tutti e quattro i componenti: schema, nome host, porta facoltativa e percorso. Gli errori comuni includono l'utilizzo http://di quando il servizio pubblico è in ascolto solo su HTTPS, l'omissione di una porta non standard, l'utilizzo di un nome host interno che non può essere risolto al di fuori dell'ufficio o l'inserimento di un endpoint DAV invece dell'URL di base di ownCloud.
La documentazione per Android afferma che l'app verifica la connessione dopo l'inserimento dell'URL del server e delle credenziali, e consiglia un server con SSL abilitato in modo che la connessione possa utilizzare HTTPS. Analogamente, la documentazione per iOS verifica l'URL del server, il metodo di autenticazione e il certificato TLS durante l'aggiunta di un account. Consultare la guida alla connessione di ownCloud per Android e la guida all'account ownCloud per iOS .
Sul telefono interessato, apri l'URL esatto di ownCloud in un browser. Questo è un punto di svolta cruciale. Se il browser riesce a caricare la pagina di ownCloud ma l'app no, verifica il certificato specifico dell'app, il reindirizzamento, l'autenticazione OAuth o la configurazione dell'account. Se sia il browser che l'app non riescono a caricare la pagina sulla stessa rete, procedi con i controlli del server e della rete.
Eseguite i test anche da più di una rete. Nel nostro caso esemplificativo Northstar, il Wi-Fi dell'ufficio funziona, ma la connessione dati cellulare non funziona. Questo indica un problema di esposizione a DNS pubblico, firewall, NAT o reverse proxy, piuttosto che un problema con il nome utente di ownCloud.
Da una macchina in grado di raggiungere il server, testa l'URL e il socket di ascolto. Comandi come i seguenti possono essere un buon punto di partenza:
curl -I https://cloud.example.com/owncloud
sudo ss -tlnp | grep -E ':80|:443'Una risposta HTTP di successo non è necessariamente tale 200; anche un reindirizzamento può dimostrare che un servizio web sta rispondendo. La distinzione importante sta nel fatto che una connessione TCP venga accettata o meno. Se nessun servizio è in ascolto sulla porta pubblica prevista, è necessario risolvere questo problema prima di modificare le impostazioni dell'applicazione ownCloud.
Molte implementazioni di ownCloud posizionano Apache, NGINX, HAProxy, Traefik o un altro proxy davanti all'applicazione. Assicurati che il servizio accessibile pubblicamente sia in esecuzione, associato all'interfaccia prevista e che inoltri il traffico al backend di ownCloud. Un proxy arrestato, associato solo a 127.0.0.1, o configurato per la porta upstream errata può causare un rifiuto immediato.
La documentazione di ownCloud descrive esplicitamente i proxy inversi e richiede che gli indirizzi proxy di cui ownCloud deve fidarsi siano configurati in trusted_proxies. Documenta inoltre le impostazioni di sovrascrittura per i casi in cui il rilevamento automatico del nome host, del protocollo o della directory principale del sito web non riesce dietro un proxy. Consultare la guida alla configurazione del proxy inverso di ownCloud .
Se HTTPS funziona sul server stesso ma non da un telefono esterno alla LAN, verificare il firewall dell'host, il gruppo di sicurezza cloud, il router o la regola NAT e qualsiasi firewall aziendale a monte. Per una normale implementazione HTTPS, la porta TCP 443 deve essere raggiungibile all'indirizzo pubblico. Se si utilizza intenzionalmente una porta personalizzata, tale porta deve essere esposta e inclusa nell'URL.
Non disabilitare il firewall come soluzione definitiva. Piuttosto, identifica il listener necessario e consenti solo il traffico richiesto dalla tua configurazione. Nello scenario Northstar, la domanda utile non è "Il firewall è attivo?" ma "Un client esterno può raggiungere l'indirizzo e la porta pubblicati per ownCloud?".
Un problema con il certificato è diverso da un rifiuto TCP letterale, ma spesso si presenta subito dopo aver risolto un problema di raggiungibilità. La documentazione iOS attuale afferma che l'app verifica i certificati TLS quando si aggiunge un server e consente all'utente di esaminare i dettagli del certificato. Anche la documentazione Android descrive gli avvisi relativi ai certificati che non possono essere verificati.
Quando possibile, utilizza un certificato il cui nome host corrisponda al nome host pubblico di ownCloud e la cui catena di certificati sia considerata attendibile dal dispositivo. Verifica inoltre i reindirizzamenti da HTTP a HTTPS. La documentazione sulla sicurezza di iOS indica che i reindirizzamenti durante l'accesso non vengono eseguiti automaticamente; agli utenti viene richiesto di approvarli. Consulta la documentazione sulla sicurezza di ownCloud per iOS .
Una volta che il server web accetta le connessioni, verifica che ownCloud riconosca il nome host utilizzato dal telefono. ownCloud richiede che gli URL utilizzati per accedere al server siano consentiti trusted_domains. Questo è importante quando introduci un nuovo nome host pubblico, migri il servizio o esponi un'installazione precedentemente interna.
Per un'installazione classica, esamina la configurazione anziché modificarla alla cieca. Puoi utilizzare questo strumento occper leggere i domini configurati:
sudo -u www-data ./occ config:system:get trusted_domainsSe il nome host pubblico non è presente, aggiungerlo utilizzando la occ config:system:setsintassi documentata per un indice di array non utilizzato. Il riferimento ufficiale al comando è disponibile nella documentazione del comando ownCloud occ . Per le distribuzioni in container, la documentazione attuale di ownCloud espone impostazioni equivalenti relative al dominio e al proxy tramite variabili d'ambiente come OWNCLOUD_TRUSTED_DOMAINSe OWNCLOUD_TRUSTED_PROXIES.
Torna al dispositivo interessato ed esegui un test in sequenza controllata: prima carica l'URL nel browser, poi aggiungi o riconnetti l'account ownCloud, quindi apri la visualizzazione File e verifica che venga visualizzato l'elenco delle directory. Ripeti l'operazione una volta tramite Wi-Fi e una volta tramite dati mobili, se il servizio deve funzionare in entrambi i modi.
Nell'esempio di Northstar, supponiamo che l'amministratore scopra che il proxy inverso sostitutivo era in ascolto sulla porta 443 solo sull'interfaccia privata. Associare correttamente il listener pubblico spiegherebbe perché l'accesso all'ufficio funzionava mentre l'accesso cellulare veniva negato. Questa è solo un'illustrazione del processo di ragionamento, non un'affermazione su un incidente reale di ownCloud.
| Ciò che osservi | Controllo successivo più utile |
|---|---|
| L'app e il browser del telefono sono entrambi rifiutati | Nome host pubblico, porta, listener, firewall, NAT, servizio proxy |
| Funziona tramite Wi-Fi ma non tramite dati mobili. | DNS pubblico e percorso firewall/NAT/proxy esposto a Internet |
| Il browser funziona, l'applicazione si blocca durante la verifica del certificato. | Nome host TLS, catena di certificati, reindirizzamenti |
| Il server risponde ma ownCloud rifiuta l'host | trusted_domainse impostazioni di sovrascrittura del proxy inverso |
| La connessione è riuscita, ma l'accesso non è riuscito. | Credenziali, OAuth2, autenticazione a due fattori o policy dei token |
Evitate di modificare password, impostazioni del database, permessi dei file o limiti di memoria PHP solo perché l'app mobile segnala "Connessione rifiutata". Queste impostazioni potrebbero essere rilevanti per altri errori di ownCloud, ma non sono la prima cosa da controllare quando il client non riesce a stabilire una connessione di rete. Allo stesso modo, non ignorate in modo permanente gli avvisi relativi ai certificati come alternativa alla correzione di una configurazione TLS pubblica.
A partire da ottobre 2026, ownCloud pubblica la documentazione aggiornata per il suo server Classic e per i client mobili Android e iOS separati. Le etichette e le schermate esatte possono cambiare tra le diverse versioni dell'app, quindi si consiglia di seguire la procedura di risoluzione dei problemi descritta sopra come metodo affidabile: verificare prima la raggiungibilità della rete, poi convalidare il comportamento del proxy e del TLS e solo successivamente passare alle impostazioni dell'applicazione ownCloud e all'autenticazione.
Confronta sei server e collettori syslog gratuiti per Windows e Linux, inclusi strumenti con interfaccia grafica, opzioni open source, funzionalità di ricerca, avvisi e trasporto sicuro.
Scopri cosa fa Microsoft IIS, come funzionano la sua pipeline di richieste e i pool di applicazioni e quando Apache, NGINX o Caddy potrebbero essere più adatti alle tue esigenze di server web.
Diagnostica i picchi di utilizzo della CPU del browser Jitsi Meet e riduci il carico del client controllando i riquadri video, gli effetti della fotocamera, la grafica del browser e le impostazioni dell'host.
Monitora lo stato di salute, il carico della conferenza e il traffico di Jitsi Videobridge con il suo endpoint Prometheus integrato, quindi esplora e visualizza i dati in Grafana.
Configura un dominio personalizzato per Jitsi Meet Docker con DNS, URL pubblico, HTTPS, Let's Encrypt, porte del firewall, impostazioni NAT e verifica end-to-end.
Fix Zimbra Admin Console 404 errors after SSL renewal by checking the correct URL and port, proxy routing, service status, deployed certificates, and logs.
Scopri come diagnosticare e risolvere l'avviso di configurazione di PHP OPcache di Nextcloud controllando l'SAPI PHP attivo, i limiti di dimensionamento, i commenti e le impostazioni di riconvalida.
Risolvere i problemi di migrazione del database Kopano dopo un aggiornamento di MySQL o MariaDB verificando i backup, le versioni del server, le modalità SQL, il set di caratteri, lo stato dello schema e i log.
Collega Nextcloud a LDAP o Active Directory con trasporto sicuro, filtri per utenti e gruppi, attributi di accesso e un'implementazione collaudata.
Risolvi i problemi di notifiche di Element Android sui telefoni senza Google configurando UnifiedPush, le autorizzazioni Android, le impostazioni della batteria ed eseguendo test di verifica affidabili.
