Nginx, Apache czy LiteSpeed? Który serwer WWW wybrać w 2026

Nginx obsługuje 38,6 procent stron, Apache 36, LiteSpeed 5,7. Te liczby oddają układ sił na rynku serwerów WWW, ale nie mówią całej prawdy o tym, który serwer komu i do czego się opłaca. Pora rozłożyć je na części pierwsze — od architektury, przez wydajność pod obciążeniem, po wsparcie HTTP/3 i mechanizmy ochrony.

Rynek serwerów WWW w 2026 roku — liczby, które warto znać

Dane Aguko z czerwca 2026 roku pokazują wyraźny trend: Nginx umacnia pozycję lidera, Apache systematycznie traci, a LiteSpeed rośnie najszybciej. W3Techs podaje nieco inne wartości — Nginx około 33 procent, Apache 24 procent — ale kierunek jest ten sam niezależnie od źródła.

LiteSpeed szczególnie mocno zaznacza swoją obecność w nowszych technologiach. Obsługuje ponad 36 procent stron korzystających z protokołu HTTP/3, przy całkowitym udziale w rynku na poziomie zaledwie 5,7 procent. To wyraźny sygnał: hostingodawcy, którzy postawili na LiteSpeed, świadomie inwestują w przyszłościowe rozwiązania, a ich klienci korzystają z tego bez dodatkowej konfiguracji.

Apache przeżywa najtrudniejszy okres w swojej ponad trzydziestoletniej historii. W listopadzie 2025 roku stracił 3,6 miliona stron w ciągu jednego miesiąca — największy jednomiesięczny spadek, jaki kiedykolwiek zanotował. Główny powód to architektura, która nie nadąża za współczesnymi wzorcami ruchu internetowego.

Architektura — fundament, który przesądza o wszystkim

Różnice między tymi trzema serwerami zaczynają się na poziomie obsługi połączeń przychodzących. To nie szczegół implementacyjny, lecz decyzja projektowa, która determinuje wszystko inne: zużycie pamięci, skalowalność, zachowanie pod obciążeniem i możliwości optymalizacji. Dopiero po zrozumieniu architektury liczby z testów wydajnościowych zaczynają mieć sens.

Apache: model procesowy i jego granice

Apache od zawsze działa w modelu procesowym lub wątkowym. Każde nowe połączenie przychodzące od użytkownika to osobny proces albo wątek systemu operacyjnego. Przez lata to wystarczało — ruch był niższy, połączenia krótsze, a serwery z 512 MB RAM uchodziły za wydajne.

Problem pojawia się przy tysiącach równoczesnych połączeń, co dziś jest normą nawet na średniej wielkości stronie. W trybie Prefork — najstarszym i najbezpieczniejszym — Apache obsługujący dziesięć tysięcy równoczesnych połączeń potrzebuje od 50 do 100 gigabajtów pamięci RAM. To liczba, która wyklucza go z jakichkolwiek rozważań o skalowalności.

Tryb Event MPM, domyślny w Apache 2.4, jest znacznie lepszy. Przy tym samym obciążeniu dziesięciu tysiącem połączeń pochłania od 2 do 5 gigabajtów RAM. To postęp, ale wciąż kilkudziesięciokrotnie więcej niż Nginx przy identycznym scenariuszu.

Nginx: jeden proces, tysiące połączeń

Nginx od początku projektowano z myślą o problemie zwanym C10k — obsłudze dziesięciu tysięcy równoczesnych połączeń na jednym serwerze. W 2004 roku, gdy Igor Sysoev opublikował pierwszą wersję, był to ambitny cel. Dziś jest to minimum dla każdej liczącej się platformy internetowej.

Architektura sterowana zdarzeniami i nieblokujące wejście-wyjście sprawiają, że jeden proces roboczy Nginx może obsługiwać tysiące połączeń naraz, nie tworząc osobnego procesu dla każdego z nich. Przy dziesięciu tysiącach równoczesnych połączeń Nginx zużywa 50 do 100 megabajtów RAM. To różnica rzędu tysiąckrotności względem Apache w trybie Prefork i kilkudziesięciokrotności względem trybu Event MPM.

Nginx doskonale sprawdza się jako serwer do plików statycznych, odwrotne proxy i punkt równoważenia obciążenia. Jest standardem w infrastrukturze chmurowej, kontenerach i klastrach Kubernetes. Wiele dużych serwisów internetowych używa go właśnie do tego zadania, kierując żądania dynamiczne do wyspecjalizowanych backendów.

LiteSpeed: LSAPI i pamięć podręczna wbudowana w serwer

LiteSpeed również opiera się na architekturze zdarzeniowej, więc jego wydajność pod względem obsługi połączeń jest zbliżona do Nginx. Kluczowe różnice leżą gdzie indziej — w sposobie komunikacji z PHP i w wbudowanej pamięci podręcznej.

LSAPI to zastrzeżony protokół, który LiteSpeed używa do komunikacji z PHP. Nginx musi korzystać z zewnętrznego PHP-FPM przez FastCGI — każde żądanie wymaga oddzielnego przejścia przez gniazdo. LiteSpeed komunikuje się z PHP bezpośrednio i w sposób stanowy, utrzymując połączenie między żądaniami. Niezależne testy wskazują, że LSAPI jest około 30 procent szybsze od FastCGI przy pracy z PHP 8.5.

Drugim wyróżnikiem jest LSCache — wbudowana pamięć podręczna działająca na poziomie jądra serwera, zanim PHP w ogóle zostanie uruchomiony. Oznacza to, że żądanie do strony WordPress może zostać obsłużone bez angażowania bazy danych, silnika PHP ani samego WordPressa. LSCache jest włączone domyślnie i działa od razu po instalacji — bez konfigurowania zewnętrznych warstw cache.

Wydajność: ile zapytań na sekundę?

Testy na identycznym sprzęcie — dwa rdzenie, 2 gigabajty RAM — ze standardową instalacją WordPressa bez żadnego cache pokazują zbliżone wyniki dla Apache i Nginx: oba osiągają około 350 zapytań na sekundę, po czym procesor jest nasycony w stu procentach i pojawia się kolejka. LiteSpeed z domyślnie włączonym LSCache sięga w tych samych warunkach 2400 zapytań na sekundę bez żadnych przekroczeń czasu ani błędów.

Przy wyższym obciążeniu różnica jeszcze rośnie. Symulacja 700 klientów na sekundę powoduje u Apache i Nginx masę błędów i przekroczeń czasu — serwery nie nadążają z obsługą kolejki. LiteSpeed przy tym samym scenariuszu pracuje stabilnie, obsługując ponad milion zapytań bez ani jednego przekroczenia czasu.

Testy LiteSpeed Technologies z HTTP/2 robią wrażenie: prawie 70 tysięcy zapytań na sekundę dla LiteSpeed, 6 tysięcy dla Nginx i 826 dla Apache. Relacja 12 do 1 względem Nginx i 84 do 1 względem Apache. Zastrzeżenie jest takie, że to testy producenta — warto podejść do nich ze zdrowym dystansem i traktować jako górną granicę możliwości, nie typowy wynik produkcyjny.

Niezależne testy LinuxConfig.org pokazują mniejsze, ale wciąż wyraźne różnice. W rankingu łącznym obejmującym pliki statyczne, duże pliki, wysoką konkurencyjność i mieszane obciążenie Nginx uzyskał 97,5 procent maksymalnej możliwej wydajności, OpenLiteSpeed 97,2, LiteSpeed Enterprise 95,4. Apache zamknął stawkę z wynikiem 82,1 procent.

Jak pamięć podręczna niweluje różnice między serwerami

Gdy strona jest serwowana z cache, różnice między serwerami praktycznie znikają. Każdy z nich zwraca odpowiedzi w okolicach 66 milisekund, a wahania na poziomie jednego do dwóch procent są dla użytkownika zupełnie niezauważalne. Z perspektywy odwiedzającego strona po prostu działa szybko.

Największą praktyczną przewagą LiteSpeed nie jest więc surowa szybkość w testach syntetycznych, lecz to, że LSCache działa od razu, bez żadnej konfiguracji. W Nginx, żeby uzyskać porównywalny efekt, trzeba samodzielnie wdrożyć FastCGI Cache — skonfigurować odpowiednie dyrektywy w plikach konfiguracyjnych, ustawić czas życia wpisów, obsłużyć inwalidację cache przy aktualizacji treści. Wymaga to wiedzy technicznej i dostępu do konfiguracji serwera. W Apache sytuacja jest podobna — cache trzeba wdrożyć przez zewnętrzne wtyczki WordPress i wciąż liczyć na to, że zadziała poprawnie z motywem i innymi wtyczkami.

HTTP/3 i protokół QUIC — kto jest gotowy?

HTTP/3 opiera się na protokole QUIC, który działa na UDP zamiast TCP. Efekty praktyczne są wymierne: szybsze nawiązywanie połączenia, brak blokowania na poziomie pojedynczego strumienia danych, płynne przełączanie między sieciami bez zrywania połączenia. Ostatni punkt ma szczególne znaczenie dla użytkowników mobilnych przechodzących z WiFi na transmisję danych komórkowych w środku sesji.

LiteSpeed wdrożył produkcyjne wsparcie HTTP/3 jako pierwszy — w 2019 roku. Dziś protokół QUIC jest włączony domyślnie i wystarczy otworzyć port UDP 443 w zaporze sieciowej. Żadnej dodatkowej konfiguracji, żadnej kompilacji ze źródeł.

Nginx dodał HTTP/3 w wersji 1.25.0, ale wymaga ręcznej kompilacji z odpowiednim modułem i biblioteką SSL obsługującą QUIC. W 2026 roku wsparcie jest uznawane za w pełni funkcjonalne i stabilne produkcyjnie, jednak wciąż nie jest to opcja dla kogoś, kto oczekuje włączenia jednym kliknięciem w panelu. Administratorzy z doświadczeniem w kompilacji Nginx poradzą sobie bez problemu.

Apache HTTP/3 nie obsługuje i nic nie wskazuje, żeby miało się to zmienić w najbliższym czasie. To kolejny powód, dla którego Apache jest coraz mniej atrakcyjnym wyborem dla nowych projektów wymagających nowoczesnych protokołów.

Wpływ HTTP/3 na widoczność w wyszukiwarkach jest wymierny. Badania Akamai pokazują średnio pięcioprocentowy wzrost ruchu organicznego w pierwszym miesiącu od wdrożenia. Niższy czas do pierwszego bajtu przekłada się bezpośrednio na lepsze wskaźniki Core Web Vitals, a te są czynnikiem rankingowym Google od 2021 roku.

Bezpieczeństwo: podatności i wbudowane mechanizmy obrony

W 2026 roku zarówno Apache, jak i Nginx musiały łatać realne podatności. W Apache wykryto dwie istotne luki: CVE-2026-23918, czyli podwójne zwolnienie pamięci w obsłudze HTTP/2 z potencjałem zdalnego wykonania kodu, oraz CVE-2026-29168, polegającą na wyczerpaniu zasobów przez moduł obsługi certyfikatów. Obie załatano w wersji 2.4.67, ale sam fakt ich istnienia pokazuje, że większa baza kodu i długa historia niosą ze sobą większą powierzchnię ataku.

W Nginx w tym samym czasie załatano CVE-2026-40460 — podszywanie się pod adres źródłowy w HTTP/3 — oraz CVE-2026-40701 dotyczący użycia pamięci po zwolnieniu w module obsługi certyfikatów OCSP. Naprawiono też kilka przepełnień bufora w modułach obsługi reguł przekierowań i kodowania znaków.

LiteSpeed nie odnotował w 2026 roku żadnych zgłoszonych podatności CVE. Może to wynikać zarówno z mniejszej powierzchni ataku i prostszej architektury, jak i z prostszego faktu: znacznie mniej badaczy bezpieczeństwa aktywnie analizuje ten serwer. Oba wyjaśnienia są prawdopodobne i nie wykluczają się nawzajem.

Jeśli chodzi o wbudowane mechanizmy obrony, LiteSpeed oferuje najszerszy zestaw dostępny z pudełka:

• Ochrona przed atakami siłowymi na strony logowania WordPress
• Wbudowana zapora aplikacji webowej oparta na ModSecurity
• Integracja z reCAPTCHA bez potrzeby instalowania dodatkowych wtyczek
• Natywna ochrona przed atakami odmowy usługi na poziomie serwera
• Ograniczanie liczby żądań na poziomie konfiguracji serwera

Nginx i Apache wymagają w tych obszarach ręcznej konfiguracji i dodatkowych modułów lub wtyczek. To nie dyskwalifikuje ich jako platformy — oba serwery można solidnie zabezpieczyć — ale oznacza więcej pracy i większe ryzyko błędu w konfiguracji.

Dla kogo który serwer? Praktyczny podział

Odpowiedź zależy od tego, co budujesz i jakie masz zasoby — techniczne i ludzkie.

Apache — kiedy ma sens

Apache wciąż jest rozsądnym wyborem w dwóch konkretnych sytuacjach. Pierwsza: mała strona z ruchem poniżej tysiąca odwiedzających dziennie, na której zależy ci na prostej konfiguracji i minimalnym nakładzie pracy. Apache jest dobrze udokumentowany, ma ogromną społeczność i sprawdzoną dokumentację po polsku i angielsku — znalezienie odpowiedzi na pytanie zajmuje minuty. Druga: starsza aplikacja zbudowana w całości wokół reguł w plikach .htaccess, gdzie przepisanie konfiguracji pod inny serwer byłoby kosztowne i ryzykowne.

Apache to też nadal standard w tanim hostingu współdzielonym — często po prostu nie masz wyboru. W takiej sytuacji nie ma sensu walczyć z ograniczeniami środowiska. Zamiast tego warto skupić się na optymalizacji po stronie WordPressa i dobrej wtyczce do cache.

Nginx — kiedy to naturalny wybór

Nginx sprawdza się najlepiej przy wysokim ruchu, statycznych treściach i jako odwrotne proxy. Jeśli twoja strona obsługuje dziesiątki tysięcy odwiedzających dziennie, budujesz interfejs programistyczny lub potrzebujesz równoważenia obciążenia między kilkoma backendami — Nginx to naturalny wybór. Jest standardem w infrastrukturze chmurowej, klastrach kontenerów i architekturach mikroserwisowych. Jego zużycie pamięci i skalowalność nie mają sobie równych w serwowaniu plików statycznych.

LiteSpeed — kiedy chcesz więcej przy mniej wysiłku

LiteSpeed to wybór dla WordPressa i dynamicznych treści, gdy zależy ci na namacalnym wzroście wydajności bez głębokiego zagłębiania się w konfigurację serwera. WooCommerce, blog, strona firmowa, portfolio — z LSCache dostajesz przyspieszenie od pierwszego dnia, a HTTP/3 włączone z pudełka to korzyść SEO bez dodatkowej pracy.

Dodatkowy plus: LiteSpeed czyta pliki .htaccess Apache natywnie, więc migracja z Apache na LiteSpeed sprowadza się do kilku kliknięć i nie wymaga przepisywania reguł. To znacznie obniża próg wejścia dla osób zarządzających istniejącymi stronami.

Podsumowanie — który serwer wybrać?

Żaden z tych serwerów nie jest uniwersalnie najlepszy. Chodzi o dobranie narzędzia do konkretnego zadania:

• Nginx — do wysokiego ruchu, plików statycznych, nowoczesnych architektur i odwrotnego proxy. Standard w chmurze i kontenerach.
• LiteSpeed — do WordPressa, WooCommerce i stron, które mają być szybkie od pierwszego dnia, bez pogłębionej konfiguracji serwera. HTTP/3 i LSCache z pudełka.
• Apache — gdy hosting nie daje wyboru, albo gdy masz małą stronę i zależy ci na sprawdzonej, dobrze udokumentowanej platformie z ogromną bazą wiedzy.

Jeśli dopiero zakładasz stronę i nie wiesz, który wybrać — postaw na LiteSpeed. To wybór, który daje najwięcej przy najmniejszym wysiłku, szczególnie przy WordPressie. Gdy Twoja strona urośnie do rozmiarów, gdzie potrzebne będzie precyzyjne strojenie pod wysokie obciążenia lub niestandardowa architektura, wróć do tego porównania — wtedy Nginx może okazać się lepszym narzędziem do specyficznych zadań.

Jedno jest pewne: Apache to wybór z przeszłości. Nie dlatego, że jest zły, ale dlatego, że architektura procesowa i brak HTTP/3 sprawiają, że w 2026 roku jest po prostu słabszą kartą w ręce niż dwaj pozostali zawodnicy w tej stawce.