Nginx配置验证工具
粘贴 nginx.conf，在真正重载 nginx 之前发现语法错误、指令位置错误和常见安全配置问题。
将 .conf 文件拖放到此处，或在上方粘贴配置文本。
所有处理均在你的浏览器内完成 — 配置内容永远不会上传到任何服务器。
在上方粘贴 nginx 配置（或加载示例），检查结果会显示在这里。
使用的是 JavaScript 的正则引擎，并非 nginx 真正使用的 PCRE 引擎 —— 常见模式下非常接近，但并不完全相同（例如没有独占量词/原子组）。
在 nginx 配置上线之前就发现错误
出错的 nginx.conf 通常会以两种令人不快的方式暴露自己：一是 `nginx -t` 拒绝重载，并抛出一条晦涩的行号报错；二是更糟的情况——`reload` 悄悄在内存中保留旧的（可用的）配置，而新的配置在磁盘上其实是坏的，所以直到下次完整重启之前，看起来一切正常。这两种情况都可以通过更早地发现同类错误来避免，也就是在你还在编辑的时候。
现实中最常见的 nginx.conf 错误并不稀奇——就是忘了写分号。因为 nginx 的语法只认 `;`、`{` 和 `}`（不看换行），缺少 `;` 并不会像大多数现代解析器那样给出清楚的“第 12 行：应为 ;”错误；相反，下一条指令的名称和参数会被悄悄吞进上一条指令，成为它的多余参数，有时直到下游行为异常之前都不会有任何报错。本工具的换行启发式检查专门盯着这种模式——已知指令名出现在新的一行、却位于上一条指令的参数列表中间——并在它变成工单之前把它标出来。
指令放置是第二个常见陷阱：`proxy_pass` 只有放在 `location`（或 `if`）块内才有意义，`listen`/`server_name` 只能放在 `server` 内，等等——但如果指令名在更宽泛的意义上能被 nginx 识别，它自己的解析器并不会仅仅因为位置不寻常就拒绝，而且报错信息指向的是 nginx 内部的指令注册表，而不是告诉你“这里嵌套错了”。本校验器直接检查“指令—上下文”对照表，因此不小心留在 `http` 层级（任何 `server`/`location` 之外）的 `proxy_pass`，会被标出确切的行号，而不是只告诉你“配置加载失败”。
除了语法，一些小小的配置选择会带来不成比例的安全后果：让 `server_tokens` 保持默认值（`on`），会在每个响应头和默认错误页中泄露你确切的 nginx 版本，对任何探测特定版本 CVE 的人来说，这相当于免费的侦察；在 `return`/`rewrite`/`add_header` 中使用经 URL 解码的 `$uri` 变量（而不是原始的 `$request_uri`），在某些配置下可能让攻击者向重定向目标中注入字符。这两种情况在正常测试中都不会出现明显的故障，这正是它们值得专门检查一遍、而不是靠肉眼在 200 行配置里发现的原因。
常见问题
它能取代 `nginx -t` 吗？
不能。`nginx -t` 是唯一能对照你服务器上实际安装的 nginx 版本和模块检查配置的工具，也是重载之前的最终裁决。本校验器检查的是同一类错误（语法错误、指令放错位置、若干安全隐患），而且在你还没用上装有 nginx 的服务器之前就能做到——适合在本地编辑、CI 步骤中使用，或暂时还没有目标机器 shell 权限的时候。
安全检查清单是否面面俱到？
不是——它只涵盖少量精心挑选的检查项（缺少 `server_tokens off;`、`autoindex on;`，以及在 `$request_uri` 更安全的地方使用了 `$uri`），灵感大致来自开源的 nginx 配置审计工具 Gixy。它不能取代 Gixy，也不能替代完整的安全审计。
为什么正则测试器的行为与真实的 nginx 略有不同？
nginx 的 `location ~` 和 `location ~*` 匹配使用 PCRE（通过 nginx 二进制中捆绑的 PCRE 库）。本工具完全在浏览器中运行，所以改用 JavaScript 内置的 RegExp 引擎——对常见的表达式，两者非常接近，但像占有量词或原子分组这类 PCRE 独有的特性，在这里的行为就不一样。
我的配置会离开浏览器吗？
不会。解析、校验以及两个模拟器都用纯 JavaScript 在本标签页中运行。没有任何内容被上传、记录或发送到别处——页面加载完成后，你甚至可以断开网络，它依然能正常工作。