Ein Forward-Proxy handelt im Auftrag von Clients, die ausgehende Anfragen stellen. Ein Reverse-Proxy handelt im Auftrag von Servern, die eingehende Anfragen empfangen. Bei der Entscheidung zwischen Forward-Proxy und Reverse-Proxy sollten Sie zunächst feststellen, wessen Verkehr Sie kontrollieren möchten: die Person oder Anwendung, die eine Anfrage stellt, oder die Website, die sie empfängt.
Beide sind Vermittler, und beide können Anfragen weiterleiten. Ihre Namen beschreiben ihre Rolle in der Architektur, nicht ein Versprechen über Sicherheit, Anonymität oder Leistung. Ein Website-Gateway wird nicht automatisch zu einem Dienst für ausgehendes Browsing, und der Kauf eines ausgehenden Proxys veröffentlicht Ihre Anwendung nicht für Besucher.
TL;DR
- Verwenden Sie einen Forward-Proxy, wenn ein Client einen definierten ausgehenden Pfad oder Zugangspolitik benötigt.
- Verwenden Sie einen Reverse-Proxy, wenn Besucher einen Einstiegspunkt zu Anwendungen benötigen, die Sie betreiben.
- Authentifizierung, Verschlüsselung, Caching und Protokollierung hängen von der tatsächlichen Konfiguration ab, nicht nur vom Proxy-Label.
- Beide Rollen können in einem System existieren, haben jedoch separate Eigentümer, Anmeldeinformationen und Fehlermodi.
- Ein Wohn-, ISP- oder Rechenzentrum-Label beschreibt ein Netzwerkangebot; es ersetzt nicht die Unterscheidung zwischen Forward und Reverse.
Der Unterschied in einer Tabelle
| Frage | Forward-Proxy | Reverse-Proxy |
|---|---|---|
| Für wen handelt es? | Ein Client oder eine Gruppe von Clients | Ein Server oder eine Gruppe von Servern |
| Typischer Anfragepfad | Anwendung → Proxy → Ziel | Besucher → Proxy → Anwendung |
| Wer wählt es normalerweise aus? | Client-Betreiber oder Netzwerkadministrator | Website- oder Dienstbetreiber |
| Was ist das unmittelbare Ziel? | Kontrolle oder Routen von ausgehendem Zugriff | Empfangen und Routen von eingehendem Zugriff |
| Typische Authentifizierungsfrage | Darf dieser Client den Proxy verwenden? | Darf dieser Besucher auf diese Anwendung zugreifen? |
| Gemeinsame betriebliche Bedenken | Endpunktzugriff, Anmeldeinformationen und ausgehende Richtlinien | Upstream-Gesundheit, Routing, Zertifikate und Ursprungszugriff |
| Was bietet es nicht automatisch? | Ein öffentlicher Einstiegspunkt für Ihre eigene Website | Eine andere ausgehende Identität für nicht verwandte Browserverkehre |
Dies sind typische Rollen und keine Einschränkungen für ein bestimmtes Softwarepaket. Ein fähiges Gateway kann mehrere Funktionen unterstützen, aber jede Funktion benötigt dennoch eine explizite Konfiguration. Die MDN-Übersicht über Proxy-Server unterscheidet zwischen weiterleitenden Vermittlern und Gateways im HTTP-Anfragepfad.
Wie ein Forward-Proxy funktioniert
Stellen Sie sich eine Reporting-Anwendung vor, die eine autorisierte Anfrage an einen externen Dienst stellt. Anstatt sich direkt zu verbinden, sendet sie die Anfrage über einen konfigurierten Forward-Proxy. Der Proxy stellt die nächste Verbindung her und gibt die Antwort über denselben logischen Pfad zurück.
Der Client-Betreiber möchte möglicherweise eine zentrale ausgehende Richtlinie, einen kontrollierten Netzwerkpfad oder eine unterstützte Möglichkeit für eine Anwendung, ein Ziel zu erreichen. Das genaue Ergebnis hängt vom Protokoll, der Proxy-Unterstützung des Clients und der Konfiguration des Anbieters ab. Einige Anwendungen haben ihre eigenen Proxy-Einstellungen; andere erben System- oder Umgebungs Einstellungen.
Die wichtige betriebliche Frage ist, ob die beabsichtigte Anwendung tatsächlich den Proxy verwendet. Eine Änderung einer Einstellung in einem Tool beweist nicht, dass jeder Prozess auf dem Computer ihr folgt. Ein Hintergrunddienst, ein Browser und ein Kommandozeilen-Client können unterschiedliche effektive Konfigurationen haben.
Ein Forward-Proxy garantiert auch nicht, dass das Ziel keine anderen identifizierenden Informationen sieht. Anfragen können Anmeldeinformationen, Cookies und Anwendungsdaten enthalten. Wählen Sie einen Pfad für ein legitimes technisches Bedürfnis und bewerten Sie die Datenverarbeitung getrennt von der Adresse, die für die Netzwerkverbindung verwendet wird.
Beispiel: Eine geplante Datenintegration
Betrachten Sie eine hypothetische Integration, die jeden Morgen erlaubte Lieferantendaten abruft. Ihr Betreiber möchte, dass Anfragen über einen dokumentierten Endpunkt ausgehen. Der Betreiber konfiguriert den HTTP-Client der Integration, speichert die Proxy-Anmeldeinformationen getrennt vom Lieferanten-API-Token und überprüft sowohl das Routing als auch das Anwendungs Verhalten.
Die Proxy-Anmeldeinformationen beantworten, ob die Integration den Vermittler verwenden kann. Das Lieferanten-Token beantwortet, ob es die Daten des Lieferanten lesen kann. Ein funktionierender Proxy gewährt nicht die zweite Berechtigung. Diese Verantwortlichkeiten getrennt zu halten, erleichtert die Diagnose von Authentifizierungsfehlern erheblich.
Wie ein Reverse-Proxy funktioniert
Stellen Sie sich nun eine öffentliche Website mit einer Anwendung vor, die auf einem privaten Dienstport läuft. Besucher verbinden sich mit der Eingangstür der Website. Ein Reverse-Proxy empfängt diesen Verkehr und leitet ihn an die konfigurierte Upstream-Anwendung weiter, bevor er die Antwort der Anwendung zurückgibt.
Der Betreiber der Website wählt das Upstream und kontrolliert den Einstiegspunkt. Je nach Design kann der Reverse-Proxy die TLS-Beendigung, das Routing zwischen Diensten, das Puffern oder die Lastverteilung übernehmen. Das sind konfigurierte Fähigkeiten, keine Funktionen, die man für jede Bereitstellung als selbstverständlich ansehen sollte.
Die NGINX-Dokumentation zum Reverse-Proxy erklärt, wie man Anfragen an ein Upstream mit proxy_pass weiterleitet, Anforderungsheader festlegt und das Puffern steuert. Dieser Leitfaden konzentriert sich auf die Auswahl der Rolle; Installations- und Direktive-Details gehören zur Dokumentation der Software, die Sie tatsächlich bereitstellen.
Ein Reverse-Proxy kann eine ungesunde Anwendung nicht gesund machen. Wenn die Upstream-Datenbank nicht verfügbar ist, stellt das Platzieren eines anderen Komponenten davor die fehlenden Daten nicht wieder her. Er kann nur dann eine kontrollierte Fehlermeldung bereitstellen oder zu einer anderen gesunden Instanz weiterleiten, wenn die Architektur so entworfen wurde.
Beispiel: Zwei interne Anwendungen unter einer Domain
Angenommen, ein kleines Team betreibt ein Dashboard und einen Dokumentationsdienst. Dies ist ein hypothetisches Design, kein Benchmark. Ein Reverse-Proxy kann einen definierten öffentlichen Einstiegspunkt bereitstellen und Anfragen an die entsprechende Anwendung gemäß konfigurierten Hosts oder Pfaden senden.
Das Team muss dennoch entscheiden, wer auf jede Anwendung zugreifen kann, wie Zertifikate erneuert werden und ob die Ursprungsdienste direkt erreichbar sind. Eine ordentliche Domainstruktur ist nützlich, ersetzt jedoch nicht die Zugangskontrolle. Testen Sie sowohl den erwarteten öffentlichen Pfad als auch alle unbeabsichtigten alternativen Einstiegspunkte.
Authentifizierung und Vertrauen sind auf jeder Seite unterschiedlich
Ein Forward-Proxy kann einen Benutzernamen und ein Passwort verlangen, bevor er den Verkehr weiterleitet. Die Anwendung kann auch ihre eigenen Zielanmeldeinformationen benötigen. Halten Sie die beiden Identitäten in der Konfiguration, in Protokollen und in Vorfallberichten getrennt.
Bei einem Reverse-Proxy können sich Besucher bei der Anwendung oder bei einer Zugriffsschicht davor authentifizieren. Die Anwendung muss verstehen, welche Header oder Identitätsbehauptungen sie vertrauen kann. Das Akzeptieren eines von einem Besucher bereitgestellten Identitätsheaders ohne eine vertrauenswürdige Grenze kann die beabsichtigte Kontrolle untergraben.
Zum Beispiel möchte eine Anwendung möglicherweise die ursprüngliche Besucheradresse aufzeichnen, nachdem der Verkehr durch ein Gateway geleitet wurde. Das erfordert eine bewusste Konfiguration des vertrauenswürdigen Proxys. Das bloße Lesen eines weitergeleiteten Headers stellt nicht sicher, dass dessen Inhalte autoritativ sind. Die Einstellungen der Anwendung und des Gateways müssen sich darüber einig sein, welche Komponenten berechtigt sind, ihn bereitzustellen.
In beiden Designs definieren Sie, wer die Routing-Konfiguration ändern kann. Ein Proxy-Administrator kann beeinflussen, wohin Anfragen gehen und welche Informationen durch den Vermittler fließen. Behandeln Sie diese Autorität als eine bedeutende betriebliche Berechtigung, nicht als eine harmlose Komforteinstellung.
Verschlüsselt einer der Proxys automatisch alles?
Nein. Identifizieren Sie die Verbindungen separat. Es kann eine Verbindung vom Client zum Proxy und eine andere vom Proxy zum Ziel oder Upstream geben. Verschlüsselung auf einer Verbindung stellt keine Verschlüsselung auf der anderen sicher.
Für einen Reverse-Proxy, der HTTPS beendet, entscheiden Sie, ob die Verbindung zur Anwendung ebenfalls TLS erfordert, und überprüfen Sie die relevanten Zertifikats- und Vertrauenseinstellungen. Bei einem Forward-Proxy unterscheiden Sie die Ziel-URL vom Protokoll, das verwendet wird, um den Proxy-Endpunkt zu erreichen.
Halten Sie diese Entscheidungen im Architekturprotokoll fest. Vermeiden Sie ein Diagramm, das die gesamte Route als „sicher“ kennzeichnet, ohne zu erklären, wo die Verschlüsselung beginnt und endet. Die nützliche Überprüfung fragt, was jeder Vermittler beobachten kann, wo Anmeldeinformationen reisen und welche Partei die Vertrauenskonstruktion verwaltet.
Ein praktischer Auswahlprozess
1. Schreiben Sie die Anfrage in einfacher Sprache
Verwenden Sie einen Satz wie „unser Mitarbeiter ruft eine externe API auf“ oder „Kunden öffnen unser Dashboard“. Nennen Sie den Anforderer und das Ziel. Diese kleine Übung identifiziert normalerweise die relevante Seite der Proxy-Unterscheidung, bevor ein Produktvergleich beginnt.
Wenn die Anforderung nur sagt „wir benötigen einen Proxy“, fragen Sie, was sich ändern muss: ausgehendes Routing, eingehender Anwendungszugriff, Authentifizierung oder Verkehrsmanagement. Diese Ziele können unterschiedliche Komponenten erfordern.
2. Identifizieren Sie die Grenze, die Sie kontrollieren
Listen Sie den Client, den Vermittler und das Ziel auf. Markieren Sie, welche Systeme Ihr Team betreibt und welche zu einer anderen Organisation gehören. Entwerfen Sie keine Lösung, die administrative Kontrolle über eine Website eines Dritten voraussetzt.
Für eine Anwendung, die Sie besitzen, können Sie ein eingehendes Gateway wählen und den Ursprung konfigurieren. Für eine API eines Dritten kontrollieren Sie Ihren Client und dessen autorisierten Pfad, aber die Kontoberechtigungen und Nutzungsregeln der API bleiben außerhalb dieser Grenze.
3. Definieren Sie die erforderlichen Protokolle und Verhaltensweisen
Schließen Sie das Anwendungsprotokoll, die Authentifizierungsmethode, die Anforderungsgröße, das Streaming-Verhalten und die erwartete Verbindungsdauer ein. Eine erfolgreiche kurze Seitenanfrage beweist nicht, dass langanhaltende Streams oder große Uploads korrekt funktionieren.
Verwenden Sie repräsentative autorisierte Tests und protokollieren Sie die Client-Version. Vermeiden Sie es, das Wort „Proxy“ als Beweis dafür zu behandeln, dass jedes Protokoll oder Authentifizierungsmechanismus funktioniert. Kompatibilität ist eine Eigenschaft des gesamten Verbindungspfades.
4. Weisen Sie jeder Fehlermeldung einen Eigentümer zu
Entscheiden Sie, wer die Client-Konfiguration, die Verfügbarkeit des Proxys, die Gesundheit der Anwendung und die Zertifikatserneuerung überprüft. Geben Sie dem Support-Personal genügend bereinigte Informationen, um einen Proxy-Authentifizierungsfehler von einem Fehler der Upstream-Anwendung zu unterscheiden.
Entscheiden Sie auch, wie Sie eine Routingänderung deaktivieren oder zurücksetzen können. Eine umkehrbare Konfiguration ist viel einfacher zu betreiben als eine undokumentierte Abhängigkeit, die jeder während eines Ausfalls entdeckt.
5. Überprüfen Sie das tatsächliche Ergebnis
Für einen Forward-Proxy testen Sie, ob die beabsichtigte Anwendung dem ausgewählten Pfad folgt und ihre tatsächliche Aufgabe erfüllt. Für einen Reverse-Proxy testen Sie den öffentlichen Hostnamen, das Routing, die Authentifizierung und das erwartete Upstream-Verhalten. Überprüfen Sie, ob unbeabsichtigter direkter Zugriff dort eingeschränkt ist, wo Ihr Design es erfordert.
Halten Sie das Ergebnis als kleines Abnahmeprotokoll fest, anstatt einen Screenshot einer erfolgreichen Anfrage zu machen. Schließen Sie normales Verhalten, einen kontrollierten Fehler und den Wiederherstellungsschritt ein. Dies schafft einen Referenzpunkt für zukünftige Änderungen.
Kann ein System beide verwenden?
Ja. Eine Webanwendung kann Besucher über einen Reverse-Proxy empfangen, während ihr Hintergrundarbeiter einen Forward-Proxy für eine autorisierte externe Integration verwendet. Dies sind separate Anfragepfade, auch wenn die Komponenten in derselben Infrastruktur laufen.
Halten Sie ihre Anmeldeinformationen, Protokolle und Konfigurationsnamen getrennt. „Proxy-Passwort“ ist ein mehrdeutiger geheimer Bezeichner, wenn eine Bereitstellung mehrere Vermittler enthält. Bevorzugen Sie Namen, die den Dienst und den Zweck identifizieren, ohne das Geheimnis selbst zu offenbaren.
Berücksichtigen Sie auch die Unabhängigkeit von Fehlern. Wenn der ausgehende Proxy nicht verfügbar ist, sollte die öffentliche Anwendung verfügbar bleiben, während geplante Integrationen pausieren? Wenn das eingehende Gateway ausfällt, können die Betreiber dann noch auf eine Wiederherstellungskonsole zugreifen? Diese Fragen zeigen, ob eine Komponente versehentlich zu einer Abhängigkeit für nicht verwandte Arbeiten geworden ist.
Wo Hosting- und Proxy-Produkte passen
Ein Server gibt Ihnen einen Ort, um Software auszuführen. Ein Weiterleitungsdienst gibt einem kompatiblen Client einen Pfad für Anfragen. Sie können kombiniert werden, aber keiner schließt automatisch den anderen ein. Der bestehende Vergleich zwischen VPS und Wohnproxy erweitert diese Unterscheidung.
Für das Hosting einer Anwendung oder eines Gateways bewerten Sie die Laufzeit- und Wartungsverantwortlichkeiten von Cloud VPS. Wenn Sie den NGINX Proxy Manager wählen, deckt der bestehende Bereitstellungsleitfaden für NGINX Proxy Manager diese separate Installationsaufgabe ab. Der umfassendere Leitfaden zur VPS-Verwaltung ist relevant, um den zugrunde liegenden Server gewartet zu halten.
Die ISP- oder Rechenzentrumsklassifizierung eines ausgehenden Proxys ist eine andere Entscheidung. Sie sagt Ihnen nicht, ob Ihre Website einen Reverse-Proxy benötigt, und sie beseitigt nicht die Notwendigkeit, Authentifizierung und Anwendungszugriff zu konfigurieren. Wählen Sie zuerst die Architektur und bewerten Sie dann das Netzwerkangebot anhand einer spezifischen Anforderung.
FAQ
Was ist der Hauptunterschied zwischen Forward-Proxy und Reverse-Proxy?
Ein Forward-Proxy dient Clients, die ausgehende Anfragen stellen; ein Reverse-Proxy dient Anwendungen, die eingehende Anfragen empfangen. Identifizieren Sie, welche Seite Sie betreiben und welches Verkehrsverhalten Sie ändern möchten, bevor Sie Software oder einen Dienst auswählen.
Kann ein Reverse-Proxy die ausgehende IP meines Browsers ändern?
Nicht einfach, indem er vor Ihrer Website existiert. Er verarbeitet Anfragen, die an die Anwendungen gerichtet sind, die er bedient. Das Routen von nicht verwandtem Browserverkehr durch einen Vermittler erfordert eine separate unterstützte Forward-Proxy- oder Netzwerk-Konfiguration.
Ist ein Reverse-Proxy dasselbe wie ein Lastenausgleich?
Nein. Lastenausgleich ist eine mögliche Funktion eines Reverse-Proxy-Designs. Ein Reverse-Proxy kann an ein einzelnes Upstream weiterleiten, und ein Lastenausgleichssystem kann auf unterschiedliche Weise arbeiten. Überprüfen Sie die tatsächliche Konfiguration, anstatt von dem Label auf Redundanz zu schließen.
Macht ein Forward-Proxy Anfragen anonym?
Solch eine Garantie ergibt sich nicht aus der Rolle. Kontoanmeldungen, Cookies, Anfragedaten und Protokolle des Betreibers sind weiterhin wichtig. Bewerten Sie, welche Informationen gesendet und gespeichert werden, und verwenden Sie den Dienst nur für Zugriffe, zu denen Sie autorisiert sind.
Brauche ich beide für eine kleine Website?
Nicht unbedingt. Beginnen Sie mit den Anforderungen der Anwendung. Ein verwalteter Hosting-Dienst kann bereits den eingehenden Einstiegspunkt verwalten, und gewöhnliche ausgehende Anfragen benötigen möglicherweise keinen zusätzlichen Proxy. Fügen Sie eine Komponente nur hinzu, wenn sie ein dokumentiertes Bedürfnis löst und jemand sie warten kann.
Ist ein transparenter Proxy eine dritte Richtung?
Nein. Transparenz beschreibt, wie Abfangen oder das Bewusstsein des Clients in einem bestimmten Kontext funktioniert; es ist eine separate Dimension davon, wessen Anfragen der Vermittler bedient. Verwenden Sie präzise Beschreibungen des Verkehrswegs, anstatt jedes Proxy-Label als konkurrierende Architektur zu behandeln.