☰

listen 443 ssl 中断 nginx

tag-icon • tag-icon nginx ssl-certificate https google-cloud-platform certbot
listen 443 ssl 中断 nginx

我在 GCE 虚拟机上安装了 nginx 来托管个人网站。我设置了它，它对于 http 连接非常有效。但是，在安装来自 certbot 的证书后启用 https 会破坏 nginx。

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

    # SSL configuration
    #
    #listen 443 ssl;
    # listen [::]:443 ssl default_server;
    # Note: You should disable gzip for SSL traffic.
    # See: https://bugs.debian.org/773332
    #
    # Read up on ssl_ciphers to ensure a secure configuration.
    # See: https://bugs.debian.org/765782
    #
    # Self signed certs generated by the ssl-cert package
    # Don't use them in a production server!
    #
    # include snippets/snakeoil.conf;

    root /home/Urvish/www;

    # Add index.php to the list if you are using PHP
    index index.html index.htm index.nginx-debian.html;

    server_name openrados.ddns.net;

    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.
        try_files $uri $uri/ =404;
    }


    # pass PHP scripts to FastCGI server
    #
    #location ~ \.php$ {
    #   include snippets/fastcgi-php.conf;
    #
    #   # With php-fpm (or other unix sockets):
    #   fastcgi_pass unix:/run/php/php7.3-fpm.sock;
    #   # With php-cgi (or other tcp sockets):
    #   fastcgi_pass 127.0.0.1:9000;
    #}

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    #   deny all;
    #}

        listen [::]:443 ssl; # managed by Certbot
        listen 443 ssl; # managed by Certbot
        ssl_certificate /etc/letsencrypt/live/openrados.ddns.net/fullchain.pem; # managed by Certbot
        ssl_certificate_key /etc/letsencrypt/live/openrados.ddns.net/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

}

现在，使用 sudo systemctl restart nginx 重新启动 nginx 不再起作用，并出现以下错误：

Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xe" for details.

systemctl status nginx.service 返回以下内容：

● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2020-02-05 12:48:27 UTC; 1min 11s ago
     Docs: man:nginx(8)
  Process: 6208 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
  Process: 6209 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=1/FAILURE)

我该如何解决这个问题？我很困惑。

编辑：

我运行了 nginx -t 并且它返回以下内容：

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

但是，/var/log/nginx/error.log 下的错误日志显示以下内容：

2020/02/05 13:03:29 [emerg] 6392#6392: bind() to [::]:443 failed (98: Address already in use)
2020/02/05 13:03:29 [emerg] 6392#6392: bind() to 0.0.0.0:443 failed (98: Address already in use)
2020/02/05 13:03:29 [emerg] 6392#6392: bind() to [::]:443 failed (98: Address already in use)
2020/02/05 13:03:29 [emerg] 6392#6392: bind() to 0.0.0.0:443 failed (98: Address already in use)
2020/02/05 13:03:29 [emerg] 6392#6392: bind() to [::]:443 failed (98: Address already in use)
2020/02/05 13:03:29 [emerg] 6392#6392: bind() to 0.0.0.0:443 failed (98: Address already in use)
2020/02/05 13:03:29 [emerg] 6392#6392: bind() to [::]:443 failed (98: Address already in use)
2020/02/05 13:03:29 [emerg] 6392#6392: bind() to 0.0.0.0:443 failed (98: Address already in use)
2020/02/05 13:03:29 [emerg] 6392#6392: bind() to [::]:443 failed (98: Address already in use)
2020/02/05 13:03:29 [emerg] 6392#6392: bind() to 0.0.0.0:443 failed (98: Address already in use)
2020/02/05 13:03:29 [emerg] 6392#6392: still could not bind()

答案1

您使用的这些命令实际上都没有描述 nginx 无法重新启动的原因。

当服务失败时，尝试找出 nginx 问题的一个好方法是运行journalctl-u nginx或者nginx -t。这将为您提供有关失败原因的更好线索，并且在您的情况下最有可能指向配置文件错误以及它们所在的行。

最佳做法是尽可能保持配置文件整洁，使用正确的缩进并删除不必要的注释，以使管理更容易一些。

相关内容