Proxy HTTP to jeden z fundamentów nowoczesnej architektury webowej, często niedoceniany przez młodszych administratorów. Pełni on rolę pośrednika (intermediary) na warstwie L7, co oznacza, że ma pełny wgląd w treść przesyłanych pakietów - w przeciwieństwie do routera czy firewalla działających na L3/L4. To właśnie dzięki temu może podejmować inteligentne decyzje: buforować odpowiedzi, routować zapytania do różnych serwerów, przerywać połączenia SSL/TLS, wstrzykiwać nagłówki czy blokować złośliwy ruch na poziomie aplikacji. Podstawowy podział na Forward Proxy i Reverse Proxy wynika z kierunku, w którym ktoś jest "maskowany": w pierwszym przypadku klient (wychodzący w świat) - używany w firmach do kontroli ruchu pracowników; w drugim serwer (przychodzący z zewnątrz) - standard dla każdej nowoczesnej aplikacji WWW chronionej i skalowanej. Niniejsza prezentacja (piąta z cyklu Administracja Sieci Komputerowych) pokaże od podszewki oba te typy, algorytmy rutowania load balancerów, mechanizmy sticky sessions oraz praktyczną konfigurację Nginx i HAProxy. Szczególny nacisk położymy na demonstrację na żywo: budowę środowiska testowego, konfigurację krok po kroku oraz rozwiązywanie problemów (troubleshooting).

Warsztat został zaprojektowany dla inżynierów, którzy chcą zrozumieć, jak w praktyce zarządzać wejściem aplikacji WWW w środowisku produkcyjnym. Celem nie jest tylko teoria, ale przede wszystkim praktyczne umiejętności: po warsztacie potrafisz skonfigurować Nginx jako odwrotne proxy, przetestować działanie algorytmów load balancingu i zdiagnozować problem, gdy za reverse proxy nie działa logowanie adresów IP klienta. Będziesz w stanie samodzielnie zbudować infrastrukturę Reverse Proxy z Nginx, skonfigurować upstream, przetestować algorytmy rutowania, zaimplementować sticky sessions oraz wykonać podstawowy troubleshooting. Część laboratoriów opiera się na symulacji prostego środowiska z serwerami Python HTTP, co pozwala odtworzyć każde ćwiczenie na własnym komputerze bez potrzeby posiadania rozbudowanej infrastruktury.

Agenda została zaplanowana jako płynne przejście od teorii proxy L7, przez algorytmy dystrybucji ruchu, aż po praktyczną konfigurację i laboratorium. Pierwszy blok (slajdy 4–12) kładzie fundament pod zrozumienie, dlaczego potrzebujemy proxy i jakie są jego rodzaje. Drugi blok (slajdy 13–20) wyjaśnia mechanizmy skalowania poziomego i algorytmy decyzyjne load balancerów. Trzeci blok (slajdy 21–30) to kluczowe zagadnienia dla aplikacji stanowych: sticky sessions i caching. Czwarty blok (slajdy 31–38) to sedno konfiguracji Nginx i HAProxy z prawdziwymi przykładami. Ostatni blok (slajdy 39–50) to laboratorium, w którym uruchomisz własne środowisko testowe, skonfigurujesz reverse proxy, przetestujesz dystrybucję ruchu i nauczysz się debugować problemy. Wszystkie przykłady bazują na systemie Debian/Ubuntu Linux.

W bezpośrednim modelu komunikacji serwer jest odpowiedzialny za wszystko: musi odebrać połączenie TCP, wykonać uzgadnianie SSL/TLS (jeśli HTTPS), przetworzyć żądanie HTTP, wygenerować odpowiedź i wysłać ją z powrotem. To sprawia, że serwer jest pojedynczym punktem awarii (SPOF) i wąskim gardłem wydajności. Nie ma możliwości buforowania odpowiedzi, rozłożenia ruchu na wiele serwerów ani ochrony przed atakami DDoS. To właśnie te ograniczenia doprowadziły do powstania architektur z pośrednikami na warstwie aplikacji (L7).

Proxy warstwy 7 (L7 proxy) to fundamentalnie inne narzędzie niż router czy firewall, które działają na warstwach 3 i 4. Router patrzy tylko na adresy IP i podejmuje decyzje na podstawie tablic rutingu. Firewall może sprawdzać adresy IP i porty TCP/UDP. Ale proxy L7 ma dostęp do treści komunikacji HTTP - widzi, czy klient prosi o stronę główną (GET /) czy o obrazek (GET /image.jpg), jakie ciasteczka przesła (Cookie), jakiej przeglądarki używa (User-Agent), a nawet może odczytywać treść żądania POST. To daje niesłychane możliwości: może buforować popularne zasoby (np. logo firmowe, skrypty JS), blokować dostęp do określonych kategorii stron (filtrowanie treści), modyfikować nagłówki (dodawać X-Forwarded-For), przerywać połączenia SSL i ustanawiać nowe (SSL termination), routować żądania do różnych serwerów w zależności od URI (content-based routing).

Forward Proxy to najstarszy typ proxy HTTP, używany od początków Internetu korporacyjnego. Gdy pracownik w firmie prosi o stronę internetową, żądanie nie leci bezpośrednio do serwera docelowego - najpierw trafia do forward proxy (np. Squid, HAProxy w trybie forward, dawniej Microsoft ISA/TMG). To proxy decyduje, czy żądanie może być zrealizowane: sprawdza, czy URL jest na liście dozwolonych stron, czy pracownik ma odpowiednie uprawnienia, czy treść jest już w buforze. Jeśli wszystko OK, proxy samo łączy się z serwerem docelowym, pobiera odpowiedź i zwraca ją klientowi. Z perspektywy serwera WWW w Internecie, żądanie pochodzi z adresu IP proxy - serwer nie widzi prawdziwego adresu klienta. To właśnie dlatego forward proxy jest używane do anonimizacji. W firmach forward proxy pełni rolę narzędzia do kontroli: można blokować kategorie stron, monitorować czas spędzony na stronach, buforować popularne zasoby (aktualizacje Windows, biblioteki CDN) aby oszczędzać pasmo. Najpopularniejszym rozwiązaniem jest Squid - jeden z najstarszych i najbardziej dojrzałych serwerów proxy na rynku, działający od 1996 roku.

Squid to najbardziej rozpoznawalne rozwiązanie do forward proxy w środowiskach korporacyjnych i edukacyjnych. Jego główna siła leży w elastycznym systemie ACL, który pozwala definiować polityki dostępu na podstawie niemal dowolnego kryterium: adresu źródłowego klienta (src), docelowej domeny (dstdomain), docelowego adresu IP (dst), pory dnia (time), metody HTTP (method), typu obiektu (rep_mime_type), a nawet wyrażenia regularnego w URI (url_regex). ACL-e są łączone w grupy i przypisywane do reguł http_access, które są sprawdzane w kolejności od pierwszej do ostatniej (pierwsze dopasowanie wygrywa). Squid jest również potężnym buforem (cache): przechowuje odpowiedzi HTTP w pamięci RAM i na dysku, dzięki czemu kolejne żądania o ten sam zasób są obsługiwane w milisekundach bez generowania ruchu do Internetu. W firmie zatrudniającej 1000 pracowników, Squid może buforować aktualizacje Windows, biblioteki jQuery z CDN, logo firmowe itp. W praktyce, odpowiednie skonfigurowanie buforowania może zredukować ruch wychodzący nawet o 30–50%.

Reverse Proxy to odwrotność forward proxy - zamiast maskować klienta przed serwerem, maskuje serwer przed klientem. Z punktu widzenia użytkownika Internetu, cała aplikacja WWW (np. sklep internetowy, portal bankowości elektronicznej) znajduje się pod jednym adresem: https://sklep.example.pl. W rzeczywistości za tym adresem może stać 10, 20 czy 100 serwerów fizycznych lub wirtualnych, z których każdy obsługuje inny fragment aplikacji - ale klient nigdy nie dowiaduje się o ich istnieniu. To właśnie reverse proxy (np. Nginx, HAProxy, Apache w trybie mod_proxy) pełni rolę strażnika: przyjmuje wszystkie połączenia od klientów, decyduje, który serwer backendu ma obsłużyć żądanie (load balancing), może pobrać odpowiedź z bufora (caching), może zakończyć połączenie SSL/TLS na sobie (SSL termination), może odrzucić złośliwe żądania. Serwery backendu znajdują się w sieci wewnętrznej, często w prywatnych podsieciach, niedostępne bezpośrednio z Internetu. To znacząco podnosi bezpieczeństwo: atakujący nie ma bezpośredniego dostępu do serwerów aplikacyjnych, musi najpierw przebić się przez reverse proxy.

W środowisku produkcyjnym reverse proxy pełni rolę tarczy ochronnej dla serwerów aplikacyjnych. Po pierwsze, ukrywa architekturę wewnętrzną: atakujący nie wie, czy za proxy stoi jeden serwer Apache, klaster Node.js, czy złożona architektura mikroserwisów na Kubernetesie. Po drugie, reverse proxy przejmuje na siebie ciężkie obciążenie związane z kryptografią asymetryczną - protokół TLS wymaga kosztownych obliczeniowo operacji matematycznych podczas uzgadniania połączenia (handshake). Serwery aplikacyjne, zamiast marnować cykle CPU na te operacje, mogą skupić się na generowaniu dynamicznej treści. W praktyce, serwer Nginx skonfigurowany jako reverse proxy może obsłużyć kilkadziesiąt tysięcy jednoczesnych połączeń TLS, podczas gdy serwer aplikacyjny (np. Python/Flask, PHP/WordPress) bez proxy by się po prostu udusił. Po trzecie, reverse proxy działa jak firewall warstwy 7: może analizować treść żądań i blokować te, które wyglądają na ataki (SQL Injection w parametrach GET, XSS w nagłówkach, path traversal w URI).

Forward i Reverse Proxy to dwa oblicza tej samej technologii, ale o radykalnie różnych celach i konfiguracji. W forward proxy to klient musi wiedzieć o istnieniu proxy i jawnie skonfigurować swoją przeglądarkę lub system operacyjny - w przeciwnym razie ruch leci bezpośrednio, omijając proxy. Dlatego w firmach często wymusza się użycie forward proxy poprzez transparentne przekierowanie całego ruchu HTTP z portu 80 na proxy (tzw. transparent proxy), co działa na poziomie routera/firewalla bez wiedzy użytkownika. Natomiast reverse proxy jest całkowicie przezroczyste dla klienta - użytkownik wpisuje adres https://sklep.pl i nawet nie wie, że za tym adresem kryje się dodatkowy serwer pośredniczący. To DNS kieruje klienta na reverse proxy - rekord A domeny wskazuje na adres IP reverse proxy, a nie na serwery aplikacyjne. Kolejna istotna różnica: forward proxy często buforuje odpowiedzi, aby przyspieszyć kolejne żądania i oszczędzić pasmo (cache dla całej firmy); reverse proxy również buforuje, ale w celu odciążenia serwerów aplikacyjnych.

Ścieżka pojedynczego żądania HTTP przez reverse proxy składa się z czterech wyraźnych etapów. Etap 1: Klient wykonuje zapytanie DNS na nazwę domeny i otrzymuje adres IP - jest to adres reverse proxy, a nie serwera aplikacyjnego. Klient łączy się z proxy na porcie 443 (HTTPS) i rozpoczyna uzgadnianie TLS. Etap 2: Reverse proxy przyjmuje połączenie TCP i dokonuje terminacji protokołu TLS - odszyfrowuje ruch, aby móc odczytać nagłówki HTTP. Etap 3: Na podstawie skonfigurowanych reguł, proxy wybiera serwer backendu (np. według algorytmu Round Robin) i tworzy nowe, osobne połączenie TCP w sieci prywatnej. Backend przetwarza żądanie i zwraca odpowiedź do proxy. Etap 4: Proxy otrzymuje odpowiedź od backendu, może ją zapisać w buforze (cache), a następnie przekazuje klientowi przez wcześniej ustanowione szyfrowane połączenie TLS. Cały proces jest niewidoczny dla klienta - widzi on tylko jedną sesję HTTPS z reverse proxy.

W forward proxy żądanie HTTP wygląda inaczej niż w bezpośrednim połączeniu. Klient, zamiast wysłać GET /index.html HTTP/1.1 z nagłówkiem Host, wysyła GET http://www.example.com/index.html HTTP/1.1 - czyli pełny URL w linii żądania. To właśnie odróżnia forward proxy od reverse: w reverse proxy klient wysyła standardowe żądanie (względny URI), bo nie wie o istnieniu proxy; w forward proxy klient wie, że używa proxy i wysyła pełny URL, aby proxy wiedziało, gdzie ma się łączyć. Proxy po otrzymaniu żądania sprawdza swoje reguły dostępu (ACL): czy klient ma prawo dostępu do zadanej domeny (dstdomain). Jeśli tak, proxy sprawdza, czy ma tę stronę w buforze i czy jest ona świeża. Jeśli tak - zwraca z bufora. Jeśli nie - łączy się z serwerem docelowym w Internecie, pobiera stronę, buforuje ją i zwraca klientowi. Z punktu widzenia serwera WWW, żądanie pochodzi z adresu IP proxy, a nie z adresu klienta.

Każdy serwer ma fizyczne ograniczenia: jeden proces Apache może obsłużyć maksymalnie określoną liczbę jednoczesnych połączeń (np. 256 w MPM prefork). Gdy ruch przekroczy te granicę, strona zaczyna odpowiadać z błędami timeout. Rozwiązaniem jest skalowanie poziome - zamiast wymieniać serwer na mocniejszy (skalowanie pionowe), dodajemy kolejne serwery, które dzielą się ruchem. To właśnie load balancer staje przed nimi i rozdziela ruch według algorytmu. Skalowanie poziome ma tę przewagę nad pionowym, że jest praktycznie nieograniczone: można dodawać serwery bez końca (do granic budżetu). Dodatkowo, daje redundancję – gdy jeden serwer ulegnie awarii, load balancer automatycznie kieruje ruch do pozostałych węzłów. W architekturze chmurowej (AWS, GCP, Azure) skalowanie poziome jest zautomatyzowane: Auto Scaling Groups dodają lub usuwają serwery na podstawie obciążenia CPU. Load Balancer to kluczowy element tej architektury - to on jest "menedżerem" decydującym, który serwer dostanie które żądanie.

Podział load balancerów na L4 i L7 wynika z warstwy modelu OSI, na której podejmują decyzje routingu. L4 LB działa na podstawie adresu IP źródła/celu i portu TCP/UDP. Nie zagłębia się w treść pakietu - nie wie, czy to żądanie HTTP, MySQL, czy gry online. Jest bardzo szybki (często działa w kernelu systemu operacyjnego, jak LVS), ale nie może podejmować inteligentnych decyzji na podstawie URI czy ciasteczek. L7 LB działa na wyższym poziomie - musi odebrać cały pakiet HTTP, sparsować go i dopiero wtedy podjąć decyzję. Jest wolniejszy, ale daje niesłychaną elastyczność: może routować żądania do różnych serwerów w zależności od ścieżki URI (/api/* do serwera API, /static/* do serwera plików statycznych), czytać ciasteczka (sticky sessions), modyfikować nagłówki, buforować odpowiedzi. W praktyce, L7 LB jest standardem dla aplikacji webowych. L4 LB jest używany tam, gdzie wydajność jest krytyczna (np. obsługa milionów jednoczesnych połączeń) lub gdzie protokół nie jest HTTP.

Round Robin to najstarszy algorytm load balancingu, wywodzący się z czasów mainframe'ów. Jego nazwa pochodzi od systemu przydzielania czasu procesora w systemach operacyjnych. Działanie jest banalnie proste: load balancer prowadzi licznik (wskaźnik), który po każdym zadaniu przesuwa się na następny serwer w liście. Po osiągnięciu końca listy, licznik zawraca na początek. Efekt: idealnie równomierny podział pod względem liczby zadań, ale nie pod względem obciążenia. Jeśli serwer A przetwarza każde zadanie w 100 ms, a serwer B w 500 ms, to po 10 zadaniach A będzie miał 1 s łącznego czasu pracy, a B 5 s. Round Robin jest idealny, gdy serwery w puli są jednorodne (ten sam sprzęt, ta sama konfiguracja). W praktyce, Round Robin jest często używany z wariantem Weighted Round Robin, gdzie każdemu serwerowi przypisuje się wagę (weight) proporcjonalną do jego mocy obliczeniowej. W Nginx implementuje się to dyrektywą: server backend1.example.com weight=3;.

W rzeczywistych środowiskach produkcyjnych rzadko zdarza się, aby wszystkie serwery w puli backendu miały identyczną moc obliczeniową. Często po awarii dodaje się zapasowy serwer o niższej wydajności, lub stopniowo wymienia się sprzęt na nowszy. W takiej sytuacji Round Robin bez wag byłby niesprawiedliwy: słabsze serwery dostawałyby tyle samo zadań co mocne, co prowadziłoby do przeciążenia słabszych i nieużywania pełnego potencjału mocnych. Rozwiązaniem jest Weighted Round Robin, gdzie każdy serwer w konfiguracji deklaruje swoją wagę. Waga jest liczbą całkowitą, proporcjonalną do mocy obliczeniowej serwera. Load balancer dystrybuuje zadania w cyklu Round Robin, ale serwer z wagą 3 pojawia się w cyklu 3 razy, serwer z wagą 2 - 2 razy, serwer z wagą 1 - 1 raz. W Nginx wagi ustawia się w dyrektywie server wewnątrz bloku upstream: server 192.168.1.10 weight=5;. W HAProxy: server web1 192.168.1.10:80 weight 5.

Least Connections to algorytm bardziej zaawansowany niż Round Robin, ponieważ uwzględnia faktyczne obciążenie serwera mierzone liczbą aktywnych połączeń. Działa na prostej zasadzie: gdy przychodzi nowe zadanie, load balancer przegląda wszystkie serwery backendu, sprawdza, ile każdy z nich ma aktualnie otwartych połączeń, i wysyła zadanie do tego z najmniejszą liczbą. W praktyce jest to bardziej sprawiedliwe niż Round Robin, szczególnie gdy zadania mają różny czas przetwarzania (np. niektóre są łatwe i szybkie, inne ciężkie i długie). Serwer, który właśnie dostał długie zadanie, ma więcej aktywnych połączeń i nie dostanie nowego, dopóki sobie z nim nie poradzi. Least Connections jest algorytmem domyślnym w HAProxy dla trybu http. W Nginx algorytm ustawia się dyrektywą least_conn w bloku upstream: upstream backend { least_conn; server ...; }. Wadą algorytmu jest konieczność utrzymywania stanu (stateful tracking), co może być problemem w środowiskach z bardzo dużą liczbą jednoczesnych połączeń.

IP Hash (lub Source IP Hash) to algorytm, który wykorzystuje funkcję skrótu (hash) do przypisania klienta do konkretnego serwera backendu. Funkcja hash przyjmuje adres IP źródła (np. 192.168.1.100) i oblicza liczbę, która jest następnie mapowana na jeden z serwerów backendu. Klient o adresie 192.168.1.100 zawsze trafi do tego samego serwera (np. backend A), chyba że pula backendów się zmieni. To rozwiązanie jest stosowane, gdy aplikacja nie obsługuje mechanizmu sticky sessions lub gdy chcemy uniknąć narzutu ciasteczek. IP Hash działa na poziomie L3/L4, więc jest niezależny od protokołu. W Nginx algorytm ustawia się dyrektywą ip_hash w bloku upstream. W HAProxy: balance source. Wadą IP Hash jest to, że przy małej liczbie klientów może prowadzić do nierównomiernego obciążenia - jeśli jeden klient generuje 90% ruchu (np. bot indeksujący), cały ruch trafia na jeden serwer. Dodatkowo, dodanie lub usunięcie serwera z puli zmienia funkcję hash, co powoduje, że większość klientów zostanie przekierowana do innych serwerów (tzw. domino effect).

Wybór odpowiedniego algorytmu load balancingu zależy od charakterystyki aplikacji i architektury backendu. Round Robin jest najlepszy, gdy serwery backendu są jednorodne (identyczna moc obliczeniowa), a każde zadanie wymaga podobnego czasu przetwarzania. Least Connections jest lepszy, gdy zadania mają bardzo różny czas przetwarzania - algorytm automatycznie wyrównuje obciążenie. To domyślny wybór dla większości aplikacji webowych w HAProxy. IP Hash jest niezbędny, gdy aplikacja przechowuje stan sesji lokalnie na serwerze i nie używa zewnętrznego magazynu sesji (Redis, Memcached, baza danych). W nowoczesnych architekturach mikroserwisowych, gdzie każdy serwer jest bezstanowy (stateless), IP Hash jest rzadko używany. Warto pamiętać, że można użyć Weighted Round Robin z Least Connections (tzw. Weighted Least Connections) - połączenie obu podejść.

Decyzja load balancera o wyborze serwera backendu to wieloetapowy proces. Pierwszym i najważniejszym krokiem jest health check: load balancer okresowo (np. co 2 sekundy) wysyła zapytania do każdego serwera backendu. Jeśli serwer nie odpowie na 3 kolejne próby - zostaje oznaczony jako DOWN i wykluczony z puli. Health check może być na poziomie L3 (ping), L4 (połączenie TCP na port 80) lub L7 (zadanie HTTP GET /health). Gdy serwer wróci do życia, po udanym health checku zostaje przywrócony do puli. Drugi krok to filtrowanie: z puli usuwane są serwery DOWN oraz te w trybie draining. Trzeci krok to zastosowanie algorytmu. Czwarty krok to forward: load balancer modyfikuje nagłówki zadania (dodaje X-Forwarded-For, X-Forwarded-Proto, X-Real-IP), ustanawia połączenie z backendem i przekazuje zadanie. Cały proces trwa zazwyczaj mniej niż milisekundę.

Problem stanu sesji jest jednym z najważniejszych wyzwań w skalowaniu poziomym aplikacji webowych. W tradycyjnej architekturze, gdy aplikacja działa na jednym serwerze, sesja jest przechowywana w pamięci tego serwera: użytkownik loguje się, serwer zapisuje informacje o sesji (ID użytkownika, uprawnienia, zawartość koszyka) i zwraca ciasteczko sesyjne (SESSION_ID). Gdy dodajemy load balancer i drugi serwer, pojawia się problem: użytkownik loguje się na serwerze A (sesja zapisana na A), ale następne zadanie trafia na serwer B - serwer B nie ma sesji użytkownika. Istnieją trzy rozwiązania: (1) session persistence (sticky sessions) na load balancerze, (2) wspólny magazyn sesji (np. Redis, Memcached, baza danych), (3) aplikacja bezstanowa (stateless) - wszystkie dane sesji w tokenie JWT. Sticky sessions to najprostsze rozwiązanie, ale ma wady: utrudnia zarządzanie awariami.

Session Persistence to zbiór technik zapewniających, że wszystkie zadania od jednego klienta są kierowane do tego samego serwera backendu. Najpopularniejsza metoda to cookie insert: load balancer (np. HAProxy) dodaje do odpowiedzi HTTP specjalne ciasteczko (np. SRVNAME=web02), w którym koduje nazwę serwera, który obsłużył zadanie. Przy kolejnym zadaniu przeglądarka wysyła to ciasteczko, load balancer odczytuje je i kieruje zadanie do zapisanego serwera. Metoda ta jest prosta i działa z każdą aplikacją, ale ma wady: (1) jeśli serwer ulegnie awarii, klient straci sesję; (2) nierównomierne obciążenie; (3) utrudniona konserwacja. Alternatywne metody to IP hash (używany w Nginx przez dyrektywę ip_hash) oraz URL hash. W środowiskach produkcyjnych często stosuje się hybrydę: sticky sessions + wspólny magazyn sesji (np. Redis), co zapewnia, że nawet jeśli serwer padnie, sesja jest dostępna na innych serwerach.

Mechanizm cookie insert jest genialny w swej prostocie. W konfiguracji HAProxy dodaje się jedną dyrektywę: cookie SRVNAME insert w bloku backend oraz atrybut cookie web01 przy każdej deklaracji serwera. HAProxy automatycznie robi resztę: przy pierwszym zadaniu od klienta, wybiera serwer według algorytmu, a następnie wstrzykuje do odpowiedzi HTTP nagłówek Set-Cookie zawierający identyfikator serwera. To nie jest sesja aplikacyjna (SESSION_ID) - to ciasteczko load balancera, które istnieje obok ciasteczka sesyjnego aplikacji. Przeglądarka klienta przechowuje oba ciasteczka i wysyła je przy każdym zadaniu. HAProxy czyta swoje ciasteczko (SRVNAME) i natychmiast wie, na który serwer ma przekazać zadanie - nie musi stosować algorytmu. Mechanizm ma jeden problem: jeśli serwer web02 padnie, HAProxy nie ma jak obsłużyć zadania. Rozwiązaniem jest opcja option redispatch w HAProxy, która w takiej sytuacji przekierowuje klienta do innego serwera, ignorując ciasteczko (ale sesja na oryginalnym serwerze jest utracona).

W nowoczesnych aplikacjach webowych pliki statyczne stanowią często 80-90% całego przesylanego ruchu pod względem bajtów. Każde zadanie o taki plik, nawet jeśli jest obsługiwane przez serwer aplikacyjny, wymaga uruchomienia całego stosu aplikacyjnego: proces potomny Apache, interpreter PHP, otwarcie pliku z dysku, wysłanie go przez sieć. To ogromne marnotrawstwo zasobów, szczególnie gdy plik jest ten sam dla wszystkich użytkowników (np. logo firmy, biblioteka jQuery). Reverse proxy z buforowaniem (caching) rozwiązuje ten problem: przy pierwszym zadaniu o plik, proxy pobiera go od backendu, zapisuje w pamięci RAM i zwraca klientowi. Przy każdym kolejnym zadaniu o ten sam plik, proxy sprawdza, czy ma go w buforze i czy nie jest przeterminowany. W Nginx caching włącza się dyrektywami: proxy_cache_path (definiuje ścieżkę i rozmiar bufora) oraz proxy_cache (włącza buforowanie dla danego kontekstu). Efekt: backend obsługuje tylko zadania dynamiczne, a statyka jest serwowana z pamięci RAM proxy.

Nginx oferuje potężny i elastyczny system buforowania odpowiedzi proxy. Konfiguracja zaczyna się od dyrektywy proxy_cache_path w bloku http, która definiuje: ścieżkę do katalogu bufora, strukturę podkatalogów (levels=1:2), strefę pamięci dla kluczy (keys_zone=mycache:10m), maksymalny rozmiar bufora na dysku (max_size=1g), czas bezczynności (inactive=60m - jeśli zasób nie był używany przez 60 minut, zostanie usunięty niezależnie od TTL). Następnie w bloku location włącza się buforowanie dyrektywą proxy_cache mycache. Dyrektywa proxy_cache_valid określa, które kody statusu HTTP i jak długo mają być buforowane. Można dodać proxy_cache_key, aby zmienić domyślny klucz bufora. Nginx oferuje również możliwość dodania nagłówka informującego o statusie bufora: add_header X-Cache-Status $upstream_cache_status; - pokaże HIT (z bufora), MISS (nie było), EXPIRED (przeterminowany) itd.

Nagłówki TTL (Time-To-Live) to mechanizm, którym serwer WWW komunikuje pośrednikom, jak długo mogą przechowywać odpowiedź w buforze. Głównym nagłówkiem jest Cache-Control (RFC 7234). Najważniejsze dyrektywy: public (odpowiedź może być buforowana przez każdego), private (tylko dla jednego użytkownika), no-cache (można buforować, ale trzeba sprawdzić z serwerem), no-store (całkowity zakaz), max-age=N (maksymalny czas w sekundach), s-maxage=N (dla shared cache jak proxy). Dodatkowo istnieje nagłówek Expires: Expires: Thu, 01 Dec 2025 16:00:00 GMT, ale jest mniej elastyczny niż Cache-Control. W praktyce, dla plików statycznych ustawia się Cache-Control: public, max-age=31536000, immutable (rok, niezmienny), a dla treści dynamicznych Cache-Control: no-cache, no-store, must-revalidate.

Praktyczne ustawianie TTL zależy od charakteru zasobu i strategii wersjonowania. Najważniejsza zasada: jeśli plik ma fingerprint (hash w nazwie, np. styles.abc123.css), można ustawić bardzo długi czas buforowania (max-age=31536000 = 1 rok) z dyrektywą immutable, która mówi przeglądarce: "nigdy nie sprawdzaj, czy plik się zmienił". Dzięki fingerprintowi, gdy plik się zmieni, jego nazwa też się zmieni. Dla obrazów i fontów maksymalnie 1 dzień cache jest bezpieczny. Dla stron HTML z treścią statyczną 15-30 minut cache. Dla stron generowanych dynamicznie (blog, portal) - no-cache (przeglądarka musi sprawdzić każdorazowo, ale może użyć walidatorów jak ETag czy Last-Modified). Dla API z danymi poufnymi (logowanie, finanse) - private, no-cache. Ważne: nagłówki TTL dotyczą nie tylko reverse proxy, ale przede wszystkim przeglądarek klientów - zbyt długi TTL dla zasobu, który może się zmienić, spowoduje, że użytkownicy będą widzieć starą wersję.

Cache invalidation to jeden z najsłynniejszych problemów w inżynierii oprogramowania. Gdy zasób zostanie zbuforowany przez reverse proxy (lub przeglądarkę klienta), zmiana oryginalnego pliku na serwerze nie jest automatycznie propagowana do buforów - one nadal serwują starą wersję, dopóki TTL nie wygaśnie lub bufor nie zostanie ręcznie unieważniony. Pierwsza metoda to purge: wysłanie zadania HTTP z metodą PURGE do proxy, które usuwa wpis z bufora. W Nginx wymaga to dodatkowej konfiguracji (dyrektywa proxy_cache_purge lub moduł ngx_cache_purge). Druga metoda to wersjonowanie: dodanie do nazwy pliku hasha (np. app.a1b2c3.js) lub parametru wersji (app.js?v=2). To najprostsze i najpopularniejsze rozwiązanie dla plików statycznych. Trzecia metoda to krótki TTL: ustawienie czasu życia na tyle krótkiego, aby zmiana szybko się propagowała. To kompromis między wydajnością a świeżością danych.

SSL/TLS termination to jedna z najważniejszych funkcji reverse proxy w środowiskach produkcyjnych. Protokół TLS wymaga kosztownych obliczeniowo operacji matematycznych podczas fazy handshake, szczególnie przy użyciu kryptografii asymetrycznej (RSA, ECDHE). Serwer aplikacyjny ma ograniczone zasoby CPU, które woli przeznaczyć na generowanie dynamicznej treści. Reverse proxy (Nginx, HAProxy) jest zoptymalizowany pod kątem obsługi dużej liczby połączeń TLS. W Nginx SSL termination konfiguruje się poprzez: listen 443 ssl; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem;. Ruch do backendu jest przekazywany czystym HTTP (proxy_pass http://backend;). W środowiskach o podwyższonych wymogach bezpieczeństwa (PCI DSS, HIPAA) wymagane jest szyfrowanie na całej ścieżce - wtedy stosuje się SSL re-encryption: proxy łączy się z backendem przez HTTPS z użyciem certyfikatu self-signed w zaufanej sieci.

Wybór między trybem L4 a L7 zależy od konkretnych wymagań architektonicznych. L4 (TCP mode) jest prostszy i szybszy: load balancer podejmuje decyzje na podstawie adresu IP i portu, bez analizowania treści pakietu. Jest idealny dla protokołów niebazujących na HTTP (bazy danych MySQL, PostgreSQL, Redis, gry online, VoIP) oraz dla scenariuszy, gdzie wydajność jest absolutnym priorytetem. L7 (HTTP mode) jest wolniejszy, ale daje ogromnie więcej możliwości: routing na podstawie URI, routing na podstawie nagłówka Host, SSL termination, caching, modyfikacja nagłówków. W nowoczesnych architekturach webowych standardem jest L7. HAProxy umożliwia mieszanie trybów: można ustawić mode http dla portu 80/443 i mode tcp dla portu 3306 (MySQL) w tej samej konfiguracji. Nginx działa domyślnie w trybie L7 dla HTTP, ale można go użyć jako L4 load balancera z modułu ngx_stream_core_module.

Nginx to nie tylko serwer WWW - to przede wszystkim potężne narzędzie do reverse proxy i load balancingu. Jego architektura oparta na asynchronicznej pętli zdarzeń (epoll w Linux, kqueue w FreeBSD) pozwala na obsługę setek tysięcy jednoczesnych połączeń przy minimalnym zużyciu pamięci RAM. Dla porównania: Apache w trybie prefork tworzy osobny proces dla każdego połączenia - przy 10 000 połączeń potrzeba 10 000 procesów (20-50 GB RAM). Nginx przy tych samych 10 000 połączeń użyje zaledwie kilku procesów worker i około 50-100 MB RAM. Konfiguracja Nginx jest deklaratywna i hierarchiczna: dyrektywy w bloku http odnoszą się do wszystkich serwerów, w bloku server do konkretnego hosta wirtualnego, w bloku location do konkretnej ścieżki URI. Do reverse proxy kluczowe są dwa bloki: upstream (definiuje pulę serwerów backendu) oraz location z dyrektywą proxy_pass. Nginx oferuje również mechanizmy: health check (ngx_http_upstream_module), buforowanie (proxy_cache), limitowanie połączeń (limit_conn), rate limiting (limit_req).

Blok upstream jest sercem konfiguracji Nginx jako load balancera. Definiuje się w nim listę serwerów backendu wraz z parametrami. Każdy serwer określa się linijką: server 192.168.1.10:80 weight=5 max_fails=3 fail_timeout=30s;. Parametry: weight (waga proporcjonalna do mocy serwera), max_fails (liczba nieudanych prób zanim serwer zostanie uznany za martwy), fail_timeout (czas w sekundach, przez który serwer jest uznawany za martwy, a następnie ponawiana jest próba). Nginx nie ma wbudowanego health checku na poziomie HTTP - sprawdza jedynie, czy backend odpowiada na poziomie TCP (czy port jest otwarty). Po osiągnięciu max_fails, serwer jest wykluczany z puli na czas fail_timeout. W Nginx Plus (komercyjna) dostępne są aktywne health checki HTTP. Do wyboru algorytmu służą dyrektywy wewnątrz bloku upstream: least_conn; (najmniejsza liczba połączeń), ip_hash; (przypięcie do serwera na podstawie IP klienta), hash $request_uri; (hash na podstawie URI).

Dyrektywa proxy_pass jest najważniejszą dyrektywą w konfiguracji reverse proxy w Nginx. To ona mówi Nginxowi: "przekaż to zadanie do wskazanego serwera lub grupy upstream". Jej użycie w najprostszej formie: proxy_pass http://backend; powoduje przekazanie zadania z zachowaniem oryginalnego URI. Ważny niuans: jeśli w proxy_pass dodamy na końcu ścieżkę (np. proxy_pass http://backend/api/;), to Nginx obetnie część URI pasującą do location i zastąpi ją wskazaną ścieżką. Kolejna ważna kwestia: nagłówki. Nginx domyślnie nie przekazuje wszystkich nagłówków oryginalnych; trzeba jawnie wskazać, które mają być zachowane. Standardowa konfiguracja: proxy_set_header Host $host (zachowaj oryginalny Host), proxy_set_header X-Real-IP $remote_addr (adres IP klienta), proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for (lista adresów), proxy_set_header X-Forwarded-Proto $scheme (protokół: http/https). Bez tych ustawień backend nie będzie wiedział, kto faktycznie wysłał zadanie.

Pełna konfiguracja Nginx jako reverse proxy z load balancing obejmuje trzy kluczowe elementy: (1) blok upstream definiujący grupę serwerów backendu, (2) blok server określający na jakim porcie i dla jakiej domeny ma działać proxy, (3) blok location z dyrektywą proxy_pass i dodatkowymi ustawieniami nagłówków. W przykładowej konfiguracji użyto algorytmu least_conn, trzech serwerów backendu z wagami oraz serwera backupowego (używanego tylko gdy wszystkie inne są niedostępne). W bloku server określono nasłuch na porcie 80 dla domeny example.com. W bloku location / wszystkie zadania są przekazywane do grupy backend. Dyrektywy proxy_set_header zapewniają, że backend otrzyma prawdziwy adres IP klienta. Po zmianie konfiguracji: nginx -t (test składni), systemctl reload nginx (przeładowanie bez restartu).

HAProxy to specjalizowane narzędzie do load balancingu i reverse proxy, zaprojektowane od podstaw z myślą o wysokiej wydajności i niezawodności. W przeciwieństwie do Nginx, który jest przede wszystkim serwerem WWW z funkcją reverse proxy, HAProxy jest dedykowanym load balancerem - i robi to lepiej niż ktokolwiek inny. Jego twórca, Willy Tarreau, zaprojektował go z myślą o środowiskach o krytycznym znaczeniu (bankowość, telekomunikacja, e-commerce). Architektura HAProxy jest jednowątkowa (w wersji 1.x) lub wielowątkowa (od 2.0), oparta na zdarzeniach, z optymalizacją dla systemów Linux (epoll, splice). Jedną z najważniejszych cech jest stick table - tabela w pamięci RAM przechowująca informacje o klientach (adres IP, liczba połączeń) umożliwiająca zaawansowane decyzje routingu. HAProxy oferuje również niesłychanie elastyczny system ACL (Access Control List) oraz wbudowany interfejs statystyk WWW na porcie 8404.

Architektura HAProxy z podziałem na frontend i backend jest jednym z kluczowych powodów jego popularności. Blok frontend jest odpowiednikiem bloku server w Nginx - określa, na jakim adresie IP i porcie HAProxy ma nasłuchiwać. Tutaj definiuje się tryb pracy (mode http lub mode tcp), reguły ACL, ewentualne przekierowania HTTP->HTTPS, limity połączeń. Blok backend definiuje serwery, do których ruch ma być kierowany. Tutaj określa się: algorytm load balancingu (balance roundrobin, leastconn, source itp.), listę serwerów (server), health checki (option httpchk), stick tables (stick-table). Rozdzielenie to ma tę przewagę, że jeden backend może być używany przez wiele frontendów - np. frontend HTTP (port 80) i frontend HTTPS (port 443) mogą kierować ruch do tego samego backendu. Łączenie frontend->backend odbywa się przez dyrektywę use_backend: use_backend web_servers if { hdr(Host) -i example.com }. Domyślny backend: default_backend web_servers.

Powyższa konfiguracja to klasyczny przykład użycia HAProxy jako reverse proxy z load balancing. Blok global definiuje ustawienia globalne: logowanie, maksymalną liczbę połączeń. Blok defaults definiuje domyślne wartości: tryb http, timeouty. Blok frontend http-in definiuje nasłuch na wszystkich interfejsach na porcie 80. Blok backend web_servers używa algorytmu roundrobin, włącza aktywny health check HTTP (option httpchk GET /health). Parametry: check (włącza health check), fall 3 (po 3 nieudanych próbach serwer jest DOWN), rise 2 (po 2 udanych próbach serwer wraca do puli), backup (serwer używany tylko gdy regularne są martwe). Po zmianie konfiguracji: haproxy -f /etc/haproxy/haproxy.cfg -c (test konfiguracji), systemctl reload haproxy (przeładowanie).

HAProxy ma jeden z najlepszych interfejsów monitorujących wśród load balancerów. Po skonfigurowaniu sekcji listen stats, interfejs WWW pod adresem http://adres_proxy:8404/stats pokazuje pełny obraz stanu klastra. Każdy serwer backendu jest reprezentowany jako wiersz w tabeli z kolumnami: status (zielony UP, czerwony DOWN, żółty NOLB), aktualna liczba sesji (cur), suma sesji (tot), ostatni kod błędu, czas odpowiedzi (rtime), przepustowość (bin/bout) i inne. Kliknięcie na serwer umożliwia ręczne wyłączenie go z puli (DRAIN) lub całkowite (MAINT) bez restartowania HAProxy. Interfejs jest chroniony hasłem (auth admin:haslo). Można go również użyć do generowania danych w formacie CSV do zewnętrznych systemów monitorujących (Zabbix, Prometheus). W nowszych wersjach HAProxy oferuje również REST API (Data Plane API) do pełnego zarządzania konfiguracją przez HTTP.

Laboratorium rozpoczyna się od przygotowania środowiska testowego. Użyjemy wbudowanego serwera HTTP modułu http.server w Pythonie 3, który pozwala na szybkie uruchomienie serwera HTTP na dowolnym porcie bez instalowania dodatkowego oprogramowania. Uruchomimy trzy serwery na portach 8081, 8082 i 8083, każdy w osobnym katalogu z unikalnym plikiem index.html identyfikującym serwer. Następnie skonfigurujemy Nginx jako reverse proxy na porcie 80, który będzie dystrybuował ruch między tymi trzema serwerami. W dalszej części laboratorium przetestujemy działanie algorytmu Round Robin za pomocą pętli w BASH, sprawdzimy rozkład ruchu i zdiagnozujemy ewentualne problemy. Wszystkie ćwiczenia mogą być wykonane na pojedynczej maszynie (localhost), co czyni laboratorium dostępnym bez potrzeby posiadania wielu serwerów czy skomplikowanej infrastruktury sieciowej.

W tym kroku laboratorium uruchamiamy trzy niezależne serwery HTTP na localhost, każdy na innym porcie. Moduł http.server Pythona jest idealny do testów, ponieważ uruchamia się natychmiast, nie wymaga konfiguracji i działa na dowolnym systemie z Pythonem 3. Ważne: każdy serwer ma własny katalog główny z plikiem index.html zawierającym unikalny identyfikator (Server 1, 2, 3). Dzięki temu, gdy wyślemy zadanie do reverse proxy, będziemy mogli po treści odpowiedzi stwierdzić, który serwer je obsłużył. Aby uruchomić serwery w tle, dodajemy znak & na końcu polecenia. Alternatywnie, można użyć terminala wielookienkowego (tmux, screen) lub otworzyć osobne terminale. Po uruchomieniu serwerów, testujemy je poleceniem curl. Dodatkowo przygotowujemy endpoint /health dla health checków. Pamiętaj: serwery Python działają tylko w trybie jednoprocesowym - nie są wydajne, ale do testów w pełni wystarczające.

Po uruchomieniu serwerów testowych, przystępujemy do konfiguracji Nginx jako reverse proxy. Tworzymy nowy plik konfiguracyjny w katalogu sites-available (Debian/Ubuntu) lub conf.d (RHEL/Fedora). Definiujemy blok upstream o nazwie backend, w którym wymieniamy trzy uruchomione serwery Python. Domyślnie Nginx użyje algorytmu Round Robin. W bloku server określamy nasłuch na porcie 80 i przekazanie wszystkich zadań do grupy backend. Dodajemy proxy_set_header, aby backend otrzymał prawdziwy adres IP klienta. Włączamy konfigurację przez dowiązanie symboliczne, testujemy składnię (nginx -t) i przeładowujemy Nginx (systemctl reload nginx). Ważne: reload nie zrywa aktywnych połączeń - Nginx płynnie przechodzi na nową konfigurację. Po przeładowaniu, Nginx nasłuchuje na porcie 80 i przekazuje zadania do serwerów Python.

Test obciążeniowy z pętlą w BASH to najprostszy sposób sprawdzenia, czy load balancing działa poprawnie. Polecenie curl -s http://localhost wysyła zadanie do Nginx, który przekazuje je do jednego z serwerów backendu. Pętla for wykonuje to 15 razy z półsekundowym interwałem. Jeśli wszystko działa poprawnie, odpowiedzi powinny pojawiać się w cyklu: Server 1, Server 2, Server 3, Server 1, ... - to znak, że Round Robin działa. Aby przetestować Least Connections, należy dodać dyrektywę least_conn, przeładować Nginx i powtórzyć test. Dla IP Hash dodajemy ip_hash - wtedy wszystkie zadania z tego samego adresu IP (127.0.0.1) powinny trafiać do tego samego serwera. To dobra okazja, aby zaobserwować różnice między algorytmami w praktyce.

Ten krok laboratorium demonstruje mechanizm sticky sessions w HAProxy. Konfigurujemy HAProxy jako reverse proxy z backendem wskazującym na serwery Python. Kluczowa dyrektywa to cookie SRVNAME insert indirect nocache w bloku backend oraz atrybut cookie srv1 (lub srv2, srv3) przy każdej deklaracji serwera. Dyrektywa insert oznacza, że HAProxy wstrzyknie ciasteczko Set-Cookie do odpowiedzi, indirect - ciasteczko nie będzie przesyłane do backendu, nocache - odpowiedzi z ciasteczkiem nie powinny być buforowane. Do testu używamy curl z opcjami -c (zapis ciasteczek do pliku) i -b (odczyt ciasteczek z pliku). Pierwsze zadanie zostanie przekazane do jednego z serwerów, a HAProxy doda ciasteczko Set-Cookie: SRVNAME=srvX. Kolejne zadania z tym ciasteczkiem będą kierowane zawsze do tego samego serwera.

Test symulacji awarii to jeden z najważniejszych testów w laboratorium. Uruchamiamy pętlę curl, która ciągle wysyła zadania do reverse proxy. W trakcie działania pętli, zatrzymujemy jeden z serwerów Python. Obserwujemy, co się dzieje: przez chwilę mogą pojawiać się błędy (502 Bad Gateway), ale po kilku sekundach load balancer wykrywa, że serwer nie odpowiada na health check i wyklucza go z puli. Od tego momentu ruch jest kierowany tylko do dwóch pozostałych serwerów. W interfejsie HAProxy stats widać, że serwer zmienił kolor na czerwony (DOWN). Po ponownym uruchomieniu serwera, load balancer po kilku udanych health checkach (parametr rise w HAProxy) przywraca go do puli. Ten test pokazuje kluczową cechę load balancingu: automatyczne failover i self-healing.

Jest to jeden z najczęstszych problemów przy wdrażaniu reverse proxy. Gdy Nginx lub HAProxy stoi przed serwerem backendu, to proxy ustanawia połączenie TCP z backendem. Z punktu widzenia backendu, połączenie pochodzi z adresu IP proxy (np. 10.0.0.1), a nie z adresu klienta (np. 203.0.113.5). Backend loguje więc adres proxy we wszystkich logach dostępu, co uniemożliwia analizę ruchu, blokowanie atakujących IP czy geolokalizację. Rozwiązaniem jest przekazanie oryginalnego adresu IP klienta w nagłówku HTTP. Standardem jest nagłówek X-Forwarded-For (XFF), który zawiera listę adresów IP oddzielonych przecinkami. W Nginx dodajemy: proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;. W HAProxy: option forwardfor. Po stronie backendu trzeba skonfigurować logowanie nagłówka X-Forwarded-For zamiast $remote_addr.

Konfiguracja przekazywania adresu IP klienta przez reverse proxy wymaga zmian po obu stronach: proxy i backend. Po stronie proxy (Nginx): dyrektywa proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; dodaje adres IP klienta ($remote_addr) do listy w nagłówku X-Forwarded-For. Jeśli zadanie przyszło już z XFF (np. od innego proxy), to $proxy_add_x_forwarded_for dołączy nowy adres do listy. Dodatkowo, proxy_set_header X-Real-IP $remote_addr; ustawia nagłówek X-Real-IP z jednym adresem. Po stronie backendu trzeba zmienić format logowania. Ważne ostrzeżenie: X-Forwarded-For jest nagłówkiem, który klient może łatwo fałszować (np. dodać X-Forwarded-For: 127.0.0.1). Dlatego w środowiskach produkcyjnych nagłówek X-Forwarded-For jest zaufany tylko wtedy, gdy został dodany przez zaufane proxy - nie wolno ufać wartości z zewnętrznego zadania. W niektórych przypadkach stosuje się mechanizm proxy_protocol (PROXY protocol v1/v2) jako bardziej bezpieczną alternatywę.

W HAProxy konfiguracja jest prostsza niż w Nginx: wystarczy dodać option forwardfor w bloku defaults (działa dla wszystkich backendów) lub w konkretnym bloku backend. HAProxy automatycznie dodaje nagłówek X-Forwarded-For do każdego zadania przekazywanego do backendu, z wartością równą adresowi IP klienta. Opcjonalnie można użyć option forwardfor except 10.0.0.0/8, aby nie dodawać X-Forwarded-For dla ruchu z zaufanych podsieci wewnętrznych. Dodatkowo HAProxy oferuje option originalto, które dodaje nagłówek X-Original-To z oryginalnym docelowym adresem IP (przydatne, gdy ruch przychodzi na wiele adresów IP). HAProxy oferuje też tryb transparent (wymaga root), w którym połączenia z backendem wyglądają tak, jakby pochodziły bezpośrednio od klienta - ale to wymaga zaawansowanej konfiguracji rutingu i iptables.

Diagnostyka martwych serwerów backendu to podstawowa umiejętność administratora reverse proxy. Gdy klienci zgłaszają błędy 502 (Bad Gateway) lub 503 (Service Unavailable), pierwszym krokiem jest sprawdzenie, czy serwery backendu w ogóle działają (systemctl status). Następnie sprawdzamy logi Nginx (error.log) pod kątem komunikatów o timeoutach upstream. Warto również ręcznie przetestować health check z poziomu serwera proxy, aby wykluczyć problemy sieciowe. W HAProxy najlepszym narzędziem jest interfejs statystyk, który w czasie rzeczywistym pokazuje stan każdego serwera. Częste problemy: (1) serwer backendu nie nasłuchuje na oczekiwanym porcie, (2) zapora sieciowa (firewall) blokuje ruch między proxy a backendem, (3) serwer backendu jest przeciążony i nie odpowiada w czasie (timeout), (4) ścieżka health checka jest niepoprawna (404 zamiast 200). W przypadku timeoutów warto zwiększyć wartości proxy_read_timeout i proxy_connect_timeout w Nginx.

Zaawansowana diagnostyka proxy wymaga użycia kilku narzędzi jednocześnie. Po pierwsze, analiza logów dostępu (access.log) pozwala sprawdzić, do którego serwera backendu trafiają poszczególne zadania. W Nginx domyślny format logu nie zawiera adresu upstream, ale można go dodać: $upstream_addr. Po drugie, curl -v pokazuje pełne nagłówki HTTP, w tym X-Forwarded-For i X-Cache-Status. Jeśli X-Forwarded-For nie zawiera prawidłowego adresu IP klienta, konfiguracja proxy jest niepoprawna. Po trzecie, testowanie timeoutów pozwala zidentyfikować, czy problem leży po stronie proxy (zbyt krótki timeout) czy backendu (zbyt długie przetwarzanie). Po czwarte, narzędzia do testowania wydajności (Apache Bench, hey, wrk) pozwalają sprawdzić, jak load balancer zachowuje się pod obciążeniem. Przydatne jest również narzędzie ngxtop do monitorowania logów Nginx w czasie rzeczywistym oraz tcpdump do analizy ruchu sieciowego między proxy a backendem.

Poniższe zestawienie zawiera najważniejsze komendy i dyrektywy do codziennej pracy z reverse proxy. Dla Nginx: testowanie konfiguracji (nginx -t), przeładowanie bez restartu (systemctl reload nginx), przeglądanie logów dostępu i błędów. Dla HAProxy: testowanie konfiguracji (haproxy -c), przeładowanie, dostęp do interfejsu statystyk na porcie 8404. Do testowania dystrybucji ruchu: pętla w BASH z curl. Do debugowania buforowania: dodaj nagłówek X-Cache-Status. Do sprawdzenia adresów upstream w logach: dodaj $upstream_addr do formatu logowania. Kluczowe dyrektywy konfiguracyjne do zapamiętania: proxy_pass (Nginx), balance (HAProxy), option forwardfor (HAProxy), proxy_set_header (Nginx), proxy_cache_path (Nginx), cookie SRVNAME insert (HAProxy). W razie problemów: zawsze najpierw sprawdź logi błędów (error.log), potem health checki, a na końcu ruch sieciowy tcpdumpem.