Pourquoi vos requêtes de proxy résidentiel expirent

Un guide de diagnostic des timeouts proxy : connect vs read, filtres géo trop serrés, timeouts calibrés pour du datacenter, et les vérifications qui trouvent vite la vraie cause.

« Mes requêtes expirent » est l’un des messages de support les plus fréquents que nous recevons, et aussi l’un des moins précis. Un timeout est un symptôme, pas une cause. La même erreur remonte que le gateway n’ait pas pu vous trouver une IP de sortie correspondante, que votre client ait abandonné au bout de 5 secondes sur une connexion qui en demandait 8, que le site cible soit lent, ou que votre propre conteneur soit mal configuré et n’atteigne jamais le proxy.

Ceci est un guide de diagnostic : comment identifier laquelle de ces situations se produit réellement, dans l’ordre qui la trouve le plus vite. C’est le compagnon de réduire la latence, qui traite de rendre plus rapide une configuration qui marche ; celui-ci traite d’une configuration qui bloque ou échoue, et pourquoi.

Étape 0 : est-ce vraiment un timeout ?

Avant de diagnostiquer, classez précisément, car trois pannes différentes sont rapportées comme « timeout » et ont des correctifs différents :

Timeout de connexion (connect) — votre client n’a pas pu établir de connexion au gateway du tout. Cela pointe vers votre côté : sortie réseau, pare-feu, mauvais hôte/port, ou configuration du conteneur.
Timeout de lecture (read/response) — vous vous êtes connecté, la requête est passée, mais aucune réponse n’est revenue à temps. Cela pointe vers la sortie ou la cible : aucune IP correspondante, un appareil de sortie lent, ou un site cible lent.
Pas un timeout du tout — un 407 (auth), un 502 (aucune IP ne correspondait à votre filtre), ou une page CAPTCHA bloquée. Ceux-ci sont souvent rapportés comme des timeouts par du code enveloppe qui attrape tout comme une seule exception.

La plupart des clients vous laissent séparer explicitement les timeouts de connexion et de lecture. Le faire est l’étape de diagnostic la plus rentable, et c’est généralement un changement d’une ligne :

import requests

# (connect_timeout, read_timeout) - séparez-les, ne passez pas un seul nombre
r = requests.get(url, proxies=proxies, timeout=(10, 30))

Si ça échoue dans les 10 premières secondes, c’est un problème de connexion. Si ça survit à la connexion et meurt à 30, c’est un problème de lecture. Continuez à la section correspondante.

Cause 1 : votre filtre géo est trop serré

C’est la cause réelle la plus fréquente, et la plus facile à corriger.

Chaque flag de ciblage rétrécit le pool d’IP de sortie éligibles. country-us sélectionne dans un ensemble énorme. country-us-city-scranton-asn-12345 peut sélectionner dans presque rien. Quand peu ou aucune sortie ne correspond, les requêtes attendent, puis échouent, et selon votre client cela remonte comme un timeout ou un 502.

Diagnostiquez-le en desserrant un flag à la fois :

# Est-ce que ça marche avec country seul ?
curl -x customer-USER-country-us:PASS@p.shifter.io:443 https://api.ipify.org --max-time 30

# Puis remettez la ville et comparez
curl -x customer-USER-country-us-city-chicago:PASS@p.shifter.io:443 https://api.ipify.org --max-time 30

Si country seul réussit et que le filtre plus étroit expire, vous l’avez trouvé. Correctif : ne gardez que la précision dont vos données ont véritablement besoin. Si votre cas d’usage exige vraiment cette ville, attendez-vous à un pool plus petit et un débit plus faible, et budgétez-le (quand le ciblage au niveau de la ville compte traite de quand ça vaut le coût).

Cause 2 : votre timeout est calibré pour du datacenter, pas du résidentiel

Un second de très près, et il produit des « timeouts » sur des requêtes qui n’ont jamais été cassées.

Le trafic résidentiel passe par un vrai appareil grand public sur un réseau domestique, il a donc un plancher de latence que les proxys datacenter n’ont pas (résidentiel vs datacenter). Un timeout total de 5 secondes, parfaitement raisonnable pour du datacenter, coupera une requête résidentielle saine en plein vol et la rapportera comme un échec.

Diagnostiquez-le en mesurant avant de régler : collectez la latence p50 et p95 pour votre cible réelle à travers le proxy (comment tester la vitesse, le taux de réussite et la précision de localisation d’un proxy donne la méthode). Si votre timeout est sous votre p95, vous fabriquez des échecs.

Correctif : posez le timeout au-dessus de votre p95 mesuré avec de la marge, pas au jugé. Comme point de départ, un timeout de connexion d’environ 10s et un timeout de lecture de 30s ou plus est sensé pour du résidentiel ; puis resserrez selon vos propres chiffres.

Cause 3 : la cible est lente, pas le proxy

Facile à confirmer, facile à se tromper. Chronométrez le même chemin de requête contre un endpoint rapide et neutre et contre votre vraie cible à travers le même proxy :

# Endpoint neutre - mesure le surcoût du proxy
requests.get("https://api.ipify.org", proxies=proxies, timeout=(10, 30))

# Votre vraie cible - mesure surcoût du proxy + latence de la cible
requests.get("https://your-target.example/page", proxies=proxies, timeout=(10, 30))

Si l’endpoint neutre est rapide et la cible lente, le proxy n’est pas votre problème, et aucun réglage du proxy ne le corrigera. Augmentez le timeout de lecture pour cette cible, ou réduisez la part de la page que vous tirez.

Cause 4 : la concurrence est trop élevée

Les timeouts qui n’apparaissent que sous charge et disparaissent quand vous testez une seule requête pointent ici.

Deux mécanismes : vous épuisez peut-être des ressources locales (slots du pool de connexions, descripteurs de fichiers, capacité de la boucle d’événements), donc les requêtes font la queue de votre côté avant même de partir ; ou la cible vous limite et bloque au lieu de renvoyer un 429 propre.

Diagnostiquez-le en descendant la concurrence à 1 et en retestant. Si les timeouts disparaissent, c’est lié à la charge. Correctif : appliquez des limites de concurrence par hôte plutôt qu’un seul chiffre global, ce qui est l’architecture de la répartition de charge des proxys.

Cause 5 : gestion des connexions

Deux erreurs opposées, produisant toutes deux des timeouts :

Pas de réutilisation de connexions. Créer une connexion fraîche par requête signifie payer un handshake TCP + TLS complet à travers le proxy à chaque fois, ce qui est lent et laisse bien moins de marge à votre timeout. Utilisez une session/un client avec pooling.

Connexions poolées périmées. Si vous poolez les connexions mais tournez les IP de sortie à chaque requête, les sockets poolés peuvent pointer vers des sorties qui ne sont plus valides, et celles-là bloquent. Associez le pooling à une session sticky pour que la connexion poolée reste sur une sortie, et recyclez les connexions périodiquement.

Cause 6 : l’appareil de sortie lui-même

Les sorties résidentielles sont de vrais appareils grand public sur de vrais réseaux domestiques. Certains sont sur des liens congestionnés, certains sont mobiles, certains décrochent en pleine requête. Un petit pourcentage de requêtes lentes ou échouées est normal et attendu en résidentiel, pas un défaut.

Correctif : n’augmentez pas votre timeout pour accommoder le pire appareil, cela rend juste chaque échec plus lent. Échouez vite et réessayez sur une nouvelle identité, ce qui vous obtient une sortie différente. Le guide de failover d’hier couvre la classification des échecs de transport et le réessai correct. La qualité du pool détermine l’épaisseur de cette queue (réputation d’IP).

Cause 7 : ça n’a jamais atteint le proxy

À vérifier tôt si tout expire, surtout dans des conteneurs.

Confirmez que la requête sort bien par le gateway :

curl -x customer-USER-country-us:PASS@p.shifter.io:443 https://api.ipify.org
# Renvoie une IP résidentielle -> le proxy fonctionne.
# Renvoie votre propre IP      -> votre client ignore le proxy.
# Bloque entièrement           -> la sortie locale est bloquée (pare-feu, VPN, réseau d'entreprise).

Dans Docker et Kubernetes c’est une cause fréquente : le client n’honore pas HTTP_PROXY du tout, ou NO_PROXY est mal configuré, ou localhost ne signifie pas ce que vous croyez dans un conteneur. Le guide de configuration Docker couvre ces cas spécifiquement.

Cause 8 : erreurs d’auth ou d’identifiants déguisées

Un nom d’utilisateur malformé (une faute de frappe dans un flag de ciblage, un paramètre non supporté) ou de mauvais identifiants peuvent se présenter comme un blocage ou un échec générique selon la façon dont votre client gère un 407. Si votre configuration la plus permissive échoue encore, vérifiez la chaîne d’identifiants caractère par caractère avant de supposer un problème réseau.

L’ordre de diagnostic

Exécutez ceux-ci dans l’ordre ; chacun élimine une grande classe de causes :

Séparez connect de read. Échec de connexion signifie votre côté ; échec de lecture signifie sortie ou cible.
Vérifiez que vous êtes sur le proxy tout court (la vérification ipify ci-dessus).
Testez avec country seul. Si ça marche, votre filtre géo était trop serré.
Comparez un endpoint neutre à votre cible. Isole le surcoût du proxy de la lenteur de la cible.
Descendez la concurrence à 1. Si les timeouts disparaissent, c’est la charge, pas le proxy.
Vérifiez votre timeout contre votre p95 mesuré. S’il est en dessous, vous créez les échecs.

Six vérifications, et en pratique l’une d’elles explique presque tout signalement de timeout que nous voyons.

Quand les timeouts sont en fait normaux

Une petite queue de requêtes lentes et échouées est inhérente aux proxys résidentiels, parce que de vrais appareils grand public sont intrinsèquement variables. Poursuivre un taux de réussite de 100% avec des timeouts toujours plus longs est le mauvais objectif, cela rend vos échecs plus lents sans les rendre moins nombreux.

Le bon objectif est un SLO : définissez un taux de réussite et un p95 acceptables pour votre charge, échouez vite sur la queue, et réessayez sur une identité fraîche. Un pipeline qui échoue une requête en 30 secondes et réussit au réessai est plus sain qu’un qui attend 120 secondes en espérant.

FAQ

Pourquoi ai-je des timeouts avec un filtre ville ou ASN mais pas avec country seul ? Parce que chaque flag rétrécit le pool de sorties éligibles. Country + ville + ASN peut laisser très peu d’IP correspondantes, donc les requêtes attendent puis échouent. Desserrez jusqu’à la précision dont vos données ont vraiment besoin, et attendez-vous à un débit plus faible quand vous avez véritablement besoin d’un ciblage serré.

Quelles valeurs de timeout utiliser pour les proxys résidentiels ? Mesurez d’abord : votre timeout devrait être au-dessus de votre p95 observé, avec de la marge. Comme point de départ, environ 10s de connexion et 30s+ de lecture est sensé pour du résidentiel, puis ajustez selon vos propres chiffres. Des timeouts calibrés pour du datacenter couperont des requêtes résidentielles saines.

Comment savoir si c’est le proxy ou la cible qui est lent ? Chronométrez un endpoint neutre rapide et votre vraie cible à travers le même proxy. L’endpoint neutre mesure le surcoût du proxy ; la différence est la latence propre de la cible. Si l’endpoint neutre est rapide, le proxy n’est pas le problème.

Tout expire, même des requêtes simples. Qu’est-ce qui ne va pas ? Vérifiez que vous atteignez le proxy tout court : faites un curl vers un endpoint d’écho d’IP à travers lui. Votre propre IP signifie que le client ignore le proxy ; un blocage total signifie que la sortie locale est bloquée (pare-feu, VPN, config du conteneur). Puis vérifiez vos identifiants et flags.

Devrais-je simplement augmenter mon timeout ? Généralement non. Si la cause est un filtre géo serré, une cible lente, ou un mauvais appareil de sortie, un timeout plus long rend juste l’échec plus long. Corrigez la cause, et pour la queue inévitable, échouez vite et réessayez sur une nouvelle identité.

En résumé

Un timeout est un symptôme avec au moins huit causes distinctes, et le correctif dépend entièrement de laquelle vous avez. Séparez connect de read, confirmez que vous êtes bien sur le proxy, desserrez votre filtre géo, isolez la lenteur de la cible du surcoût du proxy, testez à concurrence 1, et vérifiez votre timeout contre votre p95 mesuré. Cette séquence résout l’écrasante majorité des cas, généralement en quelques minutes.

Et acceptez la queue : les sorties résidentielles sont de vrais appareils, donc un peu de variabilité est le prix de la confiance d’un vrai utilisateur. Échouez vite, réessayez sur une identité fraîche, et jugez la configuration sur le taux de réussite et le p95 plutôt que sur le fait qu’une requête expire un jour. Si vous êtes toujours bloqué après les six vérifications, les docs du gateway résidentiel et notre équipe peuvent aider à cerner le problème, apportez votre séparation connect/read et un échantillon de la chaîne d’identifiants qui échoue, et la réponse vient généralement vite.