Connect to nextcloud through proxy

Installation & Configuration
1

Hi,
In my setup i have an forward proxy in front of all outgoing connection to filter the services.
Is there an possible configuration to point Collabora online to this proxy? All my services are in containers (Nextcloud, Collabora, Tinyproxy, Caddy).

Stuff i tried:

  • add an proxy section in the coolwsd.xml (see below)
  • curl in Nextcloud to Collabora: https://office.example.com/browser/dist/admin/admin.html
  • curl in Collabora to Nextcloud: http://cloud.example.com/status.php
  • curl from client to the two services
    => all curl commands work

The reason the curls work, is because I added the enviroment vars: HTTP_PROXY, HTTPS_PROXY, http_proxy, https_proxy to point all to the proxy.

But still i get the error message:

wsd-00001-00023 2025-04-15 21:59:34.760234 +0000 \( websrv_poll \) DBG  #-1: starting asyncRequest: GET cloud.example.com:443 /index.php/apps/richdocuments/wopi/files/7_octwoqzlt3pi?access_token=qHXzQymXM0fTT9DQkLgjgrQGroNHg788&access_token_ttl=0&permission=edit| net/HttpRequest.hpp:1340
wsd-00001-00023 2025-04-15 21:59:34.760306 +0000 \( websrv_poll \) ERR  #-1: Failed to connect to cloud.example.com:443| net/HttpRequest.hpp:1756
wsd-00001-00023 2025-04-15 21:59:34.760311 +0000 \( websrv_poll \) ERR  #-1: Failed to start an async CheckFileInfo request| wsd/wopi/CheckFileInfo.cpp:157

I also found this wiki entry Proxy but it only applies when the connection was already successful.

It would be much appreciated if anyone has an solution for my edge problem. Thank you in advance!

My coolwsd.xml:

<config>
    <ssl desc="SSL settings">
        <!-- switches from https:// + wss:// to http:// + ws:// -->
        <enable type="bool" desc="Controls whether SSL encryption between coolwsd and the network is enabled (do not disable for production deployment). If default is false, must first be c>
        <!-- SSL off-load can be done in a proxy, if so disable SSL, and enable termination below in production -->
        <termination desc="Connection via proxy where coolwsd acts as working via https, but actually uses http." type="bool" default="false">true</termination>
    </ssl>

    <storage desc="Backend storage">
        <filesystem allow="false"/>
        <wopi allow="true" desc="Allow/deny wopi storage.">
            <max_file_size desc="Maximum document size in bytes to load. 0 for unlimited." type="uint">0</max_file_size>
            <locking desc="Locking settings">
                <refresh default="900" desc="How frequently we should re-acquire a lock with the storage server, in seconds (default 15 mins) or 0 for no refresh" type="int"/>
            </locking>
            <alias_groups desc="default mode is 'first' it allows only the first host when groups are not defined. set mode to 'groups' and define group to allow multiple host and its alias>
            <!-- If you need to use multiple wopi hosts, please change the mode to "groups" and
                    add the hosts below.  If one host is accessible under multiple ip addresses
                    or names, add them as aliases. -->
            <!--<group>
                    <host desc="hostname to allow or deny." allow="true">scheme://hostname:port</host>
                    <alias desc="regex pattern of aliasname">scheme://aliasname1:port</alias>
                    <alias desc="regex pattern of aliasname">scheme://aliasname2:port</alias>
                    @UNLOCK_LINK_PER_HOST@
            </group>-->
            <!-- More "group"s possible here -->
            </alias_groups>
            <host desc="Regex pattern of hostname to allow or deny." allow="true">https://cloud\.example\.com</host>
        </wopi>
        <ssl desc="SSL settings">
           <as_scheme default="false" desc="When set we exclusively use the WOPI URI's scheme to enable SSL for storage" type="bool">false</as_scheme>
           <enable desc="If as_scheme is false or not set, this can be set to force SSL encryption between storage and coolwsd. When empty this defaults to following the ssl.en">false</enab>
           <termination type="bool">true</termination>
        </ssl>
    </storage>
    <logging>
        <level type="string" desc="Can be 0-8 \(with the lowest numbers being the least verbose\), or none \(turns off logging\), fatal, critical, error, warning, notice, information, debug, tr>
    </logging>
    <proxy>
       <http>
           <host>http://systemd-tinyproxy</host>
           <port>8888</port>
       </http>
       <https>
           <host>http://systemd-tinyproxy</host>
           <port>8888</port>
       </https>
   </proxy>
</config>
2

hii @SubjectQuit

Thanks for the detailed description — you’re on the right track! Unfortunately, Collabora Online’s coolwsd does not currently respect the <proxy> configuration section in coolwsd.xml for outgoing HTTP(S) requests (like WOPI CheckFileInfo).

What does work:

As you mentioned, setting the environment variables HTTP_PROXY, HTTPS_PROXY, and NO_PROXY is the right approach. But here’s the important detail:

These variables must be set in the container environment that actually runs the coolwsd process. Just setting them in the Dockerfile or in the parent shell won’t work if they’re not passed correctly.

How to ensure it works:

Make sure your docker run (or docker-compose) includes:

environment:
  - HTTP_PROXY=http://systemd-tinyproxy:8888
  - HTTPS_PROXY=http://systemd-tinyproxy:8888
  - NO_PROXY=localhost,127.0.0.1,.example.com

Or for docker run:

docker run -e HTTP_PROXY=http://systemd-tinyproxy:8888 \
           -e HTTPS_PROXY=http://systemd-tinyproxy:8888 \
           -e NO_PROXY=localhost,127.0.0.1,.example.com \
           collabora/code

Validate inside the container:

After launching the container, exec into it:

docker exec -it your_container_name bash
env | grep -i proxy

Then try:

curl -v https://cloud.example.com/status.php

If this works, but Collabora still logs Failed to connect, it may be an internal limitation or libcurl in the Collabora build not reading the environment (e.g., setuid context or chroot environment).

Potential workaround:

As an alternative workaround, you could wrap coolwsd with a small shell script:

#!/bin/bash
export HTTP_PROXY=http://systemd-tinyproxy:8888
export HTTPS_PROXY=http://systemd-tinyproxy:8888
export NO_PROXY=localhost,127.0.0.1,.example.com

exec /usr/bin/coolwsd "$@"

Then replace the CMD in your container to call this wrapper instead.

Thanks
Darshan

3

Hi @darshan,

thank you sooo much for the fast and also very detailed description. I missed a maybe important detail in my description. I use podman instead of docker for added security. I hope this isn’t a problem in this case. Unfortionally nothing worked in my instance. :frowning:

I’ve set these enviroment vars and the output of env | grep PROXY is the correct one:

HTTPS_PROXY=http://systemd-tinyproxy:8888
NO_PROXY="localhost,127.0.0.1"
HTTP_PROXY=http://systemd-tinyproxy:8888

and the curl also works: podman exec stack-collabora curl -v https://cloud.example.com/status.php

{"installed":true,"maintenance":false,"needsDbUpgrade":false,"version":"31.0.2.1","versionstring":"31.0.2","edition":"","productname":"Nextcloud","extendedSupport":false}

But I still get the same error.

I also tried the wrapper script, but nothing worked. :frowning:

Thank you for your spend time on this issue!

4

hii @SubjectQuit

I think there some configuration missing on your side. For that i need more detailed logs

Enable verbose logs

To help narrow down where it’s failing, add this to your coolwsd.xml:

<logging>
  <level>trace</level>
</logging>

Then look for logs in:

podman logs stack-collabora

or wherever your logging path is configured.

Confirm whether libcurl or Poco::Net is being used

Collabora Online uses Poco::Net::HTTPClientSession under the hood (which doesn’t always respect HTTPS_PROXY the same way as curl does).

In that case, a workaround is to use system-wide proxy configuration:

  • Create or edit /etc/environment:
HTTPS_PROXY=http://systemd-tinyproxy:8888
HTTP_PROXY=http://systemd-tinyproxy:8888
NO_PROXY=localhost,127.0.0.1
  • Then ensure the container inherits this using --env-file or similar Podman option.

Try Podman’s --network=host mode

If this is a testing/staging setup, you can try:

podman run --network=host ...

Just to check if the problem is related to container DNS resolution or internal routing.

Thanks
Darshan

5

Hi,
thank you for your time. I cant the container to host mode, but I temporarily circumvented the proxy. When I did that, the errors disappeared, but the loading still failed.
So there has to be another issue, that is not even logged. I only get the following Warning: (See post below)

wsd-00001-00014 2025-04-16 08:58:41.426816 +0000 [ prisoner_poll ] WRN  Waking up dead poll thread [docbroker_006], started: false, finished: false| net/Socket.hpp:831
wsd-00001-00023 2025-04-16 09:00:02.220487 +0000 [ websrv_poll ] WRN  convert-to: Requesting address is denied: ::ffff:192.168.0.241| wsd/ClientRequestDispatcher.cpp:560

The Log below is when run behind the proxy like before.

Unfortunately I cant decern witch libary is used.

I uploaded the log to:

Thanks a lot!

7

I fixed the second issue and now everything is working without the proxy.
My problem was an misconfigured docker command.

I’ve set the e server_name=office.example.de to
office\.example\.com
but this was wrong. The correct name is without the “” so:
office.example.com

The original issue was also resolved on my end, but just with an workaround.

I made an alternative internal path to my reverse proxy resolver.
It now listens to the local address used by the internal network, then I overwrote the host on my Collabora container with the command:
--add-host cloud.example.de:192.168.0.41

The container it self has no Network access, but from my testing it just works.

Thank you for your input, maybe one day the http library of collabora will respect the HTTP_PROXY env.

Thank you!!!

1 Like