Ubnt 16.04 - NGINX - LetsEncrypt - 502 Недопустимых шлюза для новых пользователей веб-сайта

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

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

Вот error.log NGINX:

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 недопустимых шлюза.

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

0
задан 10 July 2018 в 15:36

1 ответ

Только для закрытия этой темы это - то, что я узнал.

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

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

Тем не менее, я отключил SSL, отменил сертификат, и все еще имейте те же 502 ошибки Недопустимого шлюза. После многих дней я просто восстановлю сервер и установлю стек LAMP вместо стека LEMP, загружу последнее резервное копирование Wordpress, которое было сделано, и наконец выпустите новое, Давайте Зашифруем сертификат.

0
ответ дан 28 October 2019 в 09:14

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

Похожие вопросы: