Jak naprawić błąd „Odmowa połączenia” w aplikacji mobilnej ownCloud

Komunikat „Połączenie odrzucone” w aplikacji mobilnej ownCloud zazwyczaj wskazuje na problem z łącznością jeszcze przed rozpoczęciem uwierzytelniania: telefon dotarł do adresu, ale żaden z użytkowników nie zaakceptował połączenia na żądanym punkcie końcowym sieci. Dokładne brzmienie komunikatu może się różnić w zależności od wersji Androida lub iOS, dlatego należy traktować go jako objaw, a nie diagnozę.

Scenariusz poglądowy: wyobraź sobie małą firmę projektową o nazwie Northstar Studio. Jej pracownicy zazwyczaj łączą się https://cloud.example.com/owncloudz aplikacją mobilną ownCloud. Po zmianie odwrotnego proxy na kilku telefonach pojawia się komunikat „Odmowa połączenia”. Interfejs internetowy ownCloud nadal działa na laptopie administratora w biurze, ale nie działa w przypadku transmisji danych komórkowych. Ten fikcyjny scenariusz będzie wykorzystywany w całym przewodniku, aby pokazać, jak kroki rozwiązywania problemów są ze sobą powiązane; nie jest to raport z rzeczywistego wdrożenia ani wynik testu.

Po pierwsze, oddziel „odmowę połączenia” od błędów logowania

Nie zaczynaj od resetowania hasła użytkownika. Nieprawidłowe hasło, wygasły token lub problem z OAuth występują po tym, jak klient będzie mógł komunikować się z serwerem. Odrzucone połączenie TCP jest najczęściej związane z niewłaściwym hostem lub portem, zatrzymanym serwerem WWW lub proxy, regułą zapory sieciowej lub usługą nasłuchującą tylko na interfejsie wewnętrznym.

Aktualna dokumentacja mobilna ownCloud potwierdza, że ​​aplikacje są skonfigurowane z adresem URL serwera ownCloud. Dokumentacja ownCloud WebDAV również stwierdza, że ​​aplikacje mobilne powinny używać bazowego adresu URL i folderu, takiego jak example.com/owncloud, zamiast ręcznego wprowadzania punktu końcowego WebDAV. Zapoznaj się z dokumentacją dostępu ownCloud WebDAV .

1. Zweryfikuj adres URL w aplikacji mobilnej

W przykładzie Northstar oczekiwany adres URL to https://cloud.example.com/owncloud. Sprawdź wszystkie cztery komponenty: schemat, nazwę hosta, opcjonalny port i ścieżkę. Typowe błędy to: użycie, http://gdy usługa publiczna nasłuchuje tylko przez HTTPS, pominięcie niestandardowego portu, użycie wewnętrznej nazwy hosta, której nie można rozwiązać poza biurem, lub wpisanie punktu końcowego DAV zamiast podstawowego adresu URL ownCloud.

Dokumentacja Androida informuje, że aplikacja testuje połączenie po wprowadzeniu adresu URL serwera i danych logowania oraz zaleca serwer z włączonym protokołem SSL, aby połączenie mogło korzystać z protokołu HTTPS. Dokumentacja iOS również sprawdza adres URL serwera, metodę uwierzytelniania i certyfikat TLS podczas dodawania konta. Zapoznaj się z przewodnikiem połączenia ownCloud na Androidzie oraz przewodnikiem konta ownCloud na iOS .

2. Przetestuj ten sam adres URL poza aplikacją

Na telefonie z problemem otwórz dokładny adres URL ownCloud w przeglądarce. To szybka linia podziału. Jeśli przeglądarka może załadować stronę ownCloud, ale aplikacja nie, sprawdź certyfikat specyficzny dla aplikacji, przekierowanie, OAuth lub konfigurację konta. Jeśli zarówno przeglądarka, jak i aplikacja nie działają w tej samej sieci, kontynuuj sprawdzanie serwera i sieci.

Przetestuj również w więcej niż jednej sieci. W naszym przykładowym przypadku Northstar, Wi-Fi w biurze działa, ale transmisja danych komórkowych nie działa. Wskazuje to na problem z publicznym DNS, zaporą sieciową, NAT lub odwrotnym proxy, a nie na problem z nazwą użytkownika ownCloud.

3. Potwierdź, że publiczny punkt końcowy faktycznie nasłuchuje

Z komputera, który ma dostęp do serwera, przetestuj adres URL i gniazdo nasłuchujące. Polecenia takie jak poniższe będą przydatnym punktem wyjścia:

curl -I https://cloud.example.com/owncloud
sudo ss -tlnp | grep -E ':80|:443'

Pomyślna odpowiedź HTTP nie musi być 200; przekierowanie może również udowodnić, że usługa sieciowa odpowiada. Istotnym rozróżnieniem jest to, czy połączenie TCP zostało zaakceptowane. Jeśli nic nie nasłuchuje na oczekiwanym porcie publicznym, należy to naprawić przed zmianą ustawień aplikacji OwnCloud.

4. Sprawdź serwer WWW lub odwrotny serwer proxy

Wiele wdrożeń ownCloud umieszcza serwery proxy Apache, NGINX, HAProxy, Traefik lub inne przed aplikacją. Upewnij się, że usługa publiczna jest uruchomiona, powiązana z docelowym interfejsem i przekierowuje ruch do rzeczywistego zaplecza ownCloud. Serwer proxy, który jest zatrzymany, powiązany tylko z [usługą] 127.0.0.1lub skonfigurowany dla niewłaściwego portu upstream, może spowodować natychmiastową odmowę.

Własna chmura dokumentuje serwery proxy odwrotne w sposób jawny i wymaga, aby adresy serwerów proxy, którym ownCloud powinien ufać, były skonfigurowane w [link] trusted_proxies. Dokumentuje również ustawienia nadpisywania w przypadku, gdy automatyczne wykrywanie nazwy hosta, protokołu lub katalogu głównego za serwerem proxy nie powiedzie się. Zobacz przewodnik konfiguracji serwera proxy odwrotnego ownCloud .

5. Sprawdź zaporę sieciową, NAT i ścieżkę sieciową

Jeśli protokół HTTPS działa na samym serwerze, ale nie działa z telefonu spoza sieci LAN, sprawdź zaporę hosta, grupę zabezpieczeń w chmurze, router lub regułę NAT oraz każdą firmową zaporę sieciową nadrzędną. W przypadku standardowego wdrożenia HTTPS port TCP 443 musi być dostępny pod adresem publicznym. Jeśli celowo używasz niestandardowego portu, ten konkretny port musi zostać ujawniony i uwzględniony w adresie URL.

Nie wyłączaj zapory sieciowej na stałe. Zamiast tego zidentyfikuj wymaganego odbiorcę i zezwól tylko na ruch, którego potrzebuje Twój projekt. W scenariuszu Northstar przydatne pytanie nie brzmi: „Czy zapora sieciowa jest włączona?”, ale: „Czy zewnętrzny klient może dotrzeć do adresu i portu opublikowanego dla ownCloud?”.

6. Sprawdź certyfikaty TLS i przekierowania po osiągnięciu portu

Problem z certyfikatem różni się od dosłownego odrzucenia TCP, ale często pojawia się natychmiast po naprawieniu problemu z dostępnością. Aktualna dokumentacja systemu iOS podaje, że aplikacja sprawdza certyfikaty TLS podczas dodawania serwera i umożliwia użytkownikowi wgląd w szczegóły certyfikatu. Dokumentacja systemu Android opisuje również ostrzeżenia dotyczące certyfikatów, których nie można zweryfikować.

W miarę możliwości używaj certyfikatu, którego nazwa hosta jest zgodna z publiczną nazwą hosta ownCloud i którego łańcuch jest zaufany przez urządzenie. Sprawdź również przekierowania HTTP-HTTPS. Dokumentacja bezpieczeństwa iOS informuje, że przekierowania podczas logowania nie są automatycznie wykonywane; użytkownicy są proszeni o ich zatwierdzenie. Zobacz dokumentację bezpieczeństwa ownCloud iOS .

7. Potwierdź zaufane domeny ownCloud i obsługę adresów URL serwera proxy

Gdy serwer WWW zaakceptuje połączenia, sprawdź, czy ownCloud rozpoznaje nazwę hosta używaną przez telefon. ownCloud wymaga, aby adresy URL używane do dostępu do serwera były dozwolone trusted_domains. Ma to znaczenie, gdy wprowadzasz nową publiczną nazwę hosta, migrujesz usługę lub udostępniasz wcześniejszą instalację wewnętrzną.

W przypadku instalacji klasycznej, zamiast edytować ją bezmyślnie, sprawdź konfigurację. occAby odczytać skonfigurowane domeny, możesz użyć:

sudo -u www-data ./occ config:system:get trusted_domains

Jeśli brakuje publicznej nazwy hosta, dodaj ją, używając udokumentowanej occ config:system:setskładni dla nieużywanego indeksu tablicy. Oficjalny opis poleceń jest dostępny w dokumentacji poleceń ownCloud occ . W przypadku wdrożeń kontenerowych, aktualna dokumentacja ownCloud udostępnia równoważne ustawienia związane z domeną i serwerem proxy za pośrednictwem zmiennych środowiskowych, takich jak OWNCLOUD_TRUSTED_DOMAINSi OWNCLOUD_TRUSTED_PROXIES.

8. Wykonaj test ponownie z oryginalnego telefonu i porównaj wyniki

Wróć do uszkodzonego urządzenia i przetestuj w kontrolowanej kolejności: najpierw wczytaj adres URL w przeglądarce, następnie dodaj lub ponownie połącz konto ownCloud, a następnie otwórz widok Pliki i sprawdź, czy pojawia się lista katalogów. Powtórz raz dla Wi-Fi i raz dla danych mobilnych, jeśli usługa ma działać w obu sieciach.

W przykładzie Northstar załóżmy, że administrator odkrył, że zastępczy serwer proxy odwrotny nasłuchiwał na porcie 443 tylko na interfejsie prywatnym. Prawidłowe powiązanie publicznego nasłuchiwacza wyjaśniłoby, dlaczego dostęp do biura działał, podczas gdy dostęp komórkowy był odrzucany. To tylko ilustracja procesu rozumowania, a nie stwierdzenie dotyczące rzeczywistego incydentu w OwnCloud.

Szybka tabela diagnostyczna

Czego nie zmieniać w pierwszej kolejności

Unikaj zmiany haseł, ustawień bazy danych, uprawnień do plików lub limitów pamięci PHP tylko dlatego, że aplikacja mobilna wyświetla komunikat „Połączenie odrzucone”. Te ustawienia mogą mieć znaczenie w przypadku innych awarii ownCloud, ale nie są one pierwszym miejscem do sprawdzenia, gdy klient w ogóle nie może nawiązać połączenia sieciowego. Podobnie, nie pomijaj trwale ostrzeżeń dotyczących certyfikatów zamiast naprawiania publicznej konfiguracji TLS.

Ostateczna lista kontrolna weryfikacji

• Telefon korzysta z docelowego adresu URL ownCloud, w tym prawidłowego schematu, nazwy hosta, ścieżki i niestandardowego portu, jeśli ma to zastosowanie.
• Nazwa hosta jest poprawnie rozpoznawana w sieci, do której podłączony jest telefon.
• Publiczny serwer WWW lub odwrotny serwer proxy nasłuchuje na oczekiwanym porcie TCP.
• Host, chmura, router i zapory sieciowe zezwalają na zamierzony ruch.
• Serwer proxy odwrotny może połączyć się z zapleczem ownCloud.
• Certyfikat TLS jest odpowiedni dla publicznej nazwy hosta i akceptowany przez urządzenie.
• Nazwa hosta jest obecna w konfiguracji zaufanej domeny ownCloud.
• Zarówno interfejs internetowy, jak i aplikacja mobilna działają w każdej sieci, którą wdrożenie ma obsługiwać.

Od października 2026 roku ownCloud publikuje aktualną dokumentację dla swojego serwera Classic oraz oddzielnych klientów mobilnych na Androida i iOS. Dokładne etykiety i ekrany mogą się zmieniać w zależności od wersji aplikacji, dlatego należy stosować powyższą kolejność rozwiązywania problemów jako metodę trwałą: najpierw sprawdź dostępność sieci, następnie zweryfikuj działanie proxy i TLS, a dopiero potem przejdź do aplikacji ownCloud i ustawień uwierzytelniania.