видать где-то ошибка. то ли в конфигах что-то не то с адресом, портом или сокетом; то ли приложение и вовсе не запущено; а может что-то другое.
надо смотреть конфиги, читать логи.
MIHUTKA, и тем не менее финальный результат - 502, не так ли? значит нужно разбираться, в чём же дело, разве нет?
надо смотреть конфиги, читать логи.
502 как правило намекает на то, что указанный в proxy_pass апстрим недоступен. следовательно, первым делом я бы проверил, есть ли файл /run/gunicorn.sock; какие на нём права; правильно ли написана директива proxy_pass в nginx; запущен ли gunicorn сервис; какой WorkingDirectory указан в файле сервиса; существует ли этот каталог действительно; существует ли в нём подкаталог, указанный в STATIC_ROOT приложения; какие на нём права; отдаётся ли какой-либо файл из этого каталога, если выполнить к nginx GET-запрос на отдачу этого файла (с учётом того, что в URL надо не забыть использовать STATIC_URL из конфигурации приложения).
MIHUTKA, логи nginx обычно в /var/log, если только вы не переопределили этот путь директивой access_log в конфиге nginx. лог сервиса gunicorn - там, где указано в статье: в journalctl -u gunicorn.
MIHUTKA, соединение HTTPS обеспечивает Nginx. Nginx работает исправно - поэтому соединение есть, HTTP трафик идёт. Сообщение "Welcome to nginx!" генерируется Nginx-ом, прописано в его коде.
Вместо "поиска ключей под фонарём" смотрите логи программы.
Попробуйте просто руками запустить
активировать env при необходимости и порт не 8000 чтоб наверняка
python manage.py runserver 0.0.0.0:8001
и проверьте вообще запускается ли приложение или там ошибки
и попробуйте к нему достучаться ip:8001 (где ip это адрес сервера ну или через домен domen.ru:8001 если настроено), если все норм, тогда смотрите логи и запуск гуникорном (запуск приложения и открытие сокета), и если всё это ОК то ищите ошибку в конфиге NGINX
НО скорей всего у вас ошибка в gunicorn.service
Простой
