Проблемы с перенаправлением старых URL-адресов сайтов на новые URL-адреса сайтов с помощью NGINX
Я пытался изменить базовые URL-адреса в моем стеке Atlassian с небольшим успехом. Сервер Ubuntu 16.04LTS с обратным прокси Nginx. Внутренние и внешние IP-адреса назначаются различным сетевым картам. Да, этот же вопрос опубликован в stackoverflow, но я решил, что постараюсь получить максимальную отдачу от него.
Пример файла сервера Nginx:
server {
listen 80;
listen 443 ssl;
server_name projects.old-site.com;
access_log off;
return 301 $scheme://projects.new-site.com;
}
server {
listen 80;
server_name projects.new-site.com;
access_log off;
client_max_body_size 100M;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name projects.new-site.com;
client_max_body_size 100M;
ssl_certificate /path/to/new-site.crt;
ssl_certificate_key /path/to/new-site.key;
location /
...output omitted
Что работает: перенаправления HTTP и перенаправления HTTP на HTTPS. http://projects.old-site.com правильно перенаправляет на https://projects.new-site.com . Прямой доступ, набрав просто http://projects.new-site.com (также правильно перенаправляет на HTTPS).
Что не происходит: https://projects.old-site.com - https://projects.new-site.com перенаправление.
Еще более странно, что при попытке доступа к https://projects.old-site.com для проверки перенаправления браузеры не только продолжают обслуживаться .old-site.com, но и обслуживается просроченный сертификат SSL для этого домена.
Нигде в моей системе сертификаты с истекшим сроком действия не доступны на этом сервере. Я следовал руководству по обновлению URL Atlassian, меняя только файлы server.xml и на экранах администрирования приложений (когда они доступны). Все DNS-серверы указывают на правильные IP-адреса. Я определенно что-то упускаю, но в растерянности. Это было повторено на двух разных серверах Ubuntu 16.04 с установленным Nginx и одинаковыми версиями программного обеспечения Atlassian.
Пожалуйста, помогите.
1 ответ
У вас есть некоторые проблемы с вашими конфигурациями.
Мы рассмотрим каждый отдельный блок сервера здесь индивидуально.
Блок # 1: projects.old-site.com -> перенаправление projects.new-site.com
Это то, что вы нам предоставили:
server {
listen 80;
listen 443 ssl;
server_name projects.old-site.com;
access_log off;
return 301 $scheme://projects.new-site.com;
}
Вам не хватает здесь лота вещей для настройки: директива
-
ssl_certificate- необходимо знать, какой сертификат SSL следует служить для домена. - Директива
ssl_certificate_key- файл ключа сертификата SSL, который соответствует сертификату SSL для сайта «старых» проектов.
Вы делаете перенаправление 301, чтобы соответствовать схеме, но почему вы делаете это, если вы перенаправляете не-SSL на SSL в блоке сервера 2? Просто перенаправьте на сайт HTTPS, и включают $request_uri по очевидным причинам (вы не пропускаете тот же URI запроса, поэтому все не работает должным образом).
Ваш правильный серверный блок здесь должен выглядеть примерно так:
server {
listen 80;
listen 443 ssl;
server_name projects.old-site.com;
ssl_certificate /path/to/valid/projects.old-site.com/certificate;
ssl_certificate_key /path/to/valid/projects.old-site.com/certificate.key;
access_log off;
return 301 https://projects.new-site.com$request_uri;
}
Блок # 2: http -> перенаправление https для projects.new-site .com
Вы дали нам это:
server {
listen 80;
server_name projects.new-site.com;
access_log off;
client_max_body_size 100M;
return 301 https://$host$request_uri;
}
У вас не так много проблем, но давайте попробуем не не принимать $host глобально здесь (нам это не нужно, мы знаем, где мы хотим, чтобы это закончилось), и нам также не нужно client_max_body_size. 301 перенаправления не уважают это все равно.
Вы должны закончить с этим:
server {
listen 80;
server_name projects.new-site.com;
access_log off;
return 301 https://projects.new-site.com$request_uri;
}
Блок № 3: https://projects.new-site.com
Теперь для вашего третий блок. * Без всего блока сервера и всех его директив конфигурации мы не можем должным образом помочь с настройкой блока.
Вы дали нам это:
server {
listen 443 ssl;
server_name projects.new-site.com;
client_max_body_size 100M;
ssl_certificate /path/to/new-site.crt;
ssl_certificate_key /path/to/new-site.key;
...
}
В этом блоке нет ничего действительно плохого, однако, если вам не нужна директива client_max_body_size для вашего внутреннего приложения, вам, вероятно, следует удалить его .