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. nc.example.com and oo.example.com).
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 nc.example.com 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:
services:
app:
image: abiosoft/caddy:0.11.0
networks:
nextcloud_external-net:
aliases:
- nc.example.com
- oo.example.com
Then I was able to just enter https://oo.example.com 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 nc.example.com or oo.example.com) 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.