嵌套位置块中的指令继承

muf*_*fel 15 nginx

以下两个nginx服务器块在语义上是相同的,还是有什么区别?第一个示例中的JSON特定配置是否继承了"/"位置的设置?它是在第二个例子中吗?

server {
  location / {
     # ...
     location ~* \.json$ {
          # json-specific settings
     }
  }
}

server {
  location / {
     # ...
  }
  location ~*  \.json$ {
    # json-specific settings
  }
}
Run Code Online (Sandbox Code Playgroud)

Day*_*ayo 21

Nginx中的配置指令的继承是这样的,指令只能从配置树上方的上下文继承,而不能从同一级别或更低级别的上下文继承.

因此,位置块不能从另一个位置块继承,但嵌套位置块可以从父位置块继承.

我强调可以因为有许多不同类型的指令,并且继承行为对于每个指令都有所不同.

  1. 有标准类型指令,只附加一个值或一组值.这些将简单地由配置树下方的上下文继承,或者通过新值在该较低上下文中替换.一个例子是"索引".

  2. 数组类型指令,它在数组中传递多个单独的值.这些将简单地由配置树下方的上下文继承,或者通过新值在该较低上下文中替换.请注意,您无法添加到阵列.改变部分正在取代所有.一个例子是"proxy_param".因此,如果您在服务器级别定义proxy_param A和proxy_param B,然后尝试在位置上下文中定义proxy_param C,则将清除"A"和"B"(设置为默认值).因为定义"C"意味着更换阵列.

  3. 命令类型指令(如"try_files")通常不会继承.

因此,特别针对您的问题,在一个位置块上下文中定义的指令不能像第二个示例那样由另一个位置块上下文继承.

父位置块中定义的标准和数组类型指令将由嵌套位置块继承.父级中定义的命令类型指令通常不会继承.

  • `proxy_pass`也是[不是由嵌套位置继承](https://forum.nginx.org/read.php?2,243488,243488). (24认同)
  • 是否有任何该死的参考表可以咨询知道哪个指令是继承的还是未继承的?真是太痛苦了,然后点击评论中的链接,指向另一个论坛,阅读谁知道"proxy_pass不是继承的" (11认同)
  • 似乎是一个非常严重的缺陷,例如子上下文中的“add_header”不能包含来自父上下文的标头。这是一个严重的问题,而且非常不直观,并且会导致配置重复。 (10认同)
  • 有这么多奇怪的怪癖和缺陷,我很难理解为什么 nginx 如此受欢迎。我开始认为我应该使用 ATS 或其他东西作为我的反向代理。 (5认同)
  • `uwsgi_pass` 也不是继承的。 (3认同)
  • 什么集群**** (2认同)