Ce que vérifie cet outil
HTTP/2 et HTTP/3 remplacent tous deux une partie de la façon dont un navigateur communique avec votre serveur, principalement pour éliminer le blocage en tête de ligne et la surcharge de connexion que porte HTTP/1.1. Cet outil teste directement le support HTTP/2 — une vraie négociation TLS proposant à la fois h2 et http/1.1 via ALPN, rapportant exactement lequel votre serveur a choisi — et vérifie indirectement le support HTTP/3, car il n'existe ici aucun moyen équivalent d'effectuer une vraie négociation QUIC.
Pourquoi HTTP/3 ne peut être que déduit, pas prouvé
HTTP/3 fonctionne sur QUIC, construit sur UDP plutôt que TCP. Le tester en direct nécessiterait d'implémenter un client QUIC, que Node.js n'embarque pas. À la place, les serveurs qui supportent HTTP/3 l'annoncent de façon déclarative via l'en-tête de réponse Alt-Svc (quelque chose comme h3=":443"; ma=86400), indiquant aux navigateurs « vous pouvez essayer QUIC sur ce port ». Cet outil lit cet en-tête — un signal fiable en pratique, puisque les navigateurs eux-mêmes s'appuient sur exactement le même mécanisme pour décider de tenter HTTP/3, mais pas un test de connexion en direct comme l'est le contrôle HTTP/2.
Une différence entre votre CDN et ce test est fréquente
De nombreux sites fonctionnent derrière un CDN qui termine le TLS et parle HTTP/2 ou HTTP/3 aux vrais visiteurs, alors que le serveur d'origine derrière lui ne parle que HTTP/1.1. Comme cet outil se connecte à l'IP vers laquelle votre domaine résout — généralement l'edge du CDN, s'il y en a un devant — le résultat devrait normalement refléter ce que les visiteurs obtiennent réellement. S'il ne correspond pas à votre tableau de bord CDN, vérifiez que le domaine scanné est bien le nom d'hôte exposé par le CDN, pas une adresse d'origine interne.