Your Nextcloud is on HTTPS, your Document Server answers on plain HTTP — and the editor refuses to load inside the secure page. Browsers are strict about this, and rightly so. A reverse proxy with a proper certificate fixes it cleanly.
If Nextcloud is served over HTTPS — and it should be — then the OnlyOffice editor, which loads inside the Nextcloud page, must also arrive over HTTPS. A browser will block an HTTP editor inside an HTTPS page as mixed content, and no connector setting can overrule that. The standard solution is a reverse proxy in front of the Document Server: the proxy holds the certificate, speaks HTTPS to the world, and passes requests to the container behind it. This page covers the proxy-side details that decide whether editing actually works.
Create a proxy entry for the Document Server's own subdomain, for example office.example.com, pointing at the container (commonly http://127.0.0.1:80 on the same host, or the container's address on your network). Obtain a certificate for that name — with a tool like Nginx Proxy Manager or Caddy this is a couple of clicks using Let's Encrypt. From this moment the Document Server has a public HTTPS face while the container itself stays plain and simple behind the proxy.
Live editing keeps a websocket connection open between each browser and the Document Server. A proxy that does not forward the upgrade headers will serve the welcome page fine and then break every editing session. In Nginx terms the proxy must pass:
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
Along with the usual host and forwarded-for headers. Graphical proxy tools expose this as a websockets support toggle — switch it on. This single setting is the difference between an integration that demos well and one a team can actually work in all day.
In Nextcloud, Settings → ONLYOFFICE, set the Document Server address to the HTTPS address users' browsers will use — https://office.example.com — and save so the connection test runs against it. Test from a normal user account, ideally from outside the server network as well as inside: HTTPS mistakes love to hide until a real user on a real connection tries to open a file.
Here is the part that saves home and office setups: while browsers must use the public HTTPS address, the server-to-server traffic can keep using internal addresses through the connector's advanced settings — the same fields covered in the Download failed guide. Nextcloud and the Document Server can fetch from each other over the LAN, while every user enjoys the locked-padlock address. Public for people, private for servers, both correct at the same time.
Certificates expire; automation is your friend. Let's Encrypt certificates renew automatically in the common proxy tools — verify the renewal is actually scheduled once, rather than discovering an expired certificate from a user complaint ninety days later. Finish the setup the way every guide on this site finishes: open a real document as a real user, edit it with a second person if you can, and watch the co-editing cursors move. That is HTTPS, websockets and integration all proven in one gesture.
The full OnlyOffice Document Server install and Nextcloud integration, shown live step by step.
▶️ Watch Full VideoBrowsers block mixed content: an HTTPS page cannot load an HTTP editor inside it. The Document Server must be reachable over HTTPS — normally by putting a reverse proxy with a valid certificate in front of it and using that HTTPS address in the connector.
It needs HTTPS under its own name, for example office.example.com, which means a certificate covering that subdomain. Tools like Nginx Proxy Manager or Caddy can obtain and renew a free Let's Encrypt certificate for it automatically.
Co-editing uses websocket connections, and the proxy must forward the Upgrade and Connection headers (or have its websockets option enabled). Without them, pages and the welcome screen can work while live editing sessions fail or freeze.