ComputerBase Menü
Aktuelles

FritzBox mehrere Domains über eigenen NGINX Webserver

Also wenn beide Domains zu deiner IP führen, dann einmal die config für die cloud:
Code: 
server {
    listen 80;
    listen[::]:80;
    server_name cloud.meinedomain.de;

    return 301 https://$server_name$request_uri;
}
    
  server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name cloud.meinedomain.de;
    
    access_log /var/log/nginx/cloud.meinedomain.de.access.log;
    error_log /var/log/nginx/cloud.meinedomain.de.error.log;

    location / {
      more_clear_headers 'upgrade';
      more_clear_headers 'Strict-Transport-Security';

      proxy_ssl_verify on;
      proxy_pass https://<Adresse zu Nextcloud in internem Netzwerk>;

      proxy_pass_header Authorization;
      
      proxy_set_header 'X-Forwarded-Host' cloud.meinedomain.de;
      proxy_set_header 'X-Forwarded-Proto' https;
      proxy_set_header 'X-Forwarded-For' $remote_addr;
      proxy_set_header 'X-Forwarded-IP' $remote_addr;
      add_header Front-End-Https on;
    }
  }

und für wordpress:
Code: 
server {
    listen 80;
    listen[::]:80;
    server_name wordpress.meinedomain.de;

    return 301 https://$server_name$request_uri;
}
    
  server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name wordpress.meinedomain.de;
    
    access_log /var/log/nginx/wordpress.meinedomain.de.access.log;
    error_log /var/log/nginx/wordpress.meinedomain.de.error.log;

    location / {
      more_clear_headers 'upgrade';
      more_clear_headers 'Strict-Transport-Security';

      proxy_ssl_verify on;
      proxy_pass https://<Adresse zu Wordpress in internem Netzwerk>;

      proxy_pass_header Authorization;
      
      proxy_set_header 'X-Forwarded-Host' wordpress.meinedomain.de;
      proxy_set_header 'X-Forwarded-Proto' https;
      proxy_set_header 'X-Forwarded-For' $remote_addr;
      proxy_set_header 'X-Forwarded-IP' $remote_addr;
      add_header Front-End-Https on;
    }
  }
 
@Azshania also ich hab definitiv noch Fehler in der Domainauflösung, denn ich habe nun einfach nach wie vor A-Record manuell gesetzt für Rootdomain, dann cloud.meinedomain.de in der FritzBox als DynDNS. Dann blog.meinedomain.de als Subdomain eingetragen ebenfalls mit meiner IP, aber nicht in der FritzBox eingetragen.

Aber es hat geklappt! Ich komme auf WordPress. Bzw halt nicht, aber erste Lebenszeichen sind ersichtlich:

Code: 
2020/03/14 21:44:54 [error] 6#6: *95 connect() failed (111: Connection refused) while connecting to upstream, client: <meineIP>, server: blog.meinedomain.de, request: "GET / HTTP/2.0", upstream: "https://192.168.0.5:443/", host: "blog.meinedomain.de", referrer: "https://blog.meinedomain.de/"

Meine aktuelle NGINX Konfig:

Code: 
  server {
    listen 80 default_server;
    listen [::]:80 default_server;
    return 301 https://$host$request_uri;
  }

  # NextCloudPi
    
  server {
    server_name nextcloud.meinedomain.de;
    
    listen 443 ssl http2;
    listen [::]:433 ssl http2;
 
    client_max_body_size 100G;
    
    location / {
      more_clear_headers 'upgrade';
      more_clear_headers 'Strict-Transport-Security';

      proxy_ssl_verify off;
      proxy_pass https://nextcloudpi;
      proxy_set_header 'X-Forwarded-Host' nextcloud.meinedomain.de;
      proxy_set_header 'X-Forwarded-Proto' https;
      proxy_set_header 'X-Forwarded-For' $remote_addr;
      proxy_set_header 'X-Forwarded-IP' $remote_addr;

      proxy_pass_header x-requested-by;
      proxy_pass_header requesttoken;
    }
  }
    
  # NextCloudPi Konfiguration Web-Interface
    
  server {
    server_name nextcloud.meinedomain.de;
    
    listen 4443 ssl http2;
    listen [::]:4433 ssl http2;

    location / {
      more_clear_headers 'upgrade';
      more_clear_headers 'Strict-Transport-Security';

      proxy_ssl_verify off;
      proxy_pass https://nextcloudpi:4443;

      proxy_pass_header Authorization;
      
      proxy_set_header 'X-Forwarded-Host' nextcloud.meinedomain.de;
      proxy_set_header 'X-Forwarded-Proto' https;
      proxy_set_header 'X-Forwarded-For' $remote_addr;
      proxy_set_header 'X-Forwarded-IP' $remote_addr;
    }
  }
 
  # WordPress
 
   server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name blog.meinedomain.de;
    
    client_max_body_size 50m;
    
    index index.php index.html index.htm;

    root /var/www/html;

    location / {
      try_files $uri $uri/ /index.php$is_args$args;
    
      more_clear_headers 'upgrade';
      more_clear_headers 'Strict-Transport-Security';

      proxy_ssl_verify off;
      proxy_pass https://wordpress;

      proxy_pass_header Authorization;
      
      proxy_set_header 'X-Forwarded-Host' blog.meinedomain.de;
      proxy_set_header 'X-Forwarded-Proto' https;
      proxy_set_header 'X-Forwarded-For' $remote_addr;
      proxy_set_header 'X-Forwarded-IP' $remote_addr;
    }
    
    location ~ /.well-known/acme-challenge {
      allow all;
      root /var/www/html;
    }

    location ~ \.php$ {
      try_files $uri =404;
      fastcgi_split_path_info ^(.+\.php)(/.+)$;
      fastcgi_pass wordpress:9000;
      fastcgi_index index.php;
      include fastcgi_params;
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      fastcgi_param PATH_INFO $fastcgi_path_info;
    }

    location ~ /\.ht {
      deny all;
    }

    location = /favicon.ico {
      log_not_found off; access_log off;
    }
    
    location = /robots.txt {
      log_not_found off; access_log off; allow all;
    }
    
    location ~* \.(css|gif|ico|jpeg|jpg|js|png)$ {
      expires max;
      log_not_found off;
    }
   }
 
Zuletzt bearbeitet:
Was sagt denn das nginx log aus dem Wordpress Container? Ist da überhaupt irgendeine Art von Verbindungsversuch zu erkennen?
Eventuell kann der ReverseProxy den Wordpress Webserver nicht erreichen, upstream: "https://192.168.0.5:443/" ist das nicht eine IP au dem Netz deiner Fritzbox?
Wenn ich das richtig verstanden habe, hast du doch alles in Docker container, oder hast du mehrere Geräte wo die Seiten drauf laufen?
 
@Azshania was meinst du mit dem nginx log aus dem Wordpress Container? Das ist der Log vom NGINX Container, den ich dir da notiert habe. Und das ist der Versuch der Verbindung sobald ich die Seite aufrufe. Oder meinst du allgemein den Log vom Wordpress Container? Da sehe ich nur ready to handle connections. Die IP ist richtig. Nach jedem docker-compose start werden den Container IP's zugewiesen und die angegebene IP zeigt auf den Wordpress Container.
Alles läuft auf einem Gerät mit mehreren Docker Containern richtig.
 
In deinem Wordpress Container läuft ja weiterhin der Webserver der die Seite bereitstellt, der sollte in Normalfall auch ein log anlegen, egal ob da drin jetzt auch nginx, apache oder sonstwas läuft.

Mich wundert halt nur dass dein internes Dockernetzwerk IP's aus dem selben Bereich wie eine Fritzbox hat (192.168.x.x). Mein Docker bridge Netzwerk hat standartmäßig das Subnetz 172.17.0.0/16.
Kannst du denn aus dem Wordpress Container 192.168.0.5 per ping erreichen?
 
@Azshania hier so sieht das immer aus:
1584226904143.png

Das sind die Container IP's. Die Networks sehen so aus. Da ist auch das was du mit der bridge meinst:
1584226954640.png

Welchen Container soll ich wie per Ping erreichen?
 
Da hast du ja schonmal ein Problem: 192.168.0.5:443 steht in deinem Log, laut deinen Screens hat der Container aber 192.168.128.5
 
@Azshania nein hab ich nicht. Ich hab in der Zwischenzeit logischerweise herumprobiert und bei jedem Restart gibt es neue IPs.
 
Neustart oder nicht, im Subnetz 192.168.20.0/20 bzw. 192.168.144.0/20 wirst du niemals die IP 192.168.0.5 bekommen.
 
@Azshania keine Ahnung was du mir sagen willst, aber das hat zu 100 % seine Richtigkeit. Error.log passt erneut zum Container.
 
Was ich damit sagen will ist, diese IP kommt in deinen Subnetzen nicht vor und deshalb kann dein Container auch nie gehabt haben.
 
@Azshania entweder hast du dich verguckt oder keine Ahnung wie du dadrauf kommst. Weiterbringen wird mich das sowieso nicht leider. Das Subnetz war 192.168.128.0/20 wie auf Fotos zu sehen und der Container 192.168.128.5 passt sehr wohl dazu.
Naja jedenfalls versuche ich gerade erstmal zu verstehen wie FastCGI funktioniert und wo das wie aufgerufen werden soll. Weil den Port 9000 sehe ich nirgendwo in Nutzung.
 
Dann schau nochmal weiter oben wo du eine Zeile aus deinem Log gepostest hast, da steht definitiv
upstream: "https://192.168.0.5:443/"
 
@Azshania du hast mir ja auch nicht zugehört.
sasbro97 schrieb:
@Azshania nein hab ich nicht. Ich hab in der Zwischenzeit logischerweise herumprobiert und bei jedem Restart gibt es neue IPs.
Zum Vergrößern anklicken....
Das hab ich gesagt. Das gehörte zum alten Log. Die aktuellen Logs beeinhalten:
Code: 
upstream: "https://192.168.128.5:443/"
 
Doch ich habe sehr wohl verstanden was du geschrieben hast, wenn die IP jetzt als
192.168.128.5 passt es ja.
Aber wie bereits gesagt: Das die IP vorher 192.168.0.5 ist unmöglich.
Spielt aber jetzt keine Rolle mehr, da das anscheinend ja nicht das Problem ist.
Vielleicht solltest du die nginx config mal 1:1 von nextcloud übernehmen.
 
@Azshania hab ich nun auch gemacht und die selbe Config genommen wie für Port 443 für NextCloud und 1 zu 1 derselbe Fehler. Ist mein WordPress Image vielleicht ungeeignet? Hab derzeit ja wordpress:php7.3-fpm-alpine ausgewählt. Vielleicht mal nur 7.3 oder so. Ist auf jeden Fall komisch.

Ok mit php7.3 alleine wieder dasselbe. Absolut kurios.
 
So ich habe es selbst mal probiert und bin endlich mal überhaupt zu einem Ergebnis gekommen...
Die Alpine-Images gehen grundsätzlich bei mir garnicht: Laut Log ist aber scheinbar alles ok? Weder lokal Zugriff noch per Reverseproxy.

Dann einfach mal wordpress:latest ausprobiert: Läuft intern mit Apache und akzeptiert nur http Port 80 requests. Außerdem redirectet er immer auf Port 80, sprich ich habe den Container Port 80 auf meinem Host per Port 8090 verfügbar gemacht: Er redirected auf Port 80 und ich lande auf meinem Reverseproxy der mir dann meine Nextcloudpage anzeigt... :kotz:

Also in der Reverseproxy-config folgende Zeilen geändert:
Code: 
proxy_pass https://wordpress;
proxy_set_header 'X-Forwarded-Proto' https;
in:
Code: 
proxy_pass http://wordpress;
proxy_set_header 'X-Forwarded-Proto' $scheme;
Tadaa: Es läuft, zwar nur unverschlüsselt, aber ja nur innerhalb des abgeschotteten Dockernetzwerks.
Man hat ja weiterhin https vom Browser zum Reverseproxy.
 
@Azshania also alpine-fpm ging bei dir also auch nicht? Kannst du mir deine nginx.conf dafür mal bitte zeigen? Hab das mal mit $scheme und http geändert in meinem Block für Port 443 und trotzdem dasselbe Ergebnis. War ja zu erwarten. Ich wechsel jetzt auch nochmal das Image.

Mit wordpress:latest und dem http und $scheme passiert folgendes beim URL-Aufruf von blog.meinedomain.de
Die Browserzeile verwandelt sich in:

https://wordpress/wp-admin/install.php

Und natürlich kann das nicht gefunden werden. Verstehe nur nicht warum das passiert. War bei dir ja auch nicht. Oder ist das wegen meinem 443er Server Block?
 
Zuletzt bearbeitet:
Ja wie gesagt nur das Standartimage funzt, war jetzt aber auch zu faul zu schauen ob Apache was im Log abgelegt hat.
Hier meine conf:
Code: 
server {
    listen 80;
    listen [::]:80;
    server_name www.meinedomain.de;

    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.meinedomain.de;

    access_log /var/log/nginx/www.meinedomain.de.access.log;
    error_log /var/log/nginx/www.meinedomain.de.error.log;

    client_max_body_size 0;
    underscores_in_headers on;

    include /etc/nginx/conf.d/ssl.settings;
    # dont forget to create cronjob for ticketkey


        location / {
                  proxy_pass http://wordpress;
                  proxy_set_header X-Forwarded-Host $host;
                  proxy_set_header X-Forwarded-Server $host;
                  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                  proxy_set_header X-Forwarded-Proto $scheme;
                  proxy_set_header X-Real-IP $remote_addr;
                  proxy_set_header Host $host;
        }
}
 
@Azshania das hat tatsächlich bei mir auch geklappt. Wieso das andere nicht geht, keine Ahnung. Hab ich großartige Nachteile davon? Ich glaub nur, dass fpm schneller sein sollte oder? Weiß aber nicht ob das bei einer Hausleitung etc. so einen Unterschied macht. Also ich bin dir schon einmal unendlich dankbar!

Jetzt muss ich nur noch schauen, dass ich das mit dein Domains in den Griff bekomme, denn aktuell ist das nicht das Gelbe vom Ei, wenn sich ja nichts aktualisiert. Und genauso macht die Domain blog.meinedomain.de mir Schwierigkeiten, da er sich beschwert, weil das Zertifikat von meinedomain.de und nicht blog.meinedomain.de stammt. Muss ich dafür nochmal ein extra Zertifikat anlegen? Und natürlich hab ich auch noch den Certbot Weg vor mir mit dem automatischen Aktualisieren der Zertifikate. Da werd ich natürlich versuchen dein Docker Image https://hub.docker.com/r/certbot/dns-ovh umzusetzen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

D
NGINX Proxy Manager: Mehrere Domains
Antworten
4
Aufrufe
993
DerSchalker92
D
Zurück
Oben

Willkommen auf ComputerBase!

Mit Werbung weiterlesen

Besuche ComputerBase wie gewohnt mit Werbung und Tracking. Die Zustimmung ist jederzeit widerrufbar.

Details im Privacy Center und in der Liste unserer Partner. Ein Widerruf ist möglich in der Datenschutzerklärung.

… oder ComputerBase Pro bestellen

Nutze ComputerBase ohne Werbebanner, Video-Ads und Werbetracking schon für 4 €/Monat oder 36 €/Jahr.

Mehr zu ComputerBase Pro

Bereits Pro-Nutzer? Hier anmelden.

Tracking: Wir und unsere 160 Partner verarbeiten personenbezogene Daten, indem wir mit auf Ihrem Gerät gespeicherten Informationen (z. B. eindeutige Kennungen in Cookies) ein Nutzungsprofil erstellen, um z. B. Anzeigen zu personalisieren. Verarbeitungszwecke: Genaue Standortdaten und Abfrage von Geräteeigenschaften zur Identifikation, Informationen auf einem Gerät speichern und/oder abrufen, Personalisierte Anzeigen und Inhalte, Anzeigen- und Inhaltsmessungen, Erkenntnisse über Zielgruppen und Produktentwicklungen.

Impressum Kontakt Datenschutz