Reverse Proxy Troubleshooting

Set the external HTTPS origin and the CIDR of the proxy that connects directly to SimpleDMS:

SIMPLEDMS_PUBLIC_ORIGIN=https://dms.example.com
SIMPLEDMS_TRUSTED_PROXY_CIDRS=192.0.2.10/32
SIMPLEDMS_ALLOW_INSECURE_COOKIES=false

Replace both example values. Restart SimpleDMS after changing them.

SIMPLEDMS_PUBLIC_ORIGIN must contain the public https:// origin without a trailing path. Do not use the internal container name or port. Include the external port only when the public URL uses a non-standard port.

SIMPLEDMS_TRUSTED_PROXY_CIDRS accepts comma-separated IPv4 and IPv6 CIDR prefixes. Examples include:

• 192.0.2.10/32 for one IPv4 proxy
• 2001:db8::10/128 for one IPv6 proxy
• 172.20.0.0/24 for a dedicated Docker proxy network
• 127.0.0.1/32,::1/128 when the proxy connects through the loopback interface

Raw addresses without a prefix length are invalid. 0.0.0.0/0 and ::/0 are valid CIDRs but must not be trusted because every source could claim forwarded HTTPS and client addresses.

Keep SIMPLEDMS_ALLOW_INSECURE_COOKIES set to false. The browser receives the session cookie through the public HTTPS connection, so the unencrypted connection between the proxy and SimpleDMS does not require insecure cookies. Enable this setting only for direct HTTP access outside localhost.

The trusted CIDR must contain the immediate network peer as seen by SimpleDMS. It is not the browser, scanner, public server address, or DNS address unless that address belongs to the connecting proxy.

For Docker, inspect the network shared by SimpleDMS and the reverse proxy. Use its configured subnet or, preferably, a stable proxy address with /32 or /128. A container address can change after recreation unless the network assigns it explicitly.

For a proxy on the same host, the peer may be a loopback, bridge, or host gateway address depending on the container network mode.

The reverse proxy must preserve the public host and replace client-supplied forwarding headers.

The public-facing proxy must not pass arbitrary incoming X-Forwarded-Proto or X-Forwarded-For values unchanged. If several trusted proxies are chained, configure every hop deliberately and trust only proxy addresses that you operate. Only a trusted immediate network peer can assert HTTPS to SimpleDMS.

If SimpleDMS reports that SIMPLEDMS_PUBLIC_ORIGIN must be an absolute HTTPS URL, check that:

• the value starts with https://
• it contains the public hostname
• it does not contain an internal Docker hostname
• the environment variable is available inside the SimpleDMS container

This check is enabled whenever SIMPLEDMS_TRUSTED_PROXY_CIDRS contains at least one CIDR.

If the sign-in page reports that HTTPS is required even though the public URL uses HTTPS, verify that:

• the proxy sends X-Forwarded-Proto: https
• the immediate proxy address matches SIMPLEDMS_TRUSTED_PROXY_CIDRS
• the proxy replaces client-supplied forwarding headers

Do not enable SIMPLEDMS_ALLOW_INSECURE_COOKIES as a workaround. Correcting the trusted proxy configuration keeps the session cookie secure.

SimpleDMS rejects WebDAV before authentication when it cannot verify a secure connection. A reverse-proxy request is secure only when:

• the immediate proxy address matches SIMPLEDMS_TRUSTED_PROXY_CIDRS
• the proxy sends X-Forwarded-Proto: https
• the request reaches the WebDAV URL generated by SimpleDMS

An untrusted forwarded request receives 403 Forbidden without a Basic Authentication challenge. This prevents clients from sending credentials over a connection that SimpleDMS considers insecure.

After correcting the configuration, test the root WebDAV URL copied from SimpleDMS:

curl -i --user 'dav_username' -X OPTIONS 'https://dms.example.com/webdav/TENANT_ID/SPACE_ID/'

Enter the secret when curl prompts for a password. A valid connection returns 200 OK and WebDAV response headers.

SimpleDMS uses the trusted X-Forwarded-For chain for WebDAV authentication rate limits. The public-facing proxy should replace incoming client-supplied values with the actual client address. Invalid or untrusted chains fall back to the immediate network peer.

If all devices appear to share one rate limit, verify that the proxy sends the client address and that its immediate address is trusted.