Я использую nginx в облаке Rackspace после учебника и просматривая сеть и до сих пор не могу ее отсортировать.
Я хочу, чтобы www.mysite.com перешел на mysite.com как обычно в .htaccess для SEO и других причин.
Мой /etc/nginx/sites-available/www.example.com.vhost config:
server {
listen 80;
server_name www.example.com example.com;
root /var/www/www.example.com/web;
if ($http_host != "www.example.com") {
rewrite ^ http://example.com$request_uri permanent;
}
Я также пробовал
server {
listen 80;
server_name example.com;
root /var/www/www.example.com/web;
if ($http_host != "www.example.com") {
rewrite ^ http://example.com$request_uri permanent;
}
Я тоже пробовал. Обе второй попытки дают ошибки цикла перенаправления.
if ($host = 'www.example.com' ) {
rewrite ^ http://example.com$uri permanent;
}
Мой DNS настроен как стандартный:
site.com 192.192.6.8 A type at 300 seconds
www.site.com 192.192.6.8 A type at 300 seconds
(примеры IP-адресов и папок использовались для примеров и помогали людям в будущем). Я использую Ubuntu 11.
Из документации, "правильный способ - определить отдельный сервер для example.org":
server {
listen 80;
server_name example.com;
return 301 http://www.example.com$request_uri;
}
server {
listen 80;
server_name www.example.com;
...
}
Для тех, кто хочет решение, включая https://
...
server {
listen 80;
server_name www.domain.com;
# $scheme will get the http protocol
# and 301 is best practice for tablet, phone, desktop and seo
return 301 $scheme://domain.com$request_uri;
}
server {
listen 80;
server_name domain.com;
# here goes the rest of your config file
# example
location / {
rewrite ^/cp/login?$ /cp/login.php last;
# etc etc...
}
}
Примечание. Я изначально не включил https://
в мое решение, так как мы используем loadbalancers, а наш https://сервер - это SSL-сервер с высоким трафиком: мы не смешиваем https://и http://.
Чтобы проверить версию nginx, используйте nginx -v
.
Strip www from url с перенаправлением nginx
server {
server_name www.domain.com;
rewrite ^(.*) http://domain.com$1 permanent;
}
server {
server_name domain.com;
#The rest of your configuration goes here#
}
Таким образом, вам нужно иметь два кода сервера.
Добавить www в URL с перенаправлением nginx
Если вам нужно обратное, чтобы перенаправить с domain.com на www.domain.com, вы можете использовать это:
server {
server_name domain.com;
rewrite ^(.*) http://www.domain.com$1 permanent;
}
server {
server_name www.domain.com;
#The rest of your configuration goes here#
}
Как вы можете себе представить, это просто противоположное и работает так же, как в первом примере. Таким образом, вы не снижаете оценки SEO, так как это полная перенаправление и перемещение. Нет WWW принудительно и каталог показан!
server {
server_name www.google.com;
rewrite ^(.*) http://google.com$1 permanent;
}
server {
listen 80;
server_name google.com;
index index.php index.html;
####
# now pull the site from one directory #
root /var/www/www.google.com/web;
# done #
location = /favicon.ico {
log_not_found off;
access_log off;
}
}
На самом деле вам даже не нужно переписывать.
server {
#listen 80 is default
server_name www.example.com;
return 301 $scheme://example.com$request_uri;
}
server {
#listen 80 is default
server_name example.com;
## here goes the rest of your conf...
}
В качестве ответа я получаю все больше голосов, но выше. Вы не должны использовать rewrite
в этом контексте. Зачем? Потому что nginx должен обработать и начать поиск. Если вы используете return
(который должен быть доступен в любой версии nginx), он сразу останавливает выполнение. Это предпочтительнее в любом контексте.
Переназначить как не-SSL, так и SSL для своего не-www-партнера:
server {
listen 80;
listen 443 ssl;
server_name www.example.com;
ssl_certificate path/to/cert;
ssl_certificate_key path/to/key;
return 301 $scheme://example.com$request_uri;
}
server {
listen 80;
listen 443 ssl;
server_name example.com;
ssl_certificate path/to/cert;
ssl_certificate_key path/to/key;
# rest goes here...
}
Переменная $scheme
будет содержать только http
, если ваш сервер только прослушивает порт 80 (по умолчанию), а параметр listen не содержит ключевое слово ssl
. Не использовать переменную не принесет вам никакой производительности.
Обратите внимание, что вам нужно еще больше блоков сервера, если вы используете HSTS, потому что заголовки HSTS не должны отправляться по незашифрованным соединениям. Следовательно, вам нужны незашифрованные серверные блоки с переадресацией и зашифрованными серверными блоками с переадресацией и заголовками HSTS.
Перенаправить все на SSL (личная конфигурация в UNIX с IPv4, IPv6, SPDY,...):
#
# Redirect all www to non-www
#
server {
server_name www.example.com;
ssl_certificate ssl/example.com/crt;
ssl_certificate_key ssl/example.com/key;
listen *:80;
listen *:443 ssl spdy;
listen [::]:80 ipv6only=on;
listen [::]:443 ssl spdy ipv6only=on;
return 301 https://example.com$request_uri;
}
#
# Redirect all non-encrypted to encrypted
#
server {
server_name example.com;
listen *:80;
listen [::]:80;
return 301 https://example.com$request_uri;
}
#
# There we go!
#
server {
server_name example.com;
ssl_certificate ssl/example.com/crt;
ssl_certificate_key ssl/example.com/key;
listen *:443 ssl spdy;
listen [::]:443 ssl spdy;
# rest goes here...
}
Я думаю, вы можете представить себе другие соединения с этим рисунком сейчас.
Вы можете узнать, что хотите использовать одну и ту же конфигурацию для большего количества доменов.
Следующий фрагмент удаляет www перед любым доменом:
if ($host ~* ^www\.(.*)$) {
rewrite / $scheme://$1 permanent;
}
http
на $scheme
Вам нужны два серверных блока.
Поместите их в ваш конфигурационный файл, например /etc/nginx/sites-available/sitename
Допустим, вы решили использовать http://example.com в качестве основного адреса.
Ваш конфигурационный файл должен выглядеть так:
server {
listen 80;
listen [::]:80;
server_name www.example.com;
return 301 $scheme://example.com$request_uri;
}
server {
listen 80;
listen [::]:80;
server_name example.com;
# this is the main server block
# insert ALL other config or settings in this server block
}
Первый блок сервера будет содержать инструкции для перенаправления любых запросов с префиксом "www". Он слушает запросы на URL с префиксом "www" и перенаправляет.
Больше ничего не делает.
Второй блок сервера будет содержать ваш основной адрес - URL, который вы хотите использовать. Все остальные настройки идут здесь, например, root
, index
, location
и т.д. Проверьте файл по умолчанию для этих других настроек, которые вы можете включить в блок сервера.
Серверу нужны две DNS-записи.
Name: @ IPAddress: your-ip-address (for the example.com URL)
Name: www IPAddress: your-ip-address (for the www.example.com URL)
Для ipv6 создайте пару записей AAAA, используя ваш-ipv6-адрес.
Вот как это сделать для нескольких имен серверов www-no-www (я использовал это для поддоменов):
server {
server_name
"~^www\.(sub1.example.com)$"
"~^www\.(sub2.example.com)$"
"~^www\.(sub3.example.com)$";
return 301 $scheme://$1$request_uri ;
}
Это решение исходит из моего личного опыта. Мы использовали несколько кодов Amazon S3 и один сервер для перенаправления доменных имен non-www
в www
в соответствии с S3 "Host" .
Я использовал следующую конфигурацию для сервера nginx:
server {
listen 80;
server_name ~^(?!www\.)(?<domain>.+)$;
return 301 $scheme://www.$domain$request_uri;
}
Это соответствует всем доменным именам, указанным на сервере, начиная с любого, кроме www.
, и перенаправляется на www.<domain>
. Таким же образом вы можете сделать противоположное перенаправление от www
до non-www
.
listen 80
необходимо добавить директивы listen 443 ssl
а затем директивы ssl_certificate
и ssl_certificate_key
.
попробуйте это
if ($host !~* ^www\.){
rewrite ^(.*)$ https://www.yoursite.com$1;
}
Другой способ: Nginx no-www to www
server {
listen 80;
server_name yoursite.com;
root /path/;
index index.php;
return 301 https://www.yoursite.com$request_uri;
}
и www на no-www
server {
listen 80;
server_name www.yoursite.com;
root /path/;
index index.php;
return 301 https://yoursite.com$request_uri;
}
Я объединил лучшие из всех простых ответов, без жестко закодированных доменов.
301 постоянная переадресация с не-www на www (HTTP или HTTPS):
server {
if ($host !~ ^www\.) {
rewrite ^ $scheme://www.$host$request_uri permanent;
}
# Regular location configs...
}
Если вы предпочитаете не-HTTPS, не-www для HTTPS, перенаправление WWW в одно и то же время:
server {
listen 80;
if ($host !~ ^www\.) {
rewrite ^ https://www.$host$request_uri permanent;
}
rewrite ^ https://$host$request_uri permanent;
}
Перенаправить не-www на www
Для одного домена:
server {
server_name example.com;
return 301 $scheme://www.example.com$request_uri;
}
Для всех доменов:
server {
server_name "~^(?!www\.).*" ;
return 301 $scheme://www.$host$request_uri;
}
Перенаправить www на не-www Для одного домена:
server {
server_name www.example.com;
return 301 $scheme://example.com$request_uri;
}
Для всех доменов:
server {
server_name "~^www\.(.*)$" ;
return 301 $scheme://$1$request_uri ;
}
80
и 443
?
listen
Уникальный формат:
server {
listen 80;
server_name "~^www\.(.*)$" ;
return 301 https://$1$request_uri ;
}
server {
server_name "~^www\.(.*)$" ;
return 301 $scheme://$1$request_uri ;
}
location / {
if ($http_host !~ "^www.domain.com"){
rewrite ^(.*)$ $scheme://www.domain.com/$1 redirect;
}
}
$scheme://www.domain.com$1
чтобы избежать двойной косой черты
не уверен, что кто-нибудь заметит, что может быть правильно вернуть 301, но браузер заставляет его делать
rewrite ^(.*)$ https://yoursite.com$1;
быстрее, чем:
return 301 $scheme://yoursite.com$request_uri;
чтобы сделать рекомендованный nginx метод с return 301 $scheme://example.com$request_uri;
работать с Ghost, вам нужно добавить в свой основной серверный блок:
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-NginX-Proxy true;
proxy_pass_header X-CSRF-TOKEN;
proxy_buffering off;
proxy_redirect off;
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, так как у вас должен быть один сертификат, чтобы покрыть все ваши доменные имена, если вы хотите, чтобы это работало должным образом.
www
по www
с regex на отдельном server
для всех сайтов:server {
server_name ~^(?!www\.)(?<domain>.+)$;
return 301 $scheme://www.$domain$request_uri;
}
www
to non- www
w/regex на отдельном выделенном server
для всех сайтов:server {
server_name ~^www\.(?<domain>.+)$;
return 301 $scheme://$domain$request_uri;
}
www
to non- www
w/regex на выделенном 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;
}
Вы можете проверить, что регулярное выражение работает, как и ожидалось, с 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" имеет конечную точку.
if
внутри существующего server
/HTTPS:Это окончательное решение, как правило, не считается лучшей практикой, однако оно все еще работает и выполняет свою работу.
На самом деле, если вы используете HTTPS, то это окончательное решение может оказаться проще в обслуживании, поскольку вам не придется копировать и вставлять целую кучу директив ssl между различными определениями server
, а вместо этого можно размещать только фрагменты на необходимые серверы, что облегчает отладку и поддержку ваших сайтов.
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;
}
if ($host ~* ^www.example.com$) {
return 301 $scheme://example.com$request_uri;
}
Если у вас возникли проблемы с этим, вам может потребоваться добавить IP-адрес вашего сервера. Например:
server {
listen XXX.XXX.XXX.XXX:80;
listen XXX.XXX.XXX.XXX:443 ssl;
ssl_certificate /var/www/example.com/web/ssl/example.com.crt;
ssl_certificate_key /var/www/example.com/web/ssl/example.com.key;
server_name www.example.com;
return 301 $scheme://example.com$request_uri;
}
где XXX.XXX.XXX.XXX - это IP-адрес (очевидно).
Примечание: ssl crt и местоположение ключа должны быть определены для правильной перенаправления запросов https
Не забудьте перезапустить nginx после внесения изменений:
service nginx restart
/etc/init.d/nginx reload
вы также можете reload
сервер, что не вызывает простоев.
Dashboard > Settings > General Settings
и убедитесь, что в URL-адресах WordPress-адресов / адресов сайтов нетwww
. Независимо от того, как вы сконфигурируете свой nginx, если у вас есть www в этих URL, он будет перенаправлен на тот, в котором есть www.