Routage proxy QUIC pour HTTPS et HTTP/3

BotBrowser 154.0.8037.44 ou ultérieur, avec un paquet de profil correspondant, permet de garder les requêtes HTTPS et HTTP/3 compatibles dans une route de navigateur approuvée, mais le fournisseur doit fournir les opérations nécessaires. Le choix repose sur la distinction entre tunnel HTTPS et transfert UDP, ainsi que sur la réponse prévue en cas d'indisponibilité.

Résumé

• Utilisez CONNECT pour un tunnel HTTPS classique via un proxy QUIC.
• Utilisez MASQUE CONNECT-UDP pour HTTP/3 sur QUIC lorsque le fournisseur et le parcours le demandent.
• Une URL quic:// ne garantit pas HTTP/3 : le site, le navigateur et le fournisseur négocient ensemble.
• Si le proxy est indisponible, BotBrowser ne passe pas silencieusement en direct : réessayez, choisissez une route approuvée ou arrêtez.

Sommaire

• Choisir le transport
• Configurer une route contrôlée
• Valider les limites et les échecs
• Déployer avec une fiche
• Limites opérationnelles et protocolaires
• Conclusion

Choisir le transport

CONNECT crée un tunnel vers une destination HTTPS. C'est le choix normal lorsque le fournisseur annonce CONNECT sur son service proxy QUIC. MASQUE CONNECT-UDP transporte des flux UDP et concerne le trafic HTTP/3 compatible. Ces opérations ne sont pas interchangeables. Pour comprendre ce que signifie CONNECT-UDP et comment s’intègrent les HTTP Datagrams, consultez MASQUE et CONNECT-UDP pour les opérateurs web, qui liste aussi ce que les opérateurs doivent confirmer auprès du fournisseur de proxy.

Parcours	Opération	Preuve attendue
Pages et API HTTPS	CONNECT	Le contrat du fournisseur annonce CONNECT
HTTP/3 avec QUIC autorisé	CONNECT-UDP	MASQUE et le transfert UDP sont pris en charge
Trafic mixte	Les deux ou une route de secours approuvée	Consigner le protocole et le secours

Configurer une route contrôlée

Utilisez BotBrowser 154.0.8037.44 ou ultérieur avec un paquet de profil correspondant et reliez binaire, profil, politique hôte et endpoint dans une fiche de version. Voici l'exemple au niveau du processus :

chromium-browser \
  --bot-profile="/path/to/profile.enc" \
  --proxy-server="quic://user:[email protected]:443"

Encodez les caractères réservés dans les identifiants et gardez les secrets réels dans le coffre du déploiement. Dans un contexte, appliquez les mêmes indicateurs approuvés avant la première page. Consultez la documentation QUIC Proxy Routing et le guide de configuration proxy.

Le routage par contexte est disponible avec BotBrowser ENT Tier3 et BotBrowser.setBrowserContextFlags ; appliquez les indicateurs approuvés avant de créer une page. Cette limite d'API et de niveau est distincte de l'exemple CLI au niveau du processus.

Valider les limites et les échecs

HTTP/3 se négocie pour chaque requête. Le site peut choisir HTTP/2, une politique peut désactiver QUIC ou le fournisseur peut proposer CONNECT sans CONNECT-UDP. Testez le parcours réel et notez le protocole observé. Pour comprendre comment les navigateurs négocient HTTP/3 et se replient sur d’autres protocoles, consultez Bases de la compatibilité HTTP/3 et QUIC dans le navigateur, qui explique pourquoi un seul chemin réseau n’est pas universel.

Quand le proxy QUIC est indisponible, BotBrowser ne bascule pas silencieusement en connexion directe. Un nouvel essai contrôlé, une route de secours approuvée ou un arrêt explicite rendent la confidentialité, la cohérence et la protection vérifiables. BotBrowser prend en charge une route proxy QUIC configurée dans un contexte autorisé, mais ne garantit pas la disponibilité du fournisseur, la négociation HTTP/3 ou une route directe de secours. Pour planifier des routes approuvées ordonnées avec un budget de nouveaux essais borné, consultez Bascule de proxy et continuité visible pour l’utilisateur, qui explique comment distinguer les pannes du tronçon proxy de celles de la destination.

Le proxy QUIC diffère aussi de UDP sur SOCKS5. SOCKS5 utilise UDP ASSOCIATE, tandis qu'un proxy QUIC suit son contrat CONNECT et MASQUE. Changer seulement le préfixe ne crée pas une capacité absente.

Déployer avec une fiche

Avant le déploiement, notez la version BotBrowser, l'identité du profil, le support CONNECT et CONNECT-UDP du fournisseur, le responsable des identifiants, le résultat HTTP/3 attendu et l'action approuvée en cas de panne. La revue reste ainsi possible sans secret ni script de page.

Questions fréquentes

quic:// force-t-il HTTP/3 sur tous les sites ?

Non. Le résultat dépend de la destination, de la politique du navigateur et du fournisseur ; HTTPS peut encore utiliser HTTP/2 via CONNECT.

CONNECT-UDP est-il nécessaire pour HTTPS classique ?

Non. HTTPS classique utilise CONNECT. CONNECT-UDP sert au transfert UDP, dont HTTP/3 compatible.

Que se passe-t-il si QUIC échoue ?

BotBrowser prend en charge une route proxy QUIC configurée dans un contexte autorisé, mais ne garantit ni la disponibilité du fournisseur, ni la négociation HTTP/3, ni une route directe de secours. La limite de protection configurée reste en place ; l'opérateur peut réessayer, choisir une route approuvée ou arrêter.

Pour comparer les choix, consultez la configuration proxy. Traitez UDP sur SOCKS5 comme une capacité distincte du fournisseur.

Limites opérationnelles et protocolaires

Limites opérationnelles.

HTTP/3 associe les requêtes et réponses HTTP à des flux QUIC. C'est distinct de l'opération proxy utilisée pour joindre une destination. CONNECT établit un tunnel dont l'échange interne reste entre le navigateur et l'origine. CONNECT-UDP permet de transporter des datagrammes UDP par le proxy ; navigateur et origine négocient leur propre protocole sur ce trajet. « Proxy QUIC » ne signifie donc pas que le proxy termine ou comprend l'échange HTTP/3 de l'origine.

La négociation HTTP/3 utilise les identifiants définis pour HTTP/3 sur QUIC, dont h3 pendant la négociation du protocole applicatif. Un site compatible HTTP/3 peut négocier un autre protocole pour une connexion donnée. Les protocoles proposés par le navigateur, le trajet réseau, le proxy et la réponse de l'origine interviennent. Distinguez support annoncé et résultat observé. RFC 9114 définit HTTP/3, sans garantir qu'une origine ou un réseau le sélectionne pour chaque requête.

Les flux QUIC sont des flux d'octets ordonnés et séparés dans une connexion. HTTP/3 utilise ce modèle pour ses flux de requêtes. Cela ne signifie pas que toutes les requêtes finissent indépendamment de la congestion, des ressources de l'hôte ou des dépendances applicatives. Une page peut toujours attendre une réponse critique. Ces propriétés expliquent des différences possibles avec HTTP/2, pas une garantie générale de vitesse pour une route proxy.

CONNECT-UDP se situe à une autre couche. Il identifie une destination et permet de transporter des datagrammes UDP dans un contexte proxy HTTP. RFC 9298 définit l'usage de HTTP Datagrams ou du Capsule Protocol entre client et proxy. Cela ne transforme pas le proxy en tunnel général pour tout protocole et ne supprime pas sa politique. Destinations, ports, niveau de compte et limites de datagrammes restent définis par le fournisseur.

Avec HTTPS via CONNECT, le tunnel ne fait pas du proxy le point de terminaison TLS de l'origine : le navigateur établit normalement son échange protégé avec le site à travers le tunnel. En HTTP/3 via une route UDP, la négociation QUIC et TLS avec l'origine reste distincte de la connexion QUIC vers le proxy. « Tunnel chiffré » ne signifie pas absence de métadonnées : le fournisseur peut connaître la destination et les horaires, et BotBrowser ne contrôle pas ses journaux.

Chaque vérification répond à une question différente. Une connexion proxy démontre que le service est joignable. L'acceptation de CONNECT ou CONNECT-UDP démontre que l'opération a été permise. Une requête HTTPS terminée démontre l'échange applicatif ; HTTP/3 observé démontre la négociation avec l'origine. Un résultat positif à une étape ne prouve pas automatiquement les autres.

HTTP/2 peut être un résultat normal si le parcours exige seulement HTTPS. Il peut aussi indiquer qu'une exigence HTTP/3 n'est pas remplie. Le protocole ne détermine pas l'interprétation : elle dépend du besoin déclaré. Précisez avant déploiement si HTTP/2 est acceptable. Si HTTP/3 est obligatoire, consignez séparément le support proxy et le protocole négocié.

Les normes décrivent les protocoles, pas les conditions commerciales d'un proxy particulier. RFC 9114 explique HTTP/3 sur QUIC et RFC 9298 spécifie CONNECT-UDP pour les proxies HTTP. Le fournisseur définit endpoint, authentification, destinations, disponibilité et limites de compte. BotBrowser peut appliquer la route documentée, mais ne peut activer une fonction fournisseur ni garantir le choix HTTP/3 de l'origine.

Considérez le protocole observé comme une preuve au niveau de la connexion, pas comme une étiquette pour toute la page. Une page peut joindre plusieurs origines et chaque connexion peut utiliser un protocole différent. Un document principal en HTTP/2 ne prouve pas qu'une API ou un média utilise le même protocole ; une réponse HTTP/3 d'une origine ne prouve pas non plus que toutes les ressources utilisent HTTP/3. Définissez l'origine et la requête visées par l'acceptation, puis notez le résultat à cette échelle.

Comparez les performances avec les mêmes variables : destination, région, version du navigateur, paquet de profil, niveau de compte et parcours. QUIC peut modifier l'établissement de connexion et la gestion des pertes, mais une page plus rapide ne prouve pas que la route proxy en est la cause. Précisez si le test porte sur une nouvelle connexion ou une connexion réutilisée, et mesurez le même jalon visible, par exemple une réponse API terminée ou une page utilisable. Répétez les essais autorisés pour tenir compte de la variabilité réseau et publiez une plage plutôt qu'un résultat isolé.

La réutilisation des connexions change aussi ce que démontre un essai. Plusieurs requêtes peuvent partager une connexion existante ; une réponse HTTP/3 ultérieure ne signifie donc pas qu'une nouvelle négociation proxy a eu lieu. Une nouvelle connexion peut avoir des coûts absents d'un essai répété. Séparez les observations à froid des requêtes répétées lorsqu'elles comptent pour l'application. Utilisez un contexte contrôlé sans modifier les données ni les paramètres de confidentialité pour obtenir le protocole souhaité.

La capacité d'un proxy QUIC vient du contrat du fournisseur, pas de l'écriture d'une URL. Vérifiez CONNECT pour les tunnels HTTPS et CONNECT-UDP pour les datagrammes UDP de HTTP/3 compatible, ainsi que l'authentification, les destinations, les limites UDP, la disponibilité et le niveau de service. Certains plans annoncent QUIC sans fournir CONNECT-UDP.

Consignez le propriétaire de l'endpoint, du compte fournisseur, des identifiants et du paquet de profil. Conservez l'identifiant de l'endpoint avec la version BotBrowser et la révision du profil afin de distinguer une migration du fournisseur d'un changement du navigateur. Un hostname partagé ne prouve pas la responsabilité.

Les identifiants sont des données de déploiement. Encodez les caractères réservés, injectez les secrets depuis un coffre approuvé et ne les placez pas dans le code, l'historique shell, les tickets ou les diagnostics. Après une rotation, retestez la même opération et le même endpoint. Une erreur d'authentification doit rester visible comme telle.

La CLI applique une route au processus. Le routage par contexte exige BotBrowser ENT Tier3 et BotBrowser.setBrowserContextFlags avant la création de la page. La fiche du contexte doit nommer le propriétaire, la route et les destinations attendues. Changer la route après la navigation rend le parcours difficile à interpréter.

Un proxy indisponible est un événement de politique. BotBrowser ne bascule pas silencieusement en direct. La réponse approuvée peut être une nouvelle tentative bornée, une route de secours revue ou un arrêt. Le secours doit avoir été revu pour le fournisseur, la géographie, les journaux, les identifiants et les destinations.

Séparez les couches d'échec : résolution de l'endpoint, transport QUIC, authentification, rejet de CONNECT ou CONNECT-UDP, puis négociation de destination. HTTP/2 choisi par le site n'est pas la même erreur qu'une authentification refusée. Chaque état a un responsable différent.

Validez avec un endpoint autorisé et peu de destinations dans un contexte non productif. Notez l'opération requise, les protocoles attendu et observé, l'identifiant de route, la catégorie d'état et l'action prévue. HTTP/2 peut convenir à HTTPS classique ; HTTP/3 exige de vérifier séparément CONNECT-UDP et la négociation.

Gardez seulement l'évidence nécessaire : heure, route, opération et résultat. Ne conservez ni identifiants, ni cookies, ni URL sensibles, ni contenu de page. Le fournisseur peut conserver des métadonnées selon ses conditions et BotBrowser ne contrôle pas cette conservation. Le responsable doit vérifier l'accès et la durée.

Une connexion QUIC au proxy prouve seulement le premier saut. Elle ne prouve pas que l'origine a choisi HTTP/3. La politique du navigateur peut désactiver QUIC et le fournisseur peut limiter UDP par compte ou destination. La fiche doit dire si HTTP/2 était acceptable et, sinon, si les deux contrôles ont réussi.

Après un changement de fournisseur, d'identifiants, de profil ou de navigateur, répétez la fiche avec BotBrowser 154.0.8037.44 ou ultérieur, le paquet correspondant, la portée processus ou ENT Tier3, l'endpoint et l'opération déclarés. Les décisions restent ainsi liées à la configuration revue.

Conclusion

Choisissez CONNECT pour HTTPS, ajoutez CONNECT-UDP seulement si le fournisseur et le parcours l'exigent, puis vérifiez le trajet réel. Une fiche courte protège la confidentialité et la cohérence tout en exposant les limites de BotBrowser.

Sources

• MDN : HTTP/3
• RFC 9114 : HTTP/3
• RFC 9298 : HTTP Datagrams and CONNECT-UDP