代码之家  ›  专栏  ›  技术社区  ›  Jerome

nginx冲突服务器名称语法错误

  •  0
  • Jerome  · 技术社区  · 4 年前

    server_name slf.online www.slf.online mrkt.slf.online api.slf.online artterm.slf.online;
    [...]
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/mrkt.slf.online-0001/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/mrkt.slf.online-0001/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
    
    nginx: [warn] conflicting server name "artterm.slf.online" on 0.0.0.0:443, ignored
    

    server_name slf.online www.slf.online mrkt.slf.online api.slf.online;
    nginx -t
    nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
    

    但是流量不是为第三级域路由的。
    我看不出有效的3级域的语法哪里是错误的。

    此域集的配置文件 sites-enabled/slf server 块,其中第二个块由letsencrypt生成,用于将流量重定向到https页:

    if ($host = artterm.slf.online) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
    
    listen 80;
    return 404; # managed by Certbot
    

    我不明白这段代码怎么可能是问题的根源。如果第二个块起作用(为什么没有最后一个条目不会产生忽略情况?)

    另一个配置文件具有相同的第二级域,但具有不同的第三级域

    server_name prva.sfl.online prve.slf.online sales.slf.online;
    

    这是对罪责的另一种假设,但我又一次看不出这种脆弱性从何而来。

    怎样才能克服这个问题?

    0 回复  |  直到 4 年前
        1
  •  0
  •   Jerome    4 年前

    @理查德·史密斯的评论是正确的。

    nginx -T ,提供了nginx的完整配置堆栈,显示Lets Encrypt正在编写证书和 server_name

    这就自然而然地将通信量引向了另一个应用程序的逻辑,而另一个应用程序的逻辑不知道如何处理请求,并将它引向了一个非自退出循环。

    注意:这不是我第一次观察到来自自动化的Let's Encrypt脚本的意外、不稳定的行为。