Konfiguracja proxy w Wget wygląda jak robota na pięć sekund — dopóki nie spędzisz całej godziny na zastanawianiu się, dlaczego żądania kompletnie omijają proxy, a na ekranie nie widać żadnego błędu. Widziałem to zarówno u doświadczonych administratorów, jak i u początkujących programistów.
Prawdziwy problem prawie nigdy nie leży w samym proxy. To cztery różne miejsca, z których Wget może wczytać ustawienia proxy, ciche porażki związane z użyciem złej wielkości liter w zmiennych oraz specyfika sieci korporacyjnych, której nikt nie opisuje w man page. Ten poradnik pokazuje wszystkie sposoby konfiguracji Wget z proxy, dokładne zasady priorytetów, gdy kilka metod się wyklucza, rzeczywiste komunikaty terminala dla najczęstszych błędów oraz osobną sekcję dla użytkowników Windows i sieci firmowych — czyli dla tej grupy, którą niemal każdy inny artykuł udaje, że nie istnieje.
- Poziom trudności: początkujący do średnio zaawansowanego
- Szacowany czas: około 15 minut na przeczytanie i konfigurację; około 2 minut, gdy już wiesz, co robisz
- Czego potrzebujesz: działającej instalacji Wget (instrukcje poniżej), adresu proxy (host + port) i opcjonalnie danych logowania do proxy
Wypróbuj Thunderbit do ekstrakcji ustrukturyzowanych danych
Czym jest Wget i dlaczego warto używać go z proxy?
Wget to narzędzie wiersza poleceń, które pobiera pliki i strony internetowe z sieci bez użycia przeglądarki. Oficjalna dokumentacja GNU określa je jako „nieinteraktywny downloader sieciowy” — czyli działa w tle, wznawia przerwane transfery i obsługuje pobieranie rekurencyjne bez potrzeby klikania czegokolwiek przez człowieka.
Proxy w tym kontekście to pośrednik. Zamiast łączyć się bezpośrednio z docelową witryną, Wget wysyła żądanie do proxy, a ono przekazuje je dalej. Najczęstsze powody, dla których się z tego korzysta, to:
- Zgodność z zaporą korporacyjną — firma wymaga, aby cały ruch wychodzący przechodził przez zatwierdzone proxy
- Prywatność i zarządzanie adresem IP — żądania wyglądają tak, jakby pochodziły z IP proxy, a nie z Twojego
- Testy geolokalizacyjne — pobieranie zasobów z ograniczeniami regionalnymi lub testowanie zachowania CDN z określonej lokalizacji
- Potoki zbierania danych — pobieranie HTML przez rotujące proxy do badań lub monitoringu
- Środowiska CI/CD — środowiska buildów w zamkniętych sieciach, które mogą wychodzić do internetu wyłącznie przez proxy
Wget natywnie obsługuje proxy HTTP, HTTPS i FTP. Nie obsługuje SOCKS5. Jeśli potrzebujesz SOCKS5, curl ma natywne wsparcie dla schematów socks4://, socks5:// i socks5h:// — albo możesz opakować Wget narzędziem takim jak proxychains4.
Jak zainstalować Wget na Linuxie, macOS i Windows
Zanim skonfigurujesz proxy, musisz mieć Wget na swoim komputerze. Ta sekcja jest krótka — to tylko warunek wstępny, nie główny temat.
Linux (Debian/Ubuntu i RHEL/CentOS)
# Debian/Ubuntu
sudo apt update
sudo apt install wget
# RHEL/CentOS/Fedora
sudo dnf install wget
# Weryfikacja
wget --version
Ubuntu 24.04 LTS zawiera Wget 1.21.4, a Debian Trixie ma 1.25.0. Pakiety CentOS Stream 10 pokazują 1.24.5.
macOS (Homebrew)
brew install wget
wget --version
Formuła Homebrew dostarcza obecnie stabilny Wget 1.25.0, z 396 818 instalacjami w ciągu ostatniego roku.
Windows (Chocolatey i instalacja ręczna)
choco install wget
wget --version
Pakiet GNU Wget w Chocolatey ma ponad 10 milionów pobrań łącznie, choć obecnie jest na wersji 1.21.4. Plik binarny zwykle trafia do C:\ProgramData\chocolatey\bin\wget.exe.
Jedna ważna uwaga dla użytkowników Windows: to, gdzie Wget szuka pliku .wgetrc, zależy od kompilacji. Szczegóły znajdziesz w sekcji o Windows poniżej.
4 sposoby używania Wget z proxy i który wybrać
Cztery metody, każda z innym zakresem działania i poziomem priorytetu:
- Flagi wiersza poleceń
-e— jednorazowo, dla pojedynczego polecenia - Plik konfiguracyjny użytkownika (
~/.wgetrc) — działa dla każdego polecenia Wget uruchamianego przez tego użytkownika - Plik konfiguracyjny systemowy (
/etc/wgetrc) — działa dla wszystkich użytkowników na danym komputerze - Zmienne środowiskowe (
http_proxy,https_proxy) — działają w całej sesji powłoki
Metoda 1: Flagi wiersza poleceń (jednorazowe proxy)
Najlepsze do szybkich testów. Ustawienia znikają po zakończeniu polecenia.
wget -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://example.com/file.zip
Dla zasobów HTTPS:
wget -e use_proxy=on -e https_proxy=http://HOST:PORT/ https://example.com/
Szybki test kontrolny — pobierz swój widoczny adres IP przez proxy:
wget -qO- -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://ifconfig.me
Jeśli wynik pokazuje adres IP proxy zamiast Twojego, wszystko działa.
Metoda 2: Plik konfiguracyjny użytkownika (~/.wgetrc)
Dodaj te linie do ~/.wgetrc (utwórz plik, jeśli nie istnieje):
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
Zwróć uwagę na spacje wokół = — to udokumentowana składnia .wgetrc. Każde polecenie Wget uruchamiane przez tego użytkownika będzie teraz przechodzić przez proxy.
Metoda 3: Konfiguracja systemowa (/etc/wgetrc)
Te same dyrektywy co w ~/.wgetrc, ale zapisane w pliku systemowym. GNU opisuje to jako globalny plik startowy — dokładna ścieżka zależy od miejsca instalacji. Najczęstsze lokalizacje to:
/etc/wgetrc(większość menedżerów pakietów Linux)/usr/local/etc/wgetrc(niektóre kompilacje Homebrew)- Ścieżka widoczna w wyniku
wget --versionpod nagłówkiem „Wgetrc:”
To przydatne na współdzielonych serwerach, w kontenerach Dockera lub w każdym środowisku, gdzie wszyscy użytkownicy powinni korzystać z tego samego proxy.
Metoda 4: Zmienne środowiskowe (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
Wpływają one na całą sesję powłoki — nie tylko na Wget. Narzędzia takie jak curl również je odczytają.
Krytyczna uwaga: Wget odczytuje tylko małe litery w nazwach zmiennych środowiskowych. HTTP_PROXY (wielkimi literami) jest po cichu ignorowane. Bez błędu, bez ostrzeżenia, bez niczego. W sekcji z pułapkami pokażę dokładny output terminala, ale warto zapamiętać to już teraz.
Priorytet metod proxy: co nadpisuje co, gdy ustawiono kilka metod naraz
Jeśli masz proxy ustawione w zmiennych środowiskowych i w .wgetrc i w wierszu poleceń, co wygrywa? Nikt nie tłumaczy tego jasno, więc to przetestowałem.
Oto przetestowana i udokumentowana kolejność priorytetów:
| Priorytet | Metoda | Zakres | Nadpisuje |
|---|---|---|---|
| 1 (najwyższy) | flagi CLI -e | Pojedyncze polecenie | Wszystko |
| 2 | ~/.wgetrc | Bieżący użytkownik | Konfigurację systemową + zmienne środowiskowe |
| 3 | /etc/wgetrc | Cały system | Tylko zmienne środowiskowe |
| 4 (najniższy) | zmienne środowiskowe http_proxy / https_proxy | Sesja powłoki | Nic |
Potwierdziłem to na Wget 1.25.0, ustawiając sprzeczne proxy na każdym poziomie. Gdy środowisko wskazywało port 3128, plik konfiguracyjny 3129, a CLI 3130:
- Konfiguracja wygrywa ze środowiskiem: Wget połączył się z portem 3129, ignorując 3128.
- CLI wygrywa z konfiguracją: Wget połączył się z portem 3130, ignorując zarówno 3129, jak i 3128.
Wyjściem awaryjnym jest --no-proxy. Omija ono wszystkie ustawienia proxy, niezależnie od tego, gdzie zostały skonfigurowane:
wget --no-proxy https://internal-server.company.com/report.pdf
Praktyczny scenariusz: administrator ustawił proxy w /etc/wgetrc, ale Ty musisz bezpośrednio połączyć się z wewnętrznym serwerem. Użyj --no-proxy tylko dla tego jednego polecenia zamiast edytować konfigurację systemową.
Jak używać Wget z uwierzytelnianym proxy
Większość proxy biznesowych i domowych wymaga nazwy użytkownika i hasła. Wget obsługuje to na dwa sposoby, oba wykorzystujące uwierzytelnianie HTTP Basic dla danych proxy.
Dane logowania wpisane bezpośrednio w URL proxy
wget -e use_proxy=on \
-e http_proxy=http://USERNAME:PASSWORD@proxy.company.com:8080/ \
http://example.com/file.zip
To działa również w .wgetrc:
http_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
https_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
Użycie flag --proxy-user i --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
Te flagi nadpisują każde user:pass@ zapisane w URL proxy.
Jak bezpiecznie przechowywać dane logowania
Obie metody mogą ujawnić hasła. GNU ostrzega, że hasła podane w wierszu poleceń są widoczne przez ps i podobne narzędzia do listowania procesów. Ograniczenia ryzyka:
- Jednoużytkownikowe komputery: przechowuj dane w
~/.wgetrci zablokuj plik:chmod 600 ~/.wgetrc - Potoki CI/CD: użyj zaszyfrowanych sekretów GitHub Actions lub odpowiednika w swojej platformie. Przekazuj je jako małe litery w definicji kroku — nigdy nie wpisuj ich na sztywno w YAML.
- Budowanie obrazów Dockera: nie używaj
ARGaniENVdo sekretów. Dokumentacja Dockera wyraźnie ostrzega, że argumenty builda mogą zostać w końcowym obrazie. Zamiast tego używaj mountów sekretów BuildKit. - Kontrola wersji: nigdy nie commituj
.wgetrcz hasłami. Dodaj go do.gitignore.
Jedna ważna niuansowa rzecz w GitHub Actions: nazwy sekretów są zwyczajowo zapisywane wielkimi literami, ale zmienne środowiskowe, które przekazujesz do Wget, muszą być małe (http_proxy, a nie HTTP_PROXY).
Jak używać Wget z proxy na Windows i za korporacyjnymi firewallami
Większość artykułów na ten temat kończy się na „zainstaluj przez Chocolatey”. Jeśli pracujesz na Windowsie albo za firmowym proxy, to właśnie tam zaczynają się problemy.
Gdzie Windows szuka pliku .wgetrc
Dokumentacja GNU mówi, że Wget czyta $HOME/.wgetrc, chyba że zmienna WGETRC wskazuje gdzie indziej. Na Windows $HOME może mapować się do %USERPROFILE% (np. C:\Users\alice), ale nie musi — zależnie od tego, czy używasz kompilacji Chocolatey, MSYS2, Git Bash czy samodzielnego binarium.
Moja rekomendacja: nie zgadywać i użyć flagi --config, żeby zachowanie było deterministyczne:
wget --config=C:\Users\alice\wgetrc https://example.com/file.zip
Aby sprawdzić, czy Twoja kompilacja czyta plik konfiguracyjny z określonej lokalizacji, utwórz plik testowy wskazujący na znane, błędne proxy:
; C:\Users\alice\wget-test.rc
use_proxy = on
http_proxy = http://127.0.0.1:3128/
Następnie uruchom:
wget --config=C:\Users\alice\wget-test.rc --spider http://example.com/
Jeśli Wget spróbuje połączyć się z 127.0.0.1:3128, to znaczy, że odczytał plik.
Ustawianie zmiennych proxy na Windows
CMD (tylko bieżąca sesja):
set http_proxy=http://HOST:PORT/
set https_proxy=http://HOST:PORT/
wget http://example.com/
PowerShell (tylko bieżąca sesja):
$env:http_proxy = "http://HOST:PORT/"
$env:https_proxy = "http://HOST:PORT/"
wget http://example.com/
Na stałe (przetrwa restart):
setx http_proxy http://HOST:PORT/
setx https_proxy http://HOST:PORT/
Po setx musisz otworzyć nowe okno terminala. Bieżąca sesja nie zobaczy zmiany.
Pułapki proxy w firmie: pliki PAC, uwierzytelnianie NTLM i znalezienie adresu proxy
Trzy rzeczy, które najczęściej wywracają użytkowników korporacyjnych:
Pliki PAC: wiele firm używa Proxy Auto-Configuration (PAC) — skryptów opartych na JavaScript, które mówią przeglądarce, jakiego proxy użyć dla konkretnego URL. Wget nie ma interpretera JavaScript, więc nie potrafi czytać plików PAC. Dokumentacja curl mówi to samo. Rozwiązanie: otwórz plik PAC (albo zapytaj IT), znajdź wynik PROXY host:port dla docelowej domeny i wpisz ten statyczny adres do Wget.
Uwierzytelnianie NTLM: uwierzytelnianie proxy w Wget obsługuje tylko Basic auth. Jeśli firmowe proxy wymaga NTLM i widzisz 407 Proxy Authentication Required, nie trać czasu na kombinowanie z różnymi wariantami --proxy-user. Zainstaluj Cntlm — lokalny relay, który obsługuje uwierzytelnianie NTLM/NTLMv2 i wystawia Wget interfejs Basic auth. Cntlm jest nadal utrzymywany (ostatnia aktualizacja: październik 2025, około 395 pobrań tygodniowo).
Drzewo decyzyjne dla użytkowników proxy w firmie:
- Spróbuj
set http_proxy=http://YOUR_PROXY:PORT/i uruchom Wget. - Jeśli pojawi się błąd
407, a firma używa NTLM → zainstaluj Cntlm, skonfiguruj go danymi domenowymi i wskaż Wget na lokalny port Cntlm (zwyklehttp://127.0.0.1:3128/). - Jeśli firma korzysta z pliku PAC → wyciągnij rzeczywisty
PROXY host:portz pliku PAC albo poproś IT o statyczny adres proxy.
Najczęstsze porty proxy w firmach: 3128 (styl Squid), 8080 (ogólne proxy HTTP), 8888 (proxy do debugowania, np. Fiddler/Charles). To są konwencje, nie gwarancje.
Najczęstsze pułapki przy używaniu Wget z proxy (z rzeczywistym outputem błędów)
Teraz czas na to, co obiecał tytuł. Każdy poniższy komunikat został odtworzony na Wget 1.25.0 (macOS, Homebrew) w dniu 2026-06-01.
Pułapka 1: Brak prefiksu http://
Niektóre starsze poradniki twierdzą, że to zawsze psuje konfigurację. W Wget 1.25.0 ustawienie http_proxy=127.0.0.1:3128 faktycznie działa — Wget po cichu dodaje 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.
Połączenie i tak zostało skierowane do właściwego proxy. Mimo to zalecam zawsze podawanie prefiksu http:// i końcowego ukośnika /. Eliminuje to niejednoznaczności między wersjami Wget i sprawia, że składnia z danymi logowania (http://user:pass@host:port/) jest jednoznaczna.
Pułapka 2: use_proxy=yes vs. use_proxy=on
W moich testach na Wget 1.25.0 działały zarówno yes, jak i on. Ale nieprawidłowe wartości kończą się jasnym błędem:
wget: use_proxy: Invalid boolean 'true'; use `on' or `off'.
Używaj on, bo zapewnia najszerszą zgodność — pasuje do udokumentowanego formatu boolean w manualu i do podpowiedzi samego Wget.
Pułapka 3: Wielkimi literami HTTP_PROXY jest po cichu ignorowane
To najbardziej frustrująca pułapka, bo nie ma żadnego błędu. Wget po prostu łączy się bezpośrednio, tak jakby proxy w ogóle nie było ustawione.
Wersja wielkimi literami (błędna — proxy nieużyte):
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
Wersja małymi literami (działa — próba użycia 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.
Widzisz różnicę? Wersja wielkimi literami rozwiązała example.com bezpośrednio. Wersja małymi literami próbowała użyć proxy. W żadnym przypadku nie ma ostrzeżenia. curl ma podobną osobliwość — akceptuje wielkie litery dla większości zmiennych proxy, ale jawnie odrzuca HTTP_PROXY ze względów bezpieczeństwa.
Naprawa: zawsze używaj małych liter http_proxy i https_proxy.
Pułapka 4: Stare proxy w .wgetrc powodujące „Connection Refused”
Jeśli Ty (albo administrator, albo obraz Dockera) zostawił stary adres proxy w pliku konfiguracyjnym, zobaczysz coś takiego:
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.
Błąd wskazuje na stary adres proxy, a nie na stronę docelową. Kolejność diagnozowania zgodnie z hierarchią priorytetów:
- Sprawdź polecenie pod kątem flag
-elub aliasów powłoki - Sprawdź
~/.wgetrc(lub plik wskazany przezWGETRC) - Sprawdź konfigurację systemową (ścieżka pokazana przez
wget --version) - Sprawdź środowisko:
env | grep -i proxy
Do debugowania przydaje się --no-config — mówi Wget, aby pominął wszystkie pliki konfiguracyjne:
wget --no-config --spider http://example.com/
Jeśli to działa, problem leży w pliku konfiguracyjnym.
Pułapka 5: Zamieszanie wokół składni HTTPS proxy
To myli bardzo wiele osób. Gdy ustawiasz https_proxy, sam adres proxy zwykle zaczyna się od http://, a nie https://. Dzieje się tak, ponieważ Wget wysyła przez proxy żądanie HTTP CONNECT, tworząc tunel dla szyfrowanej sesji HTTPS.
Poprawnie:
https_proxy=http://proxy.company.com:8080/
wget https://example.com/
Wget wysyła do proxy CONNECT example.com:443 HTTP/1.1, a następnie tuneluje przez nie ruch HTTPS.
Niepoprawnie (dla adresów HTTP z 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 odrzuca https:// jako URL proxy dla zasobów HTTP. Używaj https_proxy=http://HOST:PORT/, chyba że Twoja organizacja wyraźnie dokumentuje HTTPS endpoint proxy i przetestowałeś go ze swoją wersją Wget.
Ściągawka poleceń proxy dla Wget
Dodaj tę tabelę do zakładek. Zbiera w jednym miejscu wszystkie flagi i dyrektywy konfiguracji związane z proxy w Wget.
| Flaga / dyrektywa | Kontekst | Przykład | Uwagi |
|---|---|---|---|
-e use_proxy=on | CLI | -e use_proxy=on | on jest najbezpieczniejsze; niektóre kompilacje akceptują też yes |
-e http_proxy= | CLI | -e http_proxy=http://proxy:8080/ | Uwzględnij prefiks http:// i końcowy / |
-e https_proxy= | CLI | -e https_proxy=http://proxy:8080/ | Adres proxy zwykle zaczyna się od http://, nawet dla HTTPS |
--proxy-user | CLI | --proxy-user=admin | Nadpisuje wpisane w URL user:pass@ |
--proxy-password | CLI | --proxy-password=secret | Widoczne w ps — unikaj na współdzielonych systemach |
--no-proxy | CLI | --no-proxy | Omija WSZYSTKIE ustawienia proxy ze wszystkich źródeł |
--no-config | CLI | --no-config | Pomija wszystkie pliki konfiguracyjne — przydatne do debugowania |
--config=FILE | CLI | --config=/tmp/wgetrc | Deterministyczna ścieżka konfiguracji — świetna dla Windows i CI |
http_proxy | .wgetrc / env | http_proxy = http://proxy:8080/ | W pliku konfiguracyjnym są spacje wokół =; w zmiennej środowiskowej używaj małych liter |
https_proxy | .wgetrc / env | https_proxy = http://proxy:8080/ | Taki sam format jak http_proxy |
ftp_proxy | .wgetrc / env | ftp_proxy = http://proxy:8080/ | Dla pobrań FTP |
no_proxy | .wgetrc / env | no_proxy = localhost,127.0.0.1,.corp | Lista domen rozdzielona przecinkami |
proxy_user | .wgetrc | proxy_user = admin | Odpowiednik --proxy-user |
proxy_password | .wgetrc | proxy_password = secret | Zabezpiecz plik poleceniem chmod 600 |
Kiedy Wget + proxy to nie jest najlepsze narzędzie i co wybrać zamiast tego
Po całej tej konfiguracji proxy, oto nieco przewrotny wniosek: czasem po prostu nie warto.
Wiele osób szukających „wget proxy” tak naprawdę nie chce pobrać jednego pliku. Chcą zebrać ustrukturyzowane dane ze stron internetowych — ceny produktów, listy kontaktów, ogłoszenia nieruchomości — i używają Wget tylko dlatego, że to znane im narzędzie wiersza poleceń. Problem w tym, że Wget daje surowy HTML. Nadal trzeba go sparsować, oczyścić i ułożyć w strukturę. A jeśli rotujesz proxy, żeby uniknąć blokad, to w praktyce utrzymujesz listę proxy, skrypt pobierający, parser i pipeline eksportu.
| Twój cel | Najlepsze narzędzie | Dlaczego |
|---|---|---|
| Pobranie jednego pliku przez proxy | wget z flagami proxy | Prosto, jednym poleceniem |
| Mirror witryny lub katalogu przez proxy | wget --recursive + konfiguracja proxy | Rekurencyjne pobieranie to jedna z największych zalet Wget |
| Zbieranie ustrukturyzowanych danych (tabele, ogłoszenia, kontakty) | Thunderbit | Wget daje surowy HTML — nadal trzeba go przetworzyć. Thunderbit dzięki AI czyta stronę i eksportuje dane strukturalne do Excel, Google Sheets, Airtable lub Notion bez kodowania. Jego scraping w chmurze obsługuje rotację IP i zabezpieczenia antybotowe, więc omijasz konfigurację proxy całkowicie. |
| Wywołania REST API przez proxy | curl | Lepsza kontrola nagłówków, natywna obsługa JSON, wsparcie SOCKS5 |
| Ciągłe, zaplanowane zbieranie danych | Thunderbit Scheduled Scraper lub cron + wget | Thunderbit dostosowuje się, gdy zmienia się układ strony; skrypty cron + wget często psują się bez ostrzeżenia |
Wget świetnie radzi sobie z pobieraniem plików. Ale proces „skonfiguruj proxy → rotuj IP → pobierz HTML → napisz parser → wyeksportuj do arkusza” to sporo ruchomych elementów, jeśli tak naprawdę potrzebujesz po prostu tabeli danych. Jeśli brzmi to jak Twoja sytuacja, nasze rozszerzenie Chrome ogarnia cały proces w dwóch kliknięciach. Więcej na ten temat znajdziesz w naszych poradnikach o web scrapingu z AI i scrapingu stron bez kodowania.
Ale jeśli Twoim celem jest „pobierz ten plik ZIP przez firmowe proxy” — Wget nadal jest właściwym narzędziem, a teraz wiesz już, jak skonfigurować je poprawnie.
Najważniejsze wnioski
Krótka wersja:
- Cztery metody, jasny priorytet: flagi CLI nadpisują konfigurację użytkownika, ta nadpisuje konfigurację systemową, a ta nadpisuje zmienne środowiskowe.
--no-proxynadpisuje wszystko. - Zawsze używaj małych liter w zmiennych środowiskowych (
http_proxy, nieHTTP_PROXY). Wielkie litery są po cichu ignorowane. - Zawsze dodawaj
http://do URL proxy, nawet dlahttps_proxy. Endpoint proxy jest HTTP; HTTPS jest tunelowane przez CONNECT. - Dla wartości logicznych używaj
onw.wgetrci flagach-e. To najbezpieczniejszy wybór między wersjami Wget. - Użytkownicy Windows: użyj
--config=C:\ścieżka\do\wgetrc, aby uniknąć niejednoznaczności pliku konfiguracyjnego. Do zmiennych proxy w sesji używajset(CMD) lub$env:(PowerShell). - Użytkownicy proxy firmowego: Wget nie czyta plików PAC i nie obsługuje natywnie NTLM. W razie potrzeby użyj Cntlm jako lokalnego relay.
- Dodaj ściągawkę do zakładek — oszczędzi Ci ponownego czytania całego artykułu za każdym razem, gdy zapomnisz nazwy flagi.
Jeśli Twoim rzeczywistym celem jest ekstrakcja ustrukturyzowanych danych, Thunderbit lub curl mogą być lepszym wyborem. Najlepsza sesja debugowania to taka, której nigdy nie musisz zaczynać.
FAQ
1. Czy Wget obsługuje proxy SOCKS5?
Nie. GNU Wget 1.x obsługuje tylko proxy HTTP, HTTPS i FTP. Projekt Wget2 miał zgłoszenia funkcji dotyczące SOCKS5, ale nie jest to standardowo udokumentowana opcja. Do SOCKS5 użyj curl z natywnymi schematami socks5:// lub socks5h://, albo opakuj Wget narzędziem proxychains4, aby wymusić ruch przez SOCKS.
2. Dlaczego moje ustawienie proxy jest ignorowane, gdy używam wielkimi literami HTTP_PROXY?
Wget odczytuje tylko małe litery w nazwach zmiennych środowiskowych (http_proxy, https_proxy, ftp_proxy, no_proxy). Warianty wielkimi literami, takie jak HTTP_PROXY, są po cichu ignorowane — bez błędu i bez ostrzeżenia. To jeden z najczęstszych i najbardziej frustrujących problemów, bo nic nie sugeruje, że coś jest nie tak. Zawsze używaj małych liter.
3. Jak ominąć proxy dla konkretnych domen?
Użyj dyrektywy no_proxy, jako zmiennej środowiskowej albo w .wgetrc:
export no_proxy=localhost,127.0.0.1,.mycompany.com
Albo w ~/.wgetrc:
no_proxy = localhost,127.0.0.1,.mycompany.com
Domeny rozdzielaj przecinkami. Kropka na początku (.mycompany.com) dopasowuje wszystkie subdomeny.
4. Czy mogę używać Wget z rotującymi proxy?
Sam Wget nie ma wbudowanej rotacji proxy. Masz dwie opcje: użyć dostawcy proxy, który rotuje IP po stronie serwera (więc zawsze łączysz się z tym samym adresem bramki, ale zmienia się IP wyjściowe), albo napisać skrypt shellowy, który losuje proxy z listy i przekazuje je przez -e http_proxy=... przy każdym uruchomieniu. Przy bardziej złożonych potrzebach — automatycznej rotacji, logice ponowień, obchodzeniu zabezpieczeń antybotowych — zwykle lepiej sprawdza się dedykowane narzędzie do scrapingu.
5. Jaka jest różnica między http_proxy a https_proxy w Wget?
http_proxy jest używane, gdy docelowy URL zaczyna się od http://. https_proxy jest używane, gdy docelowy URL zaczyna się od https://. W obu przypadkach sam adres proxy zazwyczaj zaczyna się od http://. Dla celów HTTPS Wget wysyła przez proxy żądanie HTTP CONNECT, aby utworzyć tunel, a właściwe szyfrowanie HTTPS odbywa się bezpośrednio między Wget a serwerem docelowym. Proxy widzi hosta (z żądania CONNECT), ale nie może odczytać zaszyfrowanego ruchu.
Wypróbuj Thunderbit do AI web scrapingu Get Started Free
Dowiedz się więcej
