Want to create a Caddyfile for Caddy2 that references a nextcloud reverse proxy on separate computer

Yeah. You’ll probably want to proxy over HTTP and not HTTPS though (because setting up mTLS is complicated and rarely worth the effort)

If I have a config like this I’m getting 400 bad request sent http to https error on nextcloud, is there an easy solution port is 443, should I be moving off of that port up to a different one so that the reverse proxy coming funneling through is only http expected?

Blockquote
{
email username@mail.com
}
(common) {
tls {
dns duckdns {env.DUCKDNS_TOKEN}
}
header {
Strict-Transport-Security “max-age=31536000; includeSubdomains”
X-XSS-Protection “1; mode=block”
X-Content-Type-Options “nosniff”
Referrer-Policy “same-origin”
-Server
Content-Security-Policy “frame-ancestors domain.duckdns.org:port *.domain.duckdns.org:port”
Permissions-Policy “geolocation=(self), microphone=()”
}
}
https://domain.duckdns.org:port {
import common
reverse_proxy 192.168.1.XX:443 {
}
}

‘’’

I have the port changed to 880 & 8443 and have a valid cert pulling up for the page Caddy config is implementing. I’m getting the webpage timing out and have tried changing the reverse proxy setting to https://192.168.1.XX:8443.

I’ve added the computer that is doing the reverse proxy as a trusted proxy in the config.php and added ‘forwarded_for_headers’ => array(‘HTTP_X_FORWARDED_FOR’), and set ‘overwriteprotocol’ => ‘http’, (I’ve actually tried this set to both https and http).

This is a better copy of my Caddyfile:

(common) {
        tls {
                dns duckdns {env.DUCKDNS_TOKEN}
        }
        header {
                Strict-Transport-Security "max-age=31536000; includeSubdomains"
                X-XSS-Protection "1; mode=block"
                X-Content-Type-Options "nosniff"
                Referrer-Policy "same-origin"
                -Server
                Content-Security-Policy "frame-ancestors domain.duckdns.org:port *.domain.duckdns.org:port"
                Permissions-Policy "geolocation=(self), microphone=()"
        }
}
https://domain.duckdns.org:port {
    import common
    reverse_proxy https://192.168.1.XX:8443 {
    } 
}

I appreciate your advice Francis. Please, any advice is welcome - I feel like I’m really close.

So you’re running two instances of Caddy now, right? What are the configs for both? What are in your logs on both (make sure to turn on the debug global option to see full logs)?

Hi Francis,

I actually didn’t set up Caddy on the other computer yet and can install using the directions from here:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo tee /etc/apt/trusted.gpg.d/caddy-stable.asc
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

But what other config would I need to establish the connection correctly?

Really appreciate your advice - Thank you, Daniel

I’m confused as to where you’re at, at this point. Could you recap what you have set up now? It would help if you paint a picture of your networking setup and what you’re trying to do.

Sure, I have Caddy2 add-on for HA setup on a VM HassOS on a Mac and serving a reverse proxy to a separate RPi with NextCloud instance moved to port 880 and 8443. I can access my unsecure login from the local network by the https://ip_address:8443. when I access the network by the external domain name using browser I get a blank screen and using curl I get a 502 bad gateway message, Server: Caddy, content-Length: 0.

My goal is to have the external site be secure for accessing Nextcloud Talk feature and not have to open up port 443 on the router as you would if you were having Nextcloud do the letsencrypt route. I also think in network design, I would want my external domain to have the certs for ssl and my internal network to communicate over https but not be using ssl.

I’m not quite sure how a secondary caddy server on the Nextcloud RPi would help to accomplish the handshake between the 2 servers – ahhhh, unless you just mean set up a separate Caddy for the Nextcloud all by itself and not have it worry about the Caddy on the HA server, of course that makes sense. Same technology just reduce the middle routes altogether.

I think that I want to use the config of the Caddyfile from the 1st comment, but insert “localhost” is it port 9000 or 8443 for NextCloud? all examples I’ve seen have port 9000 used and I’m not sure if that is correct for my instance.

I’m not sure where the Caddyfile is stored and how to reference it when you type caddy run?

I’ve figured out how to save the caddyfile and use it, now I’m wondering if I want the initial config that has the config for nextcloud adapted off of someone in the communities V1 to V2 file or if I want to simply have the reverse proxy setting?

Hi Francis,

I have Caddy running on the Nextcloud Server and it issued a cert for the reverse proxy, but the website is saying 400 bad request you’re speaking plain http to an SSL-enabled server port.

Any idea what’s the culprit?

Thank you,
Daniel

Should I run the reverse proxy to https://127.0.0.1:8443?

See this article:

Once you’re in your own network, there’s no reason to proxy over HTTPS, unless you have reason to believe something could intercept requests between Caddy and your upstream, maliciously.

Do I then setup my Nextcloud instance to not be SSL secured in apache2 and how does that affect things like talk that require ssl configuration?

It’s Caddy’s job to encrypt connections between itself and the clients (browsers). Once the request reaches Caddy, it’s inside of your own network. It doesn’t need to be re-encrypted to communicate with Apache.

but the nextcloud instance is https with the domain setup and the SSL certfile and key established and the reverse proxy is http on the local domain - so I’m getting the error. Do I need to take off SSL setting off of the apache2 instance running my Nextcloud and if I do that does that take off the security that is required to run talk add-on?

i have a system running this.

  1. a nextcloud instance on a docker host in an internal network (not directly reachable from the internet), running on HTTP
  2. a caddy instance on a server reachable from the internet (as https://nextcloud.example.com/ ), but also connected to the internal network

Caddy is using http for the reverse_proxy to the nextcloud service.

All clients use the caddy instance (to use SSL). The nextcloud instance does not have a certificate, but you have to make some config settings for nextcloud (in the config.php of nextcloud):

  'overwriteprotocol' => 'https',
  'overwrite.cli.url' => 'https://nextcloud.example.com',
  'forcessl' => true,
  'trusted_proxies' =>
  array (
    0 => 'INTERNAL IP OF Caddy-Host',
  ),

These are there to force nextcloud to respond to requests with the external url.
The talk clients must use the https://nextcloud.example.com/ address

Hi Francis,

Granted it doesn’t need to be rencrypted, but Nextcloud requires it to be https. So I added this:
reverse_proxy https://localhost:8443 {
transport http {
tls_insecure_skip_verify
}
}

And it was working for about 4 days then I went to reboot and have caddy start automatically and now I’m getting 502 bad gateway, any clue as to why?

Caddy starts correctly, but the page is blank of the website.

Hi Francis,

I actually looked closer into the error message and concluded from another page that Matt commented on about the service actually being up and found that there was an older reference to out of date ssl certs. So updated and reboot and all back in business!

Thank you for all your early on efforts with this method, really love the caddy technology!

Best regards,
Daniel

1 Like

Nextcloud doesn’t require it – your config for Nextcloud causes it to. You could definitely turn that off.

2 Likes

This topic was automatically closed after 30 days. New replies are no longer allowed.