Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Serwer proxy to pośredniczący serwer, który znajduje się między klientem (takim jak aplikacja) i serwerem docelowym (takim jak interfejs API zaplecza). Po wysłaniu żądania przez aplikację serwer proxy odbierze go jako pierwszy. Serwer proxy może następnie przekazać żądanie do serwera docelowego, zmodyfikować go, zablokować lub zwrócić odpowiedź bezpośrednio.
Krótko mówiąc, serwer proxy działa w imieniu klienta lub serwera w celu pośredniczącej komunikacji.
Jak działa serwer proxy
Serwery proxy działają na poziomie HTTP (lub innych protokołów aplikacji) przez odbieranie żądań przychodzących i wykonywanie co najmniej jednej z następujących akcji:
- Przekazywanie żądania do serwera docelowego, a następnie przekazywanie odpowiedzi z powrotem do klienta.
- modyfikowanie nagłówków, adresów URL lub ładunków przed przekazaniem dalej.
- przechwytywanie i odpowiadanie na żądanie lokalnie bez kontaktu z serwerem docelowym.
- Odrzucanie żądania na podstawie reguł lub zasad dostępu.
Z perspektywy klienta po prostu wysyła żądanie do adresu URL. Serwer proxy obsługuje wszystkie inne elementy w tle. Wzorzec to klient, następnie proxy, a potem serwer docelowy.
Ten wzorzec wprowadza warstwę kontroli i abstrakcji, której można użyć do zwiększenia bezpieczeństwa, wglądu, wydajności i możliwości testowania.
Typy serwerów proxy
Istnieją różne typy serwerów proxy. Każdy z nich jest odpowiedni do określonych ról w architekturze systemu.
Przekazywanie serwera proxy
Serwer proxy typu forward znajduje się przed klientem . Gdy aplikacja wysyła żądanie, przechodzi przez serwer proxy, który decyduje, czy i jak przekazać je dalej. Serwery proxy przesyłania dalej są często używane do:
- Kontrolowanie dostępu do zasobów zewnętrznych.
- Anonimizuj ruch klienta.
- Rejestrowanie ruchu wychodzącego na potrzeby monitorowania.
- Zastosuj filtrowanie lub przekształcanie zawartości.
Zwrotny serwer proxy
Zwrotny serwer proxy znajduje się przed serwerem . Klienci nie wiedzą o podstawowej infrastrukturze zaplecza. Zwrotny serwer proxy odbiera żądania przychodzące i przekazuje je do jednego z kilku serwerów zaplecza. Odwrotne serwery proxy są często używane do:
- Równoważenie obciążenia ruchu między wieloma usługami.
- Obsługa buforowanych odpowiedzi w celu zmniejszenia obciążenia zaplecza.
- Kończenie połączeń TLS/SSL.
- Ukryj szczegóły usługi wewnętrznej w publicznej sieci.
Przezroczysty serwer proxy
Przezroczysty serwer proxy przechwytuje ruch bez jawnego skonfigurowania klienta do korzystania z niego. Ten typ jest używany w środowiskach firmowych lub internetowych dostawców usług w celu wymuszania zasad lub monitorowania użycia.
Dlaczego serwery proxy mają znaczenie dla deweloperów aplikacji
Często zespoły infrastruktury lub sieci zarządzają serwerami proxy. Jednak serwery proxy bezpośrednio wpływają na zachowanie aplikacji, zwłaszcza w środowiskach deweloperskich i testowych. Oto kilka praktycznych sposobów, w jaki wpływają one na codzienną pracę.
Debugowanie i obserwowanie
Serwery proxy mogą przechwytywać i sprawdzać ruch HTTP. Narzędzia takie jak Dev Proxy, Fiddler, Proxyman, Charles Proxy lub mitmproxy działają jako lokalne serwery proxy przekazujące. Aplikację można uruchamiać za pomocą nich, aby analizować żądania i odpowiedzi, wykrywać błędy i weryfikować nagłówki lub tokeny uwierzytelniania.
Brama interfejsu API i routing
W wielu systemach produkcyjnych ruch do zaplecza aplikacji jest kierowany przez bramę interfejsu API lub zwrotny serwer proxy, taki jak NGINX, lub natywną dla chmury usługę, taką jak Azure API Management. Te serwery proxy obsługują routing, uwierzytelnianie, ograniczanie szybkości i nie tylko.
Podczas projektowania interfejsu API lub tworzenia usług rozproszonych należy zrozumieć, jak serwery proxy wpływają na nagłówki (takie jak X-Forwarded-For), limity czasu i limity rozmiaru żądania.
Mechanizm CORS i programowanie lokalne
Podczas programowania lokalnego, zwłaszcza w aplikacjach internetowych, mogą wystąpić ograniczenia współużytkowania zasobów między źródłami (CORS) podczas wywoływania interfejsów API z przeglądarki. Proxy programistyczne może przekazywać żądania do docelowego interfejsu API, zmieniając nagłówki w celu obejścia ograniczeń mechanizmu CORS. Typowe przykłady narzędzi deweloperskich do ponownego zapisywania żądań CORS to vite, webpack-dev-serverlub niestandardowe oprogramowanie pośredniczące serwera proxy w strukturach, takich jak Express lub ASP.NET Core.
Wirtualizacja i testowanie usług
Serwery proxy mogą symulować interfejsy API zaplecza. Ta funkcja jest przydatna, gdy rzeczywista usługa jest niedostępna, niestabilna lub kosztowna do użycia podczas testowania. Przechwytując i wyśmiewając odpowiedzi, można przetestować zachowanie aplikacji w różnych scenariuszach, takich jak przekroczenia limitu czasu, błędy lub źle sformułowane dane.
Narzędzia, takie jak dev proxy lub niestandardowe implementacje serwera proxy, są często używane do tego celu w ramach integracji i testów kompleksowej.
Uwierzytelnianie i zabezpieczenia
Serwery proxy są często frontonem obrony w zabezpieczaniu aplikacji. Mogą wymuszać kontrole dostępu, wprowadzać nagłówki uwierzytelniania lub przerywać połączenia TLS/SSL. Jako deweloper ważne jest, aby wiedzieć, jak działa aplikacja, gdy znajduje się za serwerem proxy i jak uzyskiwać dostęp do nagłówków zawierających informacje o uwierzytelnianiu lub tożsamości.
Typowe zagadnienia dotyczące nagłówków i serwera proxy
Gdy żądanie przechodzi przez serwer proxy, niektóre nagłówki są dodawane lub modyfikowane w celu zachowania ważnych metadanych. Na przykład:
-
X-Forwarded-For: wskazuje oryginalny adres IP klienta. -
X-Forwarded-Proto: wskazuje oryginalny protokół (HTTP lub HTTPS). -
X-Forwarded-Host: wskazuje oryginalny host żądany przez klienta.
Gdy aplikacja działa za zwrotnym serwerem proxy, upewnij się, że framework lub platforma są skonfigurowane do ufania i prawidłowego interpretowania tych nagłówków.
Używanie serwera proxy do testowania sposobu obsługi błędów interfejsu API przez aplikację
Ponieważ serwer pośredniczący widzi każde żądanie wysyłane przez aplikację, może również odpowiedzieć na niektóre z nich błędem zamiast przekazywać je dalej: odpowiedzią 500, odpowiedzią 429 Too Many Requests z nagłówkiem Retry-After lub odpowiedzią, która trwa 8 sekund. Aplikacja nadal wywołuje rzeczywiste adresy URL interfejsu API, dlatego testujesz aplikację podczas jej działania w środowisku produkcyjnym, wraz z jej klientem HTTP, pakietem SDK i zasadami ponawiania prób.
W porównaniu z innymi sposobami testowania błędów interfejsu API:
| Approach | Co znajdziesz | Co tracisz |
|---|---|---|
| Poczekaj na produkcję | Rzeczywiste awarie | Wszystko, dopóki użytkownik go nie kliknie |
| Zamockuj interfejs API w testach lub pozwól agentowi programistycznemu napisać mock | Czy gałęzie błędów są uruchamiane | Rzeczywiste kody stanu, nagłówki i ciała błędów interfejsu API oraz zasady ponawiania prób zestawu SDK. Aplikacja wymaga również przełącznika tylko do testowania, aby połączyć się z mockiem. |
| Wywołaj rzeczywisty interfejs API i miej nadzieję, że zakończy się niepowodzeniem | Rzeczywiste zachowanie | Nie można wywołać awarii na żądanie |
| Uruchamianie aplikacji za pośrednictwem serwera proxy, który symuluje błędy | Błędy, dławienie i opóźnienia na rzeczywistych adresach URL, na żądanie | Twój kod w izolacji. Do tego użyj testów jednostkowych. |
Dev Proxy jako serwer proxy do celów deweloperskich i testowych.
Dev Proxy jest serwerem proxy pośredniczącym, uruchamianym na Twoim komputerze lub w CI w celu przechwytywania i modyfikowania żądań z Twojej aplikacji do wybranych interfejsów API. Za pomocą serwera proxy deweloperskiego można wykonywać następujące czynności:
- Zobacz, jak aplikacja reaguje na błędy interfejsu API.
- Sprawdź, jak aplikacja obsługuje limity szybkości interfejsu API i dławienie.
- Zobacz, jak aplikacja obsługuje powolne interfejsy API.
- Utwórz pozorowane interfejsy API bez pisania wiersza kodu.
- Uzyskaj wskazówki kontekstowe dotyczące korzystania z interfejsów API.
Aby wypróbować go w interfejsie API, które wywołuje aplikacja, pobierz ustawienie wstępne i uruchom Dev Proxy. Na przykład GitHub:
devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"
Ustawienia wstępne są również dostępne dla punktów końcowych openAI (openai-throttling), Anthropic (anthropic-throttling) i Microsoft Graph OneDrive i SharePoint (microsoft-graph-rate-limiting).
Spróbuj samodzielnie
Wybierz scenariusz pasujący do tego, co tworzysz:
- Testowanie sposobu obsługi błędów interfejsu API przez aplikację (5 minut)
- Symulowanie ograniczania szybkości dla dowolnego interfejsu API (10 minut)
- Mockowanie odpowiedzi API bez zmieniania kodu (10 minut)
- Używanie modelu lokalnego zamiast OpenAI podczas opracowywania (15 minut)