NGINX: Umleitung zu einer Nicht-www-Adresse

NGINX: Umleitung zu einer Nicht-www-Adresse

Ich versuche, meine Website mit NGINX zu konfigurieren. Ich bin etwas überfordert und habe alle relevanten Lösungen ausprobiert, die ich finden konnte. Ich danke Ihnen also für Ihre Geduld :)

Ich möchte, dass der gesamte HTTP-Verkehr auf https umgeleitet wird und Verbindungen zur WWW-Subdomäne meiner Website und zur IP-Adresse meines Servers (für unsere Zwecke 123.123.123.123) auf mywebsite.com umgeleitet werden. Meine Serverkonfiguration ist unten aufgeführt und erfüllt alle diese Kriterien mit Ausnahme der WWW-Umleitung, die mir eine NGINX 404-Seite beschert. Was ich nicht verstehe, ist, dass die Handhabung der IP-Adresse und der WWW-Subdomäne für mich identisch erscheint – liegt das Problem woanders, beispielsweise bei DNS oder SSL-Zertifikaten? Danke.

/etc/nginx/sites-available/meinewebsite

server {
        listen 80 ;
        server_name www.mywebsite.com mywebsite.com 123.123.123.123 ;
        return 301 https://mywebsite.com$request_uri ;
}
server {
        server_name www.mywebsite.com ;
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/mywebsite.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/mywebsite.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    return 301 https://mywebsite.com$request_uri ;


}
server {
        server_name 123.123.123.123;
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/mywebsite.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/mywebsite.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    return 301 https://mywebsite.com$request_uri ;


}
server {
        server_name mywebsite.com ;
        root /var/www/mywebsite ;
        index index.html index.htm index.nginx-debian.html ;
        location / {
                try_files $uri $uri/ =404 ;
        }
        if ($host != mywebsite.com) {
                return 301 https://mywebsite.com$request_uri;
        } 


    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/mywebsite.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/mywebsite.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


}
root@localhost:~# certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: mail.mywebsite.com
    Serial Number: ###################################
    Key Type: ECDSA
    Domains: mail.mywebsite.com
    Expiry Date: 2023-12-09 16:27:55+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/mail.mywebsite.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/mail.mywebsite.com/privkey.pem
  Certificate Name: mywebsite.com
    Serial Number: ###################################
    Key Type: ECDSA
    Domains: mywebsite.com mail.mywebsite.com www.mywebsite.com
    Expiry Date: 2023-12-09 03:09:48+00:00 (VALID: 88 days)
    Certificate Path: /etc/letsencrypt/live/mywebsite.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/mywebsite.com/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Für DNS habe ich A- und AAAA-Einträge für mywebsite.com und *.mywebsite.com, die auf die IPv4- bzw. IPv6-Adressen meines Servers verweisen, sowie einen MX-Eintrag und einige TXT-Einträge für meine Mail-Subdomäne.

A   mywebsite.com   123.123.123.123 600     
A   *.mywebsite.com 123.123.123.123 600     
AAAA    mywebsite.com   1234:1234::1234:1234:1234:1234  600     
AAAA    *.mywebsite.com 1234:1234::1234:1234:1234:1234  600     
MX  mywebsite.com   mail.mywebsite.com  600 10  
TXT _dmarc.mywebsite.com    v=DMARC1; p=reject; rua=mailto:[email protected]; fo=1    600     
TXT mywebsite.com   v=spf1 mx a:mail.mywebsite.com -all 600     
TXT mail._domainkey.mywebsite.com   v=DKIM1; h=sha256; k=rsa; p=#####################################   600 

Antwort1

(hierbei handelt es sich größtenteils um einen Kommentar, aber der Platz ist begrenzt)

Ich möchte, dass der gesamte HTTP-Verkehr auf HTTPS umgeleitet wird.

OK, scheint sinnvoll.

und Verbindungen zur WWW-Subdomain meiner Website und zur IP-Adresse meines Servers (für unsere Zwecke 123.123.123.123) sollten auf mywebsite.com umgeleitet werden

Warum? Ich sehe darin keinen Vorteil und es verhindert praktisch jede Hochverfügbarkeit des Dienstes.

Ja, eine oberflächliche Betrachtung der Konfiguration lässt vermuten, dass sie das tun sollte, was Sie denken. Warum verwenden Sie jedoch verschiedene Serverblöcke, umwww.meinewebsite.comund 123.123.123.123, wenn sie dasselbe Verhalten implementieren? (Tatsächlich könnten Sie das Verhalten für 3 SSL-Vhosts in einem einzigen Serverblock implementieren.) Ebenso benötigen Sie kein separates Zertifikat für mail.mywebsite.com.

Es ist unwahrscheinlich, dass ein Zertifikatsproblem zu einem 404-Fehler führt.

DNS scheint das Naheliegendste zu sein, das überprüft werden muss. Umgekehrt können Sie jedes vorhandene DNS explizit überschreiben und die tatsächlichen HTTP-Header anzeigen, indem Sie beispielsweise Folgendes verwenden:

curl -I -k --resolve \*:443:123.123.123 https://www.example.com

verwandte Informationen