Nginx no-www zu www und www zu no-www


497

Ich verwende Nginx in der Rackspace-Cloud nach einem Tutorial und habe das Internet durchsucht und kann dies bisher nicht sortieren.

Ich möchte, dass www.mysite.com aus SEO- und anderen Gründen wie gewohnt in .htaccess zu mysite.com wechselt.

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

Ich habe es auch versucht

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

Ich habe es auch versucht. Beide zweiten Versuche führen zu Umleitungsschleifenfehlern.

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

Mein DNS ist standardmäßig eingerichtet:

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

(Beispiel-IPs und -Ordner wurden als Beispiele verwendet, um Menschen in Zukunft zu helfen.) Ich benutze Ubuntu 11.


1
Ich bin gezwungen zu kommentieren, dass, wenn Sie mit einer WordPress-Website arbeiten, überprüfen Sie die Dashboard > Settings > General Settingsund stellen Sie sicher, dass wwwdie URLs der WordPress-Adresse / Site-Adresse keine enthalten . Unabhängig davon, wie Sie Ihren Nginx konfigurieren, wird ein WWW in diesen URLs zu dem mit dem WWW umgeleitet.
Abhinav Sood

Antworten:


792

HTTP-Lösung

Aus der Dokumentation geht hervor , dass "der richtige Weg darin besteht, einen separaten Server für example.org zu definieren":

server {
    listen       80;
    server_name  example.com;
    return       301 http://www.example.com$request_uri;
}

server {
    listen       80;
    server_name  www.example.com;
    ...
}

HTTPS-Lösung

Für diejenigen, die eine Lösung suchen, einschließlich 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...

        }
}

Hinweis: Ich habe https://meine Lösung ursprünglich nicht aufgenommen , da wir Loadbalancer verwenden und unser https: // Server ein stark frequentierter SSL-Zahlungsserver ist. Wir mischen https: // und http: // nicht.


Verwenden Sie zum Überprüfen der Nginx-Version nginx -v.

Entfernen Sie www von der URL mit Nginx Redirect

server {
    server_name  www.domain.com;
    rewrite ^(.*) http://domain.com$1 permanent;
}

server {
    server_name  domain.com;
    #The rest of your configuration goes here#
}

Sie benötigen also ZWEI Servercodes.

Fügen Sie das www zur URL mit Nginx Redirect hinzu

Wenn Sie das Gegenteil benötigen, um von domain.com zu www.domain.com umzuleiten, können Sie Folgendes verwenden:

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

Wie Sie sich vorstellen können, ist dies genau das Gegenteil und funktioniert genauso wie im ersten Beispiel. Auf diese Weise erhalten Sie keine SEO-Markierungen, da es sich um eine vollständige Umleitung und Verschiebung von Dauerwellen handelt. Das kein WWW wird erzwungen und das Verzeichnis angezeigt!

Einige meiner unten gezeigten Codes dienen zur besseren Übersicht:

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

3
@puk schätzen es. Nginx ist erstaunlich, aber eine gute Dokumentation, die mit der Serverversion und den Änderungen an Betriebssystem und Serverhardware auf dem neuesten Stand bleibt, ist ziemlich mühsam. Die beste Ressource, die mir zur Verfügung steht, ist howtoforge.com, da es die RackSpace-Cloud-Versionen unterstützt. Einige der oben genannten Befehle funktionieren in späteren Versionen nicht. Aber dieser Nginx / 0.8.54 - glauben Sie mir, der beste Nginx-Server) muss nicht aktualisiert oder aktualisiert werden. Funktioniert gut. 100.000 eindeutige Treffer pro Tag mit durchschnittlich 4200 Transaktionen pro Tag. Nginx ist SCHNELL. wie eine Website ohne Verkehr.
TheBlackBenzKid

17
Ihre Umschreibungen sollten wie in Retouren werden return 301 $scheme://domain.com$request_uri;. Es ist nicht erforderlich, Muster zu erfassen, siehe Nginx-Fallstricke
Roberto

4
@TheBlackBenzKid Entschuldigung, vielleicht habe ich etwas verpasst, aber die aktualisierte Lösung funktioniert nicht. Das liegt daran, dass Sie 80 hören - damit sagen Sie, dass nur HTTP dazu passt. Es sollten mehr Ports zum Abhören vorhanden sein, wenn dieselbe Konfiguration für HTTP und HTTPS verwendet wird ... Oder? Aber auf jeden Fall hat mir geholfen, +1. Danke für die Antwort. Prost.
Tomis

3
@ TheBlackBenzKid Es war nur eine Notiz. Ich habe eine funktionierende Lösung gefunden. In Ihrem Beispiel sollte nur Listen 443 hinzugefügt werden und die Arbeit abschließen.
Tomis

2
Antwort ist falsch. Es leitet alle Subdomains an www weiter.
r3wt

398

Eigentlich brauchen Sie nicht einmal ein Umschreiben.

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

Da meine Antwort immer mehr Stimmen bekommt, aber auch die oben genannten. Sie sollten rewritein diesem Zusammenhang niemals ein verwenden . Warum? Weil nginx eine Suche verarbeiten und starten muss. Wenn Sie verwenden return(was in jeder Nginx-Version verfügbar sein sollte), wird die Ausführung direkt gestoppt. Dies ist in jedem Kontext bevorzugt.

Leiten Sie sowohl Nicht-SSL als auch SSL zu ihrem Nicht-WWW-Gegenstück um:

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

Die $schemeVariable enthält nur, httpwenn Ihr Server nur Port 80 überwacht (Standard) und die Option listen das sslSchlüsselwort nicht enthält . Wenn Sie die Variable nicht verwenden, erhalten Sie keine Leistung.

Beachten Sie, dass Sie bei Verwendung von HSTS noch mehr Serverblöcke benötigen, da die HSTS-Header nicht über unverschlüsselte Verbindungen gesendet werden sollten. Daher benötigen Sie unverschlüsselte Serverblöcke mit Weiterleitungen und verschlüsselte Serverblöcke mit Weiterleitungen und HSTS-Headern.

Leiten Sie alles auf SSL um (persönliche Konfiguration unter UNIX mit 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...
}

Ich denke, Sie können sich jetzt selbst andere Verbindungen mit diesem Muster vorstellen.

Mehr von meinen Konfigurationen? Geh hier und hier .


3
Wenn Sie HSTS verwenden, sollte Ihr Chrome nicht in der Lage sein, auf Ihre WWW- Domain zuzugreifen. Bitte öffnen Sie eine neue Frage mit möglichst vielen Details und ich werde Ihnen helfen (Sie können die URL zur Frage hier als Kommentar posten).
Fleischwolf

1
@Fleshgrinder Ich versuche, Ihr Setup zu implementieren, erhalte jedoch das folgende Problem unter stackoverflow.com/questions/29451409/…. Haben Sie Ideen, wie es funktioniert?
YPCrumble

4
Im zweiten Block "Beide, Nicht-SSL und SSL an ihr Nicht-WWW-Gegenstück umleiten:" sollten beide Serverblöcke die SSL-Anweisungen haben, da der Browser das Zertifikat für www.example.com überprüfen muss, bevor er zum Beispiel umleitet .com.
Jeff Tsay

1
Natürlich habe ich das hinzugefügt sowie eine kurze Info über HSTS.
Fleischwolf

1
@YPCrumble Ja, auf diese Weise ist es VIEL schneller, da wir nicht bei jeder Anforderung einen Abgleich für reguläre Ausdrücke durchführen. Wir leiten nur um, wenn wir wissen, dass wir umleiten müssen. Keine Überprüfungen, keine Validierung, nichts: nur umleiten. =)
Fleischfresser

37

Möglicherweise stellen Sie fest, dass Sie dieselbe Konfiguration für weitere Domänen verwenden möchten.

Das folgende Snippet entfernt www vor einer Domain:

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

7
Ich mag diesen Weg besser als dedizierte Serverblöcke. Wechseln Sie httpzu$scheme
ck_

2
Viel besser, ich kann nicht glauben, dass so viele Domänen für diese Aufgabe in Konfigurationen fest codiert werden.
MrYellow

1
@Oli Dieser Link erwähnt (bis heute) nicht die Leistung, sondern dass sie nicht 100% sicher sind. Es heißt "Die einzigen 100% sicheren Dinge, die im Kontext eines Standorts ausgeführt werden können, sind: return ...und rewrite ... last". Aktualisierte Links zu Leistungsproblemen?
Adam

1
Das hat bei mir nicht funktioniert. Es wurde immer ein Fehler im Browser angezeigt, der eine ungültige Antwort angab.
Nico Brenner

1
Leider habe ich keinen Weg ohne "wenn" gefunden. Ich verwende dieselbe Konfiguration für viele Domänen. Die Hardcodierung der Domänennamen ist keine Option. Jeder Vorschlag / Kommentar wird geschätzt!
Martin Höger

27

Sie benötigen zwei Serverblöcke.

Fügen Sie diese in Ihre Konfigurationsdatei ein, z /etc/nginx/sites-available/sitename

Angenommen, Sie entscheiden sich für http://example.com als Hauptadresse verwenden.

Ihre Konfigurationsdatei sollte folgendermaßen aussehen:

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
}

Der erste Serverblock enthält die Anweisungen zum Umleiten von Anforderungen mit dem Präfix 'www'. Es lauscht auf Anfragen nach der URL mit dem Präfix 'www' und leitet um.

Sonst macht es nichts.

Der zweite Serverblock enthält Ihre Hauptadresse - die URL, die Sie verwenden möchten. Alle anderen Einstellungen gehen hier wie rootfolgt index:location usw. die Standarddatei für diese anderen Einstellungen Überprüfen Sie im Server - Block enthalten.

Der Server benötigt zwei DNS A-Einträge.

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

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

Erstellen Sie für IPv6 das Paar AAAA-Einträge mit Ihrer IPv6-Adresse.


23

So geht's für mehrere WWW- bis No-WWW-Servernamen (ich habe dies für Subdomains verwendet):

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

20
  1. Best Practice: separat servermit fest codiertserver_name

Die beste Vorgehensweise bei Nginx besteht darin, serverfür eine solche Umleitung eine separate zu verwenden (die nicht mit der serverHauptkonfiguration geteilt wird), alles fest zu codieren und überhaupt keine regulären Ausdrücke zu verwenden.

Es kann auch erforderlich sein, die Domänen fest zu codieren, wenn Sie HTTPS verwenden, da Sie im Voraus wissen müssen, welche Zertifikate Sie bereitstellen.

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
}

  1. Verwenden von regulären Ausdrücken innerhalb von server_name

Wenn Sie über eine Reihe von Websites verfügen und sich nicht für die ultimative Leistung interessieren, aber möchten, dass jede einzelne von ihnen dieselbe Richtlinie in Bezug auf das www.Präfix hat, können Sie reguläre Ausdrücke verwenden. Die beste Vorgehensweise bei der Verwendung eines separaten Geräts serverwürde weiterhin bestehen bleiben.

Beachten Sie, dass diese Lösung schwierig wird, wenn Sie https verwenden, da Sie dann über ein einziges Zertifikat verfügen müssen, um alle Ihre Domain-Namen abzudecken, damit dies ordnungsgemäß funktioniert.


non- wwwto wwww / regex in einer dedizierten Single serverfür alle Sites:

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

wwwzu non- wwww / regex in einer dedizierten Single serverfür alle Sites:

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

wwwzu nicht wwww / regex in einem dediziertenserver nur für einige Sites :

Es kann erforderlich sein, den regulären Ausdruck so einzuschränken, dass er nur einige Domänen abdeckt. Dann können Sie so etwas verwenden, um nur Übereinstimmungen zu erzielen www.example.org, www.example.comund www.subdomain.example.net:

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

Testen regulärer Ausdrücke mit Nginx

Sie können testen, ob der reguläre Ausdruck pcretestauf Ihrem System wie erwartet funktioniert. Dies ist genau dieselbe pcreBibliothek, die Ihr Nginx für reguläre Ausdrücke verwendet:

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

Beachten Sie, dass Sie sich keine Gedanken über nachfolgende Punkte oder Groß- und Kleinschreibung machen müssen, da sich nginx bereits darum kümmert, wie es der Nginx-Servername Regex sagt, wenn der "Host" -Header einen nachgestellten Punkt hat .


  1. Mit ifvorhandenem server/ HTTPS bestreuen:

Diese endgültige Lösung wird im Allgemeinen nicht als bewährte Methode angesehen, funktioniert jedoch weiterhin und erledigt die Aufgabe.

Wenn Sie HTTPS verwenden, ist diese endgültige Lösung möglicherweise einfacher zu warten, da Sie nicht eine ganze Reihe von SSL-Anweisungen zwischen den verschiedenen serverDefinitionen kopieren und einfügen müssen und stattdessen nur die Snippets darin platzieren können die benötigten Server, um das Debuggen und Verwalten Ihrer Websites zu vereinfachen.


nicht wwwzu www:

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

wwwzu nicht- www:

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

Hardcodierung einer einzelnen bevorzugten Domäne

Wenn Sie ein bisschen mehr Leistung sowie Konsistenz zwischen mehreren Domänen wünschen, die eine einzelne servermöglicherweise verwendet, ist es möglicherweise dennoch sinnvoll, eine einzelne bevorzugte Domäne explizit fest zu codieren:

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

Verweise:


16

Diese Lösung stammt aus meiner persönlichen Erfahrung. Wir haben mehrere Amazon S3-Buckets und einen Server zum Umleiten non-wwwzu wwwDomänennamen verwendet, um der S3-Headerrichtlinie "Host" zu entsprechen .

Ich habe die folgende Konfiguration für den Nginx- Server verwendet:

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

Dies stimmt mit allen Domainnamen überein, die auf den Server verweisen, beginnend mit was auch immer www. und leitet zu weiter www.<domain>. Auf die gleiche Weise können Sie die entgegengesetzte Umleitung von wwwnach durchführen non-www.


Was ist mit https? Hinweis: https BRAUCHEN das Zertifikat
Toskan

Es gibt hier absolut kein Problem mit HTTPS. Nachdem listen 80Sie listen 443 sslund dann ssl_certificateund ssl_certificate_keyAnweisungen hinzufügen müssen .
VisioN

Niemand benutzt heutzutage http. Ich habe einen oben aufgeführten Leitfaden in Google gelesen, der Ihr Beispiel nur mit der hinzugefügten Zeile listen 443 ssl mit fehlendem Zertifikat zeigte. Das wird nicht funktionieren und verursacht ernsthafte Kopfschmerzen.
Toskan

Ich weiß nicht, über welchen Leitfaden Sie sprechen. Ich habe diese Konfiguration seit fast drei Jahren erfolgreich. Letztes Jahr habe ich Unterstützung für SSL hinzugefügt und es funktioniert wie erwartet. Und natürlich benötigen Sie ein Zertifikat mit einem privaten Schlüssel.
VisioN

Das wird also alle Subdomains außer www überladen, richtig?
Metagrapher

15

Ich habe die beste aller einfachen Antworten ohne fest codierte Domänen kombiniert.

301 permanente Weiterleitung von Nicht-WWW zu WWW (HTTP oder HTTPS):

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

    # Regular location configs...
}

Wenn Sie Nicht-HTTPS, Nicht-www gegenüber HTTPS bevorzugen, leiten Sie gleichzeitig www um:

server {
    listen 80;

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

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

11

Leiten Sie Nicht-WWW zu WWW um

Für eine einzelne Domain:

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

Für alle Domänen:

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

Leiten Sie www zu non-www um. Für eine einzelne Domain:

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

Für alle Domänen:

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

Könnten Sie zwischen 80und unterscheiden 443?
Hassan Baig

1
Es scheint listenfür mich ohne Anweisungen zu funktionieren (nginx 1.4.6).
Ibrahim

11

Versuche dies

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

Anderer Weg: Nginx no-www bis www

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

und www bis no-www

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

Warum haben die Autoren eine if-Anweisung in nginx bereitgestellt und die Leute dann aufgefordert, diese zu vermeiden? Klingt für mich leichtfertig.
Greg Smethells

4
Es wird angegeben "WENN in Ort ist böse". Sie können sicher setzen, wenn in Ihrem Server-Block
Kukunin

Direktes Zitat aus dem obigen Link ... Die einzigen 100% sicheren Dinge, die im Kontext des Standorts ausgeführt werden können, sind: return ...; umschreiben ... zuletzt;
Justin E

8

Einzigartiges Format:

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

1
Sie können es generisch machen, indem Sie es so schreiben: server { server_name "~^www\.(.*)$" ; return 301 $scheme://$1$request_uri ; }
Ramast

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

1
$scheme://www.domain.com$1um doppelte Schrägstriche zu vermeiden
Karimhossenbux

3

Ich bin mir nicht sicher, ob jemand bemerkt, dass es möglicherweise richtig ist, einen 301 zurückzugeben, aber Browser ersticken daran

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

ist schneller als:

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


1
Mein Kommentar war an den Browser gerichtet, nicht auf Effizienz auf der Nginx-Seite! Mit einer Weiterleitung macht der Browser 2 Anfragen gegen 1 Anfrage beim Umschreiben
Steven

2

Geisterblog

Um die von nginx empfohlene Methode für die return 301 $scheme://example.com$request_uri;Arbeit mit Ghost zu verwenden, müssen Sie in Ihrem Hauptserverblock Folgendes hinzufügen:

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;  

2

Wenn Sie den Domainnamen nicht fest codieren möchten, können Sie diesen Umleitungsblock verwenden. Die Domain ohne das führende www wird als Variable gespeichert, $domaindie in der Redirect-Anweisung wiederverwendet werden kann.

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

REF: Umleiten einer Subdomain mit einem regulären Ausdruck in Nginx


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

-6

Wenn Sie Probleme haben, dies zum Laufen zu bringen, müssen Sie möglicherweise die IP-Adresse Ihres Servers hinzufügen. Zum Beispiel:

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

Dabei ist XXX.XXX.XXX.XXX (offensichtlich) die IP-Adresse.

Hinweis: SSL-CRT und Schlüsselposition müssen definiert werden, um https-Anforderungen ordnungsgemäß umzuleiten

Vergessen Sie nicht, nginx nach den Änderungen neu zu starten:

service nginx restart

3
/etc/init.d/nginx reloadSie können auch reloadden Server, der keine Ausfallzeiten verursacht.
TheBlackBenzKid
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.