Я установил nginx на виртуальную машину GCE для размещения личного веб-сайта. Я установил его, и он отлично работает для HTTP-соединений. Однако включение https после установки сертификата от certbot нарушило работу 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

}

Теперь перезапуск nginx с помощью sudo systemctl restart 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()
answer

Ни одна из этих команд, которые вы использовали, на самом деле не описывает причину, по которой nginx не может перезапуститься.

Хорошее место, чтобы начать попытки выяснить проблемы nginx при сбое службы, - это запустить journalctl -u nginx или nginx -t . Это даст вам лучшие подсказки относительно того, почему это не удалось, и в вашем случае, скорее всего, укажет на ошибки файла конфигурации и строки, в которых они находятся.

Также рекомендуется сохранять файл конфигурации как можно более аккуратным, с правильными отступами и удаляя ненужные комментарии, чтобы упростить управление.