HTTP/2 passe à travers les proxys sans difficulté car il fonctionne sur TCP, et TCP est exactement ce qu'un tunnel CONNECT ou une connexion SOCKS5 transporte. HTTP/3, lui, ne le fait pas : il utilise QUIC, qui est basé sur UDP, et les proxys HTTP ordinaires ne peuvent pas tunneler UDP, tandis que la plupart des déploiements SOCKS5 ne le font pas non plus. La conséquence pratique est qu'un client derrière un proxy parle presque toujours HTTP/2 (ou HTTP/1.1) à un site, même si le site prend en charge HTTP/3 — le navigateur bascule silencieusement. Cela convient pour la plupart des travaux, mais cela change ce que la destination voit, et il vaut mieux le comprendre que de le découvrir.
Les trois protocoles en une minute
- HTTP/1.1 (1997) : basé sur du texte, une requête à la fois par connexion ; les navigateurs ouvrent plusieurs connexions en parallèle pour compenser.
- HTTP/2 (2015) : tramage binaire, de nombreux flux concurrents multiplexés sur une seule connexion TCP, compression d'en-têtes (HPACK), push serveur (désormais largement abandonné). Même TCP + TLS en dessous que HTTP/1.1.
- HTTP/3 (2022) : mêmes sémantiques que HTTP/2 mais transporté par QUIC, un protocole de transport qui fonctionne sur UDP, intègre TLS 1.3 dans sa poignée de main, évite le blocage de tête de ligne de TCP, et permet à une connexion de survivre à un changement d'adresse IP (un téléphone passant du Wi-Fi à la 4G).
Un navigateur apprend qu'un site propose HTTP/3 de deux manières : un en-tête de réponse Alt-Svc: h3=":443" sur une réponse HTTP/2 antérieure, ou un enregistrement DNS HTTPS le publiant. Une fois qu'il le sait, il essaie QUIC à la prochaine connexion et mémorise le résultat.
Comment les proxys transportent chacun d'eux
Proxy HTTP
Pour une destination HTTPS, le client envoie CONNECT host:443, le proxy ouvre une connexion TCP vers la destination et se transforme en un simple tube à octets. Tout ce que le client et la destination négocient à l'intérieur de ce tube — TLS 1.3, puis HTTP/1.1 ou HTTP/2 via ALPN — est invisible pour le proxy et fonctionne sans modification. HTTP/2 à travers un proxy HTTP est donc tout à fait normal.
UDP n'a pas sa place dans ce modèle. CONNECT crée un tunnel TCP ; il n'existe pas de moyen standard pour un proxy HTTP/1.1 ordinaire de dire « transmettez mes datagrammes UDP à cet hôte ». Un navigateur configuré avec un proxy HTTP n'essaie tout simplement pas QUIC vers les origines — Chrome et Firefox désactivent HTTP/3 pour les connexions via proxy — et utilise HTTP/2 à travers le tunnel à la place. Pas d'erreur, pas d'avertissement.
Proxy SOCKS5
SOCKS5 définit bien une commande UDP ASSOCIATE pour relayer les datagrammes. En principe, un proxy SOCKS5 pourrait transporter QUIC. En pratique :
- de nombreux proxys SOCKS5 commerciaux n'implémentent que
CONNECT(TCP) et rejettent ou ignorent UDP ASSOCIATE ; - le relais UDP via SOCKS5 nécessite que le proxy ait un port UDP accessible et que le client prenne en charge la danse d'association, ce que les navigateurs ne font pas pour HTTP/3 ;
- Chrome et Firefox traitent un proxy SOCKS de la même manière qu'un proxy HTTP à cet égard : HTTP/3 n'est pas tenté.
Ainsi, même là où le proxy pourrait transférer UDP, le navigateur ne le lui demandera pas. Les clients QUIC en ligne de commande et certaines bibliothèques peuvent être pointés vers un proxy SOCKS5 compatible UDP, mais c'est une configuration spécialisée, pas le défaut. Notre comparaison SOCKS5 vs HTTP couvre plus largement la distinction TCP/UDP.
Ce qui transporterait HTTP/3 : MASQUE et CONNECT-UDP
Le groupe de travail MASQUE de l'IETF a normalisé CONNECT-UDP (RFC 9298), une extension qui permet à un proxy HTTP/3 (ou HTTP/2) de tunneler les charges utiles UDP — et par extension QUIC vers une origine. C'est ce qu'utilisent le relais privé iCloud d'Apple et certains proxys de confidentialité plus récents. La prise en charge dans les proxys commerciaux généralistes et dans les paramètres de proxy des navigateurs est encore rare ; lorsqu'un fournisseur annonce « prise en charge HTTP/3 », il vaut la peine de demander s'il veut dire que le proxy parle HTTP/3 avec vous ou qu'il peut tunneler HTTP/3 vers les origines — ce sont des choses différentes.
Ce qui se passe réellement, étape par étape
- Votre navigateur derrière un proxy demande
https://example.com. Il ouvreCONNECT example.com:443via le proxy. - À l'intérieur du tunnel, il effectue une poignée de main TLS 1.3, proposant ALPN
h2ethttp/1.1. L'origine choisith2. Vous êtes en HTTP/2. - La réponse contient
Alt-Svc: h3=":443". Le navigateur le note — et, parce qu'un proxy est configuré, l'ignore pour les connexions. - Chaque requête suivante vers cette origine continue en HTTP/2 via le tunnel.
Désactivez le proxy et rechargez : le navigateur honore maintenant Alt-Svc et le même site est servi en HTTP/3. Rien n'est cassé dans les deux cas ; le protocole diffère simplement.
Pourquoi cela compte
Performance
Les avantages de HTTP/3 — poignées de main plus rapides, pas de blocage de tête de ligne sur les liaisons avec pertes, migration de connexion — sont perdus à travers un proxy. Pour les proxys de datacenter sur de bonnes liaisons, la différence est faible. Pour les proxys mobiles, où le dernier saut est une liaison cellulaire avec pertes, QUIC aurait aidé le plus et c'est exactement là que vous ne pouvez pas l'avoir. Prévoyez un peu plus de latence que ce qu'une connexion HTTP/3 directe montrerait ; voir la méthodologie dans comment mesurer la vitesse et la disponibilité d'un proxy.
Empreinte numérique et cohérence
C'est le point subtil. Les systèmes anti-bot enregistrent quel protocole un client a utilisé et à quoi ressemblaient ses paramètres HTTP/2 SETTINGS (voir comment fonctionnent les systèmes anti-bot). Un Chrome moderne en connexion directe atteint la plupart des grands sites en HTTP/3. Le même Chrome via un proxy arrive en HTTP/2. En soi, ce n'est pas suspect — de nombreux utilisateurs réels sont derrière des proxys d'entreprise et n'utilisent jamais HTTP/3 — mais c'est un point de données de plus, et cela signifie que votre empreinte HTTP/2 (valeurs SETTINGS, ordre des en-têtes) est maintenant toujours exposée et doit être cohérente avec le navigateur revendiqué. Les clients HTTP qui imitent les navigateurs doivent imiter la couche HTTP/2, pas seulement la couche TLS, pour exactement cette raison ; l'article sur l'empreinte TLS explique la pile.
Outils de scraping
Le requests de Python ne parle que HTTP/1.1 ; httpx peut faire HTTP/2 avec l'extension h2 ; aiohttp est HTTP/1.1. Aucun ne fait HTTP/3 via un proxy. Puisqu'un navigateur derrière un proxy est de toute façon en HTTP/2, utiliser HTTP/2 dans votre client (là où la bibliothèque le prend en charge) vous rapproche le plus de ce à quoi ressemble un utilisateur réel derrière un proxy. Exemples dans Proxies en Python.
Conseils pratiques
| Situation | Ce que vous obtenez | Action |
|---|---|---|
| Navigateur + proxy HTTP, site HTTP/3 | HTTP/2 via tunnel CONNECT | Rien à faire ; c'est normal |
| Navigateur + proxy SOCKS5, site HTTP/3 | HTTP/2 (le navigateur ne tente pas QUIC via SOCKS) | Rien à faire |
| Vous avez besoin de HTTP/3 vers une origine via un proxy | Nécessite la prise en charge de CONNECT-UDP/MASQUE de bout en bout | Demandez spécifiquement au fournisseur ; supposez que non sauf confirmation |
| Le site se comporte différemment via proxy vs direct | Peut-être lié au protocole, plus probablement lié à l'IP | Comparez avec un vrai navigateur sur le même proxy avant d'accuser HTTP/3 |
| Client imitant un navigateur pour des sites protégés | Doit correspondre aux paramètres HTTP/2 SETTINGS et à l'ordre des en-têtes d'un navigateur | Utilisez un client qui imite HTTP/2, pas seulement TLS |
| Mesure de la latence du proxy | Comparez ce qui est comparable : HTTP/2 direct vs HTTP/2 via proxy | Ne comparez pas HTTP/3 direct avec HTTP/2 via proxy |
Questions fréquemment posées
Est-ce que HTTP/2 fonctionne à travers un proxy ?
Oui. HTTP/2 fonctionne sur TCP et TLS, ce qu'un tunnel CONNECT ou une connexion SOCKS5 transporte de manière transparente. Le proxy n'a pas besoin de comprendre HTTP/2 du tout.
Est-ce que HTTP/3 fonctionne à travers un proxy ?
Généralement non. HTTP/3 utilise QUIC sur UDP ; les proxys HTTP ne peuvent pas tunneler UDP et les navigateurs ne tentent pas QUIC lorsqu'un proxy est configuré. Le navigateur retombe automatiquement sur HTTP/2. Seuls les proxys prenant en charge CONNECT-UDP (MASQUE) peuvent transporter HTTP/3 vers les origines, et c'est rare.
Un proxy SOCKS5 peut-il transporter QUIC ?
Le protocole a une commande de relais UDP, mais de nombreux services SOCKS5 commerciaux ne l'implémentent pas et les navigateurs ne l'utilisent pas pour HTTP/3. Des clients spécialisés le peuvent, si le proxy prend réellement en charge UDP ASSOCIATE.
Utiliser HTTP/2 au lieu de HTTP/3 va-t-il me faire détecter ?
Pas en soi — de nombreux utilisateurs légitimes sont derrière des proxys qui imposent HTTP/2. Mais cela signifie que votre empreinte HTTP/2 est toujours visible, donc elle doit être cohérente avec le navigateur que vous prétendez être.
HTTP/3 est-il plus rapide via un proxy ?
Vous n'obtenez pas HTTP/3 via un proxy ordinaire, donc la question ne se pose pas ; vous obtenez HTTP/2, qui est légèrement plus lent sur les liaisons avec pertes que ne le serait HTTP/3. Sur de bonnes liaisons de datacenter, la différence est négligeable.
Qu'est-ce que Alt-Svc ?
Un en-tête de réponse HTTP par lequel un site indique au client que la même ressource est disponible sur un autre protocole ou port — typiquement h3=":443" pour annoncer HTTP/3. Les navigateurs l'honorent sur les connexions directes et l'ignorent pour les connexions lorsqu'un proxy est configuré.