NGINX Grundlagen

6 Kernkonzepte

Die wichtigsten NGINX-Konzepte für Webserver, Reverse Proxy und Load Balancing: Konfigurationsstruktur · Virtual Hosts · Reverse Proxy · Load Balancing · SSL/TLS · Rewrite & Redirect NGINX ist ein leistungsstarker Webserver, Reverse Proxy und Load Balancer. Diese Cheatsheet fasst die wichtigsten Konfigurationsdirektiven und Einsatzszenarien zusammen.

Konfigurationsstruktur – nginx.conf & sites-available

/etc/nginx/nginx.conf · sites-enabled/

# Hauptkonfiguration /etc/nginx/nginx.conf # Virtual Hosts /etc/nginx/sites-available/ /etc/nginx/sites-enabled/

NGINX-Konfiguration besteht aus einer Hauptkonfigurationsdatei und mehreren Server-Blöcken (Virtual Hosts) für einzelne Websites oder Dienste.

Wichtige Konfigurationsdateien

Datei / Verzeichnis	Beschreibung
/etc/nginx/nginx.conf	Hauptkonfigurationsdatei (global)
/etc/nginx/sites-available/	Verfügbare Virtual Hosts (Konfigurationen)
/etc/nginx/sites-enabled/	Aktive Virtual Hosts (Symlinks zu sites-available)
/etc/nginx/conf.d/	Zusätzliche Konfigurationen (global)
/var/log/nginx/	Zugriffs- und Fehlerlogs

Beispiele

# Konfiguration testen

nginx -t

# Konfiguration neu laden

systemctl reload nginx

# Virtual Host aktivieren

ln -s /etc/nginx/sites-available/meineseite.conf /etc/nginx/sites-enabled/

systemctl reload nginx

Tipp: Verwenden Sie nginx -t vor jedem Reload, um die Konfiguration auf Syntaxfehler zu prüfen – das verhindert Ausfallzeiten.

Virtual Hosts – Server-Blöcke für Websites

server { listen 80; server_name; root; }

server { listen 80; server_name example.com; root /var/www/example.com; index index.html; }

Virtual Hosts (Server-Blöcke) definieren, wie NGINX auf Anfragen für bestimmte Domainnamen reagiert – mit eigenem Document Root, Logging und Konfiguration.

Beispiele

# Standard Virtual Host

server {

listen 80;

server_name example.com www.example.com;

root /var/www/example.com;

index index.html index.htm;

access_log /var/log/nginx/example.com-access.log;

error_log /var/log/nginx/example.com-error.log;

}

# HTTPS-Weiterleitung

server {

listen 80;

server_name example.com;

return 301 https://$server_name$request_uri;

}

Tipp: Erstellen Sie für jede Domain eine eigene Konfigurationsdatei in sites-available und aktivieren Sie sie mit einem Symlink in sites-enabled.

Reverse Proxy – Anfragen weiterleiten

proxy_pass · proxy_set_header

location /api/ { proxy_pass http://localhost:3000/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }

Reverse Proxy leitet eingehende Anfragen an einen oder mehrere Backend-Server weiter – ideal für Node.js, Python, Java oder andere Anwendungen hinter NGINX.

Beispiele

# Proxy zu einem Backend

server {

listen 80;

server_name api.example.com;

location / {

proxy_pass http://localhost:3000;

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection 'upgrade';

proxy_set_header Host $host;

proxy_cache_bypass $http_upgrade;

}

# Proxy mit Pfadweiterleitung

location /app/ {

proxy_pass http://localhost:8080/; # Trailing Slash wichtig!

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

}

Tipp: Bei proxy_pass mit trailing Slash (http://localhost:3000/) wird der location-Pfad ersetzt. Ohne Slash wird er an den Backend-Pfad angehängt.

Load Balancing – Lastverteilung auf mehrere Backends

upstream · proxy_pass

upstream backend_servers { server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; } location / { proxy_pass http://backend_servers; }

Load Balancing verteilt eingehende Anfragen auf mehrere Backend-Server, um Auslastung zu verteilen und Ausfallsicherheit zu erhöhen.

Load-Balancing-Methoden

Methode	Beschreibung
Round Robin (Standard)	Anfragen werden gleichmäßig verteilt
least_conn	An den Server mit den wenigsten aktiven Verbindungen
ip_hash	Selbe Client-IP geht immer zum selben Server (Session-Sticky)
weight=2	Gewichtung für Server (höheres Gewicht = mehr Anfragen)

Beispiele

# Upstream mit Gewichtung und Health Check

upstream web_backend {

least_conn; # Methode: Least Connections

server 192.168.1.10:8080 weight=3;

server 192.168.1.11:8080 weight=2;

server 192.168.1.12:8080 weight=1;

server 192.168.1.13:8080 backup; # Backup-Server

}

# Server mit ip_hash für Session-Sticky

upstream app_backend {

ip_hash;

server 192.168.1.10:8080;

server 192.168.1.11:8080;

}

Tipp: Für Session-Sticky (z.B. bei Node.js mit Sessions) verwenden Sie ip_hash. Für reine APIs ist least_conn oft die beste Wahl.

SSL/TLS – HTTPS mit Let's Encrypt

listen 443 ssl · ssl_certificate

server { listen 443 ssl; server_name example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; }

SSL/TLS verschlüsselt die Verbindung zwischen Client und Server. Let's Encrypt bietet kostenlose Zertifikate, die automatisch erneuert werden können.

Beispiele

# SSL-Konfiguration (modern)

server {

listen 443 ssl http2;

server_name example.com;

root /var/www/example.com;

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

ssl_protocols TLSv1.2 TLSv1.3;

ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384';

ssl_prefer_server_ciphers on;

ssl_session_cache shared:SSL:10m;

add_header Strict-Transport-Security "max-age=31536000" always;

}

# HTTP → HTTPS Weiterleitung

server {

listen 80;

server_name example.com www.example.com;

return 301 https://$host$request_uri;

}

Tipp: Für Let's Encrypt verwenden Sie certbot (certbot --nginx -d example.com). Die Zertifikate werden automatisch erneuert.

Rewrite & Redirect – URLs umschreiben

rewrite · return · try_files

rewrite ^/old/(.*)$ /new/$1 permanent; return 301 https://newdomain.com$request_uri; try_files $uri $uri/ /index.html;

Rewrite & Redirect ermöglichen die Umleitung von URLs, das Umschreiben von Pfaden und die Implementierung von Clean URLs.

Beispiele

# Einfache Weiterleitung (301 Permanent)

location /alt {

return 301 /neu;

}

# Rewrite mit Regex (alter Pfad → neuer Pfad)

location /blog/ {

rewrite ^/blog/([0-9]+)/(.*)$ /posts/$1/$2 break;

}

# try_files für SPA (Single Page Application)

location / {

try_files $uri $uri/ /index.html;

}

# Domänen-Weiterleitung

server {

listen 80;

server_name old-domain.com www.old-domain.com;

return 301 https://new-domain.com$request_uri;

}

Tipp: try_files ist die empfohlene Methode für SPAs (Single Page Applications) – sie prüft, ob eine Datei existiert, und fällt sonst auf index.html zurück.

NGINX Kernkonzepte im Überblick

server Virtual Host
Domain-spezifische Konfiguration

location URL-Pfad-Konfiguration
Regex, Proxy, Static Files

proxy_pass Reverse Proxy
An Backend weiterleiten

upstream Load Balancing
Mehrere Backend-Server

ssl_* SSL/TLS
HTTPS-Verschlüsselung

rewrite URL-Umschreibung
Redirect, Clean URLs

Quick Summary

nginx -t

Konfiguration testen

server

Virtual Host

proxy_pass

Reverse Proxy

upstream

Load Balancing

ssl_certificate

SSL/TLS

return 301

Redirect

nginx -t · systemctl reload nginx · proxy_pass http://localhost:3000