Können zwei Reverse-Proxys auf einem Heimserver die Ports 80 und 443 gemeinsam nutzen?

Nicht gleichzeitig unter derselben IP-Adresse und mit demselben Protokoll, es sei denn, ein Proxy ist das einzige Eingangstor und leitet ausgewählten Datenverkehr an den anderen weiter oder jeder bindet an eine andere IP-Adresse.

Das wird zu einer echten Kompatibilitätsfrage, wenn zwei Proxy-Container auf einem Rechner die Host-Ports 80 und 443 für separate App-Stacks veröffentlichen. Beginnen Sie mit einem Weg oder Konto, das Sie verwerfen können, halten Sie den zuvor funktionierenden Zustand verfügbar und beurteilen Sie das Design anhand der ursprünglichen Arbeitslast statt anhand eines einmaligen Verbindungstests.

Ermitteln Sie, wem die gemeinsame Ressource gehört

Der unterstützte Ansatz ist ein Listener pro IP-Port-Paar mit dahinterliegendem Routing. Die konkurrierende Variante besteht aus zwei unabhängigen Listenern, die um denselben Socket konkurrieren. Notieren Sie Versionen, Identitäten, Adressen, Einhängepfade, Berechtigungen und den aktuell beobachtbaren Zustand, bevor Sie einen der beiden Ansätze ändern.

Die relevanten Regeln für die Socket-Bindung definieren die erste Kompatibilitätsgrenze. Verwenden Sie sie, um die Aussage einzugrenzen, und überprüfen Sie anschließend dasselbe Verhalten auf genau diesem Heimserver, statt eine dokumentierte Funktion als Beweis dafür zu betrachten, dass das gesamte Design funktioniert.

Formulieren Sie die Entscheidungsregel vor dem Test: Der Erfolg muss dazu führen, dass nur der vorgesehene Front-Proxy jeden öffentlichen Socket besitzt und jeder Hostname den richtigen Upstream mit dem erwarteten Zertifikat erreicht. Als Fehler gelten eine Startmeldung wie „Adresse bereits in Verwendung“, Datenverkehr, der den falschen Proxy erreicht, oder TLS, das mit dem Zertifikat einer anderen Website beendet wird. Dadurch wird verhindert, dass eine teilweise Verbindung oder ein sauberer Befehlsabschluss fälschlich als Ende-zu-Ende-Kompatibilität verstanden wird.

Ändern Sie jeweils nur einen Listener oder eine Route

Verwenden Sie nur einen kontrollierten Unterscheidungsfaktor: Listen Sie die aktuellen Listener auf, binden Sie jeden Proxy an eine eigene Test-IP oder schieben Sie einen Proxy hinter den anderen und testen Sie anschließend Host-, SNI-, WebSocket- und Zertifikatsrouting. Halten Sie Client, Arbeitslast, Dateisatz, Konto und Zeitplanung konstant, damit die geänderte Komponente die einzige plausible Erklärung bleibt.

Nutzen Sie das Verhalten veröffentlichter Ports, um die zweite für diesen Pfad relevante Beobachtung auszuwählen. Erfassen Sie beide Seiten der Transaktion: Resolver oder Route, ausgehandeltes Protokoll, Prozessidentität, Exit-Status, Latenz, übertragene Bytes und jedes Wiederherstellungsereignis.

Wiederholen Sie den Test nach dem im Titel genannten Lebenszyklusereignis - Neuerstellung, erneuter Verbindung, erneutem Einhängen, Neustart, Failover oder Client-Wechsel. Ein Design, das nur funktioniert, solange alte Sockets, Caches oder Zugangsdaten aktiv bleiben, hat den Test nicht bestanden.

ss -ltnp '( sport = :80 or sport = :443 )'
docker ps --format '{{.Names}} {{.Ports}}'

Verwenden Sie beobachtbare Routing-Nachweise für die Entscheidung

BESTANDEN: Nur der vorgesehene Front-Proxy besitzt jeden öffentlichen Socket und jeder Hostname erreicht den richtigen Upstream mit dem erwarteten Zertifikat. Speichern Sie die genauen Versionen und die Topologie, die diesen Zustand erzeugt haben, da die Schlussfolgerung für diese Bedingungen gilt und nicht für jede Implementierung des Protokolls.

NICHT BESTANDEN: Der Start meldet, dass die Adresse bereits verwendet wird, der Datenverkehr erreicht den falschen Proxy oder TLS wird mit dem Zertifikat einer anderen Website beendet. Prüfen Sie gemeinsame Abhängigkeiten wie DNS, MTU, Identität, Firewall-Zustand, Speichervorgänge und Latenz sowie zwischengespeicherte Sitzungen, bevor Sie einen der beiden Hauptansätze dafür verantwortlich machen.

AUSNAHME: Beenden Sie die zweite öffentliche Bindung, stellen Sie den zuletzt funktionierenden Listener wieder her und wählen Sie ein Eingangstor oder getrennte Hostadressen. Erweitern Sie keine Berechtigungen, löschen Sie keine Quelldaten, schwächen Sie nicht die Transportsicherheit und ersetzen Sie keinen funktionierenden Speicher, bevor eine wiederholbare Beobachtung zeigt, welche Grenze versagt hat.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Prüfen Sie die Isolation erneut, bevor der Produktionsdatenverkehr zurückkehrt

Führen Sie nur die Maßnahme aus, die zum beobachteten Fall passt, und wiederholen Sie anschließend die ursprüngliche Arbeitslast. Behalten Sie das Design nur dann bei, wenn ausschließlich der vorgesehene Front-Proxy jeden öffentlichen Socket besitzt und jeder Hostname den richtigen Upstream mit dem erwarteten Zertifikat über zwei relevante Lebenszykluszyklen und unter der erwarteten gleichzeitigen Last erreicht.

Verwenden Sie die dedizierten Proxy-Netzwerke, um den nächstgelegenen abhängigen Arbeitsablauf zu überprüfen. Zugriffs-, Zeit- und Wiederherstellungsverhalten müssen unverändert bleiben, während das neue Design aktiv ist.

Stoppen Sie den Vorgang und kehren Sie zum gespeicherten Zustand zurück, wenn der Start meldet, dass die Adresse bereits verwendet wird, der Datenverkehr den falschen Proxy erreicht oder TLS mit dem Zertifikat einer anderen Website beendet wird. Eskalieren Sie mit Zeitstempeln, genauen Versionen, Nachweisen zu Routen oder Einhängepunkten und der kleinsten Reproduktion, statt einen weiteren Workaround hinzuzufügen.

Vergleichen Sie das Ergebnis mit den DNS-Überschreibungen für Reverse-Proxys, damit das Risiko nicht lediglich in eine andere Netzwerk-, Identitäts-, Sicherungs- oder Speicherschicht verlagert wird.

Für den Besitz von Ports durch zwei Reverse-Proxys lautet die qualifizierte Antwort daher wie eingangs beurteilt - kein uneingeschränktes Ja. Der beobachtbare Zustand „BESTANDEN“ ist die Abnahmelinie; der Zustand „NICHT BESTANDEN“ ist die Rücksetzlinie.

FAQ

Kann SO_REUSEPORT es unabhängigen Proxys ermöglichen, 443 gemeinsam zu verwenden?

Für unabhängige Proxys ist dies kein sicheres Design für das Hostname-Routing; verwenden Sie ein einziges TLS-Eingangstor oder separate IPs.

Kann ein Proxy TLS an den zweiten Proxy durchreichen?

Ja, wenn das Routing auf SNI basiert und der nachgeschaltete Proxy die Zertifikatsbeendigung für diesen Hostnamen übernimmt.

Stehen IPv4- und IPv6-Listener miteinander in Konflikt?

Das ist abhängig vom Dual-Stack-Socket-Verhalten und den Bind-Adressen möglich; prüfen Sie beide Protokollfamilien ausdrücklich.