newca9h
@newca9h
Software Engineer

Nginx + gunicorn + ssl. Разные конфиги для разных поддоменов на одном сертификате. Это возможно?

Здравствуйте! Нужна помощь. Убил день на то, чтобы настроить nginx так, чтобы он отдавал разные сайты на django с одного ssl сертификата (сертификат поддерживает несколько поддоменов).

Конфиг для основного домена

upstream example.com {
        server unix:/path/to/env/run/gunicorn.sock fail_timeout=0;
}

server {
        listen 443 ssl;
        server_name example.com;

        client_max_body_size 4G;

        ssl on;
        ssl_certificate /path/to/ssl/example.com.crt;
        ssl_certificate_key /path/to/ssl/example.com.key;

        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 5m;
        ssl_prefer_server_ciphers on;

        ssl_stapling on;
        ssl_stapling_verify on;
        ssl_trusted_certificate "/path/to/ssl/ca-certs.pem";
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers 'HIGH:!aNULL:!MD5:!kEDH';
        add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";

        resolver 8.8.8.8 8.8.4.4 valid=300s;
        resolver_timeout 5s;

        access_log /var/logs/nginx-access.log;

        error_log /var/logs/nginx-error.log;
 
        location / {
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                proxy_set_header Host $http_host;
                proxy_redirect off;

                if (!-f $request_filename) {
                        proxy_pass http://example.com;
                        break;
                }
        }
}


Конфиг для поддомена

upstream sub.example.com {
        server unix:/path/to/sub/env/run/gunicorn.sock fail_timeout=0;
}

server {
        listen 443 ssl;
        server_name sub.example.com;

        client_max_body_size 4G;

        ssl on;
        ssl_certificate /path/to/ssl/example.com.crt;
        ssl_certificate_key /path/to/ssl/example.com.key;

        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 5m;
        ssl_prefer_server_ciphers on;

        ssl_stapling on;
        ssl_stapling_verify on;
        ssl_trusted_certificate "/path/to/ssl/ca-certs.pem";
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers 'HIGH:!aNULL:!MD5:!kEDH';
        add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";

        resolver 8.8.8.8 8.8.4.4 valid=300s;
        resolver_timeout 5s;

        access_log /var/logs/nginx-access.log;

        error_log /var/logs/nginx-error.log;
 
        location / {
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                proxy_set_header Host $http_host;
                proxy_redirect off;

                if (!-f $request_filename) {
                        proxy_pass http://sub.example.com;
                        break;
                }
        }
}


На текущий момент основной домен работает, однако поддомен, либо выдает бесконечный редирект, либо грузит основной сайт.

Прошу помощи!

UPDATE: Обнаружил проблему. Оказалось, вообще не в nginx дело было. Это я с настройками django эксперементировал и добавил опцию SECURE_SSL_REDIRECT = True , которая и творила весь этот бред. Блин..
  • Вопрос задан
  • 764 просмотра
Решения вопроса 1
newca9h
@newca9h Автор вопроса
Software Engineer
Обнаружил проблему. Оказалось, вообще не в nginx дело было. Это я с настройками django эксперементировал и добавил опцию SECURE_SSL_REDIRECT = True , которая и творила весь этот бред. Блин..
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
@xtreme
Снимаю порчу по SSH :)
upstream subexample.com {
и
proxy_pass http://sub.example.com;
Тут непонятно, зачем описывать апстрим и не использовать его. Или это опечатка?
Второе - непонятно назначение конструкции:
if (!-f $request_filename) {
  proxy_pass http://sub.example.com;
  break;
}

Читаю так - если файл не существует, то сделать proxy_pass на самого себя и получить бесконечный редирект (это в случае, если там не опечатка и проксится на sub.example.com), либо по http-протоколу обратиться к бэкенду, который висит на сокете и тогда получим фигню, потому что результирующий урл довольно необычного вида http://unix://....
Сразу возникает вопрос... а если файл найден? Откуда его отдать? Других опций как-то не видно.

Я бы порекомендовал:
- не называйте апстримы также, как реальные серверы - одна ошибка и получим непредсказуемое поведение, которое очень сложно отловить. В идеале, апстримы можно назвать одним словом, чтобы не путать с именем сервера.
- Постарайтесь обойтись без if в конфиге, особенно для проверки существования файла. Есть же try_files.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы