Nginx（エンジンエックス）とは、Webサーバーやリバースプロキシとして広く利用されている、軽量・高性能なオープンソースソフトウェアです。
少ないリソースで大量のアクセスを処理できる設計が特徴で、静的なWebページの配信から、Node.jsやPythonで作成したWebアプリケーションの前段まで、さまざまな場面で使われています。
本記事では、Nginxの特徴やApacheとの違いを解説した上で、Ubuntuへのインストール、静的ページの公開、設定ファイルの基本、リバースプロキシの設定、よくあるエラーの対処法までを順番に紹介します。
記事の手順どおりに進めれば、初めての方でもNginxで実際にWebページを公開できるようになります。
Nginxとは
Nginxの読み方と基本的な役割
Nginxは「エンジンエックス」と読み、「engine x」に由来する名前です。
nginx公式サイト（nginx.org）では、NginxはHTTPのWebサーバー、リバースプロキシ、コンテンツキャッシュ、ロードバランサーなどとして動作するソフトウェアと説明されています。
なお、公式サイトやコマンド名では小文字の「nginx」、商用製品やブランド名としては大文字の「NGINX」と表記されることもあります。
本記事では、ソフトウェア名を「Nginx」、コマンドやファイル名を「nginx」と表記します。
Nginxの特徴と開発の背景
Nginxは、高い処理性能と軽量さが特徴的な、オープンソースのWebサーバーソフトウェアです。
2000年代前半に、ロシアのソフトウェアエンジニアであるIgor Sysoev氏によって開発され、2004年に一般公開されました。
当時のWebサーバーでは、1台のサーバーで1万件規模の同時接続をどう処理するかという課題（C10K問題）が注目されていました。
この課題に対応するため、Nginxはイベント駆動型のアーキテクチャを採用し、少ないプロセスで大量の同時接続を効率よく処理できるよう設計されています。
この特徴から、アクセス数が多いWebサイトや、複数のサーバー・アプリケーションを組み合わせたシステムなどで広く利用されています。
また、Nginxの設定はテキスト形式の設定ファイルに記述するため、用途に応じて動作を細かく設定できます。
Nginxが多くの接続を処理できる仕組み
Nginxは起動すると、1つの「マスタープロセス」と、複数の「ワーカープロセス」で動作します。
- マスタープロセス：設定ファイルを読み込み、ワーカープロセスを起動・管理する
- ワーカープロセス：クライアントからのリクエストを実際に処理する
ワーカープロセスは、接続1つごとに専用のプロセスやスレッドを割り当てるのではなく、「データを受信できる」「送信できる」といったイベントが発生した接続から順番に処理していく仕組みで動作します。
応答を待っているだけの接続のためにプロセスやスレッドを確保しておく必要がないため、同時接続数が増えてもメモリ使用量を抑えやすくなります。
プロセスの役割や設定ファイルの基本については、nginx公式のBeginner’s Guideでも解説されています。
Nginxでできること
Nginxは、単純にHTMLファイルを配信するだけのソフトウェアではありません。
代表的な用途として、次のようなものがあります。
- Webサーバーとして静的ファイル（HTML・CSS・画像など）を配信する
- 複数のWebサイトを一つのサーバーで運用する（バーチャルホスト）
- リバースプロキシとしてアプリケーションサーバーへリクエストを転送する
- SSL/TLS通信を処理し、WebサイトをHTTPSに対応させる
- 複数のサーバーへリクエストを振り分けて負荷分散（ロードバランシング）を行う
- キャッシュを利用してコンテンツ配信を効率化する
このように、Nginxは「Webページを配信するサーバー」と「アプリケーションの前段に配置するサーバー」の両方として利用できるのが大きな特徴です。
NginxとApacheの違い
Nginxと比較されることが多いWebサーバーに「Apache HTTP Server（以下、Apache）」があります。
Apacheも長い歴史を持つ代表的なWebサーバーであり、現在でもさまざまなWebサイトやシステムで利用されています。
両者の違いは、よく「Apacheはプロセス・スレッド方式、Nginxはイベント駆動方式」と説明されます。
ただし、現在のApacheはMPM（マルチプロセッシングモジュール）によって処理方式を選べるようになっており、prefork・worker・eventといった方式があります。
Linuxなどの現在の主要な環境ではevent MPMが標準になることが多く、Apacheでもイベントを活用した接続管理が行われています。
そのため、「処理方式が違うからNginxの方が必ず速い」とは言い切れません。
両者の違いは、次のような設計や設定方法、得意な使われ方の違いとして捉えると理解しやすくなります。
| 比較項目 | Nginx | Apache |
|---|---|---|
| 処理方式 | 少数のワーカープロセスがイベント駆動で多数の接続を処理する | MPMにより処理方式を選択する（prefork／worker／event） |
| 設定方法 | 本体の設定ファイルに集約して管理する | 本体の設定ファイルに加え、.htaccessでディレクトリ単位の設定もできる |
| .htaccess | 相当する仕組みはない | 利用できる（設定で許可した場合） |
| 動的コンテンツ（PHPなど） | PHP-FPMなど外部のプログラムへ処理を渡す | モジュールで処理する構成や、PHP-FPMと連携する構成がある |
| リバースプロキシ | 主要な用途の一つとして広く利用されている | mod_proxyなどのモジュールで対応できる |
| よく使われる場面 | アクセスの多いサイトの配信や、アプリケーションの前段に置く構成 | .htaccessを使うレンタルサーバー環境や、既存のApache資産を活かす構成 |
特に初心者が意識しておきたいのが、設定方法の違いです。
Apacheでは「.htaccess」という設定ファイルを利用して、Webサイトのディレクトリ単位で設定を変更できる仕組みがあります。
一方、NginxにはApacheの.htaccessに相当する仕組みがなく、Nginx本体の設定ファイルを編集して設定を反映します。
そのため、Nginxでは設定ファイルの構造を理解することが重要になります。
なお、Apache公式ドキュメントの.htaccessの解説でも、本体の設定ファイルを編集できる場合はそちらに設定を記述することが推奨されています。
実際の現場では、Nginxを前段のリバースプロキシとして配置し、その後ろでApacheを動かすように、両者を組み合わせる構成もあります。
どちらかが一方的に優れているということはなく、既存システムとの互換性や必要な機能、運用方法などによって適したWebサーバーは異なります。
それぞれの仕組みや得意分野を理解した上で、利用目的や環境に合わせて選択するようにしましょう。
Apacheとは？できること・メリット・使い方を解説
▶
【実践】UbuntuにNginxをインストールして動かしてみる
事前準備：Ubuntu環境の用意
NginxはLinux、Windows、macOSなどさまざまな環境で利用できますが、ここではサーバー用途でよく利用されるUbuntuを使用します。
Ubuntuは、Linuxディストリビューションの一つです。
実際のサーバーを用意する方法のほか、VirtualBoxなどの仮想環境や、クラウド上のUbuntu環境を利用する方法もあります。
今回はUbuntuのターミナルからコマンドを実行できる環境を用意してください。
また、Nginxのインストールや設定ファイルの編集には管理者権限が必要になるため、sudoコマンドを利用できるユーザーを使用します。
Ubuntuとは？初心者向けに特徴・Linuxとの違い・できることを分かりやすく解説
▶
Nginxをインストールする
Ubuntuでは、パッケージ管理システムのAPTを利用してNginxをインストールできます。
まず、以下のコマンドでパッケージ情報を更新します。
sudo apt update続いて、Nginxをインストールします。
sudo apt install nginxインストールの確認が表示された場合は、内容を確認して「Y」を入力します。
インストールが完了したら、以下のコマンドでNginxのバージョンを確認してみましょう。
nginx -v「nginx version: nginx/〜」のようにバージョン番号が表示されれば、Nginxは正常にインストールされています。
表示されるバージョンは、Ubuntuのバージョンによって異なります。
この手順は、Ubuntu Server公式ドキュメントのNginxインストール手順でも紹介されています。
Nginxの起動状態を確認する
Ubuntuでは、Nginxをインストールするとサービスとして登録され、通常はインストール後に自動的に起動します。
現在の起動状態は、次のコマンドで確認できます。
sudo systemctl status nginx「active (running)」と表示されていれば、Nginxが起動している状態です。
表示を終了するときは「q」キーを押します。
Nginxが起動していない場合は、次のコマンドで起動できます。
sudo systemctl start nginxまた、サーバーを再起動したときにNginxも自動で起動するようにしたい場合は、次のコマンドで自動起動を有効にしておきます。
sudo systemctl enable nginxブラウザで初期ページを表示する
Nginxが起動したら、Webブラウザからアクセスしてみましょう。
Ubuntuをローカル環境で動かしている場合は「localhost」、サーバーやクラウド上で動かしている場合は「サーバーのIPアドレス」を指定します。
http://localhost/
http://サーバーのIPアドレス/「Welcome to nginx!」と書かれたNginxの初期ページが表示されれば、Nginxが正常に動作しています。
ブラウザを使えないサーバー環境の場合は、curlコマンドで確認することもできます。
実行結果に「Welcome to nginx!」を含むHTMLが表示されれば問題ありません。
curl http://localhost/サーバー内では表示できるのに外部のPCからアクセスできない場合は、ファイアウォールで80番ポートが閉じている可能性があります。
Ubuntuのファイアウォール（ufw）を有効にしている場合は、次のコマンドでHTTP通信を許可します。
クラウドサーバーを利用している場合は、サービス側のセキュリティグループなどの設定も確認してください。
sudo ufw allow 'Nginx HTTP'Nginxの起動・停止・再起動に使うコマンド
Nginxを操作する際によく使うコマンドは次のとおりです。
必要なコマンドの行だけをコピーして実行してください。
# 起動
sudo systemctl start nginx
# 停止
sudo systemctl stop nginx
# 再起動（Nginxを停止してから起動し直す）
sudo systemctl restart nginx
# 設定の再読み込み（Nginxを止めずに設定を反映する）
sudo systemctl reload nginx
# 状態の確認
sudo systemctl status nginxrestartはNginxを一度停止するため、その間はWebサイトにアクセスできなくなります。
設定ファイルを変更しただけであれば、Nginxを止めずに設定を反映できるreloadを使うのが基本です。
自分で作成した静的ページを公開する
Nginxの初期ページが表示できたら、今度は自分で作成したHTMLファイルを表示してみましょう。
UbuntuのNginxでは、標準設定の場合、Webページのファイルは/var/www/htmlディレクトリに配置します。
先ほど表示された初期ページは、このディレクトリにある「index.nginx-debian.html」というファイルです。
Ubuntuの標準設定では、同じディレクトリに「index.html」があればそちらが優先して表示されるため、今回はindex.htmlを新しく作成します。
/var/www/htmlは管理者権限が必要なディレクトリのため、sudoを付けてテキストエディタ（nano）を起動します。
sudo nano /var/www/html/index.htmlファイルに次のようなHTMLを記述します。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>Nginx Sample</title>
</head>
<body>
<h1>Nginxで公開したページ</h1>
<p>このページはNginxから配信しています。</p>
</body>
</html>入力が終わったら、「Ctrl + O」→「Enter」で保存し、「Ctrl + X」でnanoを終了します。
その後、ブラウザで先ほどのURL（http://localhost/ など）を再読み込みします。
Nginxの初期ページではなく、作成したHTMLが表示されれば成功です。
表示が切り替わらない場合は、ブラウザのキャッシュが残っている可能性があるため、強制再読み込みを試してみてください。
Nginxの設定ファイルを理解する
設定ファイルの場所と構成
Nginxのメイン設定ファイルは、Ubuntuの場合は次の場所にあります。
/etc/nginx/nginx.confnginx.confは、Nginx全体の基本設定を記述するファイルです。
ただし、Ubuntuでは個々のWebサイトの設定をnginx.confに直接書くのではなく、別のファイルに分けて管理するのが一般的です。
- /etc/nginx/nginx.conf：Nginx全体の基本設定
- /etc/nginx/sites-available/：サイトごとの設定ファイルを置くディレクトリ
- /etc/nginx/sites-enabled/：有効にするサイトの設定（sites-availableのファイルへのシンボリックリンク）を置くディレクトリ
- /etc/nginx/conf.d/：追加の設定ファイルを置くディレクトリ
nginx.confの中には、sites-enabledやconf.dにあるファイルを読み込む設定（includeディレクティブ）が書かれています。
先ほど初期ページや自作のHTMLを表示していたのも、「/etc/nginx/sites-available/default」に書かれた設定によるものです。
つまりUbuntuでは、サイトの設定をsites-availableに作成し、sites-enabledにリンクを作って有効化するという流れで設定を追加します。
この構成はUbuntu Server公式ドキュメントのNginx設定ガイドでも紹介されています。
なお、nginx.orgの公式パッケージなど、環境によってはsites-available／sites-enabledがなく、conf.dに設定ファイルを置く構成になっている場合もあります。
ディレクティブ・ブロック・コンテキストの関係
Nginxの設定は、「ディレクティブ」と呼ばれる設定項目を組み合わせて記述します。
ディレクティブには、次の2種類があります。
- シンプルディレクティブ：名前と値を書き、最後を「;」で終えるもの（例：listen 80;）
- ブロックディレクティブ：「{ }」で囲んだ中に、ほかのディレクティブを記述できるもの（例：server { … }）
Nginxの公式ドキュメントでは、中にほかのディレクティブを書けるブロックディレクティブのことを「コンテキスト」と呼んでいます。
つまり、server { }は「serverディレクティブで作るブロック」であり、その中に書いたディレクティブが適用される範囲（コンテキスト）でもあります。
例えば、次のような設定があるとします。
server {
listen 80;
server_name example.com;
location / {
root /var/www/example;
}
}コンテキストは入れ子構造になっており、どのブロックにも含まれない最上位の「main」の中に「http」、httpの中に「server」、serverの中に「location」が入ります。
ディレクティブごとに記述できるコンテキストが決まっており、例えばlistenはserverの中にしか書けません。
どのディレクティブを、どのブロックの中に書くかを意識すると、設定ファイルが読みやすくなります。
serverブロックとlocationブロックの役割
serverブロックは、1つのWebサイト（Nginx公式ドキュメントでは「バーチャルサーバー」）の設定をまとめるブロックです。
serverブロックの中でよく使う基本的なディレクティブは次のとおりです。
| ディレクティブ | 意味 | 記述例 |
|---|---|---|
| listen | 待ち受けるポート番号 | listen 80; |
| server_name | このserverブロックが担当するドメイン名 | server_name example.com; |
| root | 公開するファイルを置くディレクトリ | root /var/www/example; |
| index | URLでファイル名が省略されたときに返すファイル | index index.html; |
locationブロックは、アクセスされたURLのパスに応じて処理を切り替えるためのブロックです。
「location /」はすべてのパスに一致し、「location /images/」のように書くと、/images/から始まるパスだけに別の設定を適用できます。
複数のlocationに一致する場合は、基本的に最も長く一致したものが使われます。
なお、上の例ではrootをlocationの中に書いていますが、serverブロックの直下に書けば、そのサーバー全体に同じ設定が適用されます。
設定変更後：構文チェックとreload
Nginxの設定ファイルを変更した場合、いきなり設定を反映するのではなく、まず構文に問題がないか確認することが重要です。
設定ファイルに記述ミスがあるとNginxの起動や再起動に失敗し、Webサイトが表示されなくなる可能性があります。
設定を変更するときは、必ず次の順番で作業しましょう。
- 設定ファイルを編集する
- sudo nginx -t で構文をチェックする
- 問題がなければ sudo systemctl reload nginx で反映する
設定ファイルの構文を確認する際は、以下のコマンドを使用します。
sudo nginx -t設定内容に問題がなければ、次のようなメッセージが表示されます。
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful「syntax is ok」「test is successful」と表示されれば、構文チェックは成功です。
問題がある場合はエラーが発生したファイル名や行番号が表示されるため、その内容を確認して修正し、再度コマンドを実行しましょう。
構文チェックが成功したら、以下のコマンドで設定を再読み込みして反映します。
sudo systemctl reload nginx「sudo nginx -s reload」でも同じように設定を再読み込みできますが、Ubuntuのようにsystemdでサービスを管理している環境では、起動・停止と同じくsystemctlで操作したほうが管理方法を統一できます。
nginxのコマンドラインオプションは公式ドキュメントで確認できます。
なお、reload時に新しい設定に問題があった場合、Nginxは古い設定のまま動作を続けます。
ただし、反映したつもりの設定が実際には反映されていないことに気付きにくいため、reloadの前にnginx -tで確認する習慣を付けておきましょう。
【応用】バーチャルホスト・リバースプロキシを設定する
バーチャルホストで複数サイトを運用する
バーチャルホストとは、一つのサーバー上で複数のWebサイトを運用する仕組みです。
Nginxでは、ドメインごとにserverブロックを用意することで、アクセスされたドメインに応じて異なるWebページを返すことができます。
ここでは、example.comとexample.netという2つのサイトを運用する例で手順を紹介します。
まず、サイトのファイルを置くディレクトリを作成し、先ほどと同じ要領でindex.htmlを作成します。
sudo mkdir -p /var/www/example.comsudo nano /var/www/example.com/index.html次に、sites-availableにサイト用の設定ファイルを作成します。
sudo nano /etc/nginx/sites-available/example.comファイルには、次のようにserverブロックを記述します。
server {
listen 80;
server_name example.com;
root /var/www/example.com;
index index.html;
}作成した設定ファイルを有効にするため、sites-enabledにシンボリックリンクを作成します。
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/もう一つのサイトも、同じ手順でディレクトリとHTMLファイル、設定ファイル（/etc/nginx/sites-available/example.net）を作成し、シンボリックリンクで有効化します。
設定ファイルの内容は次のとおりです。
server {
listen 80;
server_name example.net;
root /var/www/example.net;
index index.html;
}最後に、前述の手順で「sudo nginx -t」による構文チェックを行い、「sudo systemctl reload nginx」で設定を反映します。
これで、example.comへアクセスすると/var/www/example.comにあるページを、example.netへアクセスすると/var/www/example.netにあるページを表示する構成になります。
Nginxは、リクエストに含まれるドメイン名（Hostヘッダー）とserver_nameを照合して、どのserverブロックで処理するかを決めています。
記事中のドメインは説明用のものです。
実際のドメインを使わずに動作を確認したい場合は、curlコマンドでHostヘッダーを指定してアクセスすると、指定したドメイン用のページが返ってくることを確認できます。
curl -H "Host: example.com" http://localhost/なお、どのserver_nameにも一致しないアクセスは、そのポートの「デフォルトサーバー」が処理します。
Ubuntuの標準設定では、/etc/nginx/sites-available/defaultのserverブロックがデフォルトサーバーに指定されています。
サーバーの選ばれ方の詳細は、Nginx公式ドキュメントのリクエスト処理の解説で確認できます。
リバースプロキシでバックエンドアプリと連携する
Nginxは、HTMLや画像などを直接配信するだけでなく、別のアプリケーションへリクエストを転送する「リバースプロキシ」としても利用できます。
リバースプロキシとは、クライアントからのリクエストをいったんNginxが受け取り、裏側のアプリケーションへ転送して、その応答をクライアントへ返す仕組みです。
例えば、Node.jsやPythonなどで作成したWebアプリケーションが、サーバー内部のlocalhost:3000で動作しているとします。
この場合、ユーザーからのアクセスをNginxが受け取り、アプリケーションへ転送する構成にできます。
リバースプロキシとしてNginxを利用する際は、proxy_passディレクティブを設定します。
最低限の設定例は次のとおりです。
バーチャルホストと同じ手順で、sites-availableに設定ファイル（例：/etc/nginx/sites-available/app.example.com）を作成して有効化してください。
server {
listen 80;
server_name app.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
}
}この設定では、ブラウザからNginxへ送られたリクエストを、127.0.0.1:3000で動作しているアプリケーションへ転送します。
proxy_passのようにURLのパス部分を書かない場合、例えば「/api/users」へのリクエストはそのまま「http://127.0.0.1:3000/api/users」へ転送されます。
proxy_passの詳しい仕様は、Nginx公式ドキュメントのproxyモジュールで確認できます。
この構成により、外部から直接アプリケーションへアクセスさせるのではなく、Nginxを入口として配置することができます。
Nginxを前段に置くことで、静的ファイルの配信とアプリケーションへのリクエストを分担したり、HTTPS通信の処理をNginx側でまとめて行ったりする構成も可能です。
実際に運用する場合は、次のようにproxy_set_headerディレクティブを追加することがよくあります。
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}最低限の設定のままだと、アプリケーションから見たアクセス元は常にNginx（127.0.0.1）になり、Hostヘッダーもproxy_passに書いたアドレスに置き換わります。
上記の設定を追加すると、元のドメイン名やアクセス元のIPアドレス、HTTP／HTTPSの区別をアプリケーションへ伝えられるようになります。
| 設定 | アプリケーションへ伝える情報 |
|---|---|
| Host | ブラウザがアクセスしたドメイン名 |
| X-Real-IP | アクセス元のIPアドレス |
| X-Forwarded-For | アクセス元から経由してきたIPアドレスの一覧 |
| X-Forwarded-Proto | 元のリクエストがHTTPかHTTPSか |
これらのヘッダーを利用するかどうかは、アプリケーションやフレームワーク側の設定にもよります。
まずは最低限の設定で動作を確認し、必要に応じて追加していくと良いでしょう。
なお、Webサイトを一般公開する場合はHTTPS化がほぼ必須です。
NginxでSSL/TLS証明書を設定すれば、Nginxで暗号化通信を処理し、Nginxとアプリケーションの間はHTTPで通信する構成にできます。
証明書の取得・設定は使用する認証局や環境によって手順が異なるため、本記事では詳しく扱いません。
よくあるエラーと対処法
Nginxの設定を変更したり、Webサイトを公開したりしていると、設定ミスやファイルの権限などが原因でエラーが発生することがあります。
ここでは、Nginxを使い始めたときに遭遇しやすい代表的なエラーと、その確認方法を紹介します。
まずはエラーログを確認する
Nginxで問題が起きたときは、まずログを確認して原因を特定するのが基本です。
Ubuntuの標準設定では、ログは次の場所に保存されています。
/var/log/nginx/error.log
/var/log/nginx/access.logerror.logにはNginxで発生したエラーの内容が、access.logには「どのURLにアクセスがあり、どのステータスコードを返したか」が記録されます。
エラーログの最新部分は、次のコマンドで確認できます。
sudo tail -n 20 /var/log/nginx/error.logNginxが起動しない
Nginxを起動しようとしても起動できない場合は、まず以下のコマンドでNginxの状態を確認しましょう。
エラーが発生している場合は、ステータスの表示から原因を確認できることがあります。
sudo systemctl status nginx設定ファイルを変更した直後であれば、構文エラーが原因になっている可能性があります。
その場合は、次のコマンドを実行します。
sudo nginx -t設定ファイルの記述に問題がある場合、エラーが発生したファイルや行番号などが表示されるので、修正時の参考にすると良いでしょう。
また、80番ポートをほかのソフトウェア（Apacheなど）がすでに使用していると、Nginxは起動できません。
この場合、エラーログなどに次のようなメッセージが記録されます。
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)どのプログラムがポートを使用しているかは、次のコマンドで確認できます。
プロセス名まで表示するには管理者権限が必要なため、sudoを付けて実行します。
sudo ss -ltnp80番ポートを使用しているプログラムが見つかった場合は、そのプログラムを停止するか、Nginxで使用するポート番号を変更して対応します。
「502 Bad Gateway」が表示される
リバースプロキシを設定している場合に遭遇しやすいのが、「502 Bad Gateway」というエラーです。
これは、Nginxが転送先のアプリケーションから正常な応答を受け取れない場合などに発生します。
バックエンドのアプリケーションが停止していたり、proxy_passに指定したものと異なるポートで動作していたりすると、Nginxから接続することはできません。
このエラーが発生した際は、まずアプリケーションが正常に起動しているか、前述の「sudo ss -ltnp」で待ち受けているポート番号がproxy_passの指定と一致しているかを確認しましょう。
エラーログには、Nginxが転送先へ接続できなかった理由が記録されます。
例えば、転送先のアプリケーションが起動していない場合は、次のようなメッセージが記録されます。
connect() failed (111: Connection refused) while connecting to upstream「502 Bad Gateway」が表示されたときは、Nginxの設定だけでなく、転送先のアプリケーションが正常に動作しているかも確認することが重要です。
「403 Forbidden」が表示される
「403 Forbidden」は、サーバーがリクエストを理解したものの、アクセスを許可できない場合に表示されるHTTPステータスコードです。
Nginxで静的ファイルを公開している場合、主に次の2つが原因になります。
- ファイルやディレクトリの権限が不足していて、Nginxが読み取れない
- ディレクトリ内にindexで指定したファイル（index.htmlなど）が存在しない
Ubuntuの標準設定では、Nginxのワーカープロセスは「www-data」というユーザーで動作します。
そのため、公開するファイルにwww-dataからの読み取り権限があり、そこに至るディレクトリにも移動（実行）権限があるかを確認する必要があります。
権限が原因の場合、error.logには「Permission denied」、indexファイルがない場合は「directory index of … is forbidden」といったメッセージが記録されます。
ファイルやディレクトリにどの権限が与えられているかは、「ls -l」コマンドで確認できます。
ls -l /var/www/html/ただし、必要以上の権限を与えてしまうと、セキュリティ上の問題につながる可能性があります。
「chmod 777」のようにすべてのユーザーへ書き込み権限を与えるのではなく、必要な読み取り権限だけを付与するようにしましょう。
【初心者向け】よく使うLinuxコマンド一覧表
▶
Nginxに関するよくある質問
Q. Nginxは無料で使えますか？
A. Nginxはオープンソースソフトウェア（2条項BSDライセンス）として公開されており、無料でダウンロード・利用できます。
なお、F5社からは追加機能やサポートが付いた商用版のNGINX Plusも提供されていますが、学習や一般的なWebサイトの運用であればオープンソース版で十分です。
Q. NginxはWindowsでも使えますか？
A. nginx.orgではWindows版も配布されています。
ただし、Windows版の公式ドキュメントではベータ版扱いとされており、性能や一部機能に制限があります。
本番環境ではLinux上で動かすのが一般的なため、学習の段階からUbuntuなどのLinux環境で試しておくのがおすすめです。
Q. NginxをDockerで動かすことはできますか？
A. できます。
Docker HubではNginxの公式Dockerイメージが公開されており、サーバーに直接インストールしなくても、コンテナとしてNginxを起動できます。
手元のPCで手軽に試したい場合や、アプリケーションと一緒に環境を構築したい場合に便利です。
Docker入門（第1回）｜初心者向けに概要や基本コマンドを解説
▶
まとめ
Nginxは、静的なHTMLや画像などを配信するWebサーバーとしてだけでなく、リバースプロキシやロードバランサーなど、Webシステムのさまざまな場所で利用できるソフトウェアです。
イベント駆動型の仕組みにより多数の接続を効率よく処理でき、設定ファイルを中心としたシンプルな管理方法も特徴です。
Nginxでできることには幅があるため、慣れないうちは静的ページを公開するところから始め、設定ファイルの構造や「nginx -t → reload」の流れを身に付けてから、バーチャルホストやリバースプロキシに挑戦すると良いでしょう。
さらに詳しい設定を知りたい場合は、nginx公式ドキュメントもあわせて確認してみてください。
