Custom Header not recognized by Nextcloud about zoraxy

[Shotte]

@tobychui finally I fixed it by using secure (https) connection on nextcloud site syncing your certs to my nextcloud instance and adding all redirects to nginx config file.
However, everything is working now fine. A big thank you to your good work.

[tobychui]

Hi @Shotte
Can you check if the custom headers are successfully passed to your NextCloud instance with the following debug php script?
debug.zip

Are those warning output generated from front-end or backend? Note that the custom header only adds the header when a request is proxying to the backend server (client -> server) , but not appending them in the response from the backend (server -> client).

[Shotte]

Hi @tobychui ,

thank you for your quick response. I executed the script on Nextcloud site twice:
first using Zoraxy, second using Nginx Proxy Manager

The messages are generated in Nextcloud backend (after logging in as admin going to site management / admin page) executing the built-in configuration checker.

Comparing both outputs I can see the following differences. It looks like the Real-IP and Forwarded-For IP adresses might make the difference. On Zoraxy its the docker container address and on NPM its my hardware gateway.

Detailled Zoraxy results (I can see ythe header but seems to be ignored by Nextcloud):

REQUEST HEADERS
X-Xss-Protection: 1; mode=block
X-Robots-Tag: noindex, nofollow
X-Real-Ip: 172.31.0.1
X-Frame-Options: SAMEORIGIN
X-Forwarded-Server: zoraxy-93961920-d335-4b1e-bf94-4893c5c80189
X-Forwarded-Proto: https
X-Forwarded-Host: my.domain.de
X-Forwarded-For: 172.31.0.1
X-Content-Type-Options: nosniff
Upgrade-Insecure-Requests: 1
Sec-Fetch-User: ?1
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-Dest: document
Referrer-Policy: no-referrer
Pragma: no-cache
Cookie: __Host-nc_sameSiteCookielax=true; __Host-nc_sameSiteCookiestrict=true; oc_sessionPassphrase=o6JV%2FmOdkE3CQu2N3zUA6JTYiQoZxZNTrHJTEhN5YL8YtG4qBjOo23g8xxEK2%2F0ZP4TBz69ZRxWFIK%2F0UFtDQ%2BVPkovxRf5XQyFUDq3phLjJiPXaDu5pljDwmlAnWmBp; ocxbl29avcep=27oq94jgr6novl8f1ud3bcjt69
Cache-Control: no-cache
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0
Host: my.domain.de
Content-Length:
Content-Type:
APACHE VARIABLES
HTTP HEADERS
HTTP_ACCEPT : text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8
HTTP_COOKIE : __Host-nc_sameSiteCookielax=true; __Host-nc_sameSiteCookiestrict=true; oc_sessionPassphrase=o6JV%2FmOdkE3CQu2N3zUA6JTYiQoZxZNTrHJTEhN5YL8YtG4qBjOo23g8xxEK2%2F0ZP4TBz69ZRxWFIK%2F0UFtDQ%2BVPkovxRf5XQyFUDq3phLjJiPXaDu5pljDwmlAnWmBp; ocxbl29avcep=27oq94jgr6novl8f1ud3bcjt69
HTTP_FORWARDED :
HTTP_HOST : my.domain.de
HTTP_PROXY_CONNECTION :
HTTP_REFERER :
HTTP_USER_AGENT : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0
CONNECTION & REQUEST
AUTH_TYPE :
CONN_REMOTE_ADDR :
CONTEXT_PREFIX :
CONTEXT_DOCUMENT_ROOT :
IPV6 :
PATH_INFO :
QUERY_STRING :
REMOTE_ADDR : 192.168.8.12
REMOTE_HOST :
REMOTE_IDENT :
REMOTE_PORT : 47858
REMOTE_USER :
REQUEST_METHOD : GET
SCRIPT_FILENAME : /var/www/nextcloud/debug.php
SERVER INTERNALS
DOCUMENT_ROOT : /var/www/nextcloud
SCRIPT_GROUP :
SCRIPT_USER :
SERVER_ADDR : 192.168.8.16
SERVER_ADMIN :
SERVER_NAME : my.domain.de
SERVER_PORT : 80
SERVER_PROTOCOL : HTTP/1.1
SERVER_SOFTWARE : nginx/1.25.4
DATE & TIME
TIME_YEAR :
TIME_MON :
TIME_DAY :
TIME_HOUR :
TIME_MIN :
TIME_SEC :
TIME_WDAY :
TIME :
SPECIALS
API_VERSION :
CONN_REMOTE_ADDR :
HTTPS : on
IS_SUBREQ :
REMOTE_ADDR : 192.168.8.12
REQUEST_FILENAME :
REQUEST_SCHEME : http
REQUEST_URI : /debug.php
THE_REQUEST :

Detailled NPM results (no additional header infos there but everything is fine in Nextcloud):

REQUEST HEADERS
Cookie: __Host-nc_sameSiteCookielax=true; __Host-nc_sameSiteCookiestrict=true; oc_sessionPassphrase=o6JV%2FmOdkE3CQu2N3zUA6JTYiQoZxZNTrHJTEhN5YL8YtG4qBjOo23g8xxEK2%2F0ZP4TBz69ZRxWFIK%2F0UFtDQ%2BVPkovxRf5XQyFUDq3phLjJiPXaDu5pljDwmlAnWmBp; ocxbl29avcep=27oq94jgr6novl8f1ud3bcjt69
Cache-Control: no-cache
Pragma: no-cache
Sec-Fetch-User: ?1
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-Dest: document
Upgrade-Insecure-Requests: 1
Accept-Encoding: gzip, deflate, br
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0
X-Real-Ip: 192.168.16.1
X-Forwarded-For: 192.168.16.1
X-Forwarded-Proto: https
X-Forwarded-Scheme: https
Host: my.domain.de
Content-Length:
Content-Type:
APACHE VARIABLES
HTTP HEADERS
HTTP_ACCEPT : text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8
HTTP_COOKIE : __Host-nc_sameSiteCookielax=true; __Host-nc_sameSiteCookiestrict=true; oc_sessionPassphrase=o6JV%2FmOdkE3CQu2N3zUA6JTYiQoZxZNTrHJTEhN5YL8YtG4qBjOo23g8xxEK2%2F0ZP4TBz69ZRxWFIK%2F0UFtDQ%2BVPkovxRf5XQyFUDq3phLjJiPXaDu5pljDwmlAnWmBp; ocxbl29avcep=27oq94jgr6novl8f1ud3bcjt69
HTTP_FORWARDED :
HTTP_HOST : my.domain.de
HTTP_PROXY_CONNECTION :
HTTP_REFERER :
HTTP_USER_AGENT : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0
CONNECTION & REQUEST
AUTH_TYPE :
CONN_REMOTE_ADDR :
CONTEXT_PREFIX :
CONTEXT_DOCUMENT_ROOT :
IPV6 :
PATH_INFO :
QUERY_STRING :
REMOTE_ADDR : 192.168.8.12
REMOTE_HOST :
REMOTE_IDENT :
REMOTE_PORT : 47384
REMOTE_USER :
REQUEST_METHOD : GET
SCRIPT_FILENAME : /var/www/nextcloud/debug.php
SERVER INTERNALS
DOCUMENT_ROOT : /var/www/nextcloud
SCRIPT_GROUP :
SCRIPT_USER :
SERVER_ADDR : 192.168.8.16
SERVER_ADMIN :
SERVER_NAME : my.domain.de
SERVER_PORT : 80
SERVER_PROTOCOL : HTTP/1.1
SERVER_SOFTWARE : nginx/1.25.4
DATE & TIME
TIME_YEAR :
TIME_MON :
TIME_DAY :
TIME_HOUR :
TIME_MIN :
TIME_SEC :
TIME_WDAY :
TIME :
SPECIALS
API_VERSION :
CONN_REMOTE_ADDR :
HTTPS : on
IS_SUBREQ :
REMOTE_ADDR : 192.168.8.12
REQUEST_FILENAME :
REQUEST_SCHEME : http
REQUEST_URI : /debug.php
THE_REQUEST :

[tobychui]

@Shotte Then this seems like a NextCloud problem more than a Zoraxy problem to me.
Have you tried the solution mentioned here?

If you are running NextCloud in a docker, you might need to fix something in the docker. But you mention you want to migrate from nginx, so I assume you already get those done.

For HSTS, as I remember there are no support for HSTS yet, so that is kind of an expected behavior.

[Shotte]

@tobychui Potentially yes, that might be, but why do I have NO problems with niginx proxy manager, but using Zoraxy leads to problems? This makes no sense to me.

[tobychui]

@Shotte I have no idea.

Zoraxy follow standard HTTP protocols. The only reason I come up with is most open source project out there are only tested against Apache and / or Nginx which has some legacy code that behave weirdly. And most well known open source projects are too big / exists long enough that other smaller proxy projects need to implement similar "weird behavior" to compensate for them.

Anyway, if you figure out why, please let me know so I would add a compatibility mode to Zoraxy for docker based NextCloud use cases.

[Shotte]

@tobychui Ok, I fixed it partly. I simply added header infos to local nginx server which serves the Nextcloud files. Only the "/.well-known/webfinger" and the "/.well-known/nodeinfo" were left. This could not be fixed on Nextcloud side.
To get rid of the "/.well-known/carddav" and "/.well-known/caldav" messages I added virtual directory rules at Zoraxy, but this did not work for the webfinger / nodeinfo directory redirects. This is again a situation which makes no sense to me.

However I was very pleased by your quick responses and your very good help. Thank you for that. I will stay at Zoraxy because your tool is really simple and provides so much more than NPM. Thank you for your good work.

[tobychui]

@Shotte have you tried the redirect function instead of virtual directory?
In general, /.well-known/ is not much difference from other subpath of your HTTP proxy target which, by default, is proxying to your Nextcloud host / container. So if other proxy endpoint works, this should also works.

[Shotte]

@tobychui nether virtual directory nor redirection is working. It seems that the virtual directory and redirection settings are adding a trailling slash "/" even though i haven't configured it. Removing it manually shows the correct page(s).

[tobychui]

Oh you were using plain HTTP for NextCloud? No wonder 🤔

[Shotte]

@tobychui Please explain "no wonder". In my understanding there is no need for secured communication behind a reverse proxy, which causes additional load and requires additional work due to certificates etc.
Or has it todo with the header information, which is recognized and which not? I have not that deep knowlegde about these topics as your have.

[tobychui]

@tobychui Please explain "no wonder". In my understanding there is no need for secured communication behind a reverse proxy, which causes additional load and requires additional work due to certificates etc.
Or has it todo with the header information, which is recognized and which not? I have not that deep knowlegde about these topics as your have.

Many old open source project born before HTTPS era did not design to be reverse proxied. Like WordPress for example, you need to change a few lines of code in their php script to make it accept HTTPS headers that is added by the proxy layer but it (the WordPress instance) is actually receiving HTTP.

That is why the "skip TLS verification" function exists. It allows you to self sign some cert that pretty much won't expire and fake the instance thinking they are self hosting a valid certificate. Anyway, more modern open source projects are doing better in this regards so I guess this is just another edge case regarding your specific setup with NextCloud.

If you would like, you can contribute a wiki page on how to fix your issue. It might be helpful to future users. :)

[tobychui]

@Shotte Yes, you are right about the security things, I just means "it is another werid issue cause by HTTPS to HTTP proxy".
To be honest, from all the issues I am getting with Zoraxy (and what I saw from other newer open source reverse proxy projects), I can only conclude these weird issues were brought by legacy code in handling headers. Most of the weird issues are from HTTPS -> RP to HTTP -> PHP based systems, and that is where my "no wonders" feeling kicks in.

[Shotte]

@tobychui You are the graetest. Thank you for your time and all your explanations.
Offtopic: By the way, when will the next release be proximately available? I would like to use the whitelist feature...

[tobychui]

@Shotte I guess the Whitelist feature is already patched in the v3.0.0r2 release (you can just re-download the release if you are using v3.0.0r1). As I am still busying with my thesis, probably sometime around mid April.

[boehamian]

@tobychui You are the graetest. Thank you for your time and all your explanations. Offtopic: By the way, when will the next release be proximately available? I would like to use the whitelist feature...

Hey mate, I have a nextcloud instance running on ubuntu 22.04. I am migrating from nginx proxy manager (don't get me started on the issues with that) and was looking at the documentation for CalDav and CardDAV. Do you know where these parameters from this documentation https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html go into zoraxy? Any help setting up nextcloud with zoraxy would be greatly appreciated. Like your posting here I have never had to do a custom header like you have. Maybe there is a reason in your instance.