---
title: "ngx_mruby v2.7.4"
language: "ja"
documentation_version: "3.x"
channel: "development"
release_context: null
source_revision: "4eb847421a8739964145196428abb52738637aa3"
working_tree_clean: true
source_path: "docs/releases/v2.7.4.ja.md"
source_sha256: "2386d4b9a2b6d0151e8efaabcaa2c3f12e2a95c7aa5dc9c714a99b741785e5b0"
source_at_revision: true
source_url: "https://github.com/matsumotory/ngx_mruby/blob/4eb847421a8739964145196428abb52738637aa3/docs/releases/v2.7.4.ja.md"
html_url: "https://ngx.mruby.org/ja/releases/v2.7.4/"
markdown_url: "https://ngx.mruby.org/markdown/ja/releases/v2.7.4.md"
last_updated: "2026-11-02"
---

# ngx_mruby v2.7.4

ngx_mruby 2.7.4は、2.x系列のメンテナンスリリースです。

streamモジュールのセキュリティ問題を、アドバイザリ[GHSA-xjh6-6vgm-56wj](https://github.com/matsumotory/ngx_mruby/security/advisories/GHSA-xjh6-6vgm-56wj)とともに修正しました。深刻度はModerateです。「更新前に確認する挙動の変更」の項目1と項目2です。

<a id="アップグレードの前に読む挙動の変更"></a>

## 更新前に確認する挙動の変更

### 1. Nginx::Stream::Connection.proxy_protocol_addrとproxy_protocol_ipは、PROXYの送信元のアドレスが無い接続でnilを返します

- 変更前：nginx 1.17.6以降では、`Nginx::Stream::Connection.proxy_protocol_addr`と`Nginx::Stream::Connection.proxy_protocol_ip`は、クラスメソッドでもインスタンスメソッドでも、PROXYプロトコルのヘッダーから得た送信元のアドレスが無い接続で値を返しませんでした。そのような接続は、`proxy_protocol`の無いlistenの接続と、バージョン1のヘッダー`PROXY UNKNOWN`か、コマンドが`LOCAL`のバージョン2のヘッダーを受けた接続です。
- 変更後：これらのメソッドは、そのような接続で`nil`を返します。アドレスを持つヘッダーの後では、これまでどおり送信元のアドレスを返します。
- 変更の理由：
  - 不具合：「変更前」に書いたとおり、これらのメソッドは、そのような接続で値を返しませんでした。アドバイザリ[GHSA-xjh6-6vgm-56wj](https://github.com/matsumotory/ngx_mruby/security/advisories/GHSA-xjh6-6vgm-56wj)が、不具合、影響を受けるバージョン、条件を説明しています。
  - 前の挙動を残せなかった理由：そのような接続には、返すアドレスがありません。`nil`を返すと、アドレスのある接続と区別できます。HTTPのコードでは、`Nginx::Var#proxy_protocol_addr`が同じ場合に`nil`を返します。
  - ドキュメントが示していた挙動：これらのメソッドには、ドキュメントがありませんでした。いまは[docs/class_and_method/README.md](/ja/reference/ruby/#nginxstreamconnectionproxy_protocol_addrproxy_protocol_ip)が説明しています。
- 影響の範囲：PROXYの送信元のアドレスが無い接続で、これらのメソッドを呼ぶ`mruby_stream`と`mruby_stream_code`のコードです。
- 必要な対応：結果をStringと比べるコードでは、対応は要りません。結果にStringのメソッドを呼ぶコードでは、`to_s`などで`nil`を扱ってください。

### 2. TCPのstreamのセッションのコードがsleepしている間、nginxはクライアントから何も読まず、worker_shutdown_timeoutでセッションが終わります

- 変更前：TCPのセッションのコードが`Nginx::Stream::Async.sleep`で待っている間、接続の読み込みのイベントは、コードが動く前と同じに扱われていました。`proxy_protocol`を付けたlistenでは、sleepの間にクライアントが送ったバイトでセッションが終わることがあり、アクセスログのステータスは400でした。sleepの間に`worker_shutdown_timeout`が過ぎても、セッションはそのときに終わりませんでした。
- 変更後：コードがsleepしている間、nginxはクライアントから何も読みません。その間にクライアントが送ったバイトは、コードの後のフェーズのために残ります。`proxy_pass`は、そのバイトをupstreamへ送ります。sleepの間にクライアントが接続を閉じると、`proxy_protocol`の無いlistenと同じく、コードの後のフェーズがそれを検出します。sleepの間に`worker_shutdown_timeout`が過ぎると、セッションは終わり、コードはもう一度動きません。
- 変更の理由：
  - 不具合：「変更前」に書いたとおり、sleepの間の読み込みのイベントが、コードが動く前と同じに扱われていました。アドバイザリ[GHSA-xjh6-6vgm-56wj](https://github.com/matsumotory/ngx_mruby/security/advisories/GHSA-xjh6-6vgm-56wj)が、不具合、影響を受けるバージョン、条件を説明しています。
  - 前の挙動を残せなかった理由：ヘッダーの後のバイトは、後のフェーズが運ぶプロトコルのものです。`worker_shutdown_timeout`で終わらないセッションは、ディレクティブが決めた時間を過ぎても古いワーカープロセスを残します。
  - ドキュメントが示していた挙動：[docs/class_and_method/README.md](/ja/reference/ruby/#nginxstreamasync-class)は、sleepの間の読み込みについて何も書いていませんでした。nginxの[`worker_shutdown_timeout`](https://nginx.org/en/docs/ngx_core_module.html#worker_shutdown_timeout)のドキュメントは、タイムアウトが過ぎるとnginxが開いている接続を閉じようとすると書いています。
- 影響の範囲：TCPのlistenで、`mruby_stream`か`mruby_stream_code`のコードが`Nginx::Stream::Async.sleep`を呼ぶstreamのサーバーです。`proxy_protocol`を付けたlistenでsleepの間にバイトを送るか接続を閉じるクライアントと、コードがsleepしている間に`worker_shutdown_timeout`を付けて終わるワーカーが影響を受けます。ワーカーが終わるのは、リロード、アップグレード、停止のときです。
- 必要な対応：ありません。コードがsleepしないセッションと同じく、コードの後のフェーズがクライアントのバイトを受け取ります。
- このリリースで変わらない挙動：UDPのセッションです。sleepの間にクライアントから届くデータグラムは、2.7.3と同じく、1つごとにコードをもう一度動かします。`worker_shutdown_timeout`は、コードがsleepしているUDPのセッションを終わらせません。

## 新機能

ありません。

## 不具合の修正

ありません。

## ビルドとテストの変更

- テスト：`test/t/cases/stream_proxy_protocol_wait.rb`と`test/conf/conf.d/stream/48-proxy-protocol-wait.conf`を加えました。ポートは12384です。`test/t/cases/_second_instance.rb`には、マスタープロセスと1つのワーカープロセスを持つ2つ目のnginxを起動するモード`stream_master`を加えました。ポートは12385から12388です。`test/t/cases/_tcp_client.rb`は、最初のペイロードの0.3秒後に2つ目のペイロードを書けます。
- CI：コードかテストを変えるreadyのプルリクエストは、`test.yml`の`build`のマトリクスのうち、4つのセルを流し、全部のセルは流しません。全部のセルは、nginxのバージョン、リンクの形、`--with-openssl-src`の有無の16の組み合わせと、sanitizerのセルです。4つのセルは、`--with-openssl-src`を付けたnginx 1.31.8の静的モジュール、nginx 1.30.6の動的モジュール、sanitizerのセル、valgrindの下のセルです。sanitizerのセルとvalgrindの下のセルは、nginx 1.31.8の静的モジュールをビルドします。sanitizerのセルは、AddressSanitizerとUndefinedBehaviorSanitizerを付けてビルドします。全部のセルを流すのは、valgrindの下の夜間の実行、タグのpush、新しいラベル`full-matrix`を付けたプルリクエスト、入力`base`を付けないか入力`valgrind`を付けた「Run workflow」です。タグの前の点検のプルリクエストは、このラベルを付けます。`v*.x`のブランチへのpushは、`master`と`next`へのpushと同じく、ビルドを流しません。`test/ci/changes.sh`は、`next`と再び同じスクリプトになり、実行の種類をオプション(`--label`、`--draft`、`--push`、`--tag`、`--dispatch`、`--valgrind`)で受け取り、`build`を`standard`、`full`、`none`のどれかで出します。説明は、[docs/test/README.md](/ja/contributing/test/)の「Which jobs a run starts」にあります(#704)。

## アップグレード

- 追加、改名、削除したディレクティブはありません。このリリースで、モジュールをビルドし直してください。2.7.3をビルドしたときと同じ方法でビルドし、いつもどおりnginxのバイナリか動的モジュールを置き換えてください。

アップグレードの前に、次の点を確かめてください。各行は、上の各項目に書いた「必要な対応」です。

- `Nginx::Stream::Connection.proxy_protocol_addr`と`proxy_protocol_ip`：結果をStringと比べるコードでは、対応は要りません。結果にStringのメソッドを呼ぶコードでは、`to_s`などで`nil`を扱ってください（項目1）。
- `Nginx::Stream::Async.sleep`の間のTCPのstreamのセッションの読み込み：対応は要りません（項目2）。
