I have a public-facing server on (let's say) 10.5.0.1, which forwards requests to 10.5.0.2, which is running oTree. I noticed that this setup does not make oTree offer https:// URLs, even with the following headers set in nginx:

    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Front-End-Https on;
    proxy_set_header X-Forwarded-Protocol https;
    proxy_set_header X-Forwarded-Ssl on;
    proxy_set_header X-Url-Scheme https;

However, if I ssh into 10.5.0.1, with remote port forwarding set such that I can let nginx forward the request to 127.0.0.1:myport, which in turn redirects it to 10.5.0.2 over the ssh tunnel, then oTree does offer https:// URLs, without any further changes required. So I guess that oTree somehow notices that the request does not originate from 127.0.0.1 and decides to use http:// instead of https://.

This seems bad, since all requests, likely including those with WebSockets, are first forced through the insecure http.

Is there a way to make oTree respect a header like X-Forwarded-Protocol?