Come configurare un proxy Axios in Node.js (sì, anche per HTTPS)

Da qualche parte su Stack Overflow, proprio adesso, c’è qualcuno convinto che Axios “si rompa in silenzio” con i proxy HTTPS. È una delle frasi che ricorre più spesso nelle guide sui proxy per Node.js, ma non descrive la versione attuale testata per questa guida. Ho montato un ambiente di test locale con origin HTTP e HTTPS reali dietro due proxy, e Axios 1.19.0 ha instradato la richiesta HTTPS tramite una corretta richiesta CONNECT, invece di aggirare il proxy.

Questo non vuol dire che i problemi segnalati siano inventati. Le vecchie versioni di Axios avevano bug reali (vedi issue #3384 e issue #4531 per i dettagli), e le release recenti di Node introducono un secondo percorso di proxy tramite environment che richiede una configurazione attenta. Questa guida spiega cosa funziona davvero in Axios 1.19.0 oggi, tutti i modi per collegare un proxy alle tue richieste, un pattern di rotazione con gli interceptor che quasi nessuna guida mostra, e una tabella completa errori-soluzioni per quando qualcosa va comunque storto.

Cos’è un proxy in Axios (e perché conta in Node.js)?

Nel contesto di Axios, un proxy è semplicemente un server intermedio che si mette in mezzo tra il processo Node e il sito di destinazione. La tua richiesta arriva prima al proxy, il proxy la inoltra e il sito vede l’IP del proxy invece del tuo. Tutto qui il meccanismo.

Gli sviluppatori lo usano per diversi motivi: fare scraping di siti che limitano il traffico o bloccano per IP, testare il comportamento di un’app da un’altra area geografica, instradare il traffico tramite un’uscita aziendale, oppure semplicemente tenere l’IP del proprio server fuori dai log di accesso di un target. La configurazione ufficiale delle richieste di Axios espone un’opzione proxy integrata con i campi host, port, protocol e auth — esiste da anni, ed è la prima cosa che ogni tutorial (compreso questo) ti mostra.

Ecco il punto che spesso viene semplificato troppo: l’opzione proxy si comporta in modo diverso a seconda che tu stia colpendo un target HTTP o HTTPS, e a seconda della versione di Axios che stai usando. È proprio questa distinzione il motivo per cui esiste questa guida.

Configurare Node.js e Axios (base rapida)

Salta questo passaggio se hai già un progetto pronto. Altrimenti, servono circa due minuti.

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

Aggiungi "type": "module" al tuo package.json se vuoi usare gli import ESM (io sì — usare require() di CommonJS per una demo sul proxy sa un po’ di vecchio). La versione LTS attuale di Node è la v24.18.0, anche se ho eseguito i test specificamente su v22.22.3, così i risultati non dipendessero da stranezze dell’ultimissima runtime.

Inserisci questo in app.js ed esegui node app.js:

import axios from 'axios';

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

Dovresti vedere il tuo vero indirizzo IP nella risposta. Questo è il tuo baseline: una volta che il proxy funziona, la stessa richiesta dovrebbe restituire l’IP del proxy.

Registra questa risposta prima di attivare il proxy; ti dà un riferimento concreto con cui confrontare la richiesta proxy nel passaggio successivo.

Axios supporta davvero i proxy HTTPS? Facciamo chiarezza

Risposta breve: sì, nella release stabile attuale. Axios 1.19.0 documenta il tunneling CONNECT per i target HTTPS dietro un proxy HTTP. L’API dei download di npm ha registrato 117.890.039 download di Axios dal 31 luglio al 6 agosto 2026, un dato datato ma utile per capire quanto la libreria sia diffusa. Quando raggiungi un URL HTTPS tramite un proxy, Axios invia una richiesta CONNECT per stabilire il tunnel, e il handshake TLS avviene end-to-end con l’origin reale. L’ho verificato direttamente: proxy HTTP locale, origin HTTPS locale con certificato self-signed, e il contatore CONNECT sul proxy è aumentato esattamente come previsto.

Allora perché “Axios HTTPS proxy broken” compare praticamente in ogni thread dei forum? Per vari motivi, e sono tutti reali:

Vecchie versioni di Axios. Le issue linkate spesso hanno anni e descrivono comportamenti legati a release e configurazioni specifiche, che non andrebbero generalizzati alla versione attuale.
Proxy server senza supporto CONNECT. In quel caso il tunnel fallisce e Axios dovrebbe restituire un errore; conviene tracciare il percorso reale e l’errore prima di ipotizzare un bypass dell’IP.
Confusione tra proxy e ciò che non è. L’opzione proxy è un’istruzione da forward proxy, non un interruttore generico che dice “instrada tutto attraverso questo agente, sempre e comunque”.

Chromium ha riportato nel 2023 che oltre il 90% delle navigazioni Chrome sulle principali piattaforme usava HTTPS. È una misura di Chrome datata, non un censimento attuale dell’intero web, ma spiega perché il comportamento verso target HTTPS debba stare al centro di questo tutorial. Se usi una vecchia release di Axios, riproduci il problema sulla linea attuale prima di assumere che un bug storico descriva ancora il comportamento presente; testa l’upgrade nella tua applicazione prima di distribuirlo.

Quando ti serve comunque un agent esplicito

La configurazione nativa proxy va bene per un proxy singolo, statico e tradizionale. Ma diventa insufficiente appena ti serve controllo per richiesta, rotazione dei proxy o supporto SOCKS — l’opzione integrata di Axios semplicemente non è pensata per questo. È qui che HttpsProxyAgent diventa utile, e più sotto vedremo come usarlo. Considera l’opzione nativa come “abbastanza buona per un proxy, un solo scopo” e l’approccio basato su agent come “quello che ti serve davvero in produzione”.

Il percorso proxy via environment in Node v24 e v22.21+

Le release recenti di Node includono una modalità proxy tramite variabili d’ambiente, attivabile con NODE_USE_ENV_PROXY=1 o con il flag --use-env-proxy. Secondo la documentazione CLI di Node, questa funzionalità è arrivata in v24.0.0 ed è stata backportata fino a v22.21.0 — quindi dire “Node 22+” è tecnicamente impreciso; vale specificamente da v22.21.0 in poi su quella linea. Se hai una patch precedente di Node 22, questo flag non esiste proprio.

Axios attuale risolve già HTTP_PROXY, HTTPS_PROXY e NO_PROXY tramite la dipendenza proxy-from-env, quindi global-agent non è necessario per questo percorso attuale di Axios. Se è attiva anche la modalità env-proxy nativa di Node, nella decisione di routing possono entrare in gioco due livelli.

La documentazione di Axios nota che, sulle versioni di Node in cui l’agent espone una proprietà proxyEnv, Axios lascia a Node la gestione invece di fare una propria risoluzione. In pratica, conviene scegliere un solo sistema e attenersi a quello:

Lasciare fare a Node: imposta il flag, non impostare proxy in Axios e lascia che siano le variabili d’ambiente a fare il lavoro.
Lasciare fare ad Axios: non impostare il flag di Node e lascia che entri in gioco la risoluzione delle variabili d’ambiente di Axios.
Prendere il controllo manuale completo: imposta esplicitamente proxy: false e fornisci il tuo httpsAgent — così aggiri entrambi i sistemi automatici, ed è ciò che consiglio quando ti serve rotazione o logica per richiesta.

Ho testato direttamente la risoluzione lato Axios: impostare HTTP_PROXY nell’ambiente di un processo figlio ha instradato la richiesta attraverso il mio proxy locale, e aggiungere una voce corrispondente in NO_PROXY ha fatto saltare correttamente il proxy alla richiesta successiva. Quindi il percorso via variabili d’ambiente funziona davvero subito; il caso a doppia modalità è quello da tenere d’occhio.

5 modi per collegare un proxy ad Axios, a confronto

Prima di passare al codice, ecco il quadro generale. Ho costruito e testato ognuno di questi casi su un setup proxy locale reale, non solo leggendo la documentazione.

Metodo	Supporto HTTPS	Supporto auth	Controllo per richiesta	Adatto alla rotazione	Complessità
Opzione inline `proxy`	✅ (Axios attuale)	✅	✅	❌	Bassa
Default di `axios.create()`	✅ (Axios attuale)	✅	❌ (a livello di istanza)	❌	Bassa
Variabili d’ambiente (`HTTP_PROXY`/`HTTPS_PROXY`)	✅	✅	❌	❌	Bassa
`httpsAgent` + `HttpsProxyAgent`	✅	✅	✅	⚠️ (manuale)	Media
Interceptor di richiesta + pool di agent	✅	✅	✅	✅	Medio-alta

Usa l’opzione inline per uno script rapido che passa da un solo proxy. Usa axios.create() quando tutte le richieste di un modulo devono passare dallo stesso proxy senza ripetere la configurazione. Usa le variabili d’ambiente quando il tuo team infrastrutturale gestisce già il routing proxy in modo centralizzato e tu vuoi solo ereditarlo. Passa a un agent esplicito quando ti serve un controllo che la configurazione nativa non può darti — e passa al pattern con interceptor nel momento in cui il “controllo” diventa “rotazione”.

Tre metodi di routing proxy di Axios che convergono su una destinazione HTTPS

Passo dopo passo: configurazione proxy di base in Axios

La configurazione più semplice usa direttamente l’oggetto proxy nella richiesta:

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);

Esegui questo codice e dovresti vedere l’IP del proxy nella risposta, invece del tuo. Se stai testando localmente con un proxy reale, in genere si risolve in molto meno di un secondo — rispetto, per esempio, a configurare manualmente un proxy a livello di sistema solo per testare una richiesta, che è il tipo di cosa che ti mangia quindici minuti che non hai.

Confronta questa risposta con il baseline. Un test riuscito dovrebbe mostrare l’IP pubblico del proxy invece dell’IP origin che hai registrato prima.

Usare `axios.create()` per impostazioni predefinite a livello di istanza

Se ogni richiesta in un dato modulo deve passare dallo stesso proxy, incorpora la configurazione in un’istanza invece di ripeterla:

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

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

Ho verificato che un override proxy: false su una singola richiesta bypassa pulitamente il default dell’istanza — utile se il 95% delle chiamate deve usare il proxy, ma alcune (ad esempio un ping di health check) no.

Impostare il proxy tramite variabili d’ambiente

Per routing gestito centralmente — pensa a container Docker o ambienti CI in cui ops imposta già le variabili proxy — non devi toccare affatto la configurazione di 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 attuale legge queste variabili senza global-agent. Ricorda però il confine di versione di Node visto sopra: se è attiva anche NODE_USE_ENV_PROXY, chiarisci chi è il proprietario del routing e testa il comportamento di NO_PROXY nell’ambiente effettivamente distribuito.

Passo dopo passo: configurazione di un proxy HTTPS con `httpsAgent` (per controllo reale)

Questa è la configurazione che consiglierei davvero quando ti serve più di “un proxy, sempre”. Installa il pacchetto agent attuale:

npm install https-proxy-agent

https-proxy-agent 9.1.0 richiede Node 20 o superiore e invia al proxy una corretta richiesta CONNECT prima di incanalare attraverso di esso la connessione verso il target.

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,        // impedisce alla risoluzione nativa di Axios di intervenire di nuovo
  httpsAgent: agent,
  timeout: 15_000,
});

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

Imposta proxy: false quando il routing è gestito da un agent esplicito. In questo modo la configurazione resta inequivocabile e si evita che la risoluzione nativa o via environment di Axios entri in conflitto con l’agent fornito.

Aggiungere l’autenticazione del proxy

Includi le credenziali direttamente nell’URL del proxy:

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

Se la password contiene caratteri speciali — @, :, # sono i classici problemi — codificali in percentuale prima di costruire l’URL, oppure comporre la stringa con encodeURIComponent() su ogni componente. Un @ non codificato nella password viene interpretato come inizio della sezione host, e otterrai un errore di connessione che apparentemente non ha nulla a che fare con la codifica.

Usare proxy SOCKS5 con Axios

I proxy SOCKS non sono compatibili con HttpsProxyAgent — per quel protocollo serve un agent diverso:

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 richiede anch’esso Node 20+. SOCKS5 vale la pena quando lavori con reti aziendali che espongono solo un gateway SOCKS, oppure con provider di proxy che offrono supporto di protocollo più flessibile dei semplici proxy HTTP.

Ruotare i proxy con gli interceptor di richiesta di Axios

Scegliere un proxy casuale direttamente nel codice chiamante va bene per uno script occasionale. Crolla nel momento in cui fai centinaia di richieste, perché non esiste un punto centrale che tenga traccia dei proxy morti, manca una logica di retry e il codice di selezione finisce copiato ovunque. Il sistema di interceptor di Axios offre a questa logica un unico posto testabile; nessuno dei cinque tutorial concorrenti analizzati nella SERP di questo articolo usava questo pattern.

Richieste GET di Axios che ruotano su tre proxy con un retry limitato

Costruire un pool di proxy

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;
});

Ho eseguito questo test con due proxy locali e ho verificato che le richieste si alternassero correttamente — proxy A, poi proxy B, poi di nuovo A. Nota che Axios esegue gli interceptor di richiesta in ordine last-in-first-out, quindi se hai altri interceptor (header di auth, logging), l’ordine conta più di quanto sembri.

Aggiungere un interceptor di risposta con guardie per il retry

Qui è dove la maggior parte degli script fai-da-te sulla rotazione diventa trascurata. Ritentare alla cieca ogni errore, su un pool illimitato, può trasformare una singola richiesta sbagliata in un disastro a cascata — soprattutto per metodi non idempotenti come POST, dove il retry potrebbe duplicare un effetto collaterale che non volevi affatto duplicare.

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);
  }
);

Ho testato questo pattern contro un proxy volutamente rotto e ho confermato che veniva eseguito esattamente un retry sull’agent alternativo — nessun loop infinito, nessun retry su una richiesta POST. È questo il limite che vuoi: una policy di retry onesta su quali richieste si possono ripetere, non un trucco del tipo “riprova finché non funziona”.

Troubleshooting del proxy Axios con cURL, autenticazione 407 e controlli di timeout

Tabella diagnostica degli errori: collega ogni problema alla soluzione

Salva questa sezione tra i preferiti. Sono gli errori che compaiono davvero nelle issue GitHub di Axios e nei thread di Stack Overflow, non quelli teorici.

Errore / sintomo	Causa probabile	Soluzione
`ECONNREFUSED`	Host/porta errati, oppure il server proxy è offline	Verifica con `curl -x http://host:port target-url` prima di mettere mano al codice Axios
`407 Proxy Authentication Required`	Credenziali mancanti o errate	Aggiungi `auth: { username, password }` alla configurazione `proxy`, oppure inserisci le credenziali nell’URL di `HttpsProxyAgent`
`403 Forbidden`	L’origin o il WAF ha respinto la richiesta o l’IP del proxy	Controlla policy di accesso, autenticazione e frequenza delle richieste; non interpretare un header diverso o un IP diverso come permesso a bypassare restrizioni
La risposta mostra il tuo IP reale	`NO_PROXY`, `proxy:false`, un agent diretto esplicito o una configurazione storica/specifica della versione potrebbe stare aggirando il proxy	Verifica quale livello sta gestendo il routing; controlla il percorso con un endpoint IP controllato e, se serve, un agent esplicito
`ETIMEDOUT`	Il tempo di connessione o di risposta ha superato il timeout configurato	Misura dove si perde tempo; aumenta il timeout solo se il carico lo giustifica, altrimenti sostituisci o raffredda il percorso non sano
`ECONNRESET` a metà risposta	Il proxy, la rete o l’origin ha chiuso la connessione	Registra l’hop che fallisce; ritenta solo richieste sicure da riprodurre con un budget finito
`502 Bad Gateway` dietro Nginx	`proxy_pass` di Nginx configurato male, oppure il timeout di Axios non è allineato a quello di Nginx	Controlla `proxy_connect_timeout` e `proxy_read_timeout` (entrambi predefiniti a 60s) e allineali al tuo `timeout` di Axios
`ERR_TLS_CERT_ALTNAME_INVALID`	Agent sbagliato per il target, oppure certificato self-signed	Verifica di usare l’agent corretto per il protocollo; usa `rejectUnauthorized: false` solo per test locali — mai in produzione

Checklist rapida di debugging

Quando qualcosa si rompe e non capisci perché, procedi in quest’ordine:

Testa il proxy direttamente con curl -x http://host:port https://your-target.com. Se fallisce, indaga connettività del proxy, autenticazione e target prima di cambiare Axios. Se passa, il percorso Axios va comunque verificato a parte.
Conferma quali versioni di Axios e Node stai davvero usando, e confronta i report storici con la stessa release/configurazione prima di applicarne le soluzioni.
Capisci quale sistema sta risolvendo il proxy — configurazione nativa di Axios, risoluzione via variabili d’ambiente di Axios, modalità env-proxy nativa di Node, oppure un agent esplicito. Non lasciare mai che più di uno gestisca la stessa richiesta.
Controlla NO_PROXY per eventuali match accidentali sull’hostname.
Se usi un agent esplicito, assicurati che proxy: false sia impostato, così Axios non cerca di gestirlo due volte.

Quando conviene saltare del tutto l’impianto proxy fai-da-te

Tutto quanto sopra è davvero utile se il tuo obiettivo reale è instradare traffico arbitrario — test di rete aziendale, test geografico di un’app o uscita controllata verso Internet. Ma molti arrivano a chiedersi “come configuro un proxy Axios” perché in realtà vogliono dati da un sito web, e il proxy è solo un mezzo.

Se è il tuo caso, vale la pena chiedersi se ti serve davvero un proxy, oppure se ti serve una scraping API che gestisca l’infrastruttura al posto tuo. L’Open API di Thunderbit prende un URL e uno schema e restituisce JSON strutturato — niente parsing di HTML grezzo, niente librerie di agent, niente pool di proxy da mantenere. L’endpoint /extract gestisce lato server pagine renderizzate in JS, misure anti-bot e CAPTCHA, e c’è anche un endpoint più leggero /distill che converte semplicemente una pagina in Markdown pulito se ti basta quello. C’è anche un server MCP che espone strumenti come thunderbit_extract e thunderbit_suggest_fields, così assistenti di codice come Claude o Cursor possono recuperare dati strutturati nel mezzo del lavoro senza toccare affatto una configurazione proxy, oltre a una CLI per terminale e flussi CI.

Aspetto	DIY Axios + Proxy	Thunderbit API/MCP/CLI
Sourcing e rotazione dei proxy	Li gestisci tu	Gestiti lato server
Sfide browser e accesso	Gestisci tu il livello browser/rete	Gestito dal servizio entro le capacità documentate
Pagine renderizzate in JS	Serve un browser headless	`renderMode: full`
Formato di output	HTML grezzo → parsing a carico tuo	JSON strutturato via schema
Manutenzione quando i siti cambiano	Mantieni tu parsing/selettori	Il livello gestito di estrazione riduce parte della manutenzione lato applicazione

La formulazione onesta è questa: se devi instradare traffico per test o networking aziendale, nulla di tutto questo sostituisce Axios e una configurazione proxy. Se il tuo risultato finale sono dati web strutturati, un approccio API-first può ridurre il codice di proxy, browser e parsing che la tua applicazione deve mantenere. Al momento del recupero, il 7 agosto 2026, la documentazione dei limiti di rate dell’API di Thunderbit indicava il piano Free a 10 richieste al minuto e 2 richieste concorrenti. Considerali limiti API soggetti al tempo e ricontrolla la pagina prima di farci affidamento in produzione.

Conclusione

La lezione principale qui va contro quello che dicono molte guide più vecchie: Axios attuale documenta e, nel test locale registrato, ha usato correttamente il tunneling CONNECT per un target HTTPS. I fallimenti storici contano ancora, ma vanno letti nel contesto di versione e configurazione. La configurazione nativa è un buon punto di partenza a bassa complessità; quando ti serve controllo per richiesta, supporto SOCKS o rotazione, un HttpsProxyAgent esplicito (o SocksProxyAgent) con proxy: false ti dà una gestione più chiara. E se in produzione stai ruotando su un pool, gli interceptor di richiesta e risposta ti offrono un punto centralizzato e testabile per farlo — assicurati solo che la logica di retry abbia un guard rail contro i loop e ritenti solo richieste davvero sicure da ripetere.

Tieni tra i preferiti la tabella diagnostica qui sopra per la prossima volta che una configurazione proxy ti lancia un errore criptico alle 2 di notte. E se ti accorgi di passare più tempo a fare debug del plumbing del proxy che a usare davvero i dati che volevi ottenere, forse vale la pena verificare se uno strumento di estrazione API-first risolve il problema reale più velocemente di quanto non faccia l’infrastruttura.

FAQ

Axios supporta nativamente i proxy HTTPS? Sì, nella versione attuale di Axios per un proxy HTTP convenzionale: la documentazione attuale descrive il tunneling CONNECT per i target HTTPS, e Axios 1.19.0 ha superato quel percorso nel test locale registrato. Le release storiche e alcune configurazioni proxy specifiche hanno prodotto errori reali, quindi verifica la versione esatta e il proxy usato invece di dare per scontato un successo o un fallimento universale.

Come ruoto i proxy in Axios? Usa un interceptor di richiesta per assegnare a ogni richiesta un httpsAgent diverso preso da un pool di proxy, e abbinalo a un interceptor di risposta che ritenti le richieste fallite su un proxy diverso. Mantieni la logica di retry limitata — un solo retry, e solo per metodi idempotenti come GET — così non ripeti accidentalmente una richiesta che non dovrebbe essere ripetuta.

Perché il mio proxy Axios mostra il mio IP reale? Controlla se NO_PROXY, proxy:false, un agent diretto esplicito o un routing specifico dell’ambiente di deploy hanno bypassato il proxy. Registra le versioni di Axios e Node e testa il proxy indipendentemente con cURL. Se ti serve un routing per richiesta senza ambiguità, usa HttpsProxyAgent con proxy:false e verifica l’IP osservato su un endpoint controllato.

Posso usare proxy SOCKS5 con Axios? Sì, tramite il pacchetto socks-proxy-agent. Crea un’istanza SocksProxyAgent con l’URL SOCKS e passala come httpsAgent nella configurazione Axios — assicurati solo di non passare anche HttpsProxyAgent, perché i due protocolli richiedono tipi di agent diversi.

Qual è la differenza tra l’opzione proxy e httpsAgent in Axios? L’opzione proxy è la configurazione integrata di Axios per un singolo proxy statico e va benissimo per casi d’uso semplici nelle versioni attuali. httpsAgent accetta un agent Node.js personalizzato — come HttpsProxyAgent o SocksProxyAgent — e ti dà controllo diretto, per richiesta, su routing, autenticazione e rotazione, qualcosa per cui l’opzione nativa non è mai stata progettata.

Scopri di più

Estrai dati usando l'AI

Trasferisci facilmente i dati su Fogli Google, Airtable o Notion

Chrome Store Rating

PRODUCT HUNT#1 Product of the Week