この記事について
僕はこれまで、DNSもポート番号もファイアウォールも「なんとなく」で乗り切ってきました。
- 「DNS浸透待ち」と言われたら、「そういうものか」で納得
- 「そのポート使われてます」が出たら、適当に別のポートに変更
動けばOK。深くは考えない。それで今まで困らなかった…… んですが 、先日こういうことがありました。
Webアプリを本番公開するときに、なるべく安く最低限のWAFをつけたくてCloudflareを使おうとしたところ、ネームサーバー とか聞いたことはあるけどよくわからない単語が出てきて、そこからDNS、ポート番号、ファイアウォールまで芋づる式にわからないことが出てきました。
これはちゃんと整理しないとマズいと思い、自分なりに調べてまとめたのがこの記事です。目指すレベルは、「聞いたことはある、なんとなく知ってる」から一歩進んで、 「〇〇はこういうものでしょ？」とざっくり説明できる ようになること。全体の流れを掴むのが目標です。
書籍とかでしっかり勉強したほうがいいんじゃない？
と思うかもしれませんが、まずざっくり全体像を掴んでから本を読んだほうが理解がスムーズになると思いますし、ざっくりレベルで知れれば良い方にも役立つ内容になっていると思います。すでに理解している方には物足りない内容かもしれません。
扱っているキーワード
| キーワード | ざっくり一言 |
|---|---|
| DNS | ドメインからIPアドレスへの変換 |
| ポート番号 | サーバー内サービスの部屋番号 |
| ファイアウォール / セキュリティグループ | どの通信を許可するかの門番 |
| プロキシとリバースプロキシ | 通信を中継する仲介役 |
調べていくうちに、これらがリクエストの流れに沿ってつながっていることがわかりました。
1. DNS
Cloudflareを導入するとき、最初にやるのが「ネームサーバーをCloudflareのものに変更してください」という手順。ネームサーバーって何？から始まり、まずDNSの仕組みから調べることにしました。
遭遇するとき
- 「ドメインのDNS設定変更して」
- 「DNSが浸透するまで待って」
-
nslookupやdigコマンドを使えと言われた
一言でいうと
ドメイン名（example.com）をIPアドレス（93.184.216.34）に変換する電話帳のようなもの。
もう少し詳しく
ブラウザはドメイン名だけでは通信できないらしく、まずDNSでIPアドレスを調べるところから始まります。
あなた: 「example.com にアクセスしたい」
ブラウザ → DNSサーバー: 「example.com のIPアドレスは？」
DNSサーバー → ブラウザ: 「93.184.216.34 だよ」
ブラウザ → 93.184.216.34: 「ページをください」（←次はポート番号の出番）
ネームサーバー（NS）って何？
Cloudflareの導入で出てきたのがこれ。調べてみると、 「このドメインのDNS情報は、どのサーバーに聞けばわかるか」を指定するもの でした。
「example.com の情報はどこ？」
→ ネームサーバー:「Cloudflareに聞いて」
→ Cloudflare:「example.com のIPは xxx.xxx.xxx.xxx だよ」
つまりCloudflareにネームサーバーを変更するということは、「ドメインのDNS管理をCloudflareに任せる」ということだったんですね。
よく出てくるレコードタイプ
DNSには用途ごとに「レコード」という設定があります。最初は違いがよくわからなかったので整理。
| レコード | 役割 | 例 |
|---|---|---|
| Aレコード | ドメインを直接IPアドレスに変換 | example.com → 93.184.216.34 |
| CNAMEレコード | ドメインを別のドメインに転送（エイリアス） | www.example.com → example.com |
| MXレコード | メールの送り先を指定 | メール関連の設定で使う |
| TXTレコード | テキスト情報を入れる | 「このドメインは自分のものです」の証明などに使う |
| NSレコード | ネームサーバーの指定 | 上で説明したやつ |
Aは「住所を直接書く」、CNAMEは「あの人と同じ住所です」と書く イメージで理解しました。
「DNS浸透」という誤解
「DNSの変更が浸透するまで24〜48時間かかります」とよく言われますが、調べてみると 「浸透」という仕組み自体が存在しない ことがわかりました。
実際に起きているのは TTL（Time To Live）によるキャッシュの期限切れ です。
あなたがDNSレコードを変更
→ でも世界中のDNSサーバーが古い情報をキャッシュしている
→ キャッシュの期限（TTL）が切れるまで古い情報が使われる
→ TTLが切れたサーバーから順に新しい情報を取得する
TTLを短く設定しておけば（例：300秒 = 5分）、変更は数分で反映されるとのこと。「浸透待ち」じゃなくて「キャッシュ切れ待ち」が正確みたいです。
確認コマンド
# ドメインのIPアドレスを確認
dig example.com
# 特定のDNSサーバーに問い合わせ
dig @8.8.8.8 example.com
# レコードタイプを指定
dig example.com MX
dig example.com TXT
# TTLの確認（SECTIONの数字がTTL秒数）
dig example.com +noall +answer
2. ポート番号
DNSでIPアドレスがわかった。じゃあ次は そのIPの「どのサービス」に接続するか 。それを指定するのがポート番号でした。
遭遇するとき
-
localhost:3000とlocalhost:8080の違いは？ - 「ポート443を開けて」
- 「そのポート、すでに使われてます」エラー
一言でいうと
IPアドレスが「建物の住所」なら、ポート番号は「部屋番号」。
1台のサーバーで複数のサービスを動かすために、ポート番号でどのサービス宛かを区別します。
覚えておくべきポート番号
| ポート | サービス | 備考 |
|---|---|---|
| 22 | SSH | サーバーにリモート接続 |
| 80 | HTTP | 暗号化なし |
| 443 | HTTPS | 暗号化あり。現在の標準 |
| 3000 | 開発サーバー | React, Next.js などのデフォルト |
| 3306 | MySQL | |
| 5432 | PostgreSQL | |
| 6379 | Redis | |
| 8080 | 代替HTTP | Tomcat, 開発用サーバーなど |
| 27017 | MongoDB |
「ポートが使われてます」への対処
# macOS / Linux: 指定ポートを使っているプロセスを確認
lsof -i :3000
# 見つかったプロセスを終了
kill -9 <PID>
3. ファイアウォール / セキュリティグループ
ポート番号がサービスの「部屋番号」だとすると、ファイアウォールは 「どの部屋のドアを開けるか」を決める門番 ということみたいです。AWSのセキュリティグループでポートを開ける作業、今まで言われるがままにやっていたのが少し理解できました。
遭遇するとき
- 「セキュリティグループで443を開けて」
- 「ポート開けたのにアクセスできない」
- 「インバウンドルールを追加して」
一言でいうと
「この通信は通してOK、この通信はブロック」を判断するネットワークの門番。
もう少し詳しく
サーバーにはたくさんのポートがありますが、全部を外部に公開するのは危険です。ファイアウォールで 必要なポートだけを許可 します。
インターネットからの通信
→ ファイアウォール:「443（HTTPS）? OK、通してよし」
→ ファイアウォール:「22（SSH）? 社内IPからだけOK」
→ ファイアウォール:「3306（MySQL）? 外部からはブロック！」
AWSのセキュリティグループ
AWSでは、ファイアウォールの役割を セキュリティグループ が担います。
| ルール | 方向 | 意味 |
|---|---|---|
| インバウンド | 外 → 中 | サーバーに入ってくる通信の許可 |
| アウトバウンド | 中 → 外 | サーバーから出ていく通信の許可 |
覚えておくこと
| 項目 | 内容 |
|---|---|
| 最小権限の原則 | 必要なポートだけ、必要なIPからだけ許可する |
| 全ポート開放（0-65535）は絶対にやらない | 攻撃者にとって格好の標的になる |
| SSH（22番）は社内IPだけに制限する | 全世界に公開すると不正アクセスの試行が殺到する |
| 「つながらない」の原因の半分はセキュリティグループ | まず最初に確認すべきポイント |
「ポート開けたのにつながらない」チェックリスト
調べていて見つけた確認ポイント。次にハマったときのためにメモ。
1. セキュリティグループのインバウンドルールにポートが追加されている？
2. 正しいプロトコル（TCP / UDP）を指定している？
3. ソースIP（接続元）の範囲は正しい？（0.0.0.0/0 = 全世界）
4. サーバー内のアプリケーションがそのポートでリッスンしている？
5. ネットワークACLでブロックされていない？
4. プロキシとリバースプロキシ
DNS、ポート、ファイアウォールときて、次に気になったのがプロキシ。Cloudflareも実はリバースプロキシとして動いているらしく、そもそもリバースプロキシって何だっけ？と思って調べました。
遭遇するとき
- 「Nginxでリバースプロキシ立てて」
- 「プロキシ経由でアクセスして」
- 「ロードバランサーの設定を変更して」
一言でいうと
- プロキシ（フォワードプロキシ） = クライアントの代理。社内からインターネットに出るときの仲介役
- リバースプロキシ = サーバーの代理。インターネットからサーバーに入るときの仲介役
もう少し詳しく
プロキシ（フォワードプロキシ）
社員のPC → プロキシサーバー → インターネット
↑
「社員の代わりにアクセス」
会社や学校で「特定のサイトにアクセスできない」のはプロキシがブロックしているケースが多いです。
リバースプロキシ
インターネット → リバースプロキシ（Nginx等） → アプリサーバー
↑
「サーバーの代わりに応答」
開発で圧倒的によく使うのはこちら。Nginx、Apache、AWS ALBなどがリバースプロキシとして動きます。名前に「リバース」とつくのは、通常のプロキシ（クライアント側）と逆（サーバー側）で動くからだったんですね。
リバースプロキシが必要な理由
調べてみると、ただの中継じゃなくて色々やってくれるみたいです。
| 役割 | 説明 |
|---|---|
| 負荷分散 | 複数のアプリサーバーにリクエストを振り分ける |
| SSL終端 | HTTPS通信の暗号化/復号をここで処理し、アプリサーバーの負荷を減らす |
| 静的ファイル配信 | 画像やCSSはリバースプロキシから直接返す |
| パスベースのルーティング |
/api はバックエンド、/ はフロントエンドに振り分け |
覚えておくこと
| 項目 | 内容 |
|---|---|
| Nginx | 最もよく使われるリバースプロキシ。設定ファイルベースで軽量 |
| AWS ALB | AWSのマネージドなリバースプロキシ（ロードバランサー）。自分で管理不要 |
502 Bad Gateway |
リバースプロキシが背後のアプリサーバーに接続できないときのエラー |
まとめ
| 概念 | 一言まとめ | つながり |
|---|---|---|
| DNS | ドメインをIPに変換する電話帳 | Webアクセスの最初のステップ |
| ポート番号 | サーバー内のサービスを区別する部屋番号 | DNSで得たIPの「何番の部屋」か |
| ファイアウォール | 通信の許可/拒否を判断する門番 | どのポートを開けるか制御 |
| リバースプロキシ | サーバーの代理で通信を中継 | 負荷分散・SSL終端など |
調べる前は「ポートってなに？」「ファイアウォール = セキュリティグループでしょ？」くらいの理解だったんですが、DNS → ポート → ファイアウォール → プロキシという流れで見ると、それぞれの役割と位置づけがはっきりしました。
全部を暗記する必要はないと思いますが、「DNSって何？」と聞かれたときに 「ドメインをIPアドレスに変換する仕組みで、インターネットの電話帳みたいなものだよ」 くらいにざっくり説明できれば、この記事の目標は達成かなと思います。同じように「なんとなく」で済ませてきた方の参考になれば嬉しいです。
セキュリティ編の記事も出しました。
NCDC株式会社( ncdc.co.jp/ )のテックブログです。 主にエンジニアチームのメンバーが投稿します。 募集中のエンジニアのポジションや、採用している技術スタックの紹介などはこちら( github.com/ncdcdev/recruitment )をご覧ください！
Discussion