Question 1

設定ファイルが無効な場合に 'nginx -s stop' がサーバーを停止できないのはなぜですか？

Accepted Answer

nginxは'-s stop'の場合でも設定を検証するため、エラーがあると停止を拒否します。回避策として、systemctl stop nginx (systemd) を使用するか、nginxマスタープロセスに直接QUITシグナルを送信してください（例：kill -QUIT $(cat /var/run/nginx.pid)）。また、configファイルを一時的に修正して、正常に停止できるようにすることもできます。

Question 2

locationブロック内に設定したnginxのclient_max_body_sizeが適用されず、413エラーが発生するのはなぜですか?

Accepted Answer

nginx は、`index` ディレクティブが `/members/` を `/members/index.php` へ内部リダイレクトする前に、*元の* リクエスト URI にマッチした location に対して `client_max_body_size` をチェックします。そのため、`/members/login/` へのリクエストは `location ~* ^/members/.*\.php$` には決してマッチせず、サーバーレベルの値（例: 3k）にフォールバックし、正規表現 location が評価される前に 413 Request Entity Too Large を返します。修正方法: 代わりに、ネストされた正規表現 location を持つプレフィックス location を使用します。

```nginx
location /members/ {
    client_max_body_size 10m;
    location ~* \.php$ {
        fastcgi_param ...;
    }
}
```

プレフィックス location は元の URI `/members/...` にマッチするため、10m の制限が適用され、ネストされた正規表現が PHP の処理を担います。

Question 3

KTLS を使用した HTTP/2 で lingering_close 中に発生する nginx の 'recv() failed (5: Input/output error)' を修正する方法

Accepted Answer

このアラートは無害です（接続は正しく閉じられ、失敗したリクエストはありません）。原因は OpenSSL 3.2.0 以降での動作変更で、TLS 1.3 において kTLS 受信オフロードが有効になることに起因しています。lingering close の処理中、nginx は通常の `recv()` でソケットをドレインしますが、kTLS オフロードが有効な場合、カーネルはクライアントの TLS `close_notify` レコードを通常の `recv()` 経由で返すことができません。そのため、この呼び出しは 0 ではなく -1（EIO）を返し、nginx はそれを alert レベルでログに記録します。

回避策（パッチは不要です。いずれか一つを選んでください）：

1. nginx の設定で lingering close を無効にする：
```
http {
    lingering_close off;
}
```

2. または、次のディレクティブを削除して KTLS を無効にする：
```
ssl_conf_command Options KTLS;
```

発生条件：OpenSSL 3.2.0 以降でビルドされた nginx（OpenSSL 3.5.x/4.0.x および nginx 1.29〜1.31 でも依然として発生）、KTLS が有効、かつ `lingering_close on`（デフォルト）の場合です。HTTP/2 接続の終了処理のたびに発生します。例えば `nginx -s reload` の実行時や、`keepalive_requests` の上限に達したときなどです。HTTP/1.1 と HTTP/2 の両方の lingering close ハンドラーが影響を受けます。nginx がこの OpenSSL の変更にネイティブに対応するまでは、上記の回避策のいずれかを使用してログの大量出力を抑制してください。

Question 4

なぜカスタムNGINX streamモジュールは、SSLハンドシェイク成功後にハングするのですか？

Accepted Answer

標準の `ngx_stream_ssl_init_connection()` は、ハンドシェイクが成功すると `NGX_OK` を返しますが、これはストリームフェーズエンジンのループ (`ngx_stream_core_run_phases`) 内から呼び出されるため、ハンドシェイクハンドラは呼び出されません。フェーズエンジンは `NGX_OK` を受け取ると自動的に次のフェーズに進みます。カスタムモジュールがこのフェーズエンジンのコンテキスト外で SSL ハンドシェイクを開始する場合は、`ngx_stream_core_run_phases(s)` を呼び出すか、フェーズロジックを複製してハングを防ぐ必要があります。

Question 5

NGINXのsetディレクティブ内で$slice_rangeを使用すると、なぜproxy_cache_keyが静的になるのですか？

Accepted Answer

`set`ディレクティブは代入時に複雑な値を評価するため、メインリクエストでは`$cache_key`が静的になります。スライスモジュールのサブリクエストでは`$slice_range`が変化しますが、キャッシュされた値はそれを反映しません。回避策として、`proxy_cache_key`内で`$slice_range`を直接使用します。例: `proxy_cache_key "$uri:$slice_range";`。遅延評価には、パッチまたは（`map`のような）`volatile`パラメータが必要になる場合があります。

nginx

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト