Un mesaj „Conexiune refuzată” în aplicația mobilă ownCloud indică de obicei o problemă de conectivitate înainte ca autentificarea să înceapă: telefonul a ajuns la o adresă, dar nimic nu a acceptat conexiunea pe punctul final al rețelei solicitate. Formularea exactă poate varia în funcție de versiunea de Android sau iOS, așa că tratați mesajul ca pe un simptom, mai degrabă decât ca pe un diagnostic.
Doar un scenariu ilustrativ: imaginați-vă o mică companie de design numită Northstar Studio. Personalul său se conectează în mod normal https://cloud.example.com/owncloudprin aplicația mobilă ownCloud. După o modificare a proxy-ului invers, mai multe telefoane raportează mesajul „Conexiune refuzată”. Interfața web ownCloud funcționează în continuare de pe laptopul unui administrator din birou, dar nu și din datele mobile. Acest scenariu fictiv va fi utilizat pe tot parcursul ghidului pentru a arăta cum se îmbină pașii de depanare; nu este un raport al unei implementări sau al unui rezultat al unui test real.
Nu începeți prin a reseta parola utilizatorului. O parolă greșită, un token expirat sau o problemă OAuth apar după ce clientul poate comunica cu serverul. O conexiune TCP refuzată este asociată mai frecvent cu o gazdă sau un port greșit, un server web sau un proxy oprit, o regulă de firewall sau un serviciu care ascultă doar pe o interfață internă.
Documentația mobilă actuală a ownCloud confirmă faptul că aplicațiile sunt configurate cu adresa URL a serverului ownCloud. Documentația ownCloud WebDAV precizează, de asemenea, că aplicațiile mobile ar trebui să utilizeze adresa URL de bază și folderul, cum ar fi example.com/owncloud, în loc să introducă manual un punct final WebDAV. Consultați documentația de acces ownCloud WebDAV .
În exemplul Northstar, adresa URL așteptată este https://cloud.example.com/owncloud. Verificați toate cele patru componente: schema, numele gazdei, portul opțional și calea. Greșelile frecvente includ utilizarea http://atunci când serviciul public ascultă doar pe HTTPS, omiterea unui port non-standard, utilizarea unui nume de gazdă intern care nu poate fi rezolvat în afara biroului sau introducerea unui endpoint DAV în loc de adresa URL de bază ownCloud.
Documentația Android precizează că aplicația testează conexiunea după introducerea adresei URL a serverului și a acreditărilor și recomandă un server compatibil SSL, astfel încât conexiunea să poată utiliza HTTPS. Documentația iOS verifică în mod similar adresa URL a serverului, metoda de autentificare și certificatul TLS la adăugarea unui cont. Consultați ghidul de conectare ownCloud Android și ghidul contului ownCloud iOS .
Pe telefonul afectat, deschideți adresa URL exactă ownCloud într-un browser. Aceasta este o linie de demarcație rapidă. Dacă browserul poate încărca pagina ownCloud, dar aplicația nu, investigați certificatul specific aplicației, redirecționarea, OAuth sau configurația contului. Dacă atât browserul, cât și aplicația eșuează în aceeași rețea, continuați cu verificările serverului și rețelei.
Testați și din mai multe rețele. În cazul nostru ilustrativ, Northstar, Wi-Fi-ul de la birou funcționează, dar datele celulare eșuează. Acest lucru indică o problemă de expunere DNS public, firewall, NAT sau reverse-proxy, mai degrabă decât o problemă cu numele de utilizator ownCloud.
De pe o mașină care poate accesa serverul, testați URL-ul și socket-ul de ascultare. Comenzi precum următoarele sunt puncte de plecare utile:
curl -I https://cloud.example.com/owncloud
sudo ss -tlnp | grep -E ':80|:443'Un răspuns HTTP reușit nu trebuie neapărat să fie 200; o redirecționare poate dovedi, de asemenea, că un serviciu web răspunde. Distincția importantă este dacă o conexiune TCP este acceptată. Dacă nimic nu ascultă pe portul public așteptat, remediați acest lucru înainte de a modifica setările aplicației ownCloud.
Multe implementări ownCloud plasează Apache, NGINX, HAProxy, Traefik sau un alt proxy în fața aplicației. Asigurați-vă că serviciul orientat spre public rulează, este legat de interfața dorită și redirecționează traficul către backend-ul ownCloud propriu-zis. Un proxy oprit, legat doar la 127.0.0.1sau configurat pentru portul upstream greșit poate produce un refuz imediat.
ownCloud documentează explicit proxy-urile inverse și necesită configurarea adreselor proxy în care ownCloud ar trebui să aibă încredere trusted_proxies. De asemenea, documentează setările de suprascriere pentru cazurile în care detectarea automată a numelui de gazdă, a protocolului sau a webroot-ului eșuează în spatele unui proxy. Consultați ghidul de configurare a proxy-ului invers de la ownCloud .
Dacă HTTPS funcționează chiar pe server, dar nu de pe un telefon din afara rețelei locale (LAN), verificați firewall-ul gazdă, grupul de securitate în cloud, routerul sau regula NAT și orice firewall corporativ din amonte. Pentru o implementare HTTPS normală, TCP 443 trebuie să fie accesibil la adresa publică. Dacă utilizați intenționat un port personalizat, exact acel port trebuie expus și inclus în URL.
Nu dezactivați un firewall ca soluție permanentă. În schimb, identificați listener-ul necesar și permiteți doar traficul de care are nevoie designul. În scenariul Northstar, întrebarea utilă nu este „Este firewall-ul activat?”, ci „Poate un client extern să acceseze adresa și portul publicate pentru ownCloud?”.
O problemă cu certificatul este diferită de un refuz literal al protocolului TCP, dar apare adesea imediat după ce remediați accesibilitatea. Documentația actuală a iOS precizează că aplicația verifică certificatele TLS atunci când adaugă un server și permite utilizatorului să inspecteze detaliile certificatului. Documentația Android descrie, de asemenea, avertismente pentru certificatele care nu pot fi verificate.
Folosiți un certificat al cărui nume de gazdă corespunde cu numele public de gazdă ownCloud și al cărui lanț este considerat de încredere de către dispozitiv ori de câte ori este posibil. De asemenea, consultați redirecționările HTTP-to-HTTPS. Documentația de securitate iOS menționează că redirecționările în timpul autentificării nu sunt urmate silențios; utilizatorii sunt rugați să le aprobe. Consultați documentația de securitate ownCloud iOS .
După ce serverul web acceptă conexiuni, verificați dacă ownCloud recunoaște numele de gazdă utilizat de telefon. ownCloud necesită ca adresele URL utilizate pentru accesarea serverului să fie permise trusted_domains. Acest lucru este important atunci când introduceți un nou nume de gazdă public, migrați serviciul sau expuneți o instalare internă anterioară.
Pentru o instalare clasică, inspectați configurația în loc să o editați orbește. Puteți folosi occpentru a citi domeniile configurate:
sudo -u www-data ./occ config:system:get trusted_domainsDacă numele public de gazdă lipsește, adăugați-l folosind occ config:system:setsintaxa documentată pentru un index de matrice neutilizat. Referința oficială a comenzii este disponibilă în documentația comenzii ownCloud occ . Pentru implementările de containere, documentația actuală ownCloud expune setări echivalente legate de domeniu și proxy prin variabile de mediu, cum ar fi OWNCLOUD_TRUSTED_DOMAINSși OWNCLOUD_TRUSTED_PROXIES.
Reveniți la dispozitivul afectat și testați într-o secvență controlată: încărcați mai întâi adresa URL în browser, apoi adăugați sau reconectați contul ownCloud, apoi deschideți vizualizarea Fișiere și confirmați că apare o listă de directoare. Repetați o dată pe Wi-Fi și o dată pe date mobile dacă serviciul este destinat să funcționeze din ambele.
În exemplul Northstar, să presupunem că administratorul descoperă că proxy-ul invers de înlocuire asculta pe portul 443 doar pe interfața privată. Legarea corectă a listenerului public ar explica de ce accesul la birou a funcționat în timp ce accesul celular a fost refuzat. Aceasta este doar o ilustrare a procesului de raționament, nu o afirmație despre un incident real ownCloud.
| Ceea ce observi | Cea mai utilă verificare următoare |
|---|---|
| Aplicația și browserul telefonului sunt refuzate | Nume de gazdă public, port, ascultător, firewall, NAT, serviciu proxy |
| Funcționează prin Wi-Fi, dar nu prin date mobile | DNS public și cale firewall/NAT/proxy orientată spre internet |
| Browserul funcționează, aplicația se oprește la verificarea certificatului | Nume de gazdă TLS, lanț de certificate, redirecționări |
| Serverul răspunde, dar ownCloud respinge gazda. | trusted_domainsși setările de suprascriere a proxy-ului invers |
| Conexiunea reușește, dar autentificarea eșuează | Acreditări, OAuth2, autentificare cu doi factori sau politică privind tokenurile |
Evitați să modificați parolele, setările bazei de date, permisiunile fișierelor sau limitele de memorie PHP doar pentru că aplicația mobilă afișează mesajul „Conexiune refuzată”. Aceste setări pot fi importante pentru alte erori ownCloud, dar nu reprezintă primul loc de investigat atunci când clientul nu poate stabili deloc o conexiune la rețea. De asemenea, nu ocoliți permanent avertismentele privind certificatele ca înlocuitor pentru remedierea unei configurații TLS publice.
Începând cu octombrie 2026, ownCloud publică documentația actuală pentru serverul său Classic și pentru clienții mobili separați Android și iOS. Etichetele și ecranele exacte se pot schimba între versiunile aplicației, așadar folosiți ordinea de depanare de mai sus ca metodă durabilă: demonstrați mai întâi accesibilitatea rețelei, apoi validați comportamentul proxy și TLS și abia apoi treceți la setările aplicației și de autentificare ownCloud.
Comparați 10 instrumente de scanare ping pentru descoperirea rapidă a rețelelor LAN, scanarea multi-platformă și gestionarea adreselor IP. Aflați ce vă poate spune o scanare (sweep).
Comparați șase instrumente de gestionare a rețelei pentru monitorizarea performanței, inclusiv acoperirea SNMP, maparea, alertele, modelele de implementare și compromisurile de costuri.
Aflați ce înseamnă QoS în rețele, cum marcajele DSCP și cozile de trafic prioritizează aplicațiile vocale, video și de business și ce nu poate remedia QoS.
Compară software-ul de server SFTP fiabil pentru Windows și Linux, inclusiv OpenSSH, Bitvise, SolarWinds și SFTPGo. Găsește soluția potrivită pentru nevoile tale de securitate și transfer de fișiere.
Construiți o monitorizare practică a rețelei cu o acoperire clară a dispozitivelor, indicatori de performanță utili, alerte acționabile și o comparație între SolarWinds NPM, PRTG și OpManager.
Comparați șapte instrumente de gestionare a adreselor IP pentru descoperirea subrețelelor, coordonarea DNS și DHCP, inventarul rețelei și IPAM open-source.
Comparați instrumentele de scanare a rețelei pentru descoperirea rapidă a dispozitivelor, scanări IP pe mai multe platforme și IPAM pentru întreprinderi, cu îndrumări privind potrivirea fiecărei opțiuni la rețeaua dvs.
Folosește opțiunea --traceroute din Nmap pentru a mapa salturi la o gazdă autorizată, a înțelege ieșirea saltului și a RTT-ului și a depana răspunsurile lipsă fără a suprascana.
Comparați șase instrumente de monitorizare Windows Server în funcție de colectarea datelor Windows, vizibilitatea aplicațiilor, modelul de implementare și licențierea pentru a găsi instrumentul potrivit.
Comparați șase instrumente de monitorizare a rețelei Linux pentru descoperirea dispozitivelor SNMP, grafice de interfață, metrici gazdă, verificări de servicii și fluxuri de trafic.
