在 nginx 的世界里，每个 Nginx 模块都能够定义本人的配置指令，所以这些指令的格局形形色色。比方 content_by_lua_block 后跟着的是 Lua 语法，limit_req_zone 后则跟着以空格、等号、冒号等分隔的多个选项。这些模块有没有必然遵循的通用格局呢？如果有，那么把握了它，就能疾速读懂生产环境简单的 nginx.conf 文件。明天便来解说 Nginx 配置文件的语法格局。
Nginx 是由大量框架代码、大量模块形成的，其中，Nginx 框架会依照特定的语法，将配置指令读取进去，再交由模块解决。因而，Nginx 框架定义了通用的语法规定，而 Nginx 模块则定义了每条指令的语法规定，作为初学者，如果将学习指标定为把握所有的配置指令，方向就齐全错了，而且这是不可能实现的工作。
比方，ngx_http_lua_module 模块定义了 content_by_lua_block 指令，只有它合乎框架定义的 {} 块语法规定，哪怕大括号内是一大串 Lua 语言代码，框架也会把它交由 ngx_http_lua_module 模块解决。因而，上面这行指令就是非法的：
content_by_lua_block {ngx.say(“Hello World “)}
所以，在我看来，只有弄清楚了以下 2 点，就能疾速把握 Nginx 配置文件，：
第一点：Nginx 框架定义了每条指令的根本格局，这是所有模块必须恪守的规定，这包含以下 5 条语法：
通过 {} 大括号作为分隔符的配置块语法。比方 http{}、location{}、upstream{}等等，至于配置块中到底是搁置 Javascript 语言、Lua 语言还是字符串、数字，这齐全由定义配置块的 Nginx 模块而定。
通过；分号作为分隔符的指令语法。比方 root html; 就关上了动态资源服务。
以 #作为关键字的正文语法。比方#pid logs/nginx.pid; 指令就是不会失效的。
以 $ 作为关键字的变量语法。变量是 Nginx 模块之间可能互相配合的外围因素，也是 Nginx 与管理员之间的重要接口，通过 $ 变量名的模式，就能够灵便管制 Nginx 模块的行为。
include 指令能够将其余配置文件载入到 nginx.conf 中，这样能够晋升配置的可维护性。例如 include mime.types; 语句，就将 Content-Type 与文件后缀名的映射关系，放在了独立的 mime.types 文件中，升高了耦合性。
第二点：Nginx 框架为了进步模块解析指令选项的效率，提供了一系列通用的工具函数，绝大多数模块都会应用它们，毕竟这升高了模块开发的难度以及用户的学习老本。比方，当配置文件中蕴含字节数时，Nginx 框架提供了 ngx_conf_set_size_slot 函数，各模块通过它就能够解析以下单位：
因而，limit_req_zone 指令中 zone=one:10m 中就定义 10MB 的共享内存，这代替了很不好了解的 10485760 字节。
再比方，读取工夫能够应用以下单位：
这样，ssl_session_cache shared:SSL:2h; 指令就设置 TLS 会话信息缓存 2 小时后过期。
除以上规定外，如果编译了 pcre 开发库后，你还能够在 nginx.conf 中应用正则表达式，它们通常以~ 符号打头。
因为每个 Nginx 模块都能定义独特的指令，这让 nginx.conf 变成了简单的运维界面。在把握了根本的配置语法，以及第三方模块定义指令时遵循的潜规则后，你就能熟能生巧地编写 Nginx 配置文件。