--- title: "nginxの最新バージョンは1.31系（安定版1.30）｜バージョン確認コマンド・更新手順と変更点【2026年10月】" url: "https://www.issoh.co.jp/tech/details/11585/" published: 2026-03-30 updated: 2026-10-24 categories: ["インフラ・クラウド"] publisher: "株式会社一創" --- # nginxの最新バージョンは1.31系（安定版1.30）｜バージョン確認コマンド・更新手順と変更点【2026年10月】 2026年10月24日時点のnginxの最新バージョンは、開発版（mainline）が10月21日公開の1.31.8、安定版（stable）が10月14日公開の1.30.6です。10月14日には両系列で5件の脆弱性が修正されたので、1.30.5以前・1.31.6以前を使っているなら更新が必要です。 この記事では、手元とサーバーの版を確かめるコマンド、3つのブランチの現行版とサポート期限、1.29.0から1.31.8までのリリース履歴、1.29.7で変わった既定値、2026年の脆弱性と修正版の対応、無停止で更新する手順をまとめます。版と日付はnginx.orgの[CHANGES](https://nginx.org/en/CHANGES)と[セキュリティアドバイザリ](https://nginx.org/en/security%5Fadvisories.html)で照合し、確認方法と更新手順はDockerで1.30.6から1.31.8へ入れ替えて動作を確かめました。 ## まとめ：nginxの最新バージョンと確認・更新の要点 - **最新版**：mainline 1.31.8（2026年10月21日）、stable 1.30.6（2026年10月14日）。新機能は原則mainlineに入り、stableには脆弱性修正と重要な不具合修正が取り込まれる - **版の確認**：`nginx -v`で版、`nginx -V`でビルドオプションまで出る。出力先は標準エラー。稼働中のサーバーの版は`curl -sI`のServerヘッダーで見る - **更新後のずれ**：バイナリを入れ替えても再起動しなければ、`nginx -v`は新しい版、実際に動いているのは古い版のまま。`nginx -s reload`でも切り替わらない - **1.28系以前**：最後の版は1.28.3（2026年3月24日）。nginx.orgの範囲で数えると、1.28.3には修正版の出ていない脆弱性が15件ある。nginx.org版を使っているなら1.30系か1.31系へ上げる - **サポート期限**：nginx.orgはEOL日を公表していない。1.20系以降、次の安定版が出た後に旧系列の修正版が出たことは一度もなく、1.30系も2027年春の次の安定版までと見て計画する - **ディストリの標準パッケージ**：Ubuntu 24.04は1.24.0、Debian 13は1.26.3のままで、修正はバックポートで当たる。版番号だけで脆弱かどうかは判断できない ## nginxのバージョン確認方法 ### nginx -vとnginx -Vで確認するコマンド ``` $ nginx -v nginx version: nginx/1.31.8 $ nginx -V # ビルドオプションまで表示 nginx version: nginx/1.31.8 built by gcc 15.2.0 (Alpine 15.2.0) built with OpenSSL 3.5.9 29 Sep 2026 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx ... # ディストリのパッケージ版（バックポートの有無はこちらで見る） $ dpkg -l nginx # Debian・Ubuntu $ rpm -q nginx # RHEL系・Amazon Linux ``` どちらも出力先は標準エラーです。1.30.6の公式イメージで試すと、`nginx -v 2>/dev/null`の標準出力は0バイトで、`2>&1`を付けると28バイトの版表記が出ました。`grep`やファイルへ渡すときは`nginx -v 2>&1`と書きます。`-V`は、リンクされたOpenSSLの版や、json moduleのように既定で入らないモジュールの有無を確かめるときに使います。上の出力は公式Dockerイメージ`nginx:1.31.8-alpine`のものです。 一般ユーザーで`nginx: command not found`になる場合は、nginxが未インストールか、実行ファイルのあるディレクトリがPATHに含まれていない可能性があります。Debian 13の`/etc/profile`は、rootには`/usr/sbin`を含むPATHを、それ以外のユーザーには含まないPATHを設定しています。`/usr/sbin/nginx -v`のようにフルパスで実行すれば、root権限が無くても版は表示されます。 ### 稼働中のnginxの版：Serverヘッダーとエラーページ サーバーの外から版を見るときは、レスポンスヘッダーを取ります。ブラウザの開発者ツールのNetworkタブでも同じ値が見えます。ただし、CDNや別のリバースプロキシを経由している場合、Serverヘッダーは手前のサーバーが付けた値かもしれません。更新の確認では、対象のnginxへ直接接続します。 ``` $ curl -sI http://127.0.0.1/ | grep -i ^server Server: nginx/1.30.6 ``` 「502 Bad Gateway nginx/1.28.3」のように、エラーページの下部にも版が出ます。`server_tokens`の既定が`on`で、Serverヘッダーとエラーページの両方に版を書くためです。10月8日に1.31.6でバックエンドを止めて確かめたときは、502のページに`nginx/1.31.6`と出ました。 外部から版を読み取られたくなければ、httpブロックに`server_tokens off;`を書きます。Serverヘッダーは`nginx`だけになり、エラーページからも版が消えます。その場合は、サーバー内で次の項の方法を使って確かめます。逆に、他人のサイトのエラーページに古い版が出ていても、それだけで脆弱とは言えません。ディストリの標準パッケージはバックポートで修正されていても、元の版番号を表示するからです。 ### 更新後にnginx -vと稼働中の版がずれる例 `nginx -v`が表示するのは、ディスク上にある実行ファイルの版です。動いているプロセスの版ではありません。1.30.6で稼働中のコンテナで、1.31.8のバイナリを別名で置いて`mv`で差し替え（パッケージ更新と同じく、ファイルを書き換えずに置き換える方法）、そのまま確かめました。 ``` $ nginx -v nginx version: nginx/1.31.8 # ディスク上のファイルは新しい版 $ curl -sI http://127.0.0.1/ | grep -i ^server Server: nginx/1.30.6 # 応答しているのは古い版 $ ls -l /proc/$(cat /run/nginx.pid)/exe ... -> /usr/sbin/nginx (deleted) # 置き換え前のファイルを開いたまま $ nginx -s reload # HUPを送っても $ curl -sI http://127.0.0.1/ | grep -i ^server Server: nginx/1.30.6 # 版は変わらない ``` `(deleted)`が付いていれば、マスタープロセスは更新前のファイルで動いています。`nginx -s reload`（HUP）は設定を読み直してワーカーを作り直すだけで、新しいワーカーも同じマスターから作られるので、版は変わりません。脆弱性の修正版を入れたあとは、再起動するか後述のUSR2で入れ替えたうえで、Serverヘッダーか`/proc`の表示で切り替わったことを確かめてから「対応済み」とします。`pid`ファイルの場所は`pid`ディレクティブの値で、Debian・Ubuntuの標準パッケージとnginx.org版はいずれも`/run/nginx.pid`です。 ### Docker公式イメージのタグと版 Docker Hubの公式イメージも、タグがmainlineとstableに分かれています。2026年10月24日にpullして`docker run --rm nginx:<タグ> nginx -v`で確かめた結果は次のとおりです。 | タグ | 中身の版 | | ------------------------------- | ------ | | latest・mainline・mainline-alpine | 1.31.8 | | stable・stable-alpine | 1.30.6 | | 1.31.8-alpine・1.30.6-alpine | 表記どおり | `latest`はstableではなくmainlineを指します。安定版のつもりで`nginx:latest`を使っていると、pullのたびに奇数系列の新しい版が入ります。本番では`nginx:1.30.6-alpine`のように版を固定し、修正版が出たらタグを書き換えてコンテナを作り直します。公式イメージはnginxを`daemon off;`でPID 1として動かすので、後述のUSR2による入れ替えはできません。 ### ディストリ標準パッケージの版番号とバックポート UbuntuやDebianの安定版では、nginxの上流版番号を維持しながら、脆弱性修正や重要な不具合修正を取り込む更新が行われます（バックポート）。2026年10月24日時点で、LaunchpadとDebianのパッケージ情報から取った版は次のとおりです。Ubuntuの3つの版と公開日は[USN-8563-5](https://ubuntu.com/security/notices/USN-8563-5)、Debianの版は[Debian Sources](https://sources.debian.org/src/nginx/)で確認できます。 | ディストリ | 標準パッケージの版 | 公開日 | | ------------------- | ------------------- | ---------- | | Ubuntu 26.04 LTS | 1.28.3-2ubuntu1.11 | 2026-09-14 | | Ubuntu 24.04 LTS | 1.24.0-2ubuntu7.18 | 2026-09-14 | | Ubuntu 22.04 LTS | 1.18.0-6ubuntu14.21 | 2026-09-14 | | Debian 13（trixie） | 1.26.3-3+deb13u7 | ― | | Debian 12（bookworm） | 1.22.1-9+deb12u9 | ― | 末尾の`ubuntu7.18`や`deb13u7`が、修正を取り込むたびに上がる部分です。Ubuntuの3つは9月14日の更新が最新で、10月14日に公表された5件に対応した版はこの時点ではまだ出ていません。Debian 13は次の`deb13u10`がtrixie-proposed-updatesに入っています。`nginx -v`は元の版（1.24.0など）しか表示しないので、修正済みかどうかはパッケージの版と各ディストリのセキュリティ情報を照らし合わせて判断します。 ## nginxの現行バージョン一覧：mainline・stable・legacyの3区分 nginx.orgのダウンロードページは、版を次の3つに分けて掲載しています。2026年10月24日時点の内容です。 | 区分 | 最新版 | 公開日 | この系列で入るもの | | ------------- | ------ | ---------- | ------------------- | | Mainline（開発版） | 1.31.8 | 2026-10-21 | 新機能・仕様変更・バグ修正・脆弱性修正 | | Stable（安定版） | 1.30.6 | 2026-10-14 | 脆弱性修正と重要な不具合の修正 | | Legacy | 1.28.3 | 2026-03-24 | なし（1.30.0公開後は更新なし） | ### mainlineとstableの選び方 番号の2つ目が奇数ならmainline、偶数ならstableです。stableは毎年春にその時点のmainlineから分岐します。1.30.0は2026年4月14日に公開され、1週間前の1.29.8までの変更をそのまま引き継いでいます。以後の1.30.1〜1.30.6のCHANGESに並ぶのは、脆弱性修正と、mainlineで先に直された不具合の修正、少数の仕様変更です。 脆弱性の修正は両方の系列に同じ日に出ます。2026年5月13日の1.31.0／1.30.1から10月14日の1.31.7／1.30.6まで、修正版は6回とも同時に公開されました。ただし影響範囲は系列ごとに異なり、CVE-2026-42530は1.31.0と1.31.1だけが対象でした。 - **stableを選ぶ**：新機能に伴う設定変更を、主に安定版系列の更新時にまとめたい場合。1.31.7のHTTP/2の優先度方式の変更（RFC 9218へ移行）のようなmainlineの仕様変更は追わずに済む。ただし1.30.6のログレベル変更のように、同じ系列の修正版にも仕様変更は入る - **mainlineを選ぶ**：predicate locationや`ngx_http_json_module`（1.31.5）、geoipモジュールのMMDB形式対応（1.31.7）のように、stableには翌春まで入らない機能が必要な場合 系列の選択より、修正版が出た週のうちに入れ替えられる体制のほうが効きます。 ### 安定版のサポート期限：系列ごとの公開日と最終版 nginx.orgは系列ごとのEOL日を公表していません。各系列のCHANGESから公開日を並べると、修正版が出なくなる時期の実績は次のとおりです。 | 系列 | 初版の公開日 | 最終版 | 最終版の公開日 | 次の安定版 | | ---- | ---------- | ----------- | ---------- | ------------------ | | 1.30 | 2026-04-14 | 1.30.6（継続中） | 2026-10-14 | ― | | 1.28 | 2025-04-23 | 1.28.3 | 2026-03-24 | 1.30.0（2026-04-14） | | 1.26 | 2024-04-23 | 1.26.3 | 2025-02-05 | 1.28.0（2025-04-23） | | 1.24 | 2023-04-11 | 1.24.0 | 2023-04-11 | 1.26.0（2024-04-23） | | 1.22 | 2022-05-24 | 1.22.1 | 2022-10-19 | 1.24.0（2023-04-11） | | 1.20 | 2021-04-20 | 1.20.2 | 2021-11-16 | 1.22.0（2022-05-24） | どの系列も、次の安定版が出た後には1本も修正版が出ていません。過去の更新実績から、次の安定版の公開を移行計画の目安にできます。1.30系では2027年春ごろの後継版を想定できますが、これは公式に確約された公開時期やサポート期限ではありません。1.24系のように初版の後に修正版が一度も出なかった系列もあるので、毎年春の安定版の公開に合わせて移行の枠を取っておきます。 ### 修正が止まった1.28系に残る脆弱性 1.28系の最後の版である1.28.3は、1.29.7と同じ日に出た6件の修正を含みます。しかし1.30.0の公開後に1.28系の更新は出ていません。nginx.orgのセキュリティアドバイザリで、脆弱な版の範囲に1.28.3が入り、修正版が1.30系・1.31系にしか無いものを数えると、2026年10月24日時点で15件あります。 - CVE-2026-42945（rewriteモジュールのヒープオーバーフロー・通称NGINX Rift）、CVE-2026-42533（mapと正規表現・severity major）、10月14日公表のCVE-2026-15176（aliasとrewriteの組み合わせでのバッファオーバーフロー）を含む - 10月14日の5件のうちCVE-2026-93479は、脆弱な範囲が1.31.2〜1.31.6と1.30.0〜1.30.5で、1.28.3は含まない。残る4件は1.28.3も対象 - CVE-2026-9256は、アドバイザリでは「0.1.17-1.31.0」と書かれる一方、CVEレコード（cveawg.mitre.org、2026年10月24日取得）の影響範囲には1.28.3が列挙されていない。ただし同じレコードには、サポート終了版は評価しないという注記があり、記載がないことは影響がないという意味ではない。ここではnginx.orgの範囲で数えている nginx.orgの公式パッケージや自前ビルドで1.28.3を使っている場合、これら15件について、1.28系向けの修正版は出ていません。1.30系へ上げてください。ディストリの標準パッケージは前章のバックポートで扱いが違います。個別のCVEの影響条件は[NGINX Rift（CVE-2026-42945）の影響判定とPoCの中身](/tech/details/12209/)にまとめています。 ## リリース履歴：1.29.0から1.31.8までの変更点 CHANGESから主な変更を抜き出しました。日付はCHANGESの記載どおりです。 ### 1.31系mainlineのリリース日と変更点（2026年5月〜） | 版 | 公開日 | 主な変更 | | ------ | ---------- | -------------------------------------------- | | 1.31.8 | 2026-10-21 | working\_directoryがprefix基準に、HTTP/3のSIGBUS修正 | | 1.31.7 | 2026-10-14 | CVE 5件、geoipのMMDB対応、HTTP/2の優先度をRFC 9218へ | | 1.31.6 | 2026-09-15 | CVE-2026-90439（HTTP/3・OpenSSL 3.5.0以前） | | 1.31.5 | 2026-09-02 | control API、predicate location、json module | | 1.31.4 | 2026-08-19 | stream・mailのPROXY protocol v2送信 | | 1.31.3 | 2026-07-15 | CVE 3件、xsltの外部実体を既定で無効化 | | 1.31.2 | 2026-06-17 | CVE 3件、$request\_idがSipHash-2-4に | | 1.31.1 | 2026-05-22 | CVE-2026-9256 | | 1.31.0 | 2026-05-13 | CVE 6件、tunnelモジュール、least\_timeのOSS化 | 1.31.8の`working_directory`の変更は、相対パスで書いた値の基準がカレントディレクトリからnginxのprefixへ変わるものです。コアダンプの出力先などを相対パスで指定している場合は、1.31.8へ上げる前に絶対パスへ書き直します。 ### 1.30系stableの修正履歴とログ監視への影響（2026年4月〜） 1.30.0（4月14日）は1.29.8までの変更を引き継いだ版です。その後は1.30.1（5月13日・6件）、1.30.2（5月22日・1件）、1.30.3（6月17日・2件）、1.30.4（7月15日・3件）、1.30.5（9月15日・1件）、1.30.6（10月14日・5件）と、脆弱性修正を中心に不具合修正も取り込まれています。1.30.6では、SSLの「invalid alert」「record layer failure」などのログレベルがcritからinfoへ下がりました。critのログ件数で監視している場合、更新後に件数が減っても異常ではありません。1.30.3〜1.30.6で直った脆弱性のスコアの読み方は[nginx 脆弱性：1.30.3〜1.30.6で直ったCVSS v4.0 9.2の読み方と更新先](/tech/details/12647/)で扱っています。 ### 1.29系（2025年6月〜2026年4月）：1.30安定版の中身 1.29系は1.30系の元になった開発ブランチで、ここで入った機能はすべて1.30系でも使えます。最後の1.29.8の後は1.30.0へ引き継がれたため、1.29系の更新はもうありません。 | 版 | 公開日 | 主な変更 | | ------ | ---------- | ----------------------------------- | | 1.29.8 | 2026-04-07 | max\_headers、OpenSSL 4.0対応 | | 1.29.7 | 2026-03-24 | CVE 6件、MPTCP、proxyのkeepaliveを既定化 | | 1.29.6 | 2026-03-10 | stickyディレクティブ（セッション維持） | | 1.29.5 | 2026-02-04 | CVE-2026-1642（SSLバックエンドからの応答への平文注入） | | 1.29.4 | 2025-12-09 | proxyのHTTP/2バックエンド対応、ECH | | 1.29.3 | 2025-10-28 | add\_header\_inherit、$request\_port | | 1.29.2 | 2025-10-07 | AWS-LCでのビルド | | 1.29.1 | 2025-08-13 | CVE-2025-53859、TLS 1.3証明書圧縮を既定で無効 | | 1.29.0 | 2025-06-24 | 103 Early Hints（early\_hints） | ## 1.29.7で変わったproxy\_http\_versionとkeepaliveの既定値 HTTPリバースプロキシとして1.28系から1.30系へ上げる場合は、1.29.7で入った2つの既定値の変更を確認してください。 - `proxy_http_version`の既定が1.0から1.1に変わり、バックエンドへ`Connection`ヘッダーを既定では送らなくなった - upstreamブロックの`keepalive`が既定で有効になった。ドキュメント上の既定は`keepalive 32 local;`で、`local`は接続をlocationをまたいで共有しない指定 1.28系までは、バックエンドとの接続を再利用するために次の3行を書くのが定番でした。1.29.7以降はupstreamブロックにkeepaliveを書かなくても接続がキャッシュされ、`proxy_http_version`と`Connection`ヘッダーの2行は書かなくても同じ動きになります。 ``` upstream app { server 10.0.0.11:8080; keepalive 32; # 1.28系まで必須、1.29.7以降は既定で有効 } location / { proxy_pass http://app; proxy_http_version 1.1; # 1.29.7以降は既定値 proxy_set_header Connection ""; # 1.29.7以降は既定で送らない } ``` 1.31.6でproxy関連の指定を一切書かずに`proxy_pass`だけを置き、バックエンド側で受け取ったリクエストを表示させると、リクエスト行は`GET /hello HTTP/1.1`で、`Connection`ヘッダーはありませんでした。 注意が要るのは、HTTP/1.0でしか正しく動かない古いバックエンドと、接続ごとに状態を持つバックエンドです。前者は`proxy_http_version 1.0;`を明示し、旧来の接続終了動作も必要なら`proxy_set_header Connection "close";`を併記します。後者は、locationごとに接続を分けたい場合は既定の`local`のまま、まとめて共有したい場合は`keepalive 32;`のように`local`を付けずに書きます。 ## 1.29〜1.31で追加された主な機能 ### Multipath TCP：listenのmultipathパラメータ（1.29.7） `listen`に`multipath`を付けると、待ち受けソケットがMultipath TCP（`IPPROTO_MPTCP`）になります。ドキュメントは動作環境をLinux 5.6以降に限定し、このパラメータを付け外しすると`SO_REUSEPORT`も有効になると注記しています。 ``` # 証明書と秘密鍵を設定済みのserverブロック内に記述 listen 443 ssl multipath; # Linuxでカーネル側のMPTCPが有効か確認（1なら有効） sysctl net.mptcp.enabled ``` 効果が出るのは、クライアントもMPTCPに対応し、Wi-Fiとモバイル回線のように複数の経路を同時に持つ場合です。対応していないクライアントは通常のTCPとして扱われます。 ### stickyディレクティブ：Cookieでのセッション維持（1.29.6） 同じクライアントを同じバックエンドへ振り分ける`sticky`は、長く商用版NGINX Plusだけの機能でした。オープンソース版のCHANGESに入ったのは1.29.6で、`cookie`・`route`・`learn`の3方式が使えます。 ``` upstream backend { server backend1.example.com; server backend2.example.com; sticky cookie srv_id expires=1h domain=.example.com path=/; } ``` `ip_hash`はIPアドレスで振り分けるため、多くの利用者が同じIPアドレスを共有する社内ネットワークやモバイル回線では1台に偏ります。Cookie方式ではこの偏りが起きません。 ### predicate locationとjson module：1.31.5の新機能 1.31.5で、変数の値でlocationを選ぶpredicate locationが入りました。`$`で始まる変数を書き、値が空でも`0`でもなければ一致します。同じ版で、JSONから値を取り出して変数にする`ngx_http_json_module`と、ヘッダー受信の直後にリクエストボディを読む`client_body_early_read`も追加されました。json moduleは既定ではビルドされないため、`--with-http_json_module`が必要です。 ``` map $http_x_beta $is_beta { default 0; "on" 1; } json_set $user_name $arg_data user.name; server { location $is_beta { proxy_set_header X-Route beta; proxy_pass http://app; } location /json { proxy_set_header X-User $user_name; proxy_pass http://app; } } ``` 1.31.6で試すと、`X-Beta: on`を付けたリクエストだけがpredicate locationに入りました。`json_set`には落とし穴があります。`?data={...}`のようにJSONを生のまま渡せば`taro`が取れますが、URLエンコードした`%7B%22user...`を渡すと値は空でした。`$arg_`変数はデコードされないためで、ブラウザやHTTPクライアントがエンコードしたクエリでは動きません。JSONを受けるならリクエストボディ（`$request_body`と`client_body_early_read`）を使う方法があります。その場合も、本文が一時ファイルに退避されると変数から取得できないため、受け付けるJSONの上限に合わせて`client_max_body_size`と`client_body_buffer_size`を設定します。 このほか1.31.0では応答時間の短いサーバーを選ぶ`least_time`がオープンソース版に入り、1.31.7ではgeoipモジュールがMaxMind DB（MMDB）形式のデータベースを読めるようになりました（ビルドにはlibmaxminddbが必要）。 ## 2026年に修正された脆弱性と修正版の対応表 2026年に公表された脆弱性を、修正版の組ごとにまとめました。severityはnginx.orgの区分（low／medium／major）で、CVSSとは別の尺度です。 | 公開日 | 修正版（mainline／stable） | CVE | severity | | ---------- | -------------------- | ----------------------------------- | --------------------- | | 2026-02-04 | 1.29.5／1.28.2 | CVE-2026-1642 | medium | | 2026-03-24 | 1.29.7／1.28.3 | 27654・27784・32647・27651・28753・28755 | medium（27651のみlow） | | 2026-05-13 | 1.31.0／1.30.1 | 42926・42945・42946・42934・40460・40701 | medium（42934のみlow） | | 2026-05-22 | 1.31.1／1.30.2 | CVE-2026-9256 | medium | | 2026-06-17 | 1.31.2／1.30.3 | 42530・42055・48142 | 42530はmajor、48142はlow | | 2026-07-15 | 1.31.3／1.30.4 | 42533・60005・56434 | 42533はmajor、他はmedium | | 2026-09-15 | 1.31.6／1.30.5 | CVE-2026-90439 | medium | | 2026-10-14 | 1.31.7／1.30.6 | 15176・93479・95101・97629・97205 | medium | 表のCVE番号は、一部の行で接頭辞のCVE-2026-を省略しています。10月14日の5件は、aliasとrewriteを組み合わせたときのバッファオーバーフロー（15176）、変数を含む文字列式の評価でのバッファオーバーフロー（93479）、HTTP/3で未知のフレームがリクエストボディとして扱われ`client_max_body_size`を迂回される問題（95101）、TLSセッションチケット鍵のローテーションで鍵の1つが未初期化のまま残る問題（97629）、AIOとSSIの組み合わせでのuse-after-free（97205）です。95101と97629はHTTP/3やチケット鍵のローテーションを使っていなければ対象外ですが、15176は`alias`と`rewrite`という一般的な組み合わせで起きるため、構成を問わず1.31.7／1.30.6以降へ上げてください。 CVE-2026-42530（HTTP/3のuse-after-free）は1.31.0と1.31.1だけが対象で、stableには影響しません。1.30.1の9日後に同じrewriteモジュールで再発したCVE-2026-9256の経緯は[nginxで再発した脆弱性CVE-2026-9256](/tech/details/12251/)で解説しています。 ## nginxを最新版へ更新する手順 ### nginx.org公式リポジトリのmainline・stable設定 ディストリの標準パッケージから最新版へ移るには、nginx.orgのパッケージリポジトリを追加します。Ubuntuの場合、署名鍵を`/usr/share/keyrings/nginx-archive-keyring.gpg`に置いたうえで、stableなら`packages/ubuntu`、mainlineなら`packages/mainline/ubuntu`をリポジトリに指定します。 ``` # mainlineを使う場合（stableはURLから mainline/ を外す） echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \ https://nginx.org/packages/mainline/ubuntu `lsb_release -cs` nginx" \ | sudo tee /etc/apt/sources.list.d/nginx.list # ディストリのパッケージよりnginx.orgのものを優先する echo -e "Package: *\nPin: origin nginx.org\nPin: release o=nginx\nPin-Priority: 900\n" \ | sudo tee /etc/apt/preferences.d/99nginx sudo apt update sudo apt install nginx ``` RHEL系では`/etc/yum.repos.d/nginx.repo`に`nginx-stable`と`nginx-mainline`の2つを定義し、既定はstableです。mainlineを使うときは`sudo yum-config-manager --enable nginx-mainline`で切り替えます。2026年10月24日時点の[対応OS](https://nginx.org/en/linux%5Fpackages.html)は、RHEL 8〜10、Debian 12・13、Ubuntu 22.04・24.04・26.04、SLES 15 SP6以降と16、Alpine 3.21〜3.24、Amazon Linux 2023で、Debian 11は一覧から外れています。 パッケージを入れ替えると、設定ファイルの配置が変わります（nginx.org版は`sites-enabled`を使わず`/etc/nginx/conf.d/`を読み込む）。既存の設定をそのまま読ませたいときは、`nginx.conf`の`include`行を確認してから再起動します。 ### nginx更新前後の構文検証と確認項目 - **設定の構文**：新しいバイナリで`nginx -t`を通す。mainlineの1.31.0以降は、HTTP/2・HTTP/3で`Connection`や`Upgrade`などのヘッダーを含むリクエストを拒否するので、該当する経路はエラーログで確かめる - **切り替わりの確認**：再起動かUSR2での入れ替えのあと、Serverヘッダーか`/proc//exe`で新しい版が動いていることを見る。`nginx -v`だけでは確認にならない - **既定値の変化**：1.28系以前から上げる場合は、1.29.7のkeepaliveとHTTP/1.1化の影響をバックエンド側の接続数で確認する nginxの更新を含むサーバー基盤の設計や運用体制づくりは、弊社の[インフラ構築（AWS・Google Cloud・Azure）](/service/system/aws/)でも支援しています。 ### USR2での無停止入れ替えと失敗する2つの条件 再起動せずにバイナリを替えるには、マスタープロセスへ`USR2`を送ります。古いマスターは、まず自身のpidファイルを`nginx.pid.oldbin`へ改名してから、新しいバイナリの起動を試みます。新しいマスターとワーカーが立ち上がったことを確かめたら、古いマスターへ`WINCH`を送って古いワーカーを止め、問題が無ければ`QUIT`で古いマスターを終了します。1.30.6から1.31.8への入れ替えを、この順で実行しました。 ``` $ kill -USR2 $(cat /run/nginx.pid) $ ps -e -o pid,ppid,args | grep "[n]ginx:" 8 1 nginx: master process /usr/sbin/nginx # 古いマスター 25 8 nginx: master process /usr/sbin/nginx # 新しいマスター（親が古いマスター） 26 25 nginx: worker process # 新しいワーカー（以下略） $ cat /run/nginx.pid /run/nginx.pid.oldbin 25 8 $ kill -WINCH $(cat /run/nginx.pid.oldbin) # 以後10回の応答がすべてServer: nginx/1.31.8に $ kill -QUIT $(cat /run/nginx.pid.oldbin) # 古いマスターを終了 ``` 新しい版で不具合が出たら、`QUIT`を送る前に古いマスターへ`HUP`を送ってワーカーを起こし直し、新しいマスターを止めれば戻せます。ただし、次の2つの条件ではUSR2が効きませんでした。 - **`daemon off;`でフォアグラウンド起動している**：Docker公式イメージのマスターは、USR2を受けても「the changing binary signal is ignored」とログに出して何もしなかった。ソース（`src/os/unix/ngx_process.c`）は、起動時から親プロセスが変わっていなければ、まだ古いバイナリが動いているとみなしてUSR2を無視する。デーモン化しない構成では、親プロセスが終了でもしないかぎり親は変わらない。`WINCH`もデーモン化したときだけ処理する作りなので、コンテナではイメージの版を替えて作り直す - **`nginx`とコマンド名だけで起動している**：`sudo nginx`のように相対名で起動すると、USR2で新しいバイナリを起動する段階で`execve() failed while executing new binary process "nginx" (2: No such file or directory)`になる。起動時と同じ名前で実行し直す仕組みで、PATHを探さないためだ。`/usr/sbin/nginx`と絶対パスで起動したプロセスでは成功した 危険なのは、USR2が失敗したことに気づかずに`WINCH`を送る場合です。起動に失敗すると`nginx.pid.oldbin`は`nginx.pid`へ戻されるため、相対名で起動したマスターで試した2秒後にはpidファイルは`nginx.pid`だけでした。そこへ古いマスターのPIDで`WINCH`を送ると唯一のワーカー群が止まり、以後のリクエストは応答待ちのまま返りませんでした。`WINCH`を送るのは、プロセス一覧で新しいマスターとワーカーを確かめ、エラーログに`execve() failed`や`emerg`が無いことを見てからです。切り替え後の応答を確認できるまでは、古いマスターへ`QUIT`を送りません。 Kubernetesでnginxを入口にしている場合は、本体の版とは別にIngressコントローラーの事情があります。コミュニティ版のingress-nginxは2026年3月に開発を終えているため、[NGINX Ingressとは？退役したingress-nginxとF5版の違い](/tech/details/15773/)も確認してください。nginxをリバースプロキシとして置く構成の基本は[リバースプロキシとは？仕組みと導入判断](/tech/details/13554/)で説明しています。 ## よくある質問 ### nginxの最新バージョンはいくつですか？ 2026年10月24日時点で、mainlineが1.31.8（10月21日）、stableが1.30.6（10月14日）です。新しい版はnginx.orgのダウンロードページとCHANGESで確認できます。Docker公式イメージでは`nginx:latest`がmainlineの1.31.8、`nginx:stable`が1.30.6を指しています。 ### nginxのバージョンを確認するコマンドは？ `nginx -v`で版、`nginx -V`でビルドオプションまで表示されます。出力は標準エラーなので、パイプで加工するときは`2>&1`を付けます。一般ユーザーで見つからない場合は`/usr/sbin/nginx -v`とフルパスで実行します。動いているサーバーの版は`curl -sI`のServerヘッダーで確かめます。 ### nginx 1.28や1.29のサポートはいつまでですか？ 1.28系は1.28.3（2026年3月24日）が最後で、1.30.0の公開後は修正版が出ていません。1.29系はmainlineの系列で、1.30.0（2026年4月14日）でstableへ引き継がれた時点で更新が止まりました。どちらも1.30.6へ上げれば、機能を失わずに修正を受けられます。 ### nginxのmainlineとstableはどちらを使うべきですか？ 新機能が必要ならmainline、新機能の導入に伴う変更を抑えたいならstableです。ただし、stableにも仕様変更は入るため、更新ごとに変更履歴の確認が必要です。脆弱性の修正版は両系列に同じ日に出ますが、影響範囲は同じとは限りません。CVE-2026-42530はmainlineの1.31.0と1.31.1だけが対象でした。どちらを選んでも、修正版が出たらすぐ入れ替えることが前提です。 ### 次の安定版nginx 1.32はいつリリースされますか？ 2026年10月時点で日程は公表されていません。参考として、1.24.0は2023年4月11日、1.26.0は2024年4月23日、1.28.0は2025年4月23日、1.30.0は2026年4月14日と、直近4回の安定版はいずれも4月に出ています。 ## 関連記事 - [nginx 脆弱性：1.30.3〜1.30.6で直ったCVSS v4.0 9.2の読み方と更新先](/tech/details/12647/) - [NGINX Rift（CVE-2026-42945）の影響判定とPoCの中身｜1.30.6までの対応](/tech/details/12209/) - [nginxで再発した脆弱性CVE-2026-9256：概要と影響範囲・2026年の修正経緯](/tech/details/12251/) - [NGINX Ingressとは？退役したingress-nginxとF5版の違い・移行判断](/tech/details/15773/) - [リバースプロキシとは？仕組み・フォワードプロキシとの違いと導入判断を実装目線で解説](/tech/details/13554/) --- 出典: [nginxの最新バージョンは1.31系（安定版1.30）｜バージョン確認コマンド・更新手順と変更点【2026年10月】]()（株式会社一創）