Pojęcie reverse proxy wywodzi się z praktyki separowania ról w infrastrukturze internetowej: jedna warstwa systemu przyjmuje żądania od użytkowników, a inna je przetwarza. Taki podział porządkuje ruch, odciąża aplikacje, a przy tym pozwala wdrażać polityki i optymalizacje, których nie sposób wygodnie i bezpiecznie dodać bezpośrednio w kodzie aplikacji. Reverse proxy bywa nazywany bramą do serwisów – punktem styku, który tłumaczy protokoły, dba o połączenia, pośredniczy w uwierzytelnianiu, buforuje odpowiedzi i mierzy przepływ danych. Z perspektywy firm hostingowych oraz administratorów serwerów to narzędzie, które realnie podnosi wydajność, wzmacnia bezpieczeństwo, ułatwia skalowalność i poprawia dostępność usług bez konieczności rozbijania istniejących aplikacji na części pierwsze.

Gdzie w architekturze działa reverse proxy i czym różni się od forward proxy

Reverse proxy stoi po stronie serwera i reprezentuje grupę usług wobec świata zewnętrznego. Klient (przeglądarka, aplikacja mobilna, integracja API) widzi jeden adres i jeden certyfikat, a reverse proxy wewnątrz sieci kieruje żądania do właściwych serwerów aplikacyjnych. To przeciwieństwo forward proxy, które stoi po stronie użytkownika i pośredniczy w jego ruchu do internetu (np. proxy korporacyjne, filtry treści). Z punktu widzenia operatora hostingu reverse proxy jest centralnym zakończeniem sesji sieciowych, miejscem, w którym optymalizuje się połączenia TCP/QUIC, wdraża reguły routingu i egzekwuje zasady bezpieczeństwa.

W praktyce reverse proxy może działać na warstwie 4 (L4: TCP/UDP) lub 7 (L7: HTTP, gRPC, WebSocket). Na L4 decyduje na podstawie adresów i portów, jest bardzo szybkie, ale ma ograniczoną świadomość protokołu. Na L7 rozumie nagłówki, metody, ścieżki, może przepisywać URL, dołączać i usuwać nagłówki, stosować kompresję czy buforowanie. Ten drugi wariant jest typowy dla hostingu stron WWW i API, bo umożliwia złożone polityki ruchu.

Reverse proxy często kończy TLS (terminacja TLS), czyli przejmuje ciężar kryptografii i negocjacji protokołów (HTTP/2, HTTP/3/QUIC), a następnie przekazuje ruch do aplikacji zwykle już w sieci wewnętrznej. Dzięki temu można scentralizować cykl życia certyfikatów, wymuszać modernizację szyfrów i utrzymywać zgodność z normami branżowymi. Dodatkowo reverse proxy agreguje połączenia (connection pooling), utrzymuje Keep-Alive, co zmniejsza koszt zestawiania sesji po stronie aplikacji oraz pozwala lepiej wykorzystać zasoby sprzętowe.

Dlaczego reverse proxy to fundament nowoczesnego hostingu

Z perspektywy dostawcy hostingu (shared, VPS, chmura) jedna warstwa tworzy jednolity front dla setek lub tysięcy serwisów, a za nią można dowolnie skalować węzły aplikacyjne. Reverse proxy rozwiązuje kilka praktycznych problemów: deficyt adresów IPv4 (wiele vhostów pod jednym IP dzięki SNI), różne stosy technologiczne (PHP, Node.js, Python, Go) działające obok siebie, separację klientów, kontrolę limitów, optymalizację kosztów transferu i mocy CPU.

W środowisku firmowym lub u operatora hostingu reverse proxy jest też miejscem egzekwowania polityk zgodności: wymuszanie HSTS, redirekcje do HTTPS, ustawianie nagłówków bezpieczeństwa (CSP, X-Frame-Options, Referrer-Policy), standaryzacja logowania, a nawet anonimizacja adresów IP. Jeden punkt konfiguracji i audytu upraszcza operacje i ogranicza ryzyko błędów rozproszonych po dziesiątkach serwerów.

Kluczowe korzyści: wydajność, bezpieczeństwo i kontrola ruchu

Optymalizacja transportu i zasobów

Reverse proxy skraca drogę danych i zmniejsza narzut protokołów przez utrzymywanie trwałych połączeń z klientami i serwerami, negocjację nowoczesnych protokołów, kompresję transmisji oraz inteligentne buforowanie. Pozwala to osiągnąć niższe opóźnienia, lepsze wykorzystanie CPU na backendach i większy throughput per węzeł. W serwisach o ruchu sezonowym umożliwia to elastyczne skalowanie w górę i w dół bez wprowadzania przerw.

Kierowanie ruchem i reguły aplikacyjne

Najczęściej stosowaną funkcją jest balansowanie ruchu między wieloma serwerami backend. Reverse proxy potrafi wybierać cel na podstawie wagi (weighted), konsystentnego haszowania (affinity do użytkownika, koszyka), stanu zdrowia węzła (health checks), a nawet obserwowanych metryk opóźnień. Daje to podstawy do canary deployment, blue/green, a także mitygacji awarii przez szybkie wyłączanie niesprawnych instancji i przekierowanie ruchu gdzie indziej.

Buforowanie i skracanie czasu odpowiedzi

Strategicznie użyte cache może zredukować liczbę zapytań do aplikacji o rząd wielkości. Reverse proxy respektuje lub nadpisuje politykę cache’owania (Cache-Control, Expires, ETag, Last-Modified), rozróżnia odpowiedzi publiczne i prywatne, a w bardziej zaawansowanych scenariuszach stosuje stale-while-revalidate i stale-if-error, by utrzymać responsywność nawet podczas przeciążeń zaplecza. W połączeniu z purgem na żądanie (surrogate keys) cache staje się wydajnym buforem publikacji treści.

Wzmocnienie bezpieczeństwa i kontrola ryzyka

Reverse proxy to naturalne miejsce do implementacji firewalli aplikacyjnych, kontroli przepustowości i izolowania awarii. Polityki rate limiting, ochrona przed nadużyciami API, blokowanie automatycznych skanerów, a także reguły WAF oparte o OWASP CRS znacząco podnoszą próg wejścia dla atakujących. W tym miejscu egzekwuje się też nagłówki bezpieczeństwa, inspekcję protokołów, ograniczenia rozmiaru żądań i liczbę równoległych połączeń.

Jeśli terminacja połączeń szyfrowanych odbywa się na brzegu, to reverse proxy staje się centralnym miejscem utrzymywania polityk kryptograficznych, wymuszania poziomu szyfrów, włączania HSTS, OCSP stapling, a także 0-RTT tam, gdzie jest to akceptowalne i bezpieczne. Dla wielu działów compliance to klucz do spełnienia wymogów branżowych i audytów.

Mechanika routingu: jak reverse proxy podejmuje decyzje

Silniki reverse proxy analizują schemat (http/https), metodę, ścieżkę, nagłówki, parametry zapytań, a czasem treść żądania. Na tej podstawie wybierają pulę backendów i konkretny serwer. Możliwe jest routowanie domenowe (wirtualne hosty dla wielu witryn pod jednym adresem IP), ścieżkowe (np. /api, /static), wersjonowanie API, a także kierowanie na podstawie geolokalizacji lub sygnatur klienta. W środowiskach wielodomenowych to prosty i skalowalny sposób łączenia wielu serwisów w jedną przestrzeń adresową.

Ważna jest też obsługa nagłówków przekazujących informację o kliencie: X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host lub standaryzowany Forwarded. To one pozwalają aplikacjom uzyskać prawdziwy adres IP użytkownika i właściwy schemat, nawet jeśli połączenie wewnątrz sieci jest nieszyfrowane. Brak tych nagłówków bywa źródłem błędów logiki biznesowej (np. generowanie złych URL-i) oraz problemów z analizą incydentów.

Bezpieczeństwo: od twardnienia konfiguracji po ochronę warstwy aplikacji

Warstwa transportowa i polityki kryptograficzne

Centralizacja certyfikatów upraszcza ich odnowienia (np. ACME), rotacje kluczy, weryfikację domen oraz wymuszanie polityk zgodnych z rekomendacjami branżowymi. Reverse proxy dobiera zestawy szyfrów, włącza HSTS, weryfikuje SNI, a przy odpowiedniej konfiguracji wspiera również wzajemne uwierzytelnianie (mTLS) dla połączeń B2B lub wewnętrznych usług o podwyższonych wymaganiach.

Ochrona aplikacji

Silniki WAF wykrywają typowe wzorce ataków (SQLi, XSS, RCE) i potrafią je zablokować na wejściu. Rate limiting i polityki anty-botowe chronią zasoby przed drenażem i nadużyciami. Reverse proxy może także sanityzować nagłówki, usuwać te hop-by-hop i pilnować limitów rozmiaru nagłówków oraz ciała żądań, co przeciwdziała atakom polegającym na rozciąganiu lub fragmentacji zapytań.

Separacja i zgodność

Jedna warstwa wejściowa umożliwia implementację mechanizmów prywatności: maskowanie IP w logach, retencję danych, filtrowanie pól mogących zawierać PII, a także egzekwowanie polityk regionalnych (np. geoblokowanie). Dla organizacji podlegających audytom to cenna możliwość centralnego dowodzenia zgodnością.

Wydajność: cache, kompresja i protokoły

Utrzymanie wysokiej przepustowości przy niskich opóźnieniach to połączenie kilku technik. Kompresja (gzip, brotli) minimalizuje wolumen danych, o ile treść jest do tego podatna. HTTP/2 i HTTP/3 eliminują część ograniczeń HTTP/1.1, poprawiają współdzielenie połączeń i redukują latencję pierwszego bajtu. Do tego dochodzi zarządzanie buforami i kolejkami oraz backpressure na wypadek przeciążenia.

Największą dźwignią bywa jednak efektywne cache’owanie po stronie reverse proxy. Poprzez prawidłowe ustawienie TTL, korzystanie z walidacji warunkowej (If-None-Match, If-Modified-Since) i kontrolę nagłówków Vary można znacząco ograniczyć obciążenie backendu. W środowiskach publikacyjnych szczególnie pomocne są klucze zastępcze (surrogate keys) pozwalające na precyzyjne czyszczenie pamięci podręcznej w reakcji na zmianę treści.

Reverse proxy może też robić streaming odpowiedzi, co skraca czas do pierwszego bajtu i daje użytkownikowi wrażenie szybszego działania aplikacji. Dla dużych plików ważne jest odciążenie aplikacji dzięki temu, że reverse proxy czyta z dysku lub z upstreamu i jednocześnie wysyła do klienta, nie blokując wątku aplikacyjnego.

Architektury wielowarstwowe: mikroserwisy, orkiestracja i edge

W miarę rozwoju usług backend często ewoluuje do zestawu mikroserwisów. Każdy odpowiada za swój fragment logiki, wymaga odrębnych polityk routingu i bezpieczeństwa, a do tego ma swój cykl wdrożeń. Reverse proxy agreguje je w spójne API dla świata zewnętrznego. Ułatwia to zarządzanie wersjami, eksperymentami i migracjami bez zakłócania pracy klientów.

W środowiskach kontenerowych popularne jest korzystanie z kontrolerów Ingress i bram L7. Tutaj reverse proxy pełni rolę wyjścia na zewnątrz całego klastra, a dynamiczna konfiguracja powstaje na bazie adnotacji i obiektów orkiestratora. To pozwala programistom deklaratywnie opisywać polityki ruchu, jednocześnie zachowując separację odpowiedzialności między aplikacją a infrastrukturą.

Na brzegu sieci (edge) reverse proxy łączy się z CDN, by skrócić drogę do użytkownika. Węzły brzegowe mogą przejmować część logiki: walidację tokenów, wstępne filtrowanie, a nawet proste transformacje odpowiedzi wykonywane bardzo blisko klienta. W rezultacie spada obciążenie regionu macierzystego i poprawia się globalny czas odpowiedzi.

Rola protokołów: HTTP/2, HTTP/3, gRPC, WebSocket

Reverse proxy jest tłumaczem protokołów. Potrafi przyjąć HTTP/3 od klienta i komunikować się z backendem po HTTP/1.1, utrzymując transparentność sesji. Może proxy’ować gRPC, wymagające stałych kanałów i strumieniowania, jak również WebSocket – ważny dla aplikacji czasu rzeczywistego (czaty, trading, gry). Odpowiednie dostrojenie limitów ramek, strumieni i czasów oczekiwania zabezpiecza aplikacje przed przeciążeniami i rozłączaniem sesji.

Operacje i niezawodność: od health checków do drenażu połączeń

Niezawodność zaczyna się od właściwych health checków: proste TCP/HTTP, ale najlepiej kontrole wiedzące, czy usługa faktycznie odpowiada poprawnie. Reverse proxy powinno dynamicznie wyłączać słabe węzły i stopniowo wprowadzać nowe (slow start). Drenaż połączeń umożliwia łagodne wyłączenie instancji podczas wdrożeń. Warto także wdrożyć mechanizmy retry tylko dla operacji idempotentnych, z backoff i jitter, aby nie tworzyć fal przeciążenia.

Limity i time-outy są równie ważne: maksymalny rozmiar nagłówków, czas oczekiwania na odpowiedź, limity połączeń na klienta i na upstream. Dzięki nim reverse proxy broni się przed powolnymi klientami i potrafi przewidywalnie zachowywać się podczas skoków ruchu. To miejsce na strategię circuit breaker, która odcina wadliwy serwis i kieruje ruch do wersji zapasowej lub zwraca kontrolowaną degradację.

Praktyczne scenariusze wdrożeń w hostingu i u operatorów

• Współdzielony hosting stron: jeden reverse proxy obsługuje setki domen, zarządza certyfikatami, izoluje limity zasobów i zapewnia modernizację protokołów bez dotykania serwisów klientów.
• Sklepy internetowe: buforowanie treści publicznych (kategorie, karty produktów bez danych spersonalizowanych), separacja ścieżek API koszyka z affinity do użytkownika, ochrona przed botami i skanerami.
• Platformy SaaS: routowanie po subdomenach klientów, ograniczanie prędkości na klucz API, walidacja JWT już na brzegu, aby oszczędzać zasoby backendu.
• Media i streaming: serwowanie plików statycznych z bufora reverse proxy, segmentacja HLS/DASH, kontrola zasięgu (geoblocking) i obsługa przerw w łączności.
• Legacy modernizacja: stare aplikacje HTTP/1.1 za reverse proxy z nowoczesnym HTTPS, redirekcje, kompresja i nagłówki bezpieczeństwa bez modyfikacji kodu.

Typowe pułapki i jak ich uniknąć

Najczęściej popełniany błąd to utrata adresu IP klienta. Jeśli backend nie widzi X-Forwarded-For (lub Forwarded), logika rate limitów i analityka mogą być bezużyteczne. W niektórych środowiskach warto włączyć PROXY protocol między warstwami, aby zachować metadane po stronie L4.

Drugi obszar to błędy związane z cache’owaniem: przypadkowe buforowanie treści prywatnych, ignorowanie Vary i różnic w kompresji, zanieczyszczanie wspólnej pamięci podręcznej przez różne warianty językowe lub mobilne. Pomagają tutaj rygorystyczne reguły, weryfikacja nagłówków i testy obciążeniowe z kontrolą wskaźnika trafień.

Bardzo istotna jest odporność na request smuggling (błędy CL/TE), czyli niespójności w interpretacji długości ciała żądania między reverse proxy a backendem. Zasady: ujednolicać interpretację, odrzucać dwuznaczne nagłówki, stale aktualizować oprogramowanie i korzystać z dojrzałych, przetestowanych ścieżek parsowania HTTP.

Nie można też zapominać o szczegółach HTTP/2: limity strumieni, ochrona przed atakami wolnego nagłówka i przeciążeniem inicjowania ramek. Dla WebSocket i SSE kluczowe są poprawne time-outy i monitorowanie liczby aktywnych sesji, aby uniknąć wyczerpania deskryptorów czy pamięci.

Wybór narzędzia: od klasycznych serwerów po zarządzane usługi

Na rynku królują dojrzałe silniki reverse proxy. NGINX słynie z wydajnej pętli zdarzeń, elastyczności konfiguracji i rozbudowanej ekosfery modułów. HAProxy oferuje znakomite algorytmy równoważenia, bogate statystyki i stabilność pod dużym ruchem. Envoy wprowadza dynamiczną konfigurację (xDS), silną integrację z gRPC i świetną telemetrię, co czyni go wygodnym wyborem dla złożonych środowisk. Traefik stawia na prostotę, automatyczne wykrywanie usług i deklaratywność. Caddy z kolei umożliwia automatyczne certyfikaty i szybki start bez wielkiej konfiguracji. Dla środowisk, w których ważne jest wsparcie i zaawansowane funkcje enterprise, dostępne są edycje komercyjne i usługi zarządzane.

Alternatywą lub uzupełnieniem są usługi edge/CDN oferowane przez globalnych dostawców. Skracają odległość do użytkownika, zapewniają ochronę przed DDoS na poziomie sieci i aplikacji, a często oferują także funkcje compute na brzegu. Kosztowo trzeba uwzględnić opłaty za transfer wychodzący, przepływ danych między regionami i wpływ terminacji szyfrowania na zasoby CPU.

Integracja z procesem wytwórczym i kulturą DevOps

Reverse proxy dobrze współdziała z podejściem infrastructure as code: konfiguracje w repozytoriach, review, testy, automatyczne wdrożenia i szybkie roll-backi. W praktyce oznacza to krótszy czas reagowania na problemy i większą przewidywalność zmian. W połączeniu z pipeline’ami CI/CD można wprowadzać canary, kontrolowane wyłączanie feature’ów i precyzyjne polityki przepuszczania ruchu do nowych wersji aplikacji.

Na etapie testów przydaje się ruch syntetyczny, który stale sprawdza kluczowe ścieżki użytkownika, a także testy obciążeniowe z realistycznym rozkładem żądań. Dzięki temu zmiany w konfiguracji reverse proxy rzadziej zaskakują nieoczekiwanymi skutkami ubocznymi.

Metryki, logi i śledzenie: pełna widoczność jako narzędzie pracy

Bez rzetelnych danych trudno zarządzać ruchem. Reverse proxy powinno eksportować metryki o stanie połączeń, czasach odpowiedzi, błędach i wykorzystaniu zasobów. Strukturalne logi umożliwiają łatwą korelację zdarzeń i analizę incydentów. W połączeniu z tracingiem rozproszonym dają całościowy obraz przepływu żądania przez system i ujawniają wąskie gardła, które nie są oczywiste z punktu widzenia pojedynczej aplikacji.

To miejsce, w którym dojrzewa obserwowalność: wskaźniki SLO, budżety błędów, alerty oparte na symptomach, a nie wyłącznie na progach. Dobrze zaprojektowana telemetria reverse proxy staje się systemem wczesnego ostrzegania przed awariami i kanałem informacji zwrotnej dla zespołów deweloperskich.

CDN i reverse proxy: duet przyspieszający globalne serwisy

Wiele organizacji łączy reverse proxy w regionie macierzystym z globalną siecią CDN. CDN przejmuje część ruchu statycznego i odciąża źródło, ale równocześnie reverse proxy pozostaje miejscem egzekwowania złożonych reguł aplikacyjnych, autoryzacji i agregacji usług. Ważna jest tu spójność nagłówków cache’u, harmonizacja TTL i mechanizmy czyszczenia. Dobrą praktyką jest sterowanie cache’em poprzez jawne dyrektywy oraz klucze tematyczne, aby uniknąć niespodziewanych różnic między warstwami.

Kwestie kosztowe i planowanie pojemności

Reverse proxy obciąża CPU głównie podczas negocjacji szyfrowania, kompresji i operacji na nagłówkach. Planowanie pojemności wymaga uwzględnienia rozkładu dziennego, wskaźnika renegocjacji, udziału ruchu statycznego i odsetka cache hit. Przezroczystość połączeń i pooling redukują overhead na backendach, ale nadmiernie agresywne limity mogą pogorszyć doświadczenie użytkowników. Koszty transferu – zwłaszcza w chmurach publicznych – bywają większe niż koszty instancji, dlatego optymalizacja egress i regionalizacja ruchu mają duże znaczenie.

Konfiguracja bez pułapek: dobre praktyki

• Standaryzuj nagłówki X-Forwarded-For/Proto/Host lub Forwarded, by aplikacje miały pełny kontekst klienta.
• Ustal rozsądne limity i time-outy: połączenia, nagłówki, rozmiary ciał żądań; chroni to przed powolnymi klientami i atakami typu slowloris.
• Stosuj walidację cache i precyzyjne reguły Vary; testuj, czy cookie lub parametry nie psują współczynnika trafień.
• Automatyzuj cykl życia certyfikatów (ACME) i egzekwuj nowoczesne szyfry oraz HSTS.
• Włącz health checki świadome aplikacji i drenaż połączeń przy wdrożeniach, aby uniknąć zrywania sesji.
• Wymuszaj bezpieczne nagłówki (CSP, X-Frame-Options, Referrer-Policy) i flagi cookie (Secure, HttpOnly, SameSite).
• Ujednolicaj parsowanie HTTP; eliminuj dwuznaczności CL/TE, aby zapobiegać request smuggling.
• Projektuj retry z backoff i tylko dla operacji idempotentnych; łącz to z degradacją usług w razie awarii.
• Monitoruj metryki skuteczności cache’u, latencje p95/p99 i błędy 5xx; wiąż je z konkretnymi zmianami w konfiguracji.
• Planuj migracje stopniowo: najpierw shadow traffic, potem mały procent ruchu, a na końcu pełne przełączenie.

Reverse proxy w środowiskach kontenerowych

W platformach opartych o Kubernetes reverse proxy najczęściej działa jako Ingress Controller lub Gateway API. Konfiguracja jest deklaratywna, powstaje z manifestów i pozwala łatwo łączyć polityki ruchu z cyklem wydawniczym aplikacji. Dynamiczna rekonfiguracja umożliwia wprowadzanie zmian bez restartów, a service discovery oparte o etykiety i selektory sprawia, że nowe instancje są automatycznie włączane do puli backendów.

W tym środowisku kluczowe jest też rozróżnienie ruchu północ-południe (north-south) – obsługiwanego przez reverse proxy – oraz wschód-zachód (east-west), który często przejmuje service mesh. Reverse proxy koncentruje się na granicy klastra, podczas gdy mezhe obsługuje komunikację między serwisami, polityki mTLS i zaawansowane retry w ruchu wewnętrznym.

Kiedy reverse proxy nie wystarczy

Istnieją scenariusze, w których sama warstwa reverse proxy nie rozwiąże problemów. Gdy aplikacja generuje powolne zapytania do bazy, potrzebna jest optymalizacja zaplecza, a nie tylko zwiększanie buforów czy liczb wątków. Kiedy wąskim gardłem jest egress w chmurze, sensowniejsza będzie regionalizacja i caching przy brzegu niż zwiększanie rozmiaru instancji. Reverse proxy to świetna dźwignia, lecz działa najlepiej w parze z porządną architekturą aplikacji i danymi empirycznymi z monitoringu.

Podsumowanie: uniwersalna warstwa, która składa usługi w spójną całość

Reverse proxy porządkuje ruch, robi za punkt kontrolny i dostarcza zestaw funkcji, których wdrożenie w samej aplikacji byłoby kosztowne lub ryzykowne. Od równoważenia połączeń, przez buforowanie i kompresję, po ochronę warstwy aplikacji i telemetrię – to sprawdzony sposób na profesjonalny front usług w hostingu i własnych centrach danych. W połączeniu z dyscypliną operacyjną, testami i przemyślanymi politykami bezpieczeństwa staje się solidnym fundamentem usług o wysokich wymaganiach dostępności i jakości obsługi.

Warto przy tym pamiętać, że reverse proxy to narzędzie, a jego skuteczność zależy od doboru funkcji do problemu. Jedne zespoły skorzystają najbardziej na WAF i wymuszeniu dobrych praktyk kryptograficznych, inne zyskają na buforowaniu i agregacji połączeń, a jeszcze inne na elastycznych strategiach wdrożeniowych. Eldorado zaczyna się wtedy, gdy te elementy łączą się w spójną platformę – taką, która rośnie wraz z ruchem i potrzebami użytkowników, wspierając stabilny rozwój usług bez kompromisów.

Słownik skrótów i najważniejszych pojęć

• Reverse proxy – serwer pośredniczący po stronie usług, prezentujący jednolity punkt wejścia dla klientów.
• Forward proxy – pośrednik po stronie klienta, używany m.in. do filtrowania i kontroli dostępu w sieciach firmowych.
• Terminacja TLS – zakończenie połączenia szyfrowanego na brzegu i przekazanie żądania do backendu.
• Health check – mechanizm sprawdzający kondycję backendu, używany do wyłączania niesprawnych węzłów.
• Rate limiting – ograniczanie liczby żądań na klienta, klucz, IP lub ścieżkę.
• WAF – web application firewall, zestaw reguł chroniących aplikację WWW przed atakami.
• Cache – mechanizm przechowywania odpowiedzi w pamięci podręcznej i ich ponownego użycia.
• Ingress – punkt wejścia ruchu do klastra, zwykle realizowany przez reverse proxy z dynamiczną konfiguracją.