Konfiguracja proxy w curl: uwierzytelnianie, HTTPS CONNECT i wiarygodne sprawdzenia

Ustawić w curl jawne proxy, rozdzielić -U od -u, przesłać HTTPS przez CONNECT bez -k i odczytać kody wyjścia względem faktycznie użytej trasy.

Ten poradnik jest dla osób, które mają już curl na PATH i potrzebują przeskoku HTTP albo SOCKS, który da się udowodnić. Poniższe sprawdzenia używały lokalnego origin na loopback i atrap proxy, nie konta u dostawcy. Top Proxy nie sprzedaje adresów IP i nie ma tu darmowych kluczy. Strona Jaki jest mój adres IP w przeglądarce pokazuje trasę przeglądarki, nie ten proces curl.

01Uruchomić sprawdzenia na żywym proxy#

Liczby w tym artykule pochodzą z kontrolowanego pomiaru na loopback przy curl 8.7.1. Ten pomiar to metodyka. To nie zestaw na tej stronie i nie ma publicznego pliku do pobrania.

Należy użyć zwykłego curl wobec proxy i origin, które nadal działają. Atrapa lab-user:lab-pass to etykieta, nie konto. W poleceniu trzeba wstawić żywy host, port i CA. Nie należy ponownie używać portów z rodziny 60585 z zapisanego przebiegu. Te punkty końcowe zniknęły, gdy pomiar się skończył.

curl -q -sS --noproxy '' -x http://127.0.0.1:PROXY_PORT --proxy-user lab-user:lab-pass http://127.0.0.1:ORIGIN_PORT/identity

HTTPS przez ten sam przeskok HTTP nadal używa CONNECT. Należy zaufać CA, które pasuje do origin, z którym trwa rozmowa w tej chwili.

curl -q -sS --noproxy '' -x http://127.0.0.1:PROXY_PORT --proxy-user lab-user:lab-pass --cacert ca.pem https://localhost:ORIGIN_HTTPS_PORT/identity

02Ustawić jawne proxy HTTP i zweryfikować trasę#

curl trzeba uruchomić z -q jako pierwszą opcją. Zainstalowany man curl w wersji 8.7.1 i strona man curl zgodnie mówią, że -q na pierwszej pozycji pomija curlrc. Podręczniki online bywają nowsze. Ten przewodnik zostaje przy 8.7.1. Jeśli plik rc wstrzykuje proxy, pakiet CA albo --user, każda późniejsza flaga kłóci się z duchem. Nie należy przepisywać HOME, żeby ukryć plik. -q to izolacja, którą binarny już daje.

Przeskok wskazuje się przez -x / --proxy. Bez schematu curl traktuje host jako proxy HTTP. Proxy HTTP w everything curl opisują przekazywanie w formie absolutnej dla celów HTTP. Proxy alpha w laboratorium zapisało GET http://127.0.0.1:60585/identity i potem zwróciło JSON origin. Sam status 200 nie jest trasą. Origin oddał via_proxy_header: alpha. Drugie instrumentowane proxy o nazwie beta na tym wywołaniu pozostało bezczynne.

1. Uruchomić curl -q --version i zachować wiersz libcurl. Ten przewodnik używał curl 8.7.1, libcurl 8.7.1, SecureTransport plus LibreSSL 3.3.6. W cechach było HTTPS-proxy. Ta flaga dotyczy TLS do proxy. Nie dowodzi SOCKS i nie dowodzi CONNECT.
2. Wywołać origin raz bez -x. Bezpośredni HTTP zwrócił kod wyjścia 0, HTTP 200, identyfikator origin http-origin, a atrapa proxy nic nie dostała. To jest kontrola.
3. Wywołać ten sam URL z -x, --noproxy '' i atrapą --proxy-user. --noproxy '' wymusza proxy nawet wtedy, gdy powłokowe NO_PROXY pominęłoby loopback. Ciało origin nazwało alpha. Przeskok zużył Proxy-Authorization. Origin go nie zobaczył.
4. Czytać log proxy, nie tylko stdout. Brak danych logowania na tym stanowisku zwrócił HTTP 407 przy kodzie wyjścia curl 0, bo --fail było wyłączone.

curl -q -sS --noproxy '' -x http://127.0.0.1:PROXY_PORT --proxy-user lab-user:lab-pass http://127.0.0.1:ORIGIN_PORT/identity

PROXY_PORT i ORIGIN_PORT muszą pochodzić ze stanowiska, które nadal działa. To nie są wygasłe porty z zapisanych wyników.

Błędne dane atrapy też zwróciły 407 i kod wyjścia 0. Stanowisko oznaczyło auth: wrong. Poprawne dane zwróciły origin 200 i auth: correct. Znaki zastrzeżone w haśle atrapy poszły przez --proxy-user, nie przez wklejony URL. Kodowanie URL składnik po składniku to druga legalna ścieżka. Nie należy wstawiać prawdziwych haseł do argv, jeśli da się tego uniknąć. Listy procesów i tak przez chwilę widzą argument. Podręcznik 8.7.1 o tym mówi.

Jeśli trzeba tylko wiedzieć, czy host w ogóle odpowiada HTTP, wystarczy sprawdzanie proxy. To narzędzie osiągalności. To nie ten proces curl.

03Rozdzielić uwierzytelnianie proxy od uwierzytelniania origin#

-U / --proxy-user uwierzytelnia wobec proxy. -u / --user uwierzytelnia wobec origin. Uwierzytelnianie proxy w everything curl traktuje te ścieżki jako niezależne celowo. Mieszanie ich to sposób, by wyciec hasło bramy do logowania aplikacji albo odwrotnie.

Origin w laboratorium serwował /origin-auth z własnym wyzwaniem Basic. Jedno polecenie wysłało atrapę -U do alpha i atrapę -u do origin. JSON origin podał origin_authorized: true i proxy_authorization_present: false. Przeskok zużył Proxy-Authorization. Origin go nigdy nie zobaczył.

1. Dane logowania proxy umieszczać w -U albo w userinfo URL proxy, nigdy w -u.
2. Dane logowania origin umieszczać w -u, w zamierzonym netrc albo w URL origin. To laboratorium używało pustego prywatnego netrc i bez --netrc, więc niespodziewane logowanie byłoby błędem.
3. Potwierdzić origin. 200 od proxy przy 401 od origin to inna awaria niż 407 od przeskoku.

curl -q -sS --noproxy '' -x http://127.0.0.1:PROXY_PORT --proxy-user lab-user:lab-pass -u origin-user:origin-pass http://127.0.0.1:ORIGIN_PORT/origin-auth

HTTP 407 bez --fail zostawił curl przy kodzie wyjścia 0 na tej kompilacji. Dodanie -f na tym samym wywołaniu bez danych logowania zwróciło HTTP 407 i kod wyjścia 22. Zainstalowany podręcznik ostrzega, że 401 i 407 potrafią przejść przez --fail. Na 8.7.1 w tym przebiegu nie przeszły. Nie należy tego uogólniać na każdy przyszły curl. Status, status CONNECT i kod wyjścia zapisuje się osobno. --fail-with-body to wariant, który nadal zapisuje dokument. Tutaj nie był domyślny.

Użytkownicy-atrapy w tym artykule to etykiety. To nie konta. Ślady verbose w laboratorium miały wartości Authorization i Proxy-Authorization obcięte do [REDACTED], zanim jakikolwiek plik trafił na dysk.

04Dotrzeć do HTTPS przez CONNECT bez wyłączania TLS#

Witryna HTTPS przed proxy HTTP nadal jest obsługiwana przez proxy HTTP. curl wysyła CONNECT host:port, proxy otwiera TCP, a potem TLS idzie do origin przez ten tunel. Do tego nie potrzeba schematu https:// przy proxy. Schemat https:// przy proxy to TLS do samego proxy. everything curl o proxy HTTP i rozdział o proxy HTTPS trzymają te przeskoki osobno. To laboratorium nie stawiało proxy HTTPS. --proxy-cacert pozostało niezmierzone. --cacert weryfikowało origin po CONNECT.

1. Zostawić -x na http://127.0.0.1:PORT nawet wtedy, gdy URL to https://localhost:PORT/identity.
2. Zaufać laboratoryjnemu CA przez --cacert. Nie dodawać -k.
3. Wymagać wiersza CONNECT w logu, zanim zaufa się 200. Alpha zapisało CONNECT localhost:60586 z auth: correct i statusem 200, a potem ciało origin nazwało https-origin.
4. Powtórzyć raz bez --cacert. CONNECT nadal się udał. curl zakończył się kodem 60, błędem certyfikatu TLS partnera. Tunel był w porządku. Certyfikat nie.

curl -q -sS --noproxy '' -x http://127.0.0.1:PROXY_PORT --proxy-user lab-user:lab-pass --cacert ca.pem https://localhost:ORIGIN_HTTPS_PORT/identity

--cacert musi być CA ze stanowiska, które nadal działa. Nie należy wskazywać pozostałego evidence/ca.pem po wyjściu jednorazowego launchera i nie należy ponownie używać skasowanej ścieżki tymczasowej z zapisanego przebiegu.

Brak danych logowania proxy na CONNECT nie wyglądał jak ścieżka HTTP 407 plus kod wyjścia 0. Stanowisko i tak odpowiedziało 407 na CONNECT. curl 8.7.1 zakończył się kodem 56, a kod HTTP z write-out wyniósł 000. Błędne dane dały to samo. Awarii CONNECT należy traktować jako transport, nie jako ciche HTML 407 do późniejszego parsowania.

Bezpośredni HTTPS z laboratoryjnym CA zwrócił 200. Bezpośredni HTTPS bez niego zwrócił kod wyjścia 60. Ta para to linia bazowa TLS. Jest niezależna od proxy.

Karta Jaki jest mój adres IP w przeglądarce nadal nie pokaże tego tunelu. Jeśli celem była przeglądarka, trzeba skonfigurować przeglądarkę.

05Zrozumieć proxy ze środowiska i zamierzone ominięcie#

curl czyta http_proxy, https_proxy, all_proxy i NO_PROXY. Zmienne środowiska proxy są wprost o pułapce CGI. Przychodzące nagłówki Proxy: stają się HTTP_PROXY wielkimi literami. curl dlatego przyjmuje dla HTTP tylko małe http_proxy. Wielkie HTTPS_PROXY i ALL_PROXY pozostają ważne dla swoich schematów.

Laboratorium startowało każde dziecko z czystego środowiska. Usuwało obie wielkości liter zmiennych proxy, pozostałości CGI REQUEST_METHOD, CURL_CA_BUNDLE, SSL_CERT_FILE, SSL_CERT_DIR, SSLKEYLOGFILE i REQUESTS_CA_BUNDLE. Potem wstrzykiwało jedną nazwaną atrapę na raz. curl nie ma przełącznika trust_env=. W Requests trust_env=False zmienia też wyszukiwanie CA i netrc. Nie należy kopiować tej flagi na curl. -q plus czyste środowisko dziecka to równoważna izolacja.

1. Ustawić małe http_proxy na alpha, podać --proxy-user i dodać --noproxy ''. Origin nazwał alpha. To routing wyłącznie ze środowiska.
2. Ustawić wielkie HTTP_PROXY na ten sam URL alpha i pominąć -x. Origin wrócił bezpośrednio. Licznik zdarzeń alpha się nie ruszył. To udokumentowana konwencja bezpieczeństwa, zmierzona na tym binarnym.
3. Ustawić http_proxy na alpha i podać jawne -x beta. Origin nazwał beta. Alpha nie było wybranym przeskokiem. Dwie tożsamości proxy wygrywają ze zgadywaniem „200 skądś”.
4. Ustawić http_proxy na alpha i NO_PROXY=127.0.0.1 bez --noproxy ''. Origin był bezpośredni, a alpha pozostało bezczynne. To przypadek ominięcia, uruchomiony celowo.
5. Zostawić NO_PROXY=127.0.0.1 i dodać --noproxy ''. Pusta lista nadpisuje zmienną, jak mówi podręcznik 8.7.1 od 7.53.0. Origin znowu nazwał alpha.

Nigdy nie należy wnioskować przeskoku z HTTP 200. Sukces bezpośredni i przez proxy wygląda tak samo w ciele, dopóki trasa nie zostanie ostemplowana. Stanowisko stemplowało X-Lab-Proxy na przekazanym HTTP. CONNECT nie może ostemplować origin wewnątrz TLS, więc log CONNECT jest dowodem.

06Porównać SOCKS5 i SOCKS5h z dowodem handshake#

SOCKS to nie przekazywanie HTTP i nie CONNECT. Rozdział SOCKS w everything curl trzyma tabelę krótko. SOCKS5 rozwiązuje lokalnie. SOCKS5h wysyła nazwę hosta do proxy. --socks5 i --socks5-hostname to formy flag. socks5:// i socks5h:// na -x to formy URL.

curl 8.7.1 od Apple pomija socks na liście protokołów i mimo to dostarcza opcje proxy SOCKS. Udane żądanie SOCKS nie jest dowodem, gdzie zadziałał DNS. Dowodem jest ATYP handshake.

1. --socks5 127.0.0.1:PORT do http://127.0.0.1:ORIGIN/identity zakończyło się HTTP 200. Stanowisko zapisało ATYP ipv4 i adres 127.0.0.1.
2. --socks5-hostname 127.0.0.1:PORT do http://lab.curl-fixture.test:ORIGIN/identity zakończyło się HTTP 200. Stanowisko zapisało ATYP domain i adres lab.curl-fixture.test. Proxy zmapowało tę laboratoryjną nazwę hosta na loopback. To mapowanie to hydraulika stanowiska, nie zmierzony wyciek do publicznego DNS.
3. Na tym poprzestać. Ten artykuł nie twierdzi, że przechwycono zewnętrzny resolwer.

curl -q -sS --noproxy '' --socks5-hostname 127.0.0.1:SOCKS_PORT http://lab.curl-fixture.test:ORIGIN_PORT/identity

Dokumentacja dostawców idzie tym samym podziałem. Protokoły rezydenckie Oxylabs dokumentują socks5h://pr.oxylabs.io:7777 jako przekazanie nazwy hosta, a socks5:// jako przekazanie rozwiązanego IP. Protokoły rezydenckie Decodo, w katalogu nadal jako Smartproxy, dokumentują socks5h:// na gate.decodo.com:7000 i piszą, że hosty krajowe takie jak us.decodo.com nie działają dla SOCKS5. To udokumentowane uwagi o dopasowaniu. To nie ten przebieg na loopback.

Protokół to nie typ IP. Strony mobilne i rezydenckie opisują pule wyjścia. SOCKS5 kontra HTTP to handshake klienta. Można mieć rezydencki przeskok HTTP albo datacenter SOCKS. Nie należy spłaszczać tych pokręteł.

07Odróżnić błąd połączenia od limitu czasu transferu#

--connect-timeout ogranicza DNS plus TCP plus, dla TLS, handshake. --max-time ogranicza cały transfer. Limity czasu w everything curl mówią, że --max-time nadal odpala, gdy dane już płyną. Kod wyjścia 28 to ten timer. To nie limit odczytu w stylu Requests.

To laboratorium nie mierzyło limitu czasu połączenia i nie przechwytywało pakietów. Kod wyjścia 7 wziął się z połączenia TCP do efemerycznego portu loopback należącego do gniazda UDP. curl wypisał Couldn't connect to server z kodem HTTP 000. To błąd połączenia. To nie kod wyjścia 28.

Ścieżka opóźnionego ciała to inny kształt. /slow-body wysłało kompletne nagłówki natychmiast, wypchnęło pierwszy bajt ciała H, a potem czekało dłużej niż --max-time 1.5 przed resztą. curl zgłosił HTTP 200, nie 000, i zakończył się kodem 28. Zdarzenie pierwszego bajtu origin było ustawione. Alpha przekazało GET .../slow-body. To limit czasu transferu po starcie ciała.

1. Przy martwym przeskoku oczekiwać błędu połączenia. Tutaj był to kod wyjścia 7 wobec zajętego portu loopback.
2. Przy wolnym ciele wymagać nagłówków i pierwszego bajtu, potem --max-time, potem kod wyjścia 28 z prawdziwym HTTP 200. Kod 000 obaliłby asercję.
3. Zostawić --connect-timeout zgodnie z dokumentacją, chyba że handshake naprawdę się zacina. Ten przebieg tego nie robił.

curl -q -sS --noproxy '' -x http://127.0.0.1:PROXY_PORT --proxy-user lab-user:lab-pass --max-time 1.5 http://127.0.0.1:ORIGIN_PORT/slow-body

Ponowienia to osobny przełącznik. --retry resetuje licznik --max-time na każdą próbę na 8.7.1. Okno ponowień ogranicza --retry-max-time, jeśli się je włączy. Flagi ponowienia nie należy traktować jako idempotentności dla POST.

08Wybrać punkt końcowy według udokumentowanego protokołu i uwierzytelniania#

Przeskok wybiera się tak, jak dokumentuje go sprzedawca, a potem dowodzi curl na własnym stanowisku. Płatnych bram nie wywoływano. Targetowanie kraju, folklor antybot i rankingi „najlepszej usługi” są poza zakresem.

Protokoły rezydenckie Oxylabs, pobrane 14 października 2026, kładą HTTP na pr.oxylabs.io:7777 z -U customer-USERNAME:PASSWORD. Ta sama strona dodaje https://pr.oxylabs.io:7777, gdy potrzebny jest TLS do bramy, oraz socks5h://pr.oxylabs.io:7777, gdy proxy ma zobaczyć nazwę hosta. SOCKS5 na tej stronie nie używa krajowych hostów wejścia.

Protokoły rezydenckie Decodo, tego samego dnia, kładą HTTP na gate.decodo.com:7000 i SOCKS5h na tym samym hoście. Te udokumentowane schematy warto porównać z żywymi angielskimi kartami Oxylabs i Smartproxy / Decodo. To dopasowanie katalogowe, nie test bramy.

1. Dopasować schemat do obsługi klienta. curl 8.7.1 tutaj mówił przekazywaniem HTTP, CONNECT, SOCKS5 i SOCKS5h. TLS do proxy HTTPS pozostaje wierszem wyłącznie z dokumentacji.
2. Dopasować uwierzytelnianie do -U, z prefiksami nazwy użytkownika, które dokumentuje sprzedawca. Origin -u zostaje poza tym ciągiem.
3. Sprawdzić przeskok sprawdzaniem proxy, jeśli potrzeba tylko HTTP kontra SOCKS na hoście. Adres IP wyjścia sprawdzać w curl, nie w karcie przeglądarki. Udowodnić przeskok na żywym własnym proxy, zanim curl trafi na jakikolwiek płatny punkt końcowy.

Oxylabs — proxy rezydenckie i datacenter4.0771

Oxylabs sprzedaje proxy rezydenckie, mobilne, ISP i datacenter w jednej subskrypcji miesięcznej od $30. Płatności: karty, przelew, AliPay, PayPal.

10 krajów

0,45 USD

za 1 GB

Decodo (Smartproxy) — proxy rezydenckie i datacenter4.22118

Decodo (dawniej Smartproxy) sprzedaje proxy rezydenckie i datacenter. Rezydenckie: $4/GB bez planu miesięcznego albo pakiety miesięczne od $3.75/GB za 3 GB. Płatności: karty, PayPal, Alipay, Google/Apple Pay, krypto (z ograniczeniami).

83 kraje

0,38 USD

za 1 GB