1. Caddy version (caddy version):
v2.1.1 h1:X9k1+ehZPYYrSqBvf/ocUgdLSRIuiNiMo7CvyGUQKeA=
2. How I run Caddy:
a. System environment:
FreeNAS 11.3-U4.1
b. Command:
service caddy start
c. Service/unit/compose file:
Not applicable
d. My complete Caddyfile or JSON config:
See below.
3. The problem I’m having:
See below.
4. Error messages and/or full log output:
See below.
5. What I already tried:
See below.
6. Links to relevant resources:
See below.
7. Below 
Rather than fill in the proforma, I thought it better to tell the story in chronological order. It will make more sense that way.
I’ve got two instances of Nextcloud that I’m testing. The first is in a FreeNAS jail and the second in a Docker container running on a Ubuntu 18.4.04 virtual machine also on FreeNAS. At this point, the key difference between the jail and the container is that in the jail, all the Nextcloud dependencies have to be considered, whereas, in the containerised version, all Nextcloud dependencies are already taken of, so it’s almost plug-n-play.
Both instances are unsecured. They’re accessible via http. A separate Caddy reverse proxy handles TLS termination for the Nextcloud instances.
Nextcloud in a FreeNAS jail
Caddy was selected for the Nextcloud web server. The Caddyfile used was based on the Caddy code block result from the thread Help to migrate Caddyfile V1 to V2 for Nextcloud.
{
# debug
}
cloud.udance.com.au:80, 10.1.1.29:80 {
root * /usr/local/www/nextcloud
file_server
log {
output file /var/log/cloud.udance.com.au.log
format single_field common_log
}
php_fastcgi 127.0.0.1:9000 {
env front_controller_active true
}
redir /.well-known/carddav /remote.php/dav 301
redir /.well-known/caldav /remote.php/dav 301
# .htaccess / data / config / ... shouldn't be accessible from outside
@forbidden {
path /.htaccess
path /data/*
path /config/*
path /db_structure
path /.xml
path /README
path /3rdparty/*
path /lib/*
path /templates/*
path /occ
path /console.php
}
respond @forbidden 404
}
When the unsecured Nextcloud instance is accessed and checked for warnings, this is what I see.
This is expected for an unsecured Nextcloud instance.
Now when I place this Nextcloud instance behind the Caddy reverse proxy using the Caddyfile block below…
# Nextcloud - FreeNAS Jail
cloud.udance.com.au {
encode gzip
import dnschallenge
reverse_proxy http://10.1.1.29
}
…the unsecured access warnings disappear.
This also is an expected result.
Nextcloud in a Docker Container
An official version of the Nextcloud container from Docker Hub was used. It uses an Apache webserver. When this unsecured Nextcloud instance is accessed, I get the same result as for the unsecured jail instance of Nextcloud. So far, so good.
The difference comes about when I place this Nextcloud instance behind the Caddy reverse proxy using a very similar Caddyfile code block:
# Nextcloud in a Docker Container
cloud5.udance.com.au {
encode gzip
import dnschallenge
reverse_proxy http://10.1.1.18:8000
}
These are the warnings I see:
It’s close, but not quite the same. There are now warnings about the web server (I’m assuming the Apache web server) not being properly set up to handle caldav and carddav. The warnings refers me to this documentation. I check the Apache web server and I can see that it’s already configured for service discovery.
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} DavClnt
RewriteRule ^$ /remote.php/webdav/ [L,R=302]
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json [QSA,L]
RewriteRule ^\.well-known/webfinger /public.php?service=webfinger [QSA,L]
RewriteRule ^\.well-known/nodeinfo /public.php?service=nodeinfo [QSA,L]
RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
RewriteRule ^remote/(.*) remote.php [QSA,L]
RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
RewriteCond %{REQUEST_URI} !^/\.well-known/(acme-challenge|pki-validation)/.*
RewriteRule ^(?:\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>
I enter https://cloud5.udance.com.au/.well-known/carddav into a browser and it does get redirected to https://cloud5.udance.com.au/remote.php/dav/. I start to get a little suspicious. I begin to think that maybe these are phantom warnings. Still, it’s disconcerting to see them there.
So, I go searching and I get to this wonderful Nextcloud forum thread HowTo: Ubuntu + Docker + Nextcloud + Talk + Collabora, which I’ve since closely referred to when setting up the Docker version of Nextcloud. In this instance, the writer has used an Apache reverse proxy. What caught my attention were the following lines in one of the reverse proxy configuration files:
RewriteRule ^/\.well-known/carddav http://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
RewriteRule ^/\.well-known/caldav http://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
My question (after all that!) is 'Do I need to do something similar in the Caddyfile code block I use to interact with the Docker version of Nextcloud?