Nginx installieren und konfigurieren: Wie geht das unter Linux?

Was bedeutet Nginx installieren und welche Schritte gehören dazu?

Nginx installieren heißt, den Open Source Webserver Nginx mit dem Paketmanager auf einem Linux Server einzurichten, als Systemdienst zu starten und eine erste Konfiguration für Ihre Website zu schreiben. Sie installieren das Paket, aktivieren den Dienst, legen einen Serverblock an, prüfen ihn mit nginx -t und ergänzen danach SSL, Logs und Sicherheitseinstellungen.

Diese Anleitung haben wir als Talha Aslan und Team auf Basis offizieller Dokumentation geschrieben. Wir sind kein Hosting Anbieter, sondern ein Team für digitales Marketing, Webdesign und Software. Deshalb stützen sich die Befehle auf nginx.org, Ubuntu und Certbot, nicht auf eigene Betriebserfahrung. Versionsnummern nennen wir daher bewusst nicht. Nutzen Sie stattdessen immer die aktuelle stabile Version Ihrer Distribution oder von nginx.org.

Den Ablauf können Sie grob in vier Phasen gliedern:

1. Installation: das Paket aus der Distribution oder aus dem offiziellen Repository von nginx.org einspielen.
2. Dienstverwaltung: Nginx mit systemctl starten, beim Booten aktivieren und den Status prüfen.
3. Konfiguration: den Aufbau von nginx.conf verstehen, den ersten Serverblock schreiben und testen.
4. Absicherung: SSL, Sicherheitsheader, Versionsangabe ausblenden, Logs auswerten und Firewall einrichten.

Wofür eignet sich Nginx und wann sollten Sie ihn wählen?

Nginx arbeitet sowohl als Webserver als auch als Reverse Proxy. Laut dem offiziellen Einsteigerleitfaden liest ein Masterprozess die Konfiguration, während mehrere Workerprozesse die Anfragen ereignisbasiert abarbeiten. Somit kann Nginx viele gleichzeitige Verbindungen mit wenig Arbeitsspeicher bedienen.

In der Praxis nutzen Teams Nginx vor allem für diese Aufgaben:

• Statische Dateien wie HTML, CSS, JavaScript und Bilder schnell ausliefern.
• PHP Anwendungen über PHP-FPM ausführen.
• Als Reverse Proxy vor Anwendungen in Node.js, Python oder Go stehen.
• SSL Terminierung, Weiterleitungen und einfache Lastverteilung übernehmen.

Allerdings passt Nginx nicht zu jedem Projekt. Beim Shared Hosting wählen Sie den Webserver zum Beispiel gar nicht selbst. Falls Sie lieber mit einem Panel arbeiten, lohnt sich ein Blick auf Alternativen wie OpenLiteSpeed. Die Unterschiede beider Server haben wir in unserem Vergleich OpenLiteSpeed und Nginx beschrieben; hier wiederholen wir das nicht.

Was sollten Sie vorbereiten, bevor Sie Nginx installieren?

Bevor Sie Nginx installieren, lohnt sich etwas Vorbereitung, denn dann laufen alle späteren Schritte deutlich ruhiger. Vor allem Domain und DNS sorgen in der SSL Phase oft für Probleme.

• Ein aktueller Linux Server mit SSH Zugang und einem Benutzer mit sudo Rechten.
• Eine Domain, die auf die öffentliche IP des Servers zeigt (A Eintrag und bei Bedarf AAAA Eintrag).
• Eingehender Zugriff auf die Ports 80 und 443.
• Ein klarer Plan für das Verzeichnis, in dem Ihre Website liegt.
• Ein frisches Backup oder ein Snapshot Ihres Anbieters vor jeder Änderung.

Starten Sie mit einem leeren Server, arbeiten Sie zunächst unsere Anleitung zum Ubuntu Server installieren und einrichten durch. Danach prüfen Sie mit unserer DNS Abfrage, ob die Domain auf die richtige IP zeigt. Solange der DNS Eintrag nicht stimmt, scheitert also die Prüfung durch Certbot.

Schließlich sollten Sie klären, ob bereits ein anderer Webserver auf Port 80 lauscht. Läuft zum Beispiel Apache auf derselben Maschine, startet Nginx nicht, denn zwei Programme können nicht denselben Port belegen. Der Befehl sudo ss -tlnp zeigt, welcher Prozess welchen Port nutzt.

Nginx installieren unter Ubuntu und Debian: welche Befehle brauchen Sie?

Der einfachste Weg führt über das Paket aus dem Repository Ihrer Distribution. Die Ubuntu Server Dokumentation beschreibt die Installation mit zwei Befehlen:

sudo apt update
sudo apt install nginx

Unter Ubuntu startet der Dienst nach der Installation in der Regel von selbst. Den Zustand prüfen Sie so:

sudo systemctl status nginx

Steht in der Ausgabe "active (running)", läuft Nginx. Rufen Sie dann die IP Adresse des Servers im Browser auf. Erscheint dann die Willkommensseite von Nginx, ist die erste Phase geschafft. Lädt die Seite nicht, liegt es meist an der Firewall; dazu kommen wir weiter unten.

Das Paket für Debian und Ubuntu bringt die Struktur sites-available und sites-enabled mit. Das Standardverzeichnis für Inhalte ist /var/www/html. Konkret pflegen Sie dadurch jede Website in einer eigenen Datei. Zudem deaktivieren Sie eine Website, indem Sie einfach ihren Link entfernen.

Nginx installieren auf AlmaLinux, Rocky Linux oder RHEL: was ist anders?

In der RHEL Familie heißt der Paketmanager dnf, und Nginx stammt aus dem Repository der Distribution. Die Befehle lauten:

sudo dnf install nginx
sudo systemctl enable --now nginx

Anders als bei Debian startet der Dienst hier nach der Installation nicht automatisch. Der Schalter enable --now aktiviert Nginx beim Booten und startet ihn sofort. Auch die Dateistruktur unterscheidet sich: Ihre Websites legen Sie als .conf Dateien in /etc/nginx/conf.d ab.

Der zweite Punkt in dieser Familie heißt SELinux. Legen Sie eine Website in ein unübliches Verzeichnis oder verbinden Sie Nginx mit einer Anwendung im Hintergrund, kann SELinux den Zugriff blockieren. Dann sehen Sie einen Fehler 403 oder 502, obwohl die Dateirechte korrekt aussehen. Falls Sie noch eine Distribution suchen, hilft unser Vergleich Rocky Linux oder AlmaLinux.

Wann lohnt sich das offizielle Repository von nginx.org?

Wer Nginx installieren möchte, greift meist zuerst zu Paketen der Distribution, denn sie sind getestet und lange unterstützt. Allerdings bleiben sie manchmal auf einem älteren Zweig. Brauchen Sie eine neuere Funktion, können Sie das offizielle Linux Paketrepository von nginx.org nutzen. Es bietet zwei Zweige: stable und mainline. Für Ubuntu sehen die Schritte der offiziellen Seite zusammengefasst so aus:

sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring
curl -fsSL -o nginx_signing.key https://nginx.org/keys/nginx_signing.key
gpg --dearmor < nginx_signing.key | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null
gpg --dry-run --quiet --no-keyring --import --import-options import-show /usr/share/keyrings/nginx-archive-keyring.gpg

Vergleichen Sie den Fingerabdruck aus der letzten Ausgabe mit dem Wert auf der Seite zu den Linux Paketen von nginx.org. Stimmt er nicht überein, brechen Sie ab. Danach fügen Sie die Paketquelle hinzu und schließen die Installation ab:

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] https://nginx.org/packages/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list
sudo apt update
sudo apt install nginx

Die offizielle Seite empfiehlt außerdem eine Pinning Datei unter /etc/apt/preferences.d, damit apt die Pakete von nginx.org bevorzugt. In der RHEL Familie legen Sie stattdessen /etc/yum.repos.d/nginx.repo an. Da sich solche Details ändern, kopieren Sie die Befehle immer von der offiziellen Seite.

Paket der Distribution oder Paket von nginx.org: was passt besser?

Zunächst einmal: Beide Quellen sind vertrauenswürdig. Der eigentliche Unterschied liegt zwischen Aktualität und enger Einbindung in die Distribution. Die Tabelle fasst die Entscheidung auf Basis der offiziellen Dokumentation zusammen.

Kurz gesagt: Starten Sie mit dem Paket der Distribution, solange Sie kein bestimmtes Modul und keine neue Direktive brauchen. So erhalten Sie Sicherheitsupdates im selben Strom wie das restliche Betriebssystem.

Wie verwalten Sie den Nginx Dienst mit systemctl?

Auf aktuellen Linux Distributionen läuft Nginx als systemd Dienst. Fast alle täglichen Aufgaben erledigen Sie mit diesen Befehlen:

sudo systemctl start nginx      # starten
sudo systemctl stop nginx       # stoppen
sudo systemctl restart nginx    # komplett neu starten
sudo systemctl reload nginx     # Konfiguration ohne Verbindungsabbruch neu laden
sudo systemctl enable nginx     # beim Booten starten
sudo systemctl status nginx     # Status anzeigen

Der Unterschied zwischen restart und reload ist wichtig. Restart stoppt den Dienst und startet ihn neu, daher kann es eine kurze Unterbrechung geben. Reload lässt dagegen den Masterprozess die neue Konfiguration lesen, während alte Worker laufende Anfragen beenden. Nutzen Sie deshalb bei Konfigurationsänderungen reload.

Der Einsteigerleitfaden nennt zudem die Signale nginx -s reload, nginx -s quit und nginx -s reopen. Auf einem Server mit systemd bleibt der Dienststatus mit systemctl allerdings konsistenter. Nachdem Sie Nginx installieren, prüfen Sie außerdem mit systemctl is-enabled nginx, ob der Dienst nach einem Neustart von selbst zurückkommt.

Wo liegen die Konfigurationsdateien von Nginx?

Bei einer Installation per Paket liegt die Hauptdatei unter /etc/nginx/nginx.conf. Sie enthält den http Block mit globalen Einstellungen und die include Zeilen, die weitere Dateien einbinden. Die Ordnerstruktur im Überblick:

• /etc/nginx/nginx.conf: die Hauptdatei mit worker_processes, Ereigniseinstellungen und dem http Block.
• /etc/nginx/sites-available/: unter Debian und Ubuntu liegt hier jeder Serverblock in einer eigenen Datei.
• /etc/nginx/sites-enabled/: symbolische Links auf aktive Websites; Nginx liest nur diese.
• /etc/nginx/conf.d/: in der RHEL Familie und bei Paketen von nginx.org liegen hier die .conf Dateien.
• /etc/nginx/snippets/: unter Debian und Ubuntu kleine, wiederverwendbare Bausteine.

Die Syntax besteht zudem aus verschachtelten Blöcken. Im http Block stehen server Blöcke, und darin stehen location Blöcke. Jede Direktive endet mit einem Semikolon. Der häufigste Tippfehler ist also ein fehlendes Semikolon am Zeilenende. Ändern Sie die Hauptdatei möglichst wenig und halten Sie die Einstellungen jeder Website in eigenen Dateien. Das senkt zudem das Risiko von Konflikten bei Paketupdates.

Wie schreiben Sie Ihren ersten Serverblock?

Ein Serverblock entspricht dem virtuellen Host bei Apache. Als Beispieldomain nutzen wir deshalb example.com. Legen Sie zunächst das Verzeichnis an und speichern Sie dort eine einfache index.html:

sudo mkdir -p /var/www/example.com/html
sudo nano /etc/nginx/sites-available/example.com

Dann tragen Sie diesen Grundblock in die Datei ein:

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

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

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

Unter Debian und Ubuntu aktivieren Sie die Website über einen symbolischen Link. Anschließend testen Sie und laden neu:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

In der RHEL Familie schreiben Sie denselben Block in /etc/nginx/conf.d/example.com.conf. Einen symbolischen Link brauchen Sie dort nicht.

Was bedeuten die Direktiven im Serverblock?

Wenn Sie die Aufgabe jeder Zeile kennen, finden Sie Fehler viel schneller. Die Dokumentation des HTTP Kernmoduls von nginx.org listet Syntax und Standardwerte dieser Direktiven auf.

• listen: Adresse und Port, auf denen der Server lauscht. Der Parameter default_server leitet nicht zugeordnete Anfragen an diesen Block.
• server_name: die Domains, auf die dieser Block antwortet. Nginx behandelt den ersten Namen als Hauptnamen und versteht auch Platzhalter und reguläre Ausdrücke.
• root: das Verzeichnis, in dem Nginx nach Dateien sucht. Der Anfragepfad hängt sich an diesen Wert an.
• index: die Dateien, die Nginx der Reihe nach prüft, wenn jemand ein Verzeichnis aufruft.
• try_files: prüft Dateien nacheinander; fehlt jede davon, greift der letzte Parameter, etwa =404.

Ruft ein Besucher zum Beispiel /kontakt auf, sucht Nginx zuerst eine Datei mit diesem Namen und dann ein Verzeichnis. Findet er beides nicht, antwortet er schließlich mit 404. Bei Single Page Anwendungen setzen Sie den letzten Parameter auf /index.html, damit die Anwendung jede Route selbst übernimmt.

Wie funktionieren location Blöcke und statische Dateien?

Mit location Blöcken wenden Sie je nach Anfragepfad unterschiedliche Regeln an. Präfixe sind die einfachste Form. Blöcke mit Tilde arbeiten dagegen mit regulären Ausdrücken. Ein typisches Beispiel ist das Browser Caching für statische Dateien:

location ~* \.(css|js|png|jpg|jpeg|webp|svg|woff2)$ {
    expires 30d;
    access_log off;
}

location ~ /\.(?!well-known) {
    deny all;
}

Der erste Block setzt für diese Dateitypen beispielhaft eine Cachedauer von 30 Tagen. Tragen Ihre Dateinamen keine Versionskennung, wählen Sie eine kürzere Dauer. Der zweite Block sperrt außerdem versteckte Dateien wie .git oder .env. Den Ordner .well-known lässt er allerdings für die Prüfung durch Certbot offen.

Wie sich die Geschwindigkeit statischer Dateien auf Rankings auswirkt, lesen Sie in unserem Beitrag wie die Ladezeit SEO beeinflusst. Das Caching in Nginx ist also nur ein Baustein beim Messen und Verbessern der Ladezeit.

Wie verbinden Sie Nginx mit PHP FPM?

Nginx führt PHP Code nicht selbst aus. Stattdessen reicht er die Anfrage per FastCGI an den Dienst PHP-FPM weiter. Das Paket für Debian und Ubuntu bringt dafür ein fertiges Snippet mit. Daher genügt im Serverblock oft eine kurze Ergänzung:

index index.php index.html;

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Der Name der Socketdatei hängt von PHP Version und Distribution ab. Prüfen Sie deshalb den echten Pfad mit ls /run/php/ und passen Sie die Zeile fastcgi_pass an. Ein falscher Socketpfad gehört zu den häufigsten Ursachen für einen Fehler 502.

Bei Anwendungen wie WordPress oder Laravel ändern Sie die Zeile try_files im Block location / so, dass sie Anfragen an index.php weitergibt. Details für Laravel finden Sie in unserer Anleitung Laravel auf cPanel und VPS installieren. Anwendungen mit Node.js und Next.js brauchen dagegen einen Reverse Proxy; dazu gleich mehr.

Wie richten Sie ein SSL Zertifikat mit Certbot ein?

Let's Encrypt stellt kostenlose Zertifikate aus, die sich automatisch erneuern lassen. Certbot ist zudem der offizielle Client dafür. Die Anleitung von Certbot für Nginx empfiehlt das Snap Paket:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot
sudo certbot --nginx

Der letzte Befehl liest die Namen aus server_name, holt das Zertifikat und ergänzt Ihre Konfiguration um einen Block für Port 443. Soll Certbot Ihre Dateien nicht anfassen, nutzen Sie stattdessen certbot certonly --nginx. Danach testen Sie die Erneuerung:

sudo certbot renew --dry-run

Laut Dokumentation richtet das Paket einen Cronjob oder einen systemd Timer ein, der Zertifikate vor Ablauf erneuert. Warum SSL unverzichtbar ist, erklären wir im Beitrag Was ist ein SSL Zertifikat. Nach der Einrichtung prüfen Sie die Zertifikatskette von außen mit unserem SSL Check.

Warum sollten Sie jede Änderung mit nginx -t testen?

Ein einziges fehlendes Semikolon kann bei einem Neustart alle Websites lahmlegen. Testen Sie deshalb nach jeder Änderung zuerst die Syntax:

sudo nginx -t
sudo systemctl reload nginx

Ist alles in Ordnung, erscheinen die Meldungen "syntax is ok" und "test is successful". Bei einem Fehler nennt Nginx Datei und Zeilennummer, sodass Sie direkt dorthin springen. Ein reload mit fehlerhafter Datei behält die alte, funktionierende Konfiguration bei. Ein restart kann den Dienst dagegen gar nicht erst starten.

Bei vielen include Dateien gibt sudo nginx -T die zusammengeführte Konfiguration aus, die Nginx tatsächlich liest. Somit sehen Sie auf einen Blick, welche Datei welche Einstellung überschreibt. Außerdem zeigt nginx -v die Version und nginx -V die Build Optionen samt Modulen.

Kopieren Sie vor jeder Änderung zudem die aktuelle Datei. Eine Kopie mit Datum im Namen bringt Sie dann nach einem Fehler in Sekunden zurück. Auch Git eignet sich gut, um Konfigurationsdateien zu versionieren. Unser Team arbeitet nach einer einfachen Regel: ändern, testen, neu laden, im Browser prüfen.

Wo liegen die Logs von Nginx und wie lesen Sie sie?

Bei Installationen per Paket liegen die Standardlogs unter /var/log/nginx/access.log und /var/log/nginx/error.log. Haben Sie im Serverblock eigene Pfade gesetzt, schreibt die Website in ihre eigenen Dateien. Live verfolgen Sie die Logs mit diesen Befehlen:

sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/nginx/access.log
sudo journalctl -u nginx --since "1 hour ago"

Das Access Log hält jede Anfrage mit Statuscode und Clientdaten fest. Das Error Log zeigt fehlende Rechte, fehlende Dateien und Verbindungsprobleme zum Backend. Sehen Sie eine Fehlerseite, schauen Sie also zuerst ins Error Log. Dort steht die eigentliche Ursache meist im Klartext.

Logs wachsen allerdings mit der Zeit. Pakete der Distribution bringen in der Regel eine Einstellung für logrotate mit; trotzdem sollten Sie die Größe ab und zu prüfen. Denken Sie außerdem daran, dass Logs personenbezogene Daten wie IP Adressen enthalten. Legen Sie die Speicherdauer deshalb gemäß Ihren Pflichten aus der DSGVO fest.

Warum treten die Fehler 403, 404 und 502 auf und wie beheben Sie sie?

Diese drei Fehler begegnen Ihnen auf einem frischen Nginx Server am häufigsten. Jeder weist auf eine andere Ebene hin:

• 403 Forbidden: Nginx kann die Datei nicht lesen. Prüfen Sie Verzeichnisrechte, die Indexdatei und in der RHEL Familie den SELinux Kontext. Läuft eine WAF, hilft unser Beitrag ModSecurity und Fehler 403.
• 404 Not Found: Der Pfad in root stimmt nicht, die Datei fehlt oder try_files schickt die Anfrage an die falsche Stelle. Das Error Log zeigt den genauen Pfad, den Nginx gesucht hat.
• 502 Bad Gateway: Nginx erreicht das Backend nicht. Der Dienst PHP-FPM oder die Anwendung ist vielleicht gestoppt, oder Socketpfad und Port stimmen nicht.

Die vollständige Diagnose für 502 beschreiben wir im Beitrag 502 Bad Gateway: Ursachen und Lösung. Die Grundregel ist also einfach. Lesen Sie zuerst das Error Log. Prüfen Sie dann das Backend mit systemctl status. Kontrollieren Sie schließlich die Konfiguration mit nginx -T. Der Benutzer von Nginx braucht außerdem Ausführungsrechte auf jedem Verzeichnis im Pfad. Ein üblicher Startpunkt sind 644 für Dateien und 755 für Verzeichnisse.

Wie setzen Sie Sicherheitsheader und blenden die Version von Nginx aus?

Standardmäßig zeigt Nginx seine Version auf Fehlerseiten und im Antwortheader Server. Laut Dokumentation des Kernmoduls steht server_tokens per Standard auf on. Zum Abschalten ergänzen Sie im http Block diese Zeile:

server_tokens off;

Das Ausblenden der Version macht einen Server nicht allein sicher. Trotzdem liefern Sie automatischen Scannern weniger Informationen. Danach ergänzen Sie im Serverblock grundlegende Sicherheitsheader:

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
# Erst wenn HTTPS dauerhaft funktioniert, Beispielwert:
# add_header Strict-Transport-Security "max-age=31536000" always;

Ein Detail ist wichtig: Ein Block erbt add_header Direktiven von der höheren Ebene nur dann, wenn er selbst keine definiert. Setzen Sie also ein einziges add_header in einem location Block, fehlen dort alle Header von oben. Für Risiken auf Anwendungsebene lesen Sie auch unseren Beitrag zu den OWASP Top 10.

Welche Ports sollten Sie in der Firewall öffnen?

Ein Webserver braucht also nur die Ports 80 (HTTP) und 443 (HTTPS). Zusätzlich bleibt der SSH Port für die Verwaltung offen; alles andere schließen Sie nach außen. Unter Ubuntu bringt das Paket von Nginx fertige Anwendungsprofile für UFW mit:

sudo ufw app list
sudo ufw allow 'Nginx Full'
sudo ufw status

Das Profil Nginx Full öffnet sowohl 80 als auch 443. In der RHEL Familie nutzen Sie stattdessen firewalld:

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Erlauben Sie SSH immer, bevor Sie die Firewall aktivieren; sonst sperren Sie sich selbst aus. Für die Härtung von SSH folgen Sie unserer Anleitung Swap Datei erstellen und SSH absichern. Manche VPS Anbieter betreiben zudem eine eigene Netzwerkfirewall im Kundenpanel. Prüfen Sie daher beide Ebenen.

Was folgt danach: Reverse Proxy und Lastverteilung?

Sobald Nginx eine statische Website oder PHP ausliefert, stellen ihn viele Teams als Nächstes vor Anwendungen. Diesen Aufbau nennt man deshalb Reverse Proxy. Nginx lauscht auf 80 und 443 und leitet Anfragen per proxy_pass an eine Anwendung auf einem lokalen Port weiter. So verwalten Sie SSL und Komprimierung an einer Stelle.

Ein vollständiges Beispiel für Node.js zeigen wir in der Anleitung Node.js Deployment mit Nginx und systemd. Für Next.js lesen Sie unsere Anleitung zum VPS Deployment von Next.js. Details zum Reverse Proxy, zum Nginx Proxy Manager und zur Lastverteilung auf mehrere Server behandeln wir in den nächsten zwei Beiträgen dieser Reihe. Hier konzentrieren wir uns daher darauf, Nginx installieren und als grundlegenden Webserver betreiben zu können.

Wann sollten Sie das Nginx installieren lieber Ihrem Hoster überlassen?

Ehrlich gesagt muss nicht jeder seinen eigenen Webserver betreiben. Fühlen Sie sich auf der Kommandozeile unsicher oder fehlt Ihnen Zeit für regelmäßige Updates, ist Managed Hosting oder ein verwalteter VPS die sicherere Wahl. Schließlich birgt ein falsch eingestellter Server deutlich mehr Risiko als eine langsame Website.

In diesen Fällen empfehlen wir, die Aufgabe Ihrem Hoster oder einem erfahrenen Administrator zu überlassen:

• Die Website verarbeitet Zahlungen, Konten oder personenbezogene Daten und braucht eine Sicherheitsprüfung.
• Sie erwarten viel Traffic, mehrere Server oder strenge Anforderungen an die Verfügbarkeit.
• Niemand kann im Notfall kurzfristig auf den Server zugreifen.

Haben Sie noch keinen Hoster gewählt, beginnen Sie mit unserem Ratgeber Webhosting auswählen. Bei der Website selbst, ihrer Ladezeit und ihren Conversions unterstützt Sie unser Webdesign Service.

Welche Punkte gehören nach dem Nginx installieren auf die Checkliste?

Wenn Sie glauben, fertig zu sein, haken Sie die folgende Liste Punkt für Punkt ab. So werden kleine Lücken nicht zu Problemen auf der Live Website.

1. systemctl status nginx zeigt active (running), und der Dienst startet beim Booten.
2. nginx -t läuft fehlerfrei durch, und Sie übernehmen Änderungen per reload.
3. Die Domain zeigt auf die richtige IP, und die Adressen mit und ohne www führen zu einer einzigen URL.
4. HTTPS funktioniert, und der Testlauf von certbot renew klappt.
5. server_tokens steht auf off, und die grundlegenden Sicherheitsheader sind aktiv.
6. Versteckte Dateien sind gesperrt, und das Auflisten von Verzeichnissen ist aus.
7. In der Firewall sind nur SSH, 80 und 443 offen.
8. Das Error Log ist sauber, und Sie kennen die Ursache jedes Eintrags mit 403, 404 oder 502.
9. Regelmäßige Backups und ein Plan für den Rückweg stehen bereit.

Ist jeder Punkt erfüllt, ist das Nginx installieren abgeschlossen und Ihr Server bereit für echten Traffic. Danach können Sie zu Performancetests, Caching und Reverse Proxy übergehen. Unser Rat als Team: Nehmen Sie jede Änderung in kleinen Schritten vor und testen Sie nach jedem Schritt.