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 自己的解析器並不會因為它放在不尋常的位置就拒絕，而且錯誤訊息指向的是 nginx 內部的指令登記表，而不是告訴你「這裡巢狀放錯了」。本驗證器會直接檢查指令與所屬區塊的對應表，因此不小心放在 `http` 層級（任何 `server`/`location` 之外）的 `proxy_pass`，會被標示出確切的行號，而不只是告訴你「設定載入失敗」。
除了語法之外，少數看似微小的設定選擇也可能帶來極大的安全影響：讓 `server_tokens` 維持預設值（`on`），會在每個回應標頭與預設錯誤頁面中洩漏你確切的 nginx 版本，等於免費提供給想探測特定版本 CVE 的人做偵察；在 `return`/`rewrite`/`add_header` 中使用已解碼的 `$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 執行，不會上傳、記錄或傳送到任何地方，頁面載入完成後你甚至可以中斷網路，它仍然能正常運作。