Reverse Proxy Configuration
This section describes how to integrate Sync-in with an existing reverse proxy.
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 |
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 443 ssl http2;
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
proxy_read_timeout 900s;
proxy_send_timeout 900s;
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 OnlyOffice Docker container is running locally
# and you are not using an external URL.
# Uncomment the line below to enable it:
# include onlyoffice.conf;
}
OnlyOffice Configuration (optional)
In both modes, the OnlyOffice feature must be enabled in the environment.yaml
configuration file:
applications:
files:
onlyoffice:
enabled: true
Advanced OnlyOffice parameters are detailed in the Server Parameters section.
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
:
onlyoffice:
externalServer: onlyoffice.my-domain.com
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;
}