Nginx Reverse Proxy einrichten: Konfiguration und Nginx Proxy Manager

Was ist ein Nginx Reverse Proxy und wofür brauchen Sie ihn?

Ein Nginx Reverse Proxy ist eine vorgeschaltete Serverschicht, die Anfragen von Besuchern annimmt, an eine dahinterliegende Anwendung weiterreicht und die Antwort zurück an den Besucher schickt. Besucher sprechen also nur mit Nginx. Ihre Node.js App, Ihr Python Dienst oder Ihr Docker Container bleibt verborgen. So betreiben Sie mehrere Anwendungen sicher hinter einer IP Adresse.

Ein einfaches Bild hilft dabei. Auf Ihrem Server läuft eine Node.js App auf Port 3000 und ein Adminbereich auf Port 8080. Dann soll natürlich niemand Portnummern in die Adresszeile tippen. Stattdessen lauscht Nginx auf den Ports 80 und 443, prüft die angefragte Domain und reicht die Anfrage an die richtige Anwendung weiter. Das heißt: Ein Empfang an der Tür schickt jeden Gast in den passenden Raum.

In diesem Leitfaden klären wir zunächst den Begriff und den Unterschied zum Forward Proxy. Danach zeigen wir auf Basis der offiziellen Nginx Dokumentation proxy_pass, die Weitergabe von Headern, Timeouts und WebSocket Einstellungen. Zum Schluss geht es um Nginx Proxy Manager: Installation mit Docker, Zertifikate von Let's Encrypt und die Absicherung des Adminbereichs. Wir sind ein Team für digitales Marketing und Web, kein Hostinganbieter. Deshalb stützen wir jede technische Aussage auf offizielle Quellen.

Was unterscheidet einen Reverse Proxy von einem Forward Proxy?

Beide Begriffe beschreiben einen Server in der Mitte. Der Unterschied liegt also darin, für wen er arbeitet. Ein Forward Proxy arbeitet im Auftrag des Clients. Zum Beispiel gehen Mitarbeiter in einem Firmennetz über einen gemeinsamen Ausgang ins Internet. Die Zielseite sieht dann den Proxy, nicht den einzelnen Mitarbeiter.

Ein Reverse Proxy arbeitet dagegen im Auftrag des Servers. Besucher wissen nicht, wie viele Anwendungen dahinter laufen, welche Ports sie nutzen oder auf welcher Maschine sie liegen. Kurz gesagt: Der Forward Proxy verbirgt den Client, der Reverse Proxy verbirgt den Server.

Dieser Leitfaden behandelt die rechte Spalte. Denken Sie bei dem Wort Proxy im Folgenden also an eine Schicht vor Ihrer Website, nicht vor Ihren Besuchern.

Wann brauchen Sie einen Nginx Reverse Proxy?

Nicht jede Website braucht einen. Eine klassische WordPress Seite im Shared Hosting nutzt meist eine Proxyschicht, die der Anbieter ohnehin betreibt. Sobald Sie allerdings Ihren eigenen VPS verwalten, ist ein Nginx Reverse Proxy in diesen Fällen fast unverzichtbar:

• Eine IP, viele Apps: Blog, API und Adminbereich laufen auf einem Server, und jede Anwendung erhält eine eigene Domain oder Subdomain.
• SSL Terminierung: Nginx übernimmt die HTTPS Verschlüsselung. Die Anwendung dahinter muss sich daher nicht um Zertifikate kümmern.
• Caching und Kompression: Nginx hält häufig angefragte Antworten vor und entlastet so die Anwendung.
• Sicherheit und Abschirmung: Die Ports der Anwendungen bleiben nach außen geschlossen. Besucher sehen nur die Ports 80 und 443.
• Einfachere Wartung: Zieht eine App auf einen neuen Port oder in einen neuen Container um, ändern Sie nur die Proxyregel.

Die Verteilung von Last auf mehrere Server ist dagegen ein eigenes Thema. Load Balancing behandeln wir deshalb in einem separaten Beitrag. Hier bleiben wir beim Reverse Proxy auf einem einzelnen Server.

Was sollten Sie vor der Einrichtung vorbereiten?

Einige Grundlagen sollten bereits stehen. Sonst lässt sich bei einem Fehler kaum erkennen, ob das Problem in der Proxykonfiguration oder in der Infrastruktur darunter liegt.

1. Server und Betriebssystem: Eine aktuelle Linux Distribution und ein Benutzer mit sudo Rechten. Die ersten Schritte zeigt unser Leitfaden zur Ersteinrichtung von Ubuntu Server.
2. Nginx selbst: Ein laufendes Nginx aus dem Paketmanager Ihrer Distribution. Die Installation behandeln wir in einem eigenen Beitrag, daher wiederholen wir sie hier nicht.
3. DNS Eintrag: Der A Record (IPv4) oder AAAA Record (IPv6) Ihrer Domain zeigt auf den Server. Das prüfen Sie zunächst mit unserer DNS Abfrage.
4. Backend Anwendung: Ihre App lauscht nur auf einer lokalen Adresse wie 127.0.0.1:3000.
5. Firewall: Die Ports 80 und 443 sind offen, die Ports der Anwendungen geschlossen.

Möchten Sie zum Beispiel eine Node.js App als systemd Dienst betreiben, zeigt unser Leitfaden zum Node.js Deployment diese Vorbereitung Schritt für Schritt.

Wie schreiben Sie eine Nginx Reverse Proxy Konfiguration?

Das Herzstück jedes Nginx Reverse Proxy ist die Direktive proxy_pass. Sie legt konkret fest, wohin Nginx eine passende Anfrage schickt. Das folgende Beispiel leitet Anfragen für app.example.com an Port 3000 auf demselben Server weiter:

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        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;
    }
}

Speichern Sie die Datei im Konfigurationsverzeichnis Ihrer Distribution. Prüfen Sie dann die Syntax und laden Sie Nginx neu:

sudo nginx -t
sudo systemctl reload nginx

Schlägt der Test fehl, laden Sie nicht neu. Denn nginx -t nennt Datei und Zeile des Fehlers und lässt die laufende Konfiguration unberührt. Außerdem übernimmt reload neue Einstellungen, ohne offene Verbindungen zu trennen. Auf einer Live Website ist das daher die bessere Wahl als restart.

Was ändert der Schrägstrich am Ende von proxy_pass?

An dieser Stelle hängen viele fest. Laut der offiziellen Dokumentation des Nginx Proxy Moduls gilt Folgendes: Steht in proxy_pass eine URI, ersetzt Nginx den Teil der Anfrage, der zur location passt, durch diese URI. Fehlt die URI, reicht Nginx die Anfrage so weiter, wie der Client sie geschickt hat.

Ein konkretes Beispiel mit einem Block location /api/:

• Mit proxy_pass http://127.0.0.1:3000; landet eine Anfrage an /api/users im Backend als /api/users.
• Mit proxy_pass http://127.0.0.1:3000/; tauscht Nginx /api/ gegen / aus, und das Backend erhält /users.

Ein einziger Schrägstrich entscheidet also, ob Ihre App einen 404 Fehler liefert oder sauber antwortet. Definiert Ihre App ihre Routen selbst mit dem Präfix /api, wählen Sie die erste Form. Kennt sie das Präfix nicht, wählen Sie dagegen die zweite, denn sonst fehlt die Route. Laut Dokumentation lassen Sie die URI zudem weg, wenn die location einen regulären Ausdruck nutzt oder proxy_pass Variablen enthält. Testen Sie danach jedes Mal mehrere Pfade im Browser oder auf der Kommandozeile.

Warum sind die weitergegebenen Header so wichtig?

Standardmäßig setzt Nginx den Host Header der Anfrage an das Backend auf $proxy_host. Die App sieht also 127.0.0.1:3000 statt Ihrer Domain. Die offizielle Dokumentation nennt als Standardwerte Host $proxy_host und Connection close. Reagiert Ihre App je nach Domain unterschiedlich, entstehen so falsche Weiterleitungen.

Deshalb empfehlen wir, drei Header ausdrücklich zu setzen:

• Host $host: Gibt die Domain weiter, die der Besucher eingegeben hat. Anwendungen mit mehreren Domains und Frameworks mit absoluten Links brauchen das.
• X-Forwarded-For $proxy_add_x_forwarded_for: Hängt die IP des Besuchers an die Kette an. Fehlt der Header in der eingehenden Anfrage, entspricht die Variable einfach $remote_addr.
• X-Forwarded-Proto $scheme: Teilt der App mit, ob der Besucher HTTP oder HTTPS genutzt hat.

Gerade den letzten Header vergessen allerdings viele. Terminiert Nginx HTTPS, sieht die App eine einfache HTTP Anfrage. Ohne den Header leitet die App den Besucher erneut auf HTTPS um, und es entsteht eine endlose Schleife. Zudem nennt die Dokumentation eine wichtige Regel: Enthält eine location auch nur eine einzige proxy_set_header Zeile, erbt sie keine Header aus der übergeordneten Ebene. Folglich bündeln Sie alle Header entweder auf einer Ebene oder wiederholen den vollständigen Satz in jedem Block.

Wie testen Sie Ihren Nginx Reverse Proxy?

Prüfen Sie nach dem Laden der Konfiguration zunächst einiges auf der Kommandozeile, bevor Sie den Browser öffnen. So täuschen Sie weder Browsercache noch gespeicherte Weiterleitungen.

1. Kontrollieren Sie mit ss -tlnp, ob die App wirklich auf der lokalen Adresse lauscht.
2. Schicken Sie dann eine Anfrage direkt an das Backend. Antwortet curl -I http://127.0.0.1:3000 nicht, liegt das Problem in der App, nicht im Proxy.
3. Danach testen Sie dieselbe Anfrage über Nginx: curl -I -H "Host: app.example.com" http://127.0.0.1 zeigt ohne DNS, ob der richtige server Block greift.
4. Schließlich senden Sie eine HTTPS Anfrage an die echte Domain und lesen Statuscode und Weiterleitungsziel in den Antwortheadern.

Diese Reihenfolge grenzt die fehlerhafte Schicht schnell ein. Klappt etwa Schritt zwei, aber nicht Schritt drei, steckt der Fehler meist in der Zeile server_name oder proxy_pass. Prüfen Sie außerdem, ob der Wert von X-Forwarded-For in Ihren App Logs Ihre eigene IP zeigt.

Wie gelangt die echte Besucher IP zu Ihrer Anwendung?

Eine App hinter einem Reverse Proxy erhält ihre Verbindung von Nginx. Sie sieht daher immer 127.0.0.1 als Quelle. Nutzen Sie Besucher IPs für Statistik, Rate Limiting oder Sicherheitslogs, muss die App den Header X-Forwarded-For auswerten.

Allerdings ist hier Vorsicht nötig. Denn auch ein Client kann diesen Header in seine eigene Anfrage schreiben. Weisen Sie Ihre App deshalb an, dem Header nur dann zu vertrauen, wenn er von Proxyadressen stammt, die Sie kontrollieren. Genau dafür gibt es die Einstellung für vertrauenswürdige Proxys in Frameworks wie Laravel, Express und Django. Folgen Sie dabei konkret der Dokumentation Ihres Frameworks.

Steht vor Nginx noch eine weitere Schicht, etwa ein CDN oder ein zweiter Proxy, sieht auch Nginx selbst nicht die echte Adresse. Dann nutzen Sie die Direktiven set_real_ip_from und real_ip_header aus dem Modul ngx_http_realip_module:

set_real_ip_from 192.0.2.10;
real_ip_header X-Forwarded-For;

Die Adresse im Beispiel ist nur ein Platzhalter. Tragen Sie dort den echten Adressbereich der vorgelagerten Schicht ein. Ob Ihr Nginx das Modul enthält, sehen Sie in der Ausgabe von nginx -V. Somit kann niemand mit einem gefälschten Header unter fremder IP in Ihren Logs auftauchen.

Wann sollten Sie die Timeouts anpassen?

Laut offizieller Dokumentation liegen drei zentrale Timeouts standardmäßig bei 60 Sekunden. proxy_connect_timeout begrenzt den Verbindungsaufbau zum Backend. proxy_read_timeout begrenzt die Wartezeit zwischen zwei Lesevorgängen, proxy_send_timeout die Zeit zwischen zwei Schreibvorgängen.

Entscheidend ist folgendes Detail. Lese und Sendetimeout gelten für die Pause zwischen zwei Vorgängen, nicht für die gesamte Antwort. Ein fünfminütiger Download mit stetigem Datenfluss bricht also nicht ab. Dagegen landet eine Berichtsabfrage, die 70 Sekunden lang nichts liefert, mit den Standardwerten bei einem 504 Fehler.

location /berichte/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_connect_timeout 10s;
    proxy_read_timeout 180s;
    proxy_send_timeout 180s;
}

Im Beispiel erhöhen wir die Werte nur für den langsamen Pfad. Hohe Werte für die ganze Website binden sonst hängende Anfragen lange an Verbindungen. Zudem kann der Verbindungstimeout laut Dokumentation meist 75 Sekunden nicht überschreiten. Für lange Aufgaben ist eine Warteschlange im Hintergrund daher oft die bessere Lösung als ein größerer Timeout.

Wie richten Sie einen Nginx Reverse Proxy für WebSockets ein?

Livechat, Benachrichtigungen und Echtzeitdashboards nutzen WebSockets. Eine WebSocket Verbindung beginnt als HTTP Anfrage und wechselt dann über den Upgrade Header in eine dauerhafte Verbindung. Allerdings reichen die Header Upgrade und Connection laut der Nginx Dokumentation zu WebSockets nicht von selbst durch den Proxy. Sie müssen sie also ausdrücklich weitergeben.

http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }

    server {
        location /ws/ {
            proxy_pass http://127.0.0.1:3000;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_read_timeout 300s;
        }
    }
}

Der map Block sendet im Connection Header den Wert close, wenn der Client kein Upgrade anfragt. Somit bedient dieselbe location normale und WebSocket Anfragen. Laut offizieller Dokumentation ist HTTP 1.1 in neueren Nginx Versionen der Standard, ältere Versionen nutzten 1.0. Die Zeile proxy_http_version 1.1 ausdrücklich zu setzen, ist daher in jeder Version eine sichere Wahl.

Außerdem schließt Nginx laut Dokumentation die Verbindung, wenn das Backend 60 Sekunden lang keine Daten sendet. Dagegen hilft ein höherer proxy_read_timeout oder eine App, die regelmäßig Ping Frames schickt.

Wie funktionieren SSL Terminierung und Caching am Reverse Proxy?

SSL Terminierung bedeutet, dass die Schicht des Nginx Reverse Proxy den HTTPS Verkehr entschlüsselt. Das Zertifikat liegt nur bei Nginx, und der Verkehr zum Backend läuft innerhalb des Servers als einfaches HTTP. Sie installieren also kein Zertifikat in jeder App und steuern Verlängerungen an einer Stelle. Die Grundlagen erklärt unser Leitfaden zum SSL Zertifikat.

Let's Encrypt ist vor allem der verbreitetste Weg zu einem Zertifikat. Laut der Let's Encrypt Dokumentation zu den Prüfverfahren braucht die Prüfung HTTP-01 einen erreichbaren Port 80. Wildcard Zertifikate funktionieren dagegen nur mit DNS-01. Mehr dazu lesen Sie in unserem Beitrag zum Wildcard Zertifikat. Nach der Einrichtung testen Sie die Kette mit unserem SSL Check.

Beim Caching definieren Sie mit proxy_cache_path einen Speicherbereich auf der Festplatte und eine gemeinsame Speicherzone. Mit proxy_cache nutzen Sie diesen Bereich dann in einer location. Standardmäßig ist das Caching zudem aus. Seiten eingeloggter Nutzer zu cachen, kann Daten offenlegen. Cachen Sie deshalb nur Inhalte, die für alle gleich aussehen. Für einen umfassenderen HTTP Cache bietet unser Beitrag zu Varnish Cache einen anderen Ansatz.

Was ist Nginx Proxy Manager und für wen eignet er sich?

Nginx Proxy Manager (NPM) ist ein Open Source Projekt, mit dem Sie Nginx über eine Weboberfläche verwalten. Es läuft als Docker Container. Die offizielle Dokumentation nennt diese Hauptfunktionen: Weiterleitung von Domains, Umleitungen, Streams und 404 Hosts, kostenloses SSL über Let's Encrypt oder eigene Zertifikate, Zugriffslisten mit HTTP Basisauthentifizierung sowie Benutzerverwaltung mit Rechten und Auditlog.

NPM passt zu allen, die einige Dienste ohne eigene Konfigurationsdateien veröffentlichen möchten. Laufen zum Beispiel auf einem Heimserver oder kleinen VPS mehrere Apps in Docker, richten Sie Domain und Zertifikat für jede App mit wenigen Klicks ein. Fortgeschrittene können zudem eigene Nginx Einstellungen pro Host ergänzen.

Brauchen Sie dagegen komplexe Routingregeln, Feintuning bei hohem Traffic oder Konfigurationsdateien unter Git, bleiben handgeschriebene Nginx Dateien transparenter. Ist Docker neu für Sie, lesen Sie zunächst unseren Docker Leitfaden.

Wie installieren Sie Nginx Proxy Manager mit Docker?

Die offizielle Installationsseite von Nginx Proxy Manager empfiehlt, nach der Installation von Docker und Docker Compose mit einer einzigen Compose Datei zu starten. Laut Dokumentation dient Port 80 für öffentliches HTTP, Port 443 für öffentliches HTTPS und Port 81 für die Verwaltungsoberfläche. Wir empfehlen eine Variante, die den Adminport von Anfang an nur dem Server selbst öffnet:

services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
      - '127.0.0.1:81:81'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

Speichern Sie die Datei als docker-compose.yml in einem leeren Ordner und starten Sie dort diesen Befehl:

docker compose up -d

Beim ersten Start erzeugt NPM Schlüssel und Datenbank. Deshalb kann die Oberfläche einige Minuten brauchen. Laut Dokumentation ist SQLite im Ordner data die Standarddatenbank; MySQL, MariaDB oder PostgreSQL lassen sich ebenso anbinden. Die offizielle Installationsseite zeigt im Beispiel ein festes Versionstag. Für den Produktivbetrieb empfehlen wir ebenfalls ein festes Tag statt latest, damit Sie Updates selbst planen. Für eine Oberfläche zur Containerverwaltung passt unser Portainer Leitfaden gut zu diesem Setup.

Welche Sicherheitsschritte gehören zur ersten Anmeldung?

Da der Adminport nur auf 127.0.0.1 lauscht, erreichen Sie das Panel nicht direkt von außen. Öffnen Sie stattdessen von Ihrem Rechner aus einen SSH Tunnel:

ssh -L 8181:127.0.0.1:81 user@203.0.113.10

Rufen Sie danach http://127.0.0.1:8181 im Browser auf. Je nach Version fordert das Panel Sie beim ersten Start auf, ein Adminkonto anzulegen, oder es öffnet sich mit einem Standardkonto und bittet um neue Zugangsdaten. In beiden Fällen gilt:

1. Hinterlegen Sie Ihre eigene E-Mail und ein langes, einzigartiges Passwort. Lassen Sie keine Standardzugangsdaten bestehen.
2. Arbeiten mehrere Personen im Panel, erhält jede ein eigenes Konto mit nur den nötigen Rechten.
3. Nehmen Sie die Ordner data und letsencrypt in Ihren Backupplan auf. Dort liegen Hostdefinitionen und Zertifikate.
4. Lesen Sie vor jedem Update die offiziellen Release Notes und legen Sie zuerst ein Backup an.

Diese Schritte wirken klein. Übernimmt jedoch jemand das Panel, kann er den Verkehr all Ihrer Domains beliebig umleiten. Kurz gesagt: Das NPM Panel ist eine der wertvollsten Türen Ihres Servers.

Wie fügen Sie einen Proxy Host hinzu und erhalten SSL von Let's Encrypt?

Im Panel öffnen Sie Hosts, dann Proxy Hosts, und legen einen neuen Eintrag an. Der Reiter Details enthält vier Kernfelder: Domainname, Schema (http oder https), Zielhost oder IP und Zielport. Im selben Reiter aktivieren Sie bei Bedarf die WebSocket Unterstützung und die Option gegen gängige Angriffsmuster.

Achten Sie hier auf das Docker Netzwerk. NPM läuft in einem Container, daher meint 127.0.0.1 dort den NPM Container und nicht Ihren Server. Am saubersten bringen Sie NPM und Ihre App in dasselbe Docker Netzwerk. Legen Sie zunächst ein gemeinsames Netzwerk an:

docker network create proxy-net

Danach ergänzen Sie es als externes Netzwerk am Ende beider Compose Dateien:

networks:
  default:
    name: proxy-net
    external: true

Nun tragen Sie im Zielfeld den Containernamen statt einer IP ein, dazu den Port der App innerhalb ihres Containers. Im Reiter SSL fordern Sie ein neues Zertifikat von Let's Encrypt an und aktivieren erzwungenes HTTPS sowie HTTP/2. Für die Prüfung HTTP-01 muss der DNS Eintrag der Domain auf diesen Server zeigen, und Port 80 muss von außen erreichbar bleiben.

Wofür sind Zugriffslisten (Access Lists) gut?

Zugriffslisten legen fest, wer einen Proxy Host erreichen darf. In NPM kombinieren Sie zwei Arten von Beschränkungen. Die erste ist die HTTP Basisauthentifizierung mit Benutzername und Passwort. Die zweite sind Regeln zum Erlauben und Sperren nach IP Adresse oder Adressbereich.

So öffnen Sie zum Beispiel ein internes Reporting nur für die feste IP Ihres Büros. Oder Sie schützen eine Testumgebung mit einem einfachen Passwort vor Suchmaschinen und neugierigen Besuchern. Nach dem Anlegen wählen Sie die Liste einfach in den Einstellungen des passenden Proxy Hosts aus.

Trotzdem sollte die Basisauthentifizierung nie Ihre einzige Verteidigungslinie sein. Ein Passwort ohne Verschlüsselung ist im Netzwerk lesbar, also kombinieren Sie Zugriffslisten immer mit SSL. Halten Sie außerdem das eigene Login und Rechtesystem Ihrer App stark. Wollen Sie Brute Force Versuche auf Serverebene stoppen, ergänzt unser Fail2ban Leitfaden eine sinnvolle Schicht.

Warum ist es riskant, den Adminport 81 ins Internet zu öffnen?

Die Compose Datei im offiziellen Beispiel veröffentlicht Port 81 auf allen Netzwerkschnittstellen. Hängt Ihr Server direkt am Internet, ist die Anmeldeseite des Panels damit öffentlich. Zudem läuft dieser Port standardmäßig über einfaches HTTP, die Zugangsdaten fließen also unverschlüsselt.

Ein weiteres Detail übersehen viele. Die offizielle Docker Dokumentation zu Paketfilterung und Firewalls beschreibt, dass Docker den Verkehr zu veröffentlichten Containerports umleitet, bevor die Regeln von ufw greifen. Der Satz „ich habe Port 81 mit ufw geschlossen“ garantiert also nicht, dass der Port wirklich zu ist. Wählen Sie daher einen dieser Wege:

• Binden Sie den Port in der Compose Datei an 127.0.0.1 und erreichen Sie das Panel per SSH Tunnel.
• Veröffentlichen Sie das Panel als eigenen Proxy Host unter Ihrer Domain, erzwingen Sie SSL und beschränken Sie den Zugriff per Zugriffsliste auf Ihre IP.
• Geben Sie den Zugang zum Panel nur über ein VPN frei.

Prüfen Sie danach in jedem Fall aus einem anderen Netz, ob der Port von außen tatsächlich geschlossen ist.

Manuelle Nginx Konfiguration oder Nginx Proxy Manager: Was passt besser?

Beide Wege nutzen denselben Motor; der Unterschied liegt in der Verwaltung. Die folgende Tabelle fasst die wichtigsten Kriterien zusammen:

In der Praxis nutzen viele Teams beides in verschiedenen Umgebungen. Sie testen zum Beispiel mit NPM auf einem Stagingserver und betreiben in der Produktion versionierte Nginx Dateien. Suchen Sie eine App Plattform auf dem eigenen Server, bietet unser Coolify Leitfaden eine dritte Option.

Welche Fehler passieren beim Reverse Proxy am häufigsten?

Meldet Ihr Nginx Reverse Proxy einen Fehler, schauen Sie zuerst in das Fehlerlog von Nginx. Meist steht die Ursache dort klar beschrieben. Die häufigsten Fälle im Überblick:

• 502 Bad Gateway: Nginx erreicht das Backend nicht. Die App läuft nicht, lauscht auf dem falschen Port, oder die Namensauflösung im Docker Netzwerk scheitert.
• 504 Gateway Timeout: Der Lesetimeout lief ab, bevor das Backend antwortete. Verlagern Sie die lange Aufgabe in den Hintergrund oder erhöhen Sie den Wert nur für diesen Pfad.
• Endlose Weiterleitungen: Der Header X-Forwarded-Proto fehlt, oder die App vertraut dem Proxy nicht.
• Mixed Content Warnungen: Die App erzeugt HTTP Links auf einer HTTPS Seite. Prüfen Sie also erneut, wie das Schema bei der App ankommt.
• Alle Besucher mit derselben IP: Nginx gibt X-Forwarded-For nicht weiter, oder die App liest den Header nicht.
• WebSockets brechen ab: Die Upgrade Header fehlen, oder der Lesetimeout ist zu kurz.

Nutzen Sie diese Liste als Prüfreihenfolge. Zuerst die Verbindung, dann die Header, zuletzt die Timeouts. So vermeiden Sie neue Probleme durch zufällige Änderungen.

Wann überlassen Sie diese Aufgabe besser Ihrem Hoster oder Fachleuten?

Ehrlich gesagt muss nicht jeder seinen eigenen Nginx Reverse Proxy betreiben. Liegt Ihre Website im Shared Hosting oder auf einer verwalteten Plattform, betreibt Ihr Anbieter diese Schicht bereits. Ein eigenes Nginx funktioniert dort oft gar nicht und kann zudem Ihren Supportanspruch gefährden.

In diesen Fällen empfehlen wir, die Aufgabe dem Anbieter oder einem erfahrenen Systemadministrator zu überlassen:

• Auf dem Server läuft eine App mit Zahlungen, Gesundheitsdaten oder personenbezogenen Daten.
• Jede Minute Ausfall bedeutet echten Umsatzverlust.
• Sie fühlen sich mit SSH, Firewalls und Logs nicht sicher.

Möchten Sie die Infrastruktur gemeinsam mit Ihrer eigenen Anwendung planen, unterstützt Sie unsere individuelle Softwareentwicklung dabei, die Architektur von Anfang an richtig aufzusetzen. Zusammengefasst: Ein Reverse Proxy ist ein starkes Werkzeug, bringt aber auch Verantwortung mit sich.