Så använder du Wget med en proxy (och undviker vanliga fallgropar)

Att ställa in Wget med en proxy ser ut som ett femsekundersjobb — tills du har suttit en timme och försökt lista ut varför dina förfrågningar går förbi proxyn helt, utan ett enda felmeddelande. Jag har sett det här hända både rutinerade systemadministratörer och juniora utvecklare.

Den verkliga orsaken är nästan aldrig proxyn i sig. Det handlar om de fyra olika ställen där Wget kan läsa proxyinställningar, de tysta misslyckandena när du använder fel versal/minuskel i variabelnamn, och de egenheter i företagsnätverk som ingen man-sida orkar förklara. Den här guiden går igenom alla sätt att konfigurera Wget med en proxy, exakt vilken prioriteringsordning som gäller när flera metoder krockar, verklig terminalutskrift för vanliga fel, samt ett särskilt avsnitt för Windows- och företagsbrandväggsanvändare — alltså den målgrupp som nästan alla andra guider låtsas inte finns.

Svårighetsgrad: Nybörjare till medelnivå
Tidsåtgång: ~15 minuter att läsa och konfigurera; ~2 minuter när du väl vet vad du gör
Det här behöver du: En fungerande Wget-installation (instruktioner nedan), en proxyadress (värd + port) och eventuellt proxyinloggning

Testa Thunderbit för strukturerad dataextrahering

Vad är Wget och varför använda det med en proxy?

Wget är ett kommandoradsverktyg som laddar ner filer och webbsidor från internet utan webbläsare. GNU:s egen beskrivning kallar det en "non-interactive network downloader" — alltså något som körs i bakgrunden, återupptar avbrutna överföringar och klarar rekursiva nedladdningar utan att en människa behöver klicka på något.

En proxy är i det här sammanhanget en mellanhandserver. I stället för att din maskin ansluter direkt till en webbplats skickar Wget begäran till proxyn, som sedan vidarebefordrar den. De vanligaste skälen till att vilja göra så här är:

Följa företagsbrandväggens regler — ditt företag kräver att all utgående trafik går via en godkänd proxy
Integritet och IP-hantering — förfrågningar ser ut att komma från proxyns IP, inte din egen
Geotestning — hämta regionlåst innehåll eller testa CDN-beteende från en viss plats
Pipelines för datainsamling — ladda ner HTML via roterande proxies för research eller övervakning
CI/CD-miljöer — byggservrar i låsta nätverk som bara når internet via proxy

Wget har inbyggt stöd för HTTP-, HTTPS- och FTP-proxies. Det stöder inte SOCKS5. Om du behöver SOCKS5 har curl inbyggt stöd för socks4://, socks5:// och socks5h:// — eller så kan du köra Wget genom ett verktyg som proxychains4.

Så installerar du Wget på Linux, macOS och Windows

Innan du ställer in proxy behöver du Wget på datorn. Det här avsnittet är snabbt — det är en förutsättning, inte huvudnumret.

Linux (Debian/Ubuntu och RHEL/CentOS)

# Debian/Ubuntu
sudo apt update
sudo apt install wget

# RHEL/CentOS/Fedora
sudo dnf install wget

# Verifiera
wget --version

Ubuntu 24.04 LTS levereras med Wget 1.21.4, medan Debian Trixie har 1.25.0. CentOS Stream 10-paketen visar 1.24.5.

macOS (Homebrew)

brew install wget
wget --version

Homebrews formula levererar just nu stabila Wget 1.25.0, med 396 818 installationer det senaste året.

Windows (Chocolatey och manuell installation)

choco install wget
wget --version

Chocolateys GNU Wget-paket rapporterar över 10 miljoner nedladdningar totalt, även om versionen just nu är 1.21.4. Binärfilen hamnar vanligtvis under C:\ProgramData\chocolatey\bin\wget.exe.

En sak att känna till för Windows-användare: var Wget letar efter .wgetrc varierar beroende på byggversion. Mer om det i Windows-avsnittet längre ned.

4 sätt att använda Wget med en proxy (och vilket du bör välja)

Fyra metoder, var och en med eget scope och egen prioritet:

Kommandoradsflaggor med -e — engångsanvändning, ett kommando
Användarkonfigurationsfil (~/.wgetrc) — gäller alla Wget-kommandon du kör
Systemkonfigurationsfil (/etc/wgetrc) — gäller alla användare på datorn
Miljövariabler (http_proxy, https_proxy) — gäller hela skalets session

Metod 1: Kommandoradsflaggor (tillfällig proxy)

Bäst för snabba tester. Inställningarna försvinner när kommandot är klart.

wget -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://example.com/file.zip

För HTTPS-mål:

wget -e use_proxy=on -e https_proxy=http://HOST:PORT/ https://example.com/

Snabbt test — hämta din upplevda IP-adress via proxyn:

wget -qO- -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://ifconfig.me

Om resultatet visar proxyns IP i stället för ditt eget är allt som det ska.

Metod 2: Användarkonfigurationsfil (~/.wgetrc)

Lägg till dessa rader i ~/.wgetrc (skapa filen om den inte finns):

use_proxy = on
http_proxy = http://proxy.company.com:8080/
https_proxy = http://proxy.company.com:8080/
no_proxy = localhost,127.0.0.1,.internal.company.com

Observera mellanslagen runt = — det är den dokumenterade syntaxen för .wgetrc. Alla Wget-kommandon du kör som denna användare går nu via proxyn.

Metod 3: Systemomfattande konfiguration (/etc/wgetrc)

Samma direktiv som i ~/.wgetrc, men placerade i systemets konfigurationsfil. GNU beskriver detta som en global startfil — exakt sökväg beror på installationsprefix. Vanliga platser:

/etc/wgetrc (de flesta Linux-pakethanterare)
/usr/local/etc/wgetrc (vissa Homebrew-byggningar)
Sökvägen som visas i wget --version under "Wgetrc:"

Det här är praktiskt för delade servrar, Docker-containrar eller andra miljöer där alla användare ska gå via samma proxy.

Metod 4: Miljövariabler (http_proxy / https_proxy)

export http_proxy=http://HOST:PORT/
export https_proxy=http://HOST:PORT/
export no_proxy=localhost,127.0.0.1,.internal.company.com

Det här påverkar hela skalets session — inte bara Wget. Verktyg som curl tar också upp dem.

Viktig varning: Wget läser bara små bokstäver i miljövariablerna. HTTP_PROXY (versaler) ignoreras helt tyst. Ingen feltext, ingen varning, ingenting. Jag visar exakt terminalutskrift i avsnittet om fallgropar, men det här är värt att memorera direkt.

Prioritet mellan proxy-metoder: vad överskuggar vad när flera är satta

Om du har en proxy i miljövariablerna och i .wgetrc och på kommandoraden, vilken vinner? Ingen förklarar det här tydligt, så jag testade det.

Här är den testade och dokumenterade prioriteringsordningen:

Prioritet	Metod	Omfattning	Överskuggar
1 (högst)	`-e` CLI-flaggor	Ett enskilt kommando	Allt
2	`~/.wgetrc`	Nuvarande användare	Systemkonfig + miljövariabler
3	`/etc/wgetrc`	Systemomfattande	Bara miljövariabler
4 (lägst)	`http_proxy` / `https_proxy` i miljön	Skalets session	Ingenting

Jag verifierade detta i Wget 1.25.0 genom att sätta motstridiga proxies på varje nivå. Med miljön pekande mot port 3128, konfigurationsfilen mot 3129 och CLI mot 3130:

Konfig slår miljö: Wget anslöt till port 3129 och ignorerade 3128.
CLI slår konfig: Wget anslöt till port 3130 och ignorerade både 3129 och 3128.

Nödutvägen är --no-proxy. Det kringgår alla proxyinställningar oavsett var de är konfigurerade:

wget --no-proxy https://internal-server.company.com/report.pdf

Praktiskt scenario: din systemadministratör har satt en proxy i /etc/wgetrc, men du behöver nå en intern server direkt. Använd --no-proxy för just det kommandot i stället för att ändra systemkonfigurationen.

Så använder du Wget med en autentiserad proxy

De flesta kommersiella och privata proxies kräver användarnamn och lösenord. Wget stödjer detta via två metoder, båda med HTTP Basic-autentisering för proxyuppgifterna.

Inbyggda inloggningsuppgifter i proxy-URL:en

wget -e use_proxy=on \
  -e http_proxy=http://USERNAME:PASSWORD@proxy.company.com:8080/ \
  http://example.com/file.zip

Det här fungerar även i .wgetrc:

http_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
https_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/

Använd flaggorna --proxy-user och --proxy-password

wget --proxy-user=USERNAME --proxy-password=PASSWORD \
  -e use_proxy=on \
  -e http_proxy=http://proxy.company.com:8080/ \
  http://example.com/file.zip

De här flaggorna går före alla inbäddade user:pass@ i proxy-URL:en.

Hålla inloggningsuppgifterna säkra

Båda metoderna läcker känsliga uppgifter. GNU varnar för att lösenord på kommandoraden kan ses via ps eller processlistverktyg. Motåtgärder:

Enanvändarmaskiner: Lagra uppgifterna i ~/.wgetrc och lås filen: chmod 600 ~/.wgetrc
CI/CD-pipelines: Använd GitHub Actions krypterade secrets eller motsvarande i din plattform. Skicka dem som miljövariabler med små bokstäver i steget — hårdkoda dem aldrig i YAML.
Docker-bygg: Använd inte ARG eller ENV för hemligheter. Dockers dokumentation varnar uttryckligen för att byggargument kan följa med in i slutbilden. Använd i stället BuildKit secret mounts.
Versionshantering: Checka aldrig in .wgetrc med inloggningsuppgifter. Lägg till den i .gitignore.

En Wget-specifik detalj för GitHub Actions: secret-namn lagras ofta med versaler av konvention, men de miljövariabler du exponerar för Wget måste vara i små bokstäver (http_proxy, inte HTTP_PROXY).

Så använder du Wget med en proxy på Windows och bakom företagsbrandväggar

De flesta artiklar om detta slutar vid "installera med Chocolatey". Om du kör Windows eller sitter bakom en företagsproxy är det där problemen börjar.

Var Windows letar efter .wgetrc

GNU-dokumentationen säger att Wget läser $HOME/.wgetrc om inte miljövariabeln WGETRC pekar någon annanstans. På Windows kan $HOME mappas till %USERPROFILE% (till exempel C:\Users\alice), eller inte — beroende på om du använder Chocolatey-byggnaden, en MSYS2-byggnad, Git Bash eller en fristående binär.

Mitt råd: hoppa över gissandet och använd flaggan --config för deterministiskt beteende:

wget --config=C:\Users\alice\wgetrc https://example.com/file.zip

För att testa om din byggnad läser en konfigurationsfil från en viss plats, skapa en testfil som pekar mot en känd felaktig proxy:

; C:\Users\alice\wget-test.rc
use_proxy = on
http_proxy = http://127.0.0.1:3128/

Kör sedan:

wget --config=C:\Users\alice\wget-test.rc --spider http://example.com/

Om Wget försöker ansluta till 127.0.0.1:3128 så har den läst filen.

Ställa in proxy-miljövariabler på Windows

CMD (endast för sessionen):

set http_proxy=http://HOST:PORT/
set https_proxy=http://HOST:PORT/
wget http://example.com/

PowerShell (endast för sessionen):

$env:http_proxy = "http://HOST:PORT/"
$env:https_proxy = "http://HOST:PORT/"
wget http://example.com/

Permanent (överlever omstarter):

setx http_proxy http://HOST:PORT/
setx https_proxy http://HOST:PORT/

Efter setx behöver du öppna ett nytt terminalfönster. Den nuvarande sessionen ser inte ändringen.

Företagsproxy-fällor: PAC-filer, NTLM-autentisering och hur du hittar proxyadressen

Tre saker som konsekvent ställer till det för företagsanvändare:

PAC-filer: Många organisationer använder Proxy Auto-Configuration (PAC)-filer — JavaScript-baserade skript som berättar för webbläsaren vilken proxy som ska användas för vilken URL. Wget har ingen JavaScript-tolk, så det kan inte läsa PAC-filer. Curl-dokumentationen säger samma sak. Lösningen: öppna PAC-filen (eller fråga IT), hitta resultatet PROXY host:port för din mål-domän och konfigurera den statiska adressen i Wget.

NTLM-autentisering: Wget har bara Basic auth för proxyautentisering. Om din företagsproxy kräver NTLM och du får 407 Proxy Authentication Required, ska du inte lägga tid på att prova olika --proxy-user-varianter. Installera Cntlm — en lokal relay som hanterar NTLM/NTLMv2-autentisering och presenterar ett Basic-auth-gränssnitt för Wget. Cntlm underhålls fortfarande (senaste uppdatering oktober 2025, cirka 395 nedladdningar/vecka).

Beslutsflöde för användare bakom företagsproxy:

Testa set http_proxy=http://YOUR_PROXY:PORT/ och kör Wget.
Om du får felkoden 407 och företaget använder NTLM → installera Cntlm, konfigurera det med dina domänuppgifter och peka Wget mot Cntlms lokala port (vanligtvis http://127.0.0.1:3128/).
Om företaget använder en PAC-fil → extrahera den faktiska PROXY host:port-adressen från PAC-filen eller be IT om den statiska proxyadressen.

Vanliga företagsproxy-portar: 3128 (Squid-liknande), 8080 (allmän HTTP-proxy), 8888 (felsökningsproxys som Fiddler/Charles). Det här är konventioner, inte garantier.

Vanliga fallgropar när du använder Wget med en proxy (med verklig felutskrift)

Nu till utdelningen som lovades i rubriken. All utskrift nedan återskapades i Wget 1.25.0 (macOS, Homebrew) den 2026-06-01.

Fallgrop 1: saknar prefixet http://

Vissa äldre guider påstår att detta alltid bryter. I Wget 1.25.0 fungerar faktiskt http_proxy=127.0.0.1:3128 — Wget lägger tyst till http://:

Prepended http:// to '127.0.0.1:3128'
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:38:15--  http://example.com/
Connecting to 127.0.0.1:3128... failed: Operation not permitted.

Den anslöt alltså fortfarande till rätt proxy. Men jag rekommenderar ändå att alltid skriva med http:// och ett avslutande snedstreck. Det minskar oklarheter mellan olika Wget-versioner och gör syntaxen för autentisering (http://user:pass@host:port/) tydlig.

Fallgrop 2: use_proxy=yes vs. use_proxy=on

Både yes och on fungerade i mina tester med Wget 1.25.0. Men ogiltiga värden ger ett tydligt fel:

wget: use_proxy: Invalid boolean 'true'; use `on' or `off'.

Använd on för bredast kompatibilitet — det matchar manualens dokumenterade booleska format och Wgets egen felhint.

Fallgrop 3: HTTP_PROXY med versaler ignoreras helt tyst

Det här är den mest frustrerande fallgropen eftersom det inte kommer något fel alls. Wget ansluter bara direkt, som om du aldrig hade satt någon proxy.

Versaler (fel — ingen proxy används):

HTTP_PROXY=http://127.0.0.1:3128/ wget --no-config --spider http://example.com/

Spider mode enabled. Check if remote file exists.
--2026-06-01 10:40:06--  http://example.com/
Resolving example.com (example.com)... 198.18.58.61
Connecting to example.com (example.com)|198.18.58.61|:80... connected.
HTTP request sent, awaiting response... 200 OK

Små bokstäver (fungerar — försöker via proxy):

http_proxy=http://127.0.0.1:3128/ wget --no-config --spider http://example.com/

Spider mode enabled. Check if remote file exists.
--2026-06-01 10:40:16--  http://example.com/
Connecting to 127.0.0.1:3128... failed: Connection refused.

Ser du skillnaden? Versionen med versaler slog upp example.com direkt. Versionen med små bokstäver försökte använda proxyn. Ingen varning i något av fallen. Curl har en liknande egenhet — den accepterar versaler för de flesta proxyvariabler men avvisar uttryckligen versaler för HTTP_PROXY av säkerhetsskäl.

Lösning: Använd alltid små bokstäver för http_proxy och https_proxy.

Fallgrop 4: gammal proxy i .wgetrc ger "Connection refused"

Om du (eller din sysadmin, eller en Docker-bild) har lämnat en gammal proxyadress i en konfigurationsfil ser du något i stil med detta:

Spider mode enabled. Check if remote file exists.
--2026-06-01 10:39:10--  http://example.com/
Connecting to 127.0.0.1:3128... failed: Connection refused.

Felet pekar på den gamla proxy-IP:n, inte på målsidan. Felsökningsordning (följ prioriteringshierarkin):

Kontrollera kommandot för -e-flaggor eller skalalias
Kontrollera ~/.wgetrc (eller filen som anges av WGETRC)
Kontrollera systemkonfigurationen (sökvägen som visas av wget --version)
Kontrollera miljön: env | grep -i proxy

För felsökning är --no-config din vän — det säger åt Wget att hoppa över alla konfigurationsfiler:

wget --no-config --spider http://example.com/

Om det fungerar ligger problemet i en konfigurationsfil.

Fallgrop 5: förvirring kring syntax för HTTPS-proxy

Det här snubblar många på. När du sätter https_proxy är proxy-URL:en vanligtvis http://, inte https://. Det beror på att Wget skickar en HTTP CONNECT-begäran genom proxyn för att skapa en tunnel för den krypterade HTTPS-sessionen.

Rätt:

https_proxy=http://proxy.company.com:8080/
wget https://example.com/

Wget skickar CONNECT example.com:443 HTTP/1.1 till proxyn och tunnlar sedan HTTPS genom den.

Fel (för HTTP-mål-URL:er med en HTTPS-proxyendpoint):

http_proxy=https://127.0.0.1:18082/
wget http://example.com/

Error in proxy URL https://127.0.0.1:18082/: Must be HTTP.

Wget 1.25.0 avvisar helt enkelt https:// som proxy-URL för HTTP-mål. Använd https_proxy=http://HOST:PORT/ om inte din organisation uttryckligen dokumenterat en HTTPS-proxyendpoint och du har testat den med din Wget-byggnad.

Wget proxy-kommandocheat sheet (bokmärkesvänlig snabbreferens)

Spara den här tabellen. Den samlar alla Wget-flaggor och konfigurationsdirektiv för proxy på ett ställe.

Flagga / Direktive	Sammanhang	Exempel	Kommentar
`-e use_proxy=on`	CLI	`-e use_proxy=on`	`on` är säkrast; vissa byggversioner accepterar också `yes`
`-e http_proxy=`	CLI	`-e http_proxy=http://proxy:8080/`	Inkludera `http://` och avslutande `/`
`-e https_proxy=`	CLI	`-e https_proxy=http://proxy:8080/`	Proxy-URL:en är oftast `http://` även för HTTPS-mål
`--proxy-user`	CLI	`--proxy-user=admin`	Överskuggar inbäddad `user:pass@`
`--proxy-password`	CLI	`--proxy-password=secret`	Syns i `ps` — undvik på delade system
`--no-proxy`	CLI	`--no-proxy`	Förbigår ALL proxykonfiguration från alla källor
`--no-config`	CLI	`--no-config`	Hoppar över alla konfigurationsfiler — bra för felsökning
`--config=FILE`	CLI	`--config=/tmp/wgetrc`	Deterministisk konfigurationssökväg — perfekt för Windows och CI
`http_proxy`	`.wgetrc` / miljö	`http_proxy = http://proxy:8080/`	Konfigurationsfil använder mellanslag runt `=`; miljövariabel använder små bokstäver
`https_proxy`	`.wgetrc` / miljö	`https_proxy = http://proxy:8080/`	Samma format som `http_proxy`
`ftp_proxy`	`.wgetrc` / miljö	`ftp_proxy = http://proxy:8080/`	För FTP-hämtningar
`no_proxy`	`.wgetrc` / miljö	`no_proxy = localhost,127.0.0.1,.corp`	Kommaseparerad domänlista
`proxy_user`	`.wgetrc`	`proxy_user = admin`	Motsvarar `--proxy-user`
`proxy_password`	`.wgetrc`	`proxy_password = secret`	Skydda filen med `chmod 600`

När Wget + proxy inte är rätt verktyg (och vad du ska använda i stället)

Efter all den här proxykonfigurationen kommer en lite motsatt poäng: ibland ska du faktiskt inte använda Wget.

Många som söker på "wget proxy" försöker inte ladda ner en enda fil. De vill samla strukturerad data från webbplatser — produktpriser, kontaktlistor, bostadsannonser — och har valt Wget bara för att det är kommandoradsverktyget de känner till. Problemet är att Wget ger dig rå HTML. Du måste fortfarande tolka, rensa och strukturera den. Och om du roterar proxies för att undvika blockeringar måste du nu hålla koll på en proxyliste, ett nedladdningsskript, en parser och en exportpipeline.

| Ditt mål | Bästa verktyg | Varför | |---|---|---|---| | Ladda ner en enskild fil via proxy | wget med proxyflaggor | Enkelt, ett kommando | | Spegla en webbplats eller katalog via proxy | wget --recursive + proxykonfiguration | Wgets rekursiva hämtning är en av dess styrkor | | Skrapa strukturerad data (tabeller, listor, kontakter) | Thunderbit | Wget ger dig rå HTML — du måste ändå tolka den. Thunderbits AI läser sidan och exporterar strukturerad data till Excel, Google Sheets, Airtable eller Notion utan kod. Dess molnbaserade scraping hanterar IP-rotation och anti-bot-skydd, så du slipper proxyinställningen helt. | | REST API-anrop via proxy | curl | Bättre kontroll över headers, inbyggt JSON-stöd, SOCKS5-stöd | | Löpande schemalagd datainsamling | Thunderbit Scheduled Scraper eller cron + wget | Thunderbit anpassar sig när sidornas layout ändras; cron + wget-skript går ofta sönder utan att märkas |

Wget är utmärkt för filnedladdning. Men arbetsflödet "konfigurera proxy → rotera IP:er → ladda ner HTML → skriva en parser → exportera till kalkylark" innehåller många rörliga delar när det du egentligen vill ha är en datatabell. Om det låter som din situation, vår Chrome-tillägg löser hela kedjan på två klick. För mer om det här tillvägagångssättet, se våra guider om AI-webbscraping och webbscraping utan kod.

Men om ditt mål är "ladda ner den här ZIP-filen via en företagsproxy" — då är Wget fortfarande rätt verktyg, och nu vet du hur du konfigurerar det korrekt.

Viktiga lärdomar

Kort version:

Fyra metoder, tydlig prioritet: CLI-flaggor går före användarkonfig, som går före systemkonfig, som går före miljövariabler. --no-proxy går före allt.
Använd alltid små bokstäver för miljövariabler (http_proxy, inte HTTP_PROXY). Versaler ignoreras helt tyst.
Inkludera alltid http:// i din proxy-URL, även för https_proxy. Proxyendpointen är HTTP; den tunnelar HTTPS via CONNECT.
Använd on för booleska värden i .wgetrc och med -e-flaggor. Det är det säkraste valet mellan olika Wget-versioner.
Windows-användare: Använd --config=C:\sökväg\till\wgetrc för att undvika oklarheter kring konfigurationsfiler. Använd set (CMD) eller $env: (PowerShell) för proxyvariabler i sessionen.
Användare bakom företagsproxy: Wget kan inte läsa PAC-filer och har inget inbyggt stöd för NTLM-autentisering. Använd Cntlm som lokal relay vid behov.
Bokmärk cheat sheeten ovan — den sparar dig från att behöva läsa om artikeln varje gång du ska minnas ett flaggnamn.

Om ditt egentliga mål är strukturerad dataextraktion kan Thunderbit eller curl vara bättre val. Den bästa felsökningen är den du aldrig behöver börja med.

Vanliga frågor

1. Stöder Wget SOCKS5-proxies?

Nej. GNU Wget 1.x stöder bara HTTP-, HTTPS- och FTP-proxies. Wget2-projektet har haft SOCKS5 som önskemål, men det är inte ett standardiserat dokumenterat alternativ. För SOCKS5, använd curl med dess inbyggda socks5://- eller socks5h://-scheman, eller kör Wget genom proxychains4 för att tvinga trafik via SOCKS.

2. Varför ignoreras min proxyinställning när jag använder versalerna HTTP_PROXY?

Wget läser bara miljövariabler med små bokstäver (http_proxy, https_proxy, ftp_proxy, no_proxy). Varianter med versaler som HTTP_PROXY ignoreras helt tyst — ingen feltext, ingen varning. Det här är ett av de vanligaste och mest irriterande problemen eftersom inget säger att något är fel. Använd alltid små bokstäver.

3. Hur kringgår jag proxyn för vissa domäner?

Använd direktivet no_proxy, antingen som miljövariabel eller i .wgetrc:

export no_proxy=localhost,127.0.0.1,.mycompany.com

Eller i ~/.wgetrc:

no_proxy = localhost,127.0.0.1,.mycompany.com

Domänerna separeras med kommatecken. En inledande punkt (.mycompany.com) matchar alla underdomäner.

4. Kan jag använda Wget med roterande proxies?

Wget har ingen inbyggd proxyrotation. Du har två alternativ: använd en proxyleverantör som roterar IP-adresser på serversidan (så att du alltid når samma gateway-adress, men utgående IP ändras), eller skriv ett shellskript som väljer en slumpmässig proxy från en lista och skickar den via -e http_proxy=... vid varje körning. För allt mer avancerat — automatisk rotation, retry-logik, anti-bot-hantering — är ett dedikerat scrapingverktyg oftast bättre.

5. Vad är skillnaden mellan http_proxy och https_proxy i Wget?

http_proxy används när mål-URL:en börjar med http://. https_proxy används när mål-URL:en börjar med https://. I båda fallen är proxy-URL:en själv oftast en adress med http://. För HTTPS-mål skickar Wget en HTTP CONNECT-begäran genom proxyn för att etablera en tunnel, och den faktiska HTTPS-krypteringen sker ända mellan Wget och målservern. Proxyn ser värdnamnet (från CONNECT-begäran) men kan inte läsa den krypterade trafiken.

Testa Thunderbit för AI-webbscraping Get Started Free

Läs mer