Nginx-Konfiguration meistern: Wichtige Direktiven erklärt

Die Nginx-Konfiguration wird viel einfacher, sobald Sie verstehen, wo jede Direktive platziert werden darf. Wenn Ihre proxy_pass-, root- oder try_files-Regel im falschen Kontext steht, kann Nginx die Konfiguration ablehnen oder Anfragen anders behandeln als erwartet.

Diese Anleitung führt durch die wesentlichen Direktiven, die Sie beim Ausliefern statischer Dateien, beim Reverse-Proxy einer Anwendung, beim Aktivieren der Komprimierung und beim sicheren Neuladen von Änderungen verwenden werden.

Die Struktur der Nginx-Konfiguration

Nginx-Konfigurationsdateien befinden sich normalerweise unter /etc/nginx/ auf Linux-Paketen. Die Hauptdatei ist üblicherweise /etc/nginx/nginx.conf, und sie bindet oft Dateien aus /etc/nginx/conf.d/ ein. Debian- und Ubuntu-Pakete verwenden häufig sites-available/ und sites-enabled/; viele andere Distributionen tun dies nicht.

Die Konfiguration ist hierarchisch aufgebaut, organisiert in Blöcken oder Direktiven. Zu den wichtigsten Blöcken gehören:

• events: Konfiguriert die Verbindungsverarbeitung.
• http: Enthält HTTP-weite Einstellungen und virtuelle Server.
• server: Definiert einen virtuellen Server für einen Port und Hostnamen.
• location: Bestimmt, wie passende Anfrage-URIs behandelt werden.

Direktiven sind Schlüssel-Wert-Paare, die das Verhalten von Nginx steuern. Sie können global oder innerhalb von Blöcken verschachtelt sein.

Wichtige Direktiven erklärt

Der http-Block

Der http-Block umschließt Konfigurationen, die global für den HTTP-Verkehr gelten. Hier definieren Sie allgemeine Einstellungen für Ihren Webserver.

• include: Diese Direktive ermöglicht es Ihnen, andere Konfigurationsdateien einzubinden, was zur Modularisierung Ihrer Einrichtung beiträgt. Sie wird häufig verwendet, um Konfigurationen für verschiedene Websites oder Anwendungen zu trennen.

  http {
      include       mime.types;
      default_type  application/octet-stream;
  
      # Server-Konfigurationen aus dem conf.d-Verzeichnis einbinden
      include /etc/nginx/conf.d/*.conf;
  }
  

• log_format: Definiert benutzerdefinierte Logformate für Nginx-Zugriffs- und Fehlerlogs. Dies ist für detaillierte Protokollierung und Analyse unerlässlich.

  http {
      log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" "$http_x_forwarded_for"';
  
      access_log  /var/log/nginx/access.log  main;
      error_log   /var/log/nginx/error.log;
      # ... andere http-Direktiven
  }
  

• sendfile: Optimiert Dateiübertragungen, indem der Kernel Dateien direkt von der Festplatte an den Client senden kann, ohne den Benutzerbereich zu durchlaufen. Setzen Sie es aus Leistungsgründen auf on.

  http {
      sendfile        on;
      # ...
  }
  

• tcp_nopush und tcp_nodelay: Diese optimieren das TCP-Verhalten für HTTP-Antworten. tcp_nopush wird häufig mit sendfile verwendet, um den Paketversand zu optimieren, während tcp_nodelay hilft, Verzögerungen bei Keepalive-Verbindungen zu vermeiden.

  http {
      tcp_nopush     on;
      tcp_nodelay    on;
      # ...
  }
  

Der server-Block

Jeder server-Block definiert einen virtuellen Server, sodass Nginx Anfragen für verschiedene Domainnamen oder IP-Adressen auf demselben Server bearbeiten kann.

• listen: Gibt die IP-Adresse und/oder den Port an, auf dem der Server auf eingehende Verbindungen hören soll.

  server {
      listen 80;
      listen [::]:80;
      server_name example.com www.example.com;
      # ...
  }
  

• server_name: Definiert die Namen des Servers. Nginx verwendet dies, um den Host-Header der eingehenden Anfrage abzugleichen.

  server {
      listen 80;
      server_name mydomain.org *.mydomain.org;
      # ...
  }
  

• root: Setzt das Dokumentenwurzelverzeichnis. Nginx erstellt den Dateipfad, indem es den Anfrage-URI an dieses Verzeichnis anhängt.

  server {
      listen 80;
      server_name localhost;
      root /var/www/html;
      index index.html index.htm;
      # ...
  }
  

• index: Gibt die Standarddatei an, die ausgeliefert wird, wenn ein Verzeichnis angefordert wird.

  server {
      # ...
      index index.html index.htm default.html;
      # ...
  }
  

• error_page: Definiert benutzerdefinierte Fehlerseiten für bestimmte HTTP-Statuscodes.

  server {
      # ...
      error_page 404 /404.html;
      location = /404.html {
          root /usr/share/nginx/html;
          internal;
      }
      # ...
  }
  

Der location-Block

Der location-Block wird verwendet, um Anfrage-URIs abzugleichen und zu bestimmen, wie Nginx sie verarbeiten soll. Hier konfigurieren Sie das Routing für verschiedene Teile Ihrer Anwendung.

• URIs abgleichen: Locations können exakte Zeichenfolgen, Präfixe oder reguläre Ausdrücke abgleichen. Exakte Übereinstimmungen verwenden =, reguläre Ausdrücke verwenden ~ oder ~*, und einfache Präfixe gleichen nach URI-Präfix ab.

  location /images/ {
      # Direktiven für Anfragen, die mit /images/ beginnen
  }
  
  location = /favicon.ico {
      # Exakte Übereinstimmung für /favicon.ico
  }
  
  location ~ \.php$ {
      # Regex-Übereinstimmung für Dateien, die auf .php enden
  }
  

• proxy_pass: Leitet Anfragen an einen vorgelagerten Server weiter. Achten Sie auf den abschließenden Schrägstrich, da er ändert, wie Nginx das abgeglichene Präfix umschreibt.

  location /api/ {
      proxy_pass http://backend-service:8080/;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
  }
  

• alias: Ordnet einen Location einem Dateisystempfad zu, ohne den vollständigen ursprünglichen URI anzuhängen. Es wird häufig für statische Assets verwendet, die außerhalb des Hauptdokumentenwurzelverzeichnisses gespeichert sind.

  location /static/ {
      alias /var/www/app/assets/;
  }
  

  Verwenden Sie bei alias den abschließenden Schrägstrich sowohl für den Location als auch den Pfad bei Verzeichniszuordnungen. alias ersetzt das abgeglichene Location-Präfix durch den Alias-Pfad, während root den URI an den Wurzelpfad anhängt.

• try_files: Überprüft die Existenz von Dateien in einer angegebenen Reihenfolge und liefert die erste gefundene aus oder gibt einen bestimmten Code/URI zurück.

  location / {
      try_files $uri $uri/ /index.html;
  }
  

  Dies ist üblich für Single-Page-Anwendungen. Wenn eine angeforderte Datei oder ein Verzeichnis nicht existiert, liefert Nginx index.html aus, damit der clientseitige Router den Pfad verarbeiten kann.

Sicherheits- und Leistungsdirektiven

• ssl_certificate und ssl_certificate_key: Unerlässlich für die Konfiguration von HTTPS. Diese Direktiven verweisen auf Ihre SSL-Zertifikats- und privaten Schlüsseldateien.

  server {
      listen 443 ssl;
      server_name secure.example.com;
  
      ssl_certificate /etc/letsencrypt/live/secure.example.com/fullchain.pem;
      ssl_certificate_key /etc/letsencrypt/live/secure.example.com/privkey.pem;
  
      # ... andere SSL-Einstellungen
  }
  

• gzip: Aktiviert oder deaktiviert die Gzip-Komprimierung für ausgewählte Antworttypen. Es reduziert oft die Übertragungsgröße für Text-Assets, vermeiden Sie jedoch die Komprimierung bereits komprimierter Dateien wie der meisten Bilder.

  http {
      gzip on;
      gzip_vary on;
      gzip_proxied any;
      gzip_comp_level 6;
      gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
      # ...
  }
  

• expires: Steuert Caching-Header für statische Assets. Verwenden Sie lange Cache-Lebensdauern für versionierte Dateien und kürzere Lebensdauern für Dateien, die über mehrere Bereitstellungen hinweg dieselbe URL behalten.

  location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
      expires 30d;
      add_header Cache-Control "public";
  }
  

Häufige Nginx-Befehle

Um Nginx zu verwalten und Konfigurationsänderungen anzuwenden, werden Sie häufig diese Befehle verwenden:

• Konfiguration testen: Überprüft auf Syntaxfehler in Ihren Nginx-Konfigurationsdateien.

  sudo nginx -t
  

• Konfiguration neu laden: Lädt die Nginx-Konfiguration ohne Unterbrechung aktiver Verbindungen neu.

  sudo systemctl reload nginx
  # oder
  sudo service nginx reload
  

• Nginx neu starten: Stoppt und startet den Nginx-Dienst.

  sudo systemctl restart nginx
  # oder
  sudo service nginx restart
  

• Status überprüfen: Zeigt den aktuellen Status des Nginx-Dienstes an.

  sudo systemctl status nginx
  # oder
  sudo service nginx status
  

Ein minimales funktionierendes Beispiel

Dieses Beispiel liefert eine Single-Page-App von der Festplatte aus und leitet API-Anfragen an einen Anwendungsserver weiter:

server {
    listen 80;
    server_name example.com;

    root /var/www/example.com;
    index index.html;

    location /api/ {
        proxy_pass http://127.0.0.1:3000/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location / {
        try_files $uri $uri/ /index.html;
    }
}

Führen Sie vor jedem Neuladen sudo nginx -t aus. Diese eine Gewohnheit fängt Syntaxfehler, bevor sie zu Ausfallzeiten führen.

Fazit

Die meisten Nginx-Fehler entstehen durch Kontext- und Pfadbehandlung. Setzen Sie HTTP-weite Einstellungen in http, host-spezifische Regeln in server, URI-Routing in location und testen Sie jede Änderung mit nginx -t vor dem Neuladen.