Docker, reverse proxy, and trusted domains

I did it through nginx and forwarded my localhost to my subdomain and set the ssl ettings in the UI and put my subdomain in the trusted domain section. And it worked

so i would rather recommend the subdomain

image

Did you need to set any of the environment variables described in the container documentation (see Using the apache image behind a reverse proxy), such as TRUSTED_PROXIES?

Not really, i just set it up as the UI said and i had a calddav problem but it got solved in my other topic and thats it now. Sorry but i am very fresh to the topic.

There must be differences in the way proxies behave with respect to how they rewrite client requests. Hopefully someone will answer with the needed understanding of how the application evaluates whether the request is trusted.

Please try passing below environment variable to your nextcloud docker container:

                "NEXTCLOUD_TRUSTED_DOMAINS=nextcloud.example.com",

Based on the documentation, this variable is used for autoconfiguration when the container is initialized, after which time it has no effect.

I have set the trusted_domains value through the configuration command, as explained in another discusssion.

trusted_hosts should the name/ip of your reverse proxy (in docker usually the container_name)
trusted_domain is the hostname you use to access you application like nextcloud.my.domain

there are only few variables please read and understand the reverse proxy manual carefully… and once it doesn’t work collect configs and logs so we can see what is going wrong

Here is my configuration. I use nginx reverse proxy, which I had to learn as I came from Apache. I’m a non-expert in both, having worked in IT years ago.
Everything works on my system. I need to point out that some of the entries I could have removed as they’re redundant and you will see a lot of # where I’ve edited out config and not returned to clean up the files so apologies for the mess.
192.168.1.4 is my server.
192.168.1.1 is my router.
nextcloud.domainname.com represents my domain name edited for privacy.
I use the reverse proxy to handle the SSL from acme and the config for CALDAV and CARDDAV.
I haven’t seen your configuration but wwe has give you the answer correctly. Although, I think you need to see an example.
My nextcloud is in a docker. I always upgrade nextcloud inside the docker, rather than the docker itself. Be aware of differences like php versions etc. I would not recommend simply copying my config but trying to check the differences between mine and yours.

Happy to try and help, but I’m very busy at the moment with some tight deadlines so apologies if I don’t respond in a hurry. Once again, I’m not an expert but I’ve invested a lot of time getting my system how I want it. The experts may even read my config and laugh but it gets an A+ security rating from Nextcloud when I do a security check.

NOTE: The intention was to upload my config files in a quote. The quote function on this forum thread is terrible!!
You can pull it from here:
Nextcloud and nginx reverse proxy configuration

Let me know if this helps, I’d like to know if I helped somebody :wink:

Also, I’m running similarly to copaxy’s configuration. My docker is sitting on unRaid.

@wwe: I suppose I had confused trusted_hosts and trusted_domains.

I have now set trusted_domains to the domain name for use by the client browser, and trusted_hosts to the name of the container as understood by Docker. I have kept also trusted_proxies unset.

I no longer see the error message generated by Nextcloud, but instead find that the Nextcloud returns a redirect command that affects the domain name. This change causes further problems.

How would I configure Nextcloud to keep from redirecting to a different host name than was originally used by the client?

I am sorry if these answers might be available from the documentation, but after reviewing it, I find a great deal of confusion from the various manuals and deployment styles.

brainchild, you need to consider that we have to imagine what your issue is, because you’re not providing enough information ie. screenshots, logs, etc.
If you are using a reverse proxy, why would you leave it unset? You need to tell Nextcloud to trust that proxy.
Also, did you look at the configuration in the link that I’ve shared with you?

You’ve provided very little information to try and get the issue resolved.

At this time, I am trying to understand which variables should take which values for us to expect the application to behave as desired.

Once we reach that point, it may be helpful for me to share logs, configuration files, and so. For the time being, I would rather get advice on the proper settings for the variables. I have no reason for not setting trusted_proxies other than not currently having reached an understanding of what value it should have for the particular configuration.

Unfortunately, as I say, the various documents have caused me confusion about how each variable is used in different contexts.

As long as I am not understanding what value the variables should take, I feel that screenshots and logs are more likely to be distracting than helpful. Thanks.

Uuhhmm…okay :roll_eyes:. I guess we all need to decide what our troubleshooting methodology looks like. I’ll leave up the link to my configuration, it may help others.

Good luck!

@conradp24: I think your idea of troubleshooting methodology is fine. It may be more helpful, however, to think of my inquiry as about understanding the meanings of the configuration variables, rather than as about troubleshooting.

did you read Nexcloud documentation? all the variables are clear described there. docker documentation explains how to use them in docker environment

the variables clearly described there:

  • overwritehost set the hostname of the proxy. You can also specify a port.
  • overwriteprotocol set the protocol of the proxy. You can choose between the two options http and https.
  • overwritewebroot set the absolute web path of the proxy to the Nextcloud folder.
  • overwritecondaddr overwrite the values dependent on the remote address. The value must be a regular expression of the IP addresses of the proxy. This is useful when you use a reverse SSL proxy only for https access and you want to use the automatic detection for http access.

If you still hit some issue please describe the problem in detail, so we can understand it and help you to solve it.

I had read the documentation, and found it quite confusing.

The most recent problem was resolved by setting overwriteprotocol to https, though it seems to me this particular inference is impossible from the documentation alone. At present, I believe the entire installation is functioning, at least with respect to the issues immediate to my question.

I would like to express my view that the documentation for the container might be improved greatly through giving it a more direct and accessible structure, as well as clarification of how the various explanations for container usage relate to the general usage of the application. A helpful approach might be giving a clear indication of whether any explanation of the former simply reiterates the design of the application generally, or rather illustrates augmented or distinctive behavior compared to the latter.

Comments such as the following would be helpful, in the appropriate case:

  • The following summarizes Nextcloud behavior, which is described in greater detail in the general manual.

  • Nextcloud running from the official Docker container behaves differently from a regular installation the following ways.

The documentation for the configuration options in the general manual, for the most part, also is confusing and unclear.

Generally, helpful documentation of a configuration parameter includes answers to a combination of several of the following questions:

  • Which components read the value?
  • When do they read the value?
  • How does the value affect their behavior?
  • In which cases should the user or administrator override the default, and what considerations might be applied to selecting a desired value?
  • What is the context that makes this parameter a helpful part of the overall design?

Following are some examples, for various parameters, of documentation that might be much more helpful than those in the current revision of the manual:

  • overwriteprotocol: May be set to either of http or https.

    Nextcloud normally assumes that the client should use same protocol, that is, secure versus insecure HTTP, for access to Nextcloud, as used by any proxy, and will try to change the address for client access accordingly, by returning a HTTP redirect directive each time the client uses the other protocol. If the protocol for client access is different than for access by the proxy , then this this value must be set to the protocol to be used by the client. For example, if the connection between Nextcloud and the proxy is insecure, but clients are to use a secure connection, then this value must be set to https.

  • trusted_hosts: The host names, as appears in the address, clients are allowed to use for accessing Nextcloud.

    For security, Nextcloud allows access only through host names designated in the site configuration. Access through other host names will generate an error page. This value always should be set to the allowed host names for access directly by the client, even if the client is accessing Nextcloud through a reverse proxy. Note this parameter is different from trusted_domains, which establishes trust for the reverse proxy.

2 Likes

I agree this might be be described better for beginners… You went a hard way to understand how it works - please write either a guide here or even better create a pull request with improved version of the manual…

My summary - Nextcloud running behind reverse proxy (especially docker) has no idea how the client can reach resources like files…

say you have a docker container called nextcloud and you access it using public DNS record https://mynextcloud.dyndns.xyz. you reverse proxy traefik/nginx/apache terminates TLS and sends all requests without TLS to your nextcloud container. by default Nextcloud would use the protocol of incoming request and build the URL for *mycat.png as http://nextcloud/files/mycat.png to make URLs on Nextcloud work your container must build URLs like https://mynextcloud.dyndns.xyz/files/pictureofmycat.png where

  • rewrite http:// to https:// is controlled by OVERWRITEPROTOCOL
  • rewrite nextcloud to mynextcloud.dyndns.xyz is controlled by OVERWRITEHOST
  • and trusted_proxies define the proxy host which is allowed to perform requests for another clients
1 Like

Based on certain comments in the documentation, I came to understand that many proxies save information about the original request in extended header fields. Might Nextcloud apply the values of those fields to resolve a resource address appropriate for the original request form the client?

trusted_proxies variable instructs Nextcloud to check x_forwarded_for (and x_real_ip?) flags. but maybe not every piece of information is passed (by every proxy). I think the overwrite* settings are the most stable solution.

My suggestion is to use whatever fields are made available by the proxy to guess as accurately as possible how to reconstruct the client address, even if those same fields may not be available from other proxies. This design simplifies site configuration in many cases. The main drawback is reduced portability of the same application deployment through different proxies, but I suggest that this problem is a smaller inconvenience compared to the alternative, since changing proxies on the same site is not a common event.

With respect to the logic currently in place, explained to some degree in the manual, and which you have tried to clarify, I remain very confused. Hopefully, someone who understands the design would be able to update the manual to make it more helpful for those with limited familiarity of these systems.

If I might make one more suggestion, rather than separate fields for hosts and protocols, I would find it simpler to provide a list of full addresses (e.g. http://cloud.domain.xyz) of possible base addresses for client access, and let the application choose the best match from the list based on the fields available in the request header.