Otevřete si síťová nastavení v telefonu nebo notebooku a možná narazíte na možnost HTTP Proxy s volbami jako Off, Manual nebo Auto. Bezpečné základní pravidlo je prosté: pokud vám údaje k proxy nedal důvěryhodný správce nebo konkrétní aplikace, nic si nevymýšlejte. Adresa proxy není přepínač výkonu ani režim soukromí. Mění jen to, kam se vaše HTTP požadavky posílají.
Tenhle nenápadný panel nastavení skrývá překvapivě široké téma. HTTP proxy může vynucovat firemní politiku, směrovat API volání vývojáře, cachovat sdílené odpovědi nebo vytvářet tunel pro HTTPS. Na druhé straně komunikace může stát i reverzní proxy, tedy před webem místo před jeho uživateli. Ani jedna z těchto rolí sama o sobě nezaručuje, že je spojení soukromé, anonymní, rychlé nebo oprávněné.
Tenhle průvodce vysvětluje protokol, ne marketingové nálepky: co je HTTP proxy, co se skutečně přenáší po síti, čím se CONNECT liší od běžného přeposílání, kam zapadají SOCKS5 a VPN, a jak proxy ladit, aniž byste omylem změnili pět nastavení najednou.
Co je HTTP proxy?
HTTP proxy je prostředník, který přijme HTTP požadavek a zkusí ho vyřídit tak, že požadavek přepošle dál, použije uloženou odpověď, pokud je to povoleno, nebo vrátí vlastní odpověď. RFC 9110 označuje klientem zvolenou proxy jako agenta přeposílání zpráv. Klient se o ní obvykle dozví přes nastavení aplikace, nastavení operačního systému, soubor Proxy Auto-Configuration (PAC) nebo proměnné prostředí.
U explicitní forward proxy vypadá cesta takto:
client ---> forward proxy ---> origin server
<--- <---
Klient se nejdřív připojí k proxy. Proxy pak otevře nebo znovu použije spojení k cíli. Origin server obvykle uvidí síťové spojení proxy jako svého přímého protějška, ale to samo o sobě neznamená anonymitu. Hlavičky, cookies, otisky prohlížeče, přihlášené relace, chování DNS i logy mohou uživatele nebo organizaci dál identifikovat. „Origin vidí jinou zdrojovou IP“ a „uživatel je anonymní“ jsou dvě hodně odlišná tvrzení.
HTTP proxy také neznamená šifrování. Prosté HTTP zůstává prosté, pokud ho nechrání další bezpečnostní vrstva. HTTPS může přes proxy projít jako TLS tunel, ale šifrování zajišťuje TLS, ne samotné slovo proxy.
Jak explicitní HTTP proxy zpracuje požadavek
Důležitý rozdíl se projeví v cíli požadavku. Když HTTP/1.1 klient komunikuje přímo s origin serverem, obvykle posílá origin-form:
GET /reports/weekly HTTP/1.1
Host: example.com
Když tentýž klient pošle běžný HTTP požadavek na explicitní proxy, RFC 9112 určuje absolute-form, aby proxy poznala cíl:
GET http://example.com/reports/weekly HTTP/1.1
Host: example.com
Typický průběh je:
- Klient si podle platných konfiguračních pravidel zvolí proxy.
- Připojí se k proxy a pošle požadavek s URI cíle.
- Proxy může klienta ověřit, uplatnit politiku, podívat se do cache nebo požadavek odmítnout.
- Pokud je přeposílání povoleno, proxy pošle odpovídající požadavek na origin.
- Odpověď se vrátí přes proxy. Proxy může přidat metadata prostředníka, provést povolenou transformaci, uložit cacheovatelnou odpověď nebo ji jen přeposlat dál.
Slovo „může“ je v tom seznamu důležité. HTTP definuje možné chování a pravidla interoperability; negarantuje, že každá proxy filtruje obsah, cachuje odpovědi, přepisuje hlavičky nebo skrývá identifikátory.
Pokud proxy vyžaduje ověření, může vrátit 407 Proxy Authentication Required. To je něco jiného než 401 Unauthorized: 407 se týká přihlašovacích údajů pro proxy, zatímco 401 se týká origin serveru. RFC 9110 ten rozdíl výslovně definuje. Přihlašovací údaje navíc potřebují vhodný chráněný kanál; Basic authentication sama o sobě důvěrnost nezajišťuje.
HTTPS přes HTTP proxy: CONNECT je tunel, ne šifrování
Pro HTTPS cíl klient obvykle požádá proxy o otevření TCP tunelu pomocí CONNECT. Cílový formát je authority-form — host plus port — ne plná URL:
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Po úspěšné odpovědi se z připojení stane tunel. Klient pak přes tento byte stream provede TLS handshake s example.com:
client == TLS ==[ proxy relays bytes ]== TLS endpoint at origin
V tomto běžném modelu tunelování může proxy vidět metadata spojení, například uživatele proxy, cílovou autoritu, časování a počet přenesených bajtů, ale obsah HTTPS požadavků a odpovědí je šifrovaný TLS. Samotný tunel není šifrovací mechanismus. Ten rozdíl je zásadní při hledání závady: CONNECT může proběhnout úspěšně, ale pozdější TLS handshake selže.
Některé spravované sítě provádějí autorizovanou TLS inspekci. V takovém návrhu prostředník ukončí jedno TLS spojení a vytvoří jiné směrem k originu. Klient musí důvěřovat certifikační autoritě, kterou dané nasazení používá. Prostředník pak může kontrolovat HTTP obsah, protože je jedním z TLS endpointů, ne proto, že by všechny HTTP proxy uměly zázračně číst HTTPS. Na spravovaných zařízeních by to měla být výslovná, administrátorem řízená politika. Vypnutí ověřování certifikátu není legitimní produkční oprava pro neočekávanou chybu certifikátu.
Bezpečnostní hranice existuje i na straně proxy. Pokud povolíte CONNECT na libovolné hosty a porty, může se z proxy stát cesta ke službám, které nikdy neměla zpřístupňovat. Produkční proxy by měla cíle a porty omezovat podle svého účelu.
Forward, reverse, explicitní a intercepting proxy
Označení proxy bývají matoucí, když se do jedné zásuvky smíchají dvě různé osy.
První osa je kdo si prostředníka volí:
- Forward proxy se volí jménem klienta. Řídí nebo pomáhá s odchozím přístupem z daného klienta nebo sítě.
- Reverse proxy, v terminologii HTTP také gateway, stojí před jedním nebo více origin servery. Návštěvníci míří na veřejnou službu; gateway vybírá backend, ukončuje TLS, cachuje způsobilé odpovědi nebo uplatňuje serverovou politiku.
Druhá osa je jak se provoz k prostředníkovi dostane:
- Explicitní proxy klient zná z konfigurace. Klient pro ni záměrně formátuje požadavky nebo otevírá tunel
CONNECT. - Interception proxy přijímá provoz přesměrovaný sítí bez běžné explicitní konfigurace na klientovi.
Tyto pojmy se mohou překrývat. Firemní forward proxy může být explicitní. Síťová gateway může zachytávat vybraný odchozí provoz. Reverse proxy je pro návštěvníka obvykle jako samostatný hop neviditelná, i když je stále serverem, ke kterému se klient připojuje.
Interception není jen „explicitní proxy bez obrazovky s nastavením“. Může narušit předpoklady o cílových adresách, autentizaci, TLS i Path MTU. Dokumentace Squid k interception popisuje několik těchto provozních omezení. Pokud síť tyto podmínky nesplní, výsledkem bývá spíš záhadné částečné selhání než čistá chybová hláška — tedy přesně ten typ, který máme všichni nejraději.
Termíny jako anonymous, elite a high-anonymity patří hlavně do slovníků dodavatelů. Nejde o formální schopnosti HTTP. Místo víry v nálepku si ověřte skutečné chování, které potřebujete: hlavičky, odchozí adresy, autentizaci, logování, DNS resoluci a politiku tunelování.
HTTP proxy vs. SOCKS5 vs. VPN
Neexistuje obhajitelné univerzální pořadí, ve kterém by jedno z toho bylo vždy rychlejší, levnější nebo soukromější. Výkon závisí na vzdálenosti, přetížení, šifrování, implementaci, protokolu a cíli. Náklady závisí na poskytovateli a nasazení. Porovnávejte raději jejich hranice řízení.
| Otázka | HTTP proxy | SOCKS5 proxy | VPN |
|---|---|---|---|
| Jaké rozhraní klient používá? | HTTP forwarding a obvykle i tunelování přes CONNECT | Příkazy protokolu SOCKS | Virtuální/síťový tunel spravovaný OS nebo VPN klientem |
| Jaký provoz je podporován? | Provoz z aplikací, které podporují nastavenou HTTP proxy | TCP a při podpoře klientem i serverem také UDP association | Provoz vybraný směrováním a politikou split-tunnelingu |
| Zaručuje mechanismus šifrování dat? | Ne | Ne | VPN tunel obvykle chrání provoz uvnitř své definované hranice; důležitý je ale i protokol a politika |
| Kde se běžně nastavuje? | V aplikaci, v OS, PAC/WPAD nebo proměnných prostředí | Po aplikacích nebo v knihovnách | V OS nebo VPN klientovi, někdy po aplikacích |
| Kdo řeší DNS pro cíle? | Záleží na klientovi, režimu požadavku a implementaci | Záleží na tom, jak klient předá cíl | Záleží na směrování VPN a DNS politice |
| Na jakou klíčovou otázku je potřeba odpovědět? | Potřebuje tahle HTTP aplikace prostředníka? | Potřebuje tahle aplikace obecnější relay rozhraní? | Které směrování zařízení nebo aplikace má vstupovat do šifrovaného síťového tunelu? |
SOCKS5 definuje CONNECT, BIND a UDP ASSOCIATE. Díky tomu je obecnější než HTTP-specific forwarding, ale ani on neslibuje šifrování nebo anonymitu. Bezpečnost závisí na autentizaci, případném chráněném vnějším kanálu, chování koncových bodů a provozovateli.
VPN obvykle funguje na širší síťové hranici, ale tvrzení „VPN vždy přenáší každý byte ze zařízení“ je nesprávné. Split tunneling může zahrnovat nebo vylučovat konkrétní trasy či aplikace. Příkladem platformy podporující scoped VPN chování je dokumentace Apple k nasazení VPN.
Volte podle rozsahu a důvěry, ne podle jednoslovné nálepky. Pokud jediný HTTP klient potřebuje firemní gateway, systémová VPN může být zbytečná. Pokud naopak několik aplikací potřebuje přístup k privátní síti, mohou být samostatné HTTP proxy špatná abstrakce.
Má být nastavení HTTP proxy zapnuté, nebo vypnuté?
Na nespravované domácí síti ho nechte vypnuté, pokud vám adresu, port a způsob autentizace neposkytne služba, které záměrně důvěřujete. Zapnutí náhodné veřejné proxy posílá provoz k provozovateli, kterého jste si neprověřili.
Na spravovaném pracovním nebo školním zařízení postupujte podle aktuálních instrukcí administrátora. Neodstraňujte neznámou konfiguraci dřív, než zkontrolujete správu zařízení, VPN/bezpečnostní klient nebo administrátora. Proxy může být součástí řízení přístupu; její smazání může přístup narušit nebo porušit politiku, i když běžné prohlížení po tom zdánlivě funguje.
„Auto“ obvykle odkazuje na PAC URL nebo automatický mechanismus zjišťování. PAC soubor je JavaScript, který může vracet různé trasy pro různé URL — například poslat interní hostname přes proxy, zatímco veřejný web otevře přímo. To znamená, že prohlížeč může fungovat pro jeden cíl a selhat pro jiný, přestože nastavení vypadá stejně.
Přesné nabídky se napříč verzemi mění, proto používejte aktuální dokumentaci výrobce, ne screenshot ze starého článku. Trvalé otázky jsou:
- Je nastavení spravované organizací, nebo zadané uživatelem?
- Jde o Manual, PAC/Auto, nebo nastavení specifické pro aplikaci?
- Které protokoly a cíle pokrývá?
- Existují pravidla pro obejití jako
NO_PROXYnebo „exclude simple hostnames“? - Která konfigurace vyhraje, když se aplikace, OS, prostředí a PAC neshodnou?
Poslední otázka závisí na konkrétním klientovi. Chrome/Chromium obvykle používá systémové řešení proxy, ale má i vlastní zdokumentovaná pravidla. Firefox může používat vlastní nastavení připojení. Nástroje z příkazové řádky často čtou proměnné prostředí samostatně. Nastavená systémová proxy tedy neprokazuje, že ji používá každá aplikace.
Použití HTTP proxy v curl a Pythonu
Pro jednorázový požadavek dává volba --proxy v curlu volbu jasně najevo:
curl --fail-with-body --show-error \
--proxy 'http://proxy.example:8080' \
'https://api.example.com/health'
Pokud je potřeba autentizace, neumisťujte skutečná tajemství do zdrojových souborů, historie shellu, screenshotů ani příkladů v článku. Použijte mechanismus přihlašování schválený pro vaše prostředí. Tento příklad záměrně používá zástupné hodnoty:
curl --fail-with-body --show-error \
--proxy 'http://proxy.example:8080' \
--proxy-user "$PROXY_USER:$PROXY_PASSWORD" \
'https://api.example.com/data'
Pro dlouhodobou automatizaci selžte uzavřeně. Pokud pravidla říkají, že požadavek musí jít přes proxy, nezachytávejte chybu proxy a nezkoušejte potichu přímé připojení. Náhradní přímá cesta může prozradit odchozí adresu klienta nebo obejít přístupovou politiku.
Python Requests přijímá explicitní mapování:
import os
import requests
proxy_url = os.environ["APP_PROXY_URL"]
proxies = {
"http": proxy_url,
"https": proxy_url,
}
response = requests.get(
"https://api.example.com/health",
proxies=proxies,
timeout=(5, 20),
)
response.raise_for_status()
print(response.json())
Klíč https výše znamená „použij tuto proxy pro HTTPS cíl“; neznamená to nutně, že klient vytváří TLS na proxy. Proxy URL s http:// může stále přijmout CONNECT a tunelovat TLS k originu. Requests také v advanced proxy guide popisuje podporu proměnných prostředí a práci s CA bundlem.
Chování prostředí není dokonale jednotné. curl záměrně přijímá malá písmena http_proxy, zatímco jiné proměnné a nástroje mohou uznávat jiné varianty zápisu. Shoda NO_PROXY, podpora CIDR, počátečních teček, portů, chování loopbacku a precedence se liší. Považujte dokumentaci konkrétního runtime za smlouvu. Nepředpokládejte, že funkční curl příkaz dokazuje, že Requests, Go, prohlížeč i kontejner zvolí stejnou cestu.
Vyhněte se také tomuhle „řešení“:
# Nepoužívejte to k maskování problému s certifikátem v produkci.
requests.get("https://api.example.com", verify=False)
Pokud autorizovaná inspekční proxy používá privátní CA, nainstalujte nebo odkažte správný trust bundle. Pokud proxy autorizovaná není, zastavte se a věc prošetřete.
Ladění HTTP proxy po vrstvách
Selhání proxy se dá zvládnout, když testujete jednu vrstvu po druhé:
- Výběr konfigurace: Ověřte, který zdroj proxy daná aplikace skutečně používá — ruční nastavení, systém, PAC, proměnné prostředí nebo vlastní konfiguraci. Zkontrolujte pravidla pro bypass.
- Řešení názvů: Zjistěte, zda klient řeší cíl lokálně, nebo předává hostname proxy k vyřešení. Otestujte samostatně i hostname proxy.
- Dostupnost TCP: Dokáže se klient připojit na host a port proxy? Time-out tady není HTTP chyba.
- Autentizace proxy:
407znamená, že proxy žádá přihlašovací údaje. Nezaměňujte to s401od origin serveru. - HTTP forwarding: Pro čistý HTTP cíl zkontrolujte návratový kód a jestli požadavek používá správný target v absolute-form.
- Politika CONNECT: U HTTPS ověřte, že proxy dovoluje cílový host a port. Zamítnutý tunel se nikdy nedostane do TLS fáze.
- TLS: Po úspěšném
CONNECTzkontrolujte identitu certifikátu, trust chain, vyjednání protokolu a to, zda je očekávána autorizovaná inspekce. - Odpověď originu:
403,404nebo429z cíle není automaticky chyba proxy — a nerozšiřuje to žádné oprávnění měnit identitu nebo obcházet kontrolní mechanismy.
Někteří prostředníci vracejí volitelné pole Proxy-Status s diagnostickými detaily. Když je k dispozici, používejte ho, ale nikdy na něm nestavte jedinou cestu k odhalení problému. Logy z klienta, proxy i originu zůstávají nejspolehlivějším způsobem, jak zjistit, kde spojení selhalo.
A co proxy caching?
Sdílené cachování je užitečné, ale je podmíněné, ne automatické. RFC 9111 vyžaduje, aby sdílená cache před opětovným použitím odpovědi posoudila metodu, cache key, čerstvost, direktivy odpovědi, autorizaci a pravidla revalidace.
Čtyři direktivy se často chápou špatně:
privateříká sdílené cache, aby odpověď (nebo uvedená pole) neukládala.no-storeříká cache, aby zprávu neukládaly, ale RFC výslovně upozorňuje, že to není kompletní mechanismus ochrany soukromí.no-transformžádá prostředníky, aby reprezentaci neměnili.proxy-revalidateovlivňuje opětovné použití po zastarání uložené odpovědi; neudělá z jinak necachovatelné odpovědi odpověď cachovatelnou.
HTTPS tunelovaný end-to-end je pro forward proxy neprůhledný, takže tato proxy nemůže fungovat jako HTTP content cache pro šifrované zprávy uvnitř tunelu. Reverse proxy nebo autorizovaná TLS-terminating gateway je jiná architektura.
HTTP proxy, web scraping a Thunderbit
Systémy pro sběr dat mohou proxy používat pro řízený odchozí provoz, regionální směrování, oddělení zátěže nebo stabilní síťovou identitu. To jsou možnosti směrování, ne povolení k čemukoli. Proxy nedává oprávnění stránku sbírat, obcházet přístupové kontroly ani zaručit, že cíl požadavek přijme. Stavové kódy jako 403 a 429 nebo CAPTCHA vyžadují zpracování podle pravidel, ne automatické „změň typ proxy“.
Existuje také volba abstrakce. Surová forward proxy dává vývojáři HTTP rozhraní pro směrování nebo tunelování. Aplikace si ale pořád nese odpovědnost za stahování, renderování, parsování, validaci schématu, retry, observabilitu i compliance rozhodnutí.
Dokumentovaná rozhraní Thunderbit leží výš ve stacku. Dokumentace Thunderbit popisuje extrakci podle URL s možnostmi renderování a směrování, zatímco Web Scraper API popisuje dva výstupní režimy: čistý Markdown z URL nebo JSON ve tvaru schématu. Tím se může výrazně zmenšit množství crawlerové a parsovací infrastruktury, kterou tým provozuje. Nevytváří to ale univerzální úspěch na cílech, neobchází to přístupové kontroly ani nerozhoduje o tom, zda je sběr dat oprávněný.
Nižší vrstvu proxy použijte, když potřebujete přímou kontrolu nad transportním chováním a jste připraveni se postarat o zbytek crawleru. Vyšší vrstvu extrakce použijte, když je skutečným požadavkem strukturovaný obsah stránek a zdokumentovaná hranice služby vám vyhovuje. Jsou to odlišné inženýrské odpovědnosti, ne dvě značky téhož proxy.
Hlavní poznatky
- HTTP proxy je prostředník pro přeposílání zpráv, ne automatická funkce soukromí nebo šifrování.
- Explicitní HTTP forwarding používá absolutní URI; HTTPS obvykle začíná požadavkem
CONNECT host:porta pak běží přes tunel s TLS. - Tunelovací proxy obvykle neumí číst HTTP tělo chráněné TLS, ale autorizovaná TLS-interception gateway je jiné nasazení.
- Forward/reverse a explicitní/interception popisují dvě různé osy.
- HTTP proxy, SOCKS5 a VPN porovnávejte podle rozsahu provozu, konfigurace, důvěry a směrovací politiky, ne podle univerzálních tvrzení o rychlosti nebo ceně.
- Pokud vám údaje k proxy nedal důvěryhodný správce nebo záměrně používaná aplikace, nechte proxy vypnutou.
- V automatizaci nastavte používání proxy explicitně, chraňte přihlašovací údaje, rozumějte pravidlům bypassu a precedence a při povinné proxy selžte uzavřeně.
Často kladené otázky
Je HTTP proxy to samé co VPN?
Ne. HTTP proxy poskytuje rozhraní pro přeposílání nebo tunelování s ohledem na HTTP aplikace, které si ji zvolí. VPN vytváří síťový tunel a mění směrování provozu zahrnutého její politikou. Samotná nálepka nic neprokazuje o anonymitě a split tunneling znamená, že pokrytí celého zařízení není univerzální.
Může HTTP proxy vidět HTTPS provoz?
V běžném tunelu CONNECT proxy jen přeposílá TLS bajty a chráněný HTTP obsah číst neumí. Může ale pozorovat metadata spojení. Pokud autorizovaná gateway ukončuje TLS pomocí CA, které spravovaný klient důvěřuje, může obsah kontrolovat, protože je jedním z endpointů dvou TLS spojení.
Co znamená 407 Proxy Authentication Required?
Proxy žádá klienta o přihlašovací údaje pro proxy. Je to něco jiného než výzva 401 od originu. Než pošlete přihlašovací údaje, zkontrolujte schválený způsob autentizace a chráněný kanál.
Skrývá HTTP proxy moji IP adresu?
Origin obvykle vidí připojení proxy jako svého přímého síťového protějška, ale to samo o sobě anonymitu nezaručuje. Forwardované hlavičky, autentizace, cookies, otisky, chování DNS i logy mohou klienta dál identifikovat.
Potřebuji proxy pro web scraping?
Ne vždy. Záleží na autorizovaném cíli, objemu požadavků, regionálních požadavcích, architektuře a zveřejněných pravidlech přístupu webu. Proxy může poskytnout směrování a řízení odchozího provozu; nenahrazuje ale autorizaci, throttling, parsování, monitoring ani práci s chybami.
Proč jedna aplikace ignoruje mou systémovou proxy?
Aplikace mohou používat různé zdroje konfigurace a různá pravidla precedence. Jedna se řídí OS, jiná má vlastní nastavení a nástroje z příkazové řádky často čtou proměnné prostředí samostatně. Podívejte se do dokumentace konkrétní aplikace a na její pravidla bypassu, ne jen do systémového panelu.
Learn More
