Comment configurer un proxy Axios pour Node.js (oui, même en HTTPS)

Quelque part sur Stack Overflow, à l’heure qu’il est, quelqu’un est persuadé qu’Axios « casse silencieusement » avec les proxys HTTPS. C’est l’une des affirmations les plus répétées dans les tutos sur les proxys Node.js, et elle ne correspond pas à la version actuelle testée pour ce guide. J’ai monté une batterie de tests locale avec de vraies origines HTTP et HTTPS derrière deux proxys, et Axios 1.19.0 a bien fait passer la requête HTTPS via une vraie requête CONNECT, au lieu de contourner le proxy.

Cela ne veut pas dire que les problèmes évoqués par les utilisateurs sont inventés. Les anciennes versions d’Axios avaient de vrais bugs (voir issue #3384 et issue #4531 pour les preuves), et les versions récentes de Node ajoutent un second chemin de résolution des proxys via l’environnement qui mérite une configuration rigoureuse. Ce guide explique ce qui fonctionne réellement dans Axios 1.19.0 à ce jour, toutes les méthodes pour intégrer un proxy à vos requêtes, un schéma de rotation basé sur des interceptors que presque aucun tutoriel ne montre, ainsi qu’un tableau complet des erreurs et correctifs quand les choses déraillent malgré tout.

Qu’est-ce qu’un proxy Axios et pourquoi c’est important dans Node.js ?

Dans le contexte d’Axios, un proxy est simplement un serveur intermédiaire placé entre votre processus Node et le site cible. Votre requête passe d’abord par le proxy, qui la relaie ensuite, et le site cible voit l’adresse IP du proxy à la place de la vôtre. C’est tout le principe.

Les développeurs l’utilisent pour plusieurs raisons : scraper des sites qui limitent le débit ou bloquent par IP, tester le comportement d’une application depuis une autre zone géographique, acheminer le trafic via une sortie réseau d’entreprise, ou simplement éviter d’exposer l’IP de leur serveur dans les journaux d’accès du site visé. La configuration officielle des requêtes d’Axios propose une option proxy intégrée avec les champs host, port, protocol et auth — cela existe depuis des années, et c’est la première chose que tout tutoriel (y compris celui-ci) vous montre.

Voici le point souvent passé sous silence : cette option proxy ne se comporte pas de la même manière selon que vous contactez une cible HTTP ou HTTPS, et selon la version d’Axios utilisée. C’est précisément pour cette différence que ce guide existe.

Installer Node.js et Axios (base rapide)

Passez cette section si vous avez déjà un projet en cours. Sinon, deux minutes suffisent.

mkdir axios-proxy-demo && cd axios-proxy-demo
npm init -y
npm install axios

Ajoutez "type": "module" à votre package.json si vous voulez utiliser les imports ESM (c’est mon cas — un require() CommonJS pour une démo de proxy fait un peu daté). La version LTS actuelle de Node est la v24.18.0, mais j’ai réalisé mes tests avec la v22.22.3 afin que les résultats ne dépendent pas des particularités de la toute dernière runtime.

Ajoutez ceci dans app.js puis lancez node app.js :

import axios from 'axios';

const res = await axios.get('https://httpbin.org/ip');
console.log(res.data);

Vous devriez voir votre vraie adresse IP dans la réponse. C’est votre référence de départ — une fois le proxy actif, cette même requête devrait renvoyer l’IP du proxy à la place.

Enregistrez cette réponse avant d’activer le proxy ; cela vous donnera une base de comparaison concrète avec la requête proxifiée à l’étape suivante.

Axios gère-t-il vraiment les proxys HTTPS ? (remise à plat)

Réponse courte : oui, dans la version stable actuelle. Axios 1.19.0 documente le tunneling CONNECT pour les cibles HTTPS derrière un proxy HTTP. L’API de téléchargement npm a enregistré 117 890 039 téléchargements d’Axios du 31 juillet au 6 août 2026, un indicateur daté de l’usage massif de cette bibliothèque. Quand vous appelez une URL HTTPS via un proxy, Axios envoie désormais une requête CONNECT pour créer le tunnel, et la négociation TLS se fait de bout en bout avec l’origine réelle. J’ai vérifié cela directement : proxy HTTP local, origine HTTPS locale avec certificat auto-signé, et le compteur CONNECT de mon proxy a bien augmenté comme prévu.

Alors pourquoi voit-on partout des messages du type « le proxy HTTPS d’Axios est cassé » ? Pour plusieurs raisons, toutes bien réelles :

Anciennes versions d’Axios. Les issues GitHub souvent citées sont parfois vieilles de plusieurs années et décrivent un comportement lié à une version et une configuration précises, qu’il ne faut pas généraliser à la version actuelle.
Serveurs proxy sans prise en charge de CONNECT. Dans ce cas, le tunnel échoue et Axios doit remonter une erreur ; il faut capturer le chemin réel et le message d’erreur avant de conclure à un contournement de proxy.
Confusion entre la config proxy et autre chose. L’option proxy sert à définir un proxy de transit, pas à dire « fais passer tout le trafic par cet agent quoi qu’il arrive ».

Chromium indiquait en 2023 que plus de 90 % des navigations Chrome sur les principales plateformes utilisaient HTTPS. C’est une mesure Chrome datée, pas un recensement complet du Web actuel, mais elle explique pourquoi le comportement vis-à-vis des cibles HTTPS doit être au cœur de ce tutoriel. Si vous utilisez une vieille version d’Axios, reproduisez le problème sur la branche actuelle avant de supposer qu’un ancien bug décrit encore le comportement d’aujourd’hui ; testez la mise à jour dans votre propre application avant de la déployer.

Quand on veut quand même un agent explicite

La config native proxy convient à un proxy unique, fixe et classique. Mais elle montre vite ses limites dès qu’il faut un contrôle par requête, de la rotation de proxys ou la prise en charge de SOCKS — l’option native d’Axios n’a pas été conçue pour ça. C’est là que HttpsProxyAgent devient utile, et je détaille cela plus bas. Voyez l’option native comme « suffisant pour un proxy, un usage » et l’approche basée sur un agent comme « ce qu’il faut vraiment en production ».

Le chemin proxy d’environnement dans Node v24 et v22.21+

Les versions récentes de Node incluent un mode proxy via l’environnement, activé avec NODE_USE_ENV_PROXY=1 ou l’option --use-env-proxy. D’après la documentation CLI de Node, cette fonctionnalité est arrivée en v24.0.0 et a été rétroportée en v22.21.0 — donc dire « Node 22+ » serait techniquement faux ; il s’agit précisément de la v22.21.0 et des versions ultérieures de cette branche. Si vous êtes sur un patch plus ancien de Node 22, ce flag n’existe tout simplement pas.

Axios actuel lit déjà HTTP_PROXY, HTTPS_PROXY et NO_PROXY via sa dépendance proxy-from-env, donc global-agent n’est pas nécessaire pour ce chemin d’Axios actuel. Lorsque le mode proxy d’environnement de Node est également actif, deux couches peuvent intervenir dans la décision de routage.

La documentation d’Axios précise que sur les versions de Node où l’agent porte une propriété proxyEnv, Axios laisse Node gérer cette partie au lieu de faire sa propre résolution. En pratique, mieux vaut choisir un seul système et s’y tenir :

Laisser Node gérer : activez le flag, ne renseignez pas proxy dans Axios, et laissez les variables d’environnement faire le travail.
Laisser Axios gérer : n’activez pas le flag Node, et laissez la résolution des variables d’environnement intégrée à Axios s’exécuter.
Prendre le contrôle total manuellement : définissez explicitement proxy: false et fournissez votre propre httpsAgent — cela contourne les deux systèmes automatiques, ce que je recommande dès que vous avez besoin de rotation ou de logique par requête.

J’ai testé directement la résolution côté Axios : en définissant HTTP_PROXY dans l’environnement d’un sous-processus, la requête passait bien par mon proxy local, et en ajoutant l’entrée correspondante dans NO_PROXY, la requête suivante le contournait correctement. Donc le chemin via les variables d’environnement fonctionne bien prêt à l’emploi aujourd’hui — c’est la situation de double mode qu’il faut surveiller.

5 façons de brancher un proxy dans Axios (comparatif)

Avant d’aller dans le code, voici le panorama. J’ai construit et testé chacune de ces méthodes sur une vraie configuration locale de proxy, pas seulement à partir de la documentation.

Méthode	Prise en charge HTTPS	Authentification	Contrôle par requête	Adapté à la rotation	Complexité
Option inline `proxy`	✅ (Axios actuel)	✅	✅	❌	Faible
Défauts via `axios.create()`	✅ (Axios actuel)	✅	❌ (au niveau de l’instance)	❌	Faible
Variables d’environnement (`HTTP_PROXY`/`HTTPS_PROXY`)	✅	✅	❌	❌	Faible
`httpsAgent` + `HttpsProxyAgent`	✅	✅	✅	⚠️ (manuel)	Moyenne
Interceptor de requête + pool d’agents	✅	✅	✅	✅	Moyenne à élevée

Utilisez l’option inline pour un script rapide qui passe par un seul proxy. Utilisez axios.create() quand toutes les requêtes d’un module doivent emprunter le même proxy sans répéter la config. Utilisez les variables d’environnement si votre équipe infrastructure gère déjà le routage proxy de façon centralisée et que vous voulez simplement l’hériter. Passez à un agent explicite lorsque la config native ne vous suffit plus — et basculez vers le pattern avec interceptor dès que le « contrôle » devient de la « rotation ».

Trois méthodes de routage du proxy Axios convergeant vers une destination HTTPS

Configuration de base du proxy Axios, étape par étape

La configuration la plus simple utilise directement l’objet proxy intégré à la requête :

import axios from 'axios';

const res = await axios.get('https://httpbin.org/ip', {
  proxy: {
    host: '203.0.113.10',
    port: 8080,
    protocol: 'http',
  },
});

console.log(res.data);

Lancez cela et vous devriez voir l’IP du proxy dans la réponse à la place de la vôtre. Si vous testez en local avec un vrai proxy, cela se résout généralement en moins d’une seconde — bien plus simple que de configurer un proxy système global juste pour tester une requête, ce qui peut vous faire perdre quinze minutes que vous n’avez pas.

Comparez cette réponse avec votre valeur de référence. Un test réussi doit afficher l’IP publique du proxy plutôt que l’IP d’origine que vous aviez enregistrée plus tôt.

Utiliser `axios.create()` pour des paramètres par défaut au niveau de l’instance

Si toutes les requêtes d’un module donné doivent passer par le même proxy, intégrez-le à une instance plutôt que de répéter la configuration :

const client = axios.create({
  proxy: {
    host: '203.0.113.10',
    port: 8080,
  },
  timeout: 15_000,
});

const res = await client.get('https://httpbin.org/ip');

J’ai vérifié qu’un override proxy: false sur une requête particulière contourne proprement le proxy par défaut de l’instance — pratique si 95 % de vos appels doivent passer par le proxy, mais que quelques requêtes (par exemple un ping de santé) ne doivent pas.

Définir le proxy via les variables d’environnement

Pour un routage géré de manière centralisée — imaginez des conteneurs Docker ou des environnements CI où l’équipe ops définit déjà les variables de proxy — vous n’avez pas besoin de toucher à la config Axios :

export HTTP_PROXY=http://203.0.113.10:8080
export HTTPS_PROXY=http://203.0.113.10:8080
export NO_PROXY=localhost,127.0.0.1

Axios actuel lit ces variables sans global-agent. Retenez simplement la frontière de version Node évoquée plus haut : si NODE_USE_ENV_PROXY est aussi actif, identifiez clairement qui est responsable du routage et testez le comportement de NO_PROXY dans l’environnement de production.

Configuration pas à pas d’un proxy HTTPS avec `httpsAgent` (pour un vrai contrôle)

C’est la configuration que je recommande réellement dès que vous avez besoin de plus qu’« un seul proxy, toujours le même ». Installez le package d’agent actuel :

npm install https-proxy-agent

https-proxy-agent 9.1.0 requiert Node 20 ou plus récent et envoie bien une requête CONNECT à votre proxy avant de tunneliser la connexion cible à travers lui.

import axios from 'axios';
import { HttpsProxyAgent } from 'https-proxy-agent';

const agent = new HttpsProxyAgent('http://203.0.113.10:8080');

const client = axios.create({
  proxy: false,        // évite que la résolution native d’Axios s’en mêle aussi
  httpsAgent: agent,
  timeout: 15_000,
});

const res = await client.get('https://httpbin.org/ip');
console.log(res.data);

Définissez proxy: false lorsque le routage est pris en charge par un agent explicite. Cela rend la configuration sans ambiguïté et évite que la résolution native ou via l’environnement d’Axios entre en concurrence avec l’agent fourni.

Ajouter une authentification de proxy

Intégrez les identifiants directement dans l’URL du proxy :

const agent = new HttpsProxyAgent('http://myuser:mypassword@203.0.113.10:8080');

Si votre mot de passe contient des caractères spéciaux — @, : et # sont les plus problématiques — encodez-les en pourcentage avant de construire l’URL, ou fabriquez la chaîne avec encodeURIComponent() sur chaque composant. Un @ brut dans un mot de passe sera interprété comme le début de la partie hôte, et vous obtiendrez une erreur de connexion qui n’aura rien d’évident à voir avec l’encodage.

Utiliser des proxys SOCKS5 avec Axios

Les proxys SOCKS ne sont pas compatibles avec HttpsProxyAgent — il faut un autre agent selon le protocole :

npm install socks-proxy-agent

import { SocksProxyAgent } from 'socks-proxy-agent';

const agent = new SocksProxyAgent('socks5://myuser:mypass@203.0.113.10:1080');

const client = axios.create({
  proxy: false,
  httpsAgent: agent,
});

socks-proxy-agent 10.1.0 nécessite lui aussi Node 20+. SOCKS5 mérite d’être utilisé quand vous travaillez avec des réseaux d’entreprise qui n’exposent qu’une passerelle SOCKS, ou avec des fournisseurs de proxys qui offrent un support protocolaire plus souple que les simples proxys HTTP.

Faire tourner des proxys avec les interceptors de requête Axios

Choisir un proxy au hasard directement dans votre code appelant fonctionne pour un script ponctuel. Cela s’écroule dès qu’on passe à des centaines de requêtes, car il n’y a plus d’endroit central pour suivre les proxys morts, aucune logique de retry, et le code de sélection finit copié-collé partout. Le système d’interceptors d’Axios donne à cette logique un seul endroit testable ; aucun des cinq tutos concurrents étudiés dans le SERP n’utilisait ce pattern.

Requêtes GET Axios tournant entre trois proxys avec un retry borné

Construire un pool de proxys

import axios, { AxiosError, InternalAxiosRequestConfig } from 'axios';
import { HttpsProxyAgent } from 'https-proxy-agent';

class ProxyPool {
  private agents: HttpsProxyAgent<string>[];
  private index = 0;

  constructor(proxyUrls: string[]) {
    this.agents = proxyUrls.map((url) => new HttpsProxyAgent(url));
  }

  next(): HttpsProxyAgent<string> {
    const agent = this.agents[this.index];
    this.index = (this.index + 1) % this.agents.length;
    return agent;
  }
}

const pool = new ProxyPool([
  'http://user:pass@proxy1.example.com:8080',
  'http://user:pass@proxy2.example.com:8080',
]);

const client = axios.create({ timeout: 15_000 });

client.interceptors.request.use((config: InternalAxiosRequestConfig) => {
  config.proxy = false;
  config.httpsAgent = pool.next();
  return config;
});

J’ai exécuté cela avec deux proxys locaux et confirmé que les requêtes alternaient bien : proxy A, puis proxy B, puis retour à A. Notez qu’Axios exécute les interceptors de requête en dernier entré, premier sorti ; si vous avez d’autres interceptors (en-têtes d’auth, logs), l’ordre compte plus qu’on ne le croit.

Ajouter un interceptor de réponse avec garde-fou sur les retries

C’est là que la plupart des scripts maison de rotation deviennent bancals. Retenter aveuglément chaque échec, sur un pool illimité, peut transformer une seule requête ratée en cascade de problèmes — surtout pour les méthodes non idempotentes comme POST, où un retry peut dupliquer un effet de bord que vous ne vouliez surtout pas reproduire.

type RetryableConfig = InternalAxiosRequestConfig & {
  __proxyRetryCount?: number;
};

client.interceptors.response.use(
  undefined,
  async (error: AxiosError) => {
    const config = error.config as RetryableConfig | undefined;
    if (!config) throw error;

    const method = String(config.method ?? 'get').toUpperCase();
    config.__proxyRetryCount ??= 0;
    if (method !== 'GET' || config.__proxyRetryCount >= 1) throw error;

    config.__proxyRetryCount += 1;
    config.proxy = false;
    config.httpsAgent = pool.next();
    return client.request(config);
  }
);

J’ai testé cela avec un proxy volontairement cassé et confirmé qu’un seul retry s’exécutait sur l’agent alternatif — pas de boucle infinie, pas de retry sur une requête POST. C’est ce type de limite qu’il faut viser : une politique de retry honnête sur les requêtes qu’il est sûr de rejouer, pas un bricolage « on réessaie jusqu’à ce que ça marche ».

Dépannage du proxy Axios avec cURL, 407 d’authentification et vérification des délais

Tableau de diagnostic des erreurs : associer chaque panne à son correctif

Gardez cette section sous la main. Ce sont les erreurs qui apparaissent réellement dans les issues GitHub d’Axios et les fils Stack Overflow, pas des cas théoriques.

Erreur / symptôme	Cause probable	Correctif
`ECONNREFUSED`	Mauvais hôte/port, ou serveur proxy hors ligne	Vérifiez avec `curl -x http://host:port target-url` avant de modifier le code Axios
`407 Proxy Authentication Required`	Identifiants manquants ou incorrects	Ajoutez `auth: { username, password }` à la config `proxy`, ou intégrez les identifiants dans l’URL de `HttpsProxyAgent`
`403 Forbidden`	L’origine ou le WAF a rejeté la requête ou l’IP du proxy	Vérifiez la politique d’accès du site, l’authentification et le rythme des requêtes ; ne considérez pas qu’un autre header ou une autre IP vous autorise à contourner les restrictions
La réponse affiche votre vraie IP	`NO_PROXY`, `proxy:false`, un agent direct explicite, ou une configuration historique/spécifique à une version peut contourner le proxy	Identifiez quelle couche gère le routage ; vérifiez le chemin avec un endpoint IP contrôlé et un agent explicite si nécessaire
`ETIMEDOUT`	L’intervalle de connexion ou de réponse a dépassé le timeout configuré	Mesurez où se perd le temps ; ajustez le timeout seulement si la charge le justifie, sinon remplacez ou laissez refroidir la route défaillante
`ECONNRESET` en cours de réponse	Le proxy, le réseau ou l’origine a coupé la connexion	Enregistrez à quel saut l’échec se produit ; ne rejouez que les requêtes sans risque de duplication avec un budget limité
`502 Bad Gateway` derrière Nginx	`proxy_pass` de Nginx mal configuré, ou timeout Axios ne correspondant pas à celui de Nginx	Vérifiez `proxy_connect_timeout` et `proxy_read_timeout` (tous deux à 60 s par défaut) et alignez-les avec le `timeout` Axios
`ERR_TLS_CERT_ALTNAME_INVALID`	Mauvais type d’agent pour la cible, ou certificat auto-signé	Confirmez que vous utilisez le bon agent pour le protocole ; utilisez `rejectUnauthorized: false` uniquement pour des tests locaux — jamais en production

Checklist rapide de dépannage

Quand quelque chose casse sans que vous compreniez pourquoi, procédez dans cet ordre :

Testez le proxy directement avec curl -x http://host:port https://your-target.com. Si cela échoue, investigatez la connectivité du proxy, l’authentification et la cible avant de modifier Axios. Si cela passe, le chemin Axios doit encore être vérifié séparément.
Vérifiez les versions exactes d’Axios et de Node que vous exécutez, et comparez les signalements historiques avec la même version et la même configuration avant d’appliquer leurs correctifs.
Déterminez quel système résout le proxy — config native Axios, résolution des variables d’environnement par Axios, mode proxy d’environnement intégré à Node, ou agent explicite. Ne laissez jamais plus d’un système gérer la même requête.
Inspectez NO_PROXY pour détecter des correspondances de hostname involontaires.
Si vous utilisez un agent explicite, assurez-vous que proxy: false est bien défini pour qu’Axios ne tente pas de gérer deux fois le routage.

Quand il vaut mieux éviter complètement le bricolage proxy maison

Tout ce qui précède est vraiment utile si votre objectif réel est de router du trafic arbitraire — tests réseau d’entreprise, tests géographiques d’une application, ou sortie réseau contrôlée. Mais beaucoup de développeurs finissent sur « comment configurer un proxy Axios » alors que ce qu’ils veulent vraiment, ce sont des données d’un site web, et le proxy n’est qu’un moyen d’y parvenir.

Si c’est votre cas, demandez-vous s’il vous faut vraiment un proxy, ou plutôt une API de scraping qui gère l’infrastructure pour vous. L’Open API de Thunderbit prend une URL et un schéma, puis renvoie du JSON structuré — pas d’analyse brute du HTML, pas de bibliothèque d’agent, pas de pool de proxys à entretenir. Le point de terminaison /extract gère côté serveur les pages rendues en JS, les mesures anti-bot et les CAPTCHA, et il existe aussi un point de terminaison /distill plus léger qui convertit simplement une page en Markdown propre si c’est tout ce qu’il vous faut. Il y a également un serveur MCP qui expose des outils comme thunderbit_extract et thunderbit_suggest_fields, pour que des assistants de code comme Claude ou Cursor puissent récupérer des données structurées pendant la tâche sans toucher à une config proxy, ainsi qu’un CLI pour le terminal et les workflows CI.

Point de préoccupation	Axios + proxys en mode DIY	API / MCP / CLI Thunderbit
Fourniture et rotation des proxys	À votre charge	Géré côté serveur
Défis navigateur et accès	Vous gérez la couche navigateur/réseau	Pris en charge par le service dans le cadre de ses capacités documentées
Pages rendues en JS	Besoin d’un navigateur headless	`renderMode: full`
Format de sortie	HTML brut → à parser vous-même	JSON structuré via schéma
Maintenance quand les sites changent	Vous maintenez parsing/sélecteurs	La couche d’extraction gérée réduit une partie de la maintenance côté application

Le cadrage honnête est le suivant : si vous devez router du trafic pour des tests ou du réseau d’entreprise, rien de tout cela ne remplace Axios et une config proxy. Si votre livrable est de la donnée web structurée, une approche centrée API peut réduire le code de proxy, de navigateur et de parsing que votre application doit assumer. Lors de la consultation le 7 août 2026, la documentation des limites de débit de l’API Thunderbit indiquait pour son offre Free 10 requêtes par minute et 2 requêtes simultanées. Considérez ces chiffres comme des limites API sensibles au temps et revérifiez la page avant de vous en servir en production.

Conclusion

La leçon essentielle va à l’encontre de beaucoup d’anciens tutoriels : la version actuelle d’Axios documente correctement et, lors du test local enregistré, utilise bien le tunneling CONNECT pour une cible HTTPS. Les erreurs historiques existent toujours, mais elles doivent être replacées dans le contexte de la version et de la configuration. La config native est un bon point de départ simple ; dès que vous avez besoin d’un contrôle par requête, du support SOCKS ou de la rotation, un HttpsProxyAgent explicite (ou SocksProxyAgent) associé à proxy: false vous donne une responsabilité plus claire. Et si vous faites tourner un pool en production, les interceptors de requête et de réponse offrent un point central et testable pour le faire — à condition que votre logique de retry contienne une garde anti-boucle et ne rejoue que les requêtes réellement sûres à rejouer.

Gardez le tableau de diagnostic ci-dessus sous la main pour la prochaine fois qu’une configuration de proxy vous renverra une erreur cryptique à 2 heures du matin. Et si vous réalisez que vous passez plus de temps à déboguer la plomberie du proxy qu’à utiliser réellement les données que vous voulez obtenir, il peut être utile de vérifier si un outil d’extraction API-first ne résout pas le vrai problème plus vite que l’infrastructure elle-même.

FAQ

Axios prend-il en charge les proxys HTTPS nativement ? Oui dans la version actuelle d’Axios pour un proxy HTTP classique : la documentation actuelle décrit le tunneling CONNECT pour les cibles HTTPS, et Axios 1.19.0 a bien suivi ce chemin lors du test local enregistré. Les versions historiques et certaines configurations de proxy ont produit de vrais échecs, donc vérifiez la version exacte et le proxy utilisé plutôt que de supposer un succès ou un échec universel.

Comment faire tourner des proxys dans Axios ? Utilisez un interceptor de requête pour assigner un httpsAgent différent depuis un pool de proxys avant chaque requête, et associez-le à un interceptor de réponse qui retente les requêtes échouées sur un autre proxy. Gardez une logique de retry bornée — un seul retry, et uniquement pour les méthodes idempotentes comme GET — afin de ne pas rejouer accidentellement une requête qui ne devrait pas l’être.

Pourquoi mon proxy Axios affiche-t-il ma vraie IP ? Vérifiez si NO_PROXY, proxy:false, un agent direct explicite ou un routage spécifique à l’environnement de déploiement contourne le proxy. Notez les versions d’Axios et de Node, puis testez le proxy indépendamment avec cURL. Si vous avez besoin d’un routage par requête sans ambiguïté, utilisez HttpsProxyAgent avec proxy:false et vérifiez l’IP observée sur un endpoint contrôlé.

Puis-je utiliser des proxys SOCKS5 avec Axios ? Oui, via le package socks-proxy-agent. Créez une instance SocksProxyAgent avec votre URL SOCKS, puis passez-la dans httpsAgent de la config Axios — veillez simplement à ne pas passer aussi HttpsProxyAgent, car les deux protocoles nécessitent des types d’agent différents.

Quelle est la différence entre l’option proxy et httpsAgent dans Axios ? L’option proxy est la configuration intégrée d’Axios pour un seul proxy fixe, et elle fonctionne très bien pour des cas d’usage simples dans les versions actuelles. httpsAgent accepte un agent Node.js personnalisé — comme HttpsProxyAgent ou SocksProxyAgent — et vous donne un contrôle direct, par requête, sur le routage, l’authentification et la rotation, ce pour quoi l’option native n’a jamais été conçue.

En savoir plus

Extraire des données avec l'IA

Transférez facilement des données vers Google Sheets, Airtable ou Notion

Chrome Store Rating

PRODUCT HUNT#1 Product of the Week