Przejdź do głównej zawartości

Konfiguracja Nginx, która utrzymuje szybkość stron

· 5 min aby przeczytać
Mari-Liis Järv
Customer Care Engineer

Opublikowano 19 września 2026

Konfiguracja Nginx, która zapewnia szybkość witryn

Strona może wyglądać na całkowicie sprawną, dopóki drobny błąd w konfiguracji Nginx nie zamieni rutynowego wdrożenia w błąd 502, ostrzeżenie SSL albo pętlę przekierowań, która nie prowadzi odwiedzających do niczego użytecznego. Nginx jest szybki i niezawodny, ale jest też wymagający: jedna dyrektywa w niewłaściwym miejscu może zmienić sposób działania całej strony. Dobra wiadomość jest taka, że uporządkowane podejście sprawia, że konfiguracja Nginx staje się znacznie mniej tajemnicza.

Ten przewodnik skupia się na ustawieniach, które mają największe znaczenie podczas hostowania stron internetowych: blokach serwera, obsłudze PHP, HTTPS, przekierowaniach, plikach statycznych, cache i bezpiecznym testowaniu. Nie musisz zapamiętywać każdej dyrektywy Nginx. Musisz zrozumieć, które decyzje wpływają na Twoją stronę i jak je zweryfikować, zanim wpłyną na odwiedzających.

Zacznij od przejrzystego układu konfiguracji Nginx​

Większość instalacji Linuksa oddziela ustawienia globalne od ustawień poszczególnych stron internetowych. Główny plik konfiguracji, zwykle znajdujący się w /etc/nginx/nginx.conf, kontroluje procesy robocze, logowanie, kompresję i dołączane katalogi konfiguracji. Poszczególne strony zwykle znajdują się w katalogu takim jak sites-available, sites-enabled lub conf.d.

Ten podział jest przydatny z praktycznego powodu: ustawienia globalne należy zmieniać ostrożnie i rzadko, podczas gdy ustawienia na poziomie strony wymagają regularnej uwagi. Nowa domena, środowisko testowe albo reguła przekierowania należą do bloku serwera tej strony, a nie do głównego pliku.

Zanim cokolwiek zmienisz, zidentyfikuj aktywną konfigurację i ją przetestuj:

bash nginx -t

Jeśli test się powiedzie, przeładuj Nginx bez zrywania aktywnych połączeń:

bash systemctl reload nginx

Używaj reload do zwykłych zmian w konfiguracji. Pełny restart jest czasem konieczny, ale nie powinien być pierwszym krokiem przy aktualizacji hosta wirtualnego. Takie drobne nawyki sprawiają, że zadanie na pięć minut nie zamienia się w nocne przywracanie działania.

Utwórz jeden blok serwera dla każdej strony​

Blok serwera mówi Nginx, którą domenę obsługuje, gdzie przechowywane są pliki strony internetowej i jak mają być obsługiwane żądania. Pomyśl o nim jak o recepcji dla jednej strony internetowej. Gdy kilka domen współdzieli jeden serwer, uporządkowany blok serwera sprawia, że ruch trafia we właściwe miejsce.

Podstawowa strona HTTP może wyglądać tak:

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

server_name powinno zawierać każdą nazwę hosta, którą zamierzasz obsługiwać. Jeśli odwiedzający mogą korzystać zarówno z domeny głównej, jak i z www, uwzględnij obie, a następnie zdecyduj, która ma być kanoniczna poprzez przekierowanie.

Ścieżka root musi wskazywać katalog zawierający publiczne pliki WWW, a niekoniecznie katalog główny projektu. W przypadku WordPressa jest to często folder, w którym znajdują się wp-admin, wp-content i wp-includes. W przypadku Laravel i podobnych frameworków jest to zazwyczaj katalog public. Skierowanie Nginx na niewłaściwy folder może ujawnić pliki, które nigdy nie powinny być publicznie dostępne.

Reguła try_files zasługuje na uwagę. Sprawdza ona, czy żądany plik lub katalog istnieje, zanim przekaże niedopasowane żądania do aplikacji. Jest to niezbędne dla bezpośrednich odnośników WordPressa i wielu nowoczesnych aplikacji PHP. Bez tego strony mogą działać tylko wtedy, gdy odwiedzający użyją pełnego adresu URL z dołączonym index.php. To nie jest idealne i nie jest to problem, o którym chcesz dowiedzieć się najpierw od klientów.

Unikaj pułapki serwera domyślnego​

Nginx potrzebuje serwera domyślnego dla żądań, które nie pasują do skonfigurowanej nazwy hosta. Jeśli niewłaściwa strona jest ustawiona jako domyślna, nieznana domena lub bezpośrednie żądanie IP może wyświetlić czyjąś inną stronę internetową. To w najlepszym razie mylące, a w najgorszym ryzykowne.

W przypadku serwerów z wieloma stronami użyj prostego serwera domyślnego, który nie zwraca żadnej użytecznej treści, na przykład odpowiedzi 404. Trzymaj właściwe strony internetowe w jawnych blokach serwera z ich własnymi wartościami server\_name. To niewielka granica, która ułatwia zarządzanie współdzielonym serwerem.

Skonfiguruj PHP bez zgadywania​

Nginx nie przetwarza PHP samodzielnie. Przekazuje żądania PHP do PHP-FPM, które uruchamia kod. Połączenie to zwykle gniazdo Unix albo lokalny port TCP.

Typowy blok lokalizacji PHP wygląda tak:

location ~ \.php$ {
    try_files $uri =404;

    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;

    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Wersja PHP i ścieżka do gniazda różnią się w zależności od serwera. Jeśli po aktualizacji PHP Nginx zwraca błąd 502 Bad Gateway, ścieżka do gniazda jest jednym z pierwszych miejsc do sprawdzenia. PHP-FPM może być zatrzymane, działać w innej wersji albo nasłuchiwać gdzie indziej niż na ścieżce zdefiniowanej w Nginx.

Warto też pozostawić linię try_files $uri =404;. Powstrzymuje ona Nginx przed wysyłaniem żądań do nieistniejących plików PHP do procesora PHP. Poprawia to zarówno bezpieczeństwo, jak i obsługę błędów.

W przypadku WordPressa unikaj dodawania szerokich reguł skopiowanych z przypadkowych wpisów na forach, chyba że wiesz, dlaczego są potrzebne. WordPress już dobrze działa z czystą konfiguracją try_files, prawidłową obsługą PHP i uprawnieniami do zapisu tylko tam, gdzie WordPress ich potrzebuje. Więcej reguł nie oznacza automatycznie lepszej konfiguracji.

Uczyń HTTPS domyślną ścieżką​

Każda publiczna strona internetowa powinna obsługiwać HTTPS i przekierowywać ruch HTTP do wersji bezpiecznej. Typowy wzorzec to blok serwera HTTP, który wykonuje tylko przekierowanie, oraz osobny blok HTTPS, który obsługuje stronę.

server {
    listen 80;
    server_name example.com www.example.com;

    return 301 https://example.com$request_uri;
}

Blok serwera HTTPS nasłuchuje następnie na porcie 443 i zawiera ścieżki do certyfikatu oraz klucza prywatnego. Pliki certyfikatu zależą od sposobu udostępnienia SSL, ale zasada pozostaje ta sama: trzymaj konfigurację certyfikatu wewnątrz strony, która z niego korzysta.

Stałe przekierowanie 301 jest odpowiednie, gdy masz już pewność co do miejsca docelowego. Podczas aktywnej migracji albo krótkoterminowego testu przekierowanie 302 może być bezpieczniejsze, ponieważ przeglądarki nie zapisują go w pamięci podręcznej tak agresywnie. To jeden z tych przypadków, w których opcja wyglądająca technicznie na najmocniejszą nie zawsze jest właściwym wyborem operacyjnym.

Wybierz też jedną preferowaną nazwę hosta. Przekieruj albo www do domeny głównej, albo domenę główną do www. Obsługiwanie obu bez spójnego przekierowania może rozdzielić analitykę, utworzyć zduplikowane strony dla wyszukiwarek i utrudnić diagnozowanie działania plików cookie.

Obsługuj pliki statyczne wydajnie i bezpiecznie​

Obrazy, CSS, JavaScript, czcionki i pliki do pobrania nie powinny zużywać zasobów PHP, gdy Nginx może dostarczać je bezpośrednio. Ustaw rozsądne buforowanie w przeglądarce dla plików, które rzadko się zmieniają:

location ~* \.(css|js|jpg|jpeg|png|gif|svg|webp|ico|woff2)$ {
    expires 30d;
    add_header Cache-Control "public";
}

Trzydzieści dni to rozsądny punkt wyjścia, a nie prawo. Jeśli nazwy plików zawierają numery wersji lub hashowane nazwy plików, dłuższe buforowanie może działać bardzo dobrze. Jeśli ten sam plik o tej samej nazwie jest często podmieniany, długi cache może sprawić, że odwiedzający będą widzieć starszą wersję projektu lub skryptu. Buforowanie to zawsze kompromis między szybkością a tym, jak szybko zmiany muszą się pojawić.

Nie ujawniaj przypadkowo ukrytych plików. Prosta reguła może blokować żądania dotyczące plików ukrytych, jednocześnie dopuszczając katalog .well-known używany do weryfikacji certyfikatu:

location ~ /\.(?!well-known(?:/|$)) {
    deny all;
}

W zależności od konfiguracji certyfikatu możesz potrzebować konkretnego wyjątku dla .well-known. Przetestuj zachowanie odnowienia po zaostrzeniu reguł dostępu. Reguły bezpieczeństwa powinny ograniczać ekspozycję, a nie po cichu psuć usługi, na których polegasz.

Używaj nagłówków bezpieczeństwa z uwzględnieniem kontekstu​

Nagłówki odpowiedzi mogą poprawić ochronę po stronie przeglądarki, ale wymagają testowania. Typowe przykłady obejmują X-Content-Type-Options nosniff, Referrer-Policy i Content-Security-Policy. Ostatni z nich jest potężny i łatwo go błędnie skonfigurować. Ścisła polityka może blokować skrypty, czcionki, widżety płatności, analitykę lub osadzone treści, jeśli zostanie wprowadzona bez zrozumienia zależności strony.

Zacznij od nagłówków o jasnym celu i niskim ryzyku, a następnie dodaj politykę bezpieczeństwa treści w trybie tylko raportowania, jeśli Twoja aplikacja ją obsługuje. Celem nie jest zebranie imponującego stosu dyrektyw. Celem jest ograniczenie rzeczywistego ryzyka bez psucia stron, z których ludzie muszą korzystać.

Ograniczanie szybkości może również pomóc w przypadku nadużyć ruchu i ataków na logowanie, szczególnie dla punktów końcowych logowania WordPressa. Ale agresywne limity mogą blokować prawowitych użytkowników korzystających ze współdzielonych sieci biurowych lub operatorów komórkowych. Przeglądaj logi i dostosowuj ustawienia na podstawie rzeczywistych wzorców ruchu zamiast wybierać liczby, które tylko brzmią surowo.

Testuj zmiany tak, jakby miały znaczenie​

Każda zmiana w Nginx powinna przebiegać według tej samej krótkiej procedury: utwórz kopię zapasową lub skopiuj bieżący plik, wprowadź jedną konkretną zmianę, uruchom nginx -t, przeładuj Nginx i przetestuj stronę internetową z poziomu przeglądarki oraz wiersza poleceń. Sprawdź docelową domenę, domenę niekanoniczną, HTTP, HTTPS oraz stronę obsługiwaną przez PHP.

Gdy coś nie działa, przeczytaj logi błędów przed przepisaniem konfiguracji. Logi dostępu i błędów Nginx często pokazują, czy problemem jest brakujący plik, nieprawidłowe uprawnienie, nieudane połączenie z upstreamem czy błędne przekierowanie. Zgadywanie może stworzyć trzy nowe problemy, nie rozwiązując żadnego.

Panel sterowania może wyeliminować znaczną część tej ręcznej pracy, tworząc i porządkując ustawienia na poziomie strony, certyfikaty, wersje PHP i logi w jednym miejscu. FASTPANEL został zaprojektowany właśnie dla tego praktycznego środka: zachowujesz kontrolę nad swoim środowiskiem hostingowym, nie zamieniając każdej zmiany domeny w projekt archeologii konfiguracji.

Dobra konfiguracja Nginx nie polega na budowaniu najdłuższego pliku ani na używaniu każdej dostępnej dyrektywy. Chodzi o to, by każda strona była przewidywalna: właściwa domena trafia do właściwych plików, PHP ma zdrowy upstream, HTTPS jest wymuszony, treści statyczne są obsługiwane wydajnie, a zmiany są testowane, zanim zetkną się z nimi odwiedzający. Gdy ten fundament jest już na miejscu, zarządzanie rosnącym serwerem staje się znacznie mniej dramatyczne - dokładnie tak, jak powinno być.