NGINX Unit som alternativ till PHP-FPM? Arkitektur, risker och användningsfall

Arkiverad status och tydlig kortfattad bedömning

Per den 30 september 2026 är slutsatsen tydlig: NGINX-enhet kunde köra PHP-applikationer direkt och samtidigt ta emot HTTP-anslutningar, avsluta TLS-anslutningar, leverera statiska filer samt vidarebefordra förfrågningar. Därmed sträckte sig funktionsomfånget betydligt längre än PHP-FPM. För nya produktiva PHP-hostingplattformar är Unit dock inte en allmän rekommendation, eftersom det officiella projektet har arkiverats sedan oktober 2025 och inte längre underhålls.

Det betyder inte att en befintlig Unit-installation omedelbart skulle sluta fungera. Den kan fortsätta att driva en applikation, förutsatt att dess beroenden, säkerhetsåtgärder och en migreringsväg är dokumenterade. En nyinvestering måste dock bedömas på ett annat sätt: utan kontinuerlig projektunderhållning ökar riskerna när det gäller säkerhetsbrister, paketens tillgänglighet, nya operativsystemversioner och framtida PHP-kompatibilitet.

När det gäller versionsangivelser är det viktigt med en tydlig åtskillnad. I den installationsdokumentation som fortfarande finns tillgänglig nämns ofta Unit 1.34.2, medan den stabila versionen 1.35.0 har släppts. Denna version är bland annat kompatibel med PHP 8.5, men detta innebär inte att underhållet fortsätter. Utvecklingsgrenen master är, på grund av sin arkiverade status, inte en relevant produktversion för operativa beslut.

Skillnaden mellan NGINX, PHP-FPM och Unit

För att kunna fatta ett välgrundat beslut måste man betrakta de olika delarna var för sig. NGINX är en webbserver och en omvänd proxy: Den tar emot HTTP-förfrågningar, kan leverera statiskt innehåll och vidarebefordra dynamiska förfrågningar. PHP-FPM är däremot en FastCGI Process Manager. Den tillhandahåller PHP-arbetare, men hanterar inte själv den typiska webbserveruppgiften att ta emot HTTP-förfrågningar och vidarebefordra dem.

I den klassiska arkitekturen når en förfrågan först NGINX. Om det rör sig om en statisk fil kan NGINX leverera den direkt. För ett PHP-skript vidarebefordrar NGINX de nödvändiga FastCGI-parametrarna till en PHP-FPM-pool; en ledig worker kör koden och skickar tillbaka svaret via NGINX. Poolstorlek och processläge styrs i PHP-FPM via konfigurationsfiler i php.ini-format.

Unit var däremot en Applikationsserver med lyssnare, rutter, statisk leverans och språkkörningstider i en JSON-konfigurationsmodell. En PHP-applikation integreras där som applikationstyp; Unit kan därmed kartlägga begäranens väg inom samma plattform, från mottagandet till PHP-körningen. Detta minskar inte automatiskt driftsrisken, men förändrar ansvarsgränserna.

Unit är därför inte „NGINX med inbäddad PHP-FPM“. När PHP-modulen byggs skapas en egen SAPI-modul som är kopplad till PHP-Embed-biblioteket. Vid analys och migrering måste teamen därför inte bara överföra FastCGI-inställningar, utan även omkonfigurera routning, applikationsdefinitioner, modulbindningar och diagnostiska vägar. Fel kan inte generellt tillskrivas en uppströms webbserver eller en separat FPM-pool.

PHP-moduler, versioner och konfigurationsbegränsningar

För PHP kräver en Unit-installation, förutom kärnan, ett passande språkmodul. Detta modul är knutet till den använda PHP-versionen och Unit-installationen. Om det inte fanns några lämpliga paket för operativsystemet och PHP-versionen beskrev dokumentationen hur man kunde bygga den själv med en PHP-installation som tillhandahåller Embed-SAPI. Detta ökar arbetsinsatsen för uppdateringar, reproducerbara kompileringar och felanalys avsevärt.

Även konfigurationen följer olika modeller. Unit sammanför lyssnare, rutter och applikationer som JSON-data via sitt konfigurationsgränssnitt. PHP-FPM hanterar däremot pooler i filer i php.ini-format. Denna skillnad är mer än bara syntax: I en FPM-stack är webbserverregler och PHP-pooldefinitioner åtskilda, medan Unit kopplar samman båda dessa mer tätt inom en och samma plattform. Migrationskoncept måste ta hänsyn till denna struktur.

När det gäller PHP-direktiv skiljer Unit mellan följande områden admin och användare. Admin-alternativen motsvarar PHP_INI_SYSTEM och kan inte ändras av applikationen under körning; användaralternativen motsvarar PHP_INI_USER. Unit utvidgar dock inte det tillåtna intervallet för en PHP-direktiv. Om en inställning får anges på detta sätt eller ändras via applikationskod bestäms fortfarande av dess PHP-konfigurationsläge.

Varning: Den PHP 8.5-kompatibilitet som anges i Unit 1.35.0 bekräftar endast att denna version stöds i den senaste stabila utgåvan. Det är inte ett löfte om framtida säkerhetskorrigeringar eller anpassningar av Unit-PHP-modulen. För drift av befintliga system bör därför den exakta Unit-taggen, PHP-versionen, modulens ursprung och en testad uppgraderingsväg dokumenteras som sammanhängande beroenden.

Konfigurera PHP-routing och Front Controller

En enhetskonfiguration kopplar samman en lyssnare med rutter och en applikation. För en lokal demonstration kan lyssnaren endast vara inställd på 127.0.0.1:8080 lyssna. En rutt försöker först hitta den begärda filen under /srv/example-app/public levereras statiskt. PHP-filer undantas från denna leverans genom MIME-typ-undantaget och vidarebefordras till PHP-applikationen; detsamma gäller för filer som inte finns. På så sätt förblir offentliga filer och applikationens körning separata steg som går att spåra.

I applikationen anges root fastställer dokumentkatalogen, medan type: php väljer PHP-körmiljön. Med script: index.php varje förfrågan som vidarebefordras till applikationen dirigeras till detta skript. Detta motsvarar Frontkontroll i många PHP-ramverk: Applikationen tolkar själv den ursprungliga sökvägen och avgör till exempel vilken controller som ska användas eller vilken felsida som ska visas.

Utan den inställningen script behandlar Unit URI-baserade skriptvägar. Detta kan vara lämpligt för äldre applikationer där PHP-filerna ska anropas direkt, men kräver en noggrann begränsning av de tillgängliga sökvägarna. targets De tillåter dessutom delområden med avvikande beteende vad gäller root, script eller index. De är därför inte en ersättning för routing, utan ett sätt att på ett målinriktat sätt definiera flera applikationsregler.

Följande exempel är en JSON-filkonfiguration för en lokal demo, inte för en offentlig tjänst. Den innehåller varken domännamn, TLS-uppgifter eller inloggningsuppgifter. Innan konfigurationen implementeras måste filbehörigheter, det faktiskt installerade PHP-stödet och den metod som Unit använder för att importera konfigurationen kontrolleras.

{
  "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"
    }
  }
}

Ordningen är avgörande: Den statisk leverans Det tillhörande share-steget försöks innan fallback, men utesluter uttryckligen PHP-filer. Dessa förfrågningar och icke-existerande filer hamnar hos index.php; därmed fungerar även talande URL:er som /artikel/beispiel utan en fil med samma namn. Huruvida ytterligare regler för uppladdningskataloger, administrationsområden eller direkt tillgängliga PHP-filer krävs beror på den aktuella applikationen och bör inte generaliseras utifrån denna demo.

Jämföra processmodeller och RAM-budget

PHP-FPM styr antalet arbetare per pool via lägena static, dynamic och ondemand. I Unit modelleras däremot processnumret inom själva applikationen. En dynamisk Unit-konfiguration begränsar med processes.max det totala antalet och håller jämna steg med processes.spare Tomgångsprocesser; idle_timeout avslutar överflödiga inaktiva processer.

Begreppen är därför inte helt utbytbara. Framför allt är en dokumenterad standardinställning inte ett lämpligt värde för en webbplats. Både pm.max_children såväl som processes.max begränsar parallell PHP-bearbetning och kan orsaka köer om värdena är för låga. För höga värden konkurrerar däremot med operativsystemet, databasen, cachen och andra tjänster om arbetsminnet.

En RAM-budget är till en början endast en planeringsmodell: Från det totala minnet dras reserver för operativsystem, databas, cache och övriga processer av. Det återstående värdet divideras med ett konservativt beräknat minnesbehov per PHP-arbetare. Som exempel ger 1 200 MiB för PHP dividerat med 120 MiB per arbetare matematiskt sett tio arbetare; båda värdena är medvetet valda platshållare, inte någon mätning eller konfigurationsrekommendation.

Resultatet blir en Övre gräns och en utgångspunkt för observation, inte den rätta inställningen. Det avgörande är faktiska toppvärden, köer, svarfel och minnesbehovet vid både normal och hög belastning. För metodisk härledning och justering av pm.max_children det interna inlägget hjälper Beräkna rätt antal PHP-FPM-processer. I Unit gäller samma princip, även om parametrarna har andra namn.

Varning: Att fastställa processgränser genom att bara överta andras siffror leder ofta bara till att problemen skjuts upp. Det är först genom en avgränsad minnesbudget och kontinuerlig övervakning som man kan se om en övre gräns för antalet arbetare passar applikationen, dess tillägg och de tjänster som körs samtidigt.

Jämföra driftsmodeller för PHP-hosting

Tabellen rangordnar arkitekturer, inte hastighet eller minnesanvändning. Det som framför allt talar för ny PHP-hosting med NGINX-PHP-FPM-konfigurationen är den tydliga uppdelningen: webbservern hanterar HTTP, proxyserverfunktioner och statiskt innehåll, medan PHP-FPM hanterar PHP-arbetarna per pool. Denna ansvarsfördelning gör det enklare att utvärdera konfigurationer, felbilder och uppdateringar separat.

Unit kunde samla lyssnare, routning, statiska filer och applikationer på en och samma plattform och stödja ytterligare körmiljöer utöver PHP. Denna flerspråkiga strategi kan förklara varför en befintlig miljö valde Unit. För tjänster som uteslutande bygger på PHP är det dock inte nödvändigtvis en fördel: det ersätter varken en utvärdering av de nödvändiga funktionerna eller en prövning av om teamet på sikt kan behärska den annorlunda konfigurations- och driftslogiken.

För Unit 1.35.0 måste den tekniska funktionsomfattningen från Underhållsstatus skiljas åt. Releasedatumet anger den publicerade versionen och dess ändringar; detta innebär att det projekt som nu har arkiverats inte kommer att underhållas ytterligare. Vid ett nytt beslut väger denna gräns tyngre än ett mindre antal synliga komponenter. För en befintlig installation är den däremot en anledning att dokumentera beroenden och en migreringsväg.

Apache med PHP-FPM är inte generellt sett ett bättre eller sämre alternativ, utan ett val när det finns befintliga krav på Apache. Valet bör baseras på underhållsbarhet, tillgängliga PHP-versioner, patchprocesser, teamets kunskaper och beredskapsplanen. Utan jämförbara belastningsprofiler och dokumenterade mätmetoder går det inte att utläsa någon tillförlitlig prestandarankning utifrån denna arkitekturöversikt.

Säker drift av enheten i beståndet

En befintlig Unit-installation bör inledningsvis registreras som ett befintligt system, inte som en mall för en ny plattform. Avgörande faktorer är den version som faktiskt används, de anslutna applikationerna och deras beroenden. Att Unit fortfarande är tekniskt körbart förändrar inte det faktum att projektet har arkiverats; drift och avveckling måste därför planeras gemensamt.

I WordPress, Joomla eller Drupal är Frontkontroll Det viktigaste är: Sökvägar som inte motsvarar någon befintlig fil måste ledas till den centrala PHP-startfilen, medan befintliga filer kan levereras direkt. WordPress-guiden för Unit visar denna princip för vidarebefordran, inklusive hanteringen av PHP-filer och /wp-admin/. För ett befintligt CMS kan detta vara en rimlig konfiguration; för en nyinstallation innebär detta dock ingen rekommendation för Unit.

Flera små applikationer skrivna i PHP, Python, Ruby eller Node.js kunde samlas på en gemensam plattform med hjälp av Unit Listener, rutter och körmiljöer. Det kan förklara varför man vid den tiden valde Unit som arkitektur. Vid ren PHP-hosting är denna flerspråkighet dock inte ett mål i sig: Separata, väl underhållna komponenter kan på lång sikt vara lättare att underhålla trots ytterligare gränssnitt.

En fryst container-distribution kräver en särskilt noggrann inventering. Dokumentera därför den exakta enhets-taggen, PHP-versionen, det installerade språkmodulet, basbilden och den fullständiga konfigurationen. Lägg dessutom till källor för bilder och paket, patchningsprocessen samt en testad migrerings- och återgångsväg. PHP-kompatibiliteten för en viss enhetsutgåva innebär inte någon garanti för att den tillhörande modulen kommer att få säkerhetsuppdateringar i framtiden.

NGINX kan placeras före Unit, till exempel om ett befintligt NGINX-lager ska behållas eller om åtkomst ska dirigeras specifikt uppströms. Unit-dokumentationen nämner även denna integration i samband med säkringen av kontrollsocketen. Den åtgärdar dock inte det arkiverade tillståndet och skapar ytterligare en tjänst med egen konfiguration, loggning och ansvar för uppdateringar. Fördelarna måste därför noga vägas mot denna driftskostnad.

Timeouts, loggar och hängande processer

Processgränser är inte någon feldiagnos. Med limits.requests Unit kan ersätta en applikationsprocess efter ett fastställt antal bearbetade förfrågningar. Detta kan begränsa den ackumulerade minnesanvändningen över tid, men eliminerar varken minnesläckor, överdimensionerade datastrukturer eller blockerande externa anrop. En regelbunden omstart får därför inte betraktas som ett bevis på att applikationskoden är stabil.

Med limits.timeout Unit avslutar en förfrågan med HTTP 503 när den konfigurerade tiden har löpt ut. Detta är en synlig säkerhetsgräns för enskilda förfrågningar, men inget fullständigt skydd mot fastkörda arbetare: Enligt dokumentationen upptäcker Unit inte fastkörda processer; de kan kvarstå i processpoolen. En längre timeout skjuter bara upp detta problem, medan en kortare timeout kan avbryta normalt långsamma processer.

• Registrera HTTP-status, berörda sökvägar, tidsintervall och frekvens innan gränsvärdena ändras.
• Sammanställ åtkomst-, fel- och applikationsloggar utifrån tidsstämplar; vid användning av PHP-FPM kan en slowlog ge ytterligare information om stacken.
• Kontrollera CPU, arbetsminne, I/O, nätverksanslutningar samt processernas status och antal.
• Undersök därefter koden, databasfrågor, filsystemåtkomst och externa tjänster som möjliga orsaker.
• Först när orsaken och belastningsprofilen är kända bör man på ett målinriktat sätt anpassa timeouts, processgränser eller omstartsregler.

Ett HTTP 503-fel kan alltså bero på att tidsgränsen har löpt ut, men kan också orsakas av komponent i tidigare led eller andra fel. Återkommande långa PHP-förfrågningar bör du inte hantera enbart genom att justera antalet arbetare. Anvisningarna för att PHP-FPM-Slowlog och analys av orsakerna till långsamma förfrågningar visar hur stackspår kan kopplas till begäranddata; samma orsak-verkan-logik är också användbar vid en analys av enhetsbeståndet.

Särskilt kritiska är symptom utan tydligt slut: ökande väntetider, processer som är permanent upptagna eller uteblivna loggförlopp. I sådana fall är processstatus och beroenden viktigare än en generell förlängning av timeout-tiden. Kontrollera till exempel om en PHP-worker väntar på databas-, DNS-, filsystem- eller nätverks-I/O. Det är först den konkreta blockeringen som avgör om en kodkorrigering, en resursjustering eller en kontrollerad omstart är lämplig.

Val mellan nya och gamla system

För nya PHP-hostingmiljöer är en välskött webbserver med PHP-FPM det mer logiska standardvalet. PHP-FPM ingår i den vanliga PHP-distributionen och erbjuder dokumenterade alternativ för pool- och processhantering. När det gäller Unit förskjuts dock frågan från ren funktionalitet till underhållsbarhet: installationen kan fortsätta att fungera, men den arkiverade projektstatusen ökar risken för ett långsiktigt beroende.

För befintliga Unit-system börjar ett sakligt beslut med en inventering. Kontrollera underhållsstatus och uppdateringsbarhet för operativsystem, PHP och basbilden, kompatibiliteten hos den installerade språkmodulen, befintlig driftskunskap samt kopplade tjänster. Lika viktigt är exporterbara konfigurationer, en reproducerbar återställning och ett målsystem till vilket routning, PHP-inställningar och distributioner kan överföras steg för steg.

En migrering kräver ingen påhittad, allmängiltig tidsfrist, utan en prioriterad ordning. Applikationer som är exponerade mot internet, bilder som inte kan uppdateras, oklar modulursprung och affärskritiska applikationer utan reservplan bör prioriteras. Därefter kan applikationerna grupperas efter komplexitet och beroenden. Parallell drift under en kontrollerad övergång kan minska riskerna, förutsatt att datalagring, sessioner och återgångsvägar har definierats i förväg.

Die Kontroll-API är en administrativ åtkomstpunkt och inte en vanlig slutpunkt på en webbplats. Unit dokumenterar en Unix-domänsockel för dig och motiverar dess användning med säkerhetsaspekter. Ställ in restriktiva filbehörigheter och tydligt avgränsade administrativa åtkomsträttigheter; om den vore offentligt tillgänglig skulle det, vid en lyckad attack, ge angripare omfattande möjligheter att ändra konfigurationen.

Den praktiska migreringsprocessen slutar inte med en ny processkonfiguration. Överför PHP-versionen, tillägg, miljövariabler, filbehörigheter, routningsregler och övervakningsmöjligheter till målsystemet, applikation för applikation. Jämför då förväntade svar och felmeddelanden istället för att dra generella slutsatser om hastigheten. På så sätt förvandlas ett oplanerat arv till en dokumenterad Övergångsstrategi med välgrundade tekniska beslut.