The editor window opens, the loading starts — and then it stops with Download failed. Your documents are fine and your install is probably fine too. One specific leg of the journey between the two servers is broken, and this page finds it.
To fix Download failed, first understand whose download failed. When you click a file, your browser loads the editor from the Document Server — that part worked, because you can see the editor. Then the Document Server itself goes to Nextcloud to fetch the file, server to server. That second journey is the one that failed. Everything on this page follows from that single fact: the Document Server cannot reach Nextcloud at the address it was given, or Nextcloud's answer never makes it back.
Your browser reaching Nextcloud proves nothing about this error — you must test from the Document Server machine. On that server, try opening the Nextcloud address the way the Document Server would see it:
curl -I https://cloud.example.com
If this fails, times out, or returns a certificate error, you have found your problem class — the Document Server cannot talk to Nextcloud. If it answers cleanly, test the reverse direction too, from the Nextcloud server towards the Document Server address.
The most common version of this failure: both servers sit on the same office network, but their public names resolve to the router's public address, and the router will not loop the traffic back inside (no NAT hairpinning). Browsers outside the office work; the servers cannot reach each other by name. The fix is to give the integration internal addresses for server-to-server traffic — which is exactly what the connector's advanced settings are for.
In Nextcloud, open Settings → ONLYOFFICE → Advanced settings. Two fields solve this error class:
If the internal route uses HTTPS with a self-signed certificate, the Document Server may refuse the connection even though the address is reachable — a browser would show a warning, but a server simply fails. The honest fixes are to use a proper certificate, or to let the internal server-to-server leg use plain HTTP on a trusted private network via the advanced settings. What you should not do is keep clicking retry hoping certificates heal themselves.
Before deep changes, rule out the simple ones: a firewall between the two machines blocking the port, the Document Server container not actually running (sudo docker ps), or the Nextcloud address in the settings containing a typo or an old subdomain. The connector's own error details and the Document Server logs under /var/log/onlyoffice on the host will usually name the failing address outright — read them before guessing further.
The full OnlyOffice Document Server install and Nextcloud integration, shown live step by step.
▶️ Watch Full VideoBecause two different connections are involved. Your browser successfully loaded the editor from the Document Server, but the Document Server then failed to download the document file from Nextcloud. That server-to-server fetch is what the Download failed message reports.
They let the two servers talk over a private route while users keep using the public addresses. This fixes the common case where public names do not resolve or route correctly inside your own network, even though everything works from outside.
Yes. If the Document Server must fetch from an HTTPS address with a certificate it does not trust, such as a self-signed one, the fetch fails silently from the user's point of view. Use a trusted certificate, or keep the internal leg on plain HTTP within a trusted network.