阅读这篇文章前，可以先看看我的另外一篇文章：《Nginx 介绍，以及Nginx配置指令执行的顺序 11 个阶段》 https://blog.csdn.net/zzhongcy/article/details/86086369

nginx if 语句其实是 rewrite的一部分，我们在配置nginx时，需要明白if的一些特点。 这里转载了一部分网上的文章，自己再加入了一些配置用例进行说明，希望对大家有帮助。

1. 前言

有关被 nginx 官方自我批判的 if 语句，《 If Is Evil 》—— 着实应成为每位开发者初次使用 nginx if 之前必读的文章。

即使笔者一年前就开始接触使用 nginx 和 if 的组合做 url 跳转，但涉及的功能太简单，一直没能见识到它的真面目。直到近期在多个 if 内处理 proxy_pass 时，噩梦果真就降临了……希望大家仔细阅读上面的文章，引以为戒。

如果想快速知道为什么 “if is evil”，以及如何避免被坑，可以向下阅读一探究竟。

2. 介绍

《 If Is Evil 》这些例子描述的问题有些是 Nginx 的固有逻辑，有些己经被修正了，有些依然如旧。 本文先对 rewrite 模块的实现进行总体剖析， 然后再从 Nginx 源代码的角度对这 些例子对应的代码实现一一进行分析。

2.1 几点事实

• 从 Nginx Configuration Inheritance Model 这篇文章中我们知道， rewrite 模块提供配置指令被称为 action directives ，下一层级的 location 中不会从上一级 location 继承这些配置指令。从 Nginx 源代码里的 ngx_http_rewrite_merge_loc_conf 函数中我们能找到证据。

• server 作用域中的 rewrite 模块指令也不会向下传递到 location 作 用域，但是这些指令会在 SERVER_REWRITE 阶段 (先于 REWRITE 阶段) 被执行。 也就是说， server 作用域的 rewrite 模块指令和 location 作用域的 rewrite 模块指令都会被 Nginx 执行。

• rewrite 模块提供的指令的执行顺序和其在配置文件中的定义顺序一致。

• if 指令在 Nginx 内部创建了一个无名 location ，if 条件为真时，Nginx 使用 这个无名 location 作用域的配置处理当前请求 。

• POST REWRITE 是 Nginx 内部定义的阶段，通过检查请求 uri 是否被 rewrite 模块修改 (r->uri_changed)，判断是否需要使用修改后的 uri 重新开始 FIND CONFIG 以重新匹配合适的 location 。比如在 location 中有配置如 rewrite ... last; 且 rewrite 成功和请求 uri 匹配成功时。

2.2 rewrite 模块

rewrite 模块是一个 phase handler ， 其初始化函数 ngx_http_rewrite_init 在 SERVER REWRITE 和 REWRITE 阶段 注册了相同的处理函数 ngx_http_rewrite_handler。其中， SERVER REWRITE 阶段 的处理函数用于执行 server 作用域中的 rewrite 模块指令，而 REWRITE 阶 段的处理函数用于执行 location 和 if 作用域的 rewrite 模块指令。

rewrite 模块 文档 中提到：

The ngx_http_rewrite_module module directives are compiled at the configuration stage into internal instructions that are interpreted during request processing. An interpreter is a simple virtual stack machine.

这个 ”虚拟栈机“ (Virtual stack machine) 就是我们在 配置变量 一文中分析的 Nginx 的命令解释器ngx_http_script_engine_t。Nginx 将包含变量的 配置指令 (directive) 编译为可以在运行对变量进行求值的命令 (instruction，实际上 是一系统预先定义的函数)，然后在 Nginx 处理请求的过程中执行这些命令对变量求值。

rewrite 模块提供的配置指令基本都和变量有关系，if 除了使用变量之外，还需 要根据变量值执行不同的逻辑 (使用不同的 location 继续处理请求)，所以这个模块 也是 Nginx 提供的命令解释器的大用户。 rewrite 模块被编译后的命令保存在 ngx_http_rewrite_loc_conf_t::codes 字段中。

typedef struct {  
  ngx_array_t *codes;  
  ngx_uint_t stack_size;  
} ngx_http_http_rewrite_loc_conf_t; 

接下来，我们选取两个配置指令 break 和 if，从配置解析和请求处理两个阶段对相 关代码进行分析。

2.3 break

Nginx 大部分模块提供的配置指令的生效顺序和其在配置文件中的顺序并没有什么关系， 比如 proxy 模块。但是有些模块提供的配置指令像编程语言的语句一样，生效顺序 又和配置顺序一致，比如 http core 模块提供的使用了正则表达式的 location 和本文的主角 rewrite 模块提供的 if,break, return 和 rewrite 指令。

break 指令用于在运行时中断 rewrite 模块指令编译后的命令执行流程，也就是 说，break 之前的命令执行完毕后，就会结束当前的 SERVER REWRITE 或者 REWRITE 阶段，随后 Nginx 进入下一个阶段 (PHASE)。

在实际生成环境中，单独使用 break 并没有太大的实际意义。但是如果和 if 指令 结合使用，那作用就大了。

2.4 if

Nginx 在运行过程中对 if 指令定义的表达式求值：如果表达式值为 true，Nginx 使用 if 创建的无名 location {} 的配置处理该请求；如果表达式值为 false， Nginx 跳过 if {}，继续执行后面的 rewrite 模块指令。

先来大概了解下 if 的用法：

• if 指令语法是：if (condition) { ... }；
• if 指令只能用于 server {} 和 location {} 中；
• if 指令的 condition 可以是：
  • 单个变量 - 变量值为空字符串或者 "0" 时表达式为 false，其余情形为 true；
  • 一元运算符和一个变量 - 支持的一元运算符有 -f, !-f, -d, !-d, -e, !-e, -x, !-x。这些运算符的具体作用参见官方文档；
  • 二元运算符和两个变量 (或一个变量和一个常量，变量必须放在运算符前面) - =, !=, ~, ~*, !~,!~*。这些运算符的具体作用参见官方文档；

if 指令的配置解析和向运行时命令的编译过程，及运行时命令的解释执行，比上文分 析的 break要复杂很多，和上文对 break 的分析类似，我们依然按静态配置解析和 运行时命令执行两个阶段，对 if 指令的代码实现进行分析。

在罗列代码之前，我们先来给出几个结论：

(1) if {} 作用域里的 rewrite 模块指令和它所在的 server 或者 location 作用域里的 rewrite 模块指令共用编译后的命令存储空间，即 ngx_http_rewrite_loc_conf_t::codes。这个设定最早可追溯到 Nginx 早期的 0.17 RELEASE 版本：

*) Changes: the ngx_http_rewrite_module was rewritten from the scratch. Now it is possible to redirect, to return the error codes, to check the variables and referers. The directives can be used inside locations. The redirect directive was canceled.

我猜测，Nginx 之所以这样实现是为了简化逻辑。如果让 if {} 创建的无名 location {} 拥有自己独立的命令数组，那么进入了这个无名 location{} 后，如果需要执行其中的 rewrite 模块指令对应的命令，势必需要再次调用 ngx_http_rewrite_handler 或 者初始化一个新的解释器。而如果在 if {} 配置的还有其它 rewrite 模块指令， 那么在执行完无名 location 的命令后，还需要再次恢复原先的解释器环境。这个过程 增加了代码实现的复杂度。

上面的描述引出了另外一个结论：

(2) if 条件为 true 的情况下，Nginx 虽然把请 求和无名location {} 关联了起来，但是由于当前依然处于 REWRITE 阶段， if {} 后面的 rewrite 模块指令依然需要继续执行。"What happens in Vegas stays in Vegas"。在 REWRITE 阶段定义的指令，在此阶段执行完毕后，Nginx 才 开始执行下一个阶段的指令。

3 Why《If Is Evil》

nginx if 语句其实是 rewrite 模块的一部分，尽管在非 rewrite 环境下也可以用，但必须要意识到这是一种误用，因此才能理解为何它会引发众多意料之外的问题。

3.1 How

下面的示例代码引自 If Is Evil 的 Example 部分 ，用 30 秒即可浏览大部分 evil 场景。

# 这里收集了一些出人意料的坑爹配置来展示 location 中的 if 指令是万恶的
# 只有第二个 header 才会在响应中展示
# 这不是Bug, 只是他的处理流程如此
location /only-one-if {
    set $true 1;
    if ($true) {
        add_header X-First 1;
    if ($true) {
        add_header X-Second 2;
    return 204;
# 因为if, 请求会在未改变uri的情况下下发送到后台的 '/'
location /proxy-pass-uri {
    proxy_pass http://127.0.0.1:8080/;
    set $true 1;
    if ($true) {
        # nothing
# 因为if, try_files 失效
location /if-try-files {
     try_files  /file  @fallback;
     set $true 1;
     if ($true) {
         # nothing
# nginx 将会发出段错误信号(SIGSEGV)
location /crash {
    set $true 1;
    if ($true) {
        # fastcgi_pass here
        fastcgi_pass  127.0.0.1:9000;
    if ($true) {
        # no handler here
# alias with captures isn't correcly inherited into implicit nested location created by if
# alias with captures 不能正确的继承到由if创建的隐式嵌入的location 
location ~* ^/if-and-alias/(?.*) {
    alias /tmp/$file;
    set $true 1;
    if ($true) {
        # nothing
下面针对每一个例子，我们先把配置片断完整列出来。然后，再给出目前它在 Nginx 中的 状态。最后，如果文字无法很好解释清楚，我们再从代码上对该例子进行分析。
 
3.2 例 1
 
# only second header will be present in respons # not really bug, just how it works 
location /only-one-if {  
  set $true 1;   
  if ($true) {  
    add_header X-First 1;  
  if ($true) {  
    add_header X-Second 2;  
  return 204; 
 
依然和原文描述一致。它属于 Nginx 的固有工作模式。
 
 
原因：
 
  
 
add_header 指令是 ngx_http_headers_module 模块 (output filter module) 提供的指令，这个指令基本算是工作在 CONTENT 阶段。
 
 
REWRITE 阶段的指令执行完后，请求才会进入下一个阶段。那两个 if 指令 的 condition 都是true，那么最后一个 if {} 会成为请求关联的 location 作用域。于是，进入 CONTENT 阶段后，第二个 if {} 中的 add_header 指 令才会生效。
 
 
3.3 例 2
 
# request will be sent to backend without uri changed # to '/' due to if 
location /proxy-pass-uri {  
  proxy_pass http://127.0.0.1:8080/;   
  set $true 1;   
  if ($true) {  
    # nothing  
 
Nginx BUG, 因为最新稳定版 1.8.0 已经修正了：ChangeLog
 
 
大致原因就是因为往 if {} 创建的无名 location {} 命并配置时，漏了一个变量 plcf->location。
 
 
另外，值得提起的一个点是：proxy_pass 是一个 action directive， 按照定义和其它嵌套location 的实现来看，这个指令不应该被子作用域继承，但是 if {} 当作子作用域的话，貌似是个例外，原因如下：
 
  
 
proxy_pass, fastcgi_pass 等指令提供了 location handler。一般情况下， Nginx 开始在FIND_CONFIG 阶段处理请求时，因为要为请求匹配新的 location {}， 在ngx_http_core_find_config_phase 函数里先将 r->content_handler 置 NULL，匹配成功后，如果匹配到的 location {} 提供了 location handler， 再次在ngx_http_update_location_config 函数中将 r->content_handler 赋与 新值：
 
/* ngx_http_proxy_pass */ 
clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module); 
clcf->handler = ngx_http_proxy_handler;  
/* ngx_http_core_find_config_phase */ 
r->content_handler = NULL;  
/* ngx_http_update_location_config */ 
if (clcf->handler) {  
  r->content_handler = clcf->handler; 
} 
 
 
由上一篇的分析我们能看到，如果 if 指令后的 conditon 成立，在命令函数ngx_http_script_if_code 中只调用了 ngx_http_update_location_config 函数 而并没有让请求重新进入 FIND_CONFIG 阶段。这样一来，r->content_handler 的值就得以保留。
 
 
这也算是 if 的实现带来的 “副” 作用吧；
 
 
3.4 例 3
 
# try_files won't work due to if 
location /if-try-files {  
  try_files /file @fallback;   
  set $true 1;   
  if ($true) {  
    # nothing  
 
Nginx 固有逻辑
 
 
原因：首先，try_files 不会被子作用域继承。其次，try_files 工作于 Nginx 内部定义的TRY_FILES 阶段，并且此阶段优先级低于 REWRITE。所以，当 if 指令的 condition 成立时，请求和 if 创建的无名作用域关联，而此无名作用 域又不会继承 try_files 相关配置。
 
 
3.5 例 4
 
# nginx will SIGSEGV 
location /crash {  
  set $true 1;   
  if ($true) {  
    fastcgi_pass 127.0.0.1:9000;  
  if ($true) {  
    # no handler here  
Nginx BUG，目前稳定版本 1.2.0 已修正：Changelog
原因：参见 ChangeLog。
 
3.6 例 5
 
# alias with captures isn't correctly inherited into implicit nested # location created by if 
location ~* ^/if-and-alias/(?<file>.*) {  
  alias /tmp/$file;   
  set $true 1;   
  if ($true) {  
    # nothing  
Nginx BUG, 目前在稳定版 1.8.0 已修正: Changelog
原因：参见 ChangeLog。
 
3.7 小结
 
"if is evil" 一文中出现的例子要么已经被修正了，要么就是确实不能那么用。但是， 原文不是所有if 带来的问题大全，兴许某一天，你自己就会碰见。希望能通过这篇的讲解，将来某一天碰到莫名的问题时，你能自己分析原因，说不定还能找到 Nginx 的 BUG 呢。
 
4 如何避免
 
既然 if 如此之坑，最好的办法就是乖乖禁用 if，但拗不过诸位喜欢折腾的灵魂，特殊场景还是可以用的。下面列举最常见的避坑方案。
 
4.1 官方认可的两种用法
 
再怎么说，if 是为 rewrite 服务的，在正确的场合做正确的事，没毛病。
 
#The only 100% safe things which may be done inside if in a location context are:
return ...;
rewrite ... last;
4.2 proxy_pass 中及时 break
 
当处理各种跳转逻辑时，假设你不期望因为多传了个等于 “hi” 的参数 parma2，就导致 param1 ~ "hello" 的跳转失败，那么应该在合适的地方增加 break。
 
location /proxy-pass-uri {
    set $true 1;
    if ($arg_param1 ~ "hello") {
      proxy_pass http://127.0.0.1:8080/;
      # 这里的 break 将阻止下面 if 的执行
      break;
    if ($arg_param2 ~ "hi") {
      # anything
    proxy_pass http://127.0.0.1:8082/;
此外，也可以通过调整 if 的顺序来规避风险，但是容错率比 break 低了很多
 
server {
 listen 127.0.0.1:80;
         set $test  A; 
         set $testB B;
         location / {
            if ($test ~* "A") { 
                  proxy_pass http://www.so.com; 
                  break; 
            } 
            if ($testB ~* "B") { 
                  proxy_pass http://www.sogou.com; 
                  #break; 
            } 
        }
 }
 
希望满足某个条件的时候，走某个proxy_pass。但是如果多个if都满足，比如上例中的情况，在没有break的时候，会执行下面的if；
 
为了第一个匹配上之后就执行proxy_pass，可以加上break
 
4.3 或者条件互斥
 
判断参数进行不同的proxy_pass：
 
rewrite只能通过url路径进行匹配，不能进行参数匹配，所以如果要实现参数的判断需要用$arg_parameter。
 
location / {
         root    html;
         index   index.html index.htm index.php;
         proxy_redirect      off;
         proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header    X-Real-IP $remote_addr;
         proxy_set_header    Host $http_host;
         proxy_http_version  1.1;
         proxy_set_header    Connection "";
  
         if ( $query_string ~* "usg=0" ) {
             proxy_pass      http://local_workera;
         }
  
         if ( $query_string ~* "usg=1" ) {
             proxy_pass      http://local_workerb;
         }
  
         if ( $arg_uid ~* "(.*[AB]$)" ) {
             proxy_pass      http://local_workerf;
         }
  
         proxy_pass    http://local_workera;
 }
 1）请求路径中的usg=0和usg=1这两个参数是确定的，所以使用了$query_string进行正则匹配即可；（$query_string的值是请求中所有参数）
 
2）接下来，我们想对uid的值如果是以A、B结尾的请求，转向local_workerf处理，这时候就无法用$query_string进行正则匹配了；（因为对于/?uid=1A&t=1&usg=1和/?uid=123&t=A&usg=0 不太好匹配）这时，只能用$arg_uid进行正则匹配了。
 
3）由于usg=0和usg=2这两个参数是互斥的，所以根据上面location中if指令的逻辑，不用break也可以正确处理，且放到最上面。对于uid的匹配，由于会和usg进行冲突，所以只能放到最下面或者加break，
 
location / {
         root    html;
         index   index.html index.htm index.php;
         proxy_redirect      off;
         proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header    X-Real-IP $remote_addr;
         proxy_set_header    Host $http_host;
         proxy_http_version  1.1;
         proxy_set_header    Connection "";
         
         if ( $arg_uid ~* "(.*[AB]$)" ) {
             proxy_pass      http://local_workerf;
             break;
         }
         # 下面两个条件互斥   不用break
         if ( $query_string ~* "usg=0" ) {
             proxy_pass      http://local_workera;
         }
  
         if ( $query_string ~* "usg=1" ) {
             proxy_pass      http://local_workerb;
         }
  
         proxy_pass    http://local_workera;
 }
  
 
4.4 server_name指令与if
 
server {
    server_name example.com *.example.com;
        if ($host ~* ^www\.(.+)) {
            set $raw_domain $1;
            rewrite ^/(.*)$ $raw_domain/$1 permanent;
        # [...]
这里实际上有三个问题。首先看看if，也是我们现在要关注的，为何是劣的？你读过这篇文章 If是魔鬼 吗？当nginx接收到一个请求不管子域名是什么，即使是www.example.com或example.com，if指令也是每次都要调用，因为NGINX需要每次对请求头Host做处理，这特别没有效率，你要千万注意避免它。可以替换为两个server区块，如下面的列子：
 
server {
    server_name www.example.com;
    return 301 $scheme://example.com$request_uri;
server {
    server_name example.com;
    # [...]
这种配置也可以使配置更好阅读，这种方法减少了NGINX的处理需求。我们去除了谬误的if，同时我们使用了$schema避免了硬编码URI，如http或https。
 
4.5 检查文件是否存在（if）
 
使用if来判断一个文件是否存在太可怕了。也就是说如果你有最新版的NGINx，使用tryfiles指令将更加容易。
 
server {
    root /var/www/example.com;
    location / {
        if (!-f $request_filename) {
            break;
server {
    root /var/www/example.com;
    location / {
        try_files $uri $uri/ /index.html;
我们只是修改了判断文件是否存在但又不使用if指令，使用tryfiles表示可以测试一系列文件，如果$uri不存在，再试$uri/，如果还不存在，就使用默认位置（index.html）。
 
在这个列子，如果$uri存在就使用它，如果不存在，再判断$uri/目录是否存在，如果不存在就使用index.html，必须要保证最后一个检测的文件存在。很简单吧！下面是另一个例子去掉if指令。
 
4.6 利用变量来判断
 
nginx虽然有if，但是却不支持else，如果想要构造else语法，可以使用下面的这个“小诀窍”：
 
server {
    server_name *.maqian.io;
    listen 80;
    location / {
        set $is_matched 0;
        if ($host = a.maqian.io) {
            proxy_pass https://127.0.0.1:1001/;
            set $is_matched 1;
        if ($host = b.maqian.io) {
            proxy_pass https://127.0.0.1:1002/;
            set $is_matched 1;
        # 没有匹配到，跳转到默认页面
        if ($is_matched = 0) {
            proxy_pass https://127.0.0.1;
        # xxx
        # xxx
        # xxx
4.7 多条件判断
 
4.7.1 例子1
 
要实现的语句：
 
if ($arg_unitid = 42012 && $uri ~/thumb/){
 echo "www.ttlsa.com";
可以这么来实现，如下所示：
 
set $flag 0;
if ($uri ~ ^/thumb/[0-9]+_160.jpg$){
 set $flag "${flag}1";
if ($arg_unitid = 42012){
 set $flag "${flag}1";
if ($flag = "011"){
 echo "www.ttlsa.com";
4.7.2 例子2
 
实现禁止ip访问，禁止用post访问非php的文件
 
set $allowss true;
set $allowphp '';
if ($request_method ~ ^(POST)$) {
    set $allowphp p;
if ( $request_filename !~ \.php$) {
    set $allowphp "${allowphp}c";
if ( $allowphp = pc) {
    set $allowss false;
if ($http_x_forwarded_for ~ " ?222\.186\.34\.41$") {
    set $allowss false;
if ($http_x_forwarded_for ~ " ?180\.97\.106\.37$") {
    set $allowss false;
if ($allowss = false) {
    return 403;
 
4.7.3 例子3
 
   如果需要分支`if`语句，则很明显，仅释放带有`last`标志的重写语句，如下所示，并在下一个块中实现其他工作。 
 
https://github.com/openresty/lua-nginx-module
 
       具体来说，通过安装 lua 和 lua-nginx-module( 或 OpenResty ) 来增强 nginx 的逻辑处理，可以称为目前最流行有效的处理方案。lua 扩展带来的好处远不止 if 语句的避坑，例如带来方便地读取 POST 请求体的内容等便利操作。网上资料齐全，这里不多赘述。
 
6 使用 njs
 
 
http://nginx.org/en/docs/njs/index.html
 
       nginScript (njs) 是 nginx 在 2015 发布的 javascript 配置方案。类似于 lua-nginx-module，它也需要安装相关依赖模块。但有官方做后盾的 njs，比起 lua 要更为轻量，不需要完整的语言运行环境。并且针对 nginx 环境进行设计，理论上有更高的优化空间。
 
7 其他《nginx的location if是如何工作的》
 
http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html
 
nginx的location if是如何工作的
 
       Nginx的if指令在实际运用中有一些诡异的地方。人们常常会因为对它的行为缺乏足够的知识而可能误用它。在这篇博客中，我将分析一些例子，这样人们可能会受些启发而正确使用它。
 
       简而言之，一旦if语句条件匹配，Nginx的if块(block)实际上创建了一个(内嵌的)location块(block)，只有内部的location块(例如if块)的content handler会被执行。
 
7.1 示例1
 
location /proxy {  
      set $a 32;  
      if ($a = 32) {  
          set $a 56;  
      }  
      set $a 76;  
      proxy_pass http://127.0.0.1:$server_port/$a;  
  }  
  location ~ /(\d+) {  
      echo $1;  
  }  
 
 访问/proxy会显示76，
 
因为会像下列步骤执行：
 1.Nginx会按照在配置文件的出现顺序执行所有的rewrite阶段的指令，比如下面顺序执行：
 
set $a 32;  
if ($a = 32) {  
      set $a 56;  
}  
set $a 76;  
 
$a的最后为76。
 

 2.因为在上个阶段$a = 32条件匹配，Nginx会进入if内部location块。
 3.这个if内部location块没有任何content handler, 在外部域(outer scope)
 nginx_proxy继承了content handler(参考src/http/modules/ngx_http_proxy_module.c:2025)。
 4.proxy指定的配置也间接继承这个内部if块(详见src/http/modules/ngx_http_proxy_module.c:2015)。
 5.请求终止(控制流永远不会越过这个if块)。
 就是说，在此例子中在外部域的proxy_pass指令永远不会执行。实际上只有这个内部的if块为你服务。
 
简而言之：if block模块没有content handler，所以if block模块继承了外部模块/proxy 的`proxy_pass`，最后再if模块里执行了这个`proxy_pass`，而不是在/proxy模块中执行的`proxy_pass`。
 
让我们再来看看当我们复写了内部if块的content handler会发生什么。
 
7.2 示例2
 
location /proxy {  
      set $a 32;  
      if ($a = 32) {  
          set $a 56;  
          echo "a = $a";  
      }  
      set $a 76;  
      proxy_pass http://127.0.0.1:$server_port/$a;  
  }  
  location ~ /(\d+) {  
      echo $1;  
  }  
 
访问/proxy会得到a = 76。
 看起来不符合常理？那让我们来看看这次发生了什么：
 1.Nginx会按照配置文件出现的顺序来执行所有的rewrite阶段的指令，比如：
 
set $a 32;  
      if ($a = 32) {  
          set $a 56;  
      }  
  set $a 76;  
 
2.因为在上个阶段$a = 32条件匹配则Nginx跳入内部if块。
 3.这个内部块这次有了一个content handler，被echo指令指定，这样$a的值(76)会被发送给客户端。
 4.请求终止，请求终止(控制流永远不会越过这个if块)，如同第一个示例。
 
我们让示例2变得按照我们的意愿来工作：
 
7.3 示例3
 
location /proxy {  
      set $a 32;  
      if ($a = 32) {  
          set $a 56;  
          break;  
          echo "a = $a";  #echo是content handler，还是会被执行
      }  
      set $a 76;  
      proxy_pass http://127.0.0.1:$server_port/$a;  
  }  
  location ~ /(\d+) {  
      echo $1;  
  }  
 
 这次，我们仅仅在if块里加了一个break指令，这回让nginx中止执行剩下的ngx_rewrite指令，所以我们会得到a = 56。
 
所以这一次，nginx会这样工作：
 1.Nginx会按照配置文件出现的顺序来执行所有的rewrite阶段的指令，比如：
 
set $a 32;  
if ($a = 32) {  
      set $a 56;  
      break;  
}  
 
$a最后为56。
 2.因为在上个阶段$a = 32条件匹配则Nginx跳入内部if块。
 3.这个内部块这次有了一个content handler，被echo指令指定，这样$a的值(56)会被发送给客户端。
 4.请求终止，请求终止(控制流永远不会越过这个if块)，如同第一个示例。
 
OK，你在这里看到ngx_proxy模块在嵌入的多个location间的配置的继承扮演了关键的角色，这能让你按的心愿来工作。但是其他模块(比如echo，在作者之间的邮件提及)可能不会继承内嵌的location的content handler(事实上，大多是content handler模块，包括upstream都不支持继承)。
 

 在其它一些情况下，关于if块的配置文件的继承还有一些副作用需要注意，考虑下面的例子：
 
7.4 示例4
 
location /proxy {  
      set $a 32;  
      if ($a = 32) {  
          return 404;  
      }  
      set $a 76;  
      proxy_pass http://127.0.0.1:$server_port/$a;  
      more_set_headers "X-Foo: $a";  
  }  
  
  location ~ /(\d+) {  
      echo $1;  
  }  
 
 
 在这里，ngx_header_more模块的more_set_headers指令也会继承if块隐式创建的location。所以你会得到：
 
$ curl localhost/proxy  
  HTTP/1.1 404 Not Found  
  Server: nginx/0.8.54 (without pool)  
  Date: Mon, 14 Feb 2011 05:24:00 GMT  
  Content-Type: text/html  
  Content-Length: 184  
  Connection: keep-alive  
  X-Foo: 32  
 
 这可能是你想要的，或者是你不想要的:)
 

 顺便说说，如果在这个例子中换成add_header指令，将不会发送X-Foo头，这不代表没有发生指令的继承，而是add_header的头过滤器(header filter)会跳过404响应。
 
7.5 示例5
 
  When a request comes in to /proxy, the request process is terminated at (1) -> (2) -> (3) -> (4). 
  Probably pretty much the same as intended, and you see `a = 20` in the response. 
  Since the process ends immediately on that line, it can be understood in the same context as `if` in a general language. 
  So, it seems that only `return` is safe in the wiki. 
  By using the `break` or `last` flag in each `rewrite` statement, the behavior can be changed as desired. 
  For example, if you say `rewrite ^ /bbb last;` on line (4), it will rewrite with `/bbb` and terminate the process. 
https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/#examples
 
https://toutiao.io/posts/mi41q/preview
 
http://claude-ray.com/2019/01/09/nginx-ifisevil/
 
https://www.icode9.com/content-3-58703.html
 
https://wiki.jikexueyuan.com/project/openresty/ngx/pitfalls_and_common_mistakes.html
 
https://www.iteye.com/blog/damacheng009-1583879
 
https://ohgyun.com/607
                    nginx if 语句其实是 rewrite的一部分，我们在配置nginx时，需要明白if的一些特点。有关被 nginx 官方自我批判的 if 语句，《If Is Evil》—— 着实应成为每位开发者初次使用 nginx if 之前必读的文章。即使笔者一年前就开始接触使用 nginx 和 if 的组合做 url 跳转，但涉及的功能太简单，一直没能见识到它的真面目。直到近期在多个 if 内处理 proxy_pass 时，噩梦果真就降临了……希望大家仔细阅读上面的文章，引以为戒。如果想快速知道.
				
在上一篇文章:《Nginx if语句加正则表达式实现字符串截断》中, 我们介绍过了使用if来进行截断字符串的用法, 这次我们来了解下if的逻辑用法:
什么是逻辑用法呢, 就程序中的and、or关系, 就叫做逻辑了.
NGINX支持if的 and 与 or 或者 && 与 || 吗？
答案是No.
当你尝试这样配置, 重载nginx时, nginx会报出错误
 代码如下:
    location = /test/ {
        default_type text/html;
        set $b 0;
        if ( $remote_addr != ” && $http
~      #波浪线表示执行一个正则匹配，区分大小写
~*    #表示执行一个正则匹配，不区分大小写
^~    #^~表示普通字符匹配，如果该选项匹配，只匹配该选项，不匹配别的选项，一般用来匹配目录
=      #进行普通字符精确匹配
@     #"@" 定义一个命名的 location，使用在内部定向时，例如 error_page, try_fi
在location块中的if指令的有点问题，在某些情况下，if指令并不会按照我们预期的那般工作，而是有可能往完全不同的方向发展甚至可能会引起错误。因此最好的方法就是尽可能的不要使用if指令。
在location块的if指令内100%安全的指令有：
return
rewrite …… last
除了上面的两个指令之外的任何操作都有可能导致不可预测的效果甚至可能是
				
Nginx是当今最流行的Web服务器之一。它为世界上7%的web流量提供服务而且正在以惊人的速度增长。它是个让人惊奇的服务器，我愿意部署它。
下面是一个常见安全陷阱和解决方案的列表，它可以辅助来确保你的Nginx部署是安全的。
1. 在配置文件中小心使用"if"。它是重写模块的一部分，不应该在任何地方使用。
“if”声明是重写模块评估指令强制性的部分。换个说法，Nginx的配
				
nginx不支持if-else语句，但可以使用一些其他的指令来实现类似的功能。以下是两种常见的方法：
1. 使用location指令和正则表达式来匹配URL，并根据条件执行不同的操作。例如，可以使用if指令来检查请求的URL是否匹配某个条件，然后执行相应的操作。下面是一个示例：
```nginx
location / {
    if ($request_uri ~* "/admin") {
        # 执行某些操作
    if ($request_uri ~* "/user") {
        # 执行其他操作
    # 默认操作
2. 使用map指令来创建一个变量映射表，根据条件设置变量的值，然后根据变量的值执行相应的操作。下面是一个示例：
```nginx
map $request_uri $action {
    ~* "/admin"   admin;
    ~* "/user"    user;
    default      default;
server {
    location / {
        if ($action = "admin") {
            # 执行某些操作
        if ($action = "user") {
            # 执行其他操作
        # 默认操作
请注意，使用if指令可能会导致性能问题，并且在某些情况下可能会产生意外的结果。因此，建议尽量避免使用if指令，而是使用其他更高效和可靠的方法来实现类似的功能。