Jak používat Wget s proxy serverem (a vyhnout se častým pastem)

Nastavení proxy ve Wgetu vypadá jako práce na pět vteřin — dokud nestrávíte hodinu zjišťováním, proč vaše požadavky proxy úplně obcházejí, a přitom nedostanete žádnou chybovou hlášku. Viděl jsem to u zkušených správců i u juniorních vývojářů.

Skutečný problém téměř nikdy není v proxy samotné. Jde o čtyři různá místa, odkud Wget umí načítat nastavení proxy, o tiché selhání při použití špatného zápisu proměnných, a o firemní síťové zvláštnosti, které se v manuálu obvykle vůbec nevysvětlují. Tenhle průvodce pokrývá všechny způsoby, jak Wget s proxy nastavit, přesná pravidla precedence, když se jednotlivé metody střetnou, reálný výstup z terminálu pro nejběžnější chyby i samostatnou část pro Windows a firemní sítě — tedy pro publikum, na které většina ostatních návodů jaksi zapomíná.

Obtížnost: Začátečník až středně pokročilý
Časová náročnost: přibližně 15 minut na přečtení a nastavení; asi 2 minuty, jakmile víte, co děláte
Co budete potřebovat: funkční instalaci Wgetu (návod níže), adresu proxy serveru (host + port) a volitelně přihlašovací údaje k proxy

Vyzkoušejte Thunderbit pro strukturované získávání dat

Co je Wget a proč byste ho chtěli používat s proxy?

Wget je nástroj do příkazové řádky, který stahuje soubory a webové stránky z internetu bez prohlížeče. Oficiální popis GNU o něm mluví jako o „neinteraktivním síťovém downloaderu“ — běží na pozadí, umí obnovit přerušené přenosy a zvládá rekurzivní stahování, aniž by na cokoli musel klikat člověk.

Proxy je v tomhle kontextu prostředník. Místo toho, aby se vaše zařízení připojilo přímo k cílovému webu, Wget pošle požadavek na proxy server a ten ho přepošle dál. Hlavní důvody, proč to dává smysl:

Soulad s firemním firewallem — firma vyžaduje, aby veškerý odchozí provoz šel přes schválenou proxy
Soukromí a správa IP — požadavky vypadají, že přicházejí z IP adresy proxy, ne z vaší
Testování podle lokality — přístup k regionálně omezenému obsahu nebo testování chování CDN z konkrétní země
Datové pipeline — stahování HTML přes rotující proxy pro výzkum nebo monitoring
CI/CD prostředí — build servery v uzamčených sítích, které se na internet dostanou jen přes proxy

Wget nativně podporuje HTTP, HTTPS a FTP proxy. Nepodporuje SOCKS5. Pokud SOCKS5 potřebujete, curl má nativní podporu pro schémata socks4://, socks5:// a socks5h:// — nebo můžete Wget obalit nástrojem jako proxychains4.

Jak nainstalovat Wget na Linux, macOS a Windows

Než začnete řešit proxy, musíte mít Wget na počítači. Tahle část je rychlá — je to nutný předpoklad, ne hlavní téma.

Linux (Debian/Ubuntu a RHEL/CentOS)

# Debian/Ubuntu
sudo apt update
sudo apt install wget

# RHEL/CentOS/Fedora
sudo dnf install wget

# Ověření
wget --version

Ubuntu 24.04 LTS dodává Wget 1.21.4, zatímco Debian Trixie má 1.25.0. Balíčky CentOS Stream 10 ukazují 1.24.5.

macOS (Homebrew)

brew install wget
wget --version

Formule v Homebrew aktuálně nabízí stabilní Wget 1.25.0, s 396 818 instalacemi za poslední rok.

Windows (Chocolatey a ruční instalace)

choco install wget
wget --version

Balíček GNU Wget v Chocolatey hlásí přes 10 milionů stažení celkem, i když je aktuálně ve verzi 1.21.4. Binárka obvykle končí v C:\ProgramData\chocolatey\bin\wget.exe.

Jedno upozornění pro uživatele Windows: kde přesně Wget hledá .wgetrc, závisí na konkrétním buildu. Podrobnosti najdete v sekci pro Windows níže.

4 způsoby, jak používat Wget s proxy (a který z nich zvolit)

Čtyři metody, každá s jiným rozsahem a prioritou:

Příznaky -e v příkazové řádce — jednorázově, pro jeden příkaz
Uživatelský konfigurační soubor (~/.wgetrc) — platí pro každý příkaz Wgetu, který spustíte
Systémový konfigurační soubor (/etc/wgetrc) — platí pro všechny uživatele na počítači
Proměnné prostředí (http_proxy, https_proxy) — platí pro celou relaci shellu

Metoda 1: Příznaky v příkazové řádce (jednorázová proxy)

Vhodné pro rychlé testy. Nastavení po dokončení příkazu zmizí.

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

Pro cíle přes HTTPS:

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

Rychlý test správné funkce — zjistěte svou zdánlivou IP adresu přes proxy:

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

Pokud výstup ukáže IP adresu proxy místo vaší vlastní, funguje to.

Metoda 2: Uživatelský konfigurační soubor (~/.wgetrc)

Do souboru ~/.wgetrc přidejte tyto řádky (soubor vytvořte, pokud neexistuje):

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

Všimněte si mezer kolem = — to je dokumentovaná syntaxe .wgetrc. Každý Wget příkaz, který pod tímto uživatelem spustíte, teď půjde přes proxy.

Metoda 3: Systémová konfigurace (/etc/wgetrc)

Stejné direktivy jako v ~/.wgetrc, jen uložené v systémovém konfiguračním souboru. GNU to popisuje jako globální startovací soubor — přesná cesta závisí na instalačním prefixu. Běžná umístění:

/etc/wgetrc (většina linuxových balíčkovacích systémů)
/usr/local/etc/wgetrc (některé Homebrew buildy)
Cesta uvedená ve výstupu wget --version pod položkou „Wgetrc:“

To se hodí pro sdílené servery, Docker kontejnery nebo jakékoli prostředí, kde má každý uživatel chodit přes stejnou proxy.

Metoda 4: Proměnné prostředí (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

Tyto proměnné ovlivní celou relaci shellu — nejen Wget. Vezmou si je i nástroje jako curl.

Důležité upozornění: Wget čte proměnné prostředí pouze v malých písmenech. HTTP_PROXY (velkými) jednoduše ignoruje. Žádná chyba, žádné varování, nic. Přesný výstup v terminálu ukážu v sekci s pastmi, ale stojí za to si to zapamatovat hned teď.

Priorita proxy metod: Co přepisuje co, když je nastaveno více metod najednou

Když máte proxy nastavenou v proměnných prostředí i v .wgetrc i na příkazové řádce, co rozhodne? Nikdo to nevysvětluje dost jasně, tak jsem to otestoval.

Tady je otestovaná a dokumentovaná priorita:

Priorita	Metoda	Rozsah	Přebíjí
1 (nejvyšší)	příznaky CLI `-e`	Jeden příkaz	Všechno
2	`~/.wgetrc`	Aktuální uživatel	Systémová konfigurace + proměnné prostředí
3	`/etc/wgetrc`	Pro celý systém	Jen proměnné prostředí
4 (nejnižší)	proměnné prostředí `http_proxy` / `https_proxy`	Relace shellu	Nic

Ověřil jsem to na Wgetu 1.25.0 tak, že jsem na každé úrovni nastavil konfliktní proxy. Když bylo prostředí nastavené na port 3128, konfigurační soubor na 3129 a CLI na 3130:

Konfigurace přebíjí prostředí: Wget se připojil na port 3129 a 3128 ignoroval.
CLI přebíjí konfiguraci: Wget se připojil na port 3130 a ignoroval 3129 i 3128.

Nouzový únik je --no-proxy. Tím obejdete všechna proxy nastavení bez ohledu na to, odkud pocházejí:

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

Praktický scénář: správce sítě nastavil proxy v /etc/wgetrc, ale vy se potřebujete dostat na interní server přímo. Použijte pro ten jeden příkaz --no-proxy místo úprav systémové konfigurace.

Jak používat Wget s autentizovanou proxy

Většina firemních i rezidenčních proxy vyžaduje uživatelské jméno a heslo. Wget to podporuje dvěma způsoby, oba pomocí HTTP Basic autentizace pro přihlašovací údaje k proxy.

Přihlašovací údaje přímo v URL proxy

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

To funguje i v .wgetrc:

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

Použití příznaků --proxy-user a --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

Tyto přepínače přebíjejí jakékoli user:pass@ vložené přímo do URL proxy.

Jak držet přihlašovací údaje v bezpečí

Obě metody mohou prozradit citlivé údaje. GNU upozorňuje, že hesla na příkazové řádce jsou vidět přes ps nebo jiné nástroje na výpis procesů. Jak to zmírnit:

Jednouživatelské počítače: Uložte údaje do ~/.wgetrc a soubor zamkněte: chmod 600 ~/.wgetrc
CI/CD pipeline: Použijte šifrované secrets v GitHub Actions nebo ekvivalent na své platformě. Předávejte je jako proměnné prostředí v malých písmeny přímo v definici kroku — nikdy je napevno nepište do YAML.
Docker buildy: Nepoužívejte ARG ani ENV pro tajné údaje. Dokumentace Dockeru výslovně upozorňuje, že build argumenty mohou zůstat v hotovém image. Místo toho použijte BuildKit secret mounts.
Správa verzí: Nikdy necommitujte .wgetrc s přihlašovacími údaji. Přidejte ho do .gitignore.

Jedna nuance specifická pro Wget v GitHub Actions: názvy secretů se běžně ukládají velkými písmeny, ale proměnné prostředí, které předáte Wgetu, musí být malé (http_proxy, ne HTTP_PROXY).

Jak používat Wget s proxy na Windows a za firemním firewallem

Většina článků na tohle téma skončí u věty „nainstalujte přes Chocolatey“. Pokud jste na Windows nebo za firemní proxy, tam vaše problémy teprve začínají.

Kde Windows hledá .wgetrc

GNU dokumentace říká, že Wget čte $HOME/.wgetrc, pokud proměnná WGETRC neukazuje jinam. Na Windows může $HOME odpovídat %USERPROFILE% (např. C:\Users\alice), ale taky nemusí — podle toho, jestli používáte Chocolatey build, MSYS2 build, Git Bash nebo samostatnou binárku.

Moje doporučení: vynechte hádání a použijte příznak --config, aby bylo chování jednoznačné:

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

Chcete-li otestovat, zda vaše verze čte konfigurační soubor z konkrétní cesty, vytvořte testovací soubor, který ukazuje na záměrně špatnou proxy:

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

Pak spusťte:

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

Pokud se Wget pokusí připojit na 127.0.0.1:3128, soubor načetl.

Nastavení proměnných proxy ve Windows

CMD (jen pro aktuální relaci):

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

PowerShell (jen pro aktuální relaci):

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

Trvale (přežije restart):

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

Po setx musíte otevřít nové okno terminálu. Současná relace změnu neuvidí.

Firemní proxy pasti: PAC soubory, NTLM autentizace a jak zjistit adresu proxy

Tři věci, které firemním uživatelům dělají problémy nejčastěji:

PAC soubory: Mnoho firem používá Proxy Auto-Configuration (PAC) soubory — skripty v JavaScriptu, které prohlížeči říkají, jakou proxy použít pro danou URL. Wget nemá JavaScriptový interpret, takže PAC soubory neumí číst. Totéž uvádí i dokumentace curlu. Řešení: otevřete PAC soubor (nebo se zeptejte IT), najděte výsledek PROXY host:port pro cílovou doménu a tuto statickou adresu nastavte ve Wgetu.

NTLM autentizace: Proxy autentizace ve Wgetu implementuje jen Basic auth. Pokud vaše firemní proxy vyžaduje NTLM a dostáváte 407 Proxy Authentication Required, neztrácejte čas zkoušením různých variant --proxy-user. Nainstalujte Cntlm — lokální relé, které obslouží NTLM/NTLMv2 autentizaci a Wgetu předloží rozhraní s Basic autentizací. Cntlm je stále udržovaný (poslední aktualizace říjen 2025, přibližně 395 stažení týdně).

Rozhodovací strom pro uživatele firemní proxy:

Zkuste set http_proxy=http://YOUR_PROXY:PORT/ a spusťte Wget.
Pokud dostanete chybu 407 a firma používá NTLM → nainstalujte Cntlm, nastavte ho firemními přihlašovacími údaji a ve Wgetu použijte lokální port Cntlm (typicky http://127.0.0.1:3128/).
Pokud firma používá PAC soubor → vytáhněte z PAC souboru skutečnou hodnotu PROXY host:port, nebo si vyžádejte statickou adresu proxy od IT.

Běžné firemní porty proxy: 3128 (styl Squid), 8080 (obecná HTTP proxy), 8888 (debugovací proxy jako Fiddler/Charles). Jsou to zvyklosti, ne záruky.

Běžné problémy při použití Wgetu s proxy (s reálným výstupem chyb)

A teď část, na kterou odkazuje i titulek. Veškerý níže uvedený výstup byl reprodukován na Wgetu 1.25.0 (macOS, Homebrew) dne 2026-06-01.

Past 1: Chybějící prefix http://

Některé starší návody tvrdí, že tohle vždycky rozbije fungování. Ve Wgetu 1.25.0 ale nastavení http_proxy=127.0.0.1:3128 skutečně funguje — Wget tiše doplní 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.

Přesto se připojil ke správné proxy. I tak ale doporučuji vždy uvádět prefix http:// a na konci lomítko. Vyhnete se nejednoznačnosti napříč verzemi Wgetu a zápis přihlašovacích údajů (http://user:pass@host:port/) bude jednoznačný.

Past 2: use_proxy=yes vs. use_proxy=on

V mých testech Wgetu 1.25.0 fungovalo obojí, yes i on. Neplatné hodnoty ale selžou s jasnou chybou:

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

Používejte on kvůli nejširší kompatibilitě — odpovídá dokumentovanému formátu booleanu v manuálu i samotné nápovědě v chybové hlášce Wgetu.

Past 3: Velké HTTP_PROXY se tiše ignoruje

Tohle je nejotravnější problém, protože neexistuje žádná chyba. Wget se prostě připojí přímo, jako by žádná proxy nastavena nebyla.

Velká písmena (špatně — proxy se nepoužila):

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

Malá písmena (správně — proxy se zkusila použít):

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.

Vidíte ten rozdíl? Verze s velkými písmeny vyřešila example.com přímo. Verze s malými písmeny se pokusila použít proxy. V obou případech žádné varování. Curl má podobnou zvláštnost — většinu proxy proměnných přijímá i ve velkých písmenech, ale HTTP_PROXY z bezpečnostních důvodů výslovně odmítá.

Oprava: Vždy používejte malé http_proxy a https_proxy.

Past 4: Zastaralá proxy v .wgetrc způsobuje „Connection refused“

Pokud jste vy (nebo správce, nebo Docker image) nechali v konfiguračním souboru starou adresu proxy, uvidíte něco takového:

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.

Chyba ukazuje na starou IP proxy, ne na cílový web. Postup diagnostiky (podle hierarchie priority):

Zkontrolujte příkaz, jestli neobsahuje příznaky -e nebo shell aliasy
Zkontrolujte ~/.wgetrc (nebo soubor určený proměnnou WGETRC)
Zkontrolujte systémovou konfiguraci (cestu uvedenou ve wget --version)
Zkontrolujte prostředí: env | grep -i proxy

Při ladění je váš nejlepší přítel --no-config — řekne Wgetu, aby přeskočil všechny konfigurační soubory:

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

Pokud to funguje, problém je v konfiguračním souboru.

Past 5: Zmatek kolem syntaxe HTTPS proxy

Tohle mate spoustu lidí. Když nastavujete https_proxy, samotná adresa proxy bývá obvykle http://, ne https://. Je to proto, že Wget posílá přes proxy HTTP CONNECT požadavek, aby vytvořil tunel pro šifrovanou HTTPS relaci.

Správně:

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

Wget pošle proxy požadavek CONNECT example.com:443 HTTP/1.1 a pak přes něj tuneluje HTTPS.

Špatně (pro HTTP cíle s HTTPS endpointem proxy):

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 https:// jako URL proxy pro HTTP cíle rovnou odmítne. Používejte https_proxy=http://HOST:PORT/, pokud vaše organizace výslovně nedokumentuje HTTPS endpoint proxy a vy jste ho otestovali se svou verzí Wgetu.

Tahák příkazů pro proxy ve Wgetu (rychlá referenční tabulka)

Uložte si tuhle tabulku. Shrnuje všechny příznaky a direktivy Wgetu související s proxy na jednom místě.

Příznak / direktiva	Kontext	Příklad	Poznámky
`-e use_proxy=on`	CLI	`-e use_proxy=on`	`on` je nejbezpečnější; některé buildy přijímají i `yes`
`-e http_proxy=`	CLI	`-e http_proxy=http://proxy:8080/`	Vždy uvádějte prefix `http://` a koncové `/`
`-e https_proxy=`	CLI	`-e https_proxy=http://proxy:8080/`	Adresa proxy bývá `http://` i pro HTTPS cíle
`--proxy-user`	CLI	`--proxy-user=admin`	Přebíjí vložené `user:pass@`
`--proxy-password`	CLI	`--proxy-password=secret`	Viditelný v `ps` — na sdílených systémech nepoužívat
`--no-proxy`	CLI	`--no-proxy`	Obejít VŠECHNA proxy nastavení ze všech zdrojů
`--no-config`	CLI	`--no-config`	Přeskočí všechny konfigurační soubory — užitečné pro ladění
`--config=FILE`	CLI	`--config=/tmp/wgetrc`	Jednoznačná cesta ke konfiguraci — skvělé pro Windows a CI
`http_proxy`	`.wgetrc` / env	`http_proxy = http://proxy:8080/`	V konfiguračním souboru jsou kolem `=` mezery; proměnná prostředí je malými písmeny
`https_proxy`	`.wgetrc` / env	`https_proxy = http://proxy:8080/`	Stejný formát jako `http_proxy`
`ftp_proxy`	`.wgetrc` / env	`ftp_proxy = http://proxy:8080/`	Pro FTP stahování
`no_proxy`	`.wgetrc` / env	`no_proxy = localhost,127.0.0.1,.corp`	Seznam domén oddělených čárkami
`proxy_user`	`.wgetrc`	`proxy_user = admin`	Ekvivalent k `--proxy-user`
`proxy_password`	`.wgetrc`	`proxy_password = secret`	Soubor chraňte pomocí `chmod 600`

Kdy Wget + proxy není správná volba (a co použít místo toho)

Po tom všem nastavování proxy tady přichází trochu kontrariánský pohled: někdy se do toho vůbec nevyplatí pouštět.

Hodně lidí, kteří hledají „wget proxy“, ve skutečnosti nechce stahovat jeden soubor. Chtějí sbírat strukturovaná data z webů — ceny produktů, seznamy kontaktů, nabídky nemovitostí — a sáhli po Wgetu jen proto, že ho znají z příkazové řádky. Problém je, že Wget vám vrátí syrové HTML. To je pak ještě potřeba parsovat, čistit a strukturovat. A pokud navíc rotujete proxy, abyste se vyhnuli blokaci, spravujete zároveň seznam proxy, download skript, parser i exportní pipeline.

Váš cíl	Nejlepší nástroj	Proč
Stáhnout jeden soubor přes proxy	`wget` s proxy příznaky	Jednoduché, jeden příkaz
Zrcadlit web nebo adresář přes proxy	`wget --recursive` + konfigurace proxy	Rekurzivní stahování je silná stránka Wgetu
Sbírat strukturovaná data (tabulky, nabídky, kontakty)	Thunderbit	Wget dá jen surové HTML — pořád ho musíte zpracovat. Thunderbit pomocí AI přečte stránku a bez kódu vyexportuje strukturovaná data do Excelu, Google Sheets, Airtable nebo Notion. Cloud scraping navíc řeší rotaci IP i anti-bot ochrany, takže proxy nastavovat nemusíte vůbec.
Volání REST API přes proxy	`curl`	Lepší kontrola hlaviček, nativní podpora JSON, podpora SOCKS5
Průběžné plánované sbírání dat	Thunderbit Scheduled Scraper nebo `cron` + wget	Thunderbit se přizpůsobí změnám rozložení stránky; skripty s cron + wget často selžou tiše

Wget je skvělý na stahování souborů. Jenže workflow typu „nastavit proxy → rotovat IP → stáhnout HTML → napsat parser → exportovat do tabulky“ má spoustu pohyblivých částí, pokud ve skutečnosti chcete jen tabulku dat. Pokud vám to zní povědomě, náš Chrome rozšíření zvládne celý proces na dvě kliknutí. Více k tomu najdete v našich průvodcích AI web scrapingem a scrapingem bez programování.

Ale pokud je vaším cílem „stáhnout tenhle ZIP soubor přes firemní proxy“, Wget je pořád správný nástroj — a teď už víte, jak ho nastavit správně.

Hlavní závěry

Krátká verze:

Čtyři metody, jasná priorita: CLI příznaky přebíjejí uživatelskou konfiguraci, ta přebíjí systémovou konfiguraci a ta přebíjí proměnné prostředí. --no-proxy přebije všechno.
V proměnných prostředí vždy používejte malá písmena (http_proxy, ne HTTP_PROXY). Velká písmena se tiše ignorují.
Do URL proxy vždy uvádějte http://, a to i pro https_proxy. Endpoint proxy je HTTP; HTTPS se tuneluje přes CONNECT.
Pro booleovské hodnoty používejte on v .wgetrc i u příznaků -e. Je to nejbezpečnější volba napříč verzemi Wgetu.
Uživatelé Windows: používejte --config=C:\cesta\k\wgetrc, abyste se vyhnuli nejednoznačnosti v hledání konfigurace. Pro proxy proměnné relace používejte set v CMD nebo $env: v PowerShellu.
Uživatelé firemních proxy: Wget neumí číst PAC soubory a nativně nepodporuje NTLM autentizaci. Pokud je to potřeba, použijte jako lokální relé Cntlm.
Záložkujte si tahák výše — ušetří vám to opakované pročítání článku pokaždé, když si nebudete pamatovat název nějakého příznaku.

Pokud je vaším skutečným cílem získávání strukturovaných dat, Thunderbit nebo curl mohou být lepší volba. Nejlepší ladění je to, které nemusíte vůbec spouštět.

Často kladené otázky

1. Podporuje Wget proxy SOCKS5?

Ne. GNU Wget 1.x podporuje jen HTTP, HTTPS a FTP proxy. Projekt Wget2 měl požadavek na SOCKS5, ale nejde o standardní zdokumentovanou volbu. Pro SOCKS5 použijte curl s nativními schématy socks5:// nebo socks5h://, případně obalte Wget pomocí proxychains4, aby byl provoz směrován přes SOCKS.

2. Proč se moje nastavení proxy ignoruje, když používám velké HTTP_PROXY?

Wget čte proměnné prostředí jen v malých písmenech (http_proxy, https_proxy, ftp_proxy, no_proxy). Varianty s velkými písmeny jako HTTP_PROXY se tiše ignorují — bez chyby a bez varování. To je jeden z nejběžnějších a nejotravnějších problémů, protože nic nenasvědčuje tomu, že je něco špatně. Vždy používejte malá písmena.

3. Jak obejdu proxy pro konkrétní domény?

Použijte direktivu no_proxy, buď jako proměnnou prostředí, nebo v .wgetrc:

export no_proxy=localhost,127.0.0.1,.mycompany.com

Nebo v ~/.wgetrc:

no_proxy = localhost,127.0.0.1,.mycompany.com

Domény se oddělují čárkami. Úvodní tečka (.mycompany.com) odpovídá všem subdoménám.

4. Můžu používat Wget s rotujícími proxy?

Wget sám o sobě nemá vestavěnou rotaci proxy. Máte dvě možnosti: použít poskytovatele proxy, který rotuje IP na serverové straně (takže pořád oslovujete stejnou gateway adresu, ale výstupní IP se mění), nebo napsat shell skript, který náhodně vybere proxy ze seznamu a při každém spuštění ji předá přes -e http_proxy=.... Pro cokoli složitějšího — automatickou rotaci, retry logiku, anti-bot ochranu — je obvykle lepší specializovaný nástroj na scraping.

5. Jaký je rozdíl mezi http_proxy a https_proxy ve Wgetu?

http_proxy se použije, když cílová URL začíná http://. https_proxy se použije, když cílová URL začíná https://. V obou případech je samotná URL proxy obvykle adresa http://. U HTTPS cílů Wget přes proxy odešle HTTP CONNECT požadavek, aby vytvořil tunel, a samotné HTTPS šifrování pak probíhá end-to-end mezi Wgetem a cílovým serverem. Proxy uvidí hostname (z CONNECT požadavku), ale neobsahuje možnost číst šifrovaný provoz.

Vyzkoušejte Thunderbit pro AI web scraping Get Started Free

Zjistěte více