Nginx リクエスト処理の舞台裏:フェーズ/ハンドラ/モジュール連携を図解で理解

Nginx がなぜ高性能な Web サーバーとして世界中で愛用されているのかをご存知でしょうか。その秘密は、リクエスト処理における精巧な設計にあります。しかし、この内部動作を理解することは簡単ではありません。
今回は、Nginx のリクエスト処理の仕組みを、フェーズ、ハンドラ、モジュールの連携という視点から図解で分かりやすく解説いたします。読み終わった頃には、Nginx の内部動作が手に取るように理解できるでしょう。
背景
Nginx アーキテクチャの基本概念
Nginx は単なる Web サーバーではありません。高度に設計されたアーキテクチャによって、同時接続数万という大規模な負荷にも耐えられる仕組みを持っています。
まず、Nginx の基本的なアーキテクチャを理解しましょう。以下の図が全体の構造を示しています。
mermaidflowchart TD
master[Master Process]
worker1[Worker Process 1]
worker2[Worker Process 2]
worker3[Worker Process N]
master -->|fork| worker1
master -->|fork| worker2
master -->|fork| worker3
client1[Client 1] -->|HTTP Request| worker1
client2[Client 2] -->|HTTP Request| worker2
client3[Client N] -->|HTTP Request| worker3
worker1 -->|HTTP Response| client1
worker2 -->|HTTP Response| client2
worker3 -->|HTTP Response| client3
Master Process は設定の読み込みや Worker Process の管理を担当し、実際のリクエスト処理は Worker Process が行います。
イベント駆動型処理モデルとマルチプロセス構造
Nginx の真の強さは、イベント駆動型処理モデルにあります。従来の Web サーバーは 1 つのリクエストに対して 1 つのスレッドを割り当てる方式でしたが、Nginx は異なるアプローチを採用しています。
イベント駆動型の仕組み
各 Worker Process は数千のコネクションを同時に処理できます。これは、スレッドをブロックさせることなく、イベントループで効率的に処理しているからです。
mermaidsequenceDiagram
participant Client
participant EventLoop
participant Handler
participant Backend
Client->>EventLoop: HTTP Request
EventLoop->>Handler: Process Request
Handler->>Backend: Async Call
Backend-->>Handler: Response (Non-blocking)
Handler->>EventLoop: Response Ready
EventLoop->>Client: HTTP Response
このイベント駆動モデルにより、メモリ使用量を大幅に削減しながら高い処理能力を実現しています。
モジュラー設計の思想
Nginx の設計で特に注目すべきは、モジュラーアーキテクチャです。機能を小さなモジュールに分割することで、柔軟性と拡張性を実現しています。
モジュールの分類
Nginx のモジュールは以下の 3 つに大きく分類されます。
分類 | 役割 | 例 |
---|---|---|
コアモジュール | 基本機能提供 | ngx_core_module |
HTTP モジュール | HTTP 処理 | ngx_http_core_module |
3rd パーティモジュール | 拡張機能 | ngx_http_auth_module |
各モジュールは独立して動作し、必要に応じて組み合わせることができます。
課題
リクエスト処理フローの複雑さ
Nginx のリクエスト処理は非常に複雑です。単純に HTTP リクエストを受け取ってレスポンスを返すだけでなく、多段階の処理フェーズを経て最終的な結果を生成します。
処理フェーズの多様性
Nginx は 11 個の主要な処理フェーズを持っています。各フェーズで異なる種類の処理が実行され、前のフェーズの結果が次のフェーズに影響することがあります。
mermaidflowchart LR
req[HTTP Request] --> phase1[POST_READ]
phase1 --> phase2[SERVER_REWRITE]
phase2 --> phase3[FIND_CONFIG]
phase3 --> phase4[REWRITE]
phase4 --> phase5[POST_REWRITE]
phase5 --> phase6[PREACCESS]
phase6 --> phase7[ACCESS]
phase7 --> phase8[POST_ACCESS]
phase8 --> phase9[PRECONTENT]
phase9 --> phase10[CONTENT]
phase10 --> phase11[LOG]
phase11 --> res[HTTP Response]
この複雑なフローを理解しないと、期待通りの動作をしないモジュールを作成してしまう可能性があります。
フェーズとハンドラの連携が見えにくい
Nginx の処理において、フェーズとハンドラの関係性を理解することは重要ですが、これが見えにくいという課題があります。
ハンドラ登録の複雑さ
各フェーズには複数のハンドラが登録される可能性があり、それらの実行順序や相互作用を把握することは困難です。
mermaidstateDiagram-v2
[*] --> PostRead: Request arrives
PostRead --> ServerRewrite: Module handlers execute
ServerRewrite --> FindConfig: Config selection
FindConfig --> Rewrite: URL rewriting
Rewrite --> PostRewrite: Check loops
PostRewrite --> PreAccess: Prepare access check
PreAccess --> Access: Authentication
Access --> PostAccess: Authorization
PostAccess --> PreContent: Content preparation
PreContent --> Content: Generate response
Content --> Log: Logging
Log --> [*]: Response sent
各状態でどのハンドラが動作するかを理解することが、効果的なモジュール開発の鍵となります。
モジュール間の依存関係の理解困難
複数のモジュールが相互に作用する場合、その依存関係を理解することは非常に困難です。特に、モジュールの読み込み順序や初期化順序が結果に影響することがあります。
モジュール初期化の順序問題
c// モジュール依存関係の例
static ngx_command_t ngx_http_custom_commands[] = {
{
ngx_string("custom_directive"),
NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1,
ngx_http_custom_handler,
0,
0,
NULL
},
ngx_null_command
};
このような依存関係を適切に管理しないと、予期しない動作や設定エラーが発生する可能性があります。
解決策
フェーズベースの処理順序の可視化
Nginx のリクエスト処理を理解するためには、まずフェーズベースの処理順序を正確に把握することが重要です。各フェーズの役割と実行タイミングを明確にしましょう。
11 個の処理フェーズの詳細
以下は、Nginx の各処理フェーズとその目的を詳しく説明した図です。
mermaidflowchart TD
start[HTTP Request] --> phase1[NGX_HTTP_POST_READ_PHASE]
phase1 --> phase2[NGX_HTTP_SERVER_REWRITE_PHASE]
phase2 --> phase3[NGX_HTTP_FIND_CONFIG_PHASE]
phase3 --> phase4[NGX_HTTP_REWRITE_PHASE]
phase4 --> phase5[NGX_HTTP_POST_REWRITE_PHASE]
phase5 --> phase6[NGX_HTTP_PREACCESS_PHASE]
phase6 --> phase7[NGX_HTTP_ACCESS_PHASE]
phase7 --> phase8[NGX_HTTP_POST_ACCESS_PHASE]
phase8 --> phase9[NGX_HTTP_PRECONTENT_PHASE]
phase9 --> phase10[NGX_HTTP_CONTENT_PHASE]
phase10 --> phase11[NGX_HTTP_LOG_PHASE]
phase11 --> httpResponse[HTTP Response]
phase1 -.->|"リクエストヘッダー解析"| desc1[Header processing]
phase2 -.->|"サーバーレベル書き換え"| desc2[Server rewrite]
phase3 -.->|"設定検索"| desc3[Config lookup]
phase4 -.->|"ロケーション書き換え"| desc4[Location rewrite]
phase5 -.->|"書き換え後処理"| desc5[Post rewrite check]
phase6 -.->|"アクセス制御準備"| desc6[Pre-access check]
phase7 -.->|"アクセス制御実行"| desc7[Access control]
phase8 -.->|"アクセス後処理"| desc8[Post access]
phase9 -.->|"コンテンツ準備"| desc9[Content preparation]
phase10 -.->|"コンテンツ生成"| desc10[Content generation]
phase11 -.->|"ログ出力"| desc11[Logging]
各フェーズでは特定の処理が実行され、次のフェーズに処理が移行します。この順序を理解することで、どのタイミングでどのような処理が行われるかが明確になります。
フェーズごとの主要な処理内容
フェーズ | 主な処理内容 | 実行されるモジュール例 |
---|---|---|
POST_READ | リクエストヘッダーの読み込み | ngx_http_realip_module |
SERVER_REWRITE | サーバーコンテキストでの URL 書き換え | ngx_http_rewrite_module |
FIND_CONFIG | 適切な location 設定の検索 | Core HTTP |
REWRITE | location コンテキストでの URL 書き換え | ngx_http_rewrite_module |
POST_REWRITE | 書き換え結果の検証とループ検出 | Core HTTP |
PREACCESS | アクセス制御の準備 | ngx_http_limit_req_module |
ACCESS | 認証・認可の実行 | ngx_http_auth_basic_module |
POST_ACCESS | アクセス制御結果の処理 | Core HTTP |
PRECONTENT | コンテンツ処理の準備 | ngx_http_try_files_module |
CONTENT | レスポンスコンテンツの生成 | ngx_http_static_module |
LOG | アクセスログの記録 | ngx_http_log_module |
ハンドラとモジュールの役割分担図解
次に、ハンドラとモジュールがどのように連携して動作するかを視覚的に理解しましょう。
ハンドラとモジュールの関係性
mermaidclassDiagram
class NginxCore {
+request_handler()
+phase_handler()
+module_manager()
}
class HttpModule {
+init_module()
+register_handlers()
+process_request()
}
class ContentHandler {
+generate_response()
+handle_static_files()
+proxy_upstream()
}
class AccessHandler {
+authenticate_user()
+check_permissions()
+rate_limiting()
}
class RewriteHandler {
+parse_rules()
+rewrite_uri()
+redirect_request()
}
NginxCore --> HttpModule : manages
HttpModule --> ContentHandler : registers
HttpModule --> AccessHandler : registers
HttpModule --> RewriteHandler : registers
ContentHandler --|> HttpModule : implements
AccessHandler --|> HttpModule : implements
RewriteHandler --|> HttpModule : implements
各ハンドラは特定の責任を持ち、モジュールを通じて登録されます。この構造により、機能の分離と拡張性が実現されています。
ハンドラの実行チェーン
実際のリクエスト処理では、複数のハンドラが順次実行されます。以下の図は、この実行チェーンを示しています。
mermaidsequenceDiagram
participant Request
participant Phase_Handler
participant Module_A
participant Module_B
participant Module_C
participant Response
Request->>Phase_Handler: HTTP Request
Phase_Handler->>Module_A: Execute handler
Module_A->>Module_A: Process request
Module_A-->>Phase_Handler: NGX_OK
Phase_Handler->>Module_B: Execute handler
Module_B->>Module_B: Process request
Module_B-->>Phase_Handler: NGX_DECLINED
Phase_Handler->>Module_C: Execute handler
Module_C->>Module_C: Generate response
Module_C-->>Phase_Handler: NGX_OK
Phase_Handler->>Response: HTTP Response
各ハンドラは NGX_OK
、NGX_DECLINED
、NGX_ERROR
などの戻り値を返し、次のハンドラの実行を制御します。
実際のリクエストフローのトレース方法
Nginx の内部動作を理解するためには、実際のリクエストフローをトレースする方法を知ることが重要です。
デバッグログの活用
Nginx には詳細なデバッグログ機能があります。以下の設定でログレベルを調整できます。
nginx# Nginxデバッグ設定例
error_log /var/log/nginx/debug.log debug;
http {
# HTTPモジュールのデバッグログを有効化
access_log /var/log/nginx/access.log combined;
server {
listen 80;
server_name example.com;
# 特定のlocationでのデバッグ
location /api/ {
error_log /var/log/nginx/api_debug.log debug;
proxy_pass http://backend;
}
}
}
このデバッグログにより、各フェーズでの処理状況を詳細に確認できます。
トレーシングツールの利用
より高度なトレーシングには、以下のようなツールが利用できます。
bash# strace を使用したシステムコール追跡
strace -p $(pgrep nginx | head -1) 2>&1 | grep -E "(accept|read|write)"
# ngx_http_debug_module を使用した詳細ログ
curl -H "X-Debug: 1" http://localhost/test
これらのツールを組み合わせることで、リクエスト処理の全体像を把握できるようになります。
具体例
NGX_HTTP_POST_READ_PHASE から NGX_HTTP_LOG_PHASE までの実装
実際の Nginx モジュール開発において、各フェーズでの処理実装方法を具体的に見ていきましょう。以下は、カスタムヘッダー処理モジュールの実装例です。
モジュール構造の定義
最初に、モジュールの基本構造を定義します。
c#include <ngx_config.h>
#include <ngx_core.h>
#include <ngx_http.h>
// モジュール設定構造体
typedef struct {
ngx_str_t custom_header;
ngx_flag_t enable_logging;
} ngx_http_custom_conf_t;
// 関数プロトタイプ宣言
static ngx_int_t ngx_http_custom_init(ngx_conf_t *cf);
static void *ngx_http_custom_create_conf(ngx_conf_t *cf);
static char *ngx_http_custom_merge_conf(ngx_conf_t *cf, void *parent, void *child);
POST_READ_PHASE でのヘッダー処理
POST_READ_PHASE では、リクエストヘッダーの初期処理を行います。
c// POST_READ_PHASEハンドラ
static ngx_int_t
ngx_http_custom_post_read_handler(ngx_http_request_t *r)
{
ngx_http_custom_conf_t *conf;
ngx_str_t value;
conf = ngx_http_get_module_loc_conf(r, ngx_http_custom_module);
if (conf == NULL) {
return NGX_DECLINED;
}
// カスタムヘッダーの存在確認
if (ngx_http_arg(r, (u_char *) "custom", 6, &value) == NGX_OK) {
ngx_log_debug1(NGX_LOG_DEBUG_HTTP, r->connection->log, 0,
"custom header found: \"%V\"", &value);
// リクエストコンテキストに値を保存
ngx_http_set_ctx(r, &value, ngx_http_custom_module);
}
return NGX_DECLINED;
}
このハンドラは、カスタムヘッダーを検出し、後続のフェーズで使用するためにコンテキストに保存します。
ACCESS_PHASE での認証処理
ACCESS_PHASE では、リクエストの認証・認可を行います。
c// ACCESS_PHASEハンドラ
static ngx_int_t
ngx_http_custom_access_handler(ngx_http_request_t *r)
{
ngx_http_custom_conf_t *conf;
ngx_str_t *custom_value;
conf = ngx_http_get_module_loc_conf(r, ngx_http_custom_module);
custom_value = ngx_http_get_module_ctx(r, ngx_http_custom_module);
if (custom_value == NULL) {
ngx_log_error(NGX_LOG_ERR, r->connection->log, 0,
"custom header not found, access denied");
return NGX_HTTP_FORBIDDEN;
}
// カスタム認証ロジック
if (custom_value->len > 0 &&
ngx_strncmp(custom_value->data, "authorized", 10) == 0) {
return NGX_DECLINED; // 認証成功、次のハンドラへ
}
return NGX_HTTP_UNAUTHORIZED;
}
CONTENT_PHASE でのレスポンス生成
CONTENT_PHASE では、実際のレスポンスコンテンツを生成します。
c// CONTENT_PHASEハンドラ
static ngx_int_t
ngx_http_custom_content_handler(ngx_http_request_t *r)
{
ngx_buf_t *b;
ngx_chain_t out;
ngx_str_t *custom_value;
u_char *response_data;
size_t response_len;
custom_value = ngx_http_get_module_ctx(r, ngx_http_custom_module);
// レスポンスヘッダーの設定
r->headers_out.status = NGX_HTTP_OK;
r->headers_out.content_type_len = sizeof("application/json") - 1;
r->headers_out.content_type.data = (u_char *) "application/json";
// レスポンスボディの作成
response_len = sizeof("{\"status\":\"success\",\"custom\":\"\"}") +
(custom_value ? custom_value->len : 0);
b = ngx_pcalloc(r->pool, sizeof(ngx_buf_t));
if (b == NULL) {
return NGX_HTTP_INTERNAL_SERVER_ERROR;
}
response_data = ngx_pnalloc(r->pool, response_len);
if (response_data == NULL) {
return NGX_HTTP_INTERNAL_SERVER_ERROR;
}
if (custom_value) {
ngx_snprintf(response_data, response_len,
"{\"status\":\"success\",\"custom\":\"%V\"}", custom_value);
} else {
ngx_snprintf(response_data, response_len,
"{\"status\":\"success\",\"custom\":\"\"}");
}
// バッファ設定
b->pos = response_data;
b->last = response_data + ngx_strlen(response_data);
b->memory = 1;
b->last_buf = 1;
out.buf = b;
out.next = NULL;
r->headers_out.content_length_n = b->last - b->pos;
ngx_http_send_header(r);
return ngx_http_output_filter(r, &out);
}
コアモジュールと HTTP モジュールの連携実例
次に、コアモジュールと HTTP モジュールがどのように連携するかを実際のコードで確認しましょう。
モジュール登録とフェーズハンドラの設定
c// モジュール初期化関数
static ngx_int_t
ngx_http_custom_init(ngx_conf_t *cf)
{
ngx_http_handler_pt *h;
ngx_http_core_main_conf_t *cmcf;
cmcf = ngx_http_conf_get_module_main_conf(cf, ngx_http_core_module);
// POST_READ_PHASEハンドラの登録
h = ngx_array_push(&cmcf->phases[NGX_HTTP_POST_READ_PHASE].handlers);
if (h == NULL) {
return NGX_ERROR;
}
*h = ngx_http_custom_post_read_handler;
// ACCESS_PHASEハンドラの登録
h = ngx_array_push(&cmcf->phases[NGX_HTTP_ACCESS_PHASE].handlers);
if (h == NULL) {
return NGX_ERROR;
}
*h = ngx_http_custom_access_handler;
return NGX_OK;
}
設定コマンドの定義
モジュールの設定ディレクティブを定義します。
c// 設定コマンド配列
static ngx_command_t ngx_http_custom_commands[] = {
{
ngx_string("custom_header"),
NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1,
ngx_conf_set_str_slot,
NGX_HTTP_LOC_CONF_OFFSET,
offsetof(ngx_http_custom_conf_t, custom_header),
NULL
},
{
ngx_string("custom_logging"),
NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_FLAG,
ngx_conf_set_flag_slot,
NGX_HTTP_LOC_CONF_OFFSET,
offsetof(ngx_http_custom_conf_t, enable_logging),
NULL
},
ngx_null_command
};
カスタムハンドラの実装とフェーズ登録
最後に、完全なモジュール定義とコンパイル方法を示します。
モジュール定義の完成
c// HTTPモジュールコンテキスト
static ngx_http_module_t ngx_http_custom_module_ctx = {
NULL, /* preconfiguration */
ngx_http_custom_init, /* postconfiguration */
NULL, /* create main configuration */
NULL, /* init main configuration */
NULL, /* create server configuration */
NULL, /* merge server configuration */
ngx_http_custom_create_conf, /* create location configuration */
ngx_http_custom_merge_conf /* merge location configuration */
};
// モジュール定義
ngx_module_t ngx_http_custom_module = {
NGX_MODULE_V1,
&ngx_http_custom_module_ctx, /* module context */
ngx_http_custom_commands, /* module directives */
NGX_HTTP_MODULE, /* module type */
NULL, /* init master */
NULL, /* init module */
NULL, /* init process */
NULL, /* init thread */
NULL, /* exit thread */
NULL, /* exit process */
NULL, /* exit master */
NGX_MODULE_V1_PADDING
};
実際の動作フロー
以下の図は、このカスタムモジュールがどのように各フェーズで動作するかを示しています。
mermaidsequenceDiagram
participant Client
participant Nginx_Core
participant Custom_Module
participant Response
Client->>Nginx_Core: HTTP Request with custom header
Note over Nginx_Core: POST_READ_PHASE
Nginx_Core->>Custom_Module: post_read_handler()
Custom_Module->>Custom_Module: Extract custom header
Custom_Module->>Nginx_Core: NGX_DECLINED
Note over Nginx_Core: SERVER_REWRITE_PHASE
Note over Nginx_Core: FIND_CONFIG_PHASE
Note over Nginx_Core: REWRITE_PHASE
Note over Nginx_Core: POST_REWRITE_PHASE
Note over Nginx_Core: PREACCESS_PHASE
Note over Nginx_Core: ACCESS_PHASE
Nginx_Core->>Custom_Module: access_handler()
Custom_Module->>Custom_Module: Validate custom header
Custom_Module->>Nginx_Core: NGX_DECLINED or NGX_HTTP_FORBIDDEN
Note over Nginx_Core: POST_ACCESS_PHASE
Note over Nginx_Core: PRECONTENT_PHASE
Note over Nginx_Core: CONTENT_PHASE
Nginx_Core->>Custom_Module: content_handler()
Custom_Module->>Custom_Module: Generate JSON response
Custom_Module->>Response: HTTP Response
Response->>Client: JSON with custom data
このような実装により、Nginx の各フェーズでカスタムロジックを実行し、リクエスト処理をきめ細かく制御することができます。
まとめ
Nginx のリクエスト処理は、11 個のフェーズを通じて段階的に実行される精巧なシステムです。本記事では、フェーズ、ハンドラ、モジュールの連携について図解を交えながら詳しく解説してまいりました。
重要なポイントの再確認
フェーズベースの処理順序
Nginx は以下の順序でリクエストを処理します。
順序 | フェーズ名 | 主な役割 |
---|---|---|
1 | POST_READ | リクエストヘッダーの読み込み・解析 |
2 | SERVER_REWRITE | サーバーレベルでの URL 書き換え |
3 | FIND_CONFIG | 適切な設定コンテキストの検索 |
4 | REWRITE | ロケーションレベルでの URL 書き換え |
5 | POST_REWRITE | 書き換え後の検証とループ検出 |
6 | PREACCESS | アクセス制御の準備処理 |
7 | ACCESS | 認証・認可の実行 |
8 | POST_ACCESS | アクセス制御結果の後処理 |
9 | PRECONTENT | コンテンツ生成の準備 |
10 | CONTENT | 実際のレスポンス生成 |
11 | LOG | アクセスログの記録 |
この順序を理解することで、モジュール開発時にどのフェーズでどのような処理を行うべきかが明確になります。
ハンドラとモジュールの連携
各フェーズにおいて、複数のモジュールが登録したハンドラが順次実行されます。ハンドラは以下の戻り値によって次の処理を制御します。
NGX_OK
: 処理成功、チェーンの実行を継続NGX_DECLINED
: 現在のハンドラでは処理せず、次のハンドラへNGX_ERROR
: エラー発生、処理を中断NGX_HTTP_*
: 特定の HTTP ステータスコードを返す
モジュール開発のベストプラクティス
効果的な Nginx モジュールを開発するためには、以下の点を考慮することが重要です。
mermaidflowchart TD
design[設計段階] --> implement[実装段階]
implement --> test[テスト段階]
test --> deploy[デプロイ段階]
design -.-> phase_selection[適切なフェーズ選択]
design -.-> error_handling[エラーハンドリング設計]
implement -.-> memory_management[メモリ管理]
implement -.-> performance[パフォーマンス考慮]
test -.-> unit_test[単体テスト]
test -.-> integration_test[統合テスト]
deploy -.-> monitoring[監視体制]
deploy -.-> rollback[ロールバック計画]
学習の継続と実践への活用
Nginx のリクエスト処理を理解することで、以下のような実践的なメリットが得られます。
運用面での活用
- トラブルシューティングの効率化: 問題発生時に、どのフェーズで何が起きているかを特定できます
- パフォーマンス最適化: ボトルネックとなっているフェーズを特定し、適切な対策を講じることができます
- セキュリティ強化: アクセス制御フェーズでの適切な実装により、セキュリティを向上させることができます
開発面での活用
- カスタムモジュール開発: 要件に応じた独自機能を実装できます
- 既存モジュールの理解: サードパーティモジュールの動作原理を理解できます
- 設定最適化: より効率的な Nginx 設定を作成できます
今後の発展性
Nginx は継続的に進化しており、新しいフェーズやハンドラの仕組みが追加される可能性があります。本記事で学んだ基礎概念を基に、以下のような発展的な学習を進めることをお勧めします。
推奨する学習パス
- 実際のモジュール開発: 簡単なモジュールから始めて徐々に複雑な機能を実装してみてください
- 既存モジュールの解析: オープンソースの Nginx モジュールのコードを読んで理解を深めてください
- パフォーマンス測定: 様々な負荷条件下でのリクエスト処理性能を測定してみてください
- コミュニティ参加: Nginx コミュニティに参加して最新の情報を収集してください
Nginx のリクエスト処理メカニズムを理解することで、より高性能で信頼性の高い Web システムを構築できるようになるでしょう。
関連リンク
公式ドキュメント
技術資料
ソースコード
学習リソース
- article
Nginx リクエスト処理の舞台裏:フェーズ/ハンドラ/モジュール連携を図解で理解
- article
Nginx vs Apache 徹底比較:速度・メモリ・機能で最適解を選ぶ
- article
Nginx インストール完全ガイド:Linux・macOS・Windows・Docker 対応
- article
Nginx 入門:5 分でわかる高速 Web サーバーの基本と強み
- article
【解決方法】Dockerのnginx-proxyを経由するとアクセス元のIPが正しく取得できない件について
- article
Pinia アーキテクチャ超図解:リアクティビティとストアの舞台裏を一枚で理解
- article
FFmpeg アーキテクチャ超図解:demuxer→decoder→filter→encoder→muxer の流れを一望
- article
Obsidian 2025 年ロードマップ総ざらい:Properties/Canvas/Live Preview の現在地
- article
ESLint Flat Config 完全理解:eslint.config.js 時代の設計指針
- article
Nuxt レンダリング戦略を一気に把握:SSR・SSG・ISR・CSR・Edge の最適解
- article
Dify の内部アーキテクチャ超図解:エージェント・ワークフロー・データストアの関係
- blog
iPhone 17シリーズの発表!全モデルiPhone 16から進化したポイントを見やすく整理
- blog
Googleストアから訂正案内!Pixel 10ポイント有効期限「1年」表示は誤りだった
- blog
【2025年8月】Googleストア「ストアポイント」は1年表記はミス?2年ルールとの整合性を検証
- blog
Googleストアの注文キャンセルはなぜ起きる?Pixel 10購入前に知るべき注意点
- blog
Pixcel 10シリーズの発表!全モデル Pixcel 9 から進化したポイントを見やすく整理
- blog
フロントエンドエンジニアの成長戦略:コーチングで最速スキルアップする方法
- review
今の自分に満足していますか?『持たざる者の逆襲 まだ何者でもない君へ』溝口勇児
- review
ついに語られた業界の裏側!『フジテレビの正体』堀江貴文が描くテレビ局の本当の姿
- review
愛する勇気を持てば人生が変わる!『幸せになる勇気』岸見一郎・古賀史健のアドラー実践編で真の幸福を手に入れる
- review
週末を変えれば年収も変わる!『世界の一流は「休日」に何をしているのか』越川慎司の一流週末メソッド
- review
新しい自分に会いに行こう!『自分の変え方』村岡大樹の認知科学コーチングで人生リセット
- review
科学革命から AI 時代へ!『サピエンス全史 下巻』ユヴァル・ノア・ハラリが予見する人類の未来