Nginx to najczęściej wybierany serwer WWW dla stron WordPress o wysokim ruchu. Niskie zużycie pamięci, asynchroniczna obsługa połączeń i wbudowane mechanizmy cache sprawiają, że Nginx jest fundamentem wydajnego hostingu WordPress. W tym artykule omawiamy kluczowe aspekty konfiguracji Nginx pod WordPress, porównanie z Apache oraz nowości, które pojawiły się w wersji Nginx 1.30 stable — najnowszej gałęzi stabilnej wydanej w kwietniu 2026.
Dlaczego Nginx dla WordPress
Nginx obsługuje znaczną część stron w internecie i dominuje wśród profesjonalnych hostingów WordPress. Jego architektura event-driven pozwala obsłużyć tysiące jednoczesnych połączeń przy minimalnym zużyciu RAM — w przeciwieństwie do modelu procesowego Apache.
Event-driven zamiast procesów
Nginx nie tworzy osobnego procesu ani wątku per połączenie. Jeden worker process obsługuje tysiące jednoczesnych żądań dzięki asynchronicznemu I/O (epoll na Linuksie). To przekłada się na przewidywalną wydajność nawet pod dużym obciążeniem — serwer nie zwalnia gwałtownie po przekroczeniu pewnego progu ruchu.
Niższy TTFB i wyższe req/s
Nginx generuje niższy Time to First Byte niż Apache w typowych konfiguracjach WordPress. Serwowanie plików statycznych (CSS, JS, obrazy) bezpośrednio przez Nginx bez angażowania PHP jest wielokrotnie szybsze niż przesyłanie ich przez mod_php czy PHP-FPM. Mniej pracy dla backendu = szybsza strona.
Oszczędność pamięci
Przy tysiącach jednoczesnych połączeń Nginx zużywa ułamek pamięci potrzebnej Apache z prefork MPM. Mniejsze zużycie RAM oznacza więcej zasobów dla PHP-FPM i bazy danych — tam, gdzie WordPress naprawdę ich potrzebuje. Na VPS z ograniczonym RAM to różnica między płynną stroną a spowolnieniem. Właściwa administracja Linux i tuning systemu operacyjnego są kluczowe.
Natywny reverse proxy i load balancer
Nginx od podstaw zaprojektowano jako reverse proxy. Terminacja SSL, balansowanie ruchu między backendami, caching odpowiedzi — to funkcje wbudowane, nie doinstalowane moduły. Idealny stack dla WordPress: Nginx jako frontend obsługujący SSL i pliki statyczne → PHP-FPM jako backend generujący dynamiczne strony. To wymaga solidnej administracji serwerem.
Konfiguracja Nginx pod WordPress — kluczowe elementy
Prawidłowa konfiguracja Nginx pod WordPress wymaga uwzględnienia kilku elementów: przekierowania żądań do PHP-FPM, obsługi pretty permalinks, cache'owania i nagłówków bezpieczeństwa.
fastcgi_pass). Unix socket jest szybszy niż TCP. Pool PHP-FPM powinien mieć osobną konfigurację per strona, z parametrem pm.max_children dostosowanym do dostępnego RAM serwera.try_files $uri $uri/ /index.php?$args; aby obsługiwać czytelne adresy URL. Bez niej wszystkie podstrony oprócz strony głównej zwracają błąd 404. To odpowiednik reguł .htaccess z Apache, ale zdefiniowany bezpośrednio w konfiguracji Nginx.location z nagłówkiem expires i wyłączonym logowaniem (access_log off;) znacząco odciąża serwer. To jedna z głównych przewag Nginx nad Apache z mod_php.X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security (HSTS) i Content-Security-Policy. Konfiguracja w bloku server {} zapewnia spójne nagłówki dla wszystkich odpowiedzi — zarówno statycznych, jak i dynamicznych.TLSv1.2 TLSv1.3), krzywych, cipher suites i OCSP stapling. Od Nginx 1.30 domyślne protokoły SSL to TLSv1.2 i TLSv1.3 — stare protokoły wymagają jawnego włączenia. Integracja z Let's Encrypt i automatycznym odnawianiem certyfikatów jest prosta.Nowości w Nginx 1.30 stable
Nginx 1.30.0 to nowa gałąź stable wydana w kwietniu 2026 — konsoliduje wszystkie nowości z mainline 1.29.x. To duże wydanie, które przynosi kilkanaście istotnych zmian wpływających na wydajność, bezpieczeństwo i prywatność. Poniżej najważniejsze z nich.
HTTP/2 do backendów
Nginx może teraz utrzymywać połączenia HTTP/2 z serwerami upstream. Wcześniej — nawet gdy klient łączył się po HTTP/2 — Nginx degradował połączenie do HTTP/1.x w kierunku backendu. Teraz możliwa jest pełna komunikacja HTTP/2 end-to-end, co eliminuje narzut ponownego nawiązywania połączeń i obniża latencję.
Encrypted Client Hello (ECH)
Rozszerzenie TLS 1.3, które szyfruje pole SNI w handshake. Bez ECH — pasywny obserwator widzi, do jakiej domeny łączy się użytkownik, mimo że reszta połączenia jest zaszyfrowana. ECH zamyka tę lukę. Konfiguracja przez dyrektywę ssl_ech_file. Wymaga OpenSSL z gałęzią ECH (docelowo OpenSSL 4.0).
Multipath TCP (MPTCP)
Parametr multipath dyrektywy listen umożliwia korzystanie z wielu ścieżek sieciowych jednocześnie. Korzyści: wyższa przepustowość, bezproblemowe przełączanie między interfejsami i lepsza odporność na awarię pojedynczego łącza. Wymaga Linuksa 5.6+.
Keepalive domyślnie do upstream
Dyrektywa keepalive w bloku upstream jest teraz włączona domyślnie (32 połączenia per worker). Domyślna wersja HTTP do upstream zmieniona z 1.0 na 1.1 — nagłówek Connection nie jest już wysyłany. To eliminuje najczęstszy błąd konfiguracyjny Nginx z PHP-FPM i poprawia wydajność out-of-the-box.
Sticky sessions (session affinity)
Dyrektywa sticky w bloku upstream — wcześniej dostępna wyłącznie w Nginx Plus. Pozwala przypiąć klienta do konkretnego backendu na podstawie cookie. Kluczowe dla klastrów WordPress z sesjami PHP i WooCommerce z koszykiem zakupowym.
103 Early Hints
Dyrektywa early_hints pozwala Nginx wysłać odpowiedź HTTP 103 z nagłówkami Link: rel=preload jeszcze zanim backend (PHP-FPM) wygeneruje właściwą odpowiedź. Przeglądarka zaczyna pobierać CSS, JS i fonty wcześniej — to bezpośrednia poprawa Largest Contentful Paint. Główne przeglądarki (Chrome, Edge) już obsługują Early Hints.
Dyrektywa max_headers
Nowa dyrektywa pozwala ograniczyć maksymalną liczbę nagłówków HTTP w żądaniu klienta. Ochrona przed atakami typu resource exhaustion i buffer overflow, które wykorzystują żądania z setkami nagłówków. Proste, ale skuteczne zabezpieczenie DoS na poziomie serwera WWW — bez dodatkowego oprogramowania.
Kompatybilność z OpenSSL 4.0
Nginx 1.30 współpracuje z OpenSSL 4.0, który wprowadza surowszą walidację algorytmów i ulepszone mechanizmy wymiany kluczy. Zapewnia wsparcie najnowszych standardów kryptograficznych i przyszłościową podstawę bezpieczeństwa TLS. Dodano też dyrektywę ssl_certificate_compression i wsparcie 0-RTT w QUIC z OpenSSL 3.5+.
Nginx vs Apache — kiedy który wybrać
Oba serwery mogą obsługiwać WordPressa, ale mają fundamentalnie różne mocne strony. Nginx dominuje w scenariuszach produkcyjnych wymagających wydajności i skalowalności — Apache zachowuje przewagę w prostych konfiguracjach shared hosting.
.htaccess — plik konfiguracyjny na poziomie katalogu, popularny wśród wtyczek WordPress (przekierowania, cache, reguły bezpieczeństwa). Nginx nie ma odpowiednika — cała konfiguracja jest w plikach .conf. Reguły z .htaccess wymagają ręcznej konwersji na składnię Nginx..htaccess jest łatwiejszy dla początkujących i hostingów shared. Nginx wymaga edycji plików konfiguracyjnych z uprawnieniami root — co jest normą na VPS, serwerach dedykowanych i w zarządzanym hostingu WordPress.Podsumowanie
Nginx to fundament wydajnego hostingu WordPress. Architektura event-driven, wbudowany cache, natywny reverse proxy i terminacja SSL sprawiają, że jest optymalnym wyborem dla stron o wysokim ruchu i wymaganiach wydajnościowych. Nginx 1.30 stable przynosi istotne nowości: HTTP/2 do backendów, keepalive domyślnie, sticky sessions (wcześniej tylko w Nginx Plus), Encrypted Client Hello, Early Hints i Multipath TCP. Konfiguracja Nginx pod WordPress wymaga wiedzy serwerowej — od PHP-FPM przez cache po nagłówki bezpieczeństwa.
W WebOptimo konfigurujemy i optymalizujemy Nginx pod WordPress w ramach administracji serwerami i hostingu WordPress. Jeśli Twoja strona działa na domyślnej konfiguracji lub rozważasz migrację z Apache — skontaktuj się z nami lub sprawdź ofertę opieki WordPress.
Najczęstsze pytania o Nginx i WordPress
Dla stron o wysokim ruchu — tak. Nginx efektywniej zarządza pamięcią i obsługuje więcej jednoczesnych połączeń dzięki architekturze event-driven. Apache ma przewagę w środowiskach shared hosting dzięki obsłudze .htaccess. Dla VPS i serwerów dedykowanych Nginx jest standardem w profesjonalnym hostingu WordPress.
Tak — Nginx doskonale sprawdza się z WooCommerce. Nginx 1.30 wprowadza sticky sessions, które są kluczowe dla sklepów z koszykiem opartym na sesjach PHP. W połączeniu z fastcgi_cache (z wyjątkiem stron koszyka i checkout) Nginx znacząco przyspiesza sklepy WooCommerce.
Potencjalnie tak. Najważniejsza zmiana: domyślna wersja HTTP do upstream to teraz 1.1 z keepalive. Jeśli Twoja konfiguracja ręcznie ustawiała proxy_http_version 1.1 — możesz usunąć zbędne linie. Jeśli polegałeś na zachowaniu HTTP/1.0 do upstreamu — sprawdź kompatybilność backendu przed aktualizacją.
Tak — wsparcie HTTP/3 pojawiło się w Nginx 1.25 i jest aktywnie rozwijane. Nginx 1.30 zawiera poprawki QUIC, algorytm kontroli przeciążenia CUBIC i wsparcie 0-RTT z OpenSSL 3.5+. HTTP/3 wymaga kompilacji z odpowiednią biblioteką SSL wspierającą QUIC.
Przez SSH: komenda nginx -v wyświetla wersję, nginx -V — wersję wraz z opcjami kompilacji. Wersję można ukryć przed klientami dyrektywą server_tokens off; w konfiguracji Nginx. Regularne sprawdzanie wersji jest ważne — starsze wersje nie otrzymują poprawek bezpieczeństwa.