Meilleure pratique: séparé serveravec codage en durserver_name
La meilleure pratique avec nginx est d'utiliser un séparé serverpour une redirection comme celle-ci (non partagée avec la serverconfiguration principale), de tout coder en dur et de ne pas utiliser du tout d'expressions régulières.
Il peut également être nécessaire de coder en dur les domaines si vous utilisez HTTPS, car vous devez savoir à l'avance quels certificats vous fournirez.
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
}
Utilisation d'expressions régulières dans server_name
Si vous avez un certain nombre de sites et que vous ne vous souciez pas des performances les plus élevées, mais que chacun d'entre eux ait la même politique en ce qui concerne le www.préfixe, vous pouvez utiliser des expressions régulières. La meilleure pratique d'utiliser un élément distinct serverserait toujours valable.
Notez que cette solution devient délicate si vous utilisez https, car vous devez alors avoir un seul certificat pour couvrir tous vos noms de domaine si vous voulez que cela fonctionne correctement.
non wwwà wwww / regex dans un single dédié serverpour tous les sites:
server {
server_name ~^(?!www\.)(?<domain>.+)$;
return 301 $scheme://www.$domain$request_uri;
}
wwwà non- wwww / regex dans un single dédié serverpour tous les sites:
server {
server_name ~^www\.(?<domain>.+)$;
return 301 $scheme://$domain$request_uri;
}
wwwà non- wwww / regex dans un site dédié serverà certains sites uniquement:
Il peut être nécessaire de limiter l'expression rationnelle pour couvrir seulement quelques domaines, vous pouvez alors utiliser quelque chose comme ça pour correspondre uniquement www.example.org, www.example.comet www.subdomain.example.net:
server {
server_name ~^www\.(?<domain>(?:example\.org|example\.com|subdomain\.example\.net))$;
return 301 $scheme://$domain$request_uri;
}
Test d'expressions régulières avec nginx
Vous pouvez tester que l' expression régulière fonctionne comme prévu avec pcretestsur votre système, qui est exactement la même pcrebibliothèque que votre nginx utilisera pour les expressions régulières:
% 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>
Notez que vous n'avez pas à vous soucier des points de fin ou de la casse, car nginx s'en occupe déjà, selon le nom du serveur nginx regex lorsque l'en-tête "Host" a un point de fin .
Saupoudrer ifdans le existant server/ HTTPS:
Cette solution finale n'est généralement pas considérée comme la meilleure pratique, mais elle fonctionne et fait toujours l'affaire.
En fait, si vous utilisez HTTPS, cette solution finale peut être plus facile à maintenir, car vous n'auriez pas à copier-coller tout un tas de directives ssl entre les différentes serverdéfinitions, et pourriez à la place placer les extraits uniquement dans les serveurs nécessaires, ce qui facilite le débogage et la maintenance de vos sites.
non 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;
}
codage en dur d'un seul domaine préféré
Si vous voulez un peu plus de performances, ainsi que la cohérence entre plusieurs domaines qu'un seul serverpeut utiliser, il peut toujours être judicieux de coder en dur explicitement un seul domaine préféré:
if ($host != "example.com") {
return 301 $scheme://example.com$request_uri;
}
Références:
Dashboard > Settings > General Settingset assurez-vous qu'il n'y en a paswwwdans les URL d'adresse WordPress / adresse du site. Peu importe comment vous configurez votre nginx, si vous avez un www dans ces URL, il sera redirigé vers celui avec www dedans.