curl i wget to dwa narzędzia wiersza poleceń do pobierania danych przez HTTP, HTTPS i FTP. W skrócie: curl to uniwersalny klient HTTP do API, requestów i skryptów, domyślnie wypisuje wynik na ekran; wget to prosty downloader z rekurencją i wznawianiem, domyślnie zapisuje plik na dysk.
Co to jest curl, a co to jest wget
Oba narzędzia rozwiązują pozornie ten sam problem - „ściągnij coś z sieci z terminala" - ale wyrosły z innych potrzeb i to widać w codziennej pracy.
curl (od client URL) to para: biblioteka libcurl plus narzędzie wiersza poleceń, które z niej korzysta. Cała siła curla siedzi w tej bibliotece - to ją wpinają w siebie języki programowania, panele i aplikacje, gdy potrzebują klienta HTTP. curl mówi w kilkunastu protokołach (HTTP, HTTPS, FTP, FTPS, SFTP, SCP, SMTP, IMAP, POP3, LDAP, Telnet i dalej), potrafi transfer w obie strony - pobrać i wysłać - a wynik domyślnie kieruje na standardowe wyjście, czyli na ekran. Licencja jest permisywna, w rodzinie MIT, co ułatwia wbudowanie go w komercyjne produkty. Sam plik wykonywalny jest lekki, rzędu 180 KB (dane pakietów dystrybucji).
wget (GNU Wget) to narzędzie projektu GNU, wydane na copyleftowej licencji GNU GPL. Obsługuje węższy zestaw protokołów - w praktyce HTTP, HTTPS, FTP i FTPS - i jest pomyślany jako nieinteraktywny pobieracz plików. Domyślnie zapisuje pobraną treść do pliku, a nie na ekran, i to on rządzi tam, gdzie trzeba ściągnąć całe drzewo katalogów albo lustrzaną kopię strony. Binarka jest nieco większa, około 370 KB, bo wget nosi w sobie logikę rekurencji, jakiej w curlu nie znajdziesz.
Konkret: curl to scyzoryk do rozmowy z serwerami i API, wget to koparka do masowego ściągania plików. Oba znajdziesz na większości Linuksów - część dystrybucji ma preinstalowany jeden, część drugi, a doinstalowanie to apt install curl wget (Debian/Ubuntu) albo dnf install curl wget (Fedora/RHEL).
Tabela porownawcza curl i wget
To zależy od zadania - dlatego zamiast „który lepszy" popatrz, gdzie każde z nich ma przewagę. Poniższa tabela to rdzeń całego porównania.
| Cecha | curl | wget |
|---|---|---|
| Protokoły | kilkanaście (HTTP, HTTPS, FTP, FTPS, SFTP, SCP, SMTP, IMAP, POP3, LDAP, Telnet...) | HTTP, HTTPS, FTP, FTPS |
| Domyślne wyjście | standardowe wyjście (ekran) | zapis do pliku |
| Kierunek transferu | pobieranie i wysyłanie (upload) | głównie pobieranie |
| POST / PUT / metody HTTP | pełne wsparcie | ograniczone, --post-data |
| Rekurencyjne pobieranie / mirror | brak | tak, -r i -m |
| Wznawianie przerwanego pobierania | tak, -C - |
tak, -c |
| Podążanie za przekierowaniami | opcjonalne, -L |
domyślnie włączone |
| Nagłówki, tokeny, cookies | pełna kontrola, -H i -b |
podstawowa, --header |
| Biblioteka do wpięcia w kod | tak, libcurl |
nie |
| Praca z REST API | tak, to jego żywioł | słabo |
| Licencja | permisywna (typu MIT) | copyleft (GNU GPL) |
Sprawdź: jeśli w tabeli szukasz jednej linii decyzji - REST API i budowanie żądań to curl, masowe ściąganie plików i lustrzane kopie to wget.
Kiedy wybrac curl, a kiedy wget
Trade-off między nimi jest czytelny, gdy zejdziesz na poziom konkretnego zadania.
Wybierz curl, gdy:
- odpytujesz albo testujesz API (REST, JSON) i chcesz zobaczyć surową odpowiedź serwera,
- wysyłasz dane metodą POST albo PUT, budujesz żądanie z tokenem w nagłówku,
- debugujesz połączenie, certyfikat SSL albo przekierowania, bo flaga
-vpokazuje cały dialog z serwerem, - składasz request wewnątrz skryptu bash - curl łatwo spina się z
jqi przetwarzaniem JSON, - robisz healthcheck endpointu, czyli sprawdzasz, czy usługa odpowiada i jakim kodem HTTP.
Wybierz wget, gdy:
- ściągasz duży plik i zależy Ci na prostym wznawianiu po zerwaniu łącza,
- robisz lustrzaną kopię strony albo pobierasz rekurencyjnie całe drzewo katalogów,
- chcesz jeden krótki one-liner „pobierz i zapisz", bez dopisywania flag,
- puszczasz pobieranie w tle na serwerze flagą
-bi wracasz do niego później.
Typowy scenariusz z życia: wdrażasz aplikację na VPS, więc łączysz się przez SSH i zdalny terminal zapisuje ją do pliku o nazwie z adresu.
Zapisz pod własną nazwą:
curl -o backup.zip https://example.com/plik.zip
wget -O backup.zip https://example.com/plik.zip
Tu składnia się przecina - w curlu małe -o ustawia nazwę, a w wgecie robi to wielkie -O. Łatwo pomylić, więc warto zapamiętać oba na pamięć.
Wznów przerwane pobieranie:
curl -C - -O https://example.com/duzy-plik.iso
wget -c https://example.com/duzy-plik.iso
Podążaj za przekierowaniami:
curl -L https://example.com/pobierz
wget https://example.com/pobierz
curl domyślnie zatrzymuje się na odpowiedzi 301/302 - dopiero -L każe mu iść za przekierowaniem. wget robi to od razu, bez dodatkowej flagi.
Dodaj nagłówek z tokenem autoryzacji:
curl -H "Authorization: Bearer TOKEN" https://api.example.com/dane
wget --header="Authorization: Bearer TOKEN" https://api.example.com/dane
Wyślij żądanie POST z danymi:
curl -X POST -d "user=marcin&akcja=login" https://api.example.com/login
To domena curla - do rozmowy z REST API, wysyłania formularzy i JSON-a wget nadaje się słabo. Podobnie sprawdzenie samych nagłówków odpowiedzi to curl -I https://example.com.
Zrób lustrzaną kopię katalogu (tylko wget):
wget -r -np -k https://example.com/dokumentacja/
-r włącza rekurencję, -np (no-parent) trzyma pobieranie w obrębie wskazanego katalogu, a -k przerabia linki tak, by kopia działała lokalnie. Tego curl nie zrobi jednym poleceniem - i to jest główny powód, dla którego wget wciąż żyje na dyskach adminów.
Czeste bledy i pulapki
- curl bez
-O/-o„nic nie pobiera" - najczęstsze zaskoczenie początkujących. Treść leci na ekran, bo taki jest domyśl curla. Dodaj-O, żeby zapisać plik. - Pusty albo za mały plik z curla - zwykle brak
-L. Serwer odpowiedział przekierowaniem 301/302, a curl bez tej flagi go nie śledzi i zapisuje pustą odpowiedź. - Ślepe
curl ... | bash- wygodne, ale ryzykowne: wykonujesz kod, którego nie widziałeś. Na produkcji zawsze najpierw ściągnij skrypt do pliku i przejrzyj go. - Błąd certyfikatu
curl: (60)- curl nie ufa certyfikatowi serwera (wygasły, samopodpisany, niekompletny łańcuch). Poprawnym rozwiązaniem jest wskazanie właściwego CA przez--cacert, a nie zagłuszanie problemu flagą-k/--insecure- ta wyłącza weryfikację i otwiera drogę atakowi typu man-in-the-middle. Jeśli walczysz z SSL po stronie serwera, zacznij od bezpiecznego kopiowania i połączeń po SSH. - wget zaciąga pół internetu -
-rbez-npi bez limitu głębokości potrafi wejść w linki na zewnątrz katalogu i ściągać godzinami. Zawsze ograniczaj rekurencję przez-nporaz-lna poziom zagnieżdżenia. - Brak narzędzia w kontenerze - minimalne obrazy Docker (zwłaszcza Alpine) bywają odchudzone: raz jest tylko curl, raz tylko wget. W skryptach CI/CD warto to sprawdzić albo doinstalować jawnie, zamiast zakładać, że oba są na miejscu.
Do masowej synchronizacji plików między maszynami żadne z tej dwójki nie jest zresztą najlepszym wyborem - tam wygrywa różnicowy transfer, który opisuję we wpisie o synchronizacji katalogów przez rsync. curl i wget świetnie ściągają, ale nie porównują stanu dwóch stron.
Nauka narzedzi wiersza polecen
curl i wget to zaledwie próg administracji serwerem. Kto chce wejść głębiej w automatyzację, deploy i pracę z API, korzysta z kursów DevOps i Linuksa - na platformach takich jak Udemy czy polska Sensai Academy znajdziesz ścieżki od podstaw wiersza poleceń po CI/CD. Traktuj je jako uzupełnienie praktyki, a nie zamiennik - najwięcej i tak nauczysz się, ściągając realne paczki na własny serwer.
FAQ
Czy curl jest lepszy od wget? Żadne nie jest uniwersalnie lepsze - to zależy od zadania. curl wygrywa przy pracy z API, wysyłaniu żądań POST, debugowaniu połączeń i skryptach, bo daje pełną kontrolę nad żądaniem HTTP. wget wygrywa przy masowym ściąganiu plików, rekurencyjnym pobieraniu i tworzeniu lustrzanych kopii stron. Doświadczeni admini trzymają na serwerze oba.
Jaka jest glowna roznica miedzy curl a wget? Najkrócej: curl domyślnie wypisuje dane na ekran i jest uniwersalnym klientem kilkunastu protokołów oraz API, a wget domyślnie zapisuje plik na dysk i specjalizuje się w pobieraniu, w tym rekurencyjnym. curl korzysta z biblioteki libcurl wpinanej w inne programy, wget działa wyłącznie jako samodzielne narzędzie wiersza poleceń.
Czym pobrac plik szybciej w terminalu - curl czy wget?
Przy pojedynczym pliku różnica prędkości jest pomijalna - oba ściągają z prędkością Twojego łącza, a nie narzędzia. Liczy się wygoda: wget adres zapisuje plik od razu, a curl wymaga flagi -O. Do jednorazowego „ściągnij i zapisz" wget bywa krótszy, do wszystkiego wokół API sięgasz po curla.
Czy mozna wysylac zadania POST przez wget?
Można, ale w okrojonym zakresie - wget przyjmuje --post-data="klucz=wartosc" albo --post-file. Do prostego formularza wystarczy, natomiast przy REST API, własnych metodach HTTP, nagłówkach i tokenach szybko trafisz na ścianę. Tam standardem jest curl, który daje pełną kontrolę nad żądaniem.
Ktore narzedzie do mirroringu calej strony?
wget, bez konkurencji. Polecenie wget -r -np -k adres pobiera stronę rekurencyjnie, trzyma się wskazanego katalogu i przerabia linki tak, by kopia działała offline. curl nie ma wbudowanej rekurencji i nie zrobi lustrzanej kopii jednym poleceniem - to właśnie ta funkcja utrzymuje wget przy życiu.
Czy curl i wget sa preinstalowane na Linuksie?
Zależy od dystrybucji. Wiele systemów ma domyślnie jedno z nich, a nie oba - część minimalnych obrazów, zwłaszcza kontenery Alpine, bywa odchudzona z jednego lub drugiego. Doinstalowanie jest banalne: apt install curl wget na Debianie i Ubuntu albo dnf install curl wget na Fedorze i RHEL.