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とセキュリティアドバイザリで照合し、確認方法と更新手順は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は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、Debianの版はDebian Sourcesで確認できます。

末尾の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と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本も修正版が出ていません。過去の更新実績から、次の安定版の公開を移行計画の目安にできます。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の中身にまとめています。

リリース履歴：1.29.0から1.31.8までの変更点

CHANGESから主な変更を抜き出しました。日付はCHANGESの記載どおりです。

1.31系mainlineのリリース日と変更点（2026年5月〜）

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の読み方と更新先で扱っています。

1.29系（2025年6月〜2026年4月）：1.30安定版の中身

1.29系は1.30系の元になった開発ブランチで、ここで入った機能はすべて1.30系でも使えます。最後の1.29.8の後は1.30.0へ引き継がれたため、1.29系の更新はもうありません。

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とは別の尺度です。

表の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で解説しています。

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は、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/<PID>/exeで新しい版が動いていることを見る。nginx -vだけでは確認にならない
• 既定値の変化：1.28系以前から上げる場合は、1.29.7のkeepaliveとHTTP/1.1化の影響をバックエンド側の接続数で確認する

nginxの更新を含むサーバー基盤の設計や運用体制づくりは、弊社のインフラ構築（AWS・Google Cloud・Azure）でも支援しています。

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版の違いも確認してください。nginxをリバースプロキシとして置く構成の基本はリバースプロキシとは？仕組みと導入判断で説明しています。

よくある質問

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の読み方と更新先
• NGINX Rift（CVE-2026-42945）の影響判定とPoCの中身｜1.30.6までの対応
• nginxで再発した脆弱性CVE-2026-9256：概要と影響範囲・2026年の修正経緯
• NGINX Ingressとは？退役したingress-nginxとF5版の違い・移行判断
• リバースプロキシとは？仕組み・フォワードプロキシとの違いと導入判断を実装目線で解説