コンテンツにスキップ
DevLab

🟩 nginx.conf ジェネレーター

ホスト名・ルートディレクトリ・SSL 証明書パスを入れてチェックボックスで機能を選ぶだけ。HTTPS リダイレクト・HTTP/2・モダン TLS・HSTS・gzip / brotli・静的キャッシュ・PHP-FPM・リバースプロキシ・WebSocket・try_files まで本番運用レベルの server ブロックをリアルタイム生成。

完全無料 登録不要 ブラウザ完結 5 言語対応 ダークモード

🔒 プライバシーについて

🎛 プリセット

🧩 機能の選択

📄 生成された nginx.conf


        
    






    
📖 つまずきやすいポイント


        
静的サイト・リバースプロキシ・PHP-FPM といった構成から、server ブロックを含む nginx.conf を生成します。SSL・gzip・キャッシュ・セキュリティヘッダーの指定もまとめて出力できます。処理はブラウザ内で完結します。ただし生成できるのは構文であって、あなたの環境で正しく動く保証ではありません — 証明書のパスが存在するか、upstream に到達できるか、ドキュメントルートが合っているかは検証できません。そして nginx で時間を失うのは、たいてい設定を「書き間違えた」ときではなく、「書いたつもりの意味と、nginx が解釈した意味が違った」ときです。

    
        

        

            
                

                    ケース
                    何が起きるか
                    どうする
                

            
            
                                

                    location は書いた順に評価されない
                    nginx は location を上から順に試すのではなく、決められた優先順位で選びます。まず = の完全一致、次に 最長の前方一致 (^~ が付いていればそこで確定)、その後に 正規表現 (~ / ~*) を記述順に、どれも一致しなければ先に保留した最長の前方一致が使われます。つまりブロックを上下に動かしても何も変わらないことが多く、逆に正規表現ブロックを 1 つ足すと、前方一致ブロックが処理していたリクエストを静かに奪います。典型的な症状は、静的ファイルが PHP に渡ってしまう (またはその逆) で、location ~ \.php$ と location /assets/ の関係を誤解しているときに起きます。
                    推測せず nginx -T を実行してください。 include をすべて展開した最終的な設定が表示されるので、「どこかの別ファイルにも同じ location がある」といった見落としがその場で分かります。設計としては、静的ファイルを先に確定させるのが安全です — location ^~ /assets/ と書けば、そこで正規表現の評価が止まります。トップページや favicon.ico のように 1 つに定まる URL は = で書くと、最も速く、意図も明確になります。変更後は必ず具体的な URL を curl で叩いて確かめてください — 設定を読んで正しそうに見えることと、実際にどのブロックが選ばれるかは別です。
                

                                

                    add_header は継承ではなく上書きされる
                    nginx の継承には直感に反する規則があります。子ブロックが同じディレクティブを 1 つでも書くと、親で書いた同種のディレクティブはすべて無効になります — 「足される」のではなく「置き換わる」のです。実害が大きいのが add_header で、server ブロックにセキュリティヘッダーを 5 つ書いておき、location ~ \.php$ の中にキャッシュ制御を 1 行足しただけで、PHP のレスポンスからセキュリティヘッダーが 5 つとも消えます。エラーも警告も出ません — 診断サイトで「ヘッダーが無い」と言われて初めて気付く類のものです。同じ規則は proxy_set_header にも適用されます — location 内で 1 つ足すと、上位で設定したプロキシヘッダーが全部消えます。
                    まず curl -I で実際のレスポンスヘッダーを確認してください — 設定に書いてあることと、返っているものは別です。対処は 2 つあります。ヘッダーを 1 か所にまとめ、下位ブロックでは add_header を一切書かないのが最も単純です。それが無理なら、ヘッダー群を別ファイルに切り出して、必要な location ごとに include する — 重複しますが、消えるよりはるかにましです。そして add_header には always を付けてください — 付けないと、4xx や 5xx のレスポンスにはヘッダーが付きません (エラーページこそ守りたい場面が多いのに、です)。同じ注意は proxy_set_header にも当てはまります。
                

                                

                    リバースプロキシで壊れるのはヘッダーとサイズ
                    proxy_pass を書いただけでは、アプリは自分がどのホスト名で、どのプロトコルで呼ばれたのかを知りません。Host と X-Forwarded-Proto を渡さないと、アプリは http://localhost:3000/... のような URL を生成し、リダイレクトがループし、Cookie のドメインがずれます。proxy_pass の末尾スラッシュも意味が変わります — proxy_pass http://app; は元のパスをそのまま渡し、proxy_pass http://app/; は location の部分を取り除いて渡します。この 1 文字で 404 になります。サイズと時間の既定値も要注意で、client_max_body_size の既定は 1MB — それを超えるアップロードは、アプリに届く前に 413 で弾かれます。WebSocket は Upgrade と Connection を明示しないと接続できません。
                    プロキシの location には、最低限この 4 つを書いてください: proxy_set_header Host $host;、X-Real-IP $remote_addr;、X-Forwarded-For $proxy_add_x_forwarded_for;、X-Forwarded-Proto $scheme;。そしてアプリ側でそれらを信頼する設定 (trusted proxies) を有効にしてください — 片方だけでは効きません。アップロードを扱うなら client_max_body_size をアプリ側の上限と揃え、時間のかかる処理があるなら proxy_read_timeout (既定 60 秒) も一緒に延ばします — どちらか一方だけを変えても、短いほうで切れます。反映は nginx -t && nginx -s reload で行い、502 が出たときは access.log ではなく error.log を見てください — 原因はほぼ必ずそちらに書かれています。
                

                            
        

    

    
        
編集しただけでは何も変わりません。nginx は起動時に設定を読み込んだきりなので、ファイルを保存しても reload するまで挙動は変わりません — 「直したのに直らない」と思ったら、まずリロードしたかを確認してください。順序は必ず nginx -t で構文を検査してから reload です — 検査せずに restart すると、設定に誤りがあった場合に nginx が起動せず、サイトが完全に落ちます (reload なら、設定が不正でも古い設定で動き続けます)。証明書について 1 つ: ssl_certificate には cert.pem ではなく fullchain.pem を指定してください — 中間証明書が欠けていると、ブラウザでは正常に見えるのに、curl・モバイルアプリ・古い環境からは検証に失敗します。この不具合は「自分の環境では再現しない」ため、報告されるまで気付けません。最後に、設定ファイルは必ずバージョン管理してください — 本番サーバー上で直接編集した変更は、次のデプロイで静かに消えます。

    









    
📖 使い方

    
    
                
  1. 
            1
            
    
                
    プリセットを選ぶ
    
                
    静的サイト / WordPress / Laravel / Next.js のいずれかを選択すると、推奨機能が自動でチェックされます。
    
            
    
        
    2. 
                
  2. 
            2
            
    
                
    ホスト名と SSL パスを入力
    
                
    server_name とドキュメントルート、Lets Encrypt の fullchain.pem / privkey.pem パスを入力。
    
            
    
        
    3. 
                
  3. 
            3
            
    
                
    コピー or ダウンロード
    
                
    右上のボタンでクリップボードへコピー、または .conf ファイルとしてダウンロード。
    
            
    
        
    4. 
                
  4. 
            4
            
    
                
    nginx に配置して再起動
    
                
    /etc/nginx/sites-available/ に配置 → sites-enabled へシンボリックリンク → sudo nginx -t で構文チェック → sudo systemctl reload nginx。
    
            
    
        
    5. 
            






    
❓ よくある質問

    

                

            
                SSL 証明書がまだない場合はどうすれば？
                
            
            
Lets Encrypt の certbot で無料発行できます。sudo certbot --nginx -d example.com -d www.example.com で取得 → 設定にパスを反映。HSTS は HTTPS が完全に動いてから有効化してください。

        

                

            
                nginx -t でエラーが出ます
                
            
            
多くは SSL パスのタイプミスか、PHP-FPM ソケットパスが環境と異なるケースです。エラーメッセージの行番号とjournalctl -u nginxを確認してください。

        

                

            
                Apache の .htaccess は使えますか？
                
            
            
使えません。nginx は .htaccess を読まないので、リライト等は server / location ブロックに直接書く必要があります。当サイトの .htaccess ジェネレーターと併用すると Apache 環境でも対応できます。

        

            






    

        
🔗 関連ツール

        
    






    

        
            🐛 このツールで問題が発生しましたか？
            
        

        

            完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
        


        

                        

            

                
                
            


            

                
                
                

                    ※ 不具合再現のため、ブラウザ情報 (UA / 画面サイズ / 言語 / URL) を自動で送信します