Using nginx instead of Apache for Collabora

Did anybody get Collabora working with nginx as reverse proxy yet? I followed the guide at https://nextcloud.com/collaboraonline/ and used the nginx configuration from https://icewind.nl/entry/collabora-online.

Using the official Apache 2 configuration works just fine but using nginx as reverse proxy will lead into a) timeouts b) long loading times c) “We cannot connect…” messages.

I read in multiple threads that there are issues with nginx as reverse proxy but nobody has posted a solution yet.

Nextcloud: 10.0.1 (stable)
Collabora Online: 1.1.13 (experimental)
Apache 2: 2.4.19 (Ubuntu)
nginx: 1.10.0 (Ubuntu)
collabora/code: latest

I was also having troubles setting this up. If you are using docker, here I wrote my sollution.

I am having the exact same issues.

I already have a container with NGINX setup so I cannot use a pre-built container. I also am using cloudflare SSL so Lets Encrypt really is not an option for me.

@lachmanfrantisek could you please post the actual NGINX configuration from your “sites-available” folder?

this is my error.

I am not getting this error, that looks like something more in the docker itself.

I am just getting timeouts “cannot load the file” type messages

After taking a look at the nginx configuration inside of the docker container jwilder/nginx-proxy I found out that the following directive needs to be set in order for some websockets to work properly.

 proxy_buffering off;

For everyone interested:

When buffering is disabled, the response is passed to a client synchronously, immediately as it is received. nginx will not try to read the whole response from the proxied server. The maximum size of the data that nginx can receive from the server at a time is set by the proxy_buffer_size directive.

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering

Documents load in under one second now.

@Tyler_Collins nginx-proxy did not create sites_available. If you still want, here is nginx.conf:

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    server_names_hash_bucket_size 128;
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;

    client_max_body_size 16G;
}

Here is included file ./conf.d/default.conf, where are subdomains set up:

# If we receive X-Forwarded-Proto, pass it through; otherwise, pass along the
# scheme used to connect to this server
map $http_x_forwarded_proto $proxy_x_forwarded_proto {
  default $http_x_forwarded_proto;
  ''      $scheme;
}
# If we receive Upgrade, set Connection to "upgrade"; otherwise, delete any
# Connection header that may have been passed to this server
map $http_upgrade $proxy_connection {
  default upgrade;
  '' close;
}
gzip_types text/plain text/css application/javascript application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
log_format vhost '$host $remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent"';
access_log off;
# HTTP 1.1 support
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $proxy_connection;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
server {
    server_name _; # This is just an invalid value which will never trigger on a real hostname.
    listen 80;
    access_log /var/log/nginx/access.log vhost;
    return 503;
}

upstream nc.domain.com {
                ## Can be connect with "bridge" network
            # nc
            server 172.17.0.7:8888;
}
server {
    server_name nc.domain.com;
    listen 80 ;
    access_log /var/log/nginx/access.log vhost;
    return 301 https://$host$request_uri;
}
server {
    server_name nc.domain.com;
    listen 443 ssl http2 ;
    access_log /var/log/nginx/access.log vhost;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ECD....3-SHA;
    ssl_prefer_server_ciphers on;
    ssl_session_timeout 5m;
    ssl_session_cache shared:SSL:50m;
    ssl_certificate /etc/nginx/certs/nc.domain.com.crt;
    ssl_certificate_key /etc/nginx/certs/nc.domain.com.key;
    ssl_dhparam /etc/nginx/certs/nc.domain.com.dhparam.pem;
    add_header Strict-Transport-Security "max-age=31536000";
    include /etc/nginx/vhost.d/default;
    location / {
        proxy_pass http://nc.domain.com;
    }
}

upstream office.domain.com {
                ## Can be connect with "bridge" network
            # nc-code
            server 172.17.0.13:9980;
}
server {
    server_name office.domain.com;
    listen 80 ;
    access_log /var/log/nginx/access.log vhost;
    return 301 https://$host$request_uri;
}
server {
    server_name office.domain.com;
    listen 443 ssl http2 ;
    access_log /var/log/nginx/access.log vhost;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ECD......-SHA;
    ssl_prefer_server_ciphers on;
    ssl_session_timeout 5m;
    ssl_session_cache shared:SSL:50m;
    ssl_certificate /etc/nginx/certs/office.domain.com.crt;
    ssl_certificate_key /etc/nginx/certs/office.domain.com.key;
    ssl_dhparam /etc/nginx/certs/office.domain.com.dhparam.pem;
    add_header Strict-Transport-Security "max-age=31536000";
    include /etc/nginx/vhost.d/default;
    location / {
        proxy_pass https://office.domain.com;
    }
}

I see, that proxy_buffering off; is here by default, like @DomiStyle wrote.

has anyone an idea for my problem? unauthorized WOPI-Host

@Lars_M You have to enable collabora for specific domains. Do you have correct domain setting in environment in docker run?

Here is the info from tutorial:

1. Install the Collabora Online server

The following steps will download the Collabora Online docker, make sure to replace “cloud.nextcloud.com” with the host that your own Nextcloud runs on. Also make sure to escape all dots with double backslashes (\), since this string will be evaluated as a regular expression (and your bash ‘eats’ the first backslash.) If you want to use the docker container with more than one Nextcloud, you’ll need to use domain=cloud\\.nextcloud\\.com\|second\\.nexcloud\\.com instead. (All hosts seperated by \|.)

docker pull collabora/code

docker run -t -d -p 127.0.0.1:9980:9980 -e 'domain=cloud\\.nextcloud\\.com' --restart always --cap-add MKNOD collabora/code

Are you using the nginx proxy docker image from jwilders? With that I got it running some days before.
Do you have a valid ssl certificate for the domain office.domain.com?
I had to trick with the combination of nginx proxy and letsencrypt companion, that I could make it generate a valid certificate. The problem is, that the collabora docker image does not respond on port 80 requests, which letsencrypt needs to validate the domain.
Can you reach office.domain.com with a valid certificate, or do you get a browser warning?

Yes, I use jwilders/nginx-proxy. For generating certificates, I use jrcs/letsencrypt-nginx-proxy-companion like you. The proxy container not depends on port 80, it finds the one exposed.

Inspired by this post I try adding --env VIRTUAL_PORT=9980 and --env VIRTUAL_PROTO=https and it works.

Here is me run syntax:

docker run -t -d \
        --name nc-code \
        --hostname office.domain.com \
        --env VIRTUAL_HOST=office.domain.com \
        --env LETSENCRYPT_HOST=office.domain.com \
        --env LETSENCRYPT_EMAIL=a@b.c \
        --env VIRTUAL_PORT=9980 \
        --env VIRTUAL_PROTO=https \
        -e 'domain=nc\\.domain\\.com' \
        --restart always \
        --cap-add MKNOD \
        --expose 9980 \
        collabora/code

When I type office.domain.com to browser, it returns OK.

1 Like

I suggest enabling dns bypass in CloudFlare and see if it works with DNS resolving directly to your IP. I’ve seen MANY issues with cloudflare sitting in front of complex applications such as NextCloud, Collabora, etc unless it has specific optimizations already put in place to accommodate. I would definitely rule Cloudflare out as the problem before trying anything too drastic.

Just my 2cents.
Mike

Thank you, I will work on this over the weekend and report back if this works. I still believe some updates need to be made to the example NGINX reverse-proxy configuration at https://icewind.nl/entry/collabora-online. Updates had to be made to the Apache configuration however i believe this one got forgotten. I am not sure if anyone has gotten this working yet.

Hi, i know this thread was inactive for a while, but can some elaborate how i can get a letsencrypt certificate for my office subdomain? i used the same docker run command as lachmanfrantisek and i get the little OK text when i access it via http. When i try it via https nginx-proxy redirects to the default domain…

I would really appreciate your help.

I just had the same problem, turns out the copypasta from this forum uses the wrong ENV variable.
Instead of
--env 'DOMAIN=sub\\.tld\\.de' \
use
--env 'domain=sub\\.tld\\.de' \

Aka: don’t use capitals. Then it works fine with jwilder proxy and it’s letsencrypt proxy companion

My command looks like this:

docker run -t -d
–name nc-office
–hostname colabd.tld.de
–env ‘VIRTUAL_HOST=colab.tld.de
–env ‘LETSENCRYPT_HOST=colab.tld.de
–env ‘LETSENCRYPT_EMAIL=email@tld.de’
–env ‘VIRTUAL_PORT=9980’
–env ‘VIRTUAL_PROTO=https’
–env ‘domain=ncsub\.domain\.de’
–env ‘username=myusername’
–env ‘password=mypassword’
–env 'server_name=colab.tld.d’e
–restart always
–cap-add MKNOD
–expose 9980
collabora/code