Ubnt 16.04 - NGINX - LetsEncrypt - 502 Bad Gateway для первых пользователей сайта

Я настроил веб-сервер для двух сайтов Wordpress. Установлены NGINX, PHP, Mariadb, certbot для SSL и т. Д.

Проблема, с которой я сталкиваюсь, заключается в том, что если я посетил веб-сайт раньше, чем конфигурация Certbot, я могу получить к нему обычный доступ, загрузить разные страницы, панель администратора, php работает отлично, и все отображается и работает нормально. Тем не менее, если вы новый пользователь, который пытается получить доступ к веб-сайту ( https://liventplanning.com/), вы получите ошибку 502 - Bad Gateway.

Вот файл NGINX error.log:

2018/07/10 14:47:25 [error] 3425#3425: *1628 upstream sent invalid status "Service Unavailable" while reading response header from upstream, client: 37.9.113.120, server: liventplanning.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.0-fpm.sock:", host: "liventplanning.com"

И вот файл NGINX's../sites-available/default (для простоты я удалил все комментарии и большую часть пробелов):

server {
    server_name liventplanning.com;        
    root /var/www/liventplanning;
        index index.php index.html index.htm index.nginx-debian.html;
        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
                # proxy_pass http://localhost:8080;
                # proxy_http_version 1.1;
                # proxy_set_header Upgrade $http_upgrade;
                # proxy_set_header Connection 'upgrade';
                # proxy_set_header Host $host;
                # proxy_cache_bypass $http_upgrade;
        }

        location ~ \.php$ {
               include snippets/fastcgi-php.conf;

               # With php7.0-cgi alone:
               #fastcgi_pass 127.0.0.1:9000;
               # With php7.0-fpm:
               fastcgi_pass unix:/run/php/php7.0-fpm.sock;
        }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/liventplanning.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/liventplanning.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
}


server {
       server_name megalaboratorio.com;
       root /var/www/megalaboratorio;
       index index.php index.html;
       location / {
               try_files $uri $uri/ =404;
       }
    listen [::]:443 ssl; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/liventplanning.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/liventplanning.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

}

server {
        root /var/www/liventplanning;
        index index.php index.html index.htm index.nginx-debian.html;
    server_name www.megalaboratorio.com www.liventplanning.com; # managed by Certbot

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
                # proxy_pass http://localhost:8080;
                # proxy_http_version 1.1;
                # proxy_set_header Upgrade $http_upgrade;
                # proxy_set_header Connection 'upgrade';
                # proxy_set_header Host $host;
                # proxy_cache_bypass $http_upgrade;
        }

        location ~ \.php$ {
               include snippets/fastcgi-php.conf;

               # With php7.0-cgi alone:
               #fastcgi_pass 127.0.0.1:9000;
               # With php7.0-fpm:
               fastcgi_pass unix:/run/php/php7.0-fpm.sock;
        }

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

server {
    if ($host = liventplanning.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

        listen 80 default_server;
        listen [::]:80 default_server;

        server_name liventplanning.com;
    return 404; # managed by Certbot
}

server {
    if ($host = megalaboratorio.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

       listen 80;
       listen [::]:80;

       server_name megalaboratorio.com;
    return 404; # managed by Certbot
}

server {
    if ($host = www.megalaboratorio.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    if ($host = www.liventplanning.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

        listen 80 ;
        listen [::]:80 ;
    server_name www.megalaboratorio.com www.liventplanning.com;
    return 404; # managed by Certbot
}

Любой браузер, который ранее посещал сайт, может использовать его отлично, но если вы новый пользователь, вы получите 502 плохих шлюза.

Может ли кто-нибудь указать мне правильное направление? Я проверил документацию, конфигурационные файлы, форумы и журналы в течение недели, и все еще сбит с толку этим. Спасибо заранее за любую помощь.

1 ответ

Просто чтобы закрыть эту тему, это то, что я узнал.

Виновник, кажется, наполовину WordPress половина ошибки в Nginx. Читая журнал NGINX, я обнаружил, что действие из Wordpress (wp-cron.php) создает задание cron, которое проверяет наличие обновлений Wordpress или плагинов каждый раз, когда пользователь загружает веб-сайт, поэтому при выполнении задания cron Wordpress, похоже, отбрасывает Сокет SSL перед возвратом данных и никогда не уведомляет, если он начался, завершен или что-то еще.

То есть, согласно этому сообщению об ошибке Wordpress. https://core.trac.wordpress.org/ticket/32306

Тем не менее, я отключил SSL, отменил сертификат и все еще имею ту же ошибку 502 Bad Gateway. Через много дней я просто перестрою сервер и установлю стек LAMP вместо стека LEMP, загрузлю последнюю резервную копию Wordpress и, наконец, выпущу новый сертификат Let´s Encrypt.

Другие вопросы по тегам