Nginx インタビューのトップ 50 の質問と回答 (2026)
編集チーム
Nginx 面接の準備には、先見性、明晰さ、そして面接官が今日の実際の運用知識をどのように評価するかについての認識が求められます。Nginx 面接の質問は、深い理解、意思決定能力、トラブルシューティング能力、そして本番環境への準備能力を明らかにします。
これらの役割は、クラウドインフラストラクチャ、パフォーマンスエンジニアリング、セキュリティなど、実践的な構成が重要な分野への道を開きます。雇用主は、現場での経験から得られる技術経験、ドメイン知識、分析力を高く評価します。ping 新卒者、中堅エンジニア、ベテラン専門家は、マネージャーやチームリーダーの指導の下、チーム内で基礎から高度なスキルを応用します。 続きを読む...
Nginx面接でよくある質問と回答
1) NGINX とは何か、そしてなぜ Web インフラストラクチャで広く使用されているのかについて説明します。
NGINXは、リバースプロキシ、ロードバランサ、HTTPキャッシュとしても機能する高性能オープンソースウェブサーバーです。HTTP、HTTPS、SMTP、POP3、IMAPプロトコルをサポートしています。アーキテクチャは event-driven, asynchronous model 数万件の同時接続を低いメモリ使用量とCPU使用量で処理できるスケーラビリティを備えています。このスケーラビリティにより、NGINXは高トラフィックのWebアプリケーション、マイクロサービス、分散アーキテクチャに特に適しています。例えば、コンテンツプラットフォームやAPIゲートウェイなど、トラフィック量の多いワークロードを抱える企業は、同時接続や静的コンテンツ配信を効率的に処理するためにNGINXを好む傾向があります。
2) NGINX は HTTP リクエストを内部的にどのように処理しますか (イベント駆動型アーキテクチャ)?
NGINXの強みは event-driven, non-blocking architectureNGINXは、従来のサーバーのようにリクエストごとに個別のスレッドやプロセスを生成するのではなく、非同期イベントループを活用する少数のワーカープロセス群を使用します。各ワーカープロセスは、オペレーティングシステムの準備完了通知を待機し、発生したイベントを処理することで、数千もの接続を管理できます。I/O操作をブロックしないため、NGINXは最小限のリソースで静的コンテンツとプロキシコンテンツを提供できます。このモデルは同時実行性の高いユースケースに最適で、高負荷環境におけるプロセスベースのサーバーよりも効率的です。
3) NGINX と Apache の主な違いは何ですか?
NGINX と Apache はどちらも人気のある Web サーバーですが、アーキテクチャ、パフォーマンス、設計目標が異なります。
| 側面 | nginxの | アパッチ |
|---|---|---|
| 同時実行モデル | イベント駆動型（非同期、非ブロッキング） | プロセス/スレッドベース（ブロッキング） |
| メモリ使用量 | 接続あたりのコストが低い | 接続ごとに高い |
| 最適な使用例 | 高トラフィック、静的コンテンツ、負荷分散 | 動的コンテンツと豊富なモジュールエコシステム |
| 拡張性 | 少ないリソースで拡張可能 | プロセスのためにより多くのハードウェアが必要 |
| モジュールの取り扱い | コンパイル時に選択されたモジュール | 実行時に動的 |
NGINX の設計は負荷時のパフォーマンスを最適化しますが、Apache は動的モジュールと幅広い言語サポートにより優れた柔軟性を提供します。
4) NGINX 構成ファイルの主要コンポーネントは何ですか?
NGINX 設定ファイル (デフォルトパス: /etc/nginx/nginx.conf) は、NGINX の動作を決定する構造化されたディレクティブ ブロックで構成されています。
- 主なコンテキスト: グローバル設定など
worker_processes,error_log,pid - イベントブロック: ワーカー接続とマルチプロセスを管理する
- HTTP ブロック: HTTP 処理 (圧縮、キャッシュ、gzip など) の設定が含まれています
- サーバーブロック: 仮想ホスト（ドメインとポート）を定義します
- ロケーションブロック: ルーティングルールと特定のURIの処理方法を定義します
これらのブロックは連携して、リクエストのルーティング、プロキシ設定の定義、SSL/TLS とキャッシュの構成を行います。
5) ダウンタイムなしで NGINX 構成を安全にリロードするにはどうすればよいですか?
更新された設定でNGINXをリロードするには without interrupting active connections、次のコマンドを使用します。
nginx -s reload
またはシステム上で systemd:
sudo systemctl reload nginx
このコマンドは、マスタープロセスに構成ファイルを再読み込みさせ、ワーカーをドロップせずに正常に再起動するように指示します。ping 既存の接続。このようなシームレスな再読み込みを実行する方法を知ることは、高可用性が求められる環境において不可欠です。
6) NGINX をリバース プロキシとして設定する方法について説明します。
リバースプロキシは、クライアントからのリクエストをバックエンドサーバー（上流グループ）に転送し、レスポンスを返します。以下は、典型的なNGINXリバースプロキシのブロックです。
http {
upstream backend {
server backend1.example.com;
server backend2.example.com;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
}
}
}
このセットアップにより、セキュリティが向上し、負荷分散が提供され、クライアントとアプリケーション サーバー間のキャッシュまたはレート制限ポリシーが有効になります。
7) NGINX マスタープロセスとワーカープロセスについて説明します。
NGINXの場合:
- その マスタープロセス 構成を管理し、ワーカー プロセスを開始し、ポートへのバインドなどの特権操作を処理します。
- ワーカープロセス 実際のリクエスト処理（着信接続の処理と構成されたルールの実行）を実行します。
複数のワーカーを使用することで同時実行性が向上し、利用可能なCPUコア数やトラフィック需要に応じて調整できます。また、役割を分割することでパフォーマンスと安定性が向上します。
8) NGINX で未定義のサーバー名の処理を制限するにはどうすればよいですか?
有効なリクエストを破棄するには Host NGINXのヘッダー:
server {
listen 80;
server_name "";
return 444;
}
この構成はコードを返します 444応答なしで接続を閉じる非標準の NGINX ステータス。これにより、未定義のホストが効果的に拒否され、セキュリティが向上します。
9) ngx_http_upstream_module は何に使用されますか?
その ngx_http_upstream_module 定義 groups of backend servers （アップストリーム）NGINXが次のようなディレクティブを使用してリクエストを渡すことができる proxy_pass, fastcgi_passまたは uwsgi_passこれにより、負荷分散環境におけるアプリケーションの柔軟なスケーリングが可能になります。複数のバックエンドサーバーをグループ化した場合、NGINXは定義されたポリシーに基づいてトラフィックを分散し、ラウンドロビンなどの戦略をサポートします。
10) 静的コンテンツと動的コンテンツを提供するために NGINX がどのように使用されるかを説明します。
NGINXは非常に効率的にサービスを提供できる 静的ファイル （HTML、CSS、画像）を、最適化されたイベントループとファイルI/Oメカニズムを使用して直接処理します。 動的コンテンツNGINXはリクエストをPHP-FPMなどのバックエンドプロセッサに渡します。 Python WSGIサーバー、またはFastCGI / プロキシメカニズムを介したアプリケーションフレームワーク。この分離により、NGINXは静的ファイルサーバーとして優れた性能を発揮しながら、動的な生成にはバックエンドサービスを活用し、最適なパフォーマンスとスケーラビリティを確保します。
11) NGINX では負荷分散はどのように機能しますか? また、どのようなさまざまな方法が利用できますか?
NGINXは堅牢な ロードバランシング を通して以下のようなさまざまな upstream ディレクティブは、トラフィックを複数のバックエンドサーバーに分散することで、パフォーマンスを最適化し、高可用性を確保します。以下の複数のメソッドをサポートしています。
| 方法 | 詳細説明 | 最適な使用例 |
|---|---|---|
| ラウンドロビン | リクエストをサーバー間で順番にローテーションするデフォルトの方法。 | 均等に分散された作業負荷。 |
| 最低限の接続 | アクティブな接続が最も少ないサーバーにリクエストを送信します。 | 長時間実行されるセッション。 |
| IPハッシュ | クライアント IP を使用してサーバーの選択を決定します。 | セッションの永続性。 |
| 最短時間 | 応答時間と接続数に基づいてバランスをとります。 | 遅延に敏感なアプリケーション。 |
NGINXは以下も実行できます 健康診断 不健全なサーバーを動的に削除し、シームレスなトラフィック フローと回復力を確保します。
12) NGINX オープンソースと NGINX Plus の違いは何ですか?
nginxの オープンソース 基本的な Web サーバー、プロキシ、負荷分散機能を提供するコミュニティ バージョンです。 NGINX プラス 高度な監視、セッションの永続性、動的な再構成、アクティブなヘルス チェックなどのエンタープライズ グレードの機能強化によりこれらの機能を拡張した商用エディションです。
| 機能 | NGINX オープンソース | NGINX プラス |
|---|---|---|
| ロードバランシング | 基本（ラウンドロビン、IPハッシュ） | 高度（最短時間、動的再構成） |
| 監視 | 手動/外部ツール | 組み込みダッシュボードとAPI |
| キャッシング | Basic | パージ制御を強化 |
| サポート | コミュニティのみ | エンタープライズサポートとアップデート |
ミッションクリティカルなワークロードを持つ組織は、信頼性と監視性の向上により、NGINX Plus を選択することが多いです。
13) NGINX でキャッシュを実装するにはどうすればよいですか?
NGINXのキャッシュは、頻繁にアクセスされるコンテンツをローカルに保存することで、応答速度を向上させ、バックエンドの負荷を軽減します。これは、 proxy_cache ディレクティブ。設定例:
proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=1g;
server {
location / {
proxy_cache my_cache;
proxy_pass http://backend;
}
}
キャッシュされた応答は、一致するリクエストが到着するとディスクから直接提供されます。ping アップストリーム処理。キャッシュの有効期限は、 proxy_cache_valid 特定のURIを除外するには proxy_no_cacheこのメカニズムは、ニュースサイトや電子商取引サイトなどのトラフィック量の多い環境にとって非常に重要です。
14) 「try_files」ディレクティブの目的と使用方法を説明します。
その try_files ディレクティブは、フォールバック先にリクエストを渡す前に、指定された順序でファイルが存在するかどうかを確認します。これは通常、次のような場合に使用されます。 静的サイトルーティング or シングルページアプリケーション（SPA）.
例：
location / {
try_files $uri $uri/ /index.html;
}
ここで、NGINXはまず要求されたURIがファイルと一致するかどうかを確認し、次にディレクトリと一致するかどうかを確認し、一致しないリクエストをルーティングします。 /index.htmlこれにより、キャッシュされたファイルや静的ファイルを直接提供し、不要なバックエンド呼び出しを回避することで、効率とユーザー エクスペリエンスが向上します。
15) NGINX は HTTPS と SSL/TLS 終了をどのように処理しますか?
NGINXはSSL/TLS終端プロキシとして機能し、暗号化されていないリクエストを上流のサービスに転送する前に、サーバー層で暗号化と復号化を処理します。設定例：
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/ssl/certs/example.crt;
ssl_certificate_key /etc/ssl/private/example.key;
location / {
proxy_pass http://backend;
}
}
それはサポートしています HTTP / 2, OCSPステープリング, HSTS, 現代の暗号スイート安全で高性能な通信を実現します。NGINXでSSLを終端することで、バックエンドサーバーの暗号化オーバーヘッドが削減され、証明書管理が簡素化されます。
16) NGINX における rewrite と redirect の違いは何ですか?
両方 書き直す (NAIST) と リダイレクト リクエストのルーティング方法を変更しますが、根本的に異なります。
| 側面 | リライト | リダイレクト |
|---|---|---|
| タイプ | インナー URL 書き換え | 外部クライアントのリダイレクト |
| 世界の動き Code | 200（内部） | 301/302 (HTTP リダイレクト) |
| 透明性 | ユーザーにとって透明 | クライアントは新しいものを見る URL |
| Use Case | SEOフレンドリー URLs、ルーティング | ドメイン移行、HTTPSの強制 |
例：
rewrite ^/oldpage$ /newpage permanent; # Redirect rewrite ^/img/(.*)$ /assets/$1 break; # Rewrite
この違いを理解することが、SEO とルーティング ロジックを効果的に最適化するための鍵となります。
17) 一般的な脆弱性から NGINX をどのように保護しますか?
セキュリティ強化には、ベスト プラクティスの組み合わせが含まれます。
- サーバー トークンを無効にする:
server_tokens off; - リクエストメソッドを制限する: GET、POST、HEAD のみを許可します。
- バッファオーバーフローを制限する: 構成
client_max_body_size(NAIST) とclient_body_buffer_size. - 最新の暗号を使用した HTTPS を使用します。
- レート制限を有効にする 、
limit_req_zone. - バージョン情報を非表示にし、ディレクトリの一覧表示を無効にします。
さらに、 Webアプリケーションファイアウォール（WAF） ような ModSecurity with NGINX 悪意のあるトラフィックをフィルタリングできます。ゼロデイ攻撃を防ぐには、NGINXを定期的に更新し、セキュリティパッチを適用することが不可欠です。
18) NGINX 変数とは何ですか? また、設定でどのように使用されますか?
NGINX変数は、設定やログ処理で使用される動的なデータを格納します。リクエストヘッダー、クライアントIP、または計算された値を表すことができます。例としては、 $remote_addr, $host, $uri, $request_method, $upstream_addr.
例えば：
log_format custom '$remote_addr - $host - $uri';
変数は柔軟性を高め、条件付きルーティングやカスタムログを可能にします。また、 set モジュール構成の設計に役立つディレクティブです。
19) NGINX でレート制限を設定するにはどうすればいいですか?
レート制限は、ユーザーがリクエストを送信できる頻度を制御し、ブルートフォース攻撃やDDoS攻撃から保護します。設定は limit_req_zone 指令：
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
server {
location / {
limit_req zone=mylimit burst=5;
}
}
これにより、1秒あたり1リクエスト（バーストは5）が許可されます。NGINXは設定に基づいて、過剰なリクエストを破棄または遅延させます。レート制限により、リソースの公平な使用が確保され、サーバーの過負荷を防ぎます。
20) NGINX をリバース プロキシとして使用する場合の利点と欠点は何ですか?
リバース プロキシとしての NGINX には多くの利点がありますが、いくつかのトレードオフもあります。
| 優位性 | デメリット |
|---|---|
| 高性能と同時実行処理 | 大規模な導入には手動調整が必要 |
| SSL終了と集中セキュリティ | 限定的な動的モジュールのサポート（コンパイル時） |
| 負荷分散とキャッシュのサポート | 新規ユーザー向けの複雑な設定 |
| アプリケーション層フィルタリング | ネイティブの動的コンテンツ実行の欠如 |
ほとんどのエンタープライズ シナリオでは、その利点が制限をはるかに上回っており、NGINX は現代の Web インフラストラクチャに欠かせないコンポーネントとなっています。
21) 本番環境で NGINX のパフォーマンスと健全性をどのように監視できますか?
NGINXの監視は、ボトルネック、障害、異常なトラフィック挙動を特定するために不可欠です。いくつかのアプローチが利用可能です。
- 内蔵ステータスモジュール（
stub_status):アクティブな接続、処理されたリクエスト、読み取り/書き込み状態を表示します。例:
location /nginx_status { stub_status; allow 127.0.0.1; deny all; } - NGINX Plus ダッシュボード: REST API と GUI を介してリアルタイム メトリックを提供します。
- サードパーティの統合: Prometheus、Grafana、Datadog、ELK などのツールは、メトリックとログを収集できます。
- アクセスとエラーログ: GoAccess や AWStats などのツールを使用した定期的なログのローテーションと分析により、観測可能性が向上します。
監視は、稼働時間の確保、障害の迅速な検出、容量計画に役立ちます。
22) proxy_pass ディレクティブと fastcgi_pass ディレクティブの違いは何ですか?
どちらのディレクティブもリクエストをバックエンド サービスに転送しますが、異なるプロトコル用に設計されています。
| 指令 | 目的 | バックエンドプロトコル | 使用例 |
|---|---|---|---|
proxy_pass |
HTTP または HTTPS リクエストをバックエンド サーバーに転送します | HTTP | Reverse プロキシ経由のWeb APIまたはマイクロサービス |
fastcgi_pass |
FastCGIプロセッサにリクエストを送信します | 高速CGI | PHP-FPM、 Python FastCGIアプリケーション |
例：
location /api/ {
proxy_pass http://backend;
}
location ~ \.php$ {
fastcgi_pass unix:/run/php/php7.4-fpm.sock;
}
要約すると、使用 プロキシパス 汎用HTTPバックエンドおよび fastcgi_pass PHP のような動的言語ランタイム向け。
23) NGINX で gzip 圧縮を設定する方法とその利点は何ですか?
NGINX で Gzip 圧縮を有効にすると、テキストベースの応答をクライアントに送信する前に圧縮することで、帯域幅の使用量を削減し、読み込み時間を短縮できます。
構成例:
gzip on; gzip_types text/plain text/css application/json application/javascript; gzip_min_length 1024; gzip_comp_level 6; gzip_vary on;
メリット：
- ファイル転送サイズを最大 70% 削減します。
- 最初のバイトまでの時間 (TTFB) とページ パフォーマンス スコアが向上します。
- 帯域幅のコストを節約します。特にモバイル ユーザーにとって有益です。
ただし、すでに圧縮されたファイル（例： .zip, .jpg, .png) を使用して、CPU オーバーヘッドを回避します。
24) 高トラフィック向けに NGINX をチューニングするためのベスト プラクティスは何ですか?
高トラフィックの最適化には、リソースと構成パラメータの慎重な調整が必要です。
| エリア | 指令 | 推奨される方法 |
|---|---|---|
| 労働者 | worker_processes auto; |
CPUコアを一致させる |
| つながり | worker_connections 4096; |
同時実行性の向上 |
| 生き続ける | keepalive_timeout 65; |
クライアントの再利用を最適化する |
| File Descript金メダル | OS ulimit -n |
オープンソケットの制限を引き上げる |
| キャッシング | proxy_cache_path |
バックエンドの負荷を軽減 |
| Gzip | gzip on; |
テキスト応答を圧縮する |
さらに、 非同期ディスクI/O, ロードバランシング, アップストリームヘルスチェック 大量の同時リクエスト下でも安定性と速度を保証します。
25) NGINX は WebSocket 接続をどのように処理しますか?
WebSocketは、クライアントとサーバー間の双方向通信を可能にします。これはリアルタイムアプリケーションにとって非常に重要です。NGINXは、適切なヘッダー転送を通じてこれをネイティブにサポートしています。
構成例:
location /ws/ {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
キーポイント：
- その
Upgrade(NAIST) とConnectionヘッダーは必須です。 - NGINX が永続的な TCP 接続に HTTP/1.1 を使用することを確認します。
- 負荷分散WebSocketでは、スティッキーセッションが必要になる場合があります。
ip_hash.
この構成は、チャット、株取引、ゲームなどのアプリケーションをサポートします。
26) 「worker_rlimit_nofile」ディレクティブの目的は何ですか?
worker_rlimit_nofile ワーカープロセスで利用可能なオープンファイル記述子の最大数を定義します。この制限は、NGINXが処理できる同時接続数に直接影響します。例：
worker_rlimit_nofile 100000;
この制限値を上げることは、APIゲートウェイやストリーミングプラットフォームのような高同時実行システムにとって不可欠です。しかし、OSの制限（ulimit -n一貫性を保つために、この値に合わせて ) も増やす必要があります。
27) NGINXはどのように使用できますか？ URL 自動的にHTTPSに書き換えたり、リダイレクトしたりする？
HTTPをHTTPSにリダイレクトすることで、安全な通信が確保されます。例:
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}
この構成では、 301 永続リダイレクト HTTPからHTTPSへ。より細かい制御のために、書き換えルールでパス固有のリダイレクトを強制することができます。
rewrite ^/oldpath$ /newpath permanent;
自動 HTTPS 強制により SEO ランキングが向上し、中間者攻撃が防止され、一貫したユーザー エクスペリエンスが維持されます。
28) NGINX で「502 Bad Gateway」エラーが発生する一般的な原因は何ですか?
「502 Bad Gateway」は、プロキシとして動作しているNGINXが上流サーバーから有効な応答を受信できなかったことを示します。一般的な原因としては、以下のようなものが挙げられます。
- バックエンド サーバーがクラッシュまたは利用不能。
- 誤答
proxy_passURL またはソケットパス。 - アップストリームタイムアウト（
proxy_read_timeout低すぎる）。 - ファイアウォールまたは SELinux がアップストリーム接続をブロックしています。
- FastCGI パラメータの設定が誤っています (PHP の場合)。
デバッグするには、エラーログを確認してください（/var/log/nginx/error.log）、上流の到達可能性を確認し、バックエンドの応答を直接テストします。 curl.
29) NGINX はマイクロサービスとコンテナベースのアーキテクチャ (Docker、Kubernetes など) をどのようにサポートしますか?
NGINXは次のような場合に最適です マイクロサービス環境 軽量設計とリバースプロキシ機能により、DockerやKubernetesでは以下のような役割を果たします。
- イングレス コントローラー: 内部サービスへの外部 HTTP/S トラフィックを管理します。
- サービスゲートウェイ: ルーティング、負荷分散、認証を実行します。
- サイドカープロキシ: サービス メッシュ (Istio など) の回復力と可観測性を強化します。
NGINXの設定はKubernetes ConfigMapsを介して動的に更新できるため、集中的なトラフィック制御とSSL管理が可能になります。モジュール型のアプローチは、コンテナ化されたデプロイメントやクラウドネイティブなデプロイメントに最適です。
30) 実稼働システムの NGINX セキュリティを向上させるにはどのような方法がありますか?
NGINX のセキュリティを強化するには、多層構成が必要です。
- SSL/TLS 強化: 最新の暗号を使用し、SSLv3/TLSv1.0 を無効にします。
- HTTP メソッドを制限する: 安全な動詞 (GET、POST、HEAD) のみを許可します。
- セキュリティ ヘッダー:
add_header X-Frame-Options "DENY"; add_header X-Content-Type-Options "nosniff"; add_header X-XSS-Protection "1; mode=block";
- バージョン情報を非表示:
server_tokens off; - レート制限とアクセス制御を有効にします。
- WAFまたはFail2Banを統合する ブルートフォース攻撃の防止のため。
これらの対策を組み合わせることで、一般的なエクスプロイトに耐性のある、強化された本番環境レベルの NGINX 環境が構築されます。
31) NGINX の問題を効果的にデバッグするにはどうすればよいでしょうか?
NGINXのデバッグには、ログ、設定ファイル、プロセス状態を体系的に分析することが含まれます。主な手順は以下のとおりです。
- 構文を確認してください:
- 再ロード前に構成を検証します。
- 詳細なランタイム診断を提供します。
- 接続性のテスト：
curl -vorwgetバックエンドの到達可能性を確認します。 - アクティブな接続を監視する: ビア
stub_statusornetstat.
nginx -t
デバッグログを有効にする:
error_log /var/log/nginx/error.log debug;
アクセスログを分析する: 以下を使用して応答コードと要求パターンを検出します。
tail -f /var/log/nginx/access.log
NGINX のワーカー プロセス、バッファー制限、アップストリーム応答を理解することで、実稼働システムのボトルネックを迅速に特定できるようになります。
32) NGINX ログをどのように構成しますか? また、カスタム ログ形式とは何ですか?
NGINXは、柔軟なログ記録メカニズムを提供します。 access_log (NAIST) と error_log ディレクティブ
構成例:
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$request_time"';
access_log /var/log/nginx/access.log main;
error_log /var/log/nginx/error.log warn;
あなたは定義することができます カスタムフォーマット 次のような指標を含める $upstream_addr, $request_timeまたは $bytes_sent.
高度な観測性を実現するために、ログは多くの場合、 ELK、Loki、またはSplunk リアルタイム分析とダッシュボード作成に。
33) NGINX における proxy_buffering ディレクティブの役割は何ですか?
proxy_buffering NGINX がアップストリーム サーバーからの応答をクライアントに送信する前にバッファリングするかどうかを制御します。
| Setting | 詳細説明 | Use Case |
|---|---|---|
proxy_buffering on; |
Bufferスループットを最適化するために応答全体をs | デフォルト; パフォーマンスを向上 |
proxy_buffering off; |
バッファリングなしでクライアントに直接データをストリーミングします | リアルタイムストリーミングまたはAPI |
たとえば、バッファリングを無効にするには：
location /stream/ {
proxy_buffering off;
}
バッファリングを無効にすると、チャットやストリーミング サービスには最適ですが、通常の Web トラフィックのスループットが低下する可能性があります。
34) NGINX キャッシュを無効化または消去する方法を説明します。
NGINX オープンソースにはキャッシュ消去機能が組み込まれていませんが、いくつかの方法で実現できます。
- 手動パージ: キャッシュディレクトリからファイルを削除します。
rm -rf /var/cache/nginx/*
- サードパーティモジュール:
ngx_cache_purgeHTTPリクエスト経由で消去するには:location ~ /purge(/.*) { proxy_cache_purge my_cache $host$1; } - NGINX Plus の機能: API ベースのキャッシュの動的消去を許可します。
パージにより、古くなったコンテンツがすぐに置き換えられ、CDN またはマルチノードの展開全体でコンテンツの鮮度と一貫性が維持されます。
35) NGINX は接続タイムアウトをどのように処理しますか?
NGINX は、クライアントまたはアップストリームの応答を待機する時間を制御するために、複数のタイムアウト ディレクティブを提供します。
| 指令 | 目的 | デフォルト |
|---|---|---|
client_body_timeout |
クライアント本体の待機時間 | 60 |
client_header_timeout |
クライアントヘッダーの待機時間 | 60 |
keepalive_timeout |
アイドルキープアライブ接続 | 75 |
send_timeout |
クライアントにデータを送信する時間 | 60 |
proxy_read_timeout |
上流応答の待ち時間 | 60 |
適切な調整により、不要な切断を回避し、変化するネットワーク条件下でもスムーズなユーザー エクスペリエンスを実現できます。
36) NGINX を使用してブルーグリーン デプロイメントを実装するにはどうすればよいですか?
で ブルーグリーンデプロイメント2つの環境（青＝アクティブ、緑＝スタンバイ）が同時に稼働します。NGINXはそれらの間のトラフィックルーターとして機能します。
構成例:
upstream app_cluster {
server blue.example.com;
#server green.example.com; # Uncomment during switch
}
server {
location / {
proxy_pass http://app_cluster;
}
}
新しいバージョン（グリーン）がテストされ検証されると、アップストリーム定義を更新し、NGINXをリロードすることでトラフィックが切り替えられます（nginx -s reload).
この方法により、 ダウンタイムなし アプリケーションの更新またはロールバック中。
37) レート制限バーストとは何ですか? また、NGINX のパフォーマンスをどのように向上させますか?
その バースト レート制限のパラメータにより、トラフィックの急上昇を即座に拒否せずに一時的に通過させることができます。
例：
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
location /api/ {
limit_req zone=mylimit burst=5 nodelay;
}
ここでは、スロットルを適用する前に、5 つの追加リクエストが即座に受け入れられます。
この技術により、トラフィックの急増が緩和され、バックエンド システムに負担をかけずに一貫したユーザー エクスペリエンスが維持されます。
38) NGINX は IPv6 とデュアルスタック環境をどのように処理しますか?
NGINXは、サーバーとアップストリームの両方の設定でIPv6を完全にサポートしています。例:
server {
listen [::]:80 ipv6only=on;
server_name example.com;
}
デュアル スタック サポート (IPv4 + IPv6) は、次の両方を組み込むことによって実現されます。
listen 80; listen [::]:80;
IPv6 互換性により、特にモバイル クライアントや国際クライアントのアクセス性が高まり、最新のインターネット標準への準拠が重要になります。
39) NGINX ロードバランシングでスティッキーセッションを設定するにはどうすればよいですか?
スティッキー セッションにより、同じクライアントからのリクエストが常に同じバックエンド サーバーにルーティングされるようになります。
- 使い方
ip_hash:upstream backend { ip_hash; server app1.example.com; server app2.example.com; } - NGINX Plus スティッキー クッキー:
設定可能な Cookie による高度なセッション永続性。
ユーザーダッシュボードやショップなどのステートフルアプリケーションにとって、スティッキーセッションは不可欠です。ping カートを使用し、共有ストレージを使用せずにセッションデータの一貫性を確保します。
40) NGINX の主なログ レベルは何ですか。また、それらの違いは何ですか。
NGINX は、エラー ログの詳細度を制御するために階層的なログ レベルをサポートしています。
| レベル | 詳細説明 |
|---|---|
debug |
トラブルシューティングのための詳細情報（非常に詳細） |
info |
一般的なランタイム情報 |
notice |
重要だが重大ではないイベント |
warn |
潜在的な問題または誤った設定 |
error |
Opera注意が必要なエラー |
crit, alert, emerg |
重大な障害とシステムアラート |
構成例:
error_log /var/log/nginx/error.log warn;
環境に応じてログ レベルを調整すると (ステージングではデバッグ、本番環境では警告)、可視性とパフォーマンスのバランスを維持するのに役立ちます。
41) NGINX のパフォーマンスをどのようにベンチマークしますか?
NGINXのベンチマークでは、スループット、レイテンシ、同時実行性を測定し、構成のボトルネックを特定します。一般的なツールには以下が含まれます。
ApacheBench (ab):
ab -n 10000 -c 100 http://example.com/
- 要求の量と同時実行性をテストします。
- 仕事: 詳細なレイテンシ パーセンタイルとリクエスト レートを提供します。
- 包囲 / httperf: 実際のトラフィック負荷をシミュレートします。
- Grafana + Prometheus: ライブ パフォーマンス メトリックを監視します。
ベンチマークでは次のようなパラメータを測定する必要があります。 requests per second (RPS), time per request, error rate.
調整変数 worker_processes, worker_connections, keepalive_timeout 観測されたスループットが大幅に向上します。
42) NGINX は CI/CD パイプラインとどのように統合できますか?
NGINXはシームレスに統合します CI / CD 自動化されたデプロイメント、テスト、構成管理のためのものです。一般的なアプローチには次のようなものがあります。
- インフラストラクチャ Code (IaC): Ansible、Terraform、または Helm チャートを使用して構成を管理します。
- Dockerコンテナ： CIツールを使用してNGINXイメージを構築およびデプロイします（Jenkins（GitLab CI、またはGitHub Actions）。
- 自動テスト: 構成を検証するには
nginx -tパイプラインの各段階で。 - 青緑 / Canary 展開の自動化： ロールアウト中にアップストリーム サーバーを動的に更新します。
GitLab CI スニペットの例:
deploy:
script:
- nginx -t
- systemctl reload nginx
自動化されたデプロイメントにより、一貫性があり、バージョン管理された信頼性の高い NGINX ロールアウトが保証されます。
43) Kubernetes における NGINX Ingress Controller の役割について説明します。
その NGINX Ingress コントローラー Kubernetes サービスへの受信トラフィックを管理します。Kubernetes Ingress リソースを NGINX 構成に動的に変換します。
主な機能：
- HTTP/S リクエストを適切なサービスにルーティングします。
- SSL終端、レート制限、および URL 書き直し。
- ポッド間の負荷分散をサポートします。
- きめ細かな制御のための注釈を有効にします (例: rewrite-target、proxy-body-size)。
Ingress YAMLの例:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web-ingress
annotations: nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: myapp.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web-service
port:
number: 80
このアーキテクチャは、トラフィック ルーティング ロジックをコンテナのデプロイメントから分離し、柔軟なスケーラビリティを実現します。
44) NGINX は HTTP/2 をどのように処理し、どのような利点があるのでしょうか?
NGINXは完全にサポートしています HTTP / 2は、HTTP/1.1 の後継であり、多重化とヘッダー圧縮によって効率が向上します。
HTTP/2 を有効にするには:
server {
listen 443 ssl http2;
...
}
Advantages:
| 機能 | 詳細説明 |
|---|---|
| 多重化 | TCP接続ごとに複数のリクエスト |
| ヘッダー圧縮 (HPACK) | 帯域幅の使用量を削減 |
| サーバープッシュ | 事前に資産をクライアントに送信する |
| より高速なTLS | 合理化された安全なハンドシェイク |
HTTP/2 は、特に多数のアセットを持つ最新の Web アプリケーションにおいて、待ち時間とページの読み込み時間を大幅に短縮します。
45) NGINX におけるアップストリーム キープアライブと接続再利用の違いは何ですか?
アップストリームキープアライブ バックエンドサーバーへの永続的な接続を維持し、TCPハンドシェイクのオーバーヘッドを削減します。例:
upstream backend {
server app1.example.com;
keepalive 32;
}
差：
| 側面 | 生き続ける | 接続の再利用 |
|---|---|---|
| 対象領域 | NGINXとアップストリーム間 | NGINXとクライアント間 |
| 目的 | バックエンドの最適化 | フロントエンドのパフォーマンス |
keepalive 内部 upstream |
keepalive_timeout in server コロナ新型ウィルス(COVID-XNUMX)やメンタルヘルスの崩壊を避ける為の |
どちらの手法もレイテンシを削減しますが、異なる通信層（クライアント側とサーバー側）を提供します。
46) NGINX を再起動せずに動的に再構成するにはどうすればよいですか?
新しい構成を動的に適用する ダウンタイムなしには、Live モジュールで提供された reload 機構：
nginx -t && nginx -s reload
これは、 マスタープロセス 更新された構成で新しいワーカーを生成し、古いワーカーを正常にシャットダウンします。
NGINX Plusでは変更が可能です API経由 (例: アップストリーム サーバーを動的に追加する):
curl --request POST \
--url http://localhost:8080/api/3/http/upstreams/backend/servers \
--header 'Content-Type: application/json' \
--data-raw '{"server":"10.0.0.12"}'
この機能は、最新の DevOps パイプラインでのゼロダウンタイムのデプロイメントをサポートします。
47) NGINX におけるリバース プロキシとフォワード プロキシの主な違いは何ですか?
| 側面 | Reverse プロキシ | フォワードプロキシ |
|---|---|---|
| クライアントの可視性 | バックエンドサーバーを認識しないクライアント | クライアントのIDを認識しないサーバー |
| 主な用途 | 負荷分散、キャッシュ、SSL終了 | フィルタリング、匿名性、アクセス制御 |
| 一般的な使用例 | ウェブトラフィックの分布 | 企業または安全なアウトバウンドブラウジング |
| NGINX サポート | ネイティブで広く使用されている | カスタム構成が必要 |
例（フォワードプロキシ）：
location / {
proxy_pass $scheme://$http_host$request_uri;
proxy_set_header Host $http_host;
}
Reverse プロキシは、特にAPIゲートウェイやマイクロサービスアーキテクチャにおいて、依然として主要なユースケースとなっている。
48) API レート制限とスロットリングに NGINX をどのように使用できますか?
レート制限はAPIの不正使用を防ぎ、公正な利用を保証します。設定例：
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
server {
location /api/ {
limit_req zone=api_limit burst=20 nodelay;
proxy_pass http://backend;
}
}
メカニズム：
limit_req_zone: 共有メモリのゾーンとレートを定義します。burst: 一時的なスパイクを限定的に許可します。nodelay: 制限を即時に適用します。
この構成により、短いバーストを許可しながら、各クライアント IP が 1 秒あたり 10 件のリクエストのみを実行できるようになります。
49) エンタープライズ DevOps 環境における NGINX の一般的な使用例は何ですか?
エンタープライズ DevOps エコシステムにおいて、NGINX は複数の重要な役割を果たします。
- Webサーバー： 高性能な静的コンテンツ配信。
- Reverse プロキシ／ロードバランサー： マイクロサービス全体のトラフィック管理。
- APIゲートウェイ: 認証、ルーティング、スロットル。
- イングレス コントローラー: Kubernetes クラスターの場合。
- コンテンツ キャッシュ レイヤー: バックエンドの負荷を軽減します。
- SSL 終了エンドポイント: 集中化された証明書管理。
- 監視エンドポイント: メトリクスと可観測性の統合。
軽量なフットプリントとモジュール設計により、NGINX は CI/CD パイプライン、ハイブリッド クラウド、高可用性クラスターに欠かせないものとなっています。
50) 負荷分散における NGINX と HAProxy の主な違いは何ですか?
どちらも高性能なロードバランサですが、重点とアーキテクチャが異なります。
| 機能 | nginxの | ハプロキシ |
|---|---|---|
| 主な役割 | Webサーバー + リバースプロキシ | 専用TCP/HTTPロードバランサ |
| 設定のシンプルさ | Webベースのワークロードが簡単 | 複雑だがよりきめ細かな制御 |
| レイヤのサポート | L7 (HTTP)、L4 の一部 | L4とL7フル |
| 動的再構成 | 限定的（オープンソース） | ネイティブランタイムのアップデート |
| パフォーマンス | 混合ワークロードに最適 | 生の負荷分散に優れている |
| その他機能 | キャッシュ、圧縮、静的コンテンツ | 健康診断、スティックテーブル |
企業はしばしば合併する NGINX（フロントエンド） (NAIST) と HAProxy（バックエンド） 最適なルーティングとスケーラビリティを実現します。
🔍 実際のシナリオと戦略的回答を備えたNGINX面接でよく聞かれる質問
1) NGINX とは何ですか? また、なぜ本番環境でよく使用されるのですか?
応募者に期待すること: 面接官は、NGINX に関する基礎知識と、実際のシステムにおけるその実用的な価値の理解を評価したいと考えています。
回答例： NGINXは、イベントドリブンアーキテクチャで知られる高性能ウェブサーバーおよびリバースプロキシです。従来のウェブサーバーよりもシステムリソースの消費量が少なく、多数の同時接続を効率的に処理できるため、本番環境で広く使用されています。
2) NGINX と Apache の違いを説明していただけますか?
応募者に期待すること: 面接官は、テクノロジーを比較し、ユースケースに基づいて適切なツールを選択する能力を評価します。
回答例： 「NGINXは非同期のノンブロッキングアーキテクチャを採用しており、高トラフィックや静的コンテンツの処理効率が向上します。Apacheはプロセス駆動型モデルを採用しており、動的な設定に対してより柔軟に対応できますが、高負荷時にはより多くのリソースを消費する可能性があります。」
3) NGINX はどのようにリバースプロキシとして機能しますか?
応募者に期待すること: 面接官は、リバース プロキシの概念と、NGINX が最新のアーキテクチャにどのように適合するかについての理解を確認したいと考えています。
回答例： 「NGINXは、クライアントからのリクエストを受信してバックエンドサーバーに転送することでリバースプロキシとして機能します。その後、サーバーからのレスポンスをクライアントに返すことで、セキュリティ、負荷分散、そして全体的なパフォーマンスが向上します。」
4) 負荷分散に NGINX を使用した状況について説明してください。
応募者に期待すること: 面接官は、実践的な経験と、実際のシナリオで NGINX の機能を適用する能力を求めています。
回答例： 「以前の職務では、ラウンドロビンと最小接続アルゴリズムを用いて、複数のアプリケーションサーバーにトラフィックを分散するようにNGINXを設定していました。このアプローチにより、アプリケーションの可用性が向上し、単一のサーバーがボトルネックになることを防止できました。」
5) NGINX で SSL および HTTPS 構成をどのように処理しますか?
応募者に期待すること: 面接官は、セキュリティのベストプラクティスと構成管理に関する理解度を評価したいと考えています。
回答例： 「以前の職務では、証明書のインストール、HTTPSリスナーの有効化、強力な暗号スイートの適用など、SSLの設定を行いました。また、すべてのエンドポイントで安全な通信を確保するために、HTTPからHTTPSへのリダイレクトも実装しました。」
6) NGINX の 502 Bad Gateway エラーをトラブルシューティングするには、どのような手順を実行しますか?
応募者に期待すること: 面接官はあなたの問題解決能力とトラブルシューティング方法をテストしています。
回答例： 「まず、NGINXのエラーログをチェックして、バックエンドの接続性の問題を特定します。次に、上流サーバーが稼働していることを確認し、プロキシ設定が正しいことを確認し、タイムアウトが適切に設定されていることを確認します。」
7) 高トラフィックアプリケーションに対して NGINX のパフォーマンスをどのように最適化しますか?
応募者に期待すること: 面接官は、パフォーマンスのチューニングとスケーラビリティにどのように取り組んでいるかを知りたいと思っています。
回答例： 「前職では、gzip圧縮の有効化、ワーカープロセスのチューニング、静的コンテンツのキャッシュ設定など、NGINXの最適化を行いました。これらの変更により、応答時間とサーバー負荷が大幅に軽減されました。」
8) NGINX が静的コンテンツと動的コンテンツをどのように処理するかを説明していただけますか?
応募者に期待すること: 面接官は、リクエストの処理とパフォーマンスの最適化に関する理解度を評価します。
回答例： 「NGINXは、静的コンテンツをファイルシステムから直接、非常に効率的に提供します。動的コンテンツの場合は、リクエストをアプリケーションサーバーやPHP-FPMなどのサービスに転送することで、各コンポーネントがそれぞれの得意分野に集中できるようにします。」
9) NGINX 設定の変更を安全に管理およびテストするにはどうすればよいですか?
応募者に期待すること: 面接官は、信頼性とリスク軽減に対するあなたのアプローチを理解したいと考えています。
回答例： 「サービスをリロードする前に、NGINXの設定テストコマンドを使って設定変更を検証しています。また、メンテナンス期間中に変更を適用し、デプロイ後はログを注意深く監視しています。」
10) NGINX 関連の障害を迅速に解決しなければならなかったときのことを説明してください。
応募者に期待すること: 面接官は、プレッシャーの下で仕事を遂行し、インシデント発生時に効果的にコミュニケーションをとる能力を評価します。
回答例： 「前職では、上流サービスの設定ミスが原因で障害が発生しました。ログから問題を迅速に特定し、設定をロールバックし、サービスが完全に復旧するまで関係者にステータスの更新を報告しました。」
