Question

我们实际上正在尝试设置一个简单的Nginx配置。但是实际上，由于nginx做得很奇怪，我们对这个会议失去了信心：

从昨天开始，我们在干净的Nginx安装中设置了2个子域：

域1：

upstream 430750ef-08ce-4463-bfae-88043ffc7c82-app {
    server localhost:58033;
}

server {
    listen 80;
    listen [::]:80;

    server_name 430750ef-08ce-4463-bfae-88043ffc7c82.app.foobar.com;

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

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name 430750ef-08ce-4463-bfae-88043ffc7c82.app.foobar.com;
    
    ssl on;
    ssl_certificate /etc/letsencrypt/live/430750ef-08ce-4463-bfae-88043ffc7c82.app.foobar.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/430750ef-08ce-4463-bfae-88043ffc7c82.app.foobar.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

    location / {
        proxy_pass http://430750ef-08ce-4463-bfae-88043ffc7c82-app;
        proxy_connect_timeout       1200;
        proxy_send_timeout          1200;
        proxy_read_timeout          1200;
        send_timeout                1200;
        client_max_body_size        100M;
    }
}

域2：


upstream 820528fd-a13f-496a-b124-8973f4367db6-app {
    server localhost:58033;
}

server {
    listen 80;
    listen [::]:80;

    server_name 820528fd-a13f-496a-b124-8973f4367db6.app.foobar.com;

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

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name 820528fd-a13f-496a-b124-8973f4367db6.app.foobar.com;
    
    ssl on;
    ssl_certificate /etc/letsencrypt/live/820528fd-a13f-496a-b124-8973f4367db6.app.foobar.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/820528fd-a13f-496a-b124-8973f4367db6.app.foobar.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

    location / {
        proxy_pass http://820528fd-a13f-496a-b124-8973f4367db6-app;
        proxy_connect_timeout       1200;
        proxy_send_timeout          1200;
        proxy_read_timeout          1200;
        send_timeout                1200;
        client_max_body_size        100M;
    }
}

实际上，我们在域2 上遇到SSL问题：Firefox（以及chrome）都说域2 SSL证书不受信任，因为域2使用的是域证书1，而这一点还没有达到。

我们无法理解为什么 server_name 属性不起作用。从我们的角度来看，当任何访问者达到820528fd-a13f-496a-b124-8973f4367db6.app.foobar.com时，nginx应该使用 domain 2 证书。

还有1个规范：

由于我们正在使用长子域，因此我已将 server_names_hash_bucket_size 更新为512。

“有趣”事实：

当我们将域2 配置文件从 /etc/nginx/sites-enabled/820528fd-a13f-496a-b124-8973f4367db6.conf 重命名为 /etc/nginx/sites-enabled/000-820528fd-a13f-496a-b124-8973f4367db6.conf ，将提供正确的证书。在这种情况下，我们正在考虑，由于找不到原因，nginx使用文件名作为server_name属性，而不是我们在文件中设置的server_name属性，并且出于另一个原因，仅使用在/ etc / nginx / sites-enabled中找到的第一个配置文件。

有什么想法吗？

感谢您的支持，

此致

Nginx-使用conf文件名作为server_name，而不是server_name本身

0 个答案: