Рейтинг:1

Веб-сайт NginX возвращает страницу по умолчанию с HTTP (HTTPS работает правильно)

флаг br

Этот имеет быть дубликатом, но я долго искал и ничего не нашел.

Когда я ввожу адрес своего веб-сайта, используя http, я получаю Страница NginX по умолчанию (https работает нормально):

http://svija.love

Файл конфигурации NginX содержит в конце:

сервер {
    если ($host = svija.love) {
        вернуть 301 https://$host$request_uri;
    } # управляется Certbot

    имя_сервера svija.love;
    слушать 80;
    вернуть 404; # под управлением Certbot
}

Это было автоматически добавляется Certbot.

Я ожидаю, что заявление если ($host = svija.love) будет перехватывать http-запрос и перенаправлять на HTTPS.

Но это не работает таким образом.

Не будучи специалистом, мне кажется, что второй бит, начинающийся с server_name svija.love, находится в прямом противоречии с первой частью:

  • первый блок перенаправляет, если хост svija.love
  • второй блок возвращает 404, если хост svija.love

Фактическое сконфигурированное имя сервера live.svija.love, если это имеет значение.

Мы будем очень признательны за любые разъяснения.

[ОБНОВИТЬ] Я удалил файл конфигурации NginX по умолчанию, и HTTP теперь перенаправляется на HTTPS, как и ожидалось.

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

[ОБНОВИТЬ] Это не было хорошим решением (см. ниже).

[ОБНОВИТЬ Вот конфиг предоставленный нгинкс-Т:

# файл конфигурации /etc/nginx/nginx.conf:
www-данные пользователя;
рабочие_процессы авто;
pid /run/nginx.pid;
включить /etc/nginx/modules-enabled/*.conf;

События {
    worker_connections 768;
    # multi_accept on;
}

http {

    ##
    # Основные настройки
    ##

    отправка файла выключена;
    tcp_nopush включен;
    tcp_nodelay включен;
    keepalive_timeout 65;
    типы_хэш_макс_размер 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    включить /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # Настройки SSL
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Удаление SSLv3, ссылка: POODLE
    ssl_prefer_server_ciphers включен;

    ##
    # Настройки ведения журнала
    ##

    журнал_доступа /var/log/nginx/access.log;
    журнал_ошибок /var/log/nginx/error.log;

    ##
    # Настройки Gzip
    ##

    gzip включен;

    # gzip_vary on;
    # gzip_proxyed любой;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Конфигурации виртуального хоста
    ##

    включить /etc/nginx/conf.d/*.conf;
    включить /etc/nginx/sites-enabled/*;
}

# файл конфигурации /etc/nginx/modules-enabled/50-mod-http-image-filter.conf:
модули загрузки_модуля/ngx_http_image_filter_module.so;

# файл конфигурации /etc/nginx/modules-enabled/50-mod-http-xslt-filter.conf:
модули load_module/ngx_http_xslt_filter_module.so;

# файл конфигурации /etc/nginx/modules-enabled/50-mod-mail.conf:
модули load_module/ngx_mail_module.so;

# файл конфигурации /etc/nginx/modules-enabled/50-mod-stream.conf:
модули load_module/ngx_stream_module.so;

# файл конфигурации /etc/nginx/mime.types:

сервер {

    # должно совпадать с доменным именем или IP-адресом
    # иначе будет показана страница Nginx по умолчанию
    имя_сервера antretoise.svija.site;

    # каталог статических элементов сайта
    местоположение /статическое/ {
        корень /дом/антретуаз;
    }

    журнал_доступа /opt/logs/access.antretoise;
    error_log /opt/logs/error.antretoise ошибка;

    # передаем все дополнительные запросы нашему приложению
    место расположения / {

        # параметры из /etc/nginx/uwsgi_params
        включить uwsgi_params;

        # пропускаем трафик на сокет
        # который настраивает сервер uWSGI
        # СОКЕТЫ ДОЛЖНЫ СОВПАДАТЬ В:
        # /etc/uwsgi/sites/antretoise.ini
        uwsgi_pass unix:/run/uwsgi/antretoise.sock;
    }

    слушать 443 ssl; # под управлением Certbot
    ssl_certificate /etc/letsencrypt/live/antretoise.svija.site/fullchain.pem; # под управлением Certbot
    ssl_certificate_key /etc/letsencrypt/live/antretoise.svija.site/privkey.pem; # под управлением Certbot
    включить /etc/letsencrypt/options-ssl-nginx.conf; # под управлением Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # под управлением Certbot

}


сервер {
    если ($host = antretoise.svija.site) {
        вернуть 301 https://$host$request_uri;
    } # управляется Certbot


    слушать 80;
    имя_сервера antretoise.svija.site;
    вернуть 404; # под управлением Certbot


}
# файл конфигурации /etc/nginx/uwsgi_params:

uwsgi_param QUERY_STRING $query_string;
uwsgi_param REQUEST_METHOD $request_method;
uwsgi_param CONTENT_TYPE $content_type;
uwsgi_param CONTENT_LENGTH $content_length;

uwsgi_param REQUEST_URI $request_uri;
uwsgi_param PATH_INFO $document_uri;
uwsgi_param DOCUMENT_ROOT $document_root;
uwsgi_param SERVER_PROTOCOL $server_protocol;
uwsgi_param REQUEST_SCHEME $схема;
uwsgi_param HTTPS $https if_not_empty;

uwsgi_param REMOTE_ADDR $remote_addr;
uwsgi_param REMOTE_PORT $remote_port;
uwsgi_param SERVER_PORT $server_port;
uwsgi_param ИМЯ_СЕРВЕРА $server_name;

общий ssl_session_cache: le_nginx_SSL: 10 м;
ssl_session_timeout 1440 м;
ssl_session_tickets выключен;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers выключен;

ssl_ciphers "EC-AES128-SHA";

# â â â â â â â â â â â â â â â ââ *** âââââââ по умолчанию

сервер {
    слушать 80 default_server;
    слушать [::]:80 default_server;

    корень /var/www/html;

    # Добавьте index.php в список, если вы используете PHP
    индекс index.html index.htm index.nginx-debian.html;

    имя сервера _;

    место расположения / {
        # Сначала пытаемся обслужить запрос как файл, затем
        # в качестве каталога, затем вернуться к отображению 404.
        try_files $uri $uri/ =404;
    }

}

# â â â â â â â â â â â â â â â ââ *** ❤ svija.love

сервер {

    имя_сервера svija.love;

    # каталог статических элементов сайта
    местоположение /статическое/ {
        корень /home/svijalove;
    }

    журнал_доступа /opt/logs/access.svijalove;
    error_log /opt/logs/error.svijalove ошибка;

    # передаем все дополнительные запросы нашему приложению
    место расположения / {

        # параметры из /etc/nginx/uwsgi_params
        включить uwsgi_params;

        # пропускаем трафик на сокет
        # который настраивает сервер uWSGI
        # СОКЕТЫ ДОЛЖНЫ СОВПАДАТЬ В:
        # /etc/uwsgi/sites/svijalove.ini
        uwsgi_pass unix:/run/uwsgi/svijalove.sock;
    }

    слушать 443 ssl; # под управлением Certbot
    ssl_certificate /etc/letsencrypt/live/svija.love/fullchain.pem; # под управлением Certbot
    ssl_certificate_key /etc/letsencrypt/live/svija.love/privkey.pem; # под управлением Certbot
    включить /etc/letsencrypt/options-ssl-nginx.conf; # под управлением Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # под управлением Certbot
}

сервер {
    если ($host = svija.love) {
        вернуть 301 https://$host$request_uri;
    } # управляется Certbot

    имя_сервера svija.love;
    слушать 80;
    вернуть 404; # под управлением Certbot
}

# 6 других сайтов в конце, все настроены одинаково
# за исключением того, что в последних двух строках
# слушать 80; иногда указывается ПЕРЕД возвратом 404;
флаг in
К вашему сведению: когда я запрашиваю `http://svija.love`, я получаю перенаправление на `https://svija.love/`, что приводит к 500. После этого wget повторяет второй запрос и получает 200. Я не получить 404. Для 500 вам нужно проверить журналы вашего сервера.
флаг br
Как вы сделали запрос? Я понимаю, что неправильно сформулировал проблему - я получаю не 404 (в своем браузере), а страницу по умолчанию NginX (я исправил вопрос). Я не вижу ошибки 500, но я проверю журнал.
флаг in
Простой `wget -S http://svija.love`
флаг br
Я удалил стандартную конфигурацию NginX, и теперь он правильно перенаправляет. Я предполагаю, что это произошло из-за того, что он интерпретировал конфигурацию по умолчанию, прежде чем перейти к конфигурации svija.love.
флаг us
Пожалуйста, добавьте полную конфигурацию nginx, которая задается командой `nginx -T`.
флаг us
Мое единственное предположение состоит в том, что блок «if» перед «server_name» каким-то образом мешает nginx. Обычно я начинаю блок `server` с `listen`, `server_name` сверху для удобочитаемости, а затем с другими директивами.
флаг us
Другой вариант отладки — включить журналы отладки nginx с помощью `error_log /opt/logs/error.antretoise debug;` В зависимости от дистрибутива может потребоваться запуск nginx с помощью другой команды. С журналом отладки можно увидеть, как именно nginx обрабатывает запрос внутри.
флаг br
Я потратил пару часов на просмотр журналов и безуспешно пробовал различные модификации файлов конфигурации. В конце концов он начал работать с исходной конфигурацией (см. ответ, который я опубликовал) — возможно, какая-то проблема с кэшированием DNS. Спасибо за ваши предложения, они дали мне смелость продолжать попытки и идеи, что попробовать.
Рейтинг:2
флаг us

Если нет соответствующего виртуального хоста для Хозяин заголовок в запросе, тогда nginx будет обслуживать содержимое виртуального хоста по умолчанию.

В вашем случае ваш виртуальный хост соответствует Хозяин поле с svija.love. Однако, кажется, вы тестировали с live.svija.love.

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

После того, как вы удалили конфигурацию виртуального хоста по умолчанию, nginx использует ваш виртуальный хост в качестве виртуального хоста по умолчанию. Это не очень хорошая практика. Любой может настроить DNS-запись для домена, который указывает на ваш сайт. Конечным результатом будет то, что http://example.com покажет содержимое http://live.svija.love.

Это может привести к штрафам Google за дублированный контент.

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

флаг br
Я не тестировал с live.svija.love — это имя сервера (/etc/hosts), но я никогда не пытался посетить сервер по этому адресу. Я верну настройку по умолчанию, как вы предлагаете, и посмотрю, смогу ли я заставить ее работать на основе вашего ответа.
флаг br
Теперь, когда я посещаю svija.love, я снова получаю страницу по умолчанию NginX. Чего я не понимаю, так это почему svija.love не соответствует «if ($host = svija.love) {» в конфигурации.
флаг br
Я добавил к вопросу полную конфигурацию nginx.
Рейтинг:0
флаг br

Я решил проблему, не понимая ее.

На моем сервере есть семь веб-сайтов, и шесть из них работают правильно (http перенаправляет на https, как и ожидалось).

Все семь сайтов содержат блок в конце файлов конфигурации NginX, похожий на этот:

сервер {

# перенаправляет трафик с http на https для каждого релевантного домена

    если ($host = svija.love) {
        вернуть 301 https://$host$request_uri;
    } # управляется Certbot

# гарантирует, что любые пойманные запросы не будут непреднамеренно перенаправлены

    слушать 80;
    имя_сервера svija.love;
    вернуть 404; # под управлением Certbot
}

Фактический хост сервера live.svija.love, но сайт, на котором возникли проблемы, просто svija.love (нет веб-сайта, настроенного для live.svija.love).

Стало очевидно, что проблема была вызвана неправильной оценкой следующей строки:

если ($host = svija.love) {

В скобках не было конфигурации IPv6 для сервера (live.svija.love) и была конфигурация IPv6 для веб-сайта (svija.love), которой не должно было быть.

Я добавил запись IPv6 для сервера и удалил ее для веб-сайта.
На проблему это не повлияло.

Тогда я подумал, что, возможно, $хост переменная была установлена ​​в live.svija.love (кто знает почему), поэтому я попробовал тест, где я изменил

если ($host = svija.love) {

к

если ($host = live.svija.love) {

Как и ожидалось, стандартная страница NginX была заменена ошибкой 404 (см. блок конфигурации выше).

Итак, я положил обратно

если ($host = live.svija.love) {

и все теперь работает корректно. HTTP-запросы к svija.love перенаправляются на https://svija.love и моя проблема решена.

Я предполагаю, что в NginX был какой-то механизм кэширования DNS, который не работал, возможно, из-за того, что я изменил имя сервера в какой-то момент в прошлом.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.