Why do you think that test can’t be trusted? It was recently updated and works with all the latest HTTP/3 deployments. The sslyze tool, on the other hand, hasn’t updated its early data plugin in about 3 years (other than a couple irrelevant changes) but the QUIC protocol drafts have changed a lot in those 3 years. I suspect it’s using an older version of the draft.
HTTP/3 check shows a success for your domain:
Zero Round Trip Time Resumption (0-RTT)
The QUIC handshake for this connection was completed without any additional round-trips.
Upon further investigation, it appears sslyze doesn’t even support QUIC:
I think sslyze is the tool that can’t be trusted for this. (And that’s saying something, since HTTP/3 Check is developed by a competing web server company.)
If you want to test HTTP/3 yourself, Marten Seeman, the developer of our QUIC library, suggests:
If you actually want to check for 0-RTT support, have a look what Chrome does, and record a qlog to see if 0-RTT packets are sent.
Though, the “0-RTT security concern/risk/vulnerability” stuff has been brought up pretty frequently with Caddy, and it all really roots down to concerns of replay attacks, but that’s something you should be fixing at the application level instead of just disabling 0-RTT at the web server level. Browsers have already been “replaying” POST requests without changing the contents for a long time now with the “resend form on reload” stuff.