cURL to najpowszechniejsze narzędzie HTTP w ekosystemie uniksowym, ale domyślnie wychodzi z Twoim adresem IP. Jeśli scrapujesz dane publiczne, monitorujesz ceny konkurencji albo testujesz infrastrukturę z wielu lokalizacji, potrzebujesz używania proxy z cURL w sposób, który jest powtarzalny, bezpieczny i gotowy na produkcję. Ten artykuł pokazuje dokładnie, jak skonfigurować ProxyHat w cURL — od pojedynczych flag po skrypty Bash z rotacją IP i równoległością.
Używanie proxy z cURL — podstawowe flagi i resolve DNS
Najprostszy sposób na użycie proxy w cURL to flaga -x (lub --proxy). Dla bramki ProxyHat HTTP wygląda to tak:
# HTTP proxy — podstawowe użycie
curl -x http://USERNAME:PASSWORD@gate.proxyhat.com:8080 https://httpbin.org/ip
Jeśli preferujesz SOCKS5, użyj portu 1080:
# SOCKS5 proxy
curl --socks5-hostname gate.proxyhat.com:1080 \
--proxy-user 'USERNAME:PASSWORD' \
https://httpbin.org/ip
Kluczowa różnica: --socks5-hostname (odpowiednik socks5h:// w URL) rozwiązuje DNS po stronie proxy, a nie lokalnie. Zwykłe --socks5 rozwiązuje DNS na Twojej maszynie i wysła proxy gotowy adres IP — co ujawnia Twoje zapytania DNS dostawcy ISP i może powodować wycieki, jeśli DNS lokalny nie trafia przez tunel. Dla scrapowania to istotne: niektóre sieci CDN logują zapytania DNS i korelują je z adresem IP połączenia.
Możesz też zapisać to jako pełny URL:
# socks5h:// — DNS resolve po stronie proxy
curl -x socks5h://USERNAME:PASSWORD@gate.proxyhat.com:1080 https://httpbin.org/ip
Dla porównania, socks5:// (bez h) rozwiązuje DNS lokalnie. W kontekście curl socks5 proxy zawsze preferuj socks5h:// jeśli chcesz pełnego ukrycia zapytań DNS. Więcej szczegółów w oficjalnej dokumentacji cURL.
Uwierzytelnianie proxy i geo-targeting w nazwie użytkownika
ProxyHat koduje parametry sesji i lokalizacji w nazwie użytkownika. To oznacza, że curl z uwierzytelnieniem proxy nie wymaga dodatkowych nagłówków — wszystko idzie przez --proxy-user lub URL.
Geo-targeting: kraj i miasto
# USA, Nowy Jork
curl -x http://user-country-US-city-newyork:pass@gate.proxyhat.com:8080 \
https://httpbin.org/ip
# Niemcy, Berlin
curl -x http://user-country-DE-city-berlin:pass@gate.proxyhat.com:8080 \
https://httpbin.org/ip
Sesje sticky (sticky sessions)
Domyślnie ProxyHat rotuje IP przy każdym żądaniu. Jeśli potrzebujesz utrzymać tę samą tożsamość IP przez serię żądań — np. logowanie i kolejne strony — dodaj flagę sesji:
# Sticky session — ten sam IP przez serię żądań
curl -x http://user-session-abc123:pass@gate.proxyhat.com:8080 \
https://example.com/page1
curl -x http://user-session-abc123:pass@gate.proxyhat.com:8080 \
https://example.com/page2
Identyfikator sesji (abc123) to dowolny string. Dopóki jest ten sam, ProxyHat utrzyma ten sam adres IP wyjściowy. Jeśli zmienisz go na xyz789, dostaniesz nowy IP. To daje pełną kontrolę nad rotacją bez konieczności zarządzania pulą adresów ręcznie.
Łączenie geo-targeting i sesji
# USA + sticky session
curl -x http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080 \
https://httpbin.org/ip
Pełna lista dostępnych lokalizacji znajduje się na stronie /pl/locations.
Zmienne środowiskowe i plik konfiguracyjny .curlrc
Ręczne wpisywanie -x przy każdym wywołaniu jest uciążliwe. cURL obsługuje zmienne środowiskowe HTTPS_PROXY i powiązane, które automatycznie kierują ruch przez proxy.
Standardowe zmienne proxy
# Eksport zmiennych środowiskowych
export HTTP_PROXY="http://user-country-US:pass@gate.proxyhat.com:8080"
export HTTPS_PROXY="http://user-country-US:pass@gate.proxyhat.com:8080"
export ALL_PROXY="socks5h://user-country-US:pass@gate.proxyhat.com:1080"
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"
# Teraz zwykły curl automatycznie używa proxy
curl https://httpbin.org/ip
NO_PROXY jest krytyczne — bez niego cURL może kierować wewnętrzny ruch (np. health-checki do localhost) przez proxy, co powoduje błędy lub nieoczekiwane opóźnienia. Ustaw NO_PROXY na wszystkie wewnętrzne hosty i domeny.
Plik ~/.curlrc
cURL czyta plik ~/.curlrc przy każdym uruchomieniu. To idealne miejsce na domyślną konfigurację proxy:
# ~/.curlrc
proxy = "http://user-country-US:pass@gate.proxyhat.com:8080"
proxy-user = "user-country-US:pass"
compressed
user-agent = "Mozilla/5.0 (X11; Linux x86_64; rv:121.0) Gecko/20100101 Firefox/121.0"
retry = 3
retry-all-errors
connect-timeout = 10
max-time = 30
Od teraz każde wywołanie curl https://example.com automatycznie używa ProxyHat z geo-targeting US, kompresją gzip i retries. Jeśli chcesz nadpisać proxy dla pojedynczego żądania, użyj -x "" aby wyłączyć proxy.
Plik konfiguracyjny -K
Dla różnych projektów możesz mieć osobne pliki konfiguracyjne i ładować je flagą -K:
# ~/.curlrc-serp
proxy = "http://user-country-DE-session-serp01:pass@gate.proxyhat.com:8080"
compressed
silent
write-out = "%{http_code} %{time_total}s %{remote_ip}\n"
# Użycie
curl -K ~/.curlrc-serp https://www.google.com/search?q=test
Flaga -K (lub --config) czyta plik i stosuje wszystkie ustawienia. To czystsze niż długie jednolinijkowce w skryptach CI/CD.
Dlaczego proxy rezydencjalne biją datacenter na trudnych celach
Adresy IP z datacenter są łatwe do wykrycia — należą do bloków ASN przypisanych do dostawców chmurowych (AWS, DigitalOcean, OVH). Wiele stron używa baz takich jak IP2Location lub MaxMind GeoIP2, aby odrzucać ruch z datacenter. Proxy rezydencjalne używają adresów IP przypisanych do prawdziwych dostawców ISP, więc wyglądają jak organiczny ruch użytkownika.
| Cecha | Proxy rezydencjalne | Proxy datacenter |
|---|---|---|
| Pochodzenie IP | ISP (prawdziwi użytkownicy) | Dostawcy chmurowi |
| Wykrywalność | Niska — wygląda jak organiczny ruch | d>Wysoka — flagowane przez anti-bot|
| Sukces na SERP/e-commerce | 90–98% | 30–60% |
| Latencja | Wyższa (50–200ms dodatkowo) | Niska (1–10ms) |
| Koszt | d>Wyższy za GBNiższy za GB | |
| Idealne do | Scraping SERP, e-commerce, social | API, proste żądania, QA |
Dla scrapowania wyników wyszukiwania (SERP) lub monitorowania cen na stronach z agresywnym anti-bot (np. Cloudflare Turnstile, DataDome), proxy rezydencjalne to jedyny realny wybór. Datacenter IP mogą działać przez kilka żądań, ale po 50–100 zapytaniach dostaniesz HTTP 403 lub CAPTCHA.
Rotacja IP w Bashu — while loop z retry
#!/usr/bin/env bash
set -euo pipefail
# Lista URL do scrapowania
URLS=(
"https://httpbin.org/ip?req=1"
"https://httpbin.org/ip?req=2"
"https://httpbin.org/ip?req=3"
"https://httpbin.org/ip?req=4"
"https://httpbin.org/ip?req=5"
)
for url in "${URLS[@]}"; do
# Unikalny session ID per żądanie = nowy IP
SESSION="$(date +%s)-$RANDOM"
curl \
--retry 5 \
--retry-all-errors \
--retry-delay 2 \
--connect-timeout 10 \
--max-time 30 \
-x "http://user-session-${SESSION}:pass@gate.proxyhat.com:8080" \
-H "User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:121.0) Gecko/20100101 Firefox/121.0" \
--compressed \
-w "\n%{http_code} | %{time_total}s | IP: %{remote_ip}\n" \
-s "$url"
echo "---"
sleep 1
done
Flaga --retry-all-errors (dostępna od cURL 7.71.0) ponawia żądania na wszystkie błędy HTTP, nie tylko na problemy sieciowe. -w wypisuje kod statusu, czas trwania i adres IP proxy — przydatne do diagnozowania, czy rotacja faktycznie działa.
Równoległość z xargs -P
# Równoległe żądania — 10 wątków
echo -e "https://httpbin.org/ip\nhttps://httpbin.org/ip\nhttps://httpbin.org/ip" | \
xargs -P 10 -I {} curl -s \
-x "http://user-session-$(date +%s%N):pass@gate.proxyhat.com:8080" \
-w "%{http_code} %{time_total}s %{remote_ip}\n" \
-o /dev/null {}
xargs -P 10 uruchamia do 10 równoległych procesów cURL. Każdy dostaje unikalny session ID (z nanosekundami), więc każdy ma inny IP wyjściowy. To proste, ale skuteczne — dla większej skali rozważ curl --parallel lub dedykowany scraper w Python/Node.js.
curl --parallel (od 7.66.0)
# Plik z listą URL
cat > urls.txt << 'EOF'
url = "https://httpbin.org/ip"
url = "https://httpbin.org/ip"
url = "https://httpbin.org/ip"
EOF
curl --parallel --parallel-immediate --parallel-max 20 \
-K urls.txt \
-x "http://user-country-US:pass@gate.proxyhat.com:8080" \
-o "output_#1.txt"
--parallel-max 20 ogranicza do 20 jednoczesnych połączeń. Pamiętaj, że przy --parallel wszystkie żądania dzielą to samo proxy URL — jeśli chcesz rotację IP per żądanie, musisz generować osobne pliki konfiguracyjne albo użyć podejścia z xargs.
Wskazówki produkcyjne
TLS 1.3 i bezpieczeństwo połączenia
# Wymuś TLS 1.3
curl --tlsv1.3 --tls-max 1.3 \
-x "http://user-country-US:pass@gate.proxyhat.com:8080" \
https://example.com
Wymuszenie TLS 1.3 eliminuje negocjację do starszych wersji, które mogą mieć luki. Większość współczesnych stron wspiera TLS 1.3 — jeśli nie, cURL zwróci błąd i wtedy zdejmij ograniczenie.
Niestandardowe nagłówki i User-Agent
# Pełny zestaw nagłówków przeglądarki
curl \
-x "http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080" \
-H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36" \
-H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" \
-H "Accept-Language: en-US,en;q=0.5" \
-H "Accept-Encoding: gzip, deflate, br" \
--compressed \
https://example.com
--compressed mówi cURL, aby wysłał nagłówek Accept-Encoding i automatycznie dekompresował odpowiedzi gzip/deflate/brotli. Bez tego pobierasz 2–5× więcej danych.
Logging i diagnostyka
# Szczegółowy log do pliku
curl -v \
-x "http://user-country-US:pass@gate.proxyhat.com:8080" \
-w @- https://example.com << 'EOF'
http_code: %{http_code}
time_namelookup: %{time_namelookup}s
time_connect: %{time_connect}s
time_appconnect: %{time_appconnect}s
time_total: %{time_total}s
speed_download: %{speed_download} bytes/s
remote_ip: %{remote_ip}
EOF
To rozdziela czas DNS, TCP, TLS i całkowity — kluczowe do diagnozowania, czy opóźnienia pochodzą od proxy czy od serwera docelowego. Typowa latencja przez ProxyHat to 50–200ms dodatkowo w porównaniu do bezpośredniego połączenia.
ProxyHat SDK — alternatywa dla skomplikowanych scenariuszy
Jeśli Twój przypadek użycia wykracza poza proste żądania cURL — np. potrzebujesz automatycznej rotacji, zarządzania pulą sesji, integracji z Python/Node.js — ProxyHat SDK opakowuje te same endpointy w wygodniejsze API. Pełna dokumentacja znajduje się na docs.proxyhat.com. cURL pozostaje jednak najlepszym narzędziem do szybkiego testowania, debugowania i skryptów jednorazowych.
Nota prawna: kiedy scrapować, a kiedy użyć API
Scrapowanie danych publicznych jest legalne w wielu jurysdykcjach, ale zależy od kontekstu. W USA Computer Fraud and Abuse Act (CFAA) historycznie kwestionował scrapowanie, ale wyrok Van Buren v. United States (2021) zawęził definicję „nieautoryzowanego dostępu”. Scrapowanie publicznie dostępnych stron zazwyczaj nie łamie CFAA, o ile nie omijasz autoryzacji (np. logowania).
W UE RODO (GDPR) ma zastosowanie, jeśli zbierasz dane osobowe — np. nazwiska, adresy e-mail, profile użytkowników. Dane publiczne, ale osobowe, nadal podlegają zasadom przetwarzania. Scrapowanie cen produktów czy wyników SERP zazwyczaj nie dotyka danych osobowych, ale zawsze weryfikuj robots.txt i warunki usługi (ToS) danej strony.
Złota zasada: jeśli strona oferuje oficjalne API, użyj go. API są szybsze, stabilniejsze i legalne. Proxy i scrapowanie to ostateczność, gdy API nie istnieje, jest zbyt ograniczone, albo nie pokrywa potrzebnych danych. Cennik ProxyHat znajdziesz na /pl/pricing.
Kluczowe wnioski
- Używaj
-x http://...gate.proxyhat.com:8080dla HTTP isocks5h://...gate.proxyhat.com:1080dla SOCKS5 z resolve DNS po stronie proxy.- Geo-targeting i sesje koduj w nazwie użytkownika:
user-country-US-city-newyork-session-abc123.- Zmienne
HTTP_PROXY,HTTPS_PROXY,ALL_PROXYiNO_PROXYautomatyzują konfigurację;~/.curlrccentralizuje ustawienia.- Proxy rezydencjalne osiągają 90–98% sukcesu na trudnych celach vs 30–60% dla datacenter.
--retry-all-errors,--compressed,--tlsv1.3i-wto cztery flagi, które robią 80% różnicy w produkcji.- Zawsze sprawdzaj
robots.txt, ToS i preferuj oficjalne API, gdy jest dostępne.
Więcej porad dotyczących scrapowania znajdziesz w naszych artykułach o web scrapingu i śledzeniu SERP.
FAQ
Czym jest używanie proxy z cURL?
Używanie proxy z cURL to kierowanie żądań HTTP/HTTPS przez pośredni serwer proxy za pomocą flagi -x lub zmiennych środowiskowych HTTP_PROXY/HTTPS_PROXY. Proxy zmienia Twój adres IP wyjściowy, co jest przydatne do scrapowania, testów geo-lokalizacji i omijania limitów rate. W ProxyHat dodatkowo koduje się parametry sesji i lokalizacji w nazwie użytkownika.
Dlaczego używanie proxy z cURL ma znaczenie?
Bez proxy cURL wychodzi z Twoim IP, co ujawnia tożsamość i lokalizację. Przy scrapowaniu danych publicznych to prowadzi do blokad po 50–100 żądaniach. Proxy rezydencjalne ukrywają Twój IP i rozpraszają żądania po puli adresów ISP, co podnosi sukces z 30–60% do 90–98% na stronach z anti-bot.
Który typ proxy działa najlepiej z cURL?
To zależy od celu. Proxy rezydencjalne (port 8080 HTTP lub 1080 SOCKS5) najlepiej nadają się do scrapowania stron z anti-bot, SERP i e-commerce. Proxy datacenter są tańsze i szybsze, ale łatwo wykrywalne. SOCKS5 z socks5h:// jest preferowany, gdy chcesz, aby DNS było rozwiązywane po stronie proxy — eliminuje to wycieki zapytań DNS.
Jak unikać blokad używając proxy z cURL?
Rotuj IP przy każdym żądaniu używając unikalnych session ID, ustaw realistyczny User-Agent, dodaj --retry-all-errors z opóźnieniem, ogranicz współbieżność do 10–20 żądań, używaj --compressed i przestrzegaj robots.txt. Unikaj stałych session ID przy dużej liczbie żądań do tej samej domeny — to tworzy wzorzec, który anti-bot może wykryć.
Czy mogę używać zmiennych środowiskowych zamiast flagi -x?
Tak. cURL automatycznie czyta HTTP_PROXY, HTTPS_PROXY, ALL_PROXY i NO_PROXY. Ustaw je w shellu lub w ~/.curlrc, a każde wywołanie cURL użyje proxy bez dodatkowych flag. NO_PROXY jest krytyczne, aby wykluczyć ruch wewnętrzny (localhost, sieci prywatne) z proxy.






