Наилучшая практика: отдельно server с жестким кодом server_name
Наилучшая практика с nginx - использовать отдельную server для перенаправления, подобногоэто (не используется совместно с server вашей основной конфигурации), чтобы жестко закодировать все и вообще не использовать регулярные выражения.
Может также потребоваться жестко закодировать домены, если вы используете HTTPS, потому чтоВы должны заранее знать, какие сертификаты вы будете предоставлять.
server {
server_name www.example.com;
return 301 $scheme://example.com$request_uri;
}
server {
server_name www.example.org;
return 301 $scheme://example.org$request_uri;
}
server {
server_name example.com example.org;
# real configuration goes here
}
Использование регулярных выражений в server_name
Если у вас несколько сайтов, и вам не нужна максимальная производительность, но вы хотите, чтобы каждый из нихчтобы они имели одинаковую политику в отношении префикса www., тогда вы можете использовать регулярные выражения.Лучшая практика использования отдельного server все еще остается в силе.
Обратите внимание, что это решение становится сложным, если вы используете https, так как вы должны иметь один сертификат, чтобы покрыть все ваши доменные имена, если вы этого хотите.для правильной работы.
non- www до www с регулярным выражением в выделенном сингле server для всех сайтов:
server {
server_name ~^(?!www\.)(?<domain>.+)$;
return 301 $scheme://www.$domain$request_uri;
}
www к не- www с регулярным выражением в выделенном сингле server для всех сайтов:
server {
server_name ~^www\.(?<domain>.+)$;
return 301 $scheme://$domain$request_uri;
}
www к не- www с регулярным выражением в выделенном server только для некоторых сайтов:
Может потребоваться ограничить регулярное выражение только несколькими доменами, тогда вы можете использовать что-то подобное, чтобы соответствовать только www.example.org, www.example.com и www.subdomain.example.net:
server {
server_name ~^www\.(?<domain>(?:example\.org|example\.com|subdomain\.example\.net))$;
return 301 $scheme://$domain$request_uri;
}
Проверка регулярных выражений w / nginx
Вы можете проверить, что регулярное выражение работает, как и ожидалось, с pcretest в вашей системе, которая являетсяточно такая же pcre библиотека, которую ваш nginx будет использовать для регулярных выражений:
% pcretest
PCRE version 8.35 2014-04-04
re> #^www\.(?<domain>(?:example\.org|example\.com|subdomain\.example\.net))$#
data> test
No match
data> www.example.org
0: www.example.org
1: example.org
data> www.test.example.org
No match
data> www.example.com
0: www.example.com
1: example.com
data> www.subdomain.example.net
0: www.subdomain.example.net
1: subdomain.example.net
data> subdomain.example.net
No match
data> www.subdomain.example.net.
No match
data>
Обратите внимание, что выне нужно беспокоиться о конечных точках или регистре, поскольку nginx уже позаботился об этом, согласно регулярному выражению имени сервера nginx, когда заголовок "Host" имеет конечную точку .
Sprinkle if в существующих server / HTTPS:
Это окончательное решение, как правило, не считается наилучшей практикой, однако оно все еще работает и работаетзадание.
На самом деле, если вы используете HTTPS, то это окончательное решение может оказаться проще в обслуживании, поскольку вам не придется копировать и вставлять целый набор директив ssl между различными server определений и может вместо этого размещать фрагменты только на нужные серверы, упрощая отладку и поддержку ваших сайтов.
non- www до www:
if ($host ~ ^(?!www\.)(?<domain>.+)$) {
return 301 $scheme://www.$domain$request_uri;
}
www в non- www:
if ($host ~ ^www\.(?<domain>.+)$) {
return 301 $scheme://$domain$request_uri;
}
жесткое кодирование одного предпочтительного домена
Если вы хотите немного большей производительности, какКроме согласованности между несколькими доменами, которые может использовать один server, все же может иметь смысл явно жестко кодировать один предпочтительный домен:
if ($host != "example.com") {
return 301 $scheme://example.com$request_uri;
}
Ссылки: