如何将 .htaccess 规则转换为 NGINX 指令

NGINX 是一种 Web 服务器,它正成为越来越受欢迎的 Web 托管选项,因为 Internet 上所有站点中有 16% 都在使用 NGINX。 由于客户端需要可以更快地提供内容的 Web 服务器,因此该百分比不断增加。 它还可用于代理、反向代理、负载平衡等,具体取决于您加载到 NGINX 上的模块。 之间的显着差异之一 Apache (流行的网络服务器)和 NGINX 是每个系统处理访问规则的方式。 如果您熟悉使用 .htaccess 规则 Apache,那么 NGINX 使用的在服务器的 vhost 块中包含指令的方法将是一个实质性的变化。

我们将展示如何将 .htaccess 重写规则转换为 NGINX 重写指令。 NGINX 重写指令也需要放在 server 块中。 许多服务器配置在 vhosts 文件中包含此服务器块信息,而有些使用单独的 NGINX 配置文件(有关 NGINX 配置文件的更多信息,请参阅使用 NGINX 重定向 URL)。 要完成此任务,您需要了解我将在下一节中讨论的一些基本 NGINX 指令。

NGINX 重写和返回指令介绍

NGINX 最常用的指令是 return 和 rewrite 指令。 使用 NGINX 指令时,可以将访问页面的客户端定向到不同的目录或不同的登录页面。 还可以根据您指定的指令将请求重定向到应用程序。 例如,从智能手机访问页面的客户端可以被转发到专门为手机浏览器编码的脚本。 另一个例子是根据 IP 或地理位置转发客户端,使您的站点特定于区域并根据位置为访问者量身定制。

NGINX 返回指令

return 指令比 rewrite 指令简单一点。 最佳做法是尽可能使用此指令而不是重写指令。 您通常会将返回包含在指定要重写的域的服务器上下文中。 我在下面包含了一个常见的例子。 访问该站点的客户将被重定向到 301 状态代码后指定的域。 使用此指令会将访问 www.CodePretest.com 的客户端转发到 www.CodePre.com。

server {  listen 80;  server_name www.CodePretest.com;  return 301 $scheme://www.CodePre.com$request_uri;  }

NGINX 重写指令

重写指令与 .htaccess 中的重写规则有些不同。 需要将其放置在特定位置或服务器块中以重写 URL。 rewrite 指令通常用于执行较小的繁琐任务。 例如,在某些情况下用于捕获原始 URL 中的元素或更改路径中的元素。 NGINX 重写指令可能会变得非常复杂,但是一旦您了解了基本语法,它就不会那么令人生畏了。 我在下面包含了 NGINX 重写指令的基本语法。

rewrite regex URL [flag];

重要的是要知道重写指令几乎总是返回 HTTP 301 或 302 状态代码。 如果您需要您的 Web 服务器返回不同的状态代码,则在重写后需要 return 指令。 我在下面包含了一个例子 NGINX 的重写模块文档.

server{  ...  rewrite ^(/download/.*)/media/(.*)..*$ $1/mp3/$2.mp3 last;  rewrite ^(/download/.*)/audio/(.*)..*$ $1/mp3/$2.ra last;  return 403;  ...  }

在此示例中,匹配以 /download 开头,后跟 /media 或 /audio 的 URL。 之后,包含 /mp3 的目录 /media 和 /audio 元素会将扩展名 .mp3 或 .ra 文件扩展名添加到 URL。 如果 URL 与重写规则不匹配,此返回指令将向客户端返回 403。

将 .htaccess 规则转换为 NGINX 指令

希望此时我们对两个最常用的 NGINX 指令有了基本的了解。 但是,学习这些规则需要一些时间,因为这可能非常复杂。 在这个过程中学习正则表达式是很有帮助的。 我们将通过我们将转换为 NGINX 指令的常用 .htaccess 规则的示例工作。

示例:从 example.com 重定向到 www.example.com

当客户端从您的服务器请求内容时,将 www 添加到 URL 可以帮助某些站点(例如托管在 WordPress 上的站点)更有效地运行。 完成此重写的常见 .htaccess 规则是:

RewriteCond %{HTTP_HOST} example.com RewriteRule (.*)https://www.example.com$1

正如我们之前提到的,最好的做法是尽可能使用 return 指令。 下面我们将在 nginx.conf 中创建一个 server 块来完成与上面的 .htaccess 重写规则相同的任务。

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

在这个例子中,将有两个用括号“{}”定义的服务器块。 我们告诉 NGINX 在端口 80 上侦听对 example.com 的请求。 然后返回一个 301“重定向”到 www.example.com。 我们通常将这些规则分成两个服务器块,以使这些指令尽可能高效。 第二个并不总是需要的,但如果请求 www.example.com,它将提供工作目录中的内容。 如果没有找到完全匹配,NGINX 然后检查是否有适合的起始通配符的 server_name。 将选择以通配符开头的最长匹配项来满足请求。

您可以通过运行以下命令来测试您的语法:

nginx -t

这允许您在加载配置文件中的更改之前测试错误的语法,并可能导致您的实时站点出现问题。 编辑完 NGINX 配置文件后,请务必使用守护程序或简单地运行以下命令重新启动 NGINX。

nginx -s reload

示例:WordPress 永久链接

在此示例中,我包含了当今最常用的一组 .htaccess 规则。 我在下面包含的规则允许 WordPress 使用永久链接。 默认情况下,它与 WordPress 一起安装在 Apache 服务器。 永久链接是旨在保持不变的 URL。 例如,可以在浏览器地址栏中将 domainexample.com/blogexample.php 加载为 domainexample.com/blog。

<IfModule mod_rewrite.c>  RewriteEngine On  RewriteBase /  RewriteRule ^index.php$ - [L]  RewriteCond ${REQUEST_FILENAME} ~ - f  RewriteCond ${REQUEST_FILENAME} ~ - d  RewriteRule . /index.php [L]  <IfModule>

下面是 NGINX 的等价物。 这里不需要返回或重写指令,因为我们只允许内容管理系统使用永久链接隐藏路径。 有关此任务的更多信息,请参阅NGINX 关于永久链接的文档.

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

您可以通过运行以下命令来测试您的语法:

nginx -t

这允许您在加载配置文件中的更改之前测试错误的语法,并可能导致您的实时站点出现问题。 编辑完 NGINX 配置文件后,请务必使用守护程序或简单地运行以下命令重新启动 NGINX。

nginx -s reload

示例:强制 http 到 https

.htaccess 文件的另一个流行用途是强制浏览器使用 https over HTTP 加载站点。 这允许浏览器通过确认该站点存在于它声称位于的服务器上来验证该站点是否存在安全风险(请参阅 什么是 SSL 证书?)。 它还可用于验证营业地点、营业 ID 号和营业地点。 这有助于防止访问可能对您的个人计算机或私人信息造成损害的恶意站点。

以下 .htaccess 规则将强制使用 https,以便使用端口 80 的 example.com 请求将被重定向到 https://www.example.com。

RewriteEngine On RewriteCond %{HTTP_HOST} ^example.com [NC] RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]

为了使用 NGINX 实现这一点,我们将使用 NGINX 返回指令。

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

您可以通过运行以下命令来测试您的语法:

nginx -t

这允许您在加载配置文件中的更改之前测试错误的语法,并可能导致您的实时站点出现问题。 编辑完 NGINX 配置文件后,请务必使用守护程序或简单地运行以下命令重新启动 NGINX。

nginx -s reload

结论

我们可以继续举例,但希望在这一点上,我们现在对将 .htaccess 转换为 Apache 到 NGINX 指令。 如果您需要有关完成这些任务的更多信息,您可以随时联系我们的支持人员寻求帮助。 但是,我们并不完全支持 NGINX,它被认为是 超越范围 支持。 这意味着我们会尽可能多地为您提供帮助,但我们可能无法解决您的问题,而是会将您转介给开发人员以获得更多帮助。 如果您想使用 NGINX Web 服务器来托管您的内容,我们有多种选择,包括我们的 VPS 阵容来满足您的业务需求。 NGINX 目前也正在开发用于 cPanel 服务器,尽管目前不支持或不推荐在生产情况下使用。 看 cPanel 的博客 想要查询更多的信息。

就像你看到的一样?

立即拨打 1.800.580.4985 与我们联系,与知识渊博的托管解决方案提供商交谈,他们可以为您提供所需的信息,以便立即做出明智的决定。

忙到不想说话? 点击 这里 与我们进行快速聊天以了解更多信息。 您是否需要可以在闲暇时查看的电子邮件中的信息? 立即给我们发送电子邮件,以获得关于我们产品系列中哪种产品最适合您的需求的可靠建议。

我们期待您的回音!