Reverse Proxy Configuration

This section describes how to integrate Sync-in with an existing reverse proxy.

info

With the recommended Docker installation, the server is already configured with the Nginx reverse proxy.
Therefore, this documentation does not apply to that use case.

---

Why a reverse proxy?

A reverse proxy enhances the security and connectivity of your Sync-in deployment (NPM or Docker).
It acts as a shield between the Internet and the Sync-in server, filtering traffic and hiding the internal infrastructure.
It centralizes HTTPS encryption management, ensuring all communications with Sync-in remain secure.
Finally, it simplifies integration into the network environment by controlling flows and interfacing with other existing services.

Sync-in Server Configuration

In the environment.yaml configuration file, the server section defines the trustProxy option, which tells the server to what extent it should trust proxies (e.g., Nginx, Traefik) to determine the client's real IP address.

server:
  trustProxy: 1 # default value if not specified

Possible values

Value	Behavior
false	Ignores proxy headers, uses only the direct connection IP
true	Trusts the entire proxy chain
n (e.g. 1)	Trusts the n-th proxy in the chain
IP, CIDR	Trusts only the specified proxies

warning

The trustProxy: 1 setting is recommended when running behind a reverse proxy (Nginx, Traefik, etc.).
It ensures that the Sync-in server correctly retrieves the client's IP address and operates without errors in a proxied environment.

Nginx Configuration

Several reverse proxies can be used. In this documentation, the configuration is described with Nginx, as it is the most common and best supported solution.

This configuration file is the recommended reference to ensure optimal operation of Sync-in server features.

⚠️ The directives server_name, ssl_certificate, ssl_certificate_key as well as the server address sync_in:8080 must be adapted to your environment.

# SYNC-IN NGINX VHOST

map $request_uri $xfp {
    # This header must be null on webdav uri
    # It causes authentication failures with Microsoft-WebDAV-MiniRedir (Windows)
    ~^/webdav(?:/.*)?  "";
    default            $scheme;
}


map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

upstream sync_in_server {
    server sync_in:8080;
    keepalive 32;
}

server {
    listen 80;
    # listen 443 ssl;
    # http2 on;
    # server_name  domain.com www.domain.com;
    # ssl_certificate      /etc/ssl/certs/fullchain.pem;
    # ssl_certificate_key  /etc/ssl/certs/privkey.pem;
    # ssl_protocols TLSv1.2 TLSv1.3;
    # ssl_session_cache shared:SSL:10m;
    # ssl_session_timeout 1h;
    # ssl_prefer_server_ciphers on;
    # ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
    # ssl_ecdh_curve X25519:prime256v1;

    # General settings
    charset UTF-8;
    server_tokens off;
    access_log off;
    include mime.types;

    # Optimized file sending
    sendfile on;
    tcp_nodelay on;
    tcp_nopush on;

    # Buffering for requests proxied to Node
    proxy_http_version 1.1;
    chunked_transfer_encoding on;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP  $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Proto $xfp;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_cache_bypass $http_upgrade;
    proxy_redirect off;

    # Proxy buffering settings
    proxy_buffering off; # nginx -> node
    proxy_buffers 8 512k;
    proxy_buffer_size 512k; # node highWaterMark

    # Generous timeouts for long transfers or ws
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;
    keepalive_timeout  180  90s;

    # Clients settings
    proxy_request_buffering off; # client -> nginx
    large_client_header_buffers 4 16k;
    client_max_body_size 0;
    client_body_buffer_size 25M;

    location / {
        proxy_pass http://sync_in_server;
    }

    location ~* .(ico|jpg|png|gif|jpeg|swf|woff|svg)$ {
        # nginx always use the most accurate rule in its internal routing policies
        proxy_pass http://sync_in_server;
        gzip_static on;
        gzip_comp_level 5;
        expires 1d;
        add_header Cache-Control public;
    }

    # NOTE: This is only needed when the Collabora Online Docker container is running locally
    #       and you are not using an external URL.
    # Uncomment the line below to enable it:
    # include collabora.conf;

    # NOTE: This is only needed when the OnlyOffice Docker container is running locally
    #       and you are not using an external URL.
    # Uncomment the line below to enable it:
    # include onlyoffice.conf;
}

Collabora Online Configuration

In both modes, the Collabora feature must be enabled in the environment.yaml configuration file:

applications:
  files:
    collabora:
      enabled: true

⚠️ If you deployed Collabora using Docker and are running Nginx with HTTPS, make sure to enable SSL termination.

Proxied mode

In the Nginx configuration, uncomment the directive include collabora.conf; to load the Collabora configuration.
In this mode, it is not necessary to expose the Collabora server directly to the Internet, but it must still be accessible from the Sync-in server.

Then, create the file /etc/nginx/collabora.conf and insert the content below.

⚠️ The value of proxy_pass must be adjusted according to the address of your Collabora server.

# Static Files
location ^~ /browser/ {
  proxy_pass http://collabora:9980;
  proxy_set_header Host $http_host;
}

# WOPI Discovery URL and Capabilities
location ^~ /hosting/ {
  proxy_pass http://collabora:9980;
  proxy_set_header Host $http_host;
}

# Main WebSocket + Docs Management
location ^~ /cool/ {
  proxy_pass http://collabora:9980;
  proxy_set_header Host $http_host;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
}

External mode

The Collabora server must be accessible from both the Sync-in server and the browser (domain name or IP address).
Configure the externalServer directive in environment.yaml:

applications:
  files:
    collabora:
      enabled: true
      externalServer: collabora.my-domain.com  

OnlyOffice Configuration

In both modes, the OnlyOffice feature must be enabled in the environment.yaml configuration file:

applications:
  files:
    onlyoffice:
      enabled: true

info

Advanced OnlyOffice parameters are detailed in the Server Parameters section.

Proxied mode

In the Nginx configuration, uncomment the directive include onlyoffice.conf; to load the OnlyOffice configuration.
In this mode, it is not necessary to expose the OnlyOffice server directly to the Internet, but it must still be accessible from the Sync-in server.

Then, create the file /etc/nginx/onlyoffice.conf and insert the content below.

⚠️ The value of proxy_pass must be adjusted according to the address of your OnlyOffice server.

location ^~ /onlyoffice/ {
    proxy_pass http://onlyoffice:80/;
    proxy_set_header X-Real-IP  $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $host/onlyoffice;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_no_cache 1;
    proxy_cache_bypass 1;
}

External mode

The OnlyOffice server must be accessible from both the Sync-in server and the browser (domain name or IP address).
Configure the externalServer directive in environment.yaml:

applications:
  files:
    onlyoffice:
      enabled: true
      externalServer: onlyoffice.my-domain.com