Can`t connect ONLYOFFICE from Nextcloud in docker

Nextcloud version---------------------Docker pull nextcloud
Operating system and version-----Debian GNU/Linux 9 (stretch)
Web server------------------------------Caddy in docker
Docker version-------------------------18.06.0-ce

I am tring to connect OnlyOffice from Nextcloud.Both OnlyOffice and Nextcloud are running in docker.

I am using portainer and running OnlyOffice with selecting interactive mode and TTY (-i -t) and using HTTPS.Now everything is running well.But I just can`t connect OnlyOffice from the nextcloud.The note said

Error when trying to connect (Bad Request or timeout error)

I am 100% sure both the containers are in one docker network.And in the OnlyOffice container the nginx is running well.

Because I am running other sites on the server,so I am running a Caddy docker as proxy.So there are 4 containers running and they are all in the same network.

Container Note
Caddy docker As proxy
Nextcloud Full version with Apache inside
Mysql Database
Onlyoffice Fulle version with everthing inside

The Caddyfile looks like this:

    proxy / {

As the Onlyoffice container\s IP is,so I enter in the Onlyoffice settings,but that does not work.

The OnlyOffice container ENV details are here.

Name Value
PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
DEBIAN_FRONTEND noninteractive
SSL_CERTIFICATE_PATH /var/www/onlyoffice/Data/certs/onlyoffice.crt
SSL_KEY_PATH /var/www/onlyoffice/Data/certs/onlyoffice.key
SSL_DHPARAM_PATH /var/www/onlyoffice/Data/certs/dhparam.pem

The log in Nextcloud is here.

Error onlyoffice HealthcheckRequest on check error: Bad Request or timeout error
Error PHP file_get_contents( failed to open stream: operation failed at /var/www/html/custom_apps/onlyoffice/lib/documentservice.php#381
Error PHP file_get_contents(): Failed to enable crypto at /var/www/html/custom_apps/onlyoffice/lib/documentservice.php#381
Error PHP file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed at /var/www/html/custom_apps/onlyoffice/lib/documentservice.php#381

I have tried to fix this issue but failed.Can somebody help me?

Have fixed it by myself.

So, I struggled for a very long time to get ONLYOFFICE to work. So, I want to put here what I did.


  1. Nextcloud 13.0.*
  2. Had a working Collabora docker installed
  3. Using apache2 reverse proxy to connect to ONLYOFFICE docker container
  4. You’ve installed postgresql at some point in time

How to install:
NOTE: There is a lot of info, and a lot of it is noise and not simple to understand.

  1. Install the docker container
    sudo docker pull onlyoffice/documentserver
  2. Create these directories
    sudo mkdir -p /var/log/onlyoffice
    sudo mkdir -p /var/lib/onlyoffice
  3. Start ONLYOFFICE container
    sudo docker run -i -t -d --restart=always -p -p -v /app/onlyoffice/DocumentServer/logs:/var/log/onlyoffice -v /app/onlyoffice/DocumentServer/lib:/var/lib/onlyoffice -v /app/onlyoffice/DocumentServer/db:/var/lib/postgresql onlyoffice/documentserver
  4. Make your onlyoffice.conf file

< IfModule mod_ssl.c >

ServerTokens Prod
SSLStaplingCache "shmcb:${APACHE_LOG_DIR}/stapling-cache(150000)"
SSLSessionCache "shmcb:${APACHE_LOG_DIR}/ssl_scache(512000)"
SSLSessionCacheTimeout 300

<VirtualHost *:443>

Basic Info

CustomLog ${APACHE_LOG_DIR}/ combined

SSL Info

SSLEngine On
SSLCertificateFile /etc/letsencrypt/live/
SSLCertificateKeyFile /etc/letsencrypt/live/
Include /etc/letsencrypt/options-ssl-apache.conf

Security Hardening

SSLProxyEngine On
AddDefaultCharset utf-8
HostnameLookups Off
UseCanonicalName Off
ProxyBadHeader Ignore
KeepAlive Off
ProxyPreserveHost On
ProxyRequests Off
ProxyTimeout 600
ProxyReceiveBufferSize 4096
SSLProtocol All -SSLv2 -SSLv3
SSLCompression Off
SSLHonorCipherOrder On
#Header always set Strict-Transport-Security "max-age=11536000;
#Header set X-Content-Type-Options "nosniff"
#RequestHeader unset Accept-Encoding

Magic stuff from:

SetEnvIf Host "^(.*)$" THE_HOST=$1
RequestHeader setifempty X-Forwarded-Proto https
RequestHeader setifempty X-Forwarded-Host %{THE_HOST}e
ProxyAddHeaders Off

If you used a different port, be sure to change 9981

ProxyPassMatch (.*)(\/websocket)$ "ws://$1$2"
ProxyPass / ""
ProxyPassReverse / ""

Since ONLYOFFICE is not SSL (using 9981->80)

SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off

< /VirtualHost>
< /IfModule>`

  1. If you have access to a browser from the local machine, type

  2. Should get

  3. Add your ds domain to Nextcloud i.e.

  4. Should be good to go!

hello , I have met the same question as you, so I want to know how you solve it. Really hope to receive your help.

I have met the same question as you.too,
How to solve it?
If you find a way, please let me know, thank you

hello,I have met the same question as you.too,
How to solve it?
If you find a way, please let me know, thank you

I have solved it. you only need to use the safe link ‘https’ will be ok. such as ‘‘https://xxx.xx’’


would you mind translating it to english, please?

Have you met the same question like me ? just type in the link started with “https”. my document server address is “”, you can use my link to have a test .

1 Like

thanks so much

My situation is slightly different from the op and the above suggestions did not really work for me. Wanted to post out there and hopefully save anyone in a similar situation from a lot of headaches.

My Setup:
On a single Docker host (Ubuntu linux) I am running Nextcloud and OnlyOffice from docker containers. (Importantly, I am running the FPM version of the Nextcloud image.) I am using Caddy (also running in a Docker container) to proxy/serve both NC and OO on separate subdomains (e.g. and

The Problem:
The seemingly easy task of pointing the OnlyOffice plugin in Nextcloud to my hosted OO server was thwarted by my UFW firewall blocking requests to my host machine when they originated from my host machine. (Meaning that if I hosted OO on a separate machine everything worked fine, but when OO and NC were on the same host, and NC tried to make a request to OO, the firewall would block it because the IPs for the source and dest were the same). The error that showed up in NC was:

‘HealthcheckRequest on check error: cURL error 28: Connection timed out after 60001 milliseconds’

I could not use the loopback interface on the host machine either since the Docker network stack is segregated from the host’s network stack (and I did not want to run my Docker network in “host” mode).

The OO plugin in NC offers the ability to set internal addresses for your services and I thought perhaps I could point the containers at each other directly using the container names (since they both were on the same user-defined Docker network). This allowed me to connect NC to OO by setting http://oo_contatiner_name/ as the internal document editing service address. However, the setup still failed and I could see in the logs that when OO service tried to call back to it timed out (blocked again by the firewall). So, of course, I tried to set the internal document server address for calling back to NC to http://nc_containter_name/. This did not work, though, at least in part because the FPM image needs to sit behind a webserver…

The Solution
I got things to work via a creative use of Docker network aliases. Basically, my Caddy container, OO container, and NC container were all on the same user-defined Docker network (nextcloud_external-net). Docker lets you define network-level aliases for a container that can be resolved by services in other containers on the network. I used docker-compose to define my Caddy container setup and here is the relevant section with the aliases:

    image: abiosoft/caddy:0.11.0

Then I was able to just enter as the Document Editing Server Address in the OO plugin settings in Nextcloud (without filling anything out in the Advanced Server Settings) and everything worked! Whenever either of the containers tries to talk to the other (via or those addresses resolve to the Caddy container and Caddy just proxys the request to the proper container. So, the requests between the two never actually leave the nextcloud_external-net network.