nginx und Apache in Plesk: den Anfrageweg verstehen

Eine Anfrage hat mehrere mögliche Stationen

Im Browser wirkt eine Website wie ein einzelner Dienst. Auf dem Server kann der Aufruf jedoch mehrere Stationen passieren. Ein äußerer Proxy nimmt die Verbindung entgegen, ein Webserver wählt den Host, ein weiterer Dienst verarbeitet Regeln und PHP erzeugt den Inhalt. Ein Cache kann vorher antworten und Teile dieses Weges überspringen. Deshalb ist die Frage nach nginx oder Apache oft zu grob. Für den Betrieb zählt, wo eine konkrete Anfrage endet. Eine Bilddatei, eine WordPress Detailseite und ein Login können auf derselben Domain verschiedene Pfade nutzen. Das erklärt, warum eine Änderung an einer Ebene nur einen Teil der Website betrifft.

Die Plesk Dokumentation zu Apache mit nginx beschreibt nginx als vorgelagerten Webserver in dieser Kombination. Je nach Konfiguration werden Anfragen weitergegeben oder direkt bedient. Für einen Betreiber folgt daraus eine einfache Regel: Erst den tatsächlichen Modus aufnehmen, dann über Regeln und Fehler urteilen. Ein Serverheader ist dafür nur ein Hinweis. Er kann von der äußersten Ebene stammen und sagt wenig darüber aus, wer den Inhalt erzeugt hat. Eine dokumentierte Konfiguration und gezielte Vergleichsaufrufe liefern den belastbareren Zusammenhang zwischen Anfrage und Verarbeitung.

Die drei wichtigsten Wege unterscheiden

Bei einer statischen Datei kann nginx selbst antworten. Apache und PHP sehen diesen Aufruf dann möglicherweise gar nicht. Eine klassische dynamische Anfrage kann dagegen von nginx an Apache gelangen und von dort an FPM übergeben werden. Ein weiterer Modus verbindet nginx direkt mit FPM. Alle drei Wege können für Besucher ähnlich aussehen, aber die zuständigen Regeln ändern sich. Wenn ein Schutz nur in Apache eingerichtet ist und eine Datei direkt durch nginx ausgeliefert wird, muss geprüft werden, ob dieser Schutz dort ebenfalls gilt. Diese Prüfung ist besonders für Downloads, Medien und vorbereitete Vorschauseiten wichtig, die nicht nur aus PHP bestehen.

Auch ein vorgeschalteter Cache verändert die Beobachtung. Eine erfolgreiche Antwort aus dem Cache kann einen Fehler in PHP verdecken. Umgekehrt kann ein altes Cacheobjekt eine bereits korrigierte Weiterleitung noch zeigen. Prüfen Sie deshalb, aus welcher Ebene die Antwort stammt und ob ein frischer dynamischer Weg erreichbar ist. Nutzen Sie dafür die in Ihrer Umgebung vorgesehenen Diagnosewege. Ein zufälliger Suchparameter ist keine zuverlässige Garantie für einen Cache Bypass, weil manche Systeme ihn ignorieren oder getrennt speichern. Beschreiben Sie im Prüfbericht, ob der Aufruf regulär, direkt zum Ursprung oder bewusst ohne Cache erfolgte. Dann bleiben die Ergebnisse später richtig einzuordnen.

htaccess gehört zu Apache

Eine htaccess Datei ist kein allgemeines Regelwerk für alle Webserver. Die Apache Dokumentation zu htaccess erklärt ihren Einsatz für verzeichnisbezogene Konfiguration. Ob eine Direktive dort wirksam ist, hängt zudem von der zulässigen Überschreibung in der Hauptkonfiguration ab. Ein vorhandener Dateiname belegt daher noch keine Wirkung. Bei einem direkt von nginx verarbeiteten Weg werden diese Apache Regeln nicht ausgewertet. Das betrifft unter anderem Weiterleitungen und Zugriffsschutz. Prüfen Sie zuerst, ob die fragliche Anfrage Apache überhaupt erreicht, bevor Sie die Datei mehrfach ändern und aus einem unveränderten Ergebnis auf eine falsche Syntax schließen.

Beim Umstieg auf direkte Verarbeitung durch nginx müssen nötige Regeln in der passenden Konfiguration abgebildet werden. Dabei geht es nicht darum, jede alte Zeile mechanisch zu übertragen. Manche Regeln sind überholt, doppelt oder beziehen sich auf eine frühere Anwendung. Sammeln Sie stattdessen die gewünschte Wirkung: Welche Adresse soll wohin führen, welche Dateien müssen gesperrt bleiben und welche URLs braucht die Anwendung? Testen Sie diese Fälle nach dem Umbau. Die Plesk Beschreibung der PHP Handler benennt die Grenze zwischen Apache und nginx ausdrücklich. Der Umbau ist dadurch ein eigener Änderungsschritt mit eigener Abnahme.

Hostwahl und TLS vor dem Inhalt prüfen

Noch bevor PHP startet, muss der richtige virtuelle Host ausgewählt sein. Bei HTTPS gehört der angefragte Name bereits zur Auswahl des Zertifikats. Eine direkte Anfrage an eine Serveradresse kann deshalb ein anderes Ergebnis liefern als der normale Aufruf über die Domain. Wenn Sie den Ursprung gezielt testen, erhalten Sie den Domainnamen für Host und TLS Namensprüfung und legen nur die Zieladresse fest. So prüfen Sie die richtige Website am gewählten Ziel. Eine erfolgreiche Verbindung zum falschen Standardhost ist kein Nachweis für die Anwendung. Unser TLS Ratgeber erläutert diese Trennung von Zertifikatszuordnung und erfolgreicher Inhaltsauslieferung.

Prüfen Sie außerdem Hauptdomain und www getrennt. Eine Weiterleitung kann auf der einen Adresse korrekt sein und auf der anderen fehlen. Dasselbe gilt für IPv4 und IPv6. Wenn beide Namen auf mehrere Adressen zeigen, muss jeder veröffentlichte Weg den passenden Host erreichen. Ein Fehler nur über eine Adressfamilie kann für Besucher zeitweise verborgen bleiben, weil ihr Client den anderen Weg nutzt. Für die technische Abnahme werden diese Pfade daher bewusst erzwungen. Die Prüfung von A und AAAA zeigt, wie Sie Veröffentlichung und tatsächliche Verbindung auseinanderhalten und später als getrennte Belege dokumentieren.

Weiterleitungen mit echten Beispielen abnehmen

Eine Weiterleitung sollte nicht nur die Startseite korrekt behandeln. Nutzen Sie einen tiefen Pfad mit einem harmlosen Suchparameter und prüfen Sie Ziel, Status und Erhalt der benötigten Bestandteile. Eine Regel, die jede Anfrage auf die Hauptseite lenkt, kann beim kurzen Browserbesuch zunächst gut aussehen und trotzdem alle gespeicherten Detailadressen zerstören. Achten Sie auch auf Ketten zwischen HTTP, HTTPS, www und der Hauptdomain. Mehrere Ebenen können dieselbe Aufgabe übernehmen und sich gegenseitig erneut auslösen. Dokumentieren Sie daher, welche Ebene die Hauptadresse festlegt und welche anderen Regeln bewusst entfallen. Ein klarer Besitzer der Weiterleitung reduziert widersprüchliche Konfiguration.

Bei Anwendungen hinter einem Proxy ist die Sicht auf das ursprüngliche Protokoll wichtig. Wenn die Anwendung ihren Aufruf als HTTP wahrnimmt, obwohl der Besucher HTTPS nutzt, kann sie eine erneute HTTPS Weiterleitung erzeugen. Die nötigen Angaben zwischen den Ebenen dürfen jedoch nur von vertrauenswürdigen Proxys übernommen werden. Ein beliebig vom Besucher gesetzter Header ist kein verlässlicher Beleg. Lassen Sie die dafür vorgesehene Konfiguration des Webservers prüfen und ändern Sie nicht pauschal Anwendungscode, bis eine Schleife scheinbar verschwindet. Die Ursache lässt sich meist am dokumentierten Anfrageweg und an der Weiterleitungskette eingrenzen. Der endgültige Test erfolgt danach über den normalen Besuchspfad.

Logs jeder Ebene zusammen lesen

Das äußere Zugriffslog zeigt häufig den Status, den der Besucher erhalten hat. Ein inneres Fehlerlog kann den Grund nennen, zum Beispiel ein nicht erreichbares Backend oder einen ungültigen Skriptpfad. Diese Informationen gehören zusammen, sind aber nicht austauschbar. Suchen Sie mit Host, Uhrzeit und Pfad. Wenn die Umgebung eine eindeutige Anfragekennung unterstützt, kann sie die Zuordnung verbessern. Prüfen Sie trotzdem die Zeitbasis, weil Dienste mit abweichender Zeitzone sonst scheinbar verschiedene Ereignisse zeigen. Ein enges gemeinsames Zeitfenster ist besser als eine große Sammlung zufälliger Fehlerzeilen, die aus verschiedenen Websites und langen Zeiträumen stammen.

Eine fehlende Zeile kann ebenfalls ein Hinweis sein. Wenn eine statische Datei im nginx Log erscheint und nicht im Apache Log, kann das zum vorgesehenen direkten Weg passen. Daraus folgt aber nicht automatisch ein Fehler. Umgekehrt kann ein schwerer dynamischer Aufruf fehlen, weil ein Cache bereits geantwortet hat. Prüfen Sie deshalb die erwartete Station statt jede Ebene auf denselben Eintrag festzulegen. Die Diagnosefrage lautet: Wo sollte diese Anfrage in der aktuellen Konfiguration sichtbar sein? Erst wenn eine erwartete Station fehlt, untersuchen Sie Routing, Cache und Hostwahl. So bleibt die Interpretation an den tatsächlichen Aufbau gebunden und setzt keine beliebige Standardarchitektur voraus.

Ein kontrollierter Vergleich macht den Pfad sichtbar

Für eine kleine Abnahme reichen mehrere bewusst gewählte Aufrufe. Nutzen Sie eine bekannte statische Datei, eine reguläre Inhaltsseite, eine nicht vorhandene URL und eine geschützte Funktion. Prüfen Sie Status, Inhalt und passende Logeinträge. In einer Vorschau kommt ein unangemeldeter Abruf eines Bildes hinzu, um die Schutzgrenze zu testen. Verwenden Sie keine Datei mit vollständigen Systemdaten als öffentliches Diagnoseziel. Eine harmlose Testdatei mit klar erkennbarem Inhalt genügt für viele Fragen. Entfernen Sie sie danach wieder, falls sie nur für die Prüfung angelegt wurde. Halten Sie dabei fest, welche Adresse und welcher Modus tatsächlich getestet wurden.

Dieser Vergleich liefert keine allgemeine Leistungsbewertung. Eine schnelle statische Antwort beweist nicht, dass PHP unter Last ausreichend Kapazität hat. Eine langsame Detailseite beweist umgekehrt nicht, dass der vorgelagerte Webserver ungeeignet ist. Für eine Leistungsaussage benötigen Sie einen definierten Ablauf und passende Messungen. Im Betrieb ist der Vergleich zunächst eine Landkarte: Er zeigt, welche Station beteiligt ist und wo die nächste Prüfung sinnvoll ansetzt. Bei einem FPM Engpass lesen Sie anschließend den FPM Diagnoseablauf. Bei einem Cachefehler wechseln Sie zur Prüfung von Regeln, Varianten und Invalidierung. Die Trennung spart unnötige Umbauten.

Konfigurationen in Plesk wartbar verändern

Plesk verwaltet Teile der Webserverkonfiguration selbst. Eine direkte Änderung an einer erzeugten Datei kann bei einem späteren Vorgang überschrieben werden. Nutzen Sie daher die vorgesehenen domainspezifischen Felder oder den dokumentierten Erweiterungsweg Ihrer Umgebung. Klären Sie bei fehlenden Rechten, welche Einstellung der Anbieter setzen kann und auf welchen Umfang sie wirkt. Speichern Sie vor einer Änderung den alten Wert und prüfen Sie die neue Konfiguration, bevor sie übernommen wird. Der erlaubte Weg hängt von Rolle und Host ab. Eine Anleitung für Administratoren ist keine Zusage, dass derselbe Schalter für einen Kunden in einem bestimmten Abo verfügbar ist.

Vermeiden Sie Regeln, die für eine Domain gedacht sind und unbemerkt auf alle Websites wirken. Gerade Header, Zeitgrenzen und Zugriffsschutz können in globalen Dateien schnell einen größeren Umfang bekommen. Eine domainspezifische Lösung ist leichter zu prüfen und zurückzunehmen. Wenn eine globale Änderung unvermeidbar ist, gehört sie in die Verantwortung des Hostbetriebs und braucht eine breitere Abnahme. Für den einzelnen Betreiber bleibt der Auftrag konkret: gewünschte Wirkung, betroffene URLs, aktueller Weg und Testfälle liefern. Der Ratgeber zu Zuständigkeiten hilft, diese Grenze zwischen Websitekonfiguration und allgemeinem Serverbetrieb klar zu beschreiben.

Eine brauchbare Dokumentation passt auf eine Seite

Die Dokumentation kann als einfache Folge aufgebaut sein: Domain und Adressen, äußerer Dienst, Weiterleitung, statische Verarbeitung, dynamischer Handler, Cache und Logquellen. Daneben stehen die zuständige Person und die zuletzt geprüften Testfälle. Nach einem Handlerwechsel wird diese Folge aktualisiert. Das ist kein Selbstzweck. Im Vorfall verhindert sie, dass ein Team htaccess Regeln untersucht, obwohl die Anfrage nie Apache erreicht, oder dass PHP neu gestartet wird, obwohl nur eine äußere Zertifikatszuordnung falsch ist. Eine kleine Grafik kann die Folge gut erklären, sofern sie den tatsächlichen oder ausdrücklich beispielhaften Aufbau kennzeichnet und keine erfundene Infrastruktur als Istzustand zeigt.

Wenn der Pfad bekannt ist, lassen sich Änderungen besser begrenzen. Schutz wird auf jeder betroffenen Ebene geprüft, Weiterleitungen erhalten einen eindeutigen Besitzer und Logs beantworten konkrete Fragen. Ein späterer Anbieterwechsel wird ebenfalls leichter, weil die benötigte Wirkung unabhängig von einzelnen Dateinamen beschrieben ist. nginx und Apache zu verstehen heißt im Betrieb, den Weg einer bestimmten Anfrage belegen zu können. Das ist wertvoller als eine pauschale Entscheidung für den vermeintlich schnelleren Namen. Es schafft einen verständlichen Zusammenhang zwischen Konfiguration, sichtbarem Ergebnis und der Person, die eine Störung an der passenden Stelle beheben kann.