Slik bruker du Wget med en proxy (og unngår vanlige fallgruver)

Oppsett av proxy i Wget ser ut som en jobb som tar fem sekunder — helt til du bruker en time på å finne ut hvorfor forespørslene dine går rett forbi proxien, uten én eneste feilmelding. Jeg har sett dette skje både med erfarne systemadministratorer og ferske utviklere.

Den egentlige årsaken er nesten aldri selve proxien. Det handler som regel om de fire ulike stedene Wget kan lese proxyinnstillinger fra, stille feil når du bruker feil store/små bokstaver i variabelnavn, og de små særtrekkene i bedriftsnettverk som ingen man-side gidder å forklare. Denne guiden går gjennom alle måtene å konfigurere Wget med proxy på, de nøyaktige prioriteringsreglene når flere metoder krasjer med hverandre, ekte terminalutskrifter for vanlige feil, og en egen del for Windows- og bedriftsbrannmurbrukere — altså den gruppen nesten alle andre guider later som ikke finnes.

Vanskelighetsgrad: Nybegynner til middels
Tidsbruk: ~15 minutter å lese og sette opp; ~2 minutter når du vet hva du gjør
Det du trenger: En fungerende Wget-installasjon (instruksjoner nedenfor), en proxyadresse (vert + port), og eventuelt proxy-opplysninger

Prøv Thunderbit for strukturert datauttrekk

Hva er Wget, og hvorfor bruke det med en proxy?

Wget er et kommandolinjeverktøy som laster ned filer og nettsider fra internett uten nettleser. GNUs egen beskrivelse kaller det en «non-interactive network downloader» — altså et verktøy som kjører i bakgrunnen, fortsetter avbrutte overføringer og håndterer rekursive nedlastinger uten at noen trenger å klikke på noe.

En proxy er i denne sammenhengen en mellommannsserver. I stedet for at maskinen din kobler seg direkte til et nettsted, sender Wget forespørselen til proxien, og proxien videresender den. De vanligste grunnene til å gjøre dette er:

Etterlevelse av bedriftsbrannmur — bedriften krever at all utgående trafikk går via en godkjent proxy
Personvern og IP-styring — forespørsler ser ut til å komme fra proxyens IP, ikke din egen
Geotesting — hent innhold som er låst til bestemte regioner, eller test CDN-atferd fra et spesifikt geografisk område
Datainnsamlingsflyter — last ned HTML via roterende proxyer til forskning eller overvåking
CI/CD-miljøer — byggeagenter i låste nettverk som bare kan nå internett via proxy

Wget støtter naturlig HTTP-, HTTPS- og FTP-proxyer. Det støtter ikke SOCKS5. Hvis du trenger SOCKS5, har curl innebygd støtte for socks4://, socks5:// og socks5h:// — eller du kan pakke Wget inn i et verktøy som proxychains4.

Slik installerer du Wget på Linux, macOS og Windows

Før du setter opp proxy, må du ha Wget på maskinen. Denne delen går raskt — det er et krav, ikke hovedpoenget.

Linux (Debian/Ubuntu og RHEL/CentOS)

# Debian/Ubuntu
sudo apt update
sudo apt install wget

# RHEL/CentOS/Fedora
sudo dnf install wget

# Sjekk versjon
wget --version

Ubuntu 24.04 LTS leveres med Wget 1.21.4, mens Debian Trixie har 1.25.0. CentOS Stream 10-pakkene viser 1.24.5.

macOS (Homebrew)

brew install wget
wget --version

Homebrews formel tilbyr per nå stabile Wget 1.25.0, med 396 818 installasjoner det siste året.

Windows (Chocolatey og manuell installasjon)

choco install wget
wget --version

Chocolateys GNU Wget-pakke rapporterer over 10 millioner totale nedlastinger, men ligger for øyeblikket på versjon 1.21.4. Binæren havner vanligvis under C:\ProgramData\chocolatey\bin\wget.exe.

Et viktig tips for Windows-brukere: Hvor Wget ser etter .wgetrc varierer med bygget. Mer om dette i Windows-delen nedenfor.

4 måter å bruke Wget med en proxy på (og hvilken du bør velge)

Fire metoder, hver med sitt eget omfang og sin egen prioritet:

Kommandolinjeflagg med -e — for enkeltstående kommandoer
Brukerkonfigurasjonsfil (~/.wgetrc) — gjelder for alle Wget-kommandoer du kjører
Systemkonfigurasjonsfil (/etc/wgetrc) — gjelder for alle brukere på maskinen
Miljøvariabler (http_proxy, https_proxy) — gjelder for hele skallsesjonen

Metode 1: Kommandolinjeflagg (enkelttilfelle)

Best for raske tester. Innstillingene forsvinner når kommandoen er ferdig.

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

For HTTPS-mål:

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

Rask test — hent din tilsynelatende IP gjennom proxien:

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

Hvis output viser proxyens IP i stedet for din egen, er du i mål.

Metode 2: Brukerkonfigurasjonsfil (~/.wgetrc)

Legg inn disse linjene i ~/.wgetrc (opprett filen hvis den ikke finnes):

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

Legg merke til mellomrommene rundt = — det er den dokumenterte syntaksen for .wgetrc. Alle Wget-kommandoer du kjører som denne brukeren vil nå gå via proxien.

Metode 3: Systemomfattende konfigurasjon (/etc/wgetrc)

De samme direktivene som i ~/.wgetrc, men lagt i systemfilen. GNU beskriver dette som en global oppstartsfil — nøyaktig plassering avhenger av installasjonsstien. Vanlige steder er:

/etc/wgetrc (de fleste Linux-pakkebehandlere)
/usr/local/etc/wgetrc (noen Homebrew-bygg)
Stien som vises i wget --version under «Wgetrc:»

Dette er nyttig på delte servere, i Docker-containere eller i andre miljøer der alle brukere skal gå gjennom samme proxy.

Metode 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

Disse påvirker hele skallsesjonen — ikke bare Wget. Verktøy som curl plukker dem også opp.

Kritisk advarsel: Wget leser bare miljøvariabler med små bokstaver. HTTP_PROXY (store bokstaver) ignoreres stille. Ingen feil, ingen advarsel, ingenting. Jeg viser nøyaktig terminalutskrift i fallgruve-delen, men dette er verdt å huske med en gang.

Prioritet mellom proxy-metoder: Hva overstyrer hva når flere metoder er satt

Hvis du har proxy konfigurert både i miljøvariabler, i .wgetrc og på kommandolinjen, hvem vinner? Det er ingen som forklarer dette tydelig, så jeg testet det.

Her er den testede og dokumenterte rekkefølgen:

Prioritet	Metode	Omfang	Overstyrer
1 (høyest)	`-e` CLI-flagg	Enkeltkommando	Alt
2	`~/.wgetrc`	Nåværende bruker	Systemkonfig + miljøvariabler
3	`/etc/wgetrc`	Hele systemet	Bare miljøvariabler
4 (lavest)	`http_proxy` / `https_proxy` miljøvariabler	Skallsesjon	Ingenting

Jeg bekreftet dette i Wget 1.25.0 ved å sette motstridende proxyer på hvert nivå. Med miljøet pekt mot port 3128, konfigurasjonsfilen mot 3129 og CLI mot 3130:

Konfigurasjon slår miljø: Wget koblet til port 3129 og ignorerte 3128.
CLI slår konfigurasjon: Wget koblet til port 3130 og ignorerte både 3129 og 3128.

Nødløsningen er --no-proxy. Den overstyrer alle proxyinnstillinger, uansett hvor de er satt:

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

Praktisk scenario: Systemadministratoren din har satt proxy i /etc/wgetrc, men du må nå en intern server direkte. Bruk --no-proxy for akkurat den kommandoen i stedet for å redigere systemkonfigurasjonen.

Slik bruker du Wget med en autentisert proxy

De fleste bedrifts- og boligproxies krever brukernavn og passord. Wget støtter dette via to metoder, begge med HTTP Basic-autentisering for proxyopplysningene.

Innebygde opplysninger i proxy-URL-en

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

Dette fungerer også i .wgetrc:

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

Bruke flaggene --proxy-user og --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

Disse flaggene overstyrer eventuelle user:pass@ som ligger innebygd i proxy-URL-en.

Slik holder du legitimasjonen trygg

Begge metodene kan lekke opplysningene. GNU advarer om at passord på kommandolinjen er synlige via ps eller andre prosesslister. Tiltak:

Maskiner med én bruker: Lagre opplysningene i ~/.wgetrc og lås filen: chmod 600 ~/.wgetrc
CI/CD-pipelines: Bruk GitHub Actions sine krypterte secrets eller tilsvarende løsning i plattformen din. Send dem inn som miljøvariabler med små bokstaver i stegdefinisjonen — aldri hardkod i YAML.
Docker-bygg: Ikke bruk ARG eller ENV for hemmeligheter. Dockers dokumentasjon advarer eksplisitt om at build-argumenter kan bli værende i sluttbildet. Bruk BuildKit secret mounts i stedet.
Versjonskontroll: Commit aldri .wgetrc med legitimasjon. Legg den i .gitignore.

En Wget-spesifikk detalj for GitHub Actions: Hemmelighetsnavn lagres vanligvis med store bokstaver, men miljøvariablene du eksponerer til Wget må være med små bokstaver (http_proxy, ikke HTTP_PROXY).

Slik bruker du Wget med en proxy på Windows og bak bedriftsbrannmurer

De fleste artikler om dette temaet stopper ved «installer med Chocolatey». Hvis du er på Windows eller bak en bedriftsproxy, er det der problemene dine starter.

Hvor Windows leter etter .wgetrc

GNU-dokumentasjonen sier at Wget leser $HOME/.wgetrc med mindre WGETRC-miljøvariabelen peker et annet sted. På Windows kan $HOME mappe til %USERPROFILE% (for eksempel C:\Users\alice), eller ikke — avhengig av om du bruker Chocolatey-bygg, MSYS2-bygg, Git Bash eller en separat binærfil.

Min anbefaling: Dropp gjettingen og bruk --config for forutsigbar oppførsel:

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

For å teste om bygget ditt leser en konfigurasjonsfil fra et bestemt sted, lag en testfil som peker mot en kjent feil proxy:

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

Kjør deretter:

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

Hvis Wget prøver å koble til 127.0.0.1:3128, har den lest filen.

Slik setter du proxy-miljøvariabler på Windows

CMD (bare i denne økten):

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

PowerShell (bare i denne økten):

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

Permanent (overlever omstart):

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

Etter setx må du åpne et nytt terminalvindu. Den nåværende økten ser ikke endringen.

Fallgruver med bedriftsproxy: PAC-filer, NTLM-autentisering og hvordan finne proxyadressen

Tre ting som stadig skaper trøbbel for bedriftsbrukere:

PAC-filer: Mange virksomheter bruker Proxy Auto-Configuration (PAC)-filer — JavaScript-baserte skript som forteller nettleseren hvilken proxy som skal brukes for hvilken URL. Wget har ingen JavaScript-tolker, så den kan ikke lese PAC-filer. Curls dokumentasjon sier det samme. Løsningen: Åpne PAC-filen (eller spør IT), finn PROXY host:port-svaret for domenet du skal nå, og konfigurer den statiske adressen i Wget.

NTLM-autentisering: Wgets proxyautentisering støtter bare Basic-auth. Hvis bedriftsproxyen krever NTLM og du får 407 Proxy Authentication Required, ikke kast bort tid på å prøve ulike --proxy-user-varianter. Installer Cntlm — en lokal mellomtjener som håndterer NTLM/NTLMv2-autentisering og presenterer et Basic-auth-grensesnitt til Wget. Cntlm vedlikeholdes fortsatt (sist oppdatert oktober 2025, rundt 395 nedlastinger i uken).

Beslutningstre for bedriftsbrukere av proxy:

Prøv set http_proxy=http://DIN_PROXY:PORT/ og kjør Wget.
Hvis du får en 407-feil og bedriften bruker NTLM → installer Cntlm, konfigurer det med domenekontoen din, og pek Wget mot Cntlms lokale port (vanligvis http://127.0.0.1:3128/).
Hvis bedriften bruker en PAC-fil → hent den faktiske PROXY host:port fra PAC-filen, eller be IT om den statiske proxyadressen.

Vanlige proxyporter i bedrifter: 3128 (Squid-stil), 8080 (generell HTTP-proxy), 8888 (feilsøkingsproxyer som Fiddler/Charles). Dette er vaner, ikke garantier.

Vanlige fallgruver når du bruker Wget med proxy (med ekte feilmeldinger)

Nå til gevinsten som ble lovet i tittelen. All output nedenfor ble gjenskapt med Wget 1.25.0 (macOS, Homebrew) den 2026-06-01.

Fallgruve 1: Mangler `http://`-prefiks

Noen eldre guider hevder at dette alltid ødelegger. I Wget 1.25.0 fungerer faktisk http_proxy=127.0.0.1:3128 — Wget legger stille til http:// foran:

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 koblet likevel til riktig proxy. Men jeg anbefaler fortsatt å alltid ta med http://-prefikset og en skråstrek på slutten. Det fjerner tvetydighet mellom Wget-versjoner og gjør legitimasjonssyntaksen (http://user:pass@host:port/) entydig.

Fallgruve 2: use_proxy=yes vs. use_proxy=on

Både yes og on fungerte i mine tester med Wget 1.25.0. Men ugyldige verdier feiler med en tydelig feilmelding:

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

Bruk on for bredest kompatibilitet — det samsvarer med manualens dokumenterte boolske format og Wgets egen feilhint.

Fallgruve 3: HTTP_PROXY med store bokstaver ignoreres stille

Dette er den mest frustrerende fallgruven fordi det finnes ingen feilmelding i det hele tatt. Wget kobler bare direkte, som om du aldri satte en proxy.

Store bokstaver (feil — ingen proxy brukt):

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å bokstaver (fungerer — prøver 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 forskjellen? Versjonen med store bokstaver slo opp example.com direkte. Versjonen med små bokstaver prøvde proxien. Ingen advarsel i noen av tilfellene. Curl har en lignende særhet — det godtar store bokstaver for de fleste proxyvariabler, men avviser uttrykkelig HTTP_PROXY av sikkerhetshensyn.

Fiks: Bruk alltid små bokstaver i http_proxy og https_proxy.

Fallgruve 4: Gammel proxy i .wgetrc gir «Connection Refused»

Hvis du (eller systemadministratoren din, eller et Docker-image) har lagt igjen en gammel proxyadresse i en konfigurasjonsfil, vil du se noe slikt:

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.

Feilen peker på den gamle proxy-IP-en, ikke målnettstedet. Riktig feilsøkingsrekkefølge, i tråd med prioriteringshierarkiet:

Sjekk kommandoen din for -e-flagg eller skallaliaser
Sjekk ~/.wgetrc (eller filen som WGETRC peker til)
Sjekk systemkonfigurasjonen (stien som vises av wget --version)
Sjekk miljøet: env | grep -i proxy

For feilsøking er --no-config din venn — den ber Wget hoppe over alle konfigurasjonsfiler:

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

Hvis det fungerer, ligger problemet i en konfigurasjonsfil.

Fallgruve 5: Forvirring rundt syntaks for HTTPS-proxy

Dette er noe mange snubler i. Når du setter https_proxy, er proxy-URL-en vanligvis http://, ikke https://. Det er fordi Wget sender en HTTP CONNECT-forespørsel gjennom proxien for å opprette en tunnel for den krypterte HTTPS-sesjonen.

Riktig:

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

Wget sender CONNECT example.com:443 HTTP/1.1 til proxien, og tunneler deretter HTTPS gjennom den.

Feil (for HTTP-mål-URL-er med et HTTPS-proxyendepunkt):

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 avviser https:// som proxy-URL for HTTP-mål direkte. Bruk https_proxy=http://HOST:PORT/ med mindre organisasjonen din spesifikt har dokumentert et HTTPS-proxyendepunkt og du har testet det med din Wget-versjon.

Hurtigreferanse for Wget-proxykommandoer

Bokmerk denne tabellen. Den samler alle Wget-flagg og konfigurasjonsdirektiver knyttet til proxy på ett sted.

Flagg / direktiv	Kontekst	Eksempel	Merknader
`-e use_proxy=on`	CLI	`-e use_proxy=on`	`on` er sikrest; noen bygg godtar også `yes`
`-e http_proxy=`	CLI	`-e http_proxy=http://proxy:8080/`	Ta med `http://`-prefiks og avsluttende `/`
`-e https_proxy=`	CLI	`-e https_proxy=http://proxy:8080/`	Proxy-URL-en er vanligvis `http://` selv for HTTPS-mål
`--proxy-user`	CLI	`--proxy-user=admin`	Overstyrer innebygd `user:pass@`
`--proxy-password`	CLI	`--proxy-password=secret`	Synlig i `ps` — unngå på delte systemer
`--no-proxy`	CLI	`--no-proxy`	Bypasser ALLE proxyinnstillinger fra alle kilder
`--no-config`	CLI	`--no-config`	Hopper over alle konfigurasjonsfiler — nyttig ved feilsøking
`--config=FILE`	CLI	`--config=/tmp/wgetrc`	Forutsigbar konfigurasjonssti — veldig nyttig på Windows og i CI
`http_proxy`	`.wgetrc` / miljø	`http_proxy = http://proxy:8080/`	Konfigurasjonsfil bruker mellomrom rundt `=`; miljøvariabel bruker små bokstaver
`https_proxy`	`.wgetrc` / miljø	`https_proxy = http://proxy:8080/`	Samme format som `http_proxy`
`ftp_proxy`	`.wgetrc` / miljø	`ftp_proxy = http://proxy:8080/`	For FTP-nedlastinger
`no_proxy`	`.wgetrc` / miljø	`no_proxy = localhost,127.0.0.1,.corp`	Komma-separert domeneliste
`proxy_user`	`.wgetrc`	`proxy_user = admin`	Tilsvarer `--proxy-user`
`proxy_password`	`.wgetrc`	`proxy_password = secret`	Beskytt filen med `chmod 600`

Når Wget + proxy ikke er riktig verktøy (og hva du bør bruke i stedet)

Etter all denne proxykonfigurasjonen, her er en litt kontrær påstand: Noen ganger bør du la være.

Mange som søker på «wget proxy» prøver egentlig ikke å laste ned én enkelt fil. De vil samle strukturert data fra nettsteder — produktpriser, kontaktlister, boligannonser — og har valgt Wget fordi det er kommandolinjeverktøyet de allerede kjenner. Problemet er at Wget bare gir deg rå HTML. Du må fortsatt tolke det, rydde det og strukturere det. Og hvis du roterer proxyer for å unngå blokkeringer, må du plutselig vedlikeholde en proxy-liste, et nedlastingsskript, en parser og en eksportflyt.

Målet ditt	Beste verktøy	Hvorfor
Last ned én fil gjennom en proxy	`wget` med proxy-flagg	Enkelt, én kommando
Speil et nettsted eller en mappe via proxy	`wget --recursive` + proxykonfigurasjon	Rekursiv nedlasting er en av Wgets styrker
Skrap strukturert data (tabeller, lister, kontakter)	Thunderbit	Wget gir deg rå HTML — du må fortsatt tolke den. Thunderbits AI leser siden og leverer strukturert data til Excel, Google Sheets, Airtable eller Notion uten kode. Skybasert skraping håndterer IP-rotasjon og anti-bot-tiltak, så du slipper proxyoppsett helt.
REST API-kall gjennom en proxy	`curl`	Bedre kontroll over headere, innebygd JSON-støtte, SOCKS5-støtte
Løpende, planlagt datainnsamling	Thunderbit Scheduled Scraper eller `cron` + wget	Thunderbit tilpasser seg når sidens layout endres; cron + wget-skript feiler ofte stille

Wget er veldig god på filnedlastinger. Men arbeidsflyten «konfigurer proxy → roter IP-er → last ned HTML → skriv parser → eksporter til regneark» innebærer mange bevegelige deler når det du egentlig vil ha er en datatabell. Hvis det høres ut som situasjonen din, håndterer Chrome-utvidelsen vår hele løypa på to klikk. Les mer om tilnærmingen i guidene våre om AI web scraping og webskraping uten koding.

Men hvis målet ditt er «last ned denne ZIP-filen gjennom en bedriftsproxy» — da er Wget fortsatt riktig verktøy, og nå vet du hvordan du setter det opp skikkelig.

Viktige læringspunkter

Kortversjonen:

Fire metoder, tydelig prioritet: CLI-flagg overstyrer brukerkonfigurasjon, som overstyrer systemkonfigurasjon, som overstyrer miljøvariabler. --no-proxy overstyrer alt.
Bruk alltid små bokstaver for miljøvariabler (http_proxy, ikke HTTP_PROXY). Store bokstaver ignoreres stille.
Ta alltid med http:// i proxy-URL-en din, selv for https_proxy. Proxy-endepunktet er HTTP; det tunnelerer HTTPS via CONNECT.
Bruk on for boolske verdier i .wgetrc og -e-flagg. Det er det tryggeste valget på tvers av Wget-versjoner.
Windows-brukere: Bruk --config=C:\path\to\wgetrc for å unngå uklarhet rundt konfigurasjonsfil. Bruk set (CMD) eller $env: (PowerShell) for sesjonsvariabler for proxy.
Bedriftsbrukere av proxy: Wget kan ikke lese PAC-filer og har ikke innebygd støtte for NTLM-autentisering. Bruk Cntlm som lokal mellomtjener ved behov.
Bokmerk hurtigreferansen over — den sparer deg for å lese artikkelen på nytt hver gang du lurer på et flaggnavn.

Hvis det du egentlig trenger er strukturert datauttrekk, kan Thunderbit eller curl være et bedre valg. Den beste feilsøkingsøkten er den du aldri trenger å starte.

Vanlige spørsmål

1. Støtter Wget SOCKS5-proxyer?

Nei. GNU Wget 1.x støtter bare HTTP-, HTTPS- og FTP-proxyer. Wget2-prosjektet har hatt SOCKS5 som et ønske om funksjonalitet, men det er ikke et standard dokumentert alternativ. For SOCKS5 bør du bruke curl med de innebygde scheme-ene socks5:// eller socks5h://, eller pakke Wget inn i proxychains4 for å tvinge SOCKS-ruting.

2. Hvorfor blir proxyinnstillingen min ignorert når jeg bruker HTTP_PROXY med store bokstaver?

Wget leser bare miljøvariabler med små bokstaver (http_proxy, https_proxy, ftp_proxy, no_proxy). Varianter med store bokstaver, som HTTP_PROXY, blir ignorert stille — uten feil og uten advarsel. Dette er et av de vanligste og mest frustrerende problemene, fordi ingenting avslører at noe er galt. Bruk alltid små bokstaver.

3. Hvordan omgår jeg proxy for bestemte domener?

Bruk no_proxy-direktivet, enten 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

Domener skilles med komma. Et ledende punktum (.mycompany.com) matcher alle underdomener.

4. Kan jeg bruke Wget med roterende proxyer?

Wget har ikke innebygd proxyrotasjon. Du har to valg: Bruk en proxy-leverandør som roterer IP-er på serversiden (slik at du alltid treffer samme gateway-adresse, men utgående IP endres), eller skriv et skallskript som velger en tilfeldig proxy fra en liste og sender den via -e http_proxy=... for hver kjøring. For mer komplekse behov — automatisk rotasjon, retry-logikk, anti-bot-håndtering — er et dedikert skrapeverktøy som regel et bedre valg.

5. Hva er forskjellen på http_proxy og https_proxy i Wget?

http_proxy brukes når mål-URL-en er http://. https_proxy brukes når mål-URL-en er https://. I begge tilfeller er proxy-URL-en vanligvis en http://-adresse. For HTTPS-mål sender Wget en HTTP CONNECT-forespørsel gjennom proxien for å opprette en tunnel, og selve HTTPS-krypteringen skjer ende til ende mellom Wget og målserveren. Proxien ser vertsnavnet (fra CONNECT-forespørselen), men kan ikke lese den krypterte trafikken.

Prøv Thunderbit for AI-webskraping Get Started Free

Les mer