Nginx-Proxy-Pass zum Reverse-Proxy

Sep 11 2020

Ich bin ziemlich neu in Nginx und bleibe bei der aktuellen Konfiguration.

Ich habe auch überprüft, ob ssl - nginx umleitet , nginx als Proxy für Web-App , nginx proxy_pass , nginx proxy rewrite und einen weiteren Beitrag zu meiner Frage .

Ich habe mir auch einige andere Beiträge angesehen, die mir im Moment nicht geholfen haben. Ich habe nicht alle rund 21500 Beiträge zu den Themen nginxund gelesen proxy.

Google hat mich auch nicht zur Lösung weitergeleitet.

Das aktuelle Setup ist:

[CMS (Plone in LAN)]<--->[Reverse-Proxy (Apache / http://oldsite.foo)]

Dies ist das alte Site-Setup. Grundsätzlich brauchen wir eine Neugestaltung des CMS. Aber es ist mit vielen Abhängigkeiten und selbstgeschriebenen Modulen von mindestens zwei Entwicklern (die sich nie getroffen haben) gewachsen. Es wird nur ein Jahr lang eine Aufgabe sein, es richtig zu ersetzen. Es gibt auch einige seltsame Dinge in der Apache-Konfiguration, so dass wir die Verwendung von Apache im Moment nicht vermeiden können.

Leider brauchen wir so schnell wie möglich ein optisches Redesign.

Daher kamen wir auf die Idee, Diazo / XSLT in Nginx zu verwenden, um die alte Website neu zu gestalten und unseren Prüfern einige Ergebnisse zu zeigen.

Deshalb versuche ich folgendes Setup:

[Plone]<--->[Apache]<--->[Proxy (XSLT in Nginx / https://newsite.foo)]

Hier ist meine xslt_for_oldsiteKonfigurationsdatei (Cache-Control nur zum Debuggen deaktiviert):

add_header Cache-Control no-cache;

server {
  server_name newsite.foo;
  server_tokens off;

  listen b.b.b.b:80;

  return 301 https://$server_name$request_uri;

  access_log /var/log/nginx/newsite.port80.access.log;
  error_log /var/log/nginx/newsite.port80.error.log;
}

server {
  server_name newsite.foo;
  server_tokens off;

  listen b.b.b.b:443 ssl;

  access_log /var/log/nginx/newsite.port443.access.log;
  error_log /var/log/nginx/newsite.port443.error.log;

  ssl_certificate /etc/ssl/certs/nginx.crt;
  ssl_certificate_key /etc/ssl/private/nginx.key;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
  ssl_ciphers HIGH:!aNULL:!MD5:!ADH:!AECDH;
  ssl_session_cache shared:SSL:5m;

  proxy_http_version 1.1;

  #proxy_set_header X-Forwarded-Host $host:$server_port;
  #proxy_set_header X-Forwarded-Server $host; #proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

#  proxy_set_header Connection "";
#  proxy_ignore_headers Expires;

#  proxy_set_header X-Real-IP $remote_addr; # proxy_set_header X-forwarded-host $host;

  sub_filter_types *;
  sub_filter_once off;
  sub_filter "http://oldsite.foo" "https://newsite.foo";

  location / {
    proxy_pass http://oldsite.foo/;
    proxy_redirect off;
    #proxy_redirect http://oldsite.foo/ https://newsite.foo/;
    proxy_set_header Host $host;
  }
}

Wenn ich meinen Browser starte, um eine Verbindung herzustellen http://oldsite.foo dann lädt es:

1 HTML-Dokument von oldsite
3 CSS-Dateien von oldsite
9 JS-Dateien von oldsite
10 Grafikdateien von oldsite

Aber wenn ich meinen Browser benutze um zu bekommen https://newsite.foo dann lädt es:

1 HTML-Dokument von der Newsite
nur 5 Grafikdateien von oldsite (direkte Anfrage von meinem Browser)
alles andere fehlt

Während für das empfangene HTML-Dokument wget https://newsite.foo -o index.htmlalle Links geändert wurden https://newsite.foo(korrekt ersetzt http://oldsite.foodurch https://newsite.foo), zeigt der Browser alle Links unverändert an: http://oldsite.fooanstelle von https://newsite.foo.

Ich bekomme folgenden Server-Header mit curl -I https://newsite.foo:

HTTP/1.1 200 OK
Server: nginx
Date: Fri, 11 Sep 2020 10:28:15 GMT
Content-Type: text/html
Connection: keep-alive
Accept-Ranges: none
Accept-Ranges: bytes
X-Varnish: 1216306480
Age: 0
Via: 1.1 varnish
Set-Cookie: I18N_LANGUAGE="de"; Path=/
Via: 1.1 oldsite.foo
Vary: Accept-Encoding
Cache-Control: no-cache

Ich spielte mit dem add_header, proxy_set_headerund proxy_redirect. Ich habe es auch versucht

location ~* .* {
  proxy_pass http://oldsite.foo$request_uri;
  proxy_redirect off;
  proxy_set_header Host $host;
}

Aber keine meiner Änderungen hat das Verhalten von Nginx geändert, an das die GET-Anforderungen umgeleitet werden http://oldsite.foo und zeigt die Antworten, als ob sie kommen würden https://newsite.foo .

Ich habe keine Antwort auf diese Fragen:

Warum mein Browser immer wieder eine Verbindung herstellt http://oldsite.foo? Es sollte eine Verbindung zu herstellenhttps://newsite.foo .
Warum unterscheiden sich die Links im HTML zwischen der Version von wgetund meinem Browser?
Warum über die Hälfte der Website den Browser nicht erreicht https://newsite.foo?
Wie kann ich das beheben?

Ist da draußen jemand, der mich in die richtige Richtung weist?

Danke im Voraus. Zumindest danke, dass du meinen Beitrag gelesen hast.

Freundliche Grüße.

Antworten

choogeoh Sep 15 2020 at 13:11

Inzwischen habe ich die Lösung gefunden.

Apache hat die Daten gzipped gesendet und sub_filter konnte nicht damit umgehen (siehe offizielle Dokumentation: sub_filter ).

In der Tat habe ich versucht, dies durch die Verwendung zu vermeiden, proxy_set_header Accept-Encoding "";aber es hat nicht funktioniert. Der Grund ist, dass dieser Teil im Standortkontext festgelegt werden muss .