Best Practice: separato servercon hardcodedserver_name
La migliore pratica con nginx è quella di utilizzare un metodo separato serverper un reindirizzamento come questo (non condiviso con la serverconfigurazione principale), per codificare tutto e non usare affatto espressioni regolari.
Potrebbe essere necessario codificare i domini se si utilizza HTTPS, poiché è necessario conoscere anticipatamente i certificati che verranno forniti.
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
}
Utilizzo delle espressioni regolari all'interno server_name
Se disponi di un numero di siti e non ti preoccupi delle massime prestazioni, ma desideri che ognuno di essi abbia la stessa politica rispetto al www.prefisso, puoi utilizzare le espressioni regolari. La migliore pratica di utilizzare un separato serversarebbe ancora valida.
Nota che questa soluzione diventa complicata se usi https, dato che devi avere un unico certificato per coprire tutti i tuoi nomi di dominio se vuoi che funzioni correttamente.
non www- wwww / regex in un singolo dedicato serverper tutti i siti:
server {
server_name ~^(?!www\.)(?<domain>.+)$;
return 301 $scheme://www.$domain$request_uri;
}
wwwa non www-regex in un singolo dedicato serverper tutti i siti:
server {
server_name ~^www\.(?<domain>.+)$;
return 301 $scheme://$domain$request_uri;
}
wwwa non www-regex in un dedicato solo serverper alcuni siti:
Potrebbe essere necessario limitare l'espressione regolare per coprire solo un paio di domini, quindi si può usare qualcosa di simile per abbinare solo www.example.org, www.example.come www.subdomain.example.net:
server {
server_name ~^www\.(?<domain>(?:example\.org|example\.com|subdomain\.example\.net))$;
return 301 $scheme://$domain$request_uri;
}
Test delle espressioni regolari w / nginx
Puoi provare che regex funziona come previsto pcretestsul tuo sistema, che è esattamente la stessa pcrelibreria che il tuo nginx utilizzerà per le espressioni regolari:
% 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>
Nota che non devi preoccuparti dei punti finali o del caso, poiché nginx se ne occupa già, come per regex nome server nginx quando l'intestazione "Host" ha un punto finale .
Cospargere ifall'interno di server/ HTTPS esistente :
Questa soluzione finale non è generalmente considerata la migliore pratica, tuttavia funziona ancora e fa il suo lavoro.
In effetti, se stai usando HTTPS, questa soluzione finale potrebbe essere più facile da mantenere, poiché non dovresti copiare e incollare un intero gruppo di direttive ssl tra le diverse serverdefinizioni e potresti invece posizionare gli snippet solo in i server necessari, semplificando il debug e la manutenzione dei siti.
non wwwa www:
if ($host ~ ^(?!www\.)(?<domain>.+)$) {
return 301 $scheme://www.$domain$request_uri;
}
wwwa non- www:
if ($host ~ ^www\.(?<domain>.+)$) {
return 301 $scheme://$domain$request_uri;
}
hardcoding di un singolo dominio preferito
Se vuoi un po 'più di prestazioni, oltre alla coerenza tra più domini che un singolo serverpuò usare, potrebbe comunque avere senso codificare esplicitamente un singolo dominio preferito:
if ($host != "example.com") {
return 301 $scheme://example.com$request_uri;
}
Riferimenti:
Dashboard > Settings > General Settingse assicurati che non ci sianowwwURL di indirizzo / indirizzo sito di WordPress. Indipendentemente da come configuri il tuo nginx, se hai un www in questi URL verrebbe reindirizzato a quello con www in esso.