開発/クラウド連載 · Oracle Cloud無料サーバーを作る第3回

Oracle Cloud無料サーバーに独自ドメインを接続する：DNS Aレコード、Nginxリバースプロキシ、Let's Encryptで無料HTTPS

2026.10.26 公開 · 21分で読めます

ドメインのAレコードをOracleの予約済IPに向け、Nginxのリバースプロキシ設定とCertbotによるLet's Encrypt無料証明書の取得で、HTTPS化と自動更新まで済ませた作業記録です。

この記事で扱う内容

前回見送ったエフェメラルIP → 予約済IPへの切り替え手順

ドメインのネームサーバーをCloudflareに委任し、Aレコード2つ（@、www）を登録

pingではなくnslookupでドメインとIPの紐付け（名前解決）を確認

Nginxにドメイン専用のリバースプロキシ設定ファイルを作成

CertbotでLet’s Encryptの無料証明書を取得し、HTTPS化と自動リダイレクトを適用

systemdタイマーによる自動更新とドライラン（dry-run）検証

証明書発行エラーや502 Bad Gatewayが発生したときのトラブルシューティング

前回、UFWファイアウォール、Swap 4GB、タイムゾーン（JST）まで整えたことで、サーバーは常時起動しておいても不安のない状態になりました。ただ、パブリックIPはエフェメラルIPのままで、予約済IPへの切り替えはドメインを接続するときにまとめて行うことにして見送っていました。アクセスするには相変わらず数字のIPアドレスを打つ必要があり、ブラウザのアドレスバーには「保護されていない通信」と警告が表示されていました。前回の最後では次回をDockerと予告しましたが、Webサービスをデプロイする前にアドレスとSSL/TLS証明書を整えておくほうが順序として自然だと判断し、この記事を先にまとめました。

まずは前回見送った予約済IPへの切り替えを完了させ、Cloudflare上でドメインのAレコードをその予約済IPに向けました。続いてドメイン宛てに届いたリクエストをNginxが内部ポートへ転送するリバースプロキシを設定し、CertbotでLet’s Encryptの証明書を取得してHTTPSを有効化しました。ドメインの登録費用以外に追加料金は一切かからず、証明書の取得からNginxのHTTPS設定・リダイレクトまでCertbotのコマンド1行で完結しました。

ブラウザのリクエストがDNSの名前解決を経て、OCIセキュリティ・リスト、UFW、Nginx（80・443）を通り、サーバー内部の127.0.0.1:8080のアプリに届くまで（概念図）

検証環境

作業日: 2026-10-26

ホームリージョン: Japan East (Tokyo)

OSイメージ: Canonical Ubuntu 24.04

シェイプ: VM.Standard.A1.Flex 2 OCPU / 12GB

Webサーバー: Nginx（第1回でインストール済み）、Certbot（Ubuntuのaptパッケージ）

作業端末: Windows 11 + コマンドプロンプト、Chrome

前回の記事: Oracle Cloud無料サーバーの安定化、エフェメラルIPの正体とUFW・Swap・タイムゾーン設定

01 前回見送った予約済IPへの切り替え

前回確認したとおり、サーバー作成時に自動で付与されたパブリックIPはエフェメラルIPであり、アドレス番号を維持したまま予約済IPへ昇格させる機能は用意されていません。前回は解放の一歩手前で踏みとどまりましたが、DNSのAレコードに登録するIPを確定させる必要があるため、今回の最初の作業として切り替えを行いました。この時点ではまだIPをどこにも登録していなかったため、番号が変わっても実害はないと判断しました。

編集画面までの経路は前回と同じです。

[ナビゲーション・メニュー (≡)] > [コンピュート (Compute)] > [インスタンス (Instances)] > インスタンス名 > [ネットワーキング (Networking)] タブ > [アタッチされたVNIC (Attached VNICs)] > プライマリVNIC > [IP管理 (IP administration)] タブ > IPv4アドレス行の [⋯] > [編集 (Edit)]

手順	編集画面で選んだもの	結果
1	パブリックIPタイプ: パブリックIPなし (No public IP) → 更新	エフェメラルIPが解放され、外部からの接続が切断される
2	もう一度編集 → パブリックIPタイプ: 予約済パブリックIP (Reserved public IP) → 新しい予約済IPを作成 → 更新	新しい番号の予約済IPが割り当てられる

エフェメラルIPのアドレス番号を維持したまま予約済IPに昇格させることはできないため、このタイミングでサーバーのパブリックIPアドレスが別の番号に変更されます。切り替え後、[ネットワーキング] > [IP管理] > [予約済パブリックIP] の一覧に、前回は空だったテーブルに新しい予約済IPが1行追加されていることを確認しました。エフェメラルIPを解放して新規の予約済IPを1つ払い出す構成のため、Always Free枠の「パブリックIPv4アドレス1つまで」の範囲内に収まり、追加料金は一切発生しません。

新しく割り当てられた予約済IPでSSHに接続し直します。同一サーバーであってもIPアドレスが変わったため、初回接続時にホスト鍵確認のプロンプトが再度表示されますが、yes と入力して進めれば問題ありません。

ssh -i <秘密鍵のパス> ubuntu@<新しい予約済IP>

注意：更新を押した瞬間に接続が切断されます

手順1で [更新] をクリックするとその場で現在のパブリックIPが解放されるため、接続中のSSHセッションは即座に切断され、手順2が完了するまで外部からサーバーへアクセスできなくなります。新しく割り当てられた予約済IPは、このあとのDNS Aレコード登録やSSH接続に必要となるため、必ず手元にメモしておきましょう。

02 ネームサーバーをCloudflareに委任してAレコードを登録

今回使用した独自ドメインは韓国のレジストラ（Gabia）で取得したものですが、DNSの管理はCloudflareで行っています。レジストラ側ではネームサーバーにCloudflareを指定（委任）し、実際のDNSレコードはCloudflareのダッシュボード上で一元管理する構成です。作業は大きく2つのステップに分かれます。

ステップ1：レジストラでネームサーバーをCloudflareに変更

まずCloudflareにドメインを追加すると、そのドメイン専用に割り当てられたネームサーバーが2つ提示されます。私のアカウントでは fonzie.ns.cloudflare.com と rachel.ns.cloudflare.com が指定されました。アカウントやドメインごとに値が異なりますので、各自のCloudflare管理画面に表示された値をそのまま使用します。

次にレジストラのドメイン管理画面を開き、対象ドメインのネームサーバー変更メニューに進みます。レジストラ標準のネームサーバーから「指定のネームサーバーを使用する（他社DNS）」へと切り替え、1次・2次の入力欄にCloudflareのネームサーバーをそれぞれ入力します。お名前.com、ムームードメイン、Xserverドメインなど日本の主要レジストラでも設定の流れは全く同じです。私が利用したGabiaでは、変更の確定前にSMSやメールによる所有者認証が必要でした。

項目	設定値
ネームサーバー1	`fonzie.ns.cloudflare.com`
ネームサーバー2	`rachel.ns.cloudflare.com`

ネームサーバーの変更は、全世界のDNSキャッシュに浸透するまで数時間から最大24時間程度かかる場合があります。Cloudflareのダッシュボード上でドメインのステータスが「アクティブ（Active）」に切り替わったことを確認してから次の作業へ進みます。なお、レジストラ側にもDNSレコード設定画面（DNS管理ツールなど）が存在しますが、ネームサーバーをCloudflareに委任した後は、レジストラ側で設定したDNSレコードは一切参照されなくなります。 過去に登録した古いレコードがレジストラ側に残っていても無視されるため、今後のレコード管理はすべてCloudflare上で行います。

ステップ2：CloudflareでAレコードを登録

Cloudflareのダッシュボードで対象ドメインを選択し、次の順に開きます。

[DNS] > [レコード (Records)] > [レコードを追加 (Add record)]

Aレコードは、特定のドメイン名やサブドメインをIPv4アドレスに対応付けるための最も基本的なDNSレコードです。名前（Name）を @ にしたレコードはルートドメイン（<ドメイン>）を指し、www にしたレコードは www.<ドメイン> を指します。のちほどCertbotでSSL証明書を発行する際に両方のドメインをまとめて指定するため、この段階で2つのAレコードを作成しておきます。

項目	レコード1	レコード2
タイプ (Type)	A	A
名前 (Name)	@（保存するとドメイン名で表示）	www
IPv4アドレス	Oracleの予約済パブリックIP	Oracleの予約済パブリックIP
プロキシ状態 (Proxy status)	DNSのみ（グレーの雲）	DNSのみ（グレーの雲）
TTL	自動 (Auto)	自動 (Auto)

IPv4アドレス欄には、01節で新しく割り当てたOracle Cloudの予約済パブリックIPを入力します。ここでエフェメラルIPを指定してしまうと、将来インスタンスを停止・再作成した際にIPが変わり、ドメインが別のアドレスを指してしまうトラブルにつながります。また、Cloudflareでは新規レコードを追加する際、プロキシ状態がデフォルトで「プロキシ済み（Proxied）」（オレンジの雲）に設定されますが、保存する前にトグルをクリックして「DNSのみ（DNS only）」（グレーの雲）に切り替えておきます。

注意：SSL証明書の初期取得時は必ず「グレーの雲（DNSのみ）」にする

プロキシ状態がオレンジの雲（Proxied）のままだと、Let’s EncryptのHTTP-01チャレンジ認証がOracleサーバーではなくCloudflareのエッジプロキシを経由してしまい、証明書の発行検証に失敗する原因になります。オレンジの雲の状態では、ドメインを名前解決した際にOracleのIPではなくCloudflareのIPが返ってきます。初期セットアップで証明書を発行する段階では、必ず「DNSのみ（グレーの雲）」に設定しておきましょう。

03 nslookupでドメインとIPの紐付けを確認

DNSレコードを追加・変更すると、世界中のDNSサーバーへ名前解決の情報が伝播するまでに多少のタイムラグが生じます。新規作成したレコードであれば通常は数分程度で反映されますが、手元のWindows環境からコマンドプロンプトを起動し、2つのドメインが正しくOracleの予約済IPを指しているかを確認しました。

nslookup <ドメイン>
nslookup www.<ドメイン>

権限のない回答:
名前:    <ドメイン>
Address:  203.0.113.10

Address の欄に先ほど設定したOracleの予約済IPが表示されれば、名前解決の紐付けは正常に完了しています。ルートドメインと www の両方で同一のIPが返ってくることを確認しました。

コマンドプロンプトでnslookupを使い、ドメインとwwwを問い合わせた結果。名前の下のAddressにOracleの予約済IPが表示される（IPは伏せています）

当初は手軽に ping で疎通を確認しようと考えていましたが、途中で nslookup による確認へと切り替えました。Oracle Cloudのデフォルトのセキュリティ・リストはICMP（ping）のエコー要求パケットを遮断する設定になっているため、DNSレコードが正常に紐付いていても、pingコマンドは「要求がタイムアウトしました」となって失敗します。 ping実行時にも1行目の角括弧内に解決されたIPは表示されますが、その後のタイムアウト表示が障害のように見えて紛らわしいため、DNSの確認には nslookup（または dig）を使うのが最も確実です。

04 Nginxにドメイン専用の設定ファイルを作る

リバースプロキシ（Reverse Proxy）は、Webサイトの「受付窓口」のような役割を果たします。クライアントがブラウザから https://<ドメイン> へアクセスしてきた際、まずは窓口であるNginxがリクエストを受け取り、サーバー内部で稼働しているバックエンドのWebアプリケーション（例：8080番ポートで動くDockerコンテナなど）へ安全に転送し、受け取ったレスポンスをブラウザへと返します。外部のインターネットには80番および443番ポートのみを公開し、実際のアプリケーションは外部非公開の内部ポートで稼働させられるため、セキュリティと運用の両面で非常に優れた構成です。

サーバーにSSHで接続し、ドメイン専用のバーチャルホスト設定ファイルを新規作成します。

sudo nano /etc/nginx/sites-available/<ドメイン>.conf

エディタに次の内容を貼り付け、<ドメイン> の部分を実際のドメイン名に置き換えます。

server {
    listen 80;
    server_name <ドメイン> www.<ドメイン>;

    location / {
        # サーバー内部のサービスポートへ転送する。次回アプリを8080で起動する予定
        proxy_pass http://127.0.0.1:8080;
        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;
    }
}

proxy_set_header の4行は、クライアントからの元のリクエスト情報（ホスト名、アクセス元IPアドレス、接続プロトコルがHTTPかHTTPSか）をバックエンドのWebアプリへそのまま中継・伝達するための重要な設定です。これらのディレクティブを記述しておかないと、Webアプリ側のアクセスログにはすべてのアクセス元IPが「127.0.0.1」として記録されてしまいます。編集が完了したら Ctrl + O → Enter で保存し、Ctrl + X でnanoを終了します。

nanoで/etc/nginx/sites-available/<ドメイン>.confを開き、listen 80、server_name、proxy_pass http://127.0.0.1:8080とproxy_set_header 4行を入れた画面

当初の下書きでは proxy_pass http://127.0.0.1:80; と記述していましたが、バックエンドアプリが実際に使用する8080番ポートに修正しました。なお、次回アプリをデプロイするまでの間、Nginxのデフォルトウェルカムページを表示させておきたい場合は、location / ブロック内を root /var/www/html; の1行にして静的ファイルを配信させる方法もあります。

注意：proxy_passを80番ポートに設定すると無限ループに陥る

listen 80が指定されたserverブロック内で proxy_pass に 127.0.0.1:80 を指定すると、Nginxが受け取ったリクエストを再び自分自身へと転送し続ける無限ループ（ループバック）が発生します。正常にページが表示されずエラーログだけが肥大化してしまうため、proxy_passには必ず背後で稼働するバックエンドアプリのポート（今回の例では8080）を指定してください。

05 設定の有効化と構文チェック

sites-available ディレクトリ配下に作成した設定ファイルは、sites-enabled ディレクトリ配下にシンボリックリンクを作成して初めてNginxに読み込まれる仕様になっています。シンボリックリンクを作成するとともに、初期状態で配置されていた default のシンボリックリンクを削除しました。default は80番ポートのデフォルトサーバーとして動作しているため、残しておくとIPアドレス直接アクセスなどがそちらに吸い取られ、同じポートに対する設定が競合して混乱の原因になるためです。なお、rm -f で削除するのはリンクのみであり、sites-available/default の実体ファイルは安全に保持されます。

# 1. 設定ファイルを有効化（シンボリックリンクの作成）
sudo ln -s /etc/nginx/sites-available/<ドメイン>.conf /etc/nginx/sites-enabled/

# 2. デフォルト設定のリンクを削除
sudo rm -f /etc/nginx/sites-enabled/default

# 3. Nginxの構文チェック
sudo nginx -t

# 4. 問題なければ設定を再読み込み
sudo systemctl reload nginx

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

nginx -t を実行し、「syntax is ok」と「test is successful」の2行が両方とも出力されたことを確認してから reload を実行します。 設定ファイルの構文にエラーがある状態で再読み込みを行うと、設定の不整合やサーバーの停止を招く恐れがあるため、構文チェックのステップは絶対に省略してはいけません。reload実行後、エラーメッセージが表示されずプロンプトが戻れば適用完了です。

nginx -tの実行結果。syntax is okとtest is successfulの2行が表示され、続けてsystemctl reload nginxを実行した画面

06 Certbotのインストールと証明書の取得

Let’s Encryptは、無料で信頼性の高いSSL/TLSサーバー証明書を発行してくれる非営利の認証局（CA）です。そしてCertbotは、証明書の発行申請から取得・更新までを自動化してくれる公式推奨クライアントです。python3-certbot-nginx プラグインを併せてインストールすることで、Certbotが既存のNginx設定ファイルを自動解析し、HTTPS通信に必要なディレクティブやリダイレクト設定まで一括で書き換えてくれます。証明書の発行プロセスにおいて、Let’s EncryptのサーバーがHTTP（80番ポート）経由でドメインの所有権検証（HTTP-01チャレンジ）を行うため、第1回および第2回でOCIセキュリティ・リストとUFWの双方に80番・443番ポートを開放した状態でコマンドを実行します。

sudo apt update
sudo apt install -y certbot python3-certbot-nginx

sudo certbot --nginx -d <ドメイン> -d www.<ドメイン>

コマンドを実行すると、対話形式で3つの質問が表示されます。

質問	入力内容
Enter email address	アカウント関連の連絡を受け取るメールアドレス
Terms of Service への同意	Y
EFFからのメール受信	N

certbot –nginxの実行直後に、メールアドレス（伏せています）、利用規約への同意Y、EFFメール受信Nを入力する画面

※なお、以前は証明書の有効期限通知を受け取るためにメールアドレスの入力が推奨されていましたが、Let’s Encryptは2025年6月をもって有効期限切れの事前通知メールの送信を終了しています。現在このメールアドレスは、認証局からの緊急連絡やポリシー変更等の重要なお知らせを受け取る用途に限定されています。

質問に回答して数十秒ほど待つと、証明書の発行とNginxへの自動適用が完了します。

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/<ドメイン>/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/<ドメイン>/privkey.pem
This certificate expires on <有効期限>.

Deploying certificate
Successfully deployed certificate for <ドメイン> to /etc/nginx/sites-enabled/<ドメイン>.conf
Successfully deployed certificate for www.<ドメイン> to /etc/nginx/sites-enabled/<ドメイン>.conf
Congratulations! You have successfully enabled HTTPS on https://<ドメイン> and https://www.<ドメイン>

certbotの発行完了画面。Successfully received certificate、証明書の保存先、有効期限、Successfully deployed certificateの2行とCongratulationsの文言

Certbotが設定ファイルをどのように更新したかは、設定ファイルを直接確認すると一目瞭然です。listen 443 ssl やSSL証明書ファイルのパス、そしてHTTP（80番）で届いたリクエストをHTTPS（443番）へと自動転送する301リダイレクト設定が自動追記されており、追記された各行の末尾には # managed by Certbot のコメントが付与されています。

sudo cat /etc/nginx/sites-available/<ドメイン>.conf

ポイント：有効期限通知メール廃止に伴うタイマー監視とドライランの重要性

有効期限の事前通知メールが届かなくなった現在、証明書の自動更新が失敗していてもメール経由で気付くことができません。証明書の発行が完了したら、次節で解説する「systemdタイマーの稼働確認」と「更新ドライランの事前検証」を必ず実施し、更新経路に問題がないことをあらかじめ確認しておくのが必須の運用プラクティスです。

07 自動更新タイマーの確認

Let’s EncryptのSSL/TLS証明書の有効期限は90日間です。aptパッケージからインストールしたCertbotは、OSの起動管理機構であるsystemdに自動更新用のタイマーユニット（certbot.timer）を自動登録してくれます。このタイマーが1日2回の頻度で証明書の状態をバックグラウンドで監視し、有効期限が残り30日未満になると自動的に更新プロセスを実行します。

sudo systemctl status certbot.timer

Active: active (waiting)

Active 行に active (waiting) と表示されていれば、タイマーユニットが正常に常駐し、次回のスケジュール実行時刻を待機している状態です。Trigger 行から次回実行予定時刻（JST）を確認できたら、q キーを押してstatus表示を終了します。

systemctl status certbot.timerの結果。Loaded enabled、Active: active (waiting)、Triggerに次回の実行時刻（JST）

08 更新のドライラン（dry-run）

systemdタイマーが正常に動作していても、実際に更新処理が最後まで完走するかどうかは事前に検証しておく必要があります。--dry-run オプションを指定して実行すると、Let’s Encryptのステージング（検証用）環境と通信し、本番の証明書を上書きすることなく更新プロセス全体を安全にシミュレーションできます。本番のレートリミットを消費することもありません。

sudo certbot renew --dry-run

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/<ドメイン>/fullchain.pem (success)

このメッセージが表示されれば、90日後の本番自動更新時にもDNS名前解決・80番ポート通信・Nginxリロードの全経路が正常にパスすることが保証されます。もしドライランの段階でエラーが出るようであれば、本番更新時にも確実に失敗して証明書が失効してしまうため、原因の早期究明が必要です。

certbot renew –dry-runの結果。Simulating renewalのあとにCongratulations, all simulated renewals succeededとfullchain.pem (success)

09 ブラウザでHTTPS接続を確認

作業端末のChromeを立ち上げ、アドレスバーに https://<ドメイン> を入力してアクセスしました。近年のChromeではアドレスバーの鍵アイコンが「サイト情報を表示（View site information）」アイコン（スライダー調整バーの形状）へと仕様変更されているため、昔のような緑色の鍵マークは表示されません。このアイコンをクリックし、ポップアップメニュー内に「この接続は保護されています」と表示されれば、SSL/TLS暗号化通信が正常に確立されています。また、http://<ドメイン> とHTTPで入力した場合でも、即座にHTTPSアドレスへとリダイレクトされることを確認しました。

メニューから [この接続は保護されています] > [証明書は有効です] とクリックしていくと、証明書ビューアが開きます。発行者（Issued By）に「Let’s Encrypt（共通名 YE2）」、有効期間に発行日から90日後の日付が明記されていることを確認しました。これは、06節でCertbotが取得したLet’s Encryptのサーバー証明書が、ブラウザまで直接届いて正しく機能している動かぬ証拠です。

発行先 (Issued To)   共通名 (CN): <ドメイン>
発行者 (Issued By)   共通名 (CN): YE2
                     組織 (O):    Let's Encrypt
有効期間             2026/09/23 ～ 2026/12/22

ちなみに、当初Cloudflareのエッジプロキシ（オレンジの雲）を有効にしたまま別の検証ドメインでアクセスした際は、証明書ビューアの発行者が「Google Trust Services（WE1）」と表示されました。プロキシが有効化されていると、ブラウザはOracleのサーバーではなくCloudflareのエッジサーバーとSSL接続を行うため、Cloudflare側が代行発行したエッジ証明書が見える仕組みになっています。証明書ビューアの発行者を確認することで、ブラウザがOracle Cloudのサーバーに直接届いているのか、あるいはCloudflareのCDNプロキシを経由しているのかを一目で判別できます。

なお、次回バックエンドアプリをデプロイするまでは、8080番ポートで応答するサービスが存在しないため、ブラウザ画面上には「502 Bad Gateway」と表示されます。これは背後のアプリがまだ起動していないことによる正常な挙動であり、SSL証明書やHTTPS暗号化通信自体は完全に正常動作しています。

Tips：バックエンドアプリなしでWeb表示だけをテストしたい場合

サーバー上で python3 -m http.server 8080 --bind 127.0.0.1 を一時的に実行すると、8080番ポートで簡易Webサーバーが立ち上がります。ブラウザをリロードすると502エラーの代わりにファイル一覧ページが表示され、リバースプロキシが内部サービスへ正常にルーティングできていることを視覚的に確認できます。確認が終わったらターミナル上で Ctrl + C を押して終了します。

10 証明書の取得に失敗したとき、502が出たときの対処法

Certbotによるドメインの所有権認証に失敗した場合、ターミナル上に次のエラーメッセージが出力されます（古いバージョンのCertbotでは Failed authorization procedure と表示されることがあります）。

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:

このエラーが発生する主な原因は次の2点に集約されます。

80番ポートが外部から到達できない: OCIコンソール側の「セキュリティ・リスト（イングレス・ルール）」と、Ubuntuホスト側の「UFW」の両方で、80番および443番ポートが全開放（0.0.0.0/0）されているかを再確認してください。
DNSのAレコードがまだ浸透していない: 03節の手順に従って nslookup を再実行し、設定した予約済IPが正しく返ってくるかを確認してください。設定直後の場合は数分〜十数分ほど時間を置いてから再試行します。また、Cloudflare側でプロキシ状態が「オレンジの雲（Proxied）」になっていないかも必ず確認してください。

注意：連続して認証失敗を繰り返すと発行ロックがかかる

Let’s Encryptでは、同一ドメインに対する認証失敗が1時間に5回発生すると、レートリミット（発行制限）が発動して一定時間新規の発行が完全にブロックされます。原因を修正した後は、いきなり本番コマンドを叩くのではなく、sudo certbot certonly --nginx --dry-run -d <ドメイン> -d www.<ドメイン> を実行してステージング環境で検証が通ることを確認してから、本番発行をやり直すのが安全です。

ドメインへアクセスした際に「502 Bad Gateway」が表示されるのは、証明書やSSLの問題ではなく、Nginxのリバースプロキシ設定（proxy_pass）が転送先として指定している http://127.0.0.1:8080 でサービスが稼働していないことが原因です。サーバーのターミナル上で次のコマンドを実行することで状態を確認できます。

curl -I http://127.0.0.1:8080

Connection refused（接続が拒否されました）と返ってきた場合、8080番ポートで待ち受けているプロセスが何も存在しない状態です。次回、Dockerコンテナを使ってWebアプリケーションを8080番ポートで立ち上げれば、この502エラー画面は自動的に解消され、目的のWebサービスが表示されるようになります。

まとめ

Aレコードは @ と www の2つを予約済IPに向けて登録し、SSL証明書も2つのドメインをまとめて取得しました。

疎通確認はpingではなくnslookupで行います。 Oracle Cloudのデフォルトセキュリティ・リストがICMPエコー要求を遮断するため、pingはタイムアウトで終了します。

最初に記述した proxy_pass 127.0.0.1:80 はNginxが自分自身を呼び出す無限ループ設定になるため、バックエンドアプリ用の8080番ポートへ修正しました。

certbot –nginx コマンド1行で、SSL証明書の発行からNginxのHTTPS設定、HTTP→HTTPSのリダイレクト設定まで自動で完結します。 取得には80番ポートが開放されている必要があります。

有効期限の事前通知メールは廃止されているため、certbot.timer の常駐確認と certbot renew --dry-run で更新経路を事前に検証しておきました。

おわりに

本記事の執筆時点では、まだ実際の90日後の自動更新サイクルを迎えていません。最初の更新タイミングが訪れた際には、/var/log/letsencrypt/ 配下のログや証明書の有効期限の更新結果を確認し、本記事へ追記する予定です。

次回は、いよいよDocker環境のセットアップと、最初のWebアプリケーション（コンテナ）のデプロイを行います。8080番ポートでコンテナを起動し、今回構築したNginxリバースプロキシのバックエンドに紐付けることで、独自ドメインと常時HTTPSに対応したモダンな個人サーバー環境を完成させます。

参考にした情報

#オラクルクラウド
#OCI
#無料サーバー
#Nginx
#HTTPS

連載の記事一覧 · Oracle Cloud無料サーバーを作る

第1回Oracle Cloud無料サーバー、登録からPAYG移行とAmpereインスタンス作成まで
第2回Oracle Cloud無料サーバーの安定化、エフェメラルIPの正体とUFW・Swap・タイムゾーン設定
第3回Oracle Cloud無料サーバーに独自ドメインを接続する：DNS Aレコード、Nginxリバースプロキシ、Let's Encryptで無料HTTPS (この記事)
第4回Oracle Cloud無料サーバーにDockerを導入する：Portainer管理、Uptime KumaのデプロイとサブドメインHTTPS接続

ブログの記事をもっと見る