前回の記事では、稼働中の WordPress 環境を壊すことなく、
VPS 上の安全な場所に Node.js を導入し、
Next.js の初期システムを構築しました。
今回は、いよいよ新しい Next.js のシステムを
外部のインターネットに公開する設定を行います。
この記事では、 Nginx のリバースプロキシ設定を利用して、
既存の WordPress へのアクセスは守りつつ、
新しいサブドメインへの通信だけを Next.js へと振り分け、
安全に HTTPS 化（暗号化）して起動するまでの手順を解説します。
Web サーバーである Nginx の設定を変更するのは、最初は不安もありましたが、
テストコマンドで確認しながら、この記事の手順で進めていけば、
WordPress の環境を残したまま、Next.js で構築するサイトを外部公開できます。
事前準備：ドメインの A レコード設定
VPS での作業を始める前に、大前提としてドメイン側の設定が必要です。
- ドメインを管理しているサービス（お名前.comなど）の管理画面を開きます。
- 今回新しく使うサブドメイン（例：
next.example.com）のアクセス先を、現在の VPS の IP アドレスに紐づける設定（ A レコードの追加）を行います。
これが完了していないと、どれだけサーバーを設定してもインターネット経由でアクセスすることはできません。完了したら、 VPS の黒い画面（ターミナル）での作業に進みます。
Nginx による振り分け設定（リバースプロキシ）
インターネットから VPS に届いた「新しいサブドメイン宛てのアクセス」を、 WordPress ではなく Next.js へと案内するための「交通整理」のルールを作成します。
1. 設定ファイルの作成
- VPS に SSH 接続し、 Nginx の新しい設定ファイルを作成します。以下のコマンドを実行して、テキストエディタを開きます。
sudo nano /etc/nginx/sites-available/next.example.com.conf- 真っ黒な編集画面が開いたら、以下のルールをコピーして貼り付けます。
（next.example.comの部分はご自身のサブドメインに置き換えてください）
server {
listen 80;
server_name next.example.com;
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}- 貼り付けたら
Ctrl+Oで保存し、Enterで確定後、Ctrl+Xでエディタを終了します。
2. 設定の有効化とテスト
- 作成したルールを Nginx に有効化させるため、ショートカット（シンボリックリンク）を作成します。以下のコマンドを実行します。
sudo ln -s /etc/nginx/sites-available/next.example.com.conf /etc/nginx/sites-enabled/- 続いて、記述したルールに間違いがないかテストを行います。
sudo nginx -t- 画面に
syntax is okおよびtest is successfulと表示されればテストは合格です。 - 最後に、稼働中の WordPress を止めることなく、 Nginx に新しい設定を読み込ませます。
sudo systemctl reload nginxCertbot による HTTPS 化（暗号化）
次に、この新しい通信ルートを安全な HTTPS にするための SSL 証明書を発行します。
1. 証明書の取得コマンドを実行
- 以下のコマンドを実行して、証明書の取得と設定の自動化を試みます。
sudo certbot --nginx -d next.example.com- ここで、画面に赤い文字でエラーが出る場合があります。私も実際に遭遇しましたが、実は心配いりません。
$ sudo certbot --nginx -d next.example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for next.example.com
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/next.example.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/next.example.com/privkey.pem
This certificate expires on 2026-06-25.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
Deploying certificate
Could not install certificate
NEXT STEPS:
- The certificate was saved, but could not be installed (installer: nginx). After fixing the error shown below, try installing it again by running:
certbot install --cert-name next.example.com
Could not automatically find a matching server block for next.example.com. Set the `server_name` directive to use the Nginx installer.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
$【補足】赤字で表示される部分について 実際のターミナル画面では、下から3行目の以下のメッセージが 赤い文字 で表示されます。
Could not automatically find a matching server block for next.example.com. Set the \server_namedirective to use the Nginx installer.
画面上部に Successfully received certificate. とあれば、証明書の取得自体は成功しています。赤いエラーは「 Nginx の設定ファイルへの自動追記に失敗した」というだけなので、手動で追記すれば完璧に動作します。
2. Nginx 設定ファイルの手動更新
- 先ほど作成した Nginx の設定ファイルをもう一度開きます。
sudo nano /etc/nginx/sites-available/next.example.com.conf- 中身をすべて消去し、 SSL 対応かつセキュリティを高めた以下のコードに書き換えます。（ドメイン名はご自身の環境に合わせて変更してください）
- なぜ手動でこの長いコードに書き換えるのかと言うと、アクセスした人の「本当の IP アドレス」や「暗号化通信であること」を、 Nginx から Next.js へ正確に伝えるためです。この設定がないと、後々アクセス解析などを行う際に不都合が生じるため、ここで完璧な状態にしておきます。
server {
listen 80;
server_name next.example.com;
# HTTP通信をHTTPSに自動転送（リダイレクト）する安全設定
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name next.example.com;
# 先ほど取得成功したSSL証明書の場所を指定
ssl_certificate /etc/letsencrypt/live/next.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/next.example.com/privkey.pem;
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
# アクセス元の正確な情報をNext.jsに引き継ぐための設定
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;
}
}- 保存して終了後、再度テストと完全な再起動を行います。
sudo nginx -tsudo systemctl restart nginxNext.js の起動とブラウザでの確認
交通整理と暗号化の準備がすべて整ったので、 Next.js を起動します。
1. 自動更新（ホットリロード）の許可設定
Next.js を起動する前に、外部ドメインからのアクセスで画面の自動更新機能がブロックされないよう、設定ファイルに自分のドメインを許可します。
- Next.js のフォルダ内にある
next.config.tsを開きます。
nano ~/example-blog/next.config.ts- 中身を以下のように書き換えて保存します。
import type { NextConfig } from "next";
const nextConfig: NextConfig = {
// 自動更新（ホットリロード）を許可するドメインを指定
allowedDevOrigins: ['next.example.com'],
};
export default nextConfig;2. 開発用サーバーの起動
- Next.js のフォルダに移動し、起動コマンドを入力します。
cd ~/example-blognpm run devReady in ...と表示されたら、お手元のパソコンのブラウザからhttps://next.example.comへアクセスします。
ブラウザに Next.js の初期画面が表示されれば、ドメイン、 Nginx 、 SSL 、そして Next.js のすべてが完璧に繋がった証拠です。大成功です。
おまけ：「A tree hydrated but…」という赤いエラー画面が出た場合の対処法
ブラウザで確認した際、真っ黒な画面に赤い文字で A tree hydrated but... というエラー画面が出ることがあります。
これはシステムの異常ではなく、ブラウザに入っている拡張機能（ Google アナリティクスをブロックするアドオンなど）が、 Next.js の出力したページの中身を勝手に書き換えてしまうことで発生する「ハイドレーション・ミスマッチ」という警告です。
警告を非表示にするおまじない
このおせっかいな警告を消すには、プログラムファイルを編集します。
- Next.js を
Ctrl+Cで停止させます。 app/layout.tsxを開きます。
nano app/layout.tsx- 下の方にある
<html lang="en">というタグに、suppressHydrationWarningという1単語を追記します。
<html lang="en" suppressHydrationWarning>- 保存して Next.js を再起動すると、あの真っ赤な警告画面は二度と出なくなります。
まとめ
今回は、ドメインの紐づけから Nginx のリバースプロキシ設定、 SSL 証明書の手動追記による HTTPS 化、そして Next.js の起動とエラー対処まで、インフラ構築の最も重要なフェーズを解説しました。
途中でいくつかエラーにも遭遇しましたが、仕組みを理解して対処すれば、無事に安全な Web 環境を構築できることが確認できました。
次回からは、いよいよ Markdown ファイルを使って新しい記事の表示やデザインを作っていく、本格的な Web 制作のフェーズに入ります。
コメント