When Chevereto is deployed via Docker and you want to publish it to the public internet, it is usually done through a reverse proxy with SSL enabled on the reverse proxy. However, this raises an issue: Chevereto does not know that visitors will access it via HTTPS (normally, Docker maps HTTP ports externally because HTTPS requires configuring certificates inside the container, which many people are reluctant to do, including me~. And actually, it's not just Chevereto; many applications have this issue). The reverse proxy also uses the HTTP method when configuring the target URL. In this case, the following error will occur:

The plain HTTP request was sent to HTTPS port

At this time, accessing the Chevereto page will look like this:

While the normal situation is as follows:

Due to the reasons mentioned above, the content responded by Chevereto all starts with http, and the client browser will use http for subsequent accesses. However, because the reverse proxy uses https, receiving an http request on an https port results in the aforementioned error.

The solution is very simple, with two approaches to choose from:
Directly tell Chevereto that the user is using the HTTPS protocol
"X-Forwarded-Proto" tells the backend server that the real protocol used by the client is https, and the response needs to use https instead of http. You only need to add the following code to the reverse proxy configuration:

proxy_set_header X-Forwarded-Proto https;

Directly modify Chevereto's response content
When the reverse proxy receives the http response content sent back by Chevereto, it directly uses "proxy_redirect" to change http to https and then sends it back to the user. You only need to add the following code to the reverse proxy configuration:

proxy_redirect http:// https://;

Of course, you can also use both methods together for double insurance :)

However, this is only the simplest case of a 1-tier reverse proxy, which is: User -> Reverse Proxy -> Chevereto. The actual production environment cannot be this simple. For example, my current setup is: CDN -> Main Reverse Proxy -> WAF (which also works as an HTTP reverse proxy) -> Chevereto. If problems occur in this situation, you need to consider multi-tier reverse proxies:
If using the "X-Forwarded-Proto" method, the simplest way is to configure it on the WAF (the reverse proxy closest to Chevereto), because Chevereto is right behind the WAF, so you can just tell it directly. Of course, from a standard perspective, it should be configured on the main reverse proxy and then passed through the WAF (usinghttp_x_forwarded_proto), which won't be detailed here.
If using the "proxy_redirect" method, you can directly modify Chevereto's response on the main reverse proxy. By the way, "proxy_redirect" is very powerful. In fact, if you don't mind the trouble,you don't even need to use host, and no matter how ridiculous the response returned by the application is, it can be modified directly~.

Note: Actually, this has a lot to do with the application itself. Chevereto does not have the function to customize the access protocol, domain name, and port, while some applications, such as WordPress, can define the access URL (protocol, domain name, port) by themselves: