From a technical standpoint, these are always impressive projects, but I've always wondered: has anyone ever encountered a use case where the Caddy was the bottleneck?
In my experience Caddy has worse latency and throughput than nginx. I've set up a service that frequently sends 600MB/s (~5gbps) with nginx and the CPU is just chilling at 50%, but Caddy on that machine bottlenecks at 300MB/s despite using 100% of the CPU. AES hardware acceleration was enabled and functional on both software. This is high throughput that most people won't see, but it was also on a far beefier machine than most people would use. Caddy would definitely be a bottleneck when serving media from a raspberry pi. My last attempt was in 2025, Caddy has probably improved since then.
That being said nginx has some terrible defaults so if you're just naively benchmarking it as a proxy out of the box, you might find Caddy to be better. For example nginx caches active request bodies (in and out) to temp files in many scenarios (to block the backend/upstream as little as possible), whereas Caddy is more of a transparent proxy.
My experience mirrors that, but mostly because Caddy does HTTP/2 and http3 by default, natively. HTTP 1.1 is faster for bulk data transfers (while being worse at pipelining and latency in general), so I'm not surprised Caddy is taking more CPU in this case.
In my experience, in terms of latency, Caddy is a lot faster, every single time. I don't know what modifications I need to do to nginx to make it comparative but Caddy easily shaves half of the connection and transfer delays on my local network.
If it's http2 then Go's stdlib is pretty unoptimized to say the least. Huffman decoder is really cache unfriendly (pointer chasing) and I think allocation heavy too. Same probably goes for http1 and http3.
For most apps the backend is slower than the proxy by a wide margin, so Caddy is nowhere near the bottleneck. Where it flips is high connection churn, since TLS handshakes are the expensive part and a flood of short lived connections without session resumption burns proxy CPU well before steady state proxying does. Very high RPS of tiny responses is the other case, where allocation and header parsing start to show.
That being said nginx has some terrible defaults so if you're just naively benchmarking it as a proxy out of the box, you might find Caddy to be better. For example nginx caches active request bodies (in and out) to temp files in many scenarios (to block the backend/upstream as little as possible), whereas Caddy is more of a transparent proxy.