Axios-proxyn määrittäminen Node.js:ssä (kyllä, myös HTTPS:lle)

Jossain Stack Overflow’ssa joku on juuri nyt varma siitä, että Axios “hajoaa hiljaa” HTTPS-proxyn kanssa. Se on yksi itsepintaisimmista väitteistä Node.js-proxy-oppaissa, eikä se kuvaa tämän oppaan testaamaa nykyistä versiota. Rakensin paikallisen testiasetelman, jossa aidot HTTP- ja HTTPS-lähteet kulkivat kahden proxyn takana, ja Axios 1.19.0 ohjasi HTTPS-pyynnön oikean CONNECT-pyynnön kautta sen sijaan, että se olisi kiertänyt proxyn ohi.

Se ei tarkoita, että ihmiset kuvailevat ongelmat olisivat keksittyjä. Vanhoissa Axios-versioissa oli oikeita bugeja (katso todisteet issue #3384 ja issue #4531), ja uudemmissa Node-julkaisuissa on lisäksi toinen ympäristöproxy-reitti, joka vaatii huolellista konfigurointia. Tämä opas käy läpi, mikä todella toimii Axios 1.19.0:ssa tämänhetkisen tiedon perusteella, kaikki tavat liittää proxy pyyntöihisi, lähes missään oppaassa näkemäni rotaatiomallin interceptoreilla, sekä kattavan virhe–korjaus-taulukon siltä varalta, että jokin menee silti pieleen.

Mikä on Axios-proxy ja miksi sillä on väliä Node.js:ssä?

Axiosin yhteydessä proxy on vain välikäsipalvelin, joka seisoo Node-prosessisi ja kohdesivuston välissä. Pyyntösi menee ensin proxylle, proxy välittää sen eteenpäin, ja kohde näkee sinun sijastasi proxyn IP-osoitteen. Siinä koko idea.

Kehittäjät tarttuvat tähän muutamasta syystä: sivustojen kiertämiseen, joissa on IP-rajoituksia tai estoja, sovelluksen testaamiseen eri maantieteellisestä sijainnista, liikenteen reitittämiseen yrityksen ulospäin menevän yhteyspisteen kautta tai yksinkertaisesti oman palvelimen IP:n pitämiseen poissa kohteen lokitiedoista. Axiosin virallinen request config tarjoaa valmiin proxy-option, jossa on host, port, protocol ja auth -kentät — se on ollut olemassa vuosia, ja se on ensimmäinen asia, jonka jokainen opas (myös tämä) näyttää.

Tässä se kohta, joka usein jää selittämättä: proxy-optio toimii eri tavoin riippuen siitä, osutko HTTP- vai HTTPS-kohteeseen, ja riippuen siitä, mitä Axios-versiota käytät. Juuri siksi tämä opas on olemassa.

Node.js:n ja Axioseksen käyttöönotto (nopea lähtötilanne)

Ohita tämä, jos projektisi on jo valmiina. Muussa tapauksessa tähän menee noin kaksi minuuttia.

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

Lisää "type": "module" package.json-tiedostoon, jos haluat ESM-importit (minä haluan — CommonJS require() tuntuu proxyn demossa jo vanhahtavalta). Nykyinen Node LTS on v24.18.0, mutta ajoin testini nimenomaan versiolla v22.22.3, jotta tulokset eivät riippuisi uusimmista runtime-nyansseista.

Laita tämä tiedostoon app.js ja aja node app.js:

import axios from 'axios';

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

Sinun pitäisi nähdä vastauksessa oma oikea IP-osoitteesi. Se on vertailupisteesi — kun proxy toimii, tämän saman pyynnön pitäisi palauttaa sen sijaan proxyn IP.

Kirjaa tämä vastaus ylös ennen proxyn käyttöönottoa; näin sinulla on konkreettinen vertailuarvo, johon voit peilata proxyn kautta kulkevaa pyyntöä seuraavassa vaiheessa.

Tukeeko Axios oikeasti HTTPS-proxyjä? (Selvennetään asia)

Lyhyt vastaus: kyllä, nykyisessä vakaassa versiossa. Axios 1.19.0 dokumentoi CONNECT-tunneloinnin HTTPS-kohteille HTTP-proxyn takaa. npm-latausten API kirjasi 117 890 039 Axios-latausta ajanjaksolla 31.7.–6.8.2026, joka on vanha mutta suuntaa antava mittari kirjaston laajasta käytöstä. Kun osut HTTPS-URL:iin proxyn kautta, nykyinen Axios lähettää CONNECT-pyynnön tunnelin luomiseksi, ja TLS-kättely tapahtuu päästä päähän oikean lähteen kanssa. Testasin tämän suoraan: paikallinen HTTP-proxy, paikallinen HTTPS-lähde itse allekirjoitetulla sertifikaatilla, ja proxyni CONNECT-laskuri kasvoi juuri odotetulla tavalla.

Miksi sitten väite "Axios HTTPS proxy on rikki" nousee esiin melkein jokaisessa foorumiketjussa? Syitä on muutama, ja ne ovat kaikki todellisia:

Vanhat Axios-versiot. GitHub-issueihin viittaavat ihmiset lainaavat usein vuosia vanhoja raportteja, jotka kuvaavat tietyn version ja konfiguraation toimintaa, eikä niitä pidä yleistää nykyiseen Axiosiin.
Proxy-palvelimet ilman CONNECT-tukea. Tällöin tunnelin muodostus epäonnistuu, ja Axiosin pitäisi näyttää virhe; tarkista todellinen reitti ja virhe ennen kuin päätät, että IP ohitettiin.
proxy-asetuksen sekoittaminen johonkin muuhun. proxy-optio on forward proxy -ohjeistus, ei yleinen "reititä kaikki tämän agentin kautta riippumatta kaikesta" -kytkin.

Chromium raportoi vuonna 2023, että yli 90 % Chrome-siirtymistä suurilla alustoilla käytti HTTPS:ää. Se on vanhahko Chrome-mittaus, ei koko webin tämänhetkinen väestölaskenta, mutta se kertoo, miksi HTTPS-kohteiden käytös kuuluu tämän oppaan ytimeen. Jos käytät vanhaa Axios-julkaisua, toista ongelma nykyisellä versiolinjalla ennen kuin oletat, että historiallinen bugi kuvaa edelleen nykytilannetta; testaa päivitys omassa sovelluksessasi ennen käyttöönottoa.

Milloin explicit agent on silti parempi

Axiosin oma proxy-konfiguraatio riittää yhdelle staattiselle, tavalliselle proxylle. Mutta se alkaa rakoilla heti, kun tarvitset per-pyyntö -hallintaa, proxy-kiertoa tai SOCKS-tukea — Axiosin sisäänrakennettu optio ei vain ole tehty siihen. Siinä kohtaa HttpsProxyAgent on paikallaan, ja käyn sen läpi alla. Ajattele natiivia vaihtoehtoa muodossa "riittää yhteen proxyn käyttöön" ja agenttipohjaista lähestymistä muodossa "se, mitä oikeasti haluat tuotantoon."

Node v24:n ja v22.21+:n ympäristöproxy-reitti

Uudemmissa Node-versioissa on sisäänrakennettu ympäristöproxy-tila, joka aktivoidaan NODE_USE_ENV_PROXY=1-muuttujalla tai --use-env-proxy-lipulla. Noden omien CLI-dokumenttien mukaan tämä tuli mukaan v24.0.0:ssa ja backportattiin v22.21.0:aan — joten "Node 22+" on teknisesti väärin; tarkka raja on v22.21.0 ja sitä uudemmat kyseisellä haaralla. Jos käytössäsi on tätä aiempi Node 22 -patch, kyseistä lippua ei ole olemassa.

Nykyinen Axios lukee jo HTTP_PROXY, HTTPS_PROXY ja NO_PROXY -muuttujat proxy-from-env-riippuvuutensa kautta, joten global-agent ei ole pakollinen tällä nykyisellä Axios-polulla. Kun myös Noden oma env-proxy-tila on aktiivinen, reitityspäätökseen voi osallistua kaksi kerrosta.

Axiosin dokumentaatiossa todetaan, että Node-versioissa, joissa agentilla on proxyEnv-ominaisuus, Axios antaa reitityksen Noden hoidettavaksi sen sijaan, että se ratkaisisi sen itse. Käytännössä tämä tarkoittaa, että sinun kannattaa valita yksi järjestelmä ja pitäytyä siinä:

Anna Noden hoitaa: aseta lippu, älä määritä Axiosekseen proxy-asetusta, ja anna ympäristömuuttujien tehdä työ.
Anna Axiosekseen hoitaa: älä aseta Noden lippua, ja anna Axioseksen oman ympäristömuuttujien ratkaisun käynnistyä.
Ota täysi manuaalinen hallinta: aseta proxy: false eksplisiittisesti ja anna oma httpsAgent-arvosi — näin ohitat molemmat automaattiset järjestelmät kokonaan, ja tätä suosittelen heti kun tarvitset kiertoa tai per-pyyntölogiikkaa.

Testasin Axioseksen puolen ratkaisun suoraan: HTTP_PROXY-muuttujan asettaminen aliprosessin ympäristöön reititti pyynnön paikallisen proxyni kautta, ja vastaavan NO_PROXY-merkinnän lisääminen sai seuraavan pyynnön ohittamaan sen oikein. Eli env-muuttujapolku toimii aidosti suoraan nyt — se kaksinkertainen tila on se, johon kannattaa kiinnittää huomiota.

5 tapaa liittää proxy Axiosekseen (vertailu)

Ennen kuin sukellat koodiin, tässä kokonaiskuva. Rakensin ja testasin jokaisen näistä oikealla paikallisella proxy-asetelmalla, en vain dokumentaatiota lukemalla.

Tapa	HTTPS-tuki	Tuki autentikoinnille	Per-pyyntö -hallinta	Sopii kiertoon	Monimutkaisuus
Suora `proxy`-optio	✅ (nykyinen Axios)	✅	✅	❌	Matala
`axios.create()`-oletukset	✅ (nykyinen Axios)	✅	❌ (koko instanssille)	❌	Matala
Ympäristömuuttujat (`HTTP_PROXY`/`HTTPS_PROXY`)	✅	✅	❌	❌	Matala
`httpsAgent` + `HttpsProxyAgent`	✅	✅	✅	⚠️ (manuaalinen)	Keskitaso
Request interceptor + agent pool	✅	✅	✅	✅	Keskitaso–korkea

Käytä suoraa optiota, kun teet nopeaa skriptiä ja osut yhteen proxyn. Käytä axios.create()-mallia, kun jokaisen moduulin pyynnön pitää mennä saman proxyn läpi ilman, että kopioit asetuksia joka paikkaan. Käytä ympäristömuuttujia, kun infra-tiimi hallitsee proxy-reititystä keskitetysti ja haluat vain periä sen. Ota eksplisiittinen agentti käyttöön, kun tarvitset hallintaa, jota natiivi konfiguraatio ei tarjoa — ja ota interceptor-malli käyttöön heti kun "hallinta" muuttuu muodoksi "kierto".

Kolme Axios-proxy-reititystapaa konvergoimassa HTTPS-kohteeseen

Vaihe vaiheelta: perusproxy-konfiguraatio Axiosekseen

Yksinkertaisin asetus käyttää sisäänrakennettua proxy-oliota suoraan pyynnössä:

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

Aja tämä, niin sinun pitäisi nähdä vastauksessa proxyn IP-osoite oman IP:si sijaan. Jos testaat paikallisesti oikeaa proxya käyttäen, tämä ratkeaa yleensä alle sekunnissa — toisin kuin esimerkiksi koko järjestelmän proxy-asetuksen säätö vain yhden pyynnön testaamiseksi, joka on juuri sellaista tekemistä, joka syö vartin aikaa, jota sinulla ei ole.

Vertaa tätä vastausta lähtötilanteeseen. Onnistunut testi näyttää proxyn julkisen IP-osoitteen, ei aiemmin kirjaamaasi alkuperäistä IP:tä.

`axios.create()` koko instanssin oletuksille

Jos tietyn moduulin kaikkien pyyntöjen pitää kulkea saman proxyn kautta, upota asetus instanssiin sen sijaan että toistat konfiguraation:

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

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

Varmistin, että yksittäisessä pyynnössä annettu proxy: false ohittaa instanssin oletuksen siististi — hyödyllistä, jos 95 % kutsuista tarvitsee proxyn mutta muutama (esimerkiksi health check -ping) ei.

Proxy ympäristömuuttujien kautta

Kun reititys on keskitetysti hallittua — esimerkiksi Docker-konteissa tai CI-ympäristöissä, joissa ops-tiimi asettaa proxy-muuttujat valmiiksi — sinun ei tarvitse koskea Axios-konfiguraatioon ollenkaan:

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

Nykyinen Axios lukee nämä muuttujat ilman global-agent-kirjastoa. Muista vain yllä mainittu Node-version raja: jos NODE_USE_ENV_PROXY on myös aktiivinen, tee reitityksen omistajuus yksiselitteiseksi ja testaa NO_PROXY-käytös tuotantoympäristössä.

Vaihe vaiheelta: HTTPS-proxy-asetus `httpsAgent`-ratkaisulla (oikeaan hallintaan)

Tätä suosittelisin itse silloin, kun tarvitset enemmän kuin "yksi proxy, ikuisesti". Asenna nykyinen agenttipaketti:

npm install https-proxy-agent

https-proxy-agent 9.1.0 vaatii Node 20:n tai uudemman ja lähettää proxylle oikean CONNECT-pyynnön ennen kuin se tunneloi kohdeyhteyden sen läpi.

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,        // estä Axioseksen natiivia reititystä sotkemasta asiaa
  httpsAgent: agent,
  timeout: 15_000,
});

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

Aseta proxy: false, kun eksplisiittinen agentti omistaa reitityksen. Se tekee asetuksista yksiselitteiset ja estää Axioseksen natiivin tai ympäristöproxy-ratkaisun kilpailemisen annetun agentin kanssa.

Proxy-autentikoinnin lisääminen

Upota tunnukset suoraan proxy-URL:iin:

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

Jos salasanassasi on erikoismerkkejä — @, : ja # ovat tyypillisiä ongelmanaiheuttajia — percent-enkoodaa ne ennen URL:n rakentamista tai muodosta merkkijono komponentti kerrallaan encodeURIComponent()-funktiolla. Raaka @ salasanassa tulkitaan host-osan aluksi, ja saat yhteysvirheen, jolla ei ensisilmäyksellä näytä olevan mitään tekemistä enkoodauksen kanssa.

SOCKS5-proxyjen käyttäminen Axiosekseksi

SOCKS-proxyt eivät ole yhteensopivia HttpsProxyAgentin kanssa — tähän tarvitset eri agentin:

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 vaatii myös Node 20+:n. SOCKS5 on hyödyllinen silloin, kun käsittelet yritysverkkoja, jotka tarjoavat vain SOCKS-portin, tai proxy-palveluntarjoajia, jotka tukevat joustavampia protokollia kuin tavalliset HTTP-proxyt.

Proxyn kierto Axios request interceptorilla

Satunnaisen proxyn valitseminen suoraan kutsuvassa koodissa toimii yhdellä kertaluonteisella skriptillä. Se hajoaa heti, kun teet satoja pyyntöjä, koska ei ole keskitettyä paikkaa, joka seuraisi kuolleita proxyja, retry-logiikka puuttuu, ja proxyvalintakoodi päätyy kopioiduksi joka paikkaan. Axiosin interceptor-järjestelmä antaa tuolle logiikalle yhden testattavan kodin; yksikään tämän artikkelin SERP-katsauksen viidestä kilpailijaoppaasta ei käyttänyt tätä mallia.

Axios GET -pyynnöt kiertämässä kolmen proxyn läpi yhden rajatun retry-kerran kanssa

Proxy-poolin rakentaminen

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

Ajoin tämän kahden paikallisen proxyn läpi ja varmistan, että pyynnöt vuorottelivat oikein — proxy A, sitten proxy B, sitten takaisin A:han. Huomaa, että Axios suorittaa request-interceptorit viimeinen sisään, ensimmäisenä ulos -periaatteella, joten jos sinulla on muita interceptoreita (autentikointipäät, lokitus), järjestyksellä on suurempi merkitys kuin ehkä ajattelisit.

Response interceptor ja retry-suojaukset

Tässä kohtaa useimmat itse tehdyt rotaatioskriptit alkavat muuttua huolimattomiksi. Sokeasti kaikkia virheitä toistava retry, rajattoman poolin kanssa, voi tehdä yhdestä huonosta pyynnöstä ketjureaktion — erityisesti ei-idempotenteilla metodeilla kuten POST, joissa retry saattaa kopioida sivuvaikutuksen, jota et oikeasti halunnut monistaa.

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

Testasin tämän tarkoituksella rikkinäisen proxyn kanssa ja varmistin, että tasan yksi retry käynnistyi vaihtoehtoisella agentilla — ei ääretöntä silmukkaa, ei retryä POST-pyynnölle. Juuri tuollainen raja on se, mitä haluat: retry-politiikka, joka on rehellinen siitä, mitkä pyynnöt on turvallista ajaa uudelleen, ei "yritetään vaan uudestaan kunnes toimii" -viritys.

Axios-proxyn debuggaus cURL:lla, 407-autentikoinnilla ja timeout-tarkistuksilla

Virhediagnostiikkataulukko: yhdistä jokainen virhe oikeaan korjaukseen

Tallenna tämä kirjanmerkkeihin. Nämä ovat juuri niitä virheitä, jotka näkyvät Axiosin GitHub-issueissa ja Stack Overflow -ketjuissa, eivät hypoteettisia tapauksia.

Virhe / oire	Todennäköinen syy	Korjaus
`ECONNREFUSED`	Väärä host/portti tai proxy-palvelin on alhaalla	Varmista toiminta `curl -x http://host:port target-url` -komennolla ennen kuin muutat Axios-koodia
`407 Proxy Authentication Required`	Tunnukset puuttuvat tai ovat väärät	Lisää `auth: { username, password }` `proxy`-asetukseen tai upota tunnukset `HttpsProxyAgent`-URL:iin
`403 Forbidden`	Kohde tai WAF hylkäsi pyynnön tai proxy-IP:n	Tarkista sivuston käyttöpolitiikka, autentikointi ja pyyntötaso; älä tulkitse eri headeria tai IP:tä luvaksi kiertää rajoituksia
Vastaus näyttää oman oikean IP:si	`NO_PROXY`, `proxy:false`, eksplisiittinen suora agentti tai historiallinen/versiokohtainen konfiguraatio voi ohittaa proxyn	Selvitä, mikä kerros omistaa reitityksen; tarkista polku kontrolloidulla IP-endpointilla ja tarvittaessa eksplisiittisellä agentilla
`ETIMEDOUT`	Yhteys- tai vastausvaihe ylitti asetetun timeoutin	Mittaa, mihin aika kuluu; säädä timeoutia vain jos työkuorma sitä oikeasti vaatii, muuten vaihda tai jäähdytä huono reitti
`ECONNRESET` kesken vastauksen	Proxy, verkko tai kohde sulki yhteyden	Kirjaa epäonnistuva hoppi; retryä vain uudelleenkäsiteltävät pyynnöt rajatulla budjetilla
`502 Bad Gateway` Nginxin takana	Nginxin `proxy_pass` on väärin konfiguroitu, tai Axioseksen timeout ei vastaa Nginxiä	Tarkista `proxy_connect_timeout` ja `proxy_read_timeout` (molemmat oletuksena 60 s) ja sovita ne Axioseksen `timeout`-asetukseen
`ERR_TLS_CERT_ALTNAME_INVALID`	Väärä agenttityyppi kohteelle tai itse allekirjoitettu sertifikaatti	Varmista, että käytät protokollaan oikeaa agenttia; aseta `rejectUnauthorized: false` vain paikalliseen testaukseen — ei koskaan tuotannossa

Nopea debug-checklist

Kun jokin hajoaa etkä tiedä miksi, käy tämä läpi tässä järjestyksessä:

Testaa proxy suoraan komennolla curl -x http://host:port https://your-target.com. Jos se epäonnistuu, selvitä proxyn yhteys, autentikointi ja kohde ennen Axiosekseen koskemista. Jos se toimii, Axioseksen reitti pitää silti tarkistaa erikseen.
Varmista, mitä Axios- ja Node-versioita oikeasti käytät, ja vertaa historiallisia raportteja samaan versioon ja konfiguraatioon ennen kuin sovellat niiden korjauksia.
Selvitä, mikä järjestelmä ratkaisee proxyn — Axioseksen natiivi konfiguraatio, Axioseksen env-muuttujien ratkaisu, Noden sisäänrakennettu env-proxy-tila vai eksplisiittinen agentti. Älä anna useamman kuin yhden omistaa samaa pyyntöä.
Tarkista NO_PROXY-arvosta tahattomat hostname-matchit.
Jos käytät eksplisiittistä agenttia, varmista, että proxy: false on asetettu, jotta Axios ei yritä käsitellä sitä kahteen kertaan.

Milloin kannattaa ohittaa koko DIY-proxy-putki

Kaikki yllä oleva on aidosti hyödyllistä, jos todellinen tavoitteesi on reitittää mielivaltaista liikennettä — esimerkiksi yritysverkon testaus, sovelluksen geo-testit tai hallittu ulospäin menevä verkkoliikenne. Mutta moni päätyy hakemaan "miten asetan Axios-proxyn" siksi, että he oikeasti haluavat dataa sivustolta, ja proxy on vain väline siihen.

Jos tilanne on tämä, kannattaa kysyä, tarvitsetko ylipäätään proxyn vai tarvitsetko scraping API:n, joka hoitaa infrastruktuurin puolestasi. Thunderbitin Open API ottaa URL-osoitteen ja skeeman ja palauttaa rakenteista JSONia — ei raakaa HTML-parsintaa, ei agenttikirjastoja, ei proxy-poolin vahtimista. /extract-endpoint käsittelee JS:llä renderöidyt sivut, bot-suojaukset ja CAPTCHA:t palvelinpuolella, ja tarjolla on myös kevyempi /distill-endpoint, joka muuntaa sivun siistiksi Markdowniksi, jos se riittää. Saatavilla on myös MCP-serveri, joka tarjoaa työkalut kuten thunderbit_extract ja thunderbit_suggest_fields, joten Claude- tai Cursor-tyyppiset koodiavustajat voivat hakea rakenteista dataa kesken työn ilman, että proxya tarvitsee koskea lainkaan, sekä CLI terminaali- ja CI-työnkulkuihin.

Huoli	DIY Axios + proxyt	Thunderbit API/MCP/CLI
Proxyjen hankinta ja kierto	Sinä hallitset	Hoidetaan palvelinpuolella
Selain- ja pääsyhaasteet	Sinä hallitset selain/verkkokerroksen	Palvelu hoitaa dokumentoiduissa rajoissaan
JS-renderöidyt sivut	Tarvitset headless-selaimen	`renderMode: full`
Tulostusmuoto	Raaka HTML → sinä parsit	Rakenteinen JSON skeeman kautta
Ylläpito sivustojen muuttuessa	Sinä ylläpidät parsintaa/selektoreita	Hallittu poimintakerros vähentää osan sovellustason ylläpidosta

Rehellinen tulkinta: jos tarvitset liikenteen reititystä testaukseen tai yritysverkkoon, mikään tästä ei korvaa Axiosekseen ja proxy-konfiguraatiota. Jos lopputuotteesi on rakenteinen verkkodata, API-first-lähestymistapa voi vähentää proxy-, selain- ja parsintakoodia, jonka sovelluksesi joutuu omistamaan. Hakuhetkellä 7.8.2026 Thunderbitin API:n rate limit -dokumentaatio ilmoitti Free-tasolle 10 pyyntöä minuutissa ja 2 rinnakkaista pyyntöä. Käsittele näitä aikaherkkänä API-rajoituksena ja tarkista sivu uudelleen ennen kuin luotat niihin tuotannossa.

Yhteenveto

Tämän jutun ydin menee ristiin sen kanssa, mitä moni vanhempi opas väittää: nykyinen Axios dokumentoi ja paikallisessa testissäni myös käytti CONNECT-tunnelointia HTTPS-kohteelle oikein. Historialliset virheet ovat yhä tärkeitä, mutta niihin tarvitaan version ja konfiguraation konteksti. Natiivi konfiguraatio on hyvä matalan kompleksisuuden lähtökohta; kun tarvitset per-pyyntö -hallintaa, SOCKS-tukea tai kiertoa, eksplisiittinen HttpsProxyAgent (tai SocksProxyAgent) yhdessä proxy: false -asetuksen kanssa antaa selkeämmän omistajuuden. Ja jos kierrät poolin läpi tuotannossa, request- ja response-interceptorit tarjoavat keskitetyn, testattavan paikan tehdä se — kunhan retry-logiikassa on loop-suoja ja se toistaa vain oikeasti turvalliset pyynnöt.

Tallenna yllä oleva diagnostiikkataulukko kirjanmerkkeihin seuraavaa kertaa varten, kun proxy-asetus heittää kryptisen virheen kello kahdelta yöllä. Ja jos huomaat käyttäväsi enemmän aikaa proxy-putken debuggaukseen kuin itse datan hyödyntämiseen, kannattaa tarkistaa, ratkaisiko API-first-poimintatyökalu varsinaisen ongelman nopeammin kuin infrastruktuuri koskaan voisi.

UKK

Tukeeko Axios HTTPS-proxyjä natiivisti?
Kyllä nykyisessä Axioseksessa tavallisen HTTP-proxyn kautta: nykyinen dokumentaatio kuvaa CONNECT-tunneloinnin HTTPS-kohteille, ja Axios 1.19.0 läpäisi tämän reitin kirjatussa paikallistestissä. Historialliset julkaisut ja tietyt proxy-konfiguraatiot ovat aiheuttaneet oikeita virheitä, joten varmista tarkka versio ja proxy-asetus äläkä oleta joko aina onnistumista tai aina epäonnistumista.

Miten kierrätän proxyt Axiosekseen?
Käytä request interceptoria, joka valitsee eri httpsAgent-arvon proxy-poolista ennen jokaista lähetettävää pyyntöä, ja yhdistä siihen response interceptor, joka yrittää epäonnistuneet pyynnöt uudelleen eri proxyn kautta. Pidä retry-logiikka rajattuna — yksi retry ja vain idempotentteihin metodeihin kuten GET — jotta et vahingossa toista pyyntöä, jota ei pitäisi toistaa.

Miksi Axioseksen proxy näyttää oman oikean IP-osoitteeni?
Tarkista, ohittiko proxyn NO_PROXY, proxy:false, eksplisiittinen suora agentti tai deploy-kohtainen reititys. Kirjaa Axios- ja Node-versiot ja testaa proxy erikseen cURL:lla. Jos tarvitset yksiselitteisen per-pyyntöreitityksen, käytä HttpsProxyAgent-ratkaisua yhdessä proxy:false-asetuksen kanssa ja varmista havaittu IP kontrolloidussa endpointissa.

Voinko käyttää SOCKS5-proxyjä Axiosekseen?
Kyllä, socks-proxy-agent-paketin kautta. Luo SocksProxyAgent omalla SOCKS-URL:llasi ja anna se Axios-konfiguraatiossa httpsAgent-kenttään — varmista vain, ettet anna samalla HttpsProxyAgent-arvoa, koska nämä kaksi protokollaa käyttävät eri agenttityyppiä.

Mitä eroa on Axioseksen proxy-optiolla ja httpsAgent-kentällä?
proxy on Axioseksen sisäänrakennettu konfiguraatio yhdelle staattiselle proxylle, ja se toimii hyvin suoraviivaisissa käyttötapauksissa nykyversioissa. httpsAgent hyväksyy oman Node.js-agentin — kuten HttpsProxyAgent tai SocksProxyAgent — ja antaa sinulle suoran, per-pyyntö -hallinnan reititykseen, autentikointiin ja kiertoon, johon natiivia optiota ei koskaan suunniteltu.

Lue lisää

Poimi tietoja tekoälyn avulla

Siirrä tiedot helposti Google Sheetsiin, Airtableen tai Notioniin

Chrome Store Rating

PRODUCT HUNT#1 Product of the Week