NGINX Unit jako alternatywa dla PHP-FPM? Architektura, zagrożenia i przykłady zastosowań

Status „zarchiwizowane” i jasna, zwięzła ocena

Na dzień 30 września 2026 r. werdykt jest jednoznaczny: Moduł NGINX można było bezpośrednio uruchamiać aplikacje PHP, przyjmując przy tym połączenia HTTP, kończąc połączenia TLS, dostarczając pliki statyczne oraz przekierowując żądania. Dzięki temu zakres funkcji znacznie wykraczał poza możliwości PHP-FPM. Jednak w przypadku nowych, produkcyjnych platform hostingowych PHP nie zaleca się powszechnie stosowania Unit, ponieważ oficjalny projekt został zarchiwizowany w październiku 2025 roku i nie jest już rozwijany.

Nie oznacza to, że istniejąca instalacja Unit natychmiast przestaje działać. Może ona nadal obsługiwać aplikację, o ile udokumentowane są jej zależności, środki bezpieczeństwa oraz ścieżka migracji. Nowa inwestycja musi jednak zostać oceniona inaczej: bez ciągłej konserwacji projektu wzrasta ryzyko związane z lukami w zabezpieczeniach, dostępnością pakietów, nowymi wersjami systemów operacyjnych oraz przyszłą kompatybilnością z PHP.

W przypadku oznaczeń wersji ważne jest wyraźne rozróżnienie. W nadal dostępnej dokumentacji instalacyjnej często pojawia się wersja Unit 1.34.2, podczas gdy opublikowano stabilną wersję o numerze 1.35.0. Wersja ta zapewnia między innymi zgodność z PHP 8.5; nie oznacza to jednak dalszej obsługi technicznej. Gałąź rozwojowa master Ze względu na status „zarchiwizowane” nie jest to wersja produktu mająca decydujące znaczenie dla decyzji operacyjnych.

Różnice między NGINX, PHP-FPM i Unit

Aby podjąć trafną decyzję, należy rozpatrywać poszczególne elementy osobno. NGINX jest serwerem WWW i serwerem proxy odwrotnym: przyjmuje żądania HTTP, może dostarczać treści statyczne i przekierowuje żądania dynamiczne. Z kolei PHP-FPM jest menedżerem procesów FastCGI. Udostępnia on procesy robocze PHP, ale sam nie wykonuje typowych zadań serwera WWW, takich jak przyjmowanie żądań HTTP i ich przekierowywanie.

W klasycznej architekturze żądanie trafia najpierw do serwera NGINX. Jeśli dotyczy to pliku statycznego, NGINX może go natychmiast dostarczyć. W przypadku skryptu PHP serwer NGINX przekazuje niezbędne parametry FastCGI do puli PHP-FPM; wolny proces roboczy wykonuje kod i zwraca odpowiedź za pośrednictwem NGINX. Wielkość puli i tryb działania PHP-FPM są kontrolowane w plikach konfiguracyjnych w formacie php.ini.

Unit był natomiast Serwer aplikacji z wykorzystaniem modułów nasłuchujących, tras, statycznego dostarczania oraz czasów wykonania skryptów w modelu konfiguracyjnym JSON. Aplikacja PHP jest tam zintegrowana jako typ aplikacji; dzięki temu Unit może odwzorować ścieżkę żądania w ramach tej samej platformy, od momentu jego przyjęcia aż po wykonanie kodu PHP. Nie zmniejsza to automatycznie ryzyka operacyjnego, ale zmienia granice odpowiedzialności.

Unit nie jest zatem „NGINX-em z wbudowanym PHP-FPM“. Podczas kompilacji modułu PHP powstaje osobny moduł SAPI, który jest powiązany z biblioteką PHP-Embed. W związku z tym podczas analizy i migracji zespoły muszą nie tylko przenieść ustawienia FastCGI, ale także na nowo przypisać routing, definicje aplikacji, powiązania modułów i ścieżki diagnostyczne. Błędów nie można ogólnie przypisywać serwerowi WWW znajdującemu się na wyższym poziomie ani oddzielnej puli FPM.

Moduły PHP, wersje i ograniczenia konfiguracyjne

W przypadku PHP instalacja Unit wymaga, oprócz rdzenia, odpowiedniego modułu językowego. Moduł ten jest powiązany z używaną wersją PHP i instalacją Unit. W przypadku braku odpowiednich pakietów dla danego systemu operacyjnego i wersji PHP dokumentacja opisywała sposób samodzielnej kompilacji przy użyciu instalacji PHP udostępniającej Embed-SAPI. Znacznie zwiększa to nakład pracy związany z aktualizacjami, odtwarzalnością kompilacji oraz analizą błędów.

Również konfiguracja opiera się na różnych modelach. Unit grupuje słuchacze, trasy i aplikacje w postaci danych JSON za pośrednictwem swojego interfejsu konfiguracyjnego. Z kolei PHP-FPM zarządza pulami w plikach w formacie php.ini. Różnica ta wykracza poza samą składnię: w stosie FPM reguły serwera WWW i definicje pul PHP są oddzielone, podczas gdy Unit ściślej łączy oba elementy w ramach jednej platformy. Koncepcje migracji muszą uwzględniać tę strukturę.

W przypadku dyrektyw PHP program Unit rozróżnia następujące obszary: admin oraz użytkownik. Opcje administracyjne odpowiadają PHP_INI_SYSTEM i nie mogą być modyfikowane przez aplikację w czasie wykonywania; opcje użytkownika odpowiadają PHP_INI_USER. Moduł Unit nie rozszerza jednak w ten sposób dopuszczalnego zakresu dyrektywy PHP. To, czy dane ustawienie może zostać ustawione w ten sposób lub zmienione przez kod aplikacji, nadal zależy od trybu konfiguracji PHP.

Ostrzeżenie: Kompatybilność z PHP 8.5, wskazana w module Unit 1.35.0, potwierdza jedynie obsługę tej wersji w ostatnim stabilnym wydaniu. Nie stanowi to obietnicy przyszłych poprawek bezpieczeństwa ani dostosowań modułu Unit-PHP. W przypadku istniejących wdrożeń należy zatem udokumentować dokładną datę wydania modułu Unit, wersję PHP, pochodzenie modułu oraz przetestowaną ścieżkę migracji jako powiązane zależności.

Konfiguracja routingu PHP i kontrolera frontowego

Konfiguracja jednostki łączy moduł nasłuchujący z trasami i aplikacją. W przypadku lokalnej wersji demonstracyjnej moduł nasłuchujący może być skonfigurowany wyłącznie na 127.0.0.1:8080 wsłuchać się. Trasa najpierw próbuje znaleźć żądany plik w /srv/example-app/public dostarczać w trybie statycznym. Pliki PHP są wyłączone z tej dystrybucji na podstawie wykluczenia typu MIME i przekazywane do aplikacji PHP; to samo dotyczy plików, które nie istnieją. Dzięki temu pliki publiczne i wykonywanie aplikacji pozostają oddzielnymi etapami, które można prześledzić.

W aplikacji określa się root określa katalog dokumentów, podczas gdy type: php wybiera środowisko uruchomieniowe PHP. Za pomocą script: index.php każde zapytanie przekazane do aplikacji jest kierowane do tego skryptu. Odpowiada to Kontroler przedni wielu frameworków PHP: aplikacja sama analizuje pierwotną ścieżkę i decyduje np. o tym, który kontroler ma zostać uruchomiony lub czy wyświetlić stronę błędu.

Bez tego nastawienia script Obsługuje ścieżki skryptów oparte na identyfikatorach URI. Może to być odpowiednie rozwiązanie dla starszych aplikacji, w których pliki PHP mają być wywoływane bezpośrednio, wymaga jednak starannego ograniczenia dostępnych ścieżek. targets Ponadto umożliwiają one tworzenie podsekcji o odmiennym zachowaniu w zakresie katalogów root, script lub index. Nie stanowią one zatem zamiennika routingu, lecz możliwość precyzyjnego zdefiniowania kilku reguł aplikacji.

Poniższy przykład przedstawia plik konfiguracyjny JSON przeznaczony do lokalnej wersji demonstracyjnej, a nie do usługi publicznej. Nie zawiera on ani nazw domen, ani danych TLS, ani danych dostępowych. Przed wdrożeniem należy sprawdzić uprawnienia do plików, faktycznie zainstalowaną obsługę PHP oraz metodę wczytywania konfiguracji przewidzianą dla biblioteki Unit.

{
  "listeners": {
    "127.0.0.1:8080": {
      "pass": "routes/example"
    }
  },
  "routes": {
    "example": [
      {
        "action": {
          "share": "/srv/example-app/public$uri",
          "types": ["!application/x-httpd-php"],
          "fallback": {
            "pass": "applications/example-php"
          }
        }
      }
    ]
  },
  "applications": {
    "example-php": {
      "type": "php",
      "root": "/srv/example-app/public",
      "script": "index.php"
    }
  }
}

Kolejność ma kluczowe znaczenie: Ten dostawa statyczna Krok „share”, który ma to zapewnić, jest wykonywany przed przejściem na tryb awaryjny, ale wyraźnie wyklucza pliki PHP. Te żądania oraz nieistniejące pliki trafiają do index.php; dzięki temu działają również adresy URL z tekstem, takie jak /artikel/beispiel bez pliku o tej samej nazwie. To, czy konieczne są dodatkowe reguły dotyczące katalogów do przesyłania plików, obszarów administracyjnych lub plików PHP dostępnych bezpośrednio, zależy od konkretnej aplikacji i nie należy wyciągać z tego przykładu ogólnych wniosków.

Porównanie modeli procesów i budżetu RAM

PHP-FPM steruje procesami roboczymi w poszczególnych pulach za pomocą trybów static, dynamic oraz ondemand. Natomiast w przypadku jednostki liczba procesów jest modelowana wewnątrz aplikacji. Dynamiczna konfiguracja jednostki ogranicza się do processes.max całkowitą liczbę i utrzymuje się na poziomie processes.spare Procesy działające na biegu jałowym; idle_timeout usuwa zbędne, nieaktywne procesy.

Terminy te nie są zatem w pełni zamienne. W szczególności udokumentowane ustawienie domyślne nie jest odpowiednią wartością dla strony internetowej. Zarówno pm.max_children jak również processes.max Ograniczają one równoległe działanie procesów PHP i przy zbyt niskich wartościach mogą powodować powstawanie kolejek. Z kolei zbyt wysokie wartości powodują, że procesy PHP konkurują o pamięć operacyjną z systemem operacyjnym, bazą danych, pamięcią podręczną i innymi usługami.

A Budżet pamięci RAM jest to na razie jedynie model planistyczny: od całkowitej pojemności pamięci odejmuje się rezerwy przeznaczone dla systemu operacyjnego, bazy danych, pamięci podręcznej i innych procesów. Pozostałą wartość dzieli się przez konserwatywnie oszacowane zapotrzebowanie na pamięć na jednego pracownika PHP. Przykładowo, 1 200 MiB dla PHP podzielone przez 120 MiB na pracownika daje w obliczeniach dziesięciu pracowników; obie wartości są celowo wybranymi wartościami zastępczymi, a nie pomiarami ani zaleceniami konfiguracyjnymi.

Wynikiem tego jest Górny limit i punkt wyjścia do obserwacji, a nie właściwe ustawienie. Decydujące znaczenie mają rzeczywiste wartości szczytowe, kolejki, błędy odpowiedzi oraz zapotrzebowanie na pamięć przy typowym i wysokim obciążeniu. W celu metodycznego wyprowadzenia i dostosowania pm.max_children pomaga ten wewnętrzny wpis Prawidłowe obliczanie liczby procesów potomnych PHP-FPM. W przypadku Unit obowiązuje ta sama zasada, nawet jeśli parametry mają inne nazwy.

Ostrzeżenie: Ustalanie limitów procesów poprzez zwykłe przejmowanie danych z innych źródeł często prowadzi jedynie do przeniesienia problemów. Dopiero ustalenie konkretnego budżetu pamięci oraz regularne monitorowanie pozwalają stwierdzić, czy górny limit liczby procesów roboczych jest odpowiedni dla aplikacji, jej rozszerzeń oraz usług działających jednocześnie.

Ocena modeli działania w zakresie hostingu PHP

Tabela porządkuje architektury, a nie prędkość czy zużycie pamięci. Największym atutem konfiguracji NGINX-PHP-FPM w przypadku nowego hostingu PHP jest przede wszystkim wyraźny podział zadań: serwer WWW obsługuje protokół HTTP, funkcję proxy oraz treści statyczne, podczas gdy PHP-FPM zarządza procesami roboczymi PHP w poszczególnych pulach. Taki podział obowiązków ułatwia oddzielną ocenę konfiguracji, błędów i aktualizacji.

Unit umożliwił połączenie modułów nasłuchujących, routingu, plików statycznych i aplikacji w ramach jednej platformy oraz obsługę innych środowisk uruchomieniowych oprócz PHP. To wielojęzyczne podejście może wyjaśniać, dlaczego istniejące środowisko zdecydowało się na wybór Unit. W przypadku rozwiązań opartych wyłącznie na PHP nie stanowi to jednak automatycznej zalety: nie zastępuje to ani oceny wymaganych funkcji, ani sprawdzenia, czy zespół będzie w stanie na stałe opanować inną logikę konfiguracji i działania.

W przypadku Unit 1.35.0 zakres funkcji technicznych musi być określony przez Stan konserwacji należy je rozdzielić. Data wydania odnosi się do opublikowanej wersji i wprowadzonych w niej zmian; nie pociąga to za sobą dalszej obsługi projektu, który w międzyczasie został zarchiwizowany. W przypadku podejmowania nowej decyzji ograniczenie to ma większe znaczenie niż mniejsza liczba widocznych komponentów. Natomiast w przypadku istniejącej instalacji stanowi to powód do udokumentowania zależności i ścieżki migracji.

Apache z PHP-FPM nie jest ogólnie lepszą ani gorszą alternatywą, lecz jedną z opcji w przypadku istniejących wymagań dotyczących Apache’a. Wybór powinien opierać się na łatwości konserwacji, dostępnych wersjach PHP, procesach instalowania poprawek, wiedzy zespołu oraz planie awaryjnym. Bez porównywalnych profili obciążenia i udokumentowanej metodologii pomiarowej nie można na podstawie tego przeglądu architektury ustalić wiarygodnego rankingu wydajności.

Bezpieczna eksploatacja urządzenia w parku maszynowym

Istniejącą instalację Unit należy najpierw zarejestrować jako system istniejący, a nie jako szablon dla nowej platformy. Decydujące znaczenie mają faktycznie stosowana wersja, podłączone aplikacje oraz ich zależności. Fakt, że Unit nadal działa pod względem technicznym, nie zmienia faktu, że projekt został zarchiwizowany; dlatego też eksploatację i zastąpienie systemu należy planować łącznie.

W przypadku WordPressa, Joomli lub Drupala jest to Kontroler przedni Najważniejsze: ścieżki, które nie odpowiadają istniejącym plikom, muszą być przekierowywane do głównego pliku startowego PHP, podczas gdy istniejące pliki mogą być dostarczane bezpośrednio. Instrukcja WordPressa dotycząca Unit ilustruje tę zasadę routingu, w tym sposób obsługi plików PHP oraz /wp-admin/. W przypadku istniejącego systemu CMS może to być zrozumiała konfiguracja; w przypadku nowej instalacji nie wynika z tego żadna rekomendacja dotycząca Unit.

Kilka niewielkich aplikacji napisanych w PHP, Pythonie, Ruby lub Node.js udało się zgrupować na wspólnej platformie za pomocą modułów Unit Listener, tras i środowisk uruchomieniowych. To może wyjaśniać, dlaczego w tamtym czasie w istniejącej architekturze zdecydowano się na Unit. W przypadku hostingu opartego wyłącznie na PHP ta wielojęzyczność nie jest jednak celem samym w sobie: oddzielne, odpowiednio utrzymywane komponenty mogą w dłuższej perspektywie być łatwiejsze w utrzymaniu, pomimo dodatkowych interfejsów.

Zamrożone wdrożenie kontenerowe wymaga szczególnie dokładnej inwentaryzacji. W tym celu należy udokumentować dokładny tag jednostki, wersję PHP, zainstalowany moduł językowy, obraz bazowy oraz pełną konfigurację. Dodaj również źródła obrazów i pakietów, proces wdrażania poprawek, a także sprawdzoną ścieżkę migracji i ścieżkę awaryjną. Kompatybilność danej wersji jednostki z PHP nie stanowi gwarancji, że powiązany z nią moduł będzie w przyszłości otrzymywał poprawki bezpieczeństwa.

NGINX może znajdować się przed Unit, na przykład gdy należy zachować istniejącą warstwę NGINX lub gdy dostępy mają być celowo przekierowywane na wyższy poziom. Dokumentacja Unit wspomina o tej integracji również w kontekście zabezpieczenia gniazda sterującego (Control Socket). Nie rozwiązuje ona jednak problemu statusu archiwalnego i tworzy kolejną usługę z własną konfiguracją, logowaniem oraz odpowiedzialnością za aktualizacje. Należy zatem konkretnie rozważyć korzyści w stosunku do tego nakładu operacyjnego.

Przekroczenia limitów czasu, logi i zawieszone procesy

Granice procesu nie stanowią diagnozy błędu. Za pomocą limits.requests Unit może zastąpić proces aplikacji po przetworzeniu określonej liczby żądań. Pozwala to ograniczyć skumulowane zużycie pamięci w czasie, ale nie eliminuje ani wycieków pamięci, ani zbyt dużych struktur danych, ani blokujących wywołań zewnętrznych. Dlatego regularne ponowne uruchamianie nie może być traktowane jako dowód stabilności kodu aplikacji.

Z limits.timeout Po upływie skonfigurowanego czasu Unit kończy obsługę żądania, zwracając kod HTTP 503. Jest to widoczny limit ochronny dla poszczególnych żądań, ale nie stanowi pełnej ochrony przed zawieszonymi procesami roboczymi: zgodnie z dokumentacją Unit nie wykrywa zawieszonych procesów; mogą one pozostać w puli procesów. Dłuższy limit czasu jedynie odkłada ten problem na później, natomiast krótszy może przerywać normalnie przebiegające operacje.

• Przed zmianą wartości progowych należy zarejestrować statusy HTTP, ścieżki, na które to ma wpływ, przedziały czasowe oraz częstotliwość.
• Połącz logi dostępu, błędów i aplikacji na podstawie znaczników czasu; w przypadku PHP-FPM log spowolnień może dostarczyć dodatkowych informacji o stosie.
• Sprawdź procesor, pamięć operacyjną, wejścia/wyjścia, połączenia sieciowe oraz stan i liczbę procesów.
• Następnie należy sprawdzić kod, zapytania do bazy danych, operacje na systemie plików oraz usługi zewnętrzne jako potencjalne przyczyny.
• Dopiero po ustaleniu przyczyny i profilu obciążenia należy odpowiednio dostosować limity czasu, ograniczenia procesów lub reguły ponownego uruchamiania.

Kod HTTP 503 może zatem wskazywać na przekroczenie limitu czasu, ale może też wynikać z działania komponentów wyższego szczebla lub innych błędów. Powtarzających się długotrwałych żądań PHP nie należy rozwiązywać wyłącznie poprzez zmianę liczby procesów roboczych. Instrukcja dotycząca Plik Slowlog PHP-FPM oraz analiza przyczyn spowolnienia żądań pokazuje, w jaki sposób ślady stosu można powiązać z danymi żądania; ta sama logika przyczynowo-skutkowa ma również sens w przypadku analizy stanu jednostki.

Szczególnie niepokojące są objawy bez jednoznacznego wyjaśnienia: wydłużające się czasy oczekiwania, stale zajęte procesy lub brak postępów w logach. W takich przypadkach stan procesu i zależności są ważniejsze niż ogólne wydłużenie limitu czasu. Sprawdź na przykład, czy pracownik PHP oczekuje na operacje wejścia/wyjścia związane z bazą danych, DNS, systemem plików lub siecią. Dopiero konkretna blokada decyduje o tym, czy właściwe jest wprowadzenie poprawki w kodzie, dostosowanie zasobów czy kontrolowane ponowne uruchomienie.

Wybór między nowymi a starymi systemami

W przypadku nowych środowisk hostingowych PHP bardziej uzasadnionym standardowym wyborem jest dobrze utrzymany serwer WWW z PHP-FPM. PHP-FPM stanowi część standardowej dystrybucji PHP i oferuje udokumentowane opcje zarządzania pulami i procesami. W przypadku Unit kwestia ta przesuwa się jednak z samej funkcjonalności na łatwość konserwacji: instalacja może nadal działać, ale zarchiwizowany stan projektu zwiększa ryzyko długotrwałej zależności.

W przypadku istniejących systemów typu „unit” merytoryczna decyzja zaczyna się od sporządzenia spisu zasobów. Należy sprawdzić stan konserwacji oraz możliwość instalowania poprawek w systemie operacyjnym, PHP i obrazie bazowym, kompatybilność zainstalowanego modułu językowego, dostępną wiedzę operacyjną oraz powiązane usługi. Równie ważne są konfiguracje z możliwością eksportu, odtwarzalny proces przywracania stanu poprzedniego oraz system docelowy, na który można stopniowo przenieść routing, ustawienia PHP i wdrożenia.

Migracja nie wymaga ustalenia ogólnego terminu, ale ustalenia kolejności priorytetów. W pierwszej kolejności należy zwrócić uwagę na aplikacje dostępne w Internecie, obrazy, których nie da się zaktualizować, moduły o niejasnym pochodzeniu oraz aplikacje o kluczowym znaczeniu dla działalności, które nie mają planu awaryjnego. Następnie aplikacje można pogrupować według stopnia złożoności i zależności. Równoległa eksploatacja podczas kontrolowanego przejścia może zmniejszyć ryzyko, o ile wcześniej zdefiniowano sposób przechowywania danych, sesje oraz ścieżkę powrotną.

Die Interfejs API sterowania jest to dostęp administracyjny, a nie zwykły punkt końcowy strony internetowej. Unit dokumentuje dla Ciebie gniazdo domenowe systemu Unix i uzasadnia jego zastosowanie względami bezpieczeństwa. Ustal restrykcyjne uprawnienia do plików oraz jasno określony zakres dostępu administracyjnego; publiczna dostępność otworzyłaby atakującym, w przypadku udanego włamania, szerokie możliwości zmiany konfiguracji.

Praktyczny proces migracji nie kończy się na nowej konfiguracji procesów. Przenoś wersję PHP, rozszerzenia, wartości środowiskowe, uprawnienia do plików, reguły routingu i monitorowalność do systemu docelowego, aplikacja po aplikacji. Porównuj przy tym oczekiwane odpowiedzi i przypadki błędów, zamiast wyciągać ogólne wnioski dotyczące szybkości działania. W ten sposób nieplanowane obciążenie z przeszłości zamienia się w udokumentowaną Strategia wykupu oparte na uzasadnionych decyzjach technicznych.