☰

NGINX - Anfrage an eine andere IP umleiten, dabei die URL beibehalten

tag-icon • tag-icon nginx reverse-proxy rewrite
NGINX - Anfrage an eine andere IP umleiten, dabei die URL beibehalten

Ich habe dynamisches DNS eingerichtet und möchte von außerhalb meines Zuhauses auf verschiedene Computer zugreifen können. Derzeit habe ich einen Raspberry Pi, auf dem nginx auf 192.168.1.2 läuft, und mein Router ist auf 192.168.1.1. Außerdem habe ich Port 80 vom Router zum Raspberry Pi weitergeleitet, sodass mir durch einfaches Anklicken der dynamischen DNS-URL die phpinfo()-Seite auf meiner Pi-Startseite angezeigt wird.

Als Nächstes möchte ich in der Lage sein, mydns.com/device1diese URL beizubehalten, während ich im Hintergrund auf das andere Gerät umleite.

Mit anderen Worten: Ich sehe http://mydns.com/device1, greife aber http://192.168.1.3intern darauf zu. Wenn ich zusätzlich eingebe, mydns.com/device1/loginerfolgt eine interne Weiterleitung zu http://192.168.1.3/login.

sub_filterIch versuche , es so zu verwenden :

sub_filter_once off;
sub_filter_types text/html;
sub_filter ""http://192.168.1.3" "http://192.168.1.2"
proxy_pass http://192.168.1.3/;
proxy_set_header Host $host;

Dies funktioniert bis zu einem gewissen Grad, aber nicht vollständig. Die Pfade werden nicht umgeleitet, z. B. Dateien in Unterordnern. Beispiel:

Ich will das: http://mydns.com/device1/style/basic.css

Aber verstehen Sie das: http://mydns.com/style/basic.css

Dies führt zu einem 404-Fehler, wie in der Konsolenansicht in Chrome zu sehen ist. Ich erhalte diesen Fehler:

Failed to load resource: the server responded with a status of 404 (Not Found)

Das liegt auf dem Weg: http://mydns.com/style/basic.cssaber ich brauche http://mydns.com/device1/style/basic.css.

Ich kann auf die CSS-Datei in der Adressleiste zugreifen, indem ich . eingebe http://mydns.com/device1/style/basic.css. Ich weiß also, dass sie zugänglich ist. Ich kann NGINX nur nicht dazu bringen, diese Ordner weiterzuleiten/umzuschreiben.

Kann jemand helfen? Danke

Antwort1

Es kann mehrere Gründe haben:

  • entweder schreibt etwas Ihre URI um, bevor es den Standort mit Proxy-Pass betritt;
  • oder es wird als übereinstimmender Sub-URI an einigen zuvor verarbeiteten Stellen bereitgestellt;
  • oder (in Ihrer Nginx-Version) /bewirkt der Schrägstrich nach der IP in der Proxy_pass-Direktive, dass Nginx den Schrägstrich als Proxy-URI nimmt und ihn vor dem Senden neu schreibt.

Man kann nicht sehen, was genau auf Ihrer Seite passiert, ohne Ihre gesamte Konfiguration zu sehen. Oder Sie können versuchen, das Debug-Protokoll zu aktivieren (um zu sehen, was dies verursacht).

In jedem Fall haben Sie im Zusammenhang mit den oben genannten Gründen drei Möglichkeiten, das Problem zu lösen:

  • entweder vermeiden Sie das Umschreiben oder Sie müssen rewrite ... breakvor dem Proxy-Pass etwas Zusätzliches hinzufügen, um die URI zu erweitern;
  • proxy_pass http://192.168.1.3/device1/;oder Sie können versuchen, es als oder mit einer (Mapping-)Variable für „like“ proxy_pass http://192.168.1.3/$device/;oder sogar mit einer vollständigen Ursprungs-URI „like“ zu definieren proxy_pass http://192.168.1.3$request_uri;(beachten Sie, dass hier kein „like“ vorhanden ist /).
  • oder Sie können versuchen, den abschließenden Schrägstrich zu entfernen, also proxy_pass http://192.168.1.3;(ohne Schrägstrich) statt proxy_pass http://192.168.1.3**/**;(mit Schrägstrich).
    In diesem Fall „wird die Anforderungs-URI in derselben Form an den Server übergeben, wie sie von einem Client gesendet wurde, als die ursprüngliche Anforderung verarbeitet wurde“ (wenn keine Umschreibungen stattfinden) oder „die vollständige normalisierte Anforderungs-URI wird übergeben, wenn die geänderte URI verarbeitet wird“ (wenn einige Umschreibungen stattgefunden haben oder Sie einige Zwischenspeicherorte mit Alias ​​und try_files ... @proxyübergeben haben).

Schauen Sie sich anProxy-PasswortDokumentation für alle möglichen Varianten der Proxy-Pass-Verwendung.

verwandte Informationen