Otwórz ustawienia sieciowe w telefonie lub laptopie, a możesz znaleźć opcję HTTP Proxy z wyborem takim jak Wyłączone, Ręczne i Auto. Bezpieczna zasada jest prosta: jeśli zaufany administrator albo konkretna aplikacja nie podały Ci danych proxy, nie wymyślaj ich samodzielnie. Adres proxy nie jest przełącznikiem wydajności ani trybem prywatności. Zmienia po prostu to, dokąd trafiają Twoje żądania HTTP.
Ten niepozorny panel ustawień kryje zaskakująco szeroki temat. Proxy HTTP może egzekwować zasady firmowe, kierować wywołania API dewelopera, buforować współdzielone odpowiedzi albo tworzyć tunel dla HTTPS. Z drugiej strony reverse proxy może stać po przeciwnej stronie wymiany — przed witryną, a nie przed jej użytkownikami. Żadna z tych ról nie sprawia automatycznie, że połączenie staje się prywatne, anonimowe, szybkie lub autoryzowane.
Ten przewodnik wyjaśnia protokół, a nie marketingowe etykiety: czym jest proxy HTTP, co faktycznie płynie po łączu, czym CONNECT różni się od zwykłego przekazywania, gdzie w tym wszystkim mieści się SOCKS5 i VPN oraz jak diagnozować proxy bez przypadkowego zmieniania pięciu ustawień naraz.
Czym jest proxy HTTP?
Proxy HTTP to pośrednik, który odbiera żądanie HTTP i próbuje je obsłużyć, przekazując je dalej, zwracając zapisany wcześniej wynik, jeśli jest to dozwolone, albo odsyłając własną odpowiedź. RFC 9110 określa wybrany przez klienta proxy jako agenta przekazującego wiadomości. Klient zwykle poznaje je z ustawień aplikacji, ustawień systemu operacyjnego, pliku Proxy Auto-Configuration (PAC) albo zmiennych środowiskowych.
Dla jawnego forward proxy ścieżka wygląda tak:
klient ---> forward proxy ---> serwer źródłowy
<--- <---
Klient łączy się najpierw z proxy. Proxy otwiera albo ponownie wykorzystuje połączenie do celu. Serwer źródłowy zwykle widzi połączenie sieciowe proxy jako swojego bezpośredniego rozmówcę, ale sam ten fakt nie dowodzi anonimowości. Nagłówki, pliki cookie, odcisk przeglądarki, uwierzytelnione sesje, zachowanie DNS i logi nadal mogą ujawniać użytkownika lub organizację. „Serwer źródłowy widzi inny adres IP” i „użytkownik jest anonimowy” to dwie zupełnie różne tezy.
Proxy HTTP to również nie szyfrowanie. Zwykły HTTP pozostaje zwykłym HTTP, chyba że chroni go dodatkowa warstwa bezpieczeństwa. HTTPS może przechodzić przez proxy jako tunel TLS, ale szyfrowanie zapewnia TLS — nie samo słowo proxy.
Jak jawne proxy HTTP obsługuje żądanie
Najważniejsza różnica pojawia się w celu żądania. Gdy klient HTTP/1.1 łączy się bezpośrednio z serwerem źródłowym, zwykle wysyła format origin-form:
GET /reports/weekly HTTP/1.1
Host: example.com
Gdy ten sam klient wysyła zwykłe żądanie HTTP do jawnego proxy, RFC 9112 wymaga formatu absolute-form, aby proxy mogło rozpoznać cel:
GET http://example.com/reports/weekly HTTP/1.1
Host: example.com
Typowy przebieg wygląda tak:
- Klient wybiera proxy zgodnie z obowiązującymi regułami konfiguracji.
- Łączy się z proxy i wysyła żądanie, które wskazuje docelowy URI.
- Proxy może uwierzytelnić klienta, zastosować politykę, sprawdzić cache lub odrzucić żądanie.
- Jeśli przekazanie jest dozwolone, proxy wysyła odpowiednie żądanie do serwera źródłowego.
- Odpowiedź wraca przez proxy. Proxy może dodać metadane pośrednika, przekształcić wiadomość, jeśli jest to dozwolone, zapisać odpowiedź możliwą do cache’owania albo po prostu ją przekazać dalej.
Słowo „może” w tej liście ma znaczenie. HTTP definiuje możliwe zachowania i zasady współdziałania, ale nie gwarantuje, że każde proxy filtruje treści, buforuje odpowiedzi, przepisuje nagłówki czy ukrywa identyfikatory.
Jeśli proxy wymaga uwierzytelnienia, może odpowiedzieć kodem 407 Proxy Authentication Required. To co innego niż 401 Unauthorized: 407 dotyczy poświadczeń do proxy, a 401 — serwera źródłowego. RFC 9110 jasno rozróżnia te przypadki. Poświadczenia muszą też być przesyłane odpowiednim, chronionym kanałem; Basic authentication samo w sobie nie zapewnia poufności.
HTTPS przez proxy HTTP: CONNECT to tunel, nie szyfrowanie
Dla celu HTTPS klient zwykle prosi proxy o otwarcie tunelu TCP za pomocą CONNECT. Cel żądania ma formę authority-form — host i port, bez pełnego URL-a:
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Po poprawnej odpowiedzi połączenie staje się tunelem. Klient wykonuje następnie handshake TLS z example.com przez ten strumień bajtów:
klient == TLS ==[ proxy przekazuje bajty ]== punkt końcowy TLS u źródła
W tym zwykłym modelu tunelowania proxy może widzieć metadane połączenia, takie jak użytkownik proxy, adres docelowy, czas oraz liczba przesłanych bajtów, ale treść żądań i odpowiedzi HTTPS jest szyfrowana przez TLS. Sam tunel nie jest mechanizmem szyfrującym. To ważna różnica przy diagnozowaniu problemów: CONNECT może się udać, a później może nie przejść handshake TLS.
Niektóre zarządzane sieci stosują autoryzowaną inspekcję TLS. W takim modelu pośrednik kończy jedno połączenie TLS i tworzy drugie w stronę serwera źródłowego. Klient musi ufać urzędowi certyfikacji używanemu w takiej konfiguracji. Pośrednik może wtedy analizować treść HTTP, ponieważ sam jest punktem końcowym TLS, a nie dlatego, że wszystkie proxy HTTP potrafią magicznie czytać HTTPS. Powinno to być jawne, administrowane rozwiązanie na zarządzanych urządzeniach. Wyłączanie weryfikacji certyfikatu nie jest prawidłowym rozwiązaniem problemu z nieoczekiwanym błędem certyfikatu w środowisku produkcyjnym.
Po stronie proxy też istnieje granica bezpieczeństwa. Zezwolenie na CONNECT do dowolnych hostów i portów może zamienić proxy w drogę do usług, których nigdy nie miało ujawniać. Proxy produkcyjne powinno ograniczać cele i porty zgodnie ze swoim przeznaczeniem.
Forward, reverse, explicit i interception proxy
Nazwy proxy zaczynają być mylące, gdy dwa różne wymiary wrzuca się do jednej listy.
Pierwszy wymiar to kto wybiera pośrednika:
- Forward proxy jest wybierane w imieniu klienta. Steruje lub wspiera ruch wychodzący z tego klienta lub sieci.
- Reverse proxy, nazywane w semantyce HTTP bramą, stoi przed jednym lub wieloma serwerami źródłowymi. Odwiedzający korzysta z publicznej usługi; brama wybiera backend, kończy TLS, buforuje kwalifikujące się odpowiedzi albo stosuje zasady po stronie serwera.
Drugi wymiar to w jaki sposób ruch trafia do pośrednika:
- Explicit proxy jest znane z konfiguracji klienta. Klient celowo formatuje dla niego żądania albo otwiera tunel
CONNECT. - Interception proxy otrzymuje ruch przekierowany przez sieć bez zwykłej, jawnej konfiguracji proxy po stronie klienta.
Te nazwy mogą się nakładać. Firmowe forward proxy może być jawne. Brama sieciowa może przechwytywać wybrany ruch wychodzący. Reverse proxy jest zwykle niewidoczne dla odwiedzającego jako osobny skok, choć nadal jest serwerem, z którym łączy się klient.
Interception to nie po prostu „jawne proxy bez ekranu ustawień”. Może ono zaburzać założenia dotyczące adresów docelowych, uwierzytelniania, TLS i path MTU. Wskazówki Squid dotyczące interception opisują kilka z tych ograniczeń operacyjnych. Jeśli sieć nie jest w stanie ich spełnić, skutkiem bywa tajemnicza częściowa awaria zamiast czytelnego komunikatu o błędzie (ulubiony rodzaj awarii każdego admina).
Określenia takie jak anonymous, elite i high-anonymity należą głównie do katalogów dostawców. Nie są formalnymi możliwościami HTTP. Zamiast traktować etykietę jako gwarancję bezpieczeństwa, oceniaj obserwowalne zachowanie, którego potrzebujesz — nagłówki, adresy wyjściowe, uwierzytelnianie, logowanie, rozwiązywanie DNS i politykę tunelowania.
Proxy HTTP vs. SOCKS5 vs. VPN
Nie istnieje obronna, uniwersalna hierarchia, według której jedno z tych rozwiązań zawsze byłoby szybsze, tańsze albo bardziej prywatne. Wydajność zależy od odległości, przeciążenia, szyfrowania, implementacji, protokołu i celu. Koszt zależy od dostawcy i wdrożenia. Lepiej porównywać granice kontroli.
| Pytanie | Proxy HTTP | Proxy SOCKS5 | VPN |
|---|---|---|---|
| Z jakiego interfejsu korzysta klient? | Przekazywanie HTTP i zwykle tunelowanie CONNECT | Komendy protokołu SOCKS | Wirtualny/sieciowy tunel zarządzany przez system operacyjny lub klienta VPN |
| Jakiego ruchu to dotyczy? | Ruch z aplikacji obsługujących skonfigurowane proxy HTTP | TCP, a także UDP przy wsparciu klienta i serwera | Ruch wybrany przez routing i zasady split-tunnel |
| Czy mechanizm gwarantuje szyfrowanie treści? | Nie | Nie | Tunel VPN zwykle chroni ruch w swoim zdefiniowanym zakresie, ale nadal liczy się protokół i polityka |
| Gdzie jest zwykle konfigurowany? | Aplikacja, system, PAC/WPAD albo zmienne środowiskowe | Per aplikacja lub biblioteka | System operacyjny lub klient VPN, czasem per aplikacja |
| Kto rozwiązuje DNS dla celu? | Zależy od klienta, trybu żądania i implementacji | Zależy od tego, jak klient przekazuje cel | Zależy od routingu VPN i polityki DNS |
| Najważniejsze pytanie decyzyjne | Czy ta aplikacja HTTP potrzebuje pośrednika? | Czy ta aplikacja potrzebuje bardziej ogólnego interfejsu pośredniczącego? | Które trasy urządzenia lub aplikacji mają wejść do szyfrowanego tunelu sieciowego? |
SOCKS5 definiuje CONNECT, BIND i UDP ASSOCIATE. To czyni go bardziej ogólnym niż przekazywanie specyficzne dla HTTP, ale nadal nie obiecuje szyfrowania ani anonimowości. Bezpieczeństwo zależy od uwierzytelniania, ewentualnego zewnętrznego chronionego kanału, zachowania końcówek i operatora.
VPN zwykle działa na szerszej granicy sieci, ale twierdzenie, że „VPN zawsze przenosi każdy bajt z urządzenia”, jest błędne. Split tunneling może obejmować lub wykluczać konkretne trasy albo aplikacje. Dokumentacja wdrażania VPN firmy Apple to jeden z przykładów platformy wspierającej zakresowe zachowanie VPN.
Wybieraj na podstawie zakresu i zaufania, a nie jednowyrazowej etykiety. Jeśli tylko jeden klient HTTP potrzebuje firmowej bramy, VPN obejmujący całe urządzenie może być zbędny. Jeśli kilka aplikacji ma mieć dostęp do prywatnej sieci, osobne konfiguracje proxy HTTP mogą być złym modelem abstrakcji.
Czy ustawienie HTTP Proxy powinno być włączone, czy wyłączone?
Na niezarządzanej sieci domowej zostaw je wyłączone, chyba że zaufana usługa, której używasz celowo, poda adres, port i metodę uwierzytelniania. Włączenie przypadkowego publicznego proxy kieruje ruch do operatora, którego nie zweryfikowałeś.
Na zarządzanym urządzeniu firmowym lub szkolnym postępuj zgodnie z aktualnymi instrukcjami administratora. Nie usuwaj nieznanej konfiguracji, zanim nie sprawdzisz zarządzania urządzeniem, klienta VPN/zabezpieczeń albo administratora. Proxy może być częścią kontroli dostępu; jego usunięcie może zepsuć dostęp albo naruszyć zasady, nawet jeśli zwykłe przeglądanie wydaje się potem działać.
„Auto” zwykle oznacza adres PAC albo mechanizm automatycznego wykrywania. Plik PAC to JavaScript, który może zwracać różne trasy dla różnych URL-i — na przykład wysłać wewnętrzny host przez proxy, a do publicznej witryny połączyć się bezpośrednio. To oznacza, że przeglądarka może działać dla jednego celu i zawodzić dla innego przy tym samym widocznym ustawieniu.
Dokładne menu zmieniają się między wersjami, więc korzystaj z aktualnej dokumentacji producenta, a nie z zrzutu ekranu ze starego artykułu. Trwałe pytania są takie:
- Czy ustawienie jest zarządzane przez organizację, czy wpisane przez użytkownika?
- Czy jest Manual, PAC/Auto, czy specyficzne dla aplikacji?
- Jakie protokoły i cele obejmuje?
- Czy istnieją reguły obejścia, takie jak
NO_PROXYalbo „exclude simple hostnames”? - Która konfiguracja wygrywa, gdy aplikacja, system, środowisko i PAC się nie zgadzają?
To ostatnie pytanie zależy od klienta. Chrome/Chromium zwykle integruje się z systemowym rozwiązywaniem proxy, ale ma też własne, opisane reguły. Firefox może używać własnych ustawień połączenia. Narzędzia wiersza poleceń często czytają zmienne środowiskowe niezależnie. Sama konfiguracja proxy w systemie nie dowodzi więc, że każda aplikacja z niego korzysta.
Korzystanie z proxy HTTP w curl i Pythonie
Dla jednorazowego żądania opcja --proxy w curl jasno pokazuje wybór:
curl --fail-with-body --show-error \
--proxy 'http://proxy.example:8080' \
'https://api.example.com/health'
Jeśli wymagane jest uwierzytelnienie, nie umieszczaj prawdziwych sekretów w plikach źródłowych, historii powłoki, zrzutach ekranu ani przykładach w artykułach. Użyj mechanizmu poświadczeń zatwierdzonego w Twoim środowisku. Ten przykład celowo używa placeholderów:
curl --fail-with-body --show-error \
--proxy 'http://proxy.example:8080' \
--proxy-user "$PROXY_USER:$PROXY_PASSWORD" \
'https://api.example.com/data'
W automatyzacji długotrwałej stosuj zasadę fail closed. Jeśli polityka mówi, że żądanie musi przejść przez proxy, nie przechwytuj błędu proxy i nie próbuj po cichu łączyć się bezpośrednio. Awaryjne przejście na połączenie bezpośrednie może ujawnić adres wyjściowy klienta albo ominąć politykę dostępu.
Python Requests przyjmuje jawne mapowanie:
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())
Klucz https powyżej oznacza „użyj tego proxy dla celu HTTPS”; nie oznacza to koniecznie, że klient zestawia TLS do proxy. Adres http:// proxy nadal może przyjmować CONNECT i tunelować TLS do serwera źródłowego. Requests opisuje również wsparcie dla zmiennych środowiskowych oraz obsługę bundle’i CA w swoim zaawansowanym przewodniku po proxy.
Zachowanie zmiennych środowiskowych nie jest idealnie jednolite. curl celowo akceptuje małe http_proxy, podczas gdy inne zmienne i narzędzia mogą przyjmować inną wielkość liter. Dopasowanie NO_PROXY, obsługa CIDR, wiodących kropek, portów, zachowanie loopback i kolejność pierwszeństwa różnią się. Traktuj dokumentację konkretnego środowiska uruchomieniowego jako obowiązującą umowę. Nie zakładaj, że działające polecenie curl dowodzi, iż Requests, Go, przeglądarka i kontener wybiorą tę samą trasę.
Unikaj też tej „naprawy”:
# Nie używaj tego, aby ukryć problem z certyfikatem w produkcji.
requests.get("https://api.example.com", verify=False)
Jeśli autoryzowane proxy inspekcyjne korzysta z prywatnego CA, zainstaluj lub wskaż właściwy zestaw zaufania. Jeśli proxy nie jest autoryzowane, zatrzymaj się i zdiagnozuj problem.
Diagnozowanie proxy HTTP warstwa po warstwie
Problemy z proxy stają się bardziej zarządzalne, gdy testujesz jedną warstwę naraz:
- Wybór konfiguracji: Sprawdź, z którego źródła proxy korzysta faktycznie uszkodzona aplikacja — ustawienia ręczne, systemowe, PAC, zmienne środowiskowe czy własna konfiguracja. Zweryfikuj reguły obejścia.
- Rozwiązywanie nazw: Ustal, czy klient rozwiązuje cel lokalnie, czy wysyła nazwę hosta, aby proxy rozwiązało ją samo. Przetestuj osobno nazwę hosta proxy.
- Dostępność TCP: Czy klient może połączyć się z hostem i portem proxy? Timeout na tym etapie nie jest błędem HTTP.
- Uwierzytelnianie proxy:
407oznacza, że proxy żąda poświadczeń. Nie myl tego z401od serwera źródłowego. - Przekazywanie HTTP: Dla zwykłego celu HTTP sprawdź kod odpowiedzi i to, czy żądanie używa poprawnego targetu w formacie absolute-form.
- Polityka CONNECT: Dla HTTPS upewnij się, że proxy zezwala na dany host i port. Odrzucony tunel nigdy nie osiąga etapu TLS.
- TLS: Po udanym CONNECT sprawdź tożsamość certyfikatu, łańcuch zaufania, negocjację protokołu i to, czy autoryzowana inspekcja jest w ogóle spodziewana.
- Odpowiedź serwera źródłowego:
403,404lub429z celu nie oznacza automatycznie błędu proxy — i nie uprawnia do zmiany tożsamości ani obchodzenia kontroli.
Niektóre pośredniki emitują opcjonalne pole Proxy-Status z danymi diagnostycznymi. Korzystaj z niego, jeśli jest dostępne, ale nie buduj całej diagnostyki wyłącznie na nim. Logi klienta, proxy i serwera źródłowego pozostają najpewniejszym sposobem ustalenia, który przeskok zawiódł.
A co z cache proxy?
Współdzielony cache jest użyteczny, ale działa warunkowo, a nie automatycznie. RFC 9111 wymaga, aby współdzielony cache uwzględniał metodę, klucz cache, świeżość, dyrektywy odpowiedzi, autoryzację i zasady rewalidacji, zanim ponownie użyje odpowiedzi.
Cztery dyrektywy są często błędnie interpretowane:
privatemówi współdzielonemu cache, aby nie przechowywał odpowiedzi (lub wskazanych pól).no-storemówi cache’om, aby nie przechowywały wiadomości, ale RFC wyraźnie ostrzega, że nie jest to pełny mechanizm prywatności.no-transformprosi pośredników, aby nie przekształcali reprezentacji.proxy-revalidatewpływa na ponowne użycie po zestarzeniu się zapisanej odpowiedzi; nie sprawia, że odpowiedź, której nie da się cache’ować, nagle staje się cache’owalna.
Tunelowane HTTPS end-to-end jest dla forward proxy nieprzezroczyste, więc takie proxy nie może działać jako cache treści HTTP dla zaszyfrowanych wiadomości wewnątrz tunelu. Reverse proxy lub autoryzowana brama kończąca TLS to zupełnie inna architektura.
Proxy HTTP, web scraping i Thunderbit
Systemy do zbierania danych mogą używać proxy do kontrolowanego ruchu wychodzącego, routingu regionalnego, separacji obciążeń albo stabilnej tożsamości sieciowej. To są możliwości routingu, a nie przepustki do wszystkiego. Proxy nie daje uprawnienia do zbierania strony, obchodzenia kontroli dostępu ani gwarancji, że cel zaakceptuje żądanie. Kody statusu takie jak 403 i 429 albo CAPTCHA wymagają obsługi zgodnej z polityką — nie automatycznego przepisu „zmień typ proxy”.
Jest też wybór poziomu abstrakcji. Surowe forward proxy daje deweloperowi interfejs routingu lub tunelowania HTTP. Sama aplikacja nadal odpowiada za pobieranie, renderowanie, parsowanie, walidację schematu, ponawianie prób, obserwowalność i decyzje zgodnościowe.
Interfejsy Thunderbit działają wyżej w stosie. Dokumentacja Thunderbit opisuje ekstrakcję opartą na URL z renderowaniem i routingiem, a Web Scraper API dokumentuje dwa tryby wyjścia: czysty Markdown z URL albo JSON zgodny ze schematem. Może to zmniejszyć ilość infrastruktury crawlera i parserów, którą musi utrzymywać zespół. Nie daje jednak uniwersalnego sukcesu na każdym celu, nie omija kontroli dostępu ani nie rozstrzyga, czy zbieranie danych jest autoryzowane.
Użyj niższego poziomu proxy, gdy potrzebujesz bezpośredniej kontroli nad zachowaniem transportu i jesteś gotowy przejąć odpowiedzialność za resztę crawlera. Użyj interfejsu ekstrakcji wyższego poziomu, gdy rzeczywistym wymaganiem są ustrukturyzowane dane strony, a udokumentowany zakres usługi pasuje do zadania. To różne obowiązki inżynierskie, a nie dwie marki tego samego proxy.
Najważniejsze wnioski
- Proxy HTTP to pośrednik przekazujący wiadomości, a nie automatyczna funkcja prywatności czy szyfrowania.
- Jawne przekazywanie HTTP używa URI absolutnego; HTTPS zwykle zaczyna się od żądania
CONNECT host:port, a potem prowadzi TLS przez tunel. - Proxy tunelujące zwykle nie może odczytać treści HTTP chronionej przez TLS, ale autoryzowana brama przechwytująca TLS to odrębne wdrożenie.
- Forward/reverse oraz explicit/interception opisują osobne osie.
- Proxy HTTP, SOCKS5 i VPN należy porównywać pod kątem zakresu ruchu, konfiguracji, zaufania i polityki routingu — nie uniwersalnej szybkości czy kosztu.
- Jeśli zaufany administrator albo świadomie używana aplikacja nie podała Ci danych proxy, zostaw ustawienie proxy wyłączone.
- W automatyzacji ustaw użycie proxy jawnie, chroń poświadczenia, rozumiej zasady obejścia i pierwszeństwa oraz stosuj fail closed, gdy proxy jest obowiązkowe.
FAQ
Czy proxy HTTP to to samo co VPN?
Nie. Proxy HTTP zapewnia interfejs przekazywania lub tunelowania rozumiejący HTTP dla aplikacji, które je wybierają. VPN tworzy tunel sieciowy i zmienia routing dla ruchu objętego jego polityką. Sama etykieta nie dowodzi anonimowości, a split tunneling w VPN oznacza, że pokrycie całego urządzenia nie jest uniwersalne.
Czy proxy HTTP może widzieć ruch HTTPS?
W zwykłym tunelu CONNECT proxy przekazuje bajty TLS i nie może czytać chronionej treści HTTP. Może jednak obserwować metadane połączenia. Jeśli autoryzowana brama kończy TLS przy użyciu CA zaufanego przez zarządzanego klienta, może analizować treść, ponieważ jest jednym z końców dwóch połączeń TLS.
Co oznacza 407 Proxy Authentication Required?
Proxy prosi klienta o poświadczenia do proxy. To coś innego niż 401 od serwera źródłowego. Zanim wyślesz poświadczenia, sprawdź zatwierdzoną metodę uwierzytelniania i chroniony kanał.
Czy proxy HTTP ukrywa mój adres IP?
Serwer źródłowy zwykle widzi połączenie z proxy jako swojego bezpośredniego sąsiada w sieci, ale to nie oznacza anonimowości. Przekazywane nagłówki, uwierzytelnianie, pliki cookie, fingerprinty, zachowanie DNS i logi mogą nadal identyfikować klienta.
Czy potrzebuję proxy do web scrapingu?
Nie zawsze. Odpowiedź zależy od autoryzowanego celu, wolumenu żądań, wymagań regionalnych, architektury i opublikowanych zasad dostępu witryny. Proxy może zapewnić routing i kontrolę wyjścia; nie zastępuje autoryzacji, limitowania, parsowania, monitorowania ani obsługi błędów.
Dlaczego jedna aplikacja ignoruje moje proxy systemowe?
Aplikacje mogą korzystać z różnych źródeł konfiguracji i reguł pierwszeństwa. Jedna może respektować system operacyjny, inna własne ustawienia, a narzędzie wiersza poleceń może czytać zmienne środowiskowe. Sprawdź dokumentację wadliwej aplikacji i jej reguły obejścia, zamiast zakładać, że panel systemowy kontroluje wszystko.
Dowiedz się więcej
