Używam nginx w chmurze Rackspace po samouczku i po przeszukaniu sieci i jak dotąd nie mogę tego posortować.

Chcę, aby www.mysite.com przechodziła do mysite.com jak zwykle w .htaccess z SEO i innych powodów.

Mój /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;
       }

Próbowałem też

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;
       }

Też próbowałem. Obie drugie próby powodują błędy pętli przekierowania.

if ($host = 'www.example.com' ) {
rewrite ^ http://example.com$uri permanent;
}

Mój DNS jest skonfigurowany standardowo:

site.com 192.192.6.8 A type at 300 seconds
www.site.com 192.192.6.8 A type at 300 seconds

(przykładowe adresy IP i foldery zostały użyte jako przykłady i aby pomóc ludziom w przyszłości). Używam Ubuntu 11.

Rozwiązanie HTTP

Z dokumentacji „właściwym sposobem jest zdefiniowanie osobnego serwera dla 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;
    ...
}

Rozwiązanie HTTPS

Dla tych, którzy chcą rozwiązania, w tym 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...

        }
}

Uwaga: pierwotnie nie https://zawarłem rozwiązania, ponieważ korzystamy z loadbalancerów, a nasz serwer https: // to serwer płatności SSL o dużym ruchu: nie mieszamy https: // i http: //.

Aby sprawdzić wersję nginx, użyj nginx -v.

Usuń www z adresu URL z przekierowaniem 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#
}

Musisz mieć DWIE kody serwerów.

Dodaj www do adresu URL za pomocą przekierowania nginx

Jeśli potrzebujesz czegoś przeciwnego, aby przekierować z domain.com na www.domain.com, możesz użyć tego:

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#
}

Jak możesz sobie wyobrazić, jest odwrotnie i działa tak samo jak w pierwszym przykładzie. W ten sposób nie obniżysz znaków SEO, ponieważ jest to pełne przekierowanie perm i ruch. Brak stron WWW jest wymuszony, a katalog pokazany!

Niektóre z mojego kodu pokazano poniżej dla lepszego widoku:

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;
       }
}

W rzeczywistości nie potrzebujesz nawet przepisywania.

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...
}

Ponieważ moją odpowiedzią jest coraz więcej głosów, ale także powyższe. Nigdy nie należy używać rewritew tym kontekście. Dlaczego? Ponieważ nginx musi przetworzyć i rozpocząć wyszukiwanie. Jeśli używasz return(który powinien być dostępny w dowolnej wersji nginx), to bezpośrednio zatrzymuje wykonywanie. Jest to preferowane w dowolnym kontekście.

Przekieruj zarówno non-SSL, jak i SSL na ich odpowiednik inny niż 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...
}

$schemeZmienna będzie zawierać tylko httpjeśli serwer nasłuchuje tylko na porcie 80 (domyślnie) i opcji nie zawierają słuchać sslsłowa kluczowego. Nieużywanie zmiennej nie przyniesie żadnej wydajności.

Pamiętaj, że potrzebujesz więcej bloków serwerów, jeśli używasz HSTS, ponieważ nagłówki HSTS nie powinny być wysyłane przez niezaszyfrowane połączenia. Dlatego potrzebujesz niezaszyfrowanych bloków serwera z przekierowaniami i szyfrowanych bloków serwera z przekierowaniami i nagłówkami HSTS.

Przekieruj wszystko do SSL (konfiguracja osobista w UNIX z 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...
}

Myślę, że możesz sobie teraz wyobrazić inne związki z tym wzorem.

Więcej moich konfiguracji? Idź tu i tutaj .

Możesz dowiedzieć się, że chcesz użyć tej samej konfiguracji dla większej liczby domen.

Poniższy fragment usuwa www przed dowolną domeną:

if ($host ~* ^www\.(.*)$) {
    rewrite / $scheme://$1 permanent;
}

Potrzebujesz dwóch bloków serwera.

Umieść je w pliku konfiguracyjnym, np /etc/nginx/sites-available/sitename

Powiedzmy, że decydujesz się na http://example.com jako główny adres do użycia.

Twój plik konfiguracyjny powinien wyglądać następująco:

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
}

Pierwszy blok serwera będzie zawierał instrukcje przekierowywania wszelkich żądań z prefiksem „www”. Nasłuchuje żądań adresu URL z prefiksem „www” i przekierowuje.

Nie robi nic więcej.

Drugi blok serwera pomieści twój główny adres - adres URL, którego chcesz użyć. Wszystkie pozostałe ustawienia jak tu iść root, index, location, itd. Sprawdź plik domyślny dla innych ustawień, które można zawrzeć w bloku serwera.

Serwer potrzebuje dwóch rekordów DNS A.

Name: @ IPAddress: your-ip-address (for the example.com URL)

Name: www IPAddress: your-ip-address (for the www.example.com URL)

W przypadku ipv6 utwórz parę rekordów AAAA, używając swojego adresu-ipv6.

Oto jak to zrobić dla wielu nazw serwerów www do no-www (użyłem tego dla subdomen):

server {
        server_name 
             "~^www\.(sub1.example.com)$"
             "~^www\.(sub2.example.com)$"
             "~^www\.(sub3.example.com)$";
         return 301 $scheme://$1$request_uri ;
}

1. Najlepsza praktyka: osobno serverw / hardcodedserver_name

Najlepszą praktyką w przypadku nginx jest użycie oddzielnego serverdla takiego przekierowania (nieudostępnionego w servergłównej konfiguracji), zakodowanie wszystkiego na sztywno i nie używanie wyrażeń regularnych.

Konieczne może być również zakodowanie domen na stałe, jeśli używasz HTTPS, ponieważ musisz z góry wiedzieć, które certyfikaty będziesz zapewniał.

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
}

2. Używanie wyrażeń regularnych w obrębie server_name

Jeśli masz wiele witryn i nie dbasz o najwyższą wydajność, ale chcesz, aby każda z nich miała takie same zasady dotyczące www.prefiksu, możesz użyć wyrażeń regularnych. Najlepsza praktyka korzystania z osobnego servernadal będzie obowiązywać .

Pamiętaj, że to rozwiązanie staje się trudne, jeśli używasz protokołu https, ponieważ musisz mieć jeden certyfikat na wszystkie nazwy domen, jeśli chcesz, aby działał poprawnie.

nie- wwwdo wwww / regex w dedykowanym pojedynczy serverdla wszystkich stron:

server {
    server_name ~^(?!www\.)(?<domain>.+)$;
    return  301 $scheme://www.$domain$request_uri;
}

wwwdo non- wwww / regex w dedykowanym singlu serverdla wszystkich witryn:

server {
    server_name ~^www\.(?<domain>.+)$;
    return  301 $scheme://$domain$request_uri;
}

wwwdo non- wwww / regex w dedykowanym tylko serverdla niektórych witryn:

Konieczne może być ograniczenie wyrażenia regularnego, aby obejmowało tylko kilka domen, wtedy możesz użyć czegoś takiego, aby dopasować www.example.org, www.example.comiwww.subdomain.example.net :

server {
    server_name ~^www\.(?<domain>(?:example\.org|example\.com|subdomain\.example\.net))$;
    return  301 $scheme://$domain$request_uri;
}

Testowanie wyrażeń regularnych w / nginx

Możesz sprawdzić, czy wyrażenie regularne działa zgodnie z oczekiwaniami pcretestw twoim systemie, co jest dokładnie takie samopcre biblioteką, której twój nginx będzie używał do wyrażeń regularnych:

% 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> 

Zauważ, że nie musisz się martwić kropkami ani wielkością liter, ponieważ nginx już się tym zajmuje, tak jak w wyrażeniu regularnym nazwy serwera nginx, gdy nagłówek „Host” ma kropkę końcową .

3. Posyp ifw istniejącymserver / HTTPS:

To ostateczne rozwiązanie na ogół nie jest uważane za najlepszą praktykę, jednak nadal działa i działa.

W rzeczywistości, jeśli używasz HTTPS, to końcowe rozwiązanie może okazać się łatwiejsze w utrzymaniu, ponieważ nie musisz kopiować i wklejać całego zestawu dyrektyw ssl między różnymi serverdefinicjami, a zamiast tego możesz umieścić fragmenty tylko w potrzebnych serwerów, co ułatwia debugowanie i zarządzanie witrynami.

non- wwwto www:

if ($host ~ ^(?!www\.)(?<domain>.+)$) {
    return  301 $scheme://www.$domain$request_uri;
}

wwwdo non- www:

if ($host ~ ^www\.(?<domain>.+)$) {
    return  301 $scheme://$domain$request_uri;
}

zakodować na stałe jedną preferowaną domenę

Jeśli chcesz nieco większej wydajności, a także spójności między wieloma domenami, z których jedna servermoże korzystać, nadal może być sensowne jawne zakodowanie jednej preferowanej domeny:

if ($host != "example.com") {
    return  301 $scheme://example.com$request_uri;
}

Bibliografia:

• http://nginx.org/r/server_name
• http://nginx.org/r/return
• http://nginx.org/en/docs/http/server_names.html

To rozwiązanie pochodzi z mojego osobistego doświadczenia. Użyliśmy kilku segmentów Amazon S3 i jednego serwera do przekierowywania non-wwwdo wwwnazw domen w celu dopasowania do zasad nagłówka S3 „Host” .

Użyłem następującej konfiguracji serwera nginx :

server {
    listen 80;
    server_name ~^(?!www\.)(?<domain>.+)$;
    return 301 $scheme://www.$domain$request_uri;
}

To pasuje do wszystkich nazw domen wskazanych na serwer, zaczynając od cokolwiek oprócz www.i przekierowuje do www.<domain>. W ten sam sposób możesz wykonać przekierowanie przeciwne wwwdo non-www.

Połączyłem najlepsze ze wszystkich prostych odpowiedzi, bez domen zakodowanych na stałe.

301 stałe przekierowanie z non-www na www (HTTP lub HTTPS):

server {
    if ($host !~ ^www\.) {
        rewrite ^ $scheme://www.$host$request_uri permanent;
    }

    # Regular location configs...
}

Jeśli wolisz inne niż HTTPS, inne niż www niż HTTPS, przekierowuj www jednocześnie:

server {
    listen 80;

    if ($host !~ ^www\.) {
        rewrite ^ https://www.$host$request_uri permanent;
    }

    rewrite ^ https://$host$request_uri permanent;
}

Przekieruj non-www na www

W przypadku pojedynczej domeny:

server {
        server_name example.com;
        return 301 $scheme://www.example.com$request_uri;
}

Dla wszystkich domen:

server {
        server_name "~^(?!www\.).*" ;
        return 301 $scheme://www.$host$request_uri;
}

Przekieruj www na inną niż www dla pojedynczej domeny:

server {
        server_name www.example.com;
        return 301 $scheme://example.com$request_uri;
}

Dla wszystkich domen:

server {
         server_name "~^www\.(.*)$" ;
         return 301 $scheme://$1$request_uri ;
}

Spróbuj tego

    if ($host !~* ^www\.){
        rewrite ^(.*)$ https://www.yoursite.com$1;
    }

Inna droga: 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;
}

i www do no-www

server {
  listen       80;
  server_name  www.yoursite.com;
  root /path/;
  index index.php;
  return       301 https://yoursite.com$request_uri;
}

Unikalny format:

server {
  listen 80;
  server_name "~^www\.(.*)$" ;
  return 301 https://$1$request_uri ;
}

location / { 
    if ($http_host !~ "^www.domain.com"){ 
        rewrite ^(.*)$ $scheme://www.domain.com/$1 redirect; 
    } 
}

nie jestem pewien, czy ktokolwiek zauważy, że zwrócenie 301 może być poprawne, ale przeglądarki się do tego dławią

rewrite ^(.*)$ https://yoursite.com$1; 

jest szybszy niż:

return 301 $scheme://yoursite.com$request_uri;

Blog widmo

aby stworzyć zalecaną przez nginx metodę return 301 $scheme://example.com$request_uri;pracy z Ghostem, musisz dodać w głównym bloku serwera:

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;  

Jeśli nie chcesz na stałe kodować nazwy domeny, możesz użyć tego bloku przekierowań. Domena bez wiodącego www jest zapisywana jako zmienna, $domainktórą można ponownie wykorzystać w instrukcji przekierowania.

server {
    ...
    # Redirect www to non-www
    if ( $host ~ ^www\.(?<domain>.+) ) {
       rewrite ^/(.*)$ $scheme://$domain/$1;
    }
}

ODNIESIENIE: Przekierowanie poddomeny z wyrażeniem regularnym w nginx

if ($host ~* ^www.example.com$) {
    return 301 $scheme://example.com$request_uri;
}

Jeśli masz problemy z uruchomieniem tej funkcji, może być konieczne dodanie adresu IP serwera. Na przykład:

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;
}

gdzie XXX.XXX.XXX.XXX to adres IP (oczywiście).

Uwaga: aby poprawnie przekierować żądania https, należy zdefiniować ssl crt i lokalizację klucza

Nie zapomnij zrestartować nginx po dokonaniu zmian:

service nginx restart