DocSpace Not Accessible via HTTPS Behind Synology Reverse Proxy

Overview

This article describes a known issue where ONLYOFFICE DocSpace on-premises is inaccessible or shows broken static content when placed behind the Synology DSM (DiskStation Manager) built-in Nginx reverse proxy. The root cause is a bug in DocSpace's internal OpenResty proxy configuration that overwrites the forwarded protocol header, causing DocSpace to generate HTTP links for static assets even when the connection arrives over HTTPS.

Affected Setup

• ONLYOFFICE DocSpace on-premises (Linux, systemd-managed)
• Synology NAS with DSM acting as the external reverse proxy (SSL termination)
• Synology forwards HTTPS traffic to DocSpace on HTTP (port 80) on the internal network
• External access via HTTPS fails: login page does not load, or browser console shows mixed content errors
• Internal access via HTTP may also break after attempting some workarounds

Root Cause

Synology DSM terminates SSL and forwards requests to DocSpace over HTTP, correctly passing the X-Forwarded-Proto: https header. However, DocSpace's internal OpenResty configuration file (/etc/openresty/conf.d/onlyoffice-proxy.conf) was overwriting this header by using $scheme (which evaluates to http on the internal leg) instead of preserving the upstream-provided value. As a result, DocSpace generated http:// URLs for static files, which browsers blocked as mixed content.

Secondary factor: DocSpace also ignores the X-Forwarded-Proto header if the originating proxy IP is not listed as a trusted network in the forwardedHeadersOptions.knownNetworks configuration. This can cause the same symptom even after the OpenResty fix is applied, depending on network topology.

Solution

Two steps are required. Apply the OpenResty fix first (permanent fix, included in future DocSpace releases). If the problem persists, also apply the knownNetworks configuration.

Step 1 — Fix the OpenResty proxy configuration (primary fix)

This corrects the header overwrite in DocSpace's internal proxy. Run the following command on the DocSpace server:

sed -i 's/\$scheme/\$proxy_x_forwarded_proto/' /etc/openresty/conf.d/onlyoffice-proxy.conf && openresty -s reload

This replaces $scheme with $proxy_x_forwarded_proto in the proxy config, ensuring DocSpace reads the forwarded protocol value from the upstream proxy (Synology) rather than calculating it internally.

> Note: This fix is temporary at the file level — it will be included in a future DocSpace release. Re-check after DocSpace upgrades.

Step 2 — Add Synology subnet to DocSpace trusted networks (secondary fix, if needed)

If DocSpace still generates incorrect HTTP links after Step 1, or if internal access is also broken, you need to add the Synology/internal subnet to DocSpace's list of trusted forwarded-header sources.

2a. Back up the current configuration

ENVIRONMENT=$(grep -oP 'ENVIRONMENT=\K.*' /etc/onlyoffice/docspace/systemd.env)
CONFIG="/etc/onlyoffice/docspace/appsettings.$ENVIRONMENT.json"
cp -rf "$CONFIG" "$CONFIG.bak"

2b. Add the knownNetworks entry

Replace 192.168.0.0/16 with the actual subnet of your Synology/internal network if different:

sudo json -I -f "$CONFIG" -e 'this.core??={}'
sudo json -I -f "$CONFIG" -e 'this.core.hosting??={}'
sudo json -I -f "$CONFIG" -e 'this.core.hosting.forwardedHeadersOptions??={}'
sudo json -I -f "$CONFIG" -e 'this.core.hosting.forwardedHeadersOptions.knownNetworks=["192.168.0.0/16"]'

2c. Verify the configuration and restart services

json -f "$CONFIG" core.hosting.forwardedHeadersOptions.knownNetworks
systemctl restart docspace-*

Reverting the configuration (if needed)

If any step causes additional issues (e.g., internal HTTP access stops working), restore the configuration backup:

ENVIRONMENT=$(grep -oP 'ENVIRONMENT=\K.*' /etc/onlyoffice/docspace/systemd.env)
CONFIG="/etc/onlyoffice/docspace/appsettings.$ENVIRONMENT.json"
cp "$CONFIG.bak" "$CONFIG"
systemctl list-units -q --plain 'docspace-*' | awk '{print $1}' | xargs systemctl restart

Expected Outcome

After applying Step 1 (and Step 2 if necessary), DocSpace will correctly recognize the incoming connection as HTTPS and generate https:// URLs for all static assets. The login page will load normally through the Synology reverse proxy.

Additional Notes

• The underlying bug in onlyoffice-proxy.conf is confirmed as an ONLYOFFICE-side issue and is scheduled to be fixed in a future DocSpace release.
• When setting knownNetworks, use the broadest subnet that covers your Synology NAS IP. For example, 192.168.0.0/16 covers the common 192.168.x.x range, but adjust as needed.
• Always create a server snapshot before modifying DocSpace configuration files.
• For general guidance on proxy headers (X-Forwarded-Proto, X-Forwarded-Host), see: Using ONLYOFFICE Docs behind the proxy
• For DocSpace troubleshooting reference: DocSpace Troubleshooting