Nginx設定検証ツール
nginx.confを貼り付けて、構文エラー・配置ミスのディレクティブ・よくあるセキュリティの誤設定を、実際にnginxを再読み込みする前に検出します。
ここに.confファイルをドロップするか、上に設定テキストを貼り付けてください。
すべての処理はブラウザ内で完結します — 設定内容がサーバーにアップロードされることはありません。
上に nginx の設定を貼り付ける（またはサンプルを読み込む）と、ここにチェック結果が表示されます。
nginx本来のPCREエンジンではなく、JavaScriptの正規表現エンジンを使用しています — 一般的なパターンではほぼ同じですが、所有格量指定子やアトミックグループなど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` で生の `$request_uri` ではなく URL デコード済みの `$uri` 変数を使うと、構成によっては攻撃者がリダイレクト先に文字を注入できてしまいます。どちらも通常のテストでは目に見える不具合を起こさないため、200 行の設定を目で追って気づくのを期待するより、専用のチェックを通す価値があります。
よくある質問
`nginx -t` の代わりになりますか？
いいえ。`nginx -t` は、サーバーに実際にインストールされている nginx のビルドとモジュールに照らして設定を確認できる唯一のツールで、リロード前の最終確認になります。このバリデーターは、構文エラー、ディレクティブの置き場所の誤り、いくつかのセキュリティ上の懸念点といった同じ種類の間違いを、nginx がインストールされたサーバーに到達する前に見つけます。ローカルでの編集中、CI のステップ、まだ対象マシンにシェルでアクセスできないときに役立ちます。
セキュリティチェックは網羅的ですか？
いいえ。オープンソースの nginx 設定監査ツール Gixy を参考に、意図的に絞り込んだ少数のチェック（`server_tokens off;` の欠落、`autoindex on;`、`$request_uri` のほうが安全な場面での `$uri` の使用）を扱っているだけです。Gixy の代わりにはならず、本格的なセキュリティ監査でもありません。
正規表現テスターが本物の nginx と少し違う動きをするのはなぜですか？
nginx の `location ~` と `location ~*` のマッチングは、nginx バイナリに同梱の PCRE ライブラリによる PCRE を使っています。このツールはすべてブラウザ内で動くため、代わりに JavaScript 標準の RegExp エンジンを使っています。一般的なパターンならほぼ同じ結果になりますが、強欲な量指定子（possessive quantifier）やアトミックグループなど PCRE 固有の機能は、同じようには動作しません。
設定内容がブラウザの外に出ることはありますか？
いいえ。解析、検証、2 つのシミュレーターは、このタブ内の素の JavaScript で動作します。アップロード、ログ記録、送信は一切行われません。ページの読み込み後にインターネットから切断しても、そのまま動き続けます。