Stellen Sie sich zwei Restaurants vor.

Im ersten bekommt jeder Gast seinen eigenen Kellner. Einen, der nur an diesem einen Tisch steht. Wartet. Bedient. Solange wenige Gäste da sind, ist das herrlich. Doch dann kommt der Samstagabend. Zweihundert Gäste, zweihundert Kellner, ein Gedränge hinter der Theke, jemand stolpert über das Tablett des anderen. Irgendwann ist kein Personal mehr frei. Und die Tür bleibt zu.

Im zweiten Restaurant arbeiten vier Kellner. Nur vier. Aber sie stehen nie still. Sie gleiten zwischen den Tischen, nehmen hier eine Bestellung auf, stellen dort einen Teller ab, kümmern sich genau in dem Moment um einen Gast, in dem er etwas braucht. Niemand wartet auf seinen persönlichen Kellner, weil niemand einen persönlichen Kellner hat. Und seltsamerweise läuft dieser Laden auch um zehn Uhr abends noch wie geschmiert.

Das zweite Restaurant ist nginx.

nginx verteilt viele gleichzeitige Anfragen ressourcenschonend über wenige Worker und leitet sie an passende Ziele weiter.

Was ist nginx?

nginx (gesprochen „Engine X“) ist ein Webserver: eine Software, die Anfragen aus dem Internet entgegennimmt und die passende Antwort zurückschickt. Ruft jemand eine Website auf, klopft sein Browser bei einem Server an. nginx ist die Instanz, die dieses Klopfen hört, einordnet und beantwortet. Mit einer HTML-Seite. Einem Bild. Einem Video.

So weit die Lehrbuch-Definition. Sie greift zu kurz.

Denn nginx ist selten nur Webserver. Es ist Empfangschef, Verteiler und Vorratskammer in einem. Es nimmt Datenverkehr an, leitet ihn an die richtige Stelle weiter, verteilt Last auf mehrere Maschinen und hält Häufiges griffbereit, damit nicht jedes Mal die ganze Küche anlaufen muss. In der Sprache der Technik: Webserver, Reverse Proxy, Load Balancer, Content Cache und API-Gateway. In der Sprache des Restaurants: der Mensch am Eingang, der weiß, wohin jeder Gast gehört, und dafür sorgt, dass keiner zu lange im Flur steht.

Geschrieben ist das Ganze in C. Quelloffen, unter einer freizügigen BSD-Lizenz. Und laut W3Techs liegt nginx beim Anteil aller untersuchten Websites seit Jahren an der Spitze, im Frühjahr 2025 bei rund einem Drittel, vor dem alten Platzhirsch Apache und vor Cloudflare. Ein Stück Software, das ein gutes Stück des heutigen Webs trägt, ohne dass die meisten Menschen je seinen Namen gehört hätten.

Vier Kellner, zehntausend Gäste: wie nginx arbeitet

Zurück ins Restaurant. Was macht den Unterschied zwischen den beiden Läden? Nicht die Zahl der Kellner. Die Haltung dahinter.

Der klassische Ansatz weist jedem Gast einen eigenen Bediensteten zu. Ein Prozess pro Verbindung. Das ist sauber, übersichtlich, leicht zu verstehen. Es hat nur einen Haken: Jeder dieser Prozesse kostet Arbeitsspeicher, ob er gerade etwas tut oder nicht. Tausend gleichzeitige Gäste bedeuten tausend wartende Kellner, von denen die meisten in genau diesem Augenblick nichts in der Hand halten. Der Server füllt sich mit Leerlauf, bis nichts mehr geht.

nginx denkt anders herum. Es startet einen Hauptprozess und darunter eine kleine Zahl sogenannter Worker, oft einen pro Prozessorkern. Jeder dieser Worker führt eine Endlosschleife aus, eine Art Rundgang durch den Saal. Auf diesem Rundgang prüft er fortlaufend: Wer braucht gerade etwas? Wer hat eine Bestellung fertig? Wo wartet eine Antwort darauf, abgeholt zu werden? Nur dann, wenn tatsächlich etwas zu tun ist, wird der Kellner aktiv. Den Rest der Zeit verschwendet er nicht.

Das nennt sich ereignisgesteuerte, nicht blockierende Architektur. Klingt sperrig. Heißt im Kern: nicht warten, sondern reagieren. Ein einzelner Worker kann auf diese Weise Tausende Verbindungen gleichzeitig betreuen, weil keine davon ihn fesselt, solange sie nichts von ihm will. Möglich machen das systemnahe Mechanismen wie epoll unter Linux oder kqueue unter BSD und macOS, die dem Worker melden, an welchem Tisch sich gerade etwas regt.

Geschwindigkeit entsteht hier nicht durch mehr Kraft. Sondern durch weniger Verschwendung.

Das Problem, für das nginx geboren wurde

Diese Bauweise ist kein Zufall. Sie ist eine Antwort auf eine konkrete Frage, die das frühe Web umtrieb: das sogenannte C10k-Problem. Wie bringt man einen einzigen Server dazu, zehntausend gleichzeitige Verbindungen zu bedienen, ohne in die Knie zu gehen?

Mit dem Modell „ein Kellner pro Tisch“ ist das nicht zu schaffen. Bei zehntausend Gästen bricht jedes Personalbüro zusammen. Genau hier setzte nginx an. Es wurde nicht gebaut, um ein bisschen schneller zu sein als die anderen. Es wurde gebaut, um eine Wand zu durchbrechen, an der die etablierte Software damals zerschellte.

Und es funktionierte. Bei statischen Inhalten, bei vielen parallelen Verbindungen, bei knappem Arbeitsspeicher spielt nginx seine Stärke aus. Vergleichsmessungen zeigen regelmäßig, dass es unter hoher Last deutlich sparsamer mit Ressourcen umgeht als ein prozessorientierter Server. Bei dynamischen Inhalten, wo ohnehin eine Programmiersprache im Hintergrund rechnet, schrumpft der Abstand, weil dann nicht mehr der Webserver der Flaschenhals ist, sondern die Anwendung dahinter.

Wo also liegt für Sie der eigentliche Engpass? Beim Servieren oder beim Kochen? Diese Frage entscheidet oft mehr als jede Server-Religion.

Mehr als Teller tragen: die vielen Rollen von nginx

Dass nginx so selten allein als Webserver auftritt, hat einen Grund: Wer Verbindungen so leichtfüßig verwalten kann, eignet sich für mehr als das bloße Ausliefern von Seiten. Drei Rollen sieht man besonders häufig.

• Als Reverse Proxy steht nginx vor anderen Servern und nimmt den Verkehr stellvertretend entgegen. Wie ein Oberkellner, der die Bestellung aufnimmt und entscheidet, welcher Teil der Küche sie zubereitet. Der Gast merkt von dieser Verteilung nichts. Er sieht nur, dass jemand sich kümmert.
• Als Load Balancer verteilt nginx eingehende Anfragen auf mehrere Maschinen dahinter. Fällt eine Küche aus oder ist überlastet, wandert die Bestellung zur nächsten. So bleibt der Laden offen, auch wenn im Hintergrund einer der Herde streikt.
• Als Content Cache hält nginx häufig Gefragtes bereit, damit nicht jedes Mal die volle Maschinerie anlaufen muss. Das beliebte Tagesgericht steht vorgewärmt bereit. Wer es bestellt, wartet kaum.

Dazu kommt die moderne Garnitur: Unterstützung für WebSocket, HTTP/2, HTTP/3, gRPC, das Ausliefern von Videoströmen. Das Web hat sich seit 2004 von schlichten Textseiten zu einem Geflecht aus Anwendungen, Schnittstellen und Medien entwickelt. nginx ist mitgewachsen.

nginx und Apache: zwei Philosophien, nicht zwei Gegner

Kaum ein Text über nginx kommt ohne diesen Vergleich aus, also los: nginx gegen Apache.

Der Reflex vieler Texte lautet, einen Sieger zu küren. Das ist bequem und meistens falsch. Die beiden verkörpern unterschiedliche Grundhaltungen. Apache, das ältere und über Jahre dominierende Projekt, arbeitet in seiner klassischen Form mit einem Prozess oder Faden pro Verbindung. Das bringt Isolation und Einfachheit, kostet aber Speicher, sobald viele Gäste gleichzeitig anklopfen. Apache bietet inzwischen ebenfalls ressourcenschonendere Betriebsarten an, doch das Grundtemperament bleibt: ein dediziertes Stück Personal je Anliegen.

nginx setzt auf den schlanken, ereignisgesteuerten Saal mit wenigen, dauernd kreisenden Workern. Sparsam unter Last. Schnell beim Statischen. Klar in der Konfiguration.

Die ehrliche Antwort auf „welcher ist besser?“ lautet darum: kommt darauf an, was Ihr Restaurant servieren will. Viele Setups stellen nginx als schnellen Empfang ganz nach vorn und lassen einen anderen Server die schwere Küchenarbeit dahinter erledigen. Nicht entweder, oder. Sondern jeder an seinem Platz.

Eine kurze Geschichte, samt einem Streit am Valentinstag

nginx ist kein Produkt eines Großkonzerns mit Marketingabteilung. Es begann mit einer Person und einem Problem.

Der russische Entwickler Igor Sysoev arbeitete um 2002 an einer Lösung für das C10k-Problem und veröffentlichte sie am 4. Oktober 2004 frei. 2011 entstand die Firma Nginx, Inc., um kommerziellen Support und die kostenpflichtige Variante NGINX Plus anzubieten. 2019 kaufte der amerikanische Netzwerkanbieter F5 das Unternehmen für 670 Millionen Dollar. Aus dem Werk eines Einzelnen war ein Stück Infrastruktur geworden, an dem ein börsennotierter Konzern verdient.

Und dann, am Valentinstag 2024, ein Bruch. Maxim Dounin, einer der zentralen langjährigen Entwickler, kündigte seinen Rückzug an und startete eine eigene Abspaltung namens freenginx. Der Auslöser war ein Streit über die Sicherheitspolitik des Projekts, konkret darüber, wie mit Schwachstellen in noch experimentellem Code umgegangen werden sollte. Dounins Vorwurf: Eine neue, technikferne Führung mische sich in eine über Jahre bewährte Praxis ein und übergehe die Position der Entwickler. Sein Ziel sei ein Projekt, das von Entwicklern geführt werde, nicht von einem Konzern.

Das ist die unbequeme Wahrheit hinter jeder Infrastruktur: Auch Software, die nur Daten hin- und herschiebt, trägt Menschen, Interessen und Konflikte in sich. Wer wissen will, worauf er baut, sollte nicht nur die Funktionen kennen, sondern auch die Hände, die sie pflegen.

Wann nginx das Richtige für Sie ist

Soll man nginx einsetzen, weil es modern klingt? Nein. Das ist genau die Frage, die in die Irre führt.

Sinnvoll wird nginx, wenn Sie viele gleichzeitige Verbindungen erwarten, statische Inhalte schnell ausliefern wollen, einen schlanken Verteiler vor mehreren Servern brauchen oder Ressourcen sparen müssen, etwa auf einem kleinen virtuellen Server. Es ist die Wahl für Schnelligkeit unter Andrang und für ein Setup, in dem ein zentraler, klar konfigurierter Eingang allem anderen vorgelagert ist.

Weniger zwingend ist es, wenn Ihr Engpass woanders sitzt, in einer langsamen Datenbank etwa oder in einer rechenintensiven Anwendung. Dann hilft der schnellste Kellner der Welt wenig, solange die Küche trödelt.

Die nüchterne Empfehlung lautet also nicht „nehmen Sie nginx“, sondern: schauen Sie hin, wo Ihr Verkehr tatsächlich ins Stocken gerät. Werkzeuge folgen Problemen, nicht Moden.

Der letzte Gedanke

Was bleibt, ist mehr als eine Definition. nginx ist schnell, weil es etwas Kontraintuitives tut: Es kümmert sich um jede Verbindung möglichst wenig, damit es sich um möglichst viele kümmern kann. Es hält nicht fest. Es reagiert.

Vielleicht ist das die eigentliche Lektion, die ein Stück Server-Software für uns bereithält. Wer alles gleichzeitig umklammert, jeden Tisch mit einem eigenen, dauerhaft gebundenen Kellner besetzt, hat am Ende keine Hände mehr frei. Wer loslässt, was gerade nicht dran ist, schafft Raum für das, was im Moment wirklich zählt.

Welcher Ihrer Tische wartet gerade auf einen Kellner, der nie kommt?