QUIC-only Mode

[injust]

I'd like to play with Caddy's QUIC feature while maintaining my current nginx setup. Would it be possible to implement a QUIC-only mode that could be enabled by command-line option?

[mholt]

🤔 What exactly do you mean by "QUIC-only"? Is that different from using -quic? QUIC will be preferred where the client and protocols support it.

[injust]

By that I mean an option for Caddy to accept connections only over QUIC (only listen on UDP?), leaving the TCP port open for another server to listen on. What I'm trying to do is use Caddy as a reverse proxy to experiment with QUIC connectivity on top of my existing nginx setup.

[mholt]

Oh. No, there's no way to do that with Caddy. It's extremely niche, and severely limits the kinds of clients that can connect. Why do you need this?

[injust]

I'd like to experiment with QUIC while keeping nginx for handling other connections since Caddy's cipher suites don't support some legacy clients that I need.

Previously, I tested with quic-reverse-proxy, which had a flag (-quic_only) that changed it into only handling QUIC connections. I know that it's a niche feature request, but perhaps it could still be sane to add in, because I'm guessing that it wouldn't require too much code change.

[mholt]

Hmm... so, I am not really inclined to implement this (doesn't seem generally useful) -- I would recommend just testing on a separate machine or a different port.

Thanks for your request though!

[twdkeule]

You can use --origin-to-force-quic-on=: in Chrome to force QUIC on the client.

[injust]

I'm aware of that flag, but I'm trying to force QUIC on the server, as opposed to the client side.

[injust]

I've found a way to split TCP/UDP traffic incoming on port 443 with iptables NAT, but if anybody knows of a better method, please do let me know.

[high3eam]

@Injust How did you manage to split the traffic, so you can do QUIC-only with Caddy?

I know the time passed since this answer but can you still explain how to do it or did you find another, better solution, yet?

[randomhydrosol]

Use ufw to block the TCP port and only keep udp open?

[injust]

@Henrocker Here is a series of iptables rules that will split the traffic:

-A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 60443
-A PREROUTING -p tcp -m tcp --dport 60443 -j REDIRECT --to-ports 0
-A INPUT -p tcp -m multiport --dports 80,60443 -j ACCEPT
-A INPUT -p udp -m udp --dport 443 -j ACCEPT

TCP traffic on port 443 is redirected to 60443 (or any other port you prefer), and UDP traffic remains untouched. Have Caddy listen to https://domain.tld as usual, and have nginx listen to the high port to handle the TCP traffic.

[maltris]

This would be indeed a good feature for those people who would like to use caddy only for quic on 443/udp but another webserver on 443/tcp.

I personally run caddy in a container which then only 443/udp is forwarded to.

[zh99998]

I deploy my services in Docker, and this problem could be solved naturally.

nginx:
  ports:
    - '443:443'
caddy:
  ports:
    - '443:443/udp'

[GongT]

+1

docker is good solution but I'm not using docker. :(

firewall require root and may need edit kernel setting.

[mholt]

@injust @maltris @GongT (and all others subscribed to this)

This has been Caddy's oldest open issue for quite some time. I am pleased to report that we are enabling HTTP/3 by default and also providing the option to serve only HTTP/3 as well: https://github.com/caddyserver/caddy/pull/4707

Please try it out!

[mholt]

Implemented in #4707. HTTP/3 can be enabled exclusive to other HTTP versions.

[ha-ku]

Implemented in #4707. HTTP/3 can be enabled exclusive to other HTTP versions.

I tried with servers { protocols h3 } but caddy seems still trying to bind to tcp port. Is there anything wrong with my config?

My Caddyfile is something like this:

{
	servers {
		protocols h3
	}
	auto_https off
}

:443, www.example.site:443 {
	log {
		output stderr
	}
	tls /etc/cert/example.site/fullchain.pem /etc/cert/example.site/privkey.pem {
		protocols tls1.2
	}
	reverse_proxy * http://127.0.0.1:3000
}

Here is the caddy log output when I run sudo caddy run --config ./Caddyfile with something else listening on 443/tcp:

xxxx/xx/xx xx:xx:xx.xxx
xxxx/xx/xx xx:xx:xx.xxx INFO    using provided configuration    {"config_file": "./Caddyfile", "config_adapter": ""}
xxxx/xx/xx xx:xx:xx.xxx INFO    admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//127.0.0.1:2019", "//localhost:2019", "//[::1]:2019"]}
xxxx/xx/xx xx:xx:xx.xxx INFO    tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc000191180"}
xxxx/xx/xx xx:xx:xx.xxx WARN    http    automatic HTTPS is completely disabled for server       {"server_name": "srv0"}
xxxx/xx/xx xx:xx:xx.xxx INFO    tls     cleaning storage unit   {"description": "FileStorage:/root/.local/share/caddy"}
xxxx/xx/xx xx:xx:xx.xxx INFO    tls     finished cleaning storage units
xxxx/xx/xx xx:xx:xx.xxx INFO    tls.cache.maintenance   stopped background certificate maintenance      {"cache": "0xc000191180"}
Error: loading initial config: loading new config: http app module: start: listening on :443: listen tcp :443: bind: address already in use

By the way, I'm using caddy 2.6.2.

[mholt]

@ha-ku What logs show if you turn on debug mode (add debug to your global options)?

I know this works, at least it did in my testing. So I'm curious what's different in your case.

[ha-ku]

@ha-ku What logs show if you turn on debug mode (add debug to your global options)?

I know this works, at least it did in my testing. So I'm curious what's different in your case.

Logs go like this with debug:

xxxx/xx/xx xx:xx:xx.xxx INFO    using provided configuration    {"config_file": "./Caddyfile", "config_adapter": ""}
xxxx/xx/xx xx:xx:xx.xxx WARN    Caddyfile input is not formatted; run the 'caddy fmt' command to fix inconsistencies    {"adapter": "caddyfile", "file": "./Caddyfile", "line": 3}
xxxx/xx/xx xx:xx:xx.xxx INFO    admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
xxxx/xx/xx xx:xx:xx.xxx INFO    tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc000307570"}
xxxx/xx/xx xx:xx:xx.xxx DEBUG   events  event   {"name": "cached_unmanaged_cert", "id": "1f99ad13-6401-4800-b4b8-0608c329c138", "origin": "tls", "data": {"sans":["*.example.site","example.site"]}}
xxxx/xx/xx xx:xx:xx.xxx DEBUG   tls.cache       added certificate to cache      {"subjects": ["*.example.site","example.site"], "expiration": "xxxx/xx/xx xx:xx:xx.xxx", "managed": false, "issuer_key": "", "hash": "b0f70c934136bad92ab566c99cdb16fc621d325e9b57701064cfd71ff8642344", "cache_size": 1, "cache_capacity": 10000}
xxxx/xx/xx xx:xx:xx.xxx WARN    http    automatic HTTPS is completely disabled for server       {"server_name": "srv0"}
xxxx/xx/xx xx:xx:xx.xxx INFO    tls     cleaning storage unit   {"description": "FileStorage:/root/.local/share/caddy"}
xxxx/xx/xx xx:xx:xx.xxx INFO    tls.cache.maintenance   stopped background certificate maintenance      {"cache": "0xc000307570"}
Error: loading initial config: loading new config: http app module: start: listening on :443: listen tcp :443: bind: address already in use

[mholt]

I think that's because even though HTTP/3 is being served exclusively, it still binds to TCP first before wrapping the listener. Can you open a new issue to request that feature (UDP-only)?

[ha-ku]

I think that's because even though HTTP/3 is being served exclusively, it still binds to TCP first before wrapping the listener. Can you open a new issue to request that feature (UDP-only)?

OK, I'll do it.

[ha-ku]

#5227

[mholt]

Thank you!