はじめに
Webサイトやアプリケーションを公開する際に欠かせないのが「Webサーバ」です。
その中でも nginx(エンジンエックス) は、世界中で広く使われている高性能なWebサーバであり、軽量かつ柔軟な設計から個人開発から大規模サービスまで幅広く利用されています。
「nginxって名前は聞いたことがあるけれど、実際に何ができるのか分からない」
「Apacheとはどう違うの?」
「自分のPCで試してみたいけれど、どこから始めればいいのか分からない」
この記事は、そんな方に向けた nginx入門のロードマップ です。
この記事では以下の流れで、基礎から応用まで一通り体験できるように解説していきます。
- nginxの役割と特徴を理解する
- ローカル環境でnginxをインストールして動かす
- 基本的な設定で静的サイトを公開する
- リバースプロキシやロードバランサーとして利用する
- SSL導入や運用のポイントを学ぶ
読み終える頃には「nginxとは何か」「どのように活用できるのか」がイメージできるようになり、次のステップに進むための基礎知識が身につくでしょう。
nginxの基礎知識
Webサーバーとは?
Webサーバーとは、ブラウザなどのクライアントからのリクエスト(例: URLのアクセス)を受け取り、対応するコンテンツを返すソフトウェア のことです。
具体的には以下のような役割を担います。
- 静的コンテンツの配信
HTML・CSS・JavaScript・画像ファイルなどをそのまま返す。 - 動的コンテンツへの橋渡し
PHPやPython、Node.jsなどのアプリケーションで生成されたコンテンツをブラウザに返す。 - セキュリティや通信の制御
HTTPS通信、認証、アクセス制御などもWebサーバーが担うことが多い。

つまり、WebサイトやWebアプリをインターネットに公開する上で欠かせないのがWebサーバーです。
nginxの特徴
nginx(エンジンエックス)は、高性能・軽量 を売りにしたWebサーバです。
特に「イベント駆動型」の仕組みを採用しており、少ないリソースで大量の同時接続を効率的に処理できます。
そのため、アクセスが集中するニュースサイトや大規模サービスでもよく採用されています。
主な特徴は以下のとおりです。
- 高性能:数万以上の同時接続をさばける
- 軽量:メモリ消費が少なく省リソースで動作
- 拡張性:リバースプロキシ、ロードバランサーなど幅広い用途に対応
- 設定の柔軟さ:シンプルな構成ファイルで多様な機能を実現
nginxの主な用途
nginxは単なるWebサーバにとどまらず、さまざまな役割を担うことができます。代表的なものを挙げると次の通りです。
- 静的ファイル配信
- HTML、CSS、JavaScript、画像などを高速に配信できる。
- CDNや静的サイトホスティングにもよく使われる。
- リバースプロキシ
- クライアントからのリクエストをアプリケーションサーバに中継する役割。
- Webアプリの表側に立たせることでセキュリティやキャッシュの向上にもつながる。
- ロードバランサー
- 複数のアプリケーションサーバにリクエストを振り分け、負荷を分散。
- サービスの安定稼働やスケーラビリティ確保に欠かせない。
- APIゲートウェイ
- REST APIやGraphQL APIの入口として利用可能。
- 認証やレート制限を組み合わせることで堅牢なAPI基盤を構築できる。
nginxを実際に動かしてみる
nginxの特徴を理解したら、次は実際に動かしてみましょう。
Dockerを使った実行を紹介します。
Dockerを使った実行
インストールが面倒な場合は、Dockerを使うのが最も簡単です。
docker run -p 8080:80 nginx
これで、ローカル環境のポート8080にnginxコンテナが立ち上がります。
ブラウザから http://localhost:8080
を開くと、同じくWelcomeページが確認できます。
nginxが正しく動いていれば、以下のような「Welcome to nginx!」というページが表示されます。
この画面が出れば、nginxが動作している証拠です。

設定ファイルの場所と基本構造
nginxの挙動は 設定ファイル(nginx.conf
) で制御されています。
公式nginxイメージでは、設定ファイルは次の場所に格納されています。
- メイン設定ファイル
/etc/nginx/nginx.conf
- 仮想ホスト設定(デフォルトサーバー)
/etc/nginx/conf.d/default.conf
- ドキュメントルート(静的ファイルの置き場)
/usr/share/nginx/html
コンテナ内部に入って確認する方法
起動中のnginxコンテナに入って中を確認するには以下を実行します。
# コンテナidは docker ps で調べる
docker exec -it <コンテナID> /bin/bash
その上で、設定ファイルを直接表示することも可能です。
cat /etc/nginx/nginx.conf
設定ファイルの基本構造は以下のようになっています。
events {
# 接続処理に関する設定
}
http {
server {
listen 80; # ポート番号
server_name localhost; # サーバ名
location / {
root /usr/share/nginx/html; # ドキュメントルート
index index.html index.htm; # デフォルトファイル
}
}
}
ここを修正することで、配信するファイルや挙動をカスタマイズできるようになります。
基本設定を学ぶ
nginxを動かせるようになったら、次は 設定ファイルを理解して、自分のページを公開 してみましょう。ここでは代表的な設定項目である serverブロック と locationブロック を中心に解説します。
serverブロックとlocationブロックの基本
nginxの設定ファイル(nginx.conf
やdefault.conf
)では、リクエストをどのように処理するかを serverブロック と locationブロック で定義します。
server {
listen 80; # このサーバーが待ち受けるポート番号
server_name localhost; # ドメイン名やホスト名
location / {
root /usr/share/nginx/html; # ドキュメントルート
index index.html; # デフォルトで返すファイル
}
}
- serverブロック:1つのWebサイトやサービスを表現
- locationブロック:特定のパスに対する処理を指定
静的ファイル配信(root, index)
Webサーバーの基本は「静的ファイルを返す」ことです。
root
: HTMLや画像などを配置するディレクトリを指定index
: デフォルトで返すファイルを指定(例:index.html
)
例:http://localhost/
にアクセスすると、/usr/share/nginx/html/index.html
が返るようになります。
ポート番号を変更する方法
デフォルトでは listen 80;
でHTTPの標準ポートを使いますが、テスト用途で別ポートを利用することもできます。
例:ポート8080で待ち受ける設定
server {
listen 8080;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html;
}
}
この設定を反映後、ブラウザで http://localhost:8080
にアクセスするとページが表示されます。
自作HTMLを公開する流れ
作業ディレクトリを作成
まずは、自作のHTMLを置くためのフォルダを作成します。
mkdir my-nginx-site
cd my-nginx-site
自作HTMLファイルを用意
フォルダ内に index.html
を作成します。
<!DOCTYPE html>
<html>
<head><title>My nginx site</title></head>
<body>
<h1>Hello, nginx with Docker!</h1>
</body>
</html>
保存先は ./index.html
です。
nginxコンテナを起動(ボリュームマウント)
Docker公式イメージではドキュメントルートが /usr/share/nginx/html
なので、そこにホストのHTMLをマウントします。
docker run --name my-nginx -p 8080:80 -v $(pwd):/usr/share/nginx/html nginx
--name my-nginx
: コンテナ名を指定-p 8080:80
: ホストの8080ポート → コンテナの80ポートに割り当て-v $(pwd):/usr/share/nginx/html
: 現在のディレクトリをnginxのドキュメントルートにマウント
ブラウザで確認
ブラウザから以下にアクセスします。
http://localhost:8080
先ほど作成した index.html
の内容が表示されれば成功です 🎉
HTMLを修正する場合
ホスト側(カレントディレクトリ)の index.html
を編集すれば、即座にコンテナからも反映されます。再起動の必要はありません。
リバースプロキシを設定する
リバースプロキシとは?
リバースプロキシとは、クライアント(ブラウザなど)からのリクエストを受け取り、裏側にあるアプリケーションサーバへ中継する仕組み のことです。
ユーザーはあくまで「nginx」にアクセスしているように見えますが、実際の処理はバックエンドアプリが担当します。
利用メリットとしては以下があります。
- バックエンドを外部に直接公開せず、セキュリティを確保できる
- キャッシュや負荷分散を組み込みやすい
- 複数サービスを1つのドメインでまとめられる(例:
/api
,/app
)
proxy_pass の役割と基本書き方
リバースプロキシを実現するのが proxy_pass
ディレクティブ です。
書き方はシンプルで、リクエストを受けたら指定先に転送します。
location /api/ {
proxy_pass http://localhost:3000/;
}
この例では /api/
へのアクセスを、ローカルで動作しているアプリ(http://localhost:3000
)へ転送します。
node.jsで作成してみる
環境作成
ディレクトリ構成
nginx-node-proxy/
├─ docker-compose.yml
├─ nginx/
│ └─ conf.d/
│ └─ default.conf
└─ node/
├─ Dockerfile
├─ package.json
└─ app.js
docker-compose.yml
services:
nginx:
image: nginx:1.27-alpine
container_name: nginx
ports:
- "80:80"
depends_on:
- node
volumes:
- ./nginx/conf.d:/etc/nginx/conf.d:ro
# 静的ファイルを出したい場合は、下の行を有効化して ./public をマウント
# - ./public:/usr/share/nginx/html:ro
networks:
- webnet
node:
build:
context: ./node
container_name: node
expose:
- "3000"
environment:
- NODE_ENV=production
networks:
- webnet
networks:
webnet:
driver: bridge
ポイント
nginx
はconf.d
をマウントして設定反映node
はコンテナ内ポート3000
を expose(同一ネットワーク内の Nginx から到達可)- ホスト公開は Nginx のみ(80番)
nginx/conf.d/default.conf
# 1つの server で / と /api を出し分け
server {
listen 80;
server_name localhost;
# --- 静的配信(必要なければ削除してOK) ---
# root /usr/share/nginx/html;
# index index.html;
# --- /api を Node にプロキシ ---
# 重要:末尾の / の有無でパスの振る舞いが変わります
# proxy_pass http://node:3000/; # (/api/xxx -> /xxx)
# proxy_pass http://node:3000; # (/api/xxx -> /api/xxx)
# ここでは /api を外して転送したいので 末尾スラッシュあり を採用
location /api/ {
proxy_pass http://node: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;
}
# ヘルスチェック用(任意)
location = /healthz {
return 200 'ok';
add_header Content-Type text/plain;
}
# デフォルトは 404 にしたい場合
location / {
return 404;
}
}
末尾スラッシュ挙動(超重要)
proxy_pass http://node:3000/;
(末尾/
あり):
クライアント/api/foo
→ Node 側/foo
に転送(/api
を取り除く)proxy_pass http://node:3000;
(末尾/
なし):
クライアント/api/foo
→ Node 側/api/foo
に転送(/api
を保持)
本サンプルは「/api
を外したい」前提で あり を採用。
node/Dockerfile
FROM node:20-alpine
WORKDIR /app
COPY package.json ./
RUN npm install --omit=dev
COPY app.js ./
EXPOSE 3000
CMD ["node", "app.js"]
node/package.json
{
"name": "api-app",
"version": "1.0.0",
"main": "app.js",
"type": "module",
"scripts": {
"start": "node app.js"
},
"dependencies": {
"express": "^4.19.2"
}
}
node/app.js(最小の Express)
import express from "express";
const app = express();
app.get("/", (_req, res) => {
res.json({ message: "Hello from Node.js via Nginx reverse proxy!" });
});
app.get("/hello", (_req, res) => {
res.send("Hello route!");
});
// CORS が必要なら簡易対応(必要なければ削除)
app.use((_req, res, next) => {
res.setHeader("Access-Control-Allow-Origin", "*");
next();
});
const port = 3000;
app.listen(port, () => {
console.log(`API listening on http://0.0.0.0:${port}`);
});
起動 & 動作確認
起動
docker compose up -d --build
動作確認(ブラウザ or curl)
# /api -> Node の "/"
curl http://localhost/api/
# => {"message":"Hello from Node.js via Nginx reverse proxy!"}
# /api/hello -> Node の "/hello"
curl http://localhost/api/hello
# => Hello route!
# ヘルスチェック
curl http://localhost/healthz
# => ok
ロードバランシング
ロードバランサー設定(複数サーバへの振り分け)
nginxは単なるWebサーバーではなく、ロードバランサーとしても利用できます。
複数のバックエンドサーバーに対してリクエストを振り分けることで、サービスの可用性やパフォーマンスを高められます。
http {
upstream backend {
server node1:3000;
server node2:3000;
}
server {
listen 80;
server_name localhost;
location /api/ {
proxy_pass http://backend/;
}
}
}
upstream
ブロックで複数サーバーを定義proxy_pass
にhttp://backend/
を指定すると、自動で負荷分散される- デフォルトはラウンドロビン方式(順番に振り分け)
オプションで「重み付け」「最小接続数」なども指定できます。
upstream backend {
server node1:3000 weight=3; # 優先的に処理
server node2:3000;
}
運用とチューニングの基本
ログ管理(access.log, error.log)
nginxのログは運用の第一歩です。
- アクセスログ(access.log): クライアントからのリクエスト状況を記録
- エラーログ(error.log): サーバー内部で発生したエラーを記録
http {
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log warn;
}
ログを適切にローテーション・監視することで、トラブルシューティングが容易になります。
キャッシュ設定とパフォーマンス最適化
静的ファイル(CSS・JS・画像)にキャッシュを設定することで、レスポンス速度を改善できます。
location /static/ {
root /usr/share/nginx/html;
expires 30d; # 30日間キャッシュ
add_header Cache-Control "public";
}
キャッシュを活用することで、帯域やサーバー負荷を軽減できます。
gzip圧縮の有効化
レスポンスを圧縮して転送量を削減することで、通信を高速化できます。
http {
gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024; # 1KB以上のレスポンスに適用
}
セキュリティ対策
運用ではセキュリティも重要です。
- 不要なヘッダー削除
server_tokens off; # バージョン情報を隠す
- リクエスト制限(rate limiting)
攻撃や過負荷から守るためにリクエストを制御できます。
http {
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
server {
location /login {
limit_req zone=one burst=5 nodelay;
}
}
}
これにより、ブルートフォース攻撃やDoS攻撃のリスクを軽減できます。
まとめ
本記事では、nginxを基礎から応用まで体験できるロードマップとして解説してきました。
- nginxとは何か
高性能・軽量なイベント駆動型Webサーバーであり、静的サイト配信からリバースプロキシ、ロードバランサー、APIゲートウェイまで幅広く利用できる。 - ローカル環境での実行
Dockerを使えば数分で動かすことができ、「Welcome to nginx!」画面で動作確認できる。 - 基本設定
server
ブロックとlocation
ブロックを理解すれば、静的ファイル配信やポート変更、自作HTMLの公開などが簡単にできる。 - リバースプロキシ
proxy_pass
を使うことで、バックエンド(Node.jsなど)のアプリケーションを/api
経由で公開可能。
Docker Composeを使えば、nginxとアプリを組み合わせた開発環境も手軽に構築できる。 - ロードバランシング
upstream
を定義することで、複数のバックエンドにリクエストを自動振り分け。大規模サービスでのスケールアウトに必須。 - 運用とチューニング
- ログ(access.log / error.log)を適切に管理
- キャッシュ設定でレスポンス高速化
- gzip圧縮で転送効率アップ
- セキュリティ対策(不要なヘッダ削除、リクエスト制限)で堅牢化
nginxは「ただのWebサーバー」ではなく、アプリケーション公開の基盤となる多機能なゲートウェイです。
この記事のロードマップを通じて、nginxの役割や設定の基本を押さえれば、実際のプロジェクトや本番運用に応用できるはずです。
次のステップとしては、SSL/TLSの導入や監視・自動化(certbot, Prometheus/Grafana連携など)に進むことで、さらに実践的な運用知識を身につけられるでしょう。
コメント