Overview
This article describes a known issue affecting ONLYOFFICE DocSpace installations accessed through a Synology NAS reverse proxy (DSM), where DocSpace generates HTTP links for static resources instead of HTTPS. This causes browsers to block the content as Mixed Content, preventing the login page or UI from loading correctly over HTTPS.
Affected Setup
- ONLYOFFICE DocSpace (self-hosted, Linux)
- Synology NAS acting as an HTTPS reverse proxy (DSM uses nginx/OpenResty internally)
- DocSpace running on HTTP internally (e.g.,
192.168.x.x:80), exposed externally via HTTPS through the Synology reverse proxy
Root Cause
The root cause is a bug in DocSpace's internal OpenResty configuration (/etc/openresty/conf.d/onlyoffice-proxy.conf). The $scheme variable in that file always resolves to http (since DocSpace itself runs on HTTP internally), which overwrites the correct X-Forwarded-Proto: https header sent by the Synology proxy. As a result, DocSpace generates HTTP-based URLs for all static assets, which the browser blocks under its Mixed Content security policy when the page is loaded over HTTPS.
A secondary contributing factor: DocSpace also ignores the X-Forwarded-Proto header if the proxy's IP address is not listed in the knownNetworks trusted proxy list in the DocSpace configuration.
This bug has been acknowledged and a permanent fix is included in upcoming DocSpace releases.
Symptoms
- Login page does not load when accessed via the external HTTPS domain.
- Browser console shows Mixed Content errors (static resources being requested over
http://while the page ishttps://). - Direct internal HTTP access (e.g.,
http://192.168.x.x:80) continues to work. - External access over HTTPS does not improve after adding
X-Forwarded-Proto: httpsandX-Forwarded-Hostheaders to the Synology reverse proxy configuration.
Solution
Two complementary approaches were used to resolve the issue. Apply both for a complete fix.
Step 1 — Fix the OpenResty proxy configuration (primary fix)
This patches the internal DocSpace proxy config so it correctly uses the X-Forwarded-Proto header passed by the upstream Synology proxy instead of always falling back to $scheme (which is always http internally).
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 OpenResty configuration and reloads OpenResty to apply the change.
Step 2 — Add the Synology subnet to DocSpace's trusted proxy list (recommended)
Even with the correct X-Forwarded-Proto: https header being forwarded by Synology, DocSpace may still ignore it if the Synology proxy's IP is not in the trusted networks list. Adding the local subnet resolves this.
1. Identify the environment and locate the active config file:
ENVIRONMENT=$(grep -oP 'ENVIRONMENT=\K.*' /etc/onlyoffice/docspace/systemd.env)
CONFIG="/etc/onlyoffice/docspace/appsettings.$ENVIRONMENT.json"
2. Back up the configuration:
cp -rf "$CONFIG" "$CONFIG.bak"
3. Add the knownNetworks entry for the Synology subnet (adjust the subnet to match your network):
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"]'
4. Verify the change was applied correctly:
json -f "$CONFIG" core.hosting.forwardedHeadersOptions.knownNetworks
5. Restart all DocSpace services:
systemctl restart docspace-*
Rollback
If any step causes additional issues (e.g., internal HTTP access breaking), restore the configuration backup and restart services:
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
Synology Reverse Proxy Configuration Requirements
Ensure that the Synology DSM reverse proxy rule for DocSpace includes the following custom headers (set via Control Panel > Login Portal > Advanced > Reverse Proxy > Custom Header):
| Header Name | Value |
|---|---|
| X-Forwarded-Proto | https |
| X-Forwarded-Host | $host |
Also add WebSocket support headers (Upgrade, Connection) as required by DocSpace.
Status
The root cause (incorrect use of $scheme in onlyoffice-proxy.conf) has been confirmed as a bug on the ONLYOFFICE side and has been fixed in the DocSpace source repository. The fix will be included in a future DocSpace release. Until then, the sed command in Step 1 serves as the recommended workaround.
Related Documentation
Comments
0 comments
Please sign in to leave a comment.