Today I switched from nginx reverse proxy to caddy reverse proxy.
I have approx. 10 domains on (cloudflare, noip.com, changeip.com …). Domains run mostly websites, wordpress, nextcloud, etc. Everything works correctly, but some websites start very slowly (especially WordPress 2 out of 3). If I write the web address in the url and press enter, I have to wait 5-6 seconds until I see the website.
Oh no . I actually have 13 real domains. All domains are working, but some are loading very slowly.
I used example.com and examplex.com in the caddyfile because I don’t want to publish my domains.
Domains are already published and public information… as the help template and forum rule says, we won’t be able to help you unless we can investigate it ourselves. By redacting domains and not helping us experience the behavior you’re also seeing, you’ve tied our hands so we can’t help you
Yes, I can also put a real caddyfile here (some domains). The first and last domains in the caddyfile are wordpress sites. If I enter the url address of the site, it starts up very slowly (I have to wait 5-7 seconds). The non-Wordpress sites are working fine. If I used reverse proxy nginx, wordpress pages worked fast too.
Yes, I tried accessing from different WAN networks. And I also try LAN (respectively, the caddy is in the DMZ) and it is very slow.
hmm
I’m not an expert on these things, but if I use the F12 key in Mozilla, the developer tools will open and there you can see where the problem could be.
However, I don’t know how to solve it.
I do not claim that the problem is in the caddy. The problem manifests itself on websites with wordpress. Where there is no wordpress, websites are loaded in 200-300 ms.
When I used nginx as a reverse proxy, wordpress loaded very quickly.
I use apache2 as backend servers and I didn’t make any changes there.
I have gigabit within the local network. WAN network upload is 200 Mbps and ping 10ms.
Edit: I temporarily switched to nginx and the results are now 747 ms
I don’t understand it at all. If I use caddy as a reverse proxy, wordpress websites load very slowly (4-6 seconds or more). If I switch to the old nginx reverse proxy, everything is very fast (up to 700-800 ms).
I wanted to try ver. 2.7.3 but the Cloudflare plugin requires ver 2.7.4 caddy when compiling.
Unfortunately I was forced to go back to nginx.
I asked for the NGINX config thinking maybe the slowness is due to TCP socket vs UNIX socket, but you’re using TCP socket in both. I wonder if it has to do with some sysctl parameter or AppArmor.
I’m actually using 2.7.4 (respectively I’m already using nginx), but I wanted to downgrade to 2.7.3.
If someone could take a look at it.
JavaScript or loading relatively small images cause a big delay.
But it’s currently running on nginx.
Try to look at it through firefox F12 and later I will replace LXC nginx with LXC caddy.
But these are served by nginx So I don’t know that there’s really much of a difference. I’m guessing something to do with the network where your site is or even between it and where you are, since I can’t reproduce the results you’re seeing.
Thank you very much for trying it. 1.43 seconds is a good time. Now I just replace the LXC Debian 11 nginx container, with Dedien 12 caddy. Please clear the web browser cache and reload the website.
So it looks like Caddy vs. nginx is a red herring. The real difference is HTTP/2 vs HTTP/3. When I use curl or disable HTTP/3 in Firefox, I see the pages load quickly even when served by Caddy.
I bet you’d see similar performance issues with nginx serving HTTP/3. (I could be wrong, but I figure a bug like this would have been caught in our HTTP/3 lib already.)
It could be that some HTTP/3 streams / QUIC connections are being impeded near your site.
I can’t yet explain why only some HTTP/3 requests are slow, but I definitely think there’s something about the network configuration of the website’s host (or near the host) that is causing UDP packets to be delayed or dropped, adding significant latency. (This is not uncommon with HTTP/3, since most network gear focuses on TCP.)
I would check with your host, your host’s ISP, and the actual OS image configuration to ensure that UDP performance is optimal.
My ISP will surely be fine, because these problems are already in the LAN (DMZ). Now I closed the UDP port and left only TCP 80/443 open. It is understandable that HTTP/3 still works within the LAN network. Now I don’t have the opportunity to try the WAN.
This is my topology