ドメインはどのようにVPSを見つけるのか：DNS、HTTPS、リバースプロキシ入門

VPS内部でcurl http://127.0.0.1:3000を実行してHTMLが返ることは、アプリがローカルで正常稼働している証明になります。しかし、一般ユーザーがhttps://example.comでアクセスできるようにするには、ドメイン名、DNS、ネットワークポート、リバースプロキシ、HTTPS暗号化を一本の鎖として繋ぐ必要があります。

これらの用語は同じチュートリアルに頻出しますが、それぞれ解決している問題が異なります。

一、1回のリクエストが流れる完全な経路

ユーザーがブラウザにドメインを入力
  ↓ DNS問い合わせ
サーバーのIPアドレスを取得
  ↓ TCP 443 + TLSハンドシェイク
VPS上のリバースプロキシへ接続
  ↓ 127.0.0.1:3000 へ内部転送
バックエンドアプリがページを返却

各要素の役割と比喩：

DNSはWebページを保存・転送する仕組みではなく、TLS証明書がドメインをサーバーへ「向ける」わけでもありません。各層を個別に設定・検証する必要があります。

二、代表的なDNSレコードの種類

例えば、www.example.comをIPv4アドレスを持つVPSに向けたい場合、通常はAレコードを追加します。

DNSの変更は世界中で瞬時に反映されるわけではありません。各キャッシュDNSサーバーや端末は設定されたTTL（Time to Live）に従ってレコードを保持します。サーバー移転時は事前にTTLを短縮しておくことが重要です。

三、なぜリバースプロキシが必要なのか

1台のVPSで複数のWebサービスを並行稼働させるケースは一般的です：

blog.example.com  → 127.0.0.1:3000
api.example.com   → 127.0.0.1:4000

NginxやCaddy等のリバースプロキシは、公開用の80/443番ポートでリクエストを受け付け、ホストヘッダー（ドメイン名）に応じて適切な内部アプリへ振り分けます。また、TLS終端、アクセスログ記録、データ圧縮、レート制限などの共通処理を一手に担います。

この構成により、各バックエンドアプリが個別にroot特権で低位ポートを開放する必要がなくなります。また切り分けも容易になります：

• まずローカルホストでアプリの動作を確認する；
• 次にリバースプロキシの中継設定を検証する；
• 最後にDNS解決と外部HTTPS通信を確認する。

四、HTTPSが保護する領域

HTTPSはHTTP通信をTLSで暗号化したプロトコルです。正常に機能している場合、以下を提供します：

1. 認証性： 接続先がそのドメインの正規所有者であることを証明する； 2. 機密性： 通信内容が暗号化され、第三者による盗聴を防ぐ； 3. 完全性： 伝送中のデータ改ざんを即座に検知する。

HTTPSは「サイト運営者が信頼できること」を保証するものではなく、アプリの脆弱性を自動的に修復するものでもありません。保護されるのは「通信経路の安全性」です。

Let's Encrypt等の認証局（CA）は、ACMEプロトコルを通じて証明書の発行と自動更新を行います。ドメイン所有権の検証方式には以下があります：

• HTTP-01：Webサーバー上の特定パスにファイルを配置して検証（公開80番ポートへの到達が必要）；
• DNS-01：DNS上にTXTレコードを動的作成して検証（80/443ポートの開放は不要）；
• TLS-ALPN-01：443番ポートの専用TLSハンドシェイクで検証。

標準的なWeb構成ではHTTP-01が多く利用されますが、使用するACMEクライアントがどの検証方式を採用しているかを確認してください。

五、初心者向けのWebサーバー構築フロー

1. VPSローカルでアプリを起動し、意図したローカルアドレス（127.0.0.1等）でのみリッスンさせる； 2. ローカルリクエストでアプリの応答を確認する（curl -I http://127.0.0.1:3000）； 3. 公式リポジトリからリバースプロキシを導入・設定する； 4. リバースプロキシの設定構文を検証してから起動またはリロードする； 5. DNSに正しいレコードを追加し、公開DNSで名前解決を確認する； 6. 必要なポート（HTTP-01検証時は80番ポート必須）がファイアウォールで許可されているか確認する； 7. 信頼できるACMEクライアントでTLS証明書を発行する； 8. 外部端末からHTTPSでアクセスし、証明書、ステータスコード、画面表示を確認する； 9. 証明書の自動更新タイマーが正常にスケジューリングされているか検証する。

六、レイヤー別のトラブルシューティング

ドメインが古いサーバーのIPを引いてしまう

権威DNSレコード、TTL、端末のローカルキャッシュを確認します。リクエストが新サーバーに届いていない段階でWebサーバーを再インストールしてはいけません。

IPv4では繋がるが一部の端末で開けない

誤ったAAAAレコードが登録されていないか確認します。IPv6対応クライアントはIPv6を優先して接続を試行するため、サーバー側のIPv6設定が不完全だとタイムアウトになります。

リバースプロキシが 502 Bad Gateway を返す

フロントエンドはリクエストを受信したが、背後のバックエンドアプリに接続できない状態です。アプリのプロセス、待受アドレス、ポート番号、ローカル応答を確認してください。

ACME証明書の発行に失敗する

エラーログを確認します。HTTP-01の場合は80番ポートへの外部到達性、DNS-01の場合はTXTレコードの反映とAPI権限、TLS-ALPN-01の場合は443番ポートの状態、およびサーバー時刻の同期状態（NTP）を確認します。

HTTPSは動いているがアプリのポートも外部から直接見えてしまう

アプリが0.0.0.0でリッスンしており、FWがそのポートを開放していないか確認します。リバースプロキシ経由のみで運用する場合、アプリは127.0.0.1にバインドさせます。

七、まとめ

ドメイン、DNS、HTTPS、リバースプロキシは排他的な選択肢ではなく、一本のリクエスト処理チェーンを構成する分業関係です。DNSがIPを案内し、ネットワークが443番ポートへパケットを運び、TLSが暗号化通信路を確立し、リバースプロキシが内部アプリへ中継します。

このチェーンに沿って内側から外側へ順に検証していくことが、安定したWeb運用の基盤となります。

よくある質問

IPアドレスだけでドメインがなくてもHTTPSは使えますか？

技術的にはIP証明書も存在しますが、一般的なWebサイト運用ではドメイン名での証明書取得が標準的です。ドメインを用いればサーバー移行時にIP変更の影響を受けません。

DNS事業者のCDNプロキシ（Cloudflare等）を有効にすると何が変わりますか？

クライアントはまずCDNのエッジノードに接続し、エッジがオリジンサーバーへ中継します。キャッシュ、TLS設定、クライアント実IPの取得方法、FWルールに階層が1つ追加されます。

証明書は一度取得すれば放置して大丈夫ですか？

いいえ。短期証明書は自動更新ジョブに依存します。更新タイマーの稼働状況や有効期限のモニタリングが不可欠です。

参考リンク

• IANA：Domain Name Services
• IANA：Protocol Registries
• Let’s Encrypt ドキュメント
• Let’s Encrypt：Challenge Types
• Nginx Documentation：Beginner’s Guide
• Caddy Documentation：Automatic HTTPS