Fix ONLYOFFICE Mobile App Connection Timeouts to a Self-Hosted Server

You enter your self-hosted server in ONLYOFFICE Documents, tap Next, and the app spins until it reports a connection timeout. The same account may still work in a desktop browser, which makes the problem look like an app bug. In practice, the timeout usually means the phone cannot reach the exact service URL you entered, the URL points to the wrong ONLYOFFICE component, or a network layer blocks the request.

Start by identifying what your server actually provides. The Documents mobile app connects to an ONLYOFFICE portal such as DocSpace or Workspace, or to a supported third-party cloud such as Nextcloud, ownCloud, or another WebDAV service. ONLYOFFICE Docs, also called Document Server, is the editing service that works with a storage platform; it is not automatically the same thing as a user portal or WebDAV file account. ONLYOFFICE’s Android Documents overview and iOS Documents overview describe the supported account types.

1. Confirm which address the mobile app should use

Do not paste the Document Server URL into every connection field. If your files are stored in a self-hosted DocSpace or Workspace portal, use that portal’s public address and sign in with the portal account. If your files are in Nextcloud or ownCloud, choose that service in the app and enter the storage server’s WebDAV address with its account credentials. For a generic WebDAV service, select the app’s “Other WebDAV” option where available.

For Nextcloud and ownCloud, the URL can include a path beyond the domain. Copy the WebDAV address shown in the cloud account’s settings rather than guessing a path from an old tutorial. ONLYOFFICE’s mobile connection guide gives a Nextcloud example and directs users to paste the full URL, including the protocol. The app’s Android instructions likewise say to provide the connection URL, login, and password for WebDAV storage. See the official Nextcloud integration guide or ownCloud integration guide for the current connection flow.

• Use the portal URL for a portal account, not the editor service address.
• Use the complete WebDAV URL for Nextcloud, ownCloud, or another WebDAV account.
• Include https:// or http:// exactly as configured on the server.
• Do not add an unverified suffix such as /webdav or /remote.php/dav; copy the server’s displayed WebDAV URL.

2. Test the same address outside the app

On the phone, open the address in a mobile browser. For a portal URL, the expected result is a sign-in page or a redirect to the portal. For a WebDAV endpoint, the browser may show a sign-in prompt, an authorization response, or a plain error rather than a normal website; the important point is that it responds promptly and the browser does not report that the host cannot be found or reached.

Repeat the test once on Wi-Fi and once over mobile data. If it works on one network only, the app is probably not the first place to troubleshoot. Check the router, VPN, DNS filtering, mobile carrier restrictions, or firewall policy on the failing network. If it fails on both, confirm that the hostname resolves publicly and that the reverse proxy or firewall forwards the service’s HTTPS traffic to the intended backend.

A server that is reachable only through a private address such as 192.168.x.x will normally be unavailable when the phone is away from that local network unless the device is connected through a VPN or another secure remote-access setup. Do not expose an internal service to the public internet simply to test the app; use the organization’s approved remote-access method.

3. Check the URL, redirects, and reverse proxy

Compare the address in the app with the address that works in the browser, character by character. Look for a missing subdirectory, an old hostname, an incorrect port, a trailing path copied from a different service, or a redirect to an internal hostname that the phone cannot resolve. If your server is behind a reverse proxy, the public URL should route to the correct application, and forwarded scheme and host information should be consistent with the HTTPS address users access.

When a portal or WebDAV service is published under a subpath, verify that the proxy preserves the required path and forwards requests to that application. A root URL that displays a reverse-proxy welcome page only proves that the web server answered; it does not prove that the app’s portal or WebDAV endpoint is routed correctly. If possible, test the precise URL copied into the mobile app rather than only the domain homepage.

If the app reports a timeout but the browser reaches a login page quickly, check proxy access and error logs at the time of a fresh connection attempt. A 502 or 504 response points toward an upstream or proxy timeout; a 404 usually suggests a path or routing mismatch; a 401 or 403 indicates that the endpoint answered but authentication or access was denied. These status codes narrow the investigation, but the meaning can depend on the proxy and cloud software in front of ONLYOFFICE.

4. Validate HTTPS and the certificate chain

Mobile operating systems validate server certificates. A certificate that is expired, issued for a different hostname, missing an intermediate certificate, or signed by an authority the device does not trust can prevent a secure connection. Open the exact HTTPS address on the phone and inspect any browser certificate warning. Also check that the device date and time are correct, because an incorrect clock can make a valid certificate appear expired or not yet valid.

Use a certificate issued for the public hostname and install the full certificate chain on the public-facing proxy or server. ONLYOFFICE’s documentation describes configuring HTTPS for Document Server; the certificate must match the URL clients use. Avoid disabling certificate verification as a permanent fix. ONLYOFFICE describes that option as insecure in its integration documentation, and a connection that works only after bypassing certificate checks still needs a correct certificate configuration.

5. Separate an app sign-in problem from an editor connection problem

A user may sign into a portal successfully and still have trouble opening a document. These are separate connections. The app first needs to reach the storage or portal. When opening a file, the integration may also involve the Document Server. A working mobile sign-in therefore does not prove that the editor service can reach the storage server, or that the storage server can reach the editor.

If the timeout appears only after opening a file, ask the administrator to test the integration from the server side. ONLYOFFICE’s Nextcloud and ownCloud guides explain that installations behind restricted networks may need internal addresses configured for requests from the storage server to ONLYOFFICE Docs and from ONLYOFFICE Docs back to the storage service. The public addresses can work in a phone browser while server-to-server traffic still fails.

For an administrator, check that both services resolve each other’s configured hostnames, that firewall rules allow the required traffic, and that the connector uses the same JWT secret configured for Document Server when JWT is enabled. Do not change the secret or disable JWT as a guess; first compare the configured values using the official integration guide for your cloud platform.

6. Recheck credentials and app state

After confirming reachability and certificates, verify the username and password in the web interface for the same portal or storage account. A WebDAV endpoint may require the account’s actual credentials or an app password, depending on the server’s authentication policy. If multi-factor authentication is enabled, follow the instructions for that server; do not assume the normal web login password is accepted by every WebDAV implementation.

Update ONLYOFFICE Documents from the official app store, close and reopen it, then try adding the account again. If the account was previously saved with an incorrect address, remove that saved connection and create a fresh one with the verified URL. This does not delete files on the server: disconnecting a cloud account in the mobile app removes the local connection entry, not the remote storage contents. Before reinstalling the app or clearing its data, make sure any unsynced local documents are saved or backed up.

7. Check the server only after simpler causes are ruled out

If the exact public URL times out from multiple devices and networks, the likely fault is on the server or its network path. Confirm the portal, storage service, reverse proxy, and Document Server are running. For Docker installations, an administrator can inspect container status and recent logs with commands such as:

docker compose ps
docker compose logs --tail=100 <service-name>

Use the actual service names from the deployment’s Compose file; names vary between installations. Check for repeated restarts, DNS failures, upstream connection errors, resource exhaustion, or certificate-renewal problems. Avoid restarting every component before capturing logs, because a restart can remove useful evidence of the failure.

For a Document Server specifically, the official help center documents an /info/ page that administrators can use to check the service when it is enabled and accessible. It is a diagnostic for Document Server, not a substitute for testing the portal or WebDAV address entered in the mobile app. See ONLYOFFICE’s instructions for the Document Server Info page.

Verify the fix from the phone

Run the checks in this order: open the exact portal or WebDAV URL in the phone’s browser; repeat on Wi-Fi and mobile data; add the account in ONLYOFFICE Documents with the matching service type; sign in; browse a folder; and open a small test document. If browsing works but editing does not, investigate the server-side ONLYOFFICE Docs integration. If the browser and app both time out, continue with DNS, firewall, proxy, and server checks rather than repeatedly changing the password.

A successful result is a stable sign-in and folder listing on the network where you intend to work. Test opening and saving a noncritical file before relying on the setup for important documents. If the issue persists, give the administrator the exact URL type (portal, WebDAV, or Document Server), phone operating system, network used, timestamp, and any HTTP status or proxy log entry. Do not send passwords, access tokens, or document contents in a support request.