Open ha-ku opened 1 year ago
@ha-ku did you manage to find a workaround?
@klausenbusk I just made caddy listening on another port and placed a udp forwarder in front of caddy to avoid the port conflict. No better solutions for now.
Same issue encountered. Specified protocols h3, but both tcp and udp are being listened.
Doesn't browsers use h1/h2 to first check for h3 support?
It does now, but it does not have to. There's a QUIC-only mode for Chromium if I'm not mistaken, also if you use curl there's a --http3-only that use QUIC directly without checking with h1/h2 for h3 support.
Doesn't browsers use h1/h2 to first check for h3 support?
What does this have to do with browsers in particular? On the one hand, users may want to provide different services through different versions of http, and on the other hand, caddy does not only communicate with browsers, right?
Mostly to subscribe to the discussion: We ran into the same issue, but decided that it's ok in our case to let caddy bind to both TCP and UDP and restrict access to the TCP part of things using the network configuration.
Remind me to revisit this in a little while... we could probably implement some logic in the HTTP server that treats H3-only config or UDP listeners as special.
I tried to start caddy with
servers { protocols h3 }
in global settings. However, caddy seems still trying to bind to tcp port. My Caddyfile is something like this:Here is the caddy log output when I run
sudo ./caddy run --config ./Caddyfile
with something else listening on 443/tcp:Is there a way to make caddy really just bind to the udp port only?
By the way, I'm using caddy 2.6.2.