-
Bewährte Praxis: getrennt server mit fest kodiertem server_name
Die beste Praxis bei nginx ist die Verwendung eines separaten server für eine Weiterleitung wie diese (nicht gemeinsam mit dem server Ihrer Hauptkonfiguration), alles hart zu kodieren und überhaupt keine regulären Ausdrücke zu verwenden.
Bei der Verwendung von HTTPS kann es auch notwendig sein, die Domänen hart zu kodieren, da Sie im Voraus wissen müssen, welche Zertifikate Sie bereitstellen werden.
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
}
-
Verwendung regulärer Ausdrücke in server_name
Wenn Sie eine Reihe von Websites haben und sich nicht um die ultimative Leistung kümmern, sondern wollen, dass jede einzelne von ihnen die gleichen Richtlinien in Bezug auf die www. Präfix, dann können Sie reguläre Ausdrücke verwenden. Die beste Praxis ist die Verwendung eines separaten server würde immer noch gelten.
Beachten Sie, dass diese Lösung schwierig wird, wenn Sie https verwenden, da Sie dann ein einziges Zertifikat für alle Ihre Domänennamen haben müssen, wenn dies richtig funktionieren soll.
nicht www zu www mit Regex in einem eigenen Single server für alle Standorte:
server {
server_name ~^(?!www\.)(?<domain>.+)$;
return 301 $scheme://www.$domain$request_uri;
}
www an Nicht www mit Regex in einem speziellen Einzel server für alle Standorte:
server {
server_name ~^www\.(?<domain>.+)$;
return 301 $scheme://$domain$request_uri;
}
www an Nicht www mit Regex in einem eigenen server nur für einige Standorte:
Es kann notwendig sein, die Regex auf einige Domänen zu beschränken, dann können Sie etwas wie dieses verwenden, um nur mit www.example.org , www.example.com et 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 die Regex wie erwartet funktioniert, indem Sie pcretest auf Ihrem System, was genau dasselbe ist wie pcre Bibliothek, die Ihr Nginx für reguläre Ausdrücke verwenden wird:
% 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 nachgestellte Punkte oder Groß- und Kleinschreibung machen müssen, da nginx sich bereits darum kümmert, wie in nginx-Server-Namen-Regex, wenn "Host"-Header einen Punkt am Ende hat .
-
Streuung if innerhalb bestehender server / HTTPS:
Diese endgültige Lösung wird im Allgemeinen nicht als die beste Praxis angesehen, aber sie funktioniert trotzdem und erfüllt ihre Aufgabe.
Wenn Sie HTTPS verwenden, kann diese endgültige Lösung sogar einfacher zu warten sein, da Sie nicht eine ganze Reihe von ssl-Direktiven zwischen den verschiedenen server Definitionen, und könnten stattdessen die Snippets nur auf den benötigten Servern platzieren, was die Fehlersuche und Wartung Ihrer Websites erleichtert.
nicht www zu www :
if ($host ~ ^(?!www\.)(?<domain>.+)$) {
return 301 $scheme://www.$domain$request_uri;
}
www an Nicht www :
if ($host ~ ^www\.(?<domain>.+)$) {
return 301 $scheme://$domain$request_uri;
}
Festcodierung einer einzigen bevorzugten Domäne
Wenn Sie etwas mehr Leistung und Konsistenz zwischen mehreren Domänen wünschen, können Sie eine einzelne server verwenden können, kann es dennoch sinnvoll sein, eine einzige bevorzugte Domäne explizit zu kodieren:
if ($host != "example.com") {
return 301 $scheme://example.com$request_uri;
}
Referenzen:
