Why Caddy - Reverse Proxy page loading very slow

Help
1

Hi Gents,

  1. The situation:
    I am installing Caddy as a reverse proxy on a Progmox VM inside my home lan at 192.168.x.40, the VM is a Ubuntu v20 combined with NextCloud v9 and RocketChat server installed within the same VM, so the Nextcloud runs as localhost. I set the Nextcloud http port = 8080, and left the default https port setting alone. I am able to see the default Caddy sample index.html (/usr/share/caddy)on browser page via https: <mydomain.name>, and I get a valid Let’s Encrypt ssl cert on that url. I am also able to browse on Nextcloud internally at http: 192.168.x.40:8080/index.php/login and and RocketChat is accessible via http: 192.168.x.40:3000/admin/subscription well enough, both are pretty quick so its good.

  2. The problem:
    When I try to browse it over on public Internet, it works but it was excruciatingly slow n crawling at https: nextcloud.<mydomain.name>/index.php/apps/dashboard/
    while for RocketChat it refuses to connect at http: rocketchat. mydomain.name :3000/admin/subscription.

I believed my settings for NameCheap DNS is good n correct, while my home router has ports 80, 443 configured to point to my internal VM at 192.168.x.40.

  1. Caddy version:
    Caddy Version:- v2.9.1

  2. How I installed and ran Caddy:
    Caddy installed fpr Ubuntu as per https: Install — Caddy Documentation

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf ‘https: dl…’ | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf ‘https: dl.cloudsmith.io…’ | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

  1. System environment:
  • Progmox on Linux 6.8.12-8-pve
  • VM is Ubuntu v20 c/w NextCloud and RocketChat Server combined install
  • No Docker
  1. My complete Caddy config:
    <mydomain.name> {
    root * /usr/share/caddy
    file_server
    }
    nextcloud.<mydomain.name>:443 {
    reverse_proxy localhost:8080
    }
    rocketchat.<mydomain.name>:443 {
    reverse_proxy localhost:3000
    }

Thank you all for helping out a novice!
Cheers,
Jordan

2

Can you add the debug global option to your Caddyfile and post your Caddy logs?

I need to know either your domain name or the A/AAAA records to help you. If you are using ACME DNS to have Caddy manage certificates for you, it is not configured in your Caddyfile. How are you managing certificates?

3

On my NameCheap setup, I got my settings of the following below:-
Type Host Value
A record @ (home router public ip address)
A record mydomain.name (home router public ip address)
CAA @ 0 issuewild “letsencrypt.org”
CNAME * mydomain.name
CNAME nextcloud mydomain.name

Yeah, I didn’t do anything for ACME DNS or certs yet as I would like to see Caddy performing the auto generation of SSL certs provided first…

I’d like to mention again that the nextcloud version is from Turnkey Nextcloud v9 found together with the Ubuntu v20 server image template found in Progmox.

4

Assuming you have the caddy binary with the Namecheap plugin, you can either add the global acme_dns option or individually list dns namecheap in your site blocks.

Here's a sample Caddyfile: 
{
        acme_dns namecheap {
                api_key {env.NAMECHEAP_API_KEY}
                user {env.NAMECHEAP_API_USER}
                api_endpoint https://api.namecheap.com/xml.response
        }
}

<mydomain.name> {
root * /usr/share/caddy
file_server
}
nextcloud.<mydomain.name>:443 {
reverse_proxy localhost:8080
}
rocketchat.<mydomain.name>:443 {
reverse_proxy localhost:3000
}

I don’t know much about Turnkey or Proxmox, but as long as your networking settings are correct, I wouldn’t be able to pinpoint the exact reason why it is slow. Capturing your Caddy logs while accessing the services could potentially show something, but I’m doubtful.

Nextcloud is notoriously slow in the browser, and even with performance settings tuning, it can still be slow. It is the most widely used self-hosted personal cloud storage, so you’d think the programmers would be competent. It has become bloated in recent years and so alternatives have become more popular.

5

That saying Nextcloud being getting more bloaty is certainly very true, and that is what I am feeling about this method - that its really not that feasible to have the reverse proxy work from within the home network. So would you agree that it would be best to put reverse proxies out into a private/public cloud VM instance then have it say, VPN it directly back into the server VM instance sitting behind the home router?

I read about some guy who had his reverse proxy sitting in his VM instance on cloud provider Digital Ocean or something, and within that VM instance, he also had WireGuard server and client running in there - and it VPN connect directly back into his applications server VM instance that he setup sitting behind his home router in his home LAN.

Would this alternate design be more efficient, better performance, and offer better security? If so, do you have a general Caddyfile config that would work to fit for such a design layout?

1 Like
6

Oh incidentally, I would also like to share with you that I recently tried the latest NextCloud AIO version v30… and I got it up running without any reverse proxy as per what was mooted on their GitHub… let me tell you, it was excruciatingly slooooow too! And in according to their recommendations, I boosted up my VM up to 6GB RAM, 512Mb swap and 4 vCPUs… nope that didn’t help at all, and mind you I have an Asus AX4200 router at 1Gbps internet broadband on fibre optics.

1 Like
7

Better in regard to speed? If you’re on the home network and the machine hosting it is on the home network, nothing will beat that. I’ve also used WireGuard at home and outside the LAN, and the speed difference isn’t notable.

Any time you add more hops to a route, the more latency that will be added. WireGuard itself adds more security, especially if that is the only public-facing service. If you want to have Caddy also facing the public, it’s more than secure enough. I wouldn’t stress too much about added security on top of HTTPS and access control simply due to the fact that unless you’re trying to defend against governments or individuals that are targeting your services explicitly, anyone will have a hard enough time breaking through.

Most security breaches nowadays are from phishing, insider threats, or legitimately poor and outdated configurations that have long stopped receiving security updates. The threat vector for you specifically is likely so negligible, that dedicating days out of a busy life to improve an already relatively secure setup brings little gains.

That’s not to say you shouldn’t do it if it’s an interest to you. But if you need a service running, you’re already leagues ahead of many systems, especially health care and other high-value services with a mass of people’s PII (personally-identifiable information). Most breaches are also for money, because the company ends up paying the offender to keep them quiet or unlock the encryption.

Once you learn about the usual methods and exploits that have resulted in large breaches of information, and the drastic consequences of poor PII security and management, you’ll know that your setup is adequate, assuming you only exposed ports 80 and 443, or the standard 51820 for WireGuard. WG is only capable of working on client devices that have a paired public, private, and preshared keys.

Edit: Your most likely threat is DOS/DDOS. Plan that accordingly for any public facing services.

8

Hi Riley,
Much thanks for your past support on my Caddy journey. Would like to update you and anyone following my journey along in here - as it seems, due to performance wise, its not great to try to run everything off from a local VM from within your own home LAN, so I decided to do it in another way ie. to have the Caddy reverse proxy be sitting in a VM instance in a public/private cloud (depending on which cloud service provider you could choose) and then build a WireGuard VPN tunnel to connect that cloud VM directly to your own local VM that lies within your home LAN c/o Progmox or whatever, which is where you install/configure NextCloud AIO via Docker container. The WG will communicate via ports 51820, while the Caddy proxy will still have ports 80 and 442 open on the private cloud VM. I am now trying to figure out the proper Docker Compose script to install/configure NextCloud AIO for the internal VM sitting inside the home LAN.
Wish me luck!

1 Like
9

My Caddy proxy config sitting for the private cloud instance tested successfully with my rudimentary config as follows:
(mydomain.name):443 {
root * /static
file_server
}

Note: I have my test webpage sitting in ~/static/index.html cuz I build my Caddy from a Docker Compose yaml file. So I probably need to add on the following to reverse proxy to my internal VM/Nextcloud… woud this be the proper text for Caddyfile?

(my-nextcloudaio-domain.name):443 {
reverse_proxy (WG assigned IP address for the internal VM):11000
}

10

I believe that is correct. I have not used tunneling with Caddy, so I can’t verify.