nginx重新规则介绍（二）

示例 - 标准化域名

NGINX重写规则的最常见用途之一是捕获网站域名的弃用或非标准版本，并将其重定向到当前名称。有几个相关的用例。

从前名称重定向到当前名称

此示例NGINX重写规则将来自www.old-name.com和old-name.com的请求永久重定向到www.new-name.com，使用两个NGINX变量从原始请求URL捕获值 - $ scheme是原始协议（http或https）和$ request_uri是完整的URI（在域名后面），包括参数：

server {
    listen 80;
    listen 443 ssl;
    server_name www.old-name.com old-name.com;
    return 301 $scheme://www.new-name.com$request_uri;
}

因为$ request_uri捕获了域名后面的URL部分，所以如果旧站点和新站点之间存在一对一的页面对应，则此重写是合适的（例如，www.new-name.com / about与www.old-name.com/about相同的基本内容。如果您在更改域名之后重新组织了站点，则通过省略$ request_uri将所有请求重定向到主页可能更安全：

server {
    listen 80;
    listen 443 ssl;
    server_name www.old-name.com old-name.com;
    return 301 $scheme://www.new-name.com;
}

其他一些关于在NGINX中重写URL的博客对这些用例使用了重写指令，如下所示：

# NOT RECOMMENDED
rewrite ^ $scheme://www.new-name.com$request_uri permanent;

这比等效的返回指令效率低，因为它需要NGINX来处理正则表达式，尽管是一个简单的表达式（插入符号[^]，它匹配完整的原始URL）。对于人类读者来说，相应的返回指令也更容易解释：返回301更清楚地表明NGINX返回代码301而不是重写...永久符号

添加和删除www前缀

这些示例添加和删除www前缀：

# add 'www'
server {
    listen 80;
    listen 443 ssl;
    server_name domain.com;
    return 301 $scheme://www.domain.com$request_uri;
}

# remove 'www'
server {
    listen 80;
    listen 443 ssl;
    server_name www.domain.com;
    return 301 $scheme://domain.com$request_uri;
}

同样，返回优于随后的等效重写。重写需要解释正则表达式 - ^（。*）$ - 并创建一个实际上等同于内置$ request_uri变量的自定义变量（$ 1）。

# NOT RECOMMENDED
rewrite ^(.*)$ $scheme://www.domain.com$1 permanent;

将所有流量重定向到正确的域名

这是一个特殊情况，当请求URL与任何服务器和位置块不匹配时，可能会因为域名拼写错误而将传入流量重定向到网站的主页。它的工作原理是将default_server参数与listen指令和下划线组合作为server_name指令的参数。

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    server_name _;
    return 301 $scheme://www.domain.com;
}

我们使用下划线作为server_name的参数，以避免无意中匹配真实域名 - 可以安全地假设没有站点将下划线作为其域名。但是，与配置中的任何其他服务器块不匹配的请求最终会在此处显示，并且要监听的default_server参数告诉NGINX将此块用于它们。通过从重写的URL中省略$ request_uri变量，我们将所有请求重定向到主页，这是一个好主意，因为具有错误域名的请求特别可能使用网站上不存在的URI。

示例 - 强制所有请求使用SSL / TLS

此服务器阻止所有访问者使用与您站点的安全（SSL / TLS）连接。

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

其他一些关于NGINX重写规则的博客使用if测试和这个用例的重写指令，如下所示：

# NOT RECOMMENDED
if ($scheme != "https") {
    rewrite ^ https://www.mydomain.com$uri permanent;
}

但是这种方法需要额外的处理，因为NGINX必须同时评估if条件并处理rewrite指令中的正则表达式。

示例 - 为WordPress网站启用漂亮的永久链接

NGINX和NGINX Plus是使用WordPress的网站非常流行的应用程序交付平台。以下try_files指令告诉NGINX检查是否存在文件$ uri，然后检查目录$ uri /。如果文件或目录都不存在，NGINX会返回一个重定向到/index.php并传递查询字符串参数，这些参数由$ args参数捕获。

location / {
    try_files $uri $uri/ /index.php?$args;
}

示例 - 删除不支持的文件扩展名的请求

由于各种原因，您的站点可能会收到以与您未运行的应用程序服务器对应的文件扩展名结尾的请求URL。在Engine Yard博客的这个示例中，应用程序服务器是Ruby on Rails，因此其他应用程序服务器（Active Server Pages，PHP，CGI等）处理的文件类型的请求无法提供服务，因此需要拒绝。在将动态生成的资产的任何请求传递给应用程序的服务器块中，此位置指令在它们到达Rails队列之前删除对非Rails文件类型的请求。

location ~ .(aspx|php|jsp|cgi)$ {
    return 410;
}

严格地说，响应代码410（Gone）旨在用于所请求的资源过去在该URL处可用但不再存在的情况，并且服务器不知道其当前位置（如果有的话）。它优于响应代码404的优点在于它明确指示资源永久不可用，因此客户端不会再次发送请求。

您可能希望通过返回响应代码403（禁止）和诸如“服务器仅处理Ruby请求”之类的解释作为文本字符串，为客户端提供更准确的失败原因指示。作为替代方案，deny all指令返回403而没有解释：

location ~ .(aspx|php|jsp|cgi)$ {
    deny all;
}

代码403隐式确认所请求的资源存在，因此如果您希望通过向客户端提供尽可能少的信息来实现“通过默默无闻的安全性”，则代码404可能是更好的选择。缺点是客户端可能会反复重试请求，因为404不会指示故障是暂时还是永久。

示例 - 配置自定义重新路由

在MODXCloud的这个示例中，您有一个资源，可用作一组URL的控制器。您的用户可以使用更易读的资源名称，并重写（而不是重定向）它将由listing.html的控制器处理。

rewrite ^/listings/(.*)$ /listing.html?listing=$1 last;

例如，用户友好的URL http://mysite.com/listings/123被重写为由listing.html控制器http://mysite.com/listing.html?listing=123处理的URL。