NGINX: redirigir a una dirección sin www

NGINX: redirigir a una dirección sin www

Estoy intentando configurar mi sitio web con NGINX. Estoy un poco fuera de mi alcance y he probado todas las soluciones relevantes que pude encontrar, por lo que agradecemos su paciencia :)

Quiero que todo el tráfico http se redirija a https, y las conexiones al subdominio www de mi sitio web y a la dirección IP de mi servidor (123.123.123.123 para nuestros propósitos) deben redirigirse a mywebsite.com. La configuración de mi servidor se encuentra a continuación y cumple con todos estos criterios, excepto la redirección www, que me proporciona una página NGINX 404. Lo que no entiendo es que el manejo de la dirección IP y el subdominio www me parecen idénticos. ¿El problema está en otra parte, como en los certificados DNS o SSL? Gracias.

/etc/nginx/sitios-disponibles/misitio web

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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Para DNS, tengo registros A y AAAA para mywebsite.com y *.mywebsite.com que apuntan a las direcciones ipv4 e ipv6 de mi servidor respectivamente, así como un registro MX y algunos registros TXT para mi subdominio de correo.

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 

Respuesta1

(esto es principalmente un comentario, pero el espacio es limitado)

Quiero que todo el tráfico http se redirija a https,

OK, parece sensato.

y las conexiones al subdominio www de mi sitio web y a la dirección IP de mi servidor (123.123.123.123 para nuestros propósitos) deben redirigir a mywebsite.com

¿Por qué? No veo ningún beneficio en esto y efectivamente cierra la puerta a cualquier alta disponibilidad para el servicio.

Sí, una inspección casual de la configuración sugiere que debería hacer lo que piensas. Sin embargo, ¿por qué estás usando diferentes bloques de servidor para describir?www.misitioweb.comy 123.123.123.123 cuando implementan el mismo comportamiento? (En realidad, podría implementar el comportamiento para 3 hosts virtuales SSL en un solo bloque de servidor). Del mismo modo, no necesita el certificado independiente para mail.mywebsite.com.

Es poco probable que una emisión de certificado provoque un error 404.

DNS parece lo más obvio a verificar/a la inversa, podría anular explícitamente cualquier DNS existente y ver los encabezados HTTP reales usando (por ejemplo):

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

información relacionada