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

Question

[Ilya Sayakhov]

Здравствуйте! Нужна помощь. Убил день на то, чтобы настроить 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 , которая и творила весь этот бред. Блин..

Answer 1

[Ilya Sayakhov]

Обнаружил проблему. Оказалось, вообще не в nginx дело было. Это я с настройками django эксперементировал и добавил опцию SECURE_SSL_REDIRECT = True , которая и творила весь этот бред. Блин..

Answer 2

[Юрий]

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.

Comments

[Ilya Sayakhov]

Спасибо за ответ! Да, это опечатка была. Исправил. Смысл в том, что я уже много чего пробовал. Сейчас попробовал так:

upstream sub.example.com {
    server 127.0.0.1:3000 fail_timeot=0;
}
...

А в конфиге gunicorn добавил --bind=127.0.0.1:3000 . Тоже самое -- основной работает, поддомен выдает бесконечный редирект.

[Ilya Sayakhov]

Спасибо за советы! Исправил конфиг. Убрал if, добавил try_files. Но ничего не помогает и опять же бесконечный редирект :(

[Юрий]

Можно исправленный конфиг сабдомена увидеть?

[Ilya Sayakhov]

Да, конечно) благодарю за инициативу)

Конфиг

upstream sub_example_com {
	server 127.0.0.1:3000 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/log/nginx-access.log;

	error_log /var/log/nginx-error.log;

	try_files $uri @sub_example_com;
 
	location / {
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 
		proxy_set_header Host $http_host;

		proxy_redirect off;

		proxy_pass http://sub_example_com;
	}
}

[Ilya Sayakhov]

И сразу вопрос. А можно ли внутри одного upstrem запустить несколько процессов. Я пробовал так (в одном конфиге писал несколько разных server и пытался их запустить), но у меня все запросы шли на основной домен.

[Юрий]

newca9h: Опять какая-то фигня.

try_files $uri @sub_example_com;
Та же самая проблема. Если файл найден - отдаем файл. А если не найден? Что отдавать? В данном случае идет перенаправление на именованный локейшн @sub_example_com. А сам локейшн @sub_example_com нигде не описан. Опять же, из-за отсутствия root, ваш try_files не может найти никаких файлов.
В вашем случае либо try_files вообще не нужен (если есть только один локейшн и все запросы уходят на бэкенд), либо надо еще описать location для тех файлов, которые не надо проксировать на бэкенд, если они имеются.
Ну а дальше - настраиваем log_format и смотрим логи... кто, кого и куда редиректит. И пока можете убрать proxy_set_директивы из основного location. Они сейчас больше захламляют конфиг, чем помогают осознать, что и зачем надо. Насчет log_format - где-то в моих ответах я приводил свой формат лога, с которым я работаю и в котором можно посмотреть взаимодействие с бэкендом (это чтобы исключить неправильный конфиг nginx, если вдруг бэкенд отдает редирект).

[Ilya Sayakhov]

Ок. Понял) сейчас попробую и отпишусь. Спасибо большое!