Sådan bruger du Wget med en proxy (og undgår de klassiske faldgruber)

At sætte Wget op med en proxy ser ud som en 5-sekunders opgave — indtil du bruger en time på at finde ud af, hvorfor dine forespørgsler bare springer proxyen over uden så meget som en fejlmeddelelse. Jeg har set det ske for både erfarne sysadmins og nye udviklere.

Den egentlige årsag er næsten aldrig proxyen i sig selv. Det handler om de fire forskellige steder, Wget kan læse proxy-indstillinger fra, de stille fejl når du bruger forkert store/små bogstaver i variabelnavne, og de særheder i virksomhedsnetværk, som ingen manualer rigtig gider forklare. Denne guide gennemgår alle måder at konfigurere Wget med en proxy, de præcise prioritetsregler når metoderne er i konflikt, faktiske terminaludskrifter for de mest almindelige fejl, og et særskilt afsnit til Windows- og virksomhedsfirewall-brugere — altså den gruppe næsten alle andre guides glemmer.

Sværhedsgrad: Begynder til let øvet
Tidsforbrug: Ca. 15 minutter til at læse og sætte op; ca. 2 minutter når du først ved, hvad du laver
Det skal du bruge: En fungerende Wget-installation (vejledning nedenfor), en proxyadresse (host + port) og eventuelt proxy-oplysninger

Prøv Thunderbit til struktureret dataudtræk

Hvad er Wget, og hvorfor bruge det med en proxy?

Wget er et kommandolinjeværktøj, der henter filer og websider fra internettet uden en browser. GNU's egen beskrivelse kalder det en "non-interactive network downloader" — altså et værktøj, der kører i baggrunden, genoptager afbrudte overførsler og håndterer rekursive downloads uden at et menneske skal klikke på noget.

En proxy er i denne sammenhæng en mellemstation. I stedet for at din maskine forbinder direkte til et website, sender Wget forespørgslen til proxyen, som videresender den. Det bruger man typisk til:

Overholdelse af virksomhedsfirewall — din virksomhed kræver, at al udgående trafik går gennem en godkendt proxy
Privatliv og IP-styring — forespørgsler ser ud til at komme fra proxyens IP og ikke din egen
Geo-test — hent regionlåst indhold eller test CDN-adfærd fra et bestemt geografisk område
Dataindsamlingspipelines — hent HTML via roterende proxies til research eller monitorering
CI/CD-miljøer — build-runnere i låste netværk, der kun har internetadgang via en proxy

Wget understøtter naturligt HTTP-, HTTPS- og FTP-proxies. Det understøtter ikke SOCKS5. Hvis du har brug for SOCKS5, har curl indbygget støtte til socks4://, socks5:// og socks5h:// — eller du kan pakke Wget ind i et værktøj som proxychains4.

Sådan installerer du Wget på Linux, macOS og Windows

Før du kan konfigurere proxies, skal Wget være installeret. Dette afsnit er kort — det er en forudsætning, ikke hovedemnet.

Linux (Debian/Ubuntu og RHEL/CentOS)

# Debian/Ubuntu
sudo apt update
sudo apt install wget

# RHEL/CentOS/Fedora
sudo dnf install wget

# Tjek version
wget --version

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

macOS (Homebrew)

brew install wget
wget --version

Homebrews formel leverer i øjeblikket stabile Wget 1.25.0, med 396.818 installationer det seneste år.

Windows (Chocolatey og manuel installation)

choco install wget
wget --version

Chocolateys GNU Wget-pakke angiver over 10 millioner samlede downloads, selvom den aktuelt ligger på version 1.21.4. Binæren ender typisk i C:\ProgramData\chocolatey\bin\wget.exe.

Et vigtigt tip til Windows-brugere: hvor Wget leder efter .wgetrc, varierer efter build. Detaljer i afsnittet om Windows nedenfor.

4 måder at bruge Wget med en proxy på (og hvilken du bør vælge)

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

Kommandolinjens -e-flag — engangsbrug, én kommando
Brugerkonfigurationsfil (~/.wgetrc) — gælder for alle Wget-kommandoer, du selv kører
Systemkonfigurationsfil (/etc/wgetrc) — gælder for alle brugere på maskinen
Miljøvariabler (http_proxy, https_proxy) — gælder for hele shells-sessionen

Metode 1: Kommandolinjeflag (engangsproxy)

Bedst til hurtige tests. Indstillingerne forsvinder, når kommandoen er færdig.

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/

Hurtig test — hent din synlige IP via proxyen:

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: Brugerkonfigurationsfil (~/.wgetrc)

Tilføj disse linjer i ~/.wgetrc (opret filen, hvis den ikke findes):

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

Bemærk mellemrum omkring = — det er den dokumenterede .wgetrc-syntaks. Alle Wget-kommandoer, du kører som denne bruger, går nu gennem proxyen.

Metode 3: Systemomfattende konfiguration (/etc/wgetrc)

De samme direktiver som i ~/.wgetrc, men placeret i systemets konfigurationsfil. GNU beskriver dette som en global opstartsfil — den præcise placering afhænger af din installationssti. Typiske placeringer:

/etc/wgetrc (de fleste Linux-pakkehåndterere)
/usr/local/etc/wgetrc (nogle Homebrew-builds)
Stien vist i wget --version under "Wgetrc:"

Det er nyttigt på fælles servere, i Docker-containere eller i andre miljøer, hvor alle brugere skal ud gennem den 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 din shells-session — ikke kun Wget. Værktøjer som curl læser dem også.

Vigtig advarsel: Wget læser kun miljøvariabler i små bogstaver. HTTP_PROXY (versaler) ignoreres helt uden varsel. Ingen fejl, ingen advarsel, ingenting. Jeg viser den præcise terminaloutput i afsnittet om faldgruber, men det er værd at huske allerede nu.

Prioritet mellem proxy-metoder: Hvad vinder, når flere er sat?

Hvis du har en proxy i dine miljøvariabler og i .wgetrc og på kommandolinjen, hvad gælder så? Det er ikke altid tydeligt beskrevet, så jeg testede det.

Her er den testede og dokumenterede prioritet:

Prioritet	Metode	Omfang	Overstyrer
1 (højest)	`-e` CLI-flag	Én kommando	Alt
2	`~/.wgetrc`	Aktuel bruger	Systemkonfiguration + miljøvariabler
3	`/etc/wgetrc`	Hele systemet	Kun miljøvariabler
4 (lavest)	`http_proxy` / `https_proxy` miljøvariabler	Shell-session	Intet

Jeg verificerede dette på Wget 1.25.0 ved at sætte modstridende proxies på hvert niveau. Med miljøet pegende på port 3128, konfigurationsfilen på 3129 og CLI på 3130:

Konfiguration vinder over miljø: Wget forbandt til port 3129 og ignorerede 3128.
CLI vinder over konfiguration: Wget forbandt til port 3130 og ignorerede både 3129 og 3128.

Nødudgangen er --no-proxy. Den tilsidesætter alle proxyindstillinger, uanset hvor de er sat:

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

Praktisk scenarie: din sysadmin har sat en proxy i /etc/wgetrc, men du skal nå en intern server direkte. Brug --no-proxy til netop den kommando i stedet for at ændre systemkonfigurationen.

Sådan bruger du Wget med en autentificeret proxy

De fleste business- og residential-proxies kræver brugernavn og password. Wget understøtter dette via to metoder, som begge bruger HTTP Basic-authentication til proxy-legitimationsoplysninger.

Indbyggede legitimationsoplysninger 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 virker også i .wgetrc:

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

Brug af `--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 flag tilsidesætter eventuelle user:pass@-oplysninger, der er indlejret i proxy-URL'en.

Sådan holder du legitimationsoplysninger sikre

Begge metoder kan eksponere adgangsoplysninger. GNU advarer om, at passwords på kommandolinjen kan ses via ps eller værktøjer til proceslister. Sådan reducerer du risikoen:

En-bruger-maskiner: Gem oplysninger i ~/.wgetrc og lås filen: chmod 600 ~/.wgetrc
CI/CD-pipelines: Brug GitHub Actions krypterede secrets eller tilsvarende i din platform. Send dem som miljøvariabler i små bogstaver i step-definitionen — hardcode dem aldrig i YAML.
Docker-builds: Brug ikke ARG eller ENV til secrets. Dockers dokumentation advarer eksplicit om, at build-arguments kan ende i det færdige image. Brug i stedet BuildKit secret mounts.
Versionsstyring: Commit aldrig .wgetrc med credentials. Tilføj den til .gitignore.

En Wget-specifik detalje for GitHub Actions: secret-navne gemmes normalt med versaler, men de miljøvariabler du eksponerer til Wget, skal være i små bogstaver (http_proxy, ikke HTTP_PROXY).

Sådan bruger du Wget med en proxy på Windows og bag corporate firewalls

De fleste artikler om emnet stopper ved "installér med Chocolatey". Hvis du er på Windows eller bag en virksomhedsproxy, er det dér, problemerne begynder.

Hvor Windows leder efter .wgetrc

GNU-dokumentationen siger, at Wget læser $HOME/.wgetrc, medmindre miljøvariablen WGETRC peger et andet sted hen. På Windows kan $HOME være det samme som %USERPROFILE% (f.eks. C:\Users\alice) — eller ikke — afhængigt af om du bruger Chocolatey-build, en MSYS2-build, Git Bash eller en selvstændig binær.

Min anbefaling: drop gætteriet og brug --config-flaget for forudsigelig adfærd:

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

Hvis du vil teste, om din build læser en konfigurationsfil fra en bestemt placering, så lav en testfil, der peger på en proxy, du ved er forkert:

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

Kør derefter:

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

Hvis Wget forsøger at forbinde til 127.0.0.1:3128, har den læst filen.

Sådan sætter du proxy-miljøvariabler på Windows

CMD (kun denne session):

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

PowerShell (kun denne session):

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

Permanent (overlever genstarter):

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

Efter setx skal du åbne et nyt terminalvindue. Den nuværende session ser ikke ændringen.

Corporate proxy-faldgruber: PAC-filer, NTLM-autentificering og hvordan du finder din proxyadresse

Tre ting, der konsekvent skaber problemer for virksomhedsbrugere:

PAC-filer: Mange virksomheder bruger Proxy Auto-Configuration (PAC)-filer — JavaScript-baserede scripts, der fortæller browseren, hvilken proxy den skal bruge til hvilken URL. Wget har ingen JavaScript-fortolker, så den kan ikke læse PAC-filer. Curls dokumentation siger det samme. Løsningen: åbn PAC-filen (eller spørg IT), find resultatet PROXY host:port for dit mål-domæne, og brug den statiske adresse i Wget.

NTLM-autentificering: Wgets proxy-autentificering understøtter kun Basic auth. Hvis din virksomhedsproxy kræver NTLM og du får 407 Proxy Authentication Required, så spild ikke tid på at prøve forskellige --proxy-user-varianter. Installér Cntlm — en lokal relay, der håndterer NTLM/NTLMv2-autentificering og præsenterer en Basic-auth-grænseflade til Wget. Cntlm vedligeholdes stadig (seneste opdatering oktober 2025, ca. 395 downloads om ugen).

Beslutningstræ for corporate proxy-brugere:

Prøv set http_proxy=http://YOUR_PROXY:PORT/ og kør Wget.
Hvis du får en 407-fejl, og virksomheden bruger NTLM → installér Cntlm, konfigurér det med dine domæneoplysninger, og peg Wget på Cntlms lokale port (typisk http://127.0.0.1:3128/).
Hvis virksomheden bruger en PAC-fil → udtræk den faktiske PROXY host:port fra PAC-filen eller bed IT om den statiske proxyadresse.

Typiske corporate proxy-porte: 3128 (Squid-agtig), 8080 (generel HTTP-proxy), 8888 (debug-proxies som Fiddler/Charles). Det er konventioner, ikke garantier.

Almindelige faldgruber ved brug af Wget med en proxy (med virkelig fejloutput)

Og nu til det, titlen lovede. Alt output nedenfor er genskabt på Wget 1.25.0 (macOS, Homebrew) den 2026-06-01.

Faldgrube 1: Manglende `http://`-prefiks

Nogle ældre guides påstår, at dette altid går galt. I Wget 1.25.0 virker http_proxy=127.0.0.1:3128 faktisk fint — Wget sætter stille og roligt 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 ramte stadig den rigtige proxy. Men jeg anbefaler stadig, at du altid skriver http:// og et afsluttende skråstreg. Det fjerner tvivl på tværs af Wget-versioner og gør credentials-syntaksen (http://user:pass@host:port/) entydig.

Faldgrube 2: `use_proxy=yes` vs. `use_proxy=on`

Både yes og on virkede i mine tests med Wget 1.25.0. Men ugyldige værdier fejler med en tydelig fejl:

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

Brug on for bredest kompatibilitet — det matcher manualens dokumenterede boolske format og Wgets egen fejltekst.

Faldgrube 3: `HTTP_PROXY` i versaler ignoreres helt uden varsel

Det her er den mest frustrerende faldgrube, fordi der slet ikke kommer nogen fejl. Wget forbinder bare direkte, som om du aldrig satte en proxy.

Versaler (fejl — ingen proxy brugt):

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å bogstaver (virker — proxy forsøgt):

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 forskellen? Versal-versionen slog direkte op på example.com. Versionen med små bogstaver prøvede proxyen. Ingen advarsel i nogen af tilfældene. Curl har en lignende særhed — den accepterer normalt versaler for proxyvariabler, men afviser eksplicit HTTP_PROXY af sikkerhedshensyn.

Løsning: Brug altid små bogstaver: http_proxy og https_proxy.

Faldgrube 4: En gammel proxy i .wgetrc giver "Connection refused"

Hvis du (eller din sysadmin eller et Docker-image) har efterladt en gammel proxyadresse i en konfigurationsfil, ser du noget i stil med dette:

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.

Fejlen peger på den gamle proxy-IP, ikke på målsiden. Fremgangsmåde til fejlfinding (i prioriteringsrækkefølge):

Tjek din kommando for -e-flag eller shell-aliases
Tjek ~/.wgetrc (eller filen angivet af WGETRC)
Tjek systemkonfigurationen (stien vist af wget --version)
Tjek miljøet: env | grep -i proxy

Til fejlsøgning er --no-config din ven — den får Wget til at springe alle konfigurationsfiler over:

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

Hvis det virker, ligger problemet i en konfigurationsfil.

Faldgrube 5: Forvirring om HTTPS-proxy-syntaks

Det her forvirrer mange. Når du sætter https_proxy, er proxy-URL'en typisk http:// og ikke https://. Det skyldes, at Wget sender en HTTP CONNECT-forespørgsel gennem proxyen for at etablere en tunnel til den krypterede HTTPS-session.

Korrekt:

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

Wget sender CONNECT example.com:443 HTTP/1.1 til proxyen og tunneler derefter HTTPS gennem den.

Forkert (for HTTP-mål-URL'er med en HTTPS-proxy-endpoint):

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 afviser helt https:// som proxy-URL for HTTP-mål. Brug https_proxy=http://HOST:PORT/, medmindre din organisation specifikt har dokumenteret en HTTPS-proxy-endpoint, og du har testet den med din Wget-build.

Wget proxy-kommando cheatsheet (hurtig reference, som er værd at bogmærke)

Bogmærk denne tabel. Den samler alle Wget-flag og konfigurationsdirektiver relateret til proxy på ét sted.

Flag / direktiv	Kontekst	Eksempel	Bemærkninger
`-e use_proxy=on`	CLI	`-e use_proxy=on`	`on` er det sikreste; nogle builds accepterer også `yes`
`-e http_proxy=`	CLI	`-e http_proxy=http://proxy:8080/`	Medtag `http://` og en afsluttende `/`
`-e https_proxy=`	CLI	`-e https_proxy=http://proxy:8080/`	Proxy-URL'en er normalt `http://` selv for HTTPS-mål
`--proxy-user`	CLI	`--proxy-user=admin`	Tilsidesætter indlejret `user:pass@`
`--proxy-password`	CLI	`--proxy-password=secret`	Synlig i `ps` — undgå på delte systemer
`--no-proxy`	CLI	`--no-proxy`	Springer ALLE proxyindstillinger over fra alle kilder
`--no-config`	CLI	`--no-config`	Springer alle konfigurationsfiler over — nyttigt til fejlfinding
`--config=FILE`	CLI	`--config=/tmp/wgetrc`	Deterministisk konfigurationssti — god til Windows og CI
`http_proxy`	`.wgetrc` / env	`http_proxy = http://proxy:8080/`	Konfigurationsfil bruger mellemrum omkring `=`; miljøvariabel bruger små bogstaver
`https_proxy`	`.wgetrc` / env	`https_proxy = http://proxy:8080/`	Samme format som `http_proxy`
`ftp_proxy`	`.wgetrc` / env	`ftp_proxy = http://proxy:8080/`	Til FTP-hentninger
`no_proxy`	`.wgetrc` / env	`no_proxy = localhost,127.0.0.1,.corp`	Komma-separeret domæneliste
`proxy_user`	`.wgetrc`	`proxy_user = admin`	Svarer til `--proxy-user`
`proxy_password`	`.wgetrc`	`proxy_password = secret`	Beskyt filen med `chmod 600`

Når Wget + proxy ikke er det rigtige værktøj (og hvad du skal bruge i stedet)

Efter al den proxy-konfiguration er her et lidt modstridende synspunkt: nogle gange bør du slet ikke bruge det.

Mange, der søger på "wget proxy", prøver i virkeligheden ikke at hente én enkelt fil. De prøver at indsamle strukturerede data fra websites — produktpriser, kontaktlister, boligannoncer — og de er endt med Wget, fordi det er det kommandolinjeværktøj, de kender. Problemet er, at Wget giver dig rå HTML. Du skal stadig parse det, rense det og strukturere det. Og hvis du roterer proxies for at undgå blokeringer, skal du nu vedligeholde en proxy-liste, et downloadscript, en parser og en eksportpipeline.

Dit mål	Bedste værktøj	Hvorfor
Hent en enkelt fil gennem en proxy	`wget` med proxy-flag	Simpelt, én kommando
Spejl et website eller en mappe via proxy	`wget --recursive` + proxy-konfiguration	Wgets rekursive hentning er en af dets styrker
Scrape strukturerede data (tabeller, lister, kontakter)	Thunderbit	Wget giver rå HTML — du skal stadig parse det. Thunderbits AI læser siden og eksporterer strukturerede data til Excel, Google Sheets, Airtable eller Notion uden kode. Dets cloud scraping håndterer IP-rotation og anti-bot-foranstaltninger, så du slipper for proxy-opsætning helt.
REST API-kald gennem en proxy	`curl`	Bedre kontrol over headers, indbygget JSON-understøttelse, SOCKS5-understøttelse
Løbende planlagt dataindsamling	Thunderbit Scheduled Scraper eller `cron` + wget	Thunderbit tilpasser sig, når sidens layout ændrer sig; cron + wget-scripts går ofte i stykker uden varsel

Wget er fremragende til fil-downloads. Men arbejdsgangen "konfigurér proxy → roter IP'er → hent HTML → skriv parser → eksportér til regneark" er mange bevægelige dele, når du i virkeligheden bare vil have en tabel med data. Hvis det lyder som din situation, klarer vores Chrome-udvidelse hele forløbet med to klik. Se også vores guides om AI web scraping og web scraping uden kode.

Men hvis dit mål er "hent denne ZIP-fil gennem en virksomhedsproxy" — så er Wget stadig det rigtige værktøj, og nu ved du, hvordan du sætter det op korrekt.

Vigtige pointer

Kort version:

Fire metoder, klar prioritet: CLI-flag overstyrer brugerkonfiguration, som overstyrer systemkonfiguration, som overstyrer miljøvariabler. --no-proxy overstyrer alt.
Brug altid små bogstaver til miljøvariabler (http_proxy, ikke HTTP_PROXY). Versaler ignoreres uden varsel.
Skriv altid http:// i din proxy-URL, også for https_proxy. Proxy-endpointet er HTTP; det tunnelerer HTTPS via CONNECT.
Brug on til boolske værdier i .wgetrc og -e-flag. Det er det sikreste valg på tværs af Wget-versioner.
Windows-brugere: Brug --config=C:\sti\til\wgetrc for at undgå tvetydige konfigurationsfiler. Brug set (CMD) eller $env: (PowerShell) til sessionens proxyvariabler.
Corporate proxy-brugere: Wget kan ikke læse PAC-filer og understøtter ikke NTLM-autentificering direkte. Brug Cntlm som lokal relay, hvis det er nødvendigt.
Bogmærk cheatsheetet ovenfor — det sparer dig for at læse artiklen igen, hver gang du skal huske et flagnavn.

Hvis dit egentlige mål er struktureret dataudtræk, er Thunderbit eller curl måske et bedre valg. Den bedste fejlsøgningssession er den, du aldrig behøver at starte.

Ofte stillede spørgsmål

1. Understøtter Wget SOCKS5-proxies?

Nej. GNU Wget 1.x understøtter kun HTTP-, HTTPS- og FTP-proxies. Wget2-projektet har haft SOCKS5 som et feature request, men det er ikke en standardiseret dokumenteret mulighed. Til SOCKS5 kan du bruge curl med dets indbyggede socks5://- eller socks5h://-schemer, eller pakke Wget ind i proxychains4 for at tvinge SOCKS-routing.

2. Hvorfor bliver min proxyindstilling ignoreret, når jeg bruger versaler i HTTP_PROXY?

Wget læser kun miljøvariabler i små bogstaver (http_proxy, https_proxy, ftp_proxy, no_proxy). Varianter i versaler som HTTP_PROXY ignoreres helt uden fejl eller advarsel. Det er en af de mest almindelige og mest frustrerende fejl, fordi der ikke er nogen tydelig indikation på, at noget er galt. Brug altid små bogstaver.

3. Hvordan omgår jeg proxyen for bestemte domæner?

Brug 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

Domæner adskilles med komma. Et punktum i starten (.mycompany.com) matcher alle underdomæner.

4. Kan jeg bruge Wget med roterende proxies?

Wget har ikke indbygget proxy-rotation. Du har to muligheder: brug en proxy-udbyder, der roterer IP'er på serversiden (så du altid rammer den samme gateway-adresse, men udgangs-IP'en skifter), eller skriv et shell-script, der vælger en tilfældig proxy fra en liste og sender den videre via -e http_proxy=... ved hver kørsel. Til mere komplekse behov — automatisk rotation, retry-logik, anti-bot-håndtering — er et dedikeret scraping-værktøj normalt et bedre valg.

5. Hvad er forskellen på `http_proxy` og `https_proxy` i Wget?

http_proxy bruges, når mål-URL'en er http://. https_proxy bruges, når mål-URL'en er https://. I begge tilfælde er proxy-URL'en selv typisk en http://-adresse. For HTTPS-mål sender Wget en HTTP CONNECT-forespørgsel gennem proxyen for at etablere en tunnel, og den egentlige HTTPS-kryptering sker end-to-end mellem Wget og målserveren. Proxyen kan se hostnavnet (fra CONNECT-forespørgslen), men kan ikke læse den krypterede trafik.

Prøv Thunderbit til AI web scraping Get Started Free

Læs mere