Mejor práctica: separado server
con código rígidoserver_name
La mejor práctica con nginx es usar un separado server
para una redirección como esta (no compartida con la server
de su configuración principal), para codificar todo y no usar expresiones regulares en absoluto.
También puede ser necesario codificar los dominios si está usando HTTPS, ya que debe saber por adelantado qué certificados proporcionará.
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
}
Usando expresiones regulares dentro server_name
Si tiene varios sitios y no le interesa el rendimiento máximo, pero desea que cada uno de ellos tenga la misma política con respecto al www.
prefijo, puede usar expresiones regulares. La mejor práctica de usar un separado server
aún se mantendría.
Tenga en cuenta que esta solución se vuelve complicada si usa https, ya que debe tener un solo certificado para cubrir todos sus nombres de dominio si desea que esto funcione correctamente.
non- www
to www
w / regex en un single dedicado server
para todos los sitios:
server {
server_name ~^(?!www\.)(?<domain>.+)$;
return 301 $scheme://www.$domain$request_uri;
}
www
a non- www
w / regex en un single dedicado server
para todos los sitios:
server {
server_name ~^www\.(?<domain>.+)$;
return 301 $scheme://$domain$request_uri;
}
www
a non- www
w / regex en un sitio dedicado solo server
para algunos sitios:
Puede ser necesario restringir la expresión regular para cubrir sólo un par de dominios, entonces usted puede usar algo como esto para solo www.example.org
, www.example.com
y www.subdomain.example.net
:
server {
server_name ~^www\.(?<domain>(?:example\.org|example\.com|subdomain\.example\.net))$;
return 301 $scheme://$domain$request_uri;
}
Prueba de expresiones regulares con nginx
Puede probar que la expresión regular funciona como se esperaba pcretest
en su sistema, que es exactamente la misma pcre
biblioteca que su nginx usará para expresiones regulares:
% 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>
Tenga en cuenta que no tiene que preocuparse por los puntos finales o el caso, ya que nginx ya se encarga de eso, según el nombre del servidor nginx regex cuando el encabezado "Host" tiene un punto final .
Asperjar if
dentro de server
HTTPS existente :
Esta solución final generalmente no se considera la mejor práctica, sin embargo, todavía funciona y hace el trabajo.
De hecho, si está utilizando HTTPS, entonces esta solución final puede resultar más fácil de mantener, ya que no tendría que copiar y pegar un montón de directivas SSL entre las diferentes server
definiciones, y en su lugar podría colocar los fragmentos solo en los servidores necesarios, lo que facilita la depuración y el mantenimiento de sus sitios.
no www
a www
:
if ($host ~ ^(?!www\.)(?<domain>.+)$) {
return 301 $scheme://www.$domain$request_uri;
}
www
a no- www
:
if ($host ~ ^www\.(?<domain>.+)$) {
return 301 $scheme://$domain$request_uri;
}
codificar un solo dominio preferido
Si desea un poco más de rendimiento, así como la consistencia entre múltiples dominios que un solo server
puede usar, aún podría tener sentido codificar explícitamente un solo dominio preferido:
if ($host != "example.com") {
return 301 $scheme://example.com$request_uri;
}
Referencias
Dashboard > Settings > General Settings
y asegúrese de que no haya ningunawww
en las URL de dirección de sitio / sitio de WordPress. No importa cómo configure su nginx, si tiene un www en estas URL, se redirigirá al que tiene www.