NGINX Unit som alternativ til PHP-FPM? Arkitektur, risici og anvendelsestilfælde

Arkiveret status og en klar kortfattet vurdering

Pr. 30. september 2026 lyder den klare konklusion: NGINX-enhed kunne køre PHP-applikationer direkte og samtidig modtage HTTP-forbindelser, afslutte TLS, levere statiske filer samt videresende forespørgsler. Dermed gik funktionaliteten betydeligt ud over PHP-FPM. Unit kan dog ikke generelt anbefales til nye produktive PHP-hostingplatforme, da det officielle projekt er blevet arkiveret siden oktober 2025 og ikke længere vedligeholdes.

Det betyder ikke, at en eksisterende Unit-installation straks ville blive ubrugelig. Den kan fortsat betjene en applikation, forudsat at dens afhængigheder, sikkerhedsforanstaltninger og en migrationsplan er dokumenteret. En ny investering skal dog vurderes anderledes: Uden løbende projektvedligeholdelse stiger risikoen for sikkerhedshuller, pakketilgængelighed, nye operativsystemversioner og fremtidig PHP-kompatibilitet.

Når det gælder versionsangivelser, er det vigtigt med en klar adskillelse. Den installationsvejledning, der stadig er tilgængelig, henviser i mange tilfælde til Unit 1.34.2, mens den stabile udgivelse blev udgivet som version 1.35.0. Udgivelsen bekræfter blandt andet kompatibilitet med PHP 8.5; dette medfører dog ikke fortsat vedligeholdelse. Udviklingsgrenen master er på grund af sin arkiverede status ikke en relevant produktversion til driftsbeslutninger.

Forskellen mellem NGINX, PHP-FPM og Unit

For at kunne træffe en velovervejet beslutning skal de enkelte komponenter betragtes hver for sig. NGINX er en webserver og en reverse proxy: Den modtager HTTP-anmodninger, kan levere statisk indhold og videresender dynamiske anmodninger. PHP-FPM er derimod en FastCGI Process Manager. Den stiller PHP-workere til rådighed, men varetager ikke selv den typiske webserveropgave med at modtage HTTP-anmodninger og foretage routing.

I den klassiske opbygning modtager NGINX først en forespørgsel. Hvis der er tale om en statisk fil, kan NGINX levere den med det samme. Ved et PHP-script videregiver NGINX de nødvendige FastCGI-parametre til en PHP-FPM-pool; hvor en ledig worker udfører koden og returnerer svaret via NGINX. Poolstørrelse og procesmodus styres i PHP-FPM via konfigurationsfiler i php.ini-format.

Unit var derimod en Applikationsserver med lyttere, ruter, statisk levering og sprogløbetider i en JSON-konfigurationsmodel. En PHP-applikation integreres der som applikationstype; Unit kan dermed kortlægge anmodningsforløbet inden for samme platform, fra modtagelse til PHP-udførelse. Dette reducerer ikke automatisk driftsrisikoen, men ændrer ansvarsgrænserne.

Unit er derfor ikke „NGINX med indbygget PHP-FPM“. Når PHP-modulet kompileres, oprettes der et eget SAPI-modul, der er knyttet til PHP-Embed-biblioteket. Ved analyse og migrering skal teams derfor ikke blot overføre FastCGI-indstillinger, men også omkonfigurere routing, applikationsdefinitioner, modulbinding og fejlfindingsveje. Fejl kan ikke generelt tilskrives en opstrøms webserver eller en separat FPM-pool.

PHP-moduler, versioner og konfigurationsbegrænsninger

Til PHP kræver en Unit-installation ud over kernen et passende sprogmodul. Dette modul er bundet til den anvendte PHP-version og Unit-installationen. Hvis der ikke var egnede pakker til rådighed til operativsystemet og PHP-versionen, beskrev dokumentationen, hvordan man selv kunne kompilere med en PHP-installation, der stiller Embed-SAPI til rådighed. Dette øger arbejdsbyrden i forbindelse med opdateringer, reproducerbare builds og fejlanalyse betydeligt.

Også konfigurationen følger forskellige modeller. Unit samler lyttere, ruter og applikationer som JSON-data via sin konfigurationsgrænseflade. PHP-FPM administrerer derimod puljer i filer i php.ini-format. Denne forskel er mere end blot syntaks: I en FPM-stack er webserverregler og PHP-pooldefinitioner adskilt, mens Unit forbinder begge dele tættere i én platform. Migrationskoncepter skal tage højde for denne struktur.

For PHP-direktiver skelner Unit mellem følgende områder admin og bruger. Admin-indstillinger svarer til PHP_INI_SYSTEM og kan ikke ændres af applikationen under kørsel; brugerindstillinger svarer til PHP_INI_USER. Unit udvider dog ikke det tilladte område for en PHP-direktiv. Om en indstilling må angives på denne måde eller ændres via applikationskode, bestemmes fortsat af dens PHP-konfigurationsmodus.

Advarsel: Den PHP 8.5-kompatibilitet, der er angivet i Unit 1.35.0, bekræfter kun, at denne version understøttes i den seneste stabile udgivelse. Det er ikke et løfte om fremtidige sikkerhedsrettelser eller tilpasninger af Unit-PHP-modulet. Til drift af eksisterende systemer bør derfor den nøjagtige Unit-tag, PHP-version, modulets oprindelse og en testet overgangsplan dokumenteres som sammenhængende afhængigheder.

Konfiguration af PHP-routing og frontcontroller

En enhedskonfiguration forbinder en lytter med ruter og en applikation. Til en lokal demo kan lytteren udelukkende være på 127.0.0.1:8080 lytte. En rute forsøger først at finde den anmodede fil under /srv/example-app/public leveres statisk. PHP-filer undtages fra denne levering via MIME-type-undtagelsen og videresendes til PHP-applikationen; det samme gælder for filer, der ikke findes. På den måde forbliver offentlige filer og applikationsudførelsen overskuelige som separate trin.

I applikationen angives root fastlægger dokumentmappen, mens type: php der vælger PHP-kørselstiden. Med script: index.php Hver forespørgsel, der videresendes til applikationen, dirigeres til dette script. Dette svarer til Frontcontroller i mange PHP-frameworks: Applikationen fortolker selv den oprindelige sti og bestemmer f.eks., hvilken controller eller fejlsiden der skal vises.

Uden denne indstilling script behandler Unit URI-baserede scriptstier. Dette kan være passende for ældre applikationer, hvor PHP-filerne skal kaldes direkte, men kræver en omhyggelig afgrænsning af de tilgængelige stier. targets De tillader desuden delområder med afvigende root-, script- eller index-adfærd. De er derfor ikke en erstatning for routing, men en mulighed for målrettet at definere flere anvendelsesregler.

Følgende eksempel er en JSON-filkonfiguration til en lokal demo, ikke til en offentlig tjeneste. Den indeholder hverken domænenavne, TLS-oplysninger eller adgangsdata. Inden den implementeres, skal man kontrollere filrettighederne, den faktisk installerede PHP-understøttelse og den metode, der er valgt til at importere konfigurationen til 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"
    }
  }
}

Rækkefølgen er afgørende: Den statisk levering Dette share-trin forsøges før fallback, men udelukker udtrykkeligt PHP-filer. Disse forespørgsler og ikke-eksisterende filer ender hos index.php; dermed fungerer også beskrivende URL'er som /artikel/beispiel uden en fil med samme navn. Om der er behov for yderligere regler for upload-mapper, administrationsområder eller direkte tilgængelige PHP-filer, afhænger det af den pågældende applikation og bør ikke generelt udledes af denne demo.

Sammenligning af procesmodeller og RAM-budget

PHP-FPM styrer antallet af arbejdsprocesser pr. pool via følgende tilstande static, dynamic og ondemand. I Unit modelleres procesnummeret derimod internt i applikationen. En dynamisk Unit-konfiguration begrænser med processes.max det samlede antal og holder trit med processes.spare Tomgangsprocesser; idle_timeout rydder overskydende inaktive processer.

Begreberne kan derfor ikke bruges i flæng. Især er en dokumenteret standardindstilling ikke en passende værdi for et websted. Både pm.max_children såvel som processes.max begrænser parallel PHP-behandling og kan skabe køer, hvis værdierne er for lave. For høje værdier konkurrerer derimod med operativsystemet, databasen, cachen og andre tjenester om arbejdshukommelsen.

En RAM-budget er i første omgang blot en planlægningsmodel: Fra den samlede lagerplads trækkes der reserver til operativsystemet, databasen, cachen og andre processer. Den resterende værdi divideres med et konservativt anslået hukommelsesbehov pr. PHP-worker. Eksempelvis giver 1.200 MiB til PHP divideret med 120 MiB pr. worker matematisk set ti workers; begge værdier er bevidst valgte stedfortrædere, ikke en måling eller en konfigurationsanbefaling.

Resultatet er en Øvre grænse og et udgangspunkt for observation, ikke den rigtige indstilling. Det afgørende er de faktiske spidsværdier, køer, svarfejl og hukommelsesbehovet under både typisk og høj belastning. For den metodiske udledning og justering af pm.max_children hjælper det interne indlæg Beregne det rette antal PHP-FPM-processer. I Unit gælder det samme princip, selvom parametrene har andre navne.

Advarsel: At fastsætte procesgrænser ved blot at overtage andres tal fører ofte blot til, at problemerne udskydes. Først et afgrænset hukommelsesbudget og løbende overvågning viser, om en øvre grænse for antallet af arbejdsprocesser passer til applikationen, dens udvidelser og de tjenester, der kører samtidigt.

Vurdering af driftsmodeller for PHP-hosting

Tabellen klassificerer arkitekturer, ikke hastighed eller hukommelsesforbrug. Det, der især taler for ny PHP-hosting med NGINX-PHP-FPM-konfigurationen, er den klare opdeling: Webserveren håndterer HTTP, proxying og statisk indhold, mens PHP-FPM administrerer PHP-workerne pr. pool. Disse ansvarsområder gør det nemmere at vurdere konfigurationer, fejlmønstre og opdateringer hver for sig.

Unit kunne samle lyttere, routing, statiske filer og applikationer i én platform og understøtte andre kørselmiljøer ud over PHP. Denne flersprogede tilgang kan forklare, hvorfor et eksisterende miljø har valgt Unit. For udelukkende PHP-baserede løsninger er det dog ikke nødvendigvis en fordel: Det erstatter hverken en vurdering af de nødvendige funktioner eller en undersøgelse af, om teamet på sigt kan mestre den anderledes konfigurations- og driftslogik.

I enhed 1.35.0 skal den tekniske funktionsomfang fra Vedligeholdelsesstatus skal adskilles. Udgivelsesdatoen angiver den udgivne version og de tilhørende ændringer; det betyder, at der ikke længere foretages vedligeholdelse af det nu arkiverede projekt. Når der skal træffes en ny beslutning, vejer denne grænse tungere end et mindre antal synlige komponenter. For en eksisterende installation er den derimod anledning til at dokumentere afhængigheder og en migrationsplan.

Apache med PHP-FPM er ikke generelt et bedre eller dårligere alternativ, men en mulighed, når der allerede er krav til Apache. Valget bør baseres på vedligeholdelsesvenlighed, tilgængelige PHP-versioner, patch-processer, teamets viden og beredskabsplanen. Uden sammenlignelige belastningsprofiler og dokumenterede målemetoder er det ikke muligt at udlede en pålidelig præstationsrangorden ud fra denne arkitekturoversigt.

Sikker drift af enheden i driftsflåden

En eksisterende Unit-installation bør først registreres som et eksisterende system og ikke som en skabelon til en ny platform. Det afgørende er den faktisk anvendte version, de tilknyttede applikationer og deres afhængigheder. At Unit fortsat er teknisk kørbart, ændrer ikke på, at projektet er blevet arkiveret; drift og udskiftning skal derfor planlægges i fællesskab.

I WordPress, Joomla eller Drupal er Frontcontroller Det centrale punkt: Stier, der ikke findes som filer, skal ledes til den centrale PHP-indgangsfil, mens eksisterende filer kan leveres direkte. WordPress-vejledningen til Unit viser dette routing-princip, herunder håndteringen af PHP-filer og /wp-admin/. For et eksisterende CMS kan dette være en forståelig konfiguration; for en nyinstallation er der imidlertid ingen anbefaling vedrørende Unit.

Flere små applikationer skrevet i PHP, Python, Ruby eller Node.js kunne samles på en fælles platform ved hjælp af Unit Listener, ruter og kørselstider. Det kan forklare, hvorfor man dengang valgte Unit i den eksisterende arkitektur. Ved ren PHP-hosting er denne understøttelse af flere sprog dog ikke et mål i sig selv: Separate, velvedligeholdte komponenter kan på lang sigt være nemmere at vedligeholde på trods af yderligere grænseflader.

En fastfrossen container-deployment kræver en særlig nøjagtig opgørelse. Dokumentér derfor den nøjagtige unit-tag, PHP-versionen, det installerede sprogmodul, basisbilledet og den fuldstændige konfiguration. Tilføj desuden kilder til billeder og pakker, patch-processen samt en testet migrations- og fallback-vej. PHP-kompatibilitet for en bestemt enhedsudgivelse er ikke en garanti for, at det tilhørende modul fremover vil modtage sikkerhedsrettelser.

NGINX kan placeres foran Unit, f.eks. hvis et eksisterende NGINX-lag skal bevares, eller hvis adgang specifikt skal dirigeres forbi. Unit-dokumentationen nævner også denne integration i forbindelse med sikring af Control Socket. Den løser dog ikke problemet med den arkiverede status og skaber en yderligere tjeneste med egen konfiguration, logning og ansvar for opdateringer. Fordelene skal derfor nøje afvejes i forhold til denne driftsbyrde.

Timeouts, logfiler og hængende processer

Procesgrænser er ikke en fejldiagnose. Med limits.requests kan Unit erstatte en applikationsproces efter et fastsat antal behandlede anmodninger. Dette kan begrænse den akkumulerede hukommelsesbrug over tid, men fjerner hverken hukommelseslækager, overdimensionerede datastrukturer eller blokerende eksterne opkald. En regelmæssig genstart må derfor ikke betragtes som bevis for en stabil applikationskode.

Med limits.timeout Unit afslutter en anmodning med en HTTP 503-fejl, når den konfigurerede tid er udløbet. Dette er en synlig beskyttelsesgrænse for enkelte anmodninger, men ikke en fuldstændig beskyttelse mod fastlåste arbejdsprocesser: Ifølge dokumentationen registrerer Unit ikke fastlåste processer; de kan forblive i procespuljen. En længere timeout udskyder blot dette problem, mens en kortere timeout kan afbryde normalt langsomme processer.

• Registrer HTTP-status, berørte stier, tidsvinduer og hyppighed, inden grænseværdierne ændres.
• Saml adgangs-, fejl- og applikationslogfiler ud fra tidsstempler; i forbindelse med PHP-FPM kan en slowlog give yderligere oplysninger om stakken.
• Kontroller CPU, arbejdshukommelse, I/O, netværksforbindelser samt status og antal processer.
• Undersøg derefter koden, databaseforespørgsler, adgang til filsystemet og eksterne tjenester som mulige årsager.
• Først når årsagen og belastningsprofilen er kendt, skal man målrettet justere timeouts, procesgrænser eller genstartsregler.

En HTTP 503-fejl kan således skyldes, at tidsgrænsen er overskredet, men kan også opstå på grund af opstrøms komponenter eller andre fejl. Gentagne lange PHP-forespørgsler bør du ikke udelukkende håndtere ved at justere antallet af workers. Vejledningen til PHP-FPM-Slowlog og analyse af årsagerne til langsomme forespørgsler viser, hvordan stakspor kan knyttes til anmodningsdata; den samme årsag-virkning-logik er også relevant ved en analyse af en enhedsbeholdning.

Særligt kritiske er symptomer uden en entydig afslutning: stigende ventetider, processer, der er permanent optaget, eller manglende fremskridt i loggen. I sådanne tilfælde er processtatus og afhængigheder vigtigere end en generel forhøjelse af timeout-tiden. Kontroller for eksempel, om en PHP-worker venter på database-, DNS-, filsystem- eller netværks-I/O. Først den konkrete blokering afgør, om en kodekorrektion, en ressourcetilpasning eller en kontrolleret genstart er passende.

Valg mellem nye og gamle systemer

For nye PHP-hostingmiljøer er en velvedligeholdt webserver med PHP-FPM det mest logiske standardvalg. PHP-FPM er en del af den almindelige PHP-distribution og tilbyder dokumenterede muligheder for pool- og proceshåndtering. Hos Unit skifter fokus imidlertid fra ren funktionalitet til vedligeholdelsesvenlighed: Installationen kan fortsætte, men den arkiverede projektstatus øger risikoen for en langsigtet afhængighed.

For eksisterende Unit-systemer starter en saglig beslutning med en opgørelse. Kontroller vedligeholdelsesstatus og mulighed for opdatering af operativsystem, PHP og basisimage, kompatibiliteten af det installerede sprogmodul, eksisterende driftsviden samt tilknyttede tjenester. Lige så vigtigt er det med konfigurationer, der kan eksporteres, en reproducerbar rollback og et målsystem, hvortil routing, PHP-indstillinger og implementeringer kan overføres trin for trin.

En migrering kræver ikke en fiktiv, universel frist, men derimod en prioriteret rækkefølge. Applikationer, der er eksponeret på internettet, images, der ikke kan opdateres, uklar moduloprindelse og forretningskritiske applikationer uden en nødplan skal have første prioritet. Derefter kan applikationerne grupperes efter kompleksitet og afhængigheder. Paralleldrift under en kontrolleret overgang kan reducere risici, forudsat at datalagring, sessioner og tilbageførselsvej er defineret på forhånd.

Die Control API er en administrativ adgang og ikke et almindeligt slutpunkt på et websted. Unit dokumenterer for dig, at der er tale om en Unix-domænesocket, og begrunder brugen heraf med sikkerhedsmæssige hensyn. Fastlæg restriktive filrettigheder og klart afgrænsede administrative adgangsrettigheder; offentlig tilgængelighed ville, hvis angribere fik adgang, give dem vidtgående muligheder for at ændre konfigurationen.

Den praktiske migrationsproces slutter ikke med en ny proceskonfiguration. Overfør PHP-versionen, udvidelser, miljøvariabler, filrettigheder, routingregler og overvågbarhed til målsystemet for hver enkelt applikation. Sammenlign i den forbindelse forventede svar og fejlscenarier i stedet for at drage generelle konklusioner om hastigheden. På den måde bliver en uplanlagt arv til en dokumenteret Udskiftningsstrategi med gennemsigtige tekniske beslutninger.