Så ställer du in Axios-proxy för Node.js (ja, även för HTTPS)

Någonstans på Stack Overflow just nu sitter någon och är övertygad om att Axios ”stör” HTTPS-proxyer utan att säga till. Det är ett av de mest återkommande påståendena i guider om Node.js-proxyer, och det beskriver inte den version som användes i den här guiden. Jag satte upp en lokal testmiljö med riktiga HTTP- och HTTPS-originservrar bakom två proxyer, och Axios 1.19.0 tunnelade HTTPS-requesten via en korrekt CONNECT-request i stället för att gå runt proxyn.

Det betyder inte att problemen folk beskriver är påhittade. Äldre Axios-versioner hade faktiska buggar (se issue #3384 och issue #4531 för dokumentation), och nyare Node-versioner har dessutom en annan väg för miljöproxy som kräver noggrann konfiguration. Den här guiden visar vad som faktiskt fungerar i Axios 1.19.0 i dag, alla sätt att koppla in en proxy i dina requests, ett rotationsmönster med interceptors som nästan ingen annan guide visar, och en komplett tabell från fel till lösning när det ändå går snett.

Vad är en Axios-proxy egentligen – och varför spelar det roll i Node.js?

En proxy är, i Axios-sammanhang, bara en mellanliggande server mellan din Node-process och målsajten. Din request går först till proxyn, proxyn skickar den vidare, och målet ser proxyserverns IP-adress i stället för din egen. Det är hela poängen.

Utvecklare använder detta av flera skäl: för att skrapa sajter som begränsar hastigheten eller blockerar per IP, testa hur en app beter sig från en annan plats, routa trafik via en företagsgateway, eller helt enkelt hålla sin egen servers IP borta från målserverns accessloggar. Axios officiella request-konfiguration har en inbyggd proxy-inställning med fälten host, port, protocol och auth — den har funnits i flera år och är det första varje guide, inklusive den här, brukar visa.

Det som ofta hoppas över är att proxy-inställningen beter sig olika beroende på om du träffar ett HTTP- eller HTTPS-mål, och beroende på vilken Axios-version du kör. Den skillnaden är hela anledningen till att den här guiden finns.

Kom igång med Node.js och Axios (snabb grundnivå)

Hoppa över detta om du redan har ett projekt igång. Om inte, tar det ungefär två minuter.

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

Lägg till "type": "module" i din package.json om du vill använda ESM-importer (det gör jag — CommonJS require() för en proxy-demo känns rätt daterat). Aktuell Node LTS är v24.18.0, även om jag körde mina tester på v22.22.3 just för att resultaten inte skulle påverkas av de allra senaste runtime-detaljerna.

Lägg detta i app.js och kör node app.js:

import axios from 'axios';

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

Du bör se din riktiga IP-adress i svaret. Det är din utgångspunkt — när proxyn fungerar ska samma request i stället visa proxyserverns IP.

Spara detta svar innan du aktiverar proxyn; det ger dig en tydlig referens att jämföra med den proxade requesten i nästa steg.

Stöder Axios verkligen HTTPS-proxyer? (Räta ut frågetecknen)

Kort svar: ja, i den nuvarande stabila versionen. Axios 1.19.0 dokumenterar CONNECT-tunnling för HTTPS-mål bakom en HTTP-proxy. npm:s nedladdnings-API registrerade 117 890 039 Axios-nedladdningar mellan 31 juli och 6 augusti 2026, en daterad men ändå tydlig indikator på hur spridd biblioteket är. När du träffar en HTTPS-URL via en proxy skickar nuvarande Axios en CONNECT-request för att etablera en tunnel, och din TLS-handshake sker ända fram till den riktiga origin-servern. Jag testade detta direkt: lokal HTTP-proxy, lokal HTTPS-origin med självsignerat certifikat, och CONNECT-räknaren i proxyn ökade precis som förväntat.

Så varför dyker då ”Axios HTTPS proxy är trasig” upp i nästan varje forumtråd om detta? Några skäl, och alla är verkliga:

Gamla Axios-versioner. GitHub-ärendena folk länkar till är ofta flera år gamla och beskriver versions- och konfigurationsspecifikt beteende som inte ska generaliseras till dagens Axios.
Proxyservrar utan stöd för CONNECT. I den konfigurationen misslyckas tunneln, och Axios borde då visa ett fel; fånga den faktiska rutten och felkoden innan du drar slutsatsen att proxyn kringgås.
Förväxling av proxy med något den inte är. proxy-inställningen är en instruktion för en forward proxy, inte en generell ”skicka allt genom den här agenten oavsett vad”-växel.

Chromium rapporterade 2023 att mer än 90 % av Chrome-navigationer över stora plattformar använde HTTPS. Det är en daterad Chrome-mätning, inte en fullständig överblick av hela webben, men den förklarar varför beteendet för HTTPS-mål hör hemma i centrum av den här guiden. Om du kör en gammal Axios-version: återskapa problemet på den aktuella versionen innan du antar att ett historiskt fel fortfarande beskriver dagens beteende; testa uppgraderingen i din egen applikation innan du släpper den i produktion.

När du ändå vill ha en uttrycklig agent

Inbyggd proxy-konfiguration räcker fint för en enkel, statisk och konventionell proxy. Men den faller sönder så fort du behöver kontroll per request, proxyrotation eller SOCKS-stöd — Axios inbyggda alternativ är helt enkelt inte byggt för det. Där kommer HttpsProxyAgent in, och det går jag igenom längre ned. Se den inbyggda lösningen som ”tillräckligt bra för en proxy, ett syfte” och agent-baserad lösning som ”det du faktiskt vill ha i produktion.”

Node v24 och v22.21+ med miljöproxy

Nya Node-versioner har ett inbyggt läge för miljöproxy, aktiverat via NODE_USE_ENV_PROXY=1 eller flaggan --use-env-proxy. Enligt Nodes egna CLI-dokument kom detta i v24.0.0 och backportades till v22.21.0 — så ”Node 22+” är tekniskt sett fel; det gäller specifikt v22.21.0 och senare inom den linjen. Kör du en tidigare patch av Node 22 finns inte flaggan alls.

Nuvarande Axios läser redan HTTP_PROXY, HTTPS_PROXY och NO_PROXY via beroendet proxy-from-env, så global-agent behövs inte för denna aktuella Axios-väg. När Nodes egen env-proxy också är aktiv kan två lager samtidigt påverka routningsbeslutet.

Axios dokumentation noterar att på Node-versioner där agenten har egenskapen proxyEnv låter Axios Node hantera proxyuppslaget i stället för att göra det själv. I praktiken betyder det att du bör välja ett system och hålla dig till det:

Låt Node hantera det: sätt flaggan, låt bli Axios proxy-inställning, och låt miljövariablerna göra jobbet.
Låt Axios hantera det: sätt inte Node-flaggan, och låt Axios egen miljövariabelhantering slå in.
Ta full manuell kontroll: sätt uttryckligen proxy: false och ange din egen httpsAgent — då kringgår du båda automatiska systemen helt, vilket jag rekommenderar så snart du behöver rotation eller logik per request.

Jag testade Axios-sidan direkt: när jag satte HTTP_PROXY i en child process-miljö gick requesten genom min lokala proxy, och när jag lade till en motsvarande NO_PROXY-post hoppade nästa request korrekt över den. Så miljövariabelvägen fungerar verkligen direkt nu — det är dubbel-läget du behöver hålla koll på.

5 sätt att koppla en proxy till Axios (jämförelse)

Innan vi går in i kod: så här ser landskapet ut. Jag byggde och testade varje metod mot en riktig lokal proxy-miljö, inte bara genom att läsa dokumentation.

Metod	Stöd för HTTPS	Stöd för autentisering	Kontroll per request	Lämplig för rotation	Komplexitet
Inline-`proxy`-inställning	✅ (nuvarande Axios)	✅	✅	❌	Låg
Standardvärden i `axios.create()`	✅ (nuvarande Axios)	✅	❌ (gäller hela instansen)	❌	Låg
Miljövariabler (`HTTP_PROXY`/`HTTPS_PROXY`)	✅	✅	❌	❌	Låg
`httpsAgent` + `HttpsProxyAgent`	✅	✅	✅	⚠️ (manuellt)	Medel
Request interceptor + agentpool	✅	✅	✅	✅	Medel–hög

Använd inline-alternativet för ett snabbt skript som går via en enda proxy. Använd axios.create() när alla requests i en modul ska gå genom samma proxy utan att du upprepar konfigurationen. Använd miljövariabler när din infrastruktur redan styr proxy-routing centralt och du bara vill ärva den. Välj en uttrycklig agent när du behöver kontroll som den inbyggda konfigurationen inte kan ge dig — och välj interceptor-mönstret så fort ”kontroll” utvecklas till ”rotation.”

Tre Axios-metoder för proxy-routing som möts vid en HTTPS-destination

Steg för steg: grundläggande proxykonfiguration i Axios

Den enklaste lösningen använder det inbyggda proxy-objektet direkt i requesten:

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

Kör detta så bör du se proxyserverns IP i svaret i stället för din egen. Testar du lokalt med en riktig proxy går detta ofta på långt under en sekund — jämfört med att manuellt ändra en proxyinställning på systemnivå bara för att testa en request, vilket är den sortens sak som slukar femton minuter du inte har.

Jämför detta svar med referensen. Ett lyckat test ska visa proxyserverns publika IP i stället för origin-IP:n du noterade tidigare.

Använd `axios.create()` för inställningar som gäller hela instansen

Om alla requests i en viss modul ska gå via samma proxy, lägg in det i en instans i stället för att upprepa konfigurationen:

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

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

Jag verifierade att ett proxy: false-överstyrning på en enskild request kringgår instansens standardvärde utan problem — användbart om 95 % av dina anrop behöver proxyn men några få, till exempel en hälsokontroll, inte ska göra det.

Sätt proxy via miljövariabler

För centralt styrd routing — tänk Docker-containrar eller CI-miljöer där drift redan satt proxyvariabler — behöver du inte röra Axios-konfigurationen alls:

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

Nuvarande Axios läser dessa variabler utan global-agent. Kom bara ihåg versionsgränsen ovan: om NODE_USE_ENV_PROXY också är aktivt behöver du vara tydlig med vem som äger routningen och testa NO_PROXY-beteendet i den körmiljö där applikationen faktiskt körs.

Steg för steg: HTTPS-proxy med `httpsAgent` för riktig kontroll

Det här är den lösning jag faktiskt skulle rekommendera när du behöver mer än ”en proxy, alltid”. Installera det aktuella agent-paketet:

npm install https-proxy-agent

https-proxy-agent 9.1.0 kräver Node 20 eller nyare och skickar en korrekt CONNECT till din proxy innan den tunnelar target-anslutningen genom den.

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,        // hindra Axios inbyggda logik från att också blanda sig i
  httpsAgent: agent,
  timeout: 15_000,
});

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

Sätt proxy: false när en uttrycklig agent äger routningen. Det gör konfigurationen otvetydig och hindrar Axios inbyggda eller miljöbaserade proxylogik från att konkurrera med den angivna agenten.

Lägg till proxyautentisering

Lägg in autentiseringsuppgifterna direkt i proxy-URL:en:

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

Om lösenordet innehåller specialtecken — @, : och # är de vanligaste bovarna — percent-koda dem innan du bygger URL:en, eller bygg strängen med encodeURIComponent() för varje del. Ett rått @ i lösenordet tolkas som början på host-delen, och du får ett anslutningsfel som inte alls ser ut att handla om kodning.

Använd SOCKS5-proxyer med Axios

SOCKS-proxyer är inte kompatibla med HttpsProxyAgent — du behöver en annan agent för det protokollet:

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 kräver också Node 20+. SOCKS5 är värt att använda när du arbetar i företagsnätverk som bara exponerar en SOCKS-gateway, eller med proxy-leverantörer som erbjuder mer flexibel protokollsupport än vanliga HTTP-proxyer.

Rotera proxyer med Axios request interceptors

Att välja en slumpmässig proxy direkt i din anropskod fungerar för ett engångsskript. Det faller isär så fort du gör hundratals requests, eftersom det inte finns någon central plats som håller koll på vilka proxyer som är döda, ingen retry-logik, och proxyvalskoden slutar kopieras överallt. Axios interceptorsystem ger den logiken ett testbart hem; ingen av de fem konkurrentguiderna i den här artikelns SERP-granskning använde det här mönstret.

Axios GET-requests som roterar över tre proxyer med ett begränsat retry-försök

Bygg en proxy-pool

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

Jag körde detta mot två lokala proxyer och bekräftade att requesterna alternerade korrekt — proxy A, sedan proxy B, sedan tillbaka till A. Notera att Axios kör request-interceptors i omvänd ordning för hur de lades till, så om du har andra interceptors (autentisering, loggning) spelar ordningen mer roll än man först tror.

Lägg till en response interceptor med retry-skydd

Här blir det ofta slarvigt i hemmagjorda rotationsskript. Att blint försöka igen på varje fel, mot en obegränsad pool, kan förvandla en trasig request till en kedjereaktion — särskilt för icke-idempotenta metoder som POST, där ett nytt försök kan duplicera en sidoeffekt du verkligen inte ville duplicera.

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

Jag testade detta mot en medvetet trasig proxy och bekräftade att exakt ett retry-försök skedde på den alternativa agenten — ingen oändlig loop, inget retry på en POST-request. Det är den gräns du vill ha: en retry-policy som är ärlig med vilka requests som är säkra att spela upp igen, inte ett ”försök bara igen tills det funkar”-hack.

Felsökning av Axios-proxy med cURL, 407-autentisering och timeout-kontroller

Felsökningstabell: koppla varje fel till rätt lösning

Spara den här. Det här är de fel som faktiskt dyker upp i Axios GitHub-ärenden och Stack Overflow-trådar, inte hypotetiska exempel.

Fel / symptom	Trolig orsak	Lösning
`ECONNREFUSED`	Fel host/port, eller så är proxyservern nere	Verifiera med `curl -x http://host:port target-url` innan du ändrar Axios-kod
`407 Proxy Authentication Required`	Saknade eller felaktiga uppgifter	Lägg till `auth: { username, password }` i `proxy`-konfigurationen, eller bygg in uppgifterna i URL:en för `HttpsProxyAgent`
`403 Forbidden`	Origin-servern eller WAF:en avvisade requesten eller proxy-IP:n	Kontrollera sajtens åtkomstpolicy, autentisering och requestfrekvens; tolka inte en annan header eller IP som tillåtelse att kringgå begränsningar
Svaret visar din riktiga IP	`NO_PROXY`, `proxy:false`, en uttrycklig direkt-agent eller en historisk/version-specifik konfiguration kan ha kringgått proxyn	Se vilken nivå som äger routningen; verifiera vägen med en kontrollerad IP-endpoint och uttrycklig agent vid behov
`ETIMEDOUT`	Anslutnings- eller svarstiden överskred den konfigurerade timeouten	Mät var tiden går åt; justera timeouten bara om lasten motiverar det, annars byt eller kyla ned den instabila vägen
`ECONNRESET` mitt i svaret	Proxyn, nätverket eller origin stängde anslutningen	Logga vilken hop som faller; retrya bara replay-säkra requests med en begränsad budget
`502 Bad Gateway` bakom Nginx	Nginx `proxy_pass` är felkonfigurerad, eller så matchar Axios timeout inte Nginx	Kontrollera `proxy_connect_timeout` och `proxy_read_timeout` (båda har standardvärdet 60 s) och anpassa dem till din Axios `timeout`
`ERR_TLS_CERT_ALTNAME_INVALID`	Fel agenttyp för målet, eller ett självsignerat certifikat	Bekräfta att du använder rätt agent för protokollet; sätt `rejectUnauthorized: false` endast för lokala tester — aldrig i produktion

Snabb checklista för felsökning

När något slutar fungera och du inte vet varför, gå igenom detta i ordning:

Testa proxyn direkt med curl -x http://host:port https://your-target.com. Om det misslyckas, undersök proxyanslutning, autentisering och målet innan du ändrar i Axios. Om det fungerar behöver Axios-vägen fortfarande verifieras separat.
Bekräfta vilka versioner av Axios och Node du faktiskt kör, och jämför historiska rapporter med samma release/konfiguration innan du använder deras fixar.
Ta reda på vilket system som löser proxyn — inbyggd Axios-konfiguration, Axios miljövariabelhantering, Nodes inbyggda env-proxy-läge eller en uttrycklig agent. Låt aldrig mer än en äga samma request.
Kontrollera NO_PROXY för oavsiktliga matchningar på hostnamn.
Om du använder en uttrycklig agent, kontrollera att proxy: false är satt så att Axios inte försöker hantera det dubbelt.

När du bör hoppa över egen proxyhantering helt

Allt ovan är verkligen användbart om ditt faktiska mål är att routa godtycklig trafik — tester i företagsnätverk, geo-testning av en app eller kontrollerad utgående nätverkstrafik. Men många hamnar på ”hur sätter jag upp en Axios-proxy” för att det de egentligen vill ha är data från en webbplats, och proxyn är bara ett medel för att nå dit.

Om det är din situation är det värt att fråga sig om du verkligen behöver en proxy alls, eller om du i stället behöver ett scraping-API som sköter infrastrukturen åt dig. Thunderbits Open API tar en URL och ett schema och returnerar strukturerad JSON — ingen rå HTML-parsning, inga agentbibliotek, ingen proxy-pool att underhålla. /extract-endpointen hanterar sidor som renderas med JavaScript, anti-bot-skydd och CAPTCHA:er på serversidan, och det finns en lättare /distill-endpoint som bara gör om en sida till ren Markdown om det är allt du behöver. Det finns också en MCP-server med verktyg som thunderbit_extract och thunderbit_suggest_fields, så kodassistenter som Claude eller Cursor kan hämta strukturerad data mitt i ett arbetsflöde utan att röra proxyinställningar alls, plus en CLI för terminal- och CI-flöden.

Fråga	Egen Axios + proxyer	Thunderbit API/MCP/CLI
Källa till proxy och rotation	Du ansvarar själv	Hanteras på serversidan
Utmaningar med webbläsare och åtkomst	Du sköter webbläsare/nätverkslager	Hanteras av tjänsten inom dess dokumenterade möjligheter
Sidor renderade med JS	Kräver headless browser	`renderMode: full`
Utdataformat	Rå HTML → du parsar	Strukturerad JSON via schema
Underhåll när sajter ändras	Du underhåller parsing/selectors	Det hanterade extraktionslagret minskar en del av underhållet på applikationssidan

Det är den ärliga bilden: om du behöver routa trafik för testning eller företagsnätverk ersätter inget av detta Axios och en proxykonfiguration. Om din leverans däremot är strukturerad webbdata kan ett API-first-upplägg minska mängden proxy-, browser- och parsingkod som din applikation själv måste äga. Vid hämtning den 7 augusti 2026 angav Thunderbits dokumentation om API-rate limits att gratisnivån låg på 10 requests per minut och 2 samtidiga requests. Betrakta detta som tidskänsliga API-gränser och kontrollera sidan igen innan du förlitar dig på dem i produktion.

Avslutning

Den viktigaste lärdomen här går emot vad många äldre guider säger: nuvarande Axios dokumenterar och, i det lokala testet som kördes, använde korrekt CONNECT-tunnling för ett HTTPS-mål. Historiska fel finns kvar, men de måste sättas i versions- och kontextsammanhang. Inbyggd konfiguration är en bra start med låg komplexitet; när du behöver kontroll per request, SOCKS-stöd eller rotation, ger en uttrycklig HttpsProxyAgent (eller SocksProxyAgent) tillsammans med proxy: false ett mycket tydligare ägarskap. Och om du roterar över en pool i produktion ger request- och response-interceptors en central, testbar plats att göra det på — se bara till att din retry-logik har en loopvakt och bara spelar upp requests som faktiskt är säkra att spela upp igen.

Bokmärk felsökningstabellen ovan till nästa gång en proxykonfiguration kastar ett kryptiskt fel klockan 02:00. Och om du märker att du lägger mer tid på att felsöka proxyplumbing än på att faktiskt använda datan du försöker få tag på, kan det vara värt att se om ett API-first-extraktionsverktyg löser det riktiga problemet snabbare än infrastrukturen någonsin kommer att göra.

Vanliga frågor

Stöder Axios HTTPS-proxyer inbyggt? Ja, i nuvarande Axios för en vanlig HTTP-proxy: den aktuella dokumentationen beskriver CONNECT-tunnling för HTTPS-mål, och Axios 1.19.0 klarade den vägen i det lokala test som dokumenterats här. Historiska versioner och vissa proxykonfigurationer gav verkliga fel, så verifiera exakt version och proxy i stället för att anta att allt alltid fungerar eller alltid misslyckas.

Hur roterar jag proxyer i Axios? Använd en request interceptor för att tilldela en annan httpsAgent från en proxy-pool innan varje request skickas, och kombinera det med en response interceptor som försöker igen med en annan proxy om requesten misslyckas. Håll retry-logiken begränsad — ett försök till, och bara för idempotenta metoder som GET — så att du inte råkar spela upp en request som inte borde spelas upp igen.

Varför visar min Axios-proxy min riktiga IP? Kontrollera om NO_PROXY, proxy:false, en uttrycklig direkt-agent eller deploymentspecifik routing har kringgått proxyn. Spara Axios/Node-versionerna och testa proxyn separat med cURL. Behöver du entydig routing per request, använd HttpsProxyAgent med proxy:false och verifiera den observerade IP:n på en kontrollerad endpoint.

Kan jag använda SOCKS5-proxyer med Axios? Ja, via paketet socks-proxy-agent. Skapa en SocksProxyAgent med din SOCKS-URL och skicka den som httpsAgent i din Axios-konfiguration — se bara till att du inte också skickar HttpsProxyAgent, eftersom de två protokollen använder olika agenttyper.

Vad är skillnaden mellan proxy-inställningen och httpsAgent i Axios? proxy är Axios inbyggda konfiguration för en enda, statisk proxy och fungerar bra för enkla use case i nuvarande versioner. httpsAgent tar en egen Node.js-agent — som HttpsProxyAgent eller SocksProxyAgent — och ger dig direkt kontroll per request över routing, autentisering och rotation som den inbyggda inställningen aldrig var designad för att hantera.

Läs mer

Från webbsida till kalkylark

Beskriv vad du behöver — Thunderbits AI-agent samlar in det och exporterar till Excel, Google Sheets, Airtable eller Notion. Gratis att börja med.

Chrome Store Rating

PRODUCT HUNT#1 Product of the Week