Questions fréquentes sur les proxies mobiles et notre service.
Pourquoi un proxy pour Axios avec des IP de datacenter se fait bloquer
Quand un script Node.js interroge une API ou une page avec une IP de datacenter, l’adresse porte un ASN d’hébergement. Les systèmes antifraude la classent vite comme trafic automatisé ; la réponse se traduit par des 403, des rate limits ou des captchas. Un proxy pour Axios (axios proxy) basé sur des IP mobiles change ce contexte : l’adresse vient d’un opérateur cellulaire, avec un score de risque faible. Les requêtes passent plus souvent, et le budget de collecte n’est pas consommé par des tentatives bloquées.
Sur des cibles difficiles, des IP mobiles peuvent atteindre 95 à 99 % de succès là où des proxys résidentiels descendent sous 80 %. Ce gain vient de l’effet CGNAT : une même IP publique peut être partagée par des centaines ou des milliers d’abonnés, donc un blocage sec serait coûteux pour la plateforme. Pour un scraper Axios, cela signifie moins d’interruptions et moins de nettoyages manuels. La collecte reste exploitable sans multiplier les ports jetables.
Le trafic passe par des modems et SIM-routeurs avec SIM réelles ; vu de la plateforme, la requête ressemble à celle d’un appareil mobile, ce qui réduit les contrôles inutiles.
Brancher des proxys mobiles dans Axios : HTTP(S) ou SOCKS5
Un port OnlineProxy se branche au format ip:port:login:password ou par liste blanche d’IP, dans tout outil compatible HTTP(S) ou SOCKS5. La documentation de configuration est disponible sur https://onlineproxy.io/fr/manual. Pour un proxy HTTP pour Axios (axios http proxy), l’option native suffit dans beaucoup de scripts Node.js. SOCKS5 devient utile quand l’agent doit transporter UDP, WebRTC ou un flux qui ne doit pas dépendre des en-têtes HTTP. Le bon protocole évite des échecs silencieux et des reprises inutiles.
Option proxy native, axios.create() et authentification
Avec l’adaptateur Node.js d’Axios, une instance peut recevoir un objet proxy via la méthode create : axios.create() avec protocol, host, port, auth — l’authentification (authentication) — puis username et password. La même config peut aussi provenir de variables d’environnement, à condition de garder le bon port et le bon protocol. Si l’authentification échoue, les causes courantes sont une erreur 407, un protocole mal renseigné ou une IP source absente de la liste blanche. Une vérification rapide de ces champs évite de confondre un blocage de proxy avec un problème de cible.
Structure type : protocol : « http », host : l’adresse du port, port : le numéro fourni, auth : username/password. Si le relais est en SOCKS5, cette option native ne suffit pas ; la distinction évite de perdre du temps sur une config invalide.
Passer par SOCKS5 avec un agent dédié
Axios ne gère pas SOCKS5 nativement. Un agent dédié doit être passé dans httpAgent et httpsAgent, avec proxy : false pour éviter un double routage. Le terme using, dans certaines bibliothèques Node.js, désigne la réutilisation du même agent ; cela limite les handshakes et stabilise les sessions longues. Cette approche est plus fiable quand UDP, WebRTC ou un outil voisin imposent SOCKS5. La route reste stable, ce qui réduit les échecs de session liés aux en-têtes HTTP.
Rotation d’IP dans un script Axios : session sticky, lien de changement ou minuterie
Quand un script Node.js pilote un proxy pour Axios, la rotation doit correspondre au parcours. Une session sticky garde la même IP pendant une durée définie ; elle convient aux logins, aux paniers, aux API à jeton et aux collectes en plusieurs étapes. Le changement d’IP par lien HTTP peut être appelé depuis le code après un blocage ou un captcha. La rotation par minuterie convient aux longues collectes qui doivent rester discrètes sans logique manuelle. Chaque mode évite un coût précis : perte de session, retry aveugle ou usure d’une adresse trop visible.
Sur un matériel mobile, un modem supporte un nombre limité de flux, généralement 1 à 5, et un changement d’IP prend quelques secondes. Le script doit donc prévoir ce délai dans la logique de retry, sous peine de relancer trop vite et de créer des erreurs évitables. Une file d’attente courte ou une pause contrôlée suffit souvent. À la clé : moins de timeouts interprétés comme des pannes et moins de ports consommés inutilement.
Le tarif Regular permet ce pilotage : sticky session, changement par lien, minuterie et redémarrage de l’appareil. Le tarif Lite applique une rotation automatique toutes les 2 à 5 minutes, sans contrôle. Pour Axios, cela change la conception du code : avec Lite, il faut tolérer une IP changeante ; avec Regular, on peut aligner la rotation sur les étapes métier. Le choix évite de coder des rustines là où un mode de session suffit.
Conseil pratique : avant d’automatiser une rotation, validez la stabilité d’une sticky session sur le parcours critique. Une IP qui change au milieu d’un login ou d’une étape de paiement coûte souvent plus cher que quelques minutes de session supplémentaires.
Lite ou Regular : quel tarif choisir pour vos requêtes Axios
La facturation se fait par port et par période de 1, 7 ou 30 jours, avec un minimum de 24 heures. Il n’y a pas de facturation au Go : le trafic est sans décompte par Go sur les deux tarifs, ce qui ne signifie pas une vitesse sans plafond. Le prix dépend du pays et de l’opérateur, sans montant fixe à citer ici. Pour un développeur, cela transforme le coût en charge prévisible : un port par environnement ou par lot de scripts, sans surprise liée au volume.
| Scénario Axios | Lite | Regular |
| Rotation | Automatique toutes les 2 à 5 minutes, sans contrôle | Sticky session, changement par lien ou minuterie |
| Usage typique | Collecte simple tolérant des changements d’IP | Parcours authentifiés, retries après bloc, collecte pilotée |
| Contrôle | Port partagé entre au plus 5 utilisateurs | Appareil dédié, redémarrage possible, support prioritaire |
Lite correspond à un port partagé entre au plus cinq utilisateurs ; la rotation automatique toutes les 2 à 5 minutes ne peut pas être pilotée et l’appareil ne peut pas être redémarré. Regular attribue un appareil dédié pour la durée louée, avec sticky session, changement d’IP par lien ou par minuterie, redémarrage et support prioritaire. Le choix du pays et de l’opérateur doit rester cohérent avec la cible ; cette cohérence réduit les contrôles inutiles. Un proxy de datacenter peut être proposé pour un test limité ; aucun proxy mobile n’est disponible dans ce cadre. Après une location payante, un cashback en crédits internes peut être crédité, et un remboursement reste possible selon la politique applicable : première heure après délivrance, puis déduction du temps utilisé, le remplacement étant proposé d’abord en cas de problème technique. Ce cadre évite de confondre essai serveur et accès mobile, ou remboursement inconditionnel et politique encadrée.
Erreurs qui coûtent cher avec un proxy pour Axios et checklist avant lancement
La première erreur consiste à lancer des requêtes sans vérifier que l’IP est bien mobile : ASN, type, fraud score. Si l’adresse est en réalité classée comme hébergement, le script accumule des 403 pendant que le port continue de courir. Autre coût fréquent : une géo de proxy incohérente avec Accept-Language, le fuseau horaire ou la devise demandée. Le proxy ne masque pas non plus le User-Agent par défaut d’Axios ni son empreinte TLS ; sans ajustement, la même signature technique revient d’une session à l’autre. Résultat : des comptes ou des collectes qui tombent ensemble, alors qu’une checklist simple aurait isolé le problème.
Il faut aussi limiter les requêtes parallèles sur un seul port, car un modem mobile supporte peu de flux simultanés. Des retries sans limite transforment une réponse lente en consommation inutile, et une sortie IPv6 inattendue peut casser des outils qui ne la gèrent pas. Avant lancement, gardez une liste courte :
- Vérifier que l’IP est mobile, avec un ASN d’opérateur et un fraud score faible.
- Aligner pays, opérateur, Accept-Language et fuseau horaire avec la cible.
- Choisir HTTP(S) ou SOCKS5 selon l’agent, puis tester la 407 et la liste blanche.
- Adapter la rotation : sticky pour les sessions, lien pour les blocs, minuterie pour les longues collectes.
- Limiter le parallélisme à 1–5 flux par port et prévoir un délai après changement d’IP.
- Surveiller IPv6, les headers par défaut et l’empreinte TLS si la cible est sensible.
En cas de doute, le support est disponible 24h/24, avec un objectif de première réponse sous 4 heures. Une question posée tôt coûte moins qu’un port mal configuré laissé en production. Cette discipline finale transforme un proxy mobile en outil stable : moins de casses, moins de pertes de données et une infrastructure plus facile à dimensionner.