NGINX Server Block Generator

Ein Serverblock ist das NGINX-Äquivalent eines Apache-Virtual Hosts. Er gruppiert Direktiven, die bestimmen, wie NGINX auf eine Anfrage für eine bestimmte Host-Name und Port reagiert: welche Dateien zu servieren, wo der Traffic weitergeleitet wird, welches TLS-Zertifikat verwendet wird und welche Logs erstellt werden. NGINX vergleicht einen eingehenden Request mit einem Serverblock, indem er den Host Header und den lauschenden Socket mit den Angaben des Blocks vergleicht. server_name und listen Direktiven.

Das Verhalten wird pro locationbestimmt. Ein statischer-Datei-Location verwendet root plus try_files und index um auf der Festplatte nach Dateien zu suchen; ein Reverse-Proxy-Location verwendet proxy_pass um die Anfrage an eine andere Adresse über HTTP weiterzuleiten. NGINX selbst erkennt das nicht automatisch – Sie wählen den Modus durch Schreiben der entsprechenden Direktiven, und NGINX führt einfach die Block aus, der mit der Anfrage-URI übereinstimmt.

HTTP/2 multiplexiert viele parallele Anfragen über eine einzelne TCP-Verbindung, sendet Headers in komprimierter binärer Form (HPACK) und unterstützt Server Push. In der Praxis reduziert dies das Head-of-Line-Blocking und senkt die Latenz für Seiten, die viele Ressourcen aus dem gleichen Ursprung laden. HTTP/2 erfordert außerdem TLS in Browsern, weshalb es gemeinsam mit SSL auf dem gleichen Listener aktiviert wird.

Das NGINX-Modul gzip komprimiert die ausgehenden Antwortkörper vor dem Verlassen des Servers mit DEFLATE und einer konfigurierbaren Stufe. Es ist besonders wirksam bei textähnlichen MIME-Typen – HTML, CSS, JavaScript, JSON, XML, SVG – und ist bei bereits komprimierten Formaten wie JPEG, PNG oder Video ein Leerlauf. NGINX gibt die Unterstützung an Clients über den Vary: Accept-Encoding Header weiter, damit Caches sowohl komprimierte als auch unkomprimierte Kopien speichern können.

Wenn eine Anfrage durch einen Reverse-Proxy geht, sieht der Backend-Dienst die IP-Adresse des Proxys als Client. Der X-Forwarded-For Header bewahrt die ursprüngliche Kette von Client-Adressen auf, und X-Real-IP zeichnet nur den unmittelbaren Client auf. Zusammen mit X-Forwarded-Protoermöglichen sie dem Backend, herauszufinden, wer der echte Besucher ist und ob er über HTTPS verbunden ist, was für genaue Limitierung, Zugriffskontrolle und Analysen unerlässlich ist.