Démarrer l'essai gratuitSe connecter

Glossaire

Qu'est-ce qu'un proxy HTTP ?

Un proxy HTTP est un serveur proxy qui comprend et transfère le trafic HTTP (et via la méthode CONNECT, HTTPS), opérant au niveau de la couche applicative et capable d'inspecter, de modifier ou de mettre en cache les données de requête et de réponse pour le HTTP simple.

Comprenez en quoi les proxys HTTP diffèrent de SOCKS5, ce que fait HTTP CONNECT, et pourquoi les proxys HTTP sont le protocole par défaut pris en charge par la plupart des scrapers et des clients HTTP.

Expliqué

Un proxy HTTP est le type de serveur proxy le plus courant. Il comprend HTTP au niveau de la couche applicative : lorsque votre client envoie une requête, le proxy peut lire l'URL, les en-têtes et (pour le HTTP simple) le corps, avant de transmettre la requête à la destination. Pour HTTPS, le proxy utilise la méthode CONNECT pour établir un tunnel TCP vers la destination, après quoi il se contente de relayer les octets chiffrés sans en voir le contenu.

La plupart des services proxy commerciaux — y compris les fournisseurs résidentiels, ISP et datacenter — exposent des points de terminaison proxy HTTP, car chaque client et bibliothèque HTTP les prend en charge nativement. Définir les variables d'environnement `HTTP_PROXY` et `HTTPS_PROXY`, passer `proxies={...}` à `requests` de Python, ou configurer un indicateur de lancement dans Playwright fonctionnent tous immédiatement avec des URL de proxy HTTP comme `http://user:pass@gate.shifter.io:10000`.

La différence entre HTTP et SOCKS5 est principalement architecturale. Les proxies HTTP opèrent au niveau de la couche applicative (peuvent analyser HTTP) ; SOCKS5 opère au niveau de la couche transport (se contente de transférer des octets TCP/UDP). Pour le scraping HTTPS, la différence est surtout cosmétique — les deux finissent par tunneliser des octets chiffrés — et la prise en charge du proxy HTTP est plus universelle dans l'ensemble des outils.

Comment ça fonctionne

Pour le HTTP simple, votre client envoie la requête complète au proxy (`GET http://example.com/path HTTP/1.1` avec une URL absolue), le proxy lit l'URL, ouvre une connexion vers la destination, transmet la requête et relaie la réponse. Pour le HTTPS, le client envoie d'abord une requête `CONNECT example.com:443` au proxy, le proxy ouvre un tunnel TCP vers la destination, et à partir de ce moment le client et le serveur communiquent en TLS de bout en bout à travers le proxy, qui se contente de faire transiter des octets chiffrés.

L'authentification se fait généralement via l'en-tête `Proxy-Authorization` (authentification Basic avec nom d'utilisateur:mot de passe) ou en encodant les identifiants dans l'URL du proxy (`http://user:pass@host:port`). Le ciblage géographique et les paramètres de session dans les services commerciaux sont généralement encodés dans le nom d'utilisateur (`customer-USER-country-us-session-12345`).

Types

Proxy HTTP direct

La forme utilisée par les services de proxy commerciaux. Se place devant les clients et les représente sur Internet. Les clients configurent explicitement l'adresse du proxy.

Proxy HTTP inverse

Se place devant les serveurs backend. Utilisé pour l'équilibrage de charge, la mise en cache et la terminaison SSL (Nginx, HAProxy, Cloudflare). Les clients ne savent pas que le proxy inverse est présent.

Tunnel HTTP CONNECT

Le mécanisme utilisé par les proxys HTTP pour gérer HTTPS. Le client demande au proxy d'ouvrir un tunnel vers la destination, puis communique en TLS à travers le tunnel de bout en bout avec la destination.

Proxy HTTPS

Un proxy HTTP avec lequel vous communiquez via TLS. La connexion client-proxy est chiffrée (en plus du TLS de bout en bout via le tunnel CONNECT). Moins courant ; utilisé dans les configurations axées sur la confidentialité.

Cas d'utilisation courants

Scraping de contenu HTTP/HTTPS (le cas d'usage dominant)
Accès API via une sortie à IP fixe
Filtrage de sortie interne en entreprise
Mise en cache de contenu statique pour économiser de la bande passante
Authentification centralisée du trafic sortant
Routage HTTP par application dans les environnements de développement / test
FAQ

Foire aux questions

Questions fréquentes sur proxy http.

Un proxy HTTP opère au niveau de la couche applicative et peut analyser les requêtes HTTP ; un proxy SOCKS5 opère au niveau de la couche transport et transfère des octets TCP/UDP bruts. Pour HTTPS, la différence est essentiellement cosmétique — les deux finissent par tunneliser des octets chiffrés. SOCKS5 est préférable lorsque vous devez proxifier des protocoles non-HTTP (FTP, SMTP, BitTorrent, jeux en ligne).

Non, pas le contenu. Pour HTTPS, le proxy ouvre un tunnel TCP via CONNECT et se contente de transférer des octets chiffrés entre le client et la destination. Le proxy peut voir le nom d'hôte de destination (via la requête CONNECT et le SNI TLS) ainsi que le volume d'octets, mais pas le corps de la requête, les en-têtes ou la réponse.

`proxies={'http': 'http://user:pass@gate.shifter.io:10000', 'https': 'http://user:pass@gate.shifter.io:10000'}; requests.get(url, proxies=proxies)`. Même URL de proxy pour http et https — Python gère automatiquement le flux CONNECT lorsque le schéma est https.

Oui. Shifter expose des points de terminaison de proxy résidentiel et ISP (résidentiel statique) via HTTP/HTTPS (et SOCKS5). Utilisez les mêmes identifiants et paramètres de géociblage pour les deux protocoles. La plupart des clients utilisent HTTP en raison de sa prise en charge plus large par les clients.

Le mécanisme utilisé par les proxies HTTP pour gérer le HTTPS. Le client envoie `CONNECT host:port HTTP/1.1` au proxy, le proxy ouvre un socket TCP vers la destination, et à partir de ce moment le client et la destination communiquent en TLS de bout en bout à travers le tunnel. Le proxy ne peut pas voir le contenu chiffré.

HTTP vers le proxy convient à la plupart des usages commerciaux. Le TLS de bout en bout pour les cibles HTTPS reste chiffré dans tous les cas. HTTPS vers le proxy ajoute une couche de chiffrement supplémentaire entre vous et le proxy, ce qui protège contre l'observation passive de la ligne CONNECT et de l'en-tête Proxy-Authorization sur les réseaux non fiables. Utile sur un WiFi public ; généralement superflu depuis un serveur.