Is it good for production? Can I use caddy only as a reverse proxy of quic to nginx (or anything else?)
How can it be configured for such use as a reverse proxy? Even if not for production, but for testing?..
Thanks.
QUIC should be considered experimental as the support in the underlying library is still evolving.
Unfortunately, Caddy will still listen for regular HTTP(S) connections if QUIC is enabled.
I could make it listed for http/https in a port that’s not publicly visible.
Is it easy to make caddy reverse proxy for quic? Just like nginx does http2 proxying and and you see regular http1.1 connections on backend server?
That’s not unfortunate, that’s a feature, especially while QUIC is experimental and only a draft spec. (I know you opened a feature request to disable anything except for QUIC but to be frank, that doesn’t render the current situation unfortunate.)
QUIC support is good enough for basic use in browsers (Chrome). As Andrew said, the library is still changing but that’s because the spec is still changing. The library is being actively maintained and critical issues are fixed and new versions of QUIC are usually released pretty soon.
Some advanced HTTP features or reverse proxying cases may not work well with QUIC.
If you enable QUIC, Caddy will serve QUIC to the client but regular HTTP/2 to the upstream (or HTTP/1.1 if over HTTP).
When I said it was “unfortunate”, I was answering the OP’s question “How can it be configured for such use as a reverse proxy?”
But it’s definitely fortunate that regular connections are still permitted. After all, not everyone runs Chrome or the latest Opera.
1 Like
I want to test functionality in general, and I do not use chrome or anything advanced. I want to test loading data over QUIC connection from my own C++ code. My case is pretty simple, I simply ask to load a few files, that’s all (and possibly specifying priorities for the files, or dynamically changing these priorities in the middle of progress if everything else works ok). From replies and in general anything other than own google quic production servers could be considered experimental (even google’s servers are kind of). I mainly care if caddy could do this use case: 10Gbps 24/7 serving a few large files over quick with controlled clients (e.g. no zoo of different versions of chrome or different websites with different content). Would quic support in caddy be able to handle this kind of scenario? For the use case I’d simply want to use caddy as a quic proxy, and forward http2 to nginx; directly talking to nginx in http2 works perfectly for me.
As a side note, is it possible to use quic without any encryption? I’m mainly interested in quic’s ability to transfer data, that’s all I want. Just like with http2 I can use it unencrypted in my own code.
Isn’t it contradicting to previous sentence “reverse proxying cases may not work well with QUIC” ?
Certain reverse proxying cases may not work well with QUIC.
An error in semantics perhaps:
(Some advanced HTTP features) or (reverse proxying cases) may not work well with QUIC.
Vs.
Some (advanced HTTP features) or [some] (reverse proxying cases) may not work well with QUIC.
The latter is intended, I assume?
Yeah, sorry. QUIC should work fine in basic use, but for example until recently, DigitalOcean blocked udp packets in their network…