前回までの記事通りに設定を進め、ブラウザからWordPressの管理画面に無事ログインできた方は、今まさに「ついに10G光クロスの壁を突破して、自宅サーバーでWordPressが動いた！」と大きな達成感に包まれているかと思います。
難解なリバースプロキシの設定を乗り越えてログイン画面を拝めた瞬間は、確かに一つの大きなゴールです。
しかし、一息つく前にアドレスバーの左端を少しだけ確認してみてください。おそらくそこには、「保護されていない通信」という警告が表示されているはずです。
それもそのはず、前回の設定はあくまでVPSから自宅サーバーへ通信の「串」を通しただけの、暗号化されていない「HTTP」の状態です。このまま運用を始めてしまえば、管理画面のログインパスワードも、投稿する記事のデータも、すべて暗号化されずにネットワーク上を流れることになってしまいます。自宅サーバーとしての形はできましたが、セキュリティ面ではまだスタートラインにすら立てていません。
真の完成は、ここから通信を完全に暗号化する「常時SSL化（HTTPS化）」を完了させて初めて達成されます。
主要ポート（80/443番）が完全に塞がれている10G回線環境において、一体どうやってエラーを出さずにSSLの鍵を同期させ、安全なWebサイトへと昇格させるのか。
ここからが、本環境における構築の本当の最終決戦です。
📄 ステップ1：中継VPS側でLet’s Encrypt（SSL証明書）を発行する
まずは外部からのすべてのアクセスを受け止める玄関口、中継VPS側のSSL化を行います。
主要ポートが全滅している自宅の10G回線側とは異なり、VPS側は80番も443番も完全にオープンな環境です。そのため、ここでは通常のCertbotによる認証手順で、そのまま公式のSSL証明書を発行することができます。
VPSにログインし、まずはCertbotをインストールします。
sudo apt update
sudo apt install certbot python3-certbot-nginx -yインストールが完了したら、続けて以下のコマンドを実行して証明書の発行手続きを開始します。
sudo certbot --nginx -d test-site.onlineこのコマンドを叩くと、画面上で英語の質問（対話フロー）が始まります。画面の指示に従ってメールアドレスの入力や規約同意の手動操作を進めていく必要があります。初めて実行する環境では必ず以下の流れになるので、表示に合わせて入力を進めてください。
⌨️ 実行時の対話フロー
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices)
(Enter 'c' to cancel): test-user@example.com (←自分のメールアドレスを入力してEnter)
(Enter your email address and press Enter)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.4-April-3-2024.pdf. You must
agree in order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: Y (←「Y」を入力してEnter(Type 'Y' and press Enter))
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing, once your first certificate is successfully issued, to
share your email address with the Electronic Frontier Foundation, a founding
partner of the Let's Encrypt project and the non-profit organization that
develops Certbot? We'd like to send you email about our work encrypting the
web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: N (←お知らせメールが不要なら「N」を入力してEnter)
(Type 'N' and press Enter if you don't want to receive notification emails)
Plugins selected: Authenticator
nginx, Installer
nginx
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for test-site.online
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/test-site.online
Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2 (←2を選択)
(Select option 2)
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/test-site.online
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://test-site.online
You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=test-site.online
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/test-site.online/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/test-site.online/privkey.pem
Your cert will expire on 2026-10-10. To obtain a new or tweaked
version of this certificate in the future, simply run certbot again
with the "certonly" option. To non-interactively renew *all* of
your certificates, run "certbot renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-leこれでVPS側に無事、世界に通用する本物の「鍵」が手に入りました。
📄 ステップ2：自宅サーバー（WordOps）側で「プロトコル同期」を設定する
中継VPS側で無事にHTTPS化が完了しましたが、この段階でドメインにアクセスしても正常にWordPressは表示されません。
なぜなら、外部からは「HTTPS」でアクセスされているのに、VPSから自宅サーバーへ通信が転送される段階で「HTTP（50080番ポート）」に化けているため、WordPress側が「HTTPSのURLのはずなのに、HTTPでリクエストが届いている。不正なアクセス、または存在しないURLだ」と判断して通信を弾いてしまうからです。
この「URLの矛盾による拒絶」を解決するには、自宅側のWordOps（Nginx）とWordPressに対して、「中継VPSから伝言（ヘッダー）が届いたら、それはHTTPS通信として処理しろ」という同期設定を仕込む必要があります。
① WordOpsのNginx設定ファイルにプロキシヘッダーの受け入れを書く
自宅サーバーのUbuntuにログインし、対象ドメインのWordOps用Nginx設定ファイルを開きます。
sudo nano /etc/nginx/sites-available/test-site.onlineファイルを開くと、前回 listen 80; を追記した設定が並んでいます。 ここに、中継VPSからの「元の通信はHTTPSだよ」という伝言板（ヘッダー情報）を受け取るための設定を、server_name のすぐ下に滑り込ませるように追記します。
具体的には、以下のように書き換えてください。
server {
listen 80;
server_name test-site.online www.test-site.online;
# 🛠️ ★ここから追記★ --------------------------------------
# 中継VPSからのプロトコル伝言（ヘッダー）を正しく受け取る設定
# 🛠️ ★ Add below ★ --------------------------------------
# Settings to correctly process protocol headers forwarded from the relay VPS
set_real_ip_from 118.27.203.45; #（VPSのグローバルIPアドレスを記述）
# (Enter your VPS public IP address)
real_ip_header X-Forwarded-For;
# 通信がHTTPSであることをWordOpsの内部（WordPress）に引き継ぐ
# Pass the HTTPS protocol status down to WordOps / WordPress
proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
# 🛠️ ★ここまで追記★ --------------------------------------
# 🛠️ ★ End of addition ★ ----------------------------------
access_log /var/log/nginx/test-site.online.access.log rt_cache;
error_log /var/log/nginx/test-site.online.error.log;
root /var/www/test-site.online/htdocs;
index index.php index.html index.htm;
include common/php83.conf;
include common/wpcommon-php83.conf;
include common/locations-wo.conf;
include /var/www/test-site.online/conf/nginx/*.conf;
}ファイルを保存（Ctrl + O → Enter）し、nanoエディタを終了（Ctrl + X）したら、絶対にそのまま放置してはいけません。
新しく追記したコードにセミコロン（;）の付け忘れやスペルミスがないか、Nginxの構文チェックコマンドを叩いて確認します。
sudo nginx -tコマンドを実行し、画面に以下の2行が表示されれば設定は完璧（構文エラーなし）です。
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful無事にテストが成功したことを確認したら、設定をシステムに反映させるためにNginxを再起動（restart）します。
sudo systemctl restart nginxこれで、自宅サーバー側のNginxが中継VPSからの「HTTPS伝言」を受け止める準備が100%整いました。
② wp-config.php に「HTTPS認識」の強制コードを仕込む（レイアウト崩壊を直す決定打）
自宅側のNginxを再起動したこの段階で一度サイト（https://test-site.online）へアクセスしてみると、アドレスバーに「鍵マーク」は付くものの、デザイン（CSS）が完全に崩壊して大破したサイトが表示されるはずです。
これは、外側（VPS）はHTTPSなのに、内側（自宅WordPress）がまだHTTPのままで通信しているため、ブラウザが「危険な混在コンテンツ（Mixed Content）」としてCSSの読み込みを強制ブロックしてしまうのが原因です。
このレイアウト崩壊を物理的にねじ伏せるため、WordPressの根本である wp-config.php を書き換えます。
自宅サーバー側で、WordPressの設定ファイルを開きます。
sudo nano /var/www/test-site.online/wp-config.phpファイルを開いたら、一番上の <?php のすぐ下の行（他のコードが始まる前）に、以下のコードをそのまま貼り付けてください。
/**
* VPS中継リバースプロキシ環境でのHTTPS完全同期設定（混在コンテンツ・レイアウト崩壊の解消）
* Full HTTPS Synchronization in a VPS Reverse Proxy Setup (Fixes Mixed Content & Broken Layouts)
*/
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}なぜこれで直るのか？（技術解説）
この数行のPHPコードが命綱です。「中継VPSから届いた伝言（HTTP_X_FORWARDED_PROTO）が https だったら、WordPress内部の環境変数（$_SERVER['HTTPS']）を強制的に on にする」という処理を行っています。
これによって、自宅サーバー自体はHTTPポート（50080）で通信を受け取っているにもかかわらず、WordPressは「なるほど、表向きはちゃんとHTTPSでアクセスされてるんだな！」と完璧に錯覚します。
結果として、WordPressが書き出すCSSや画像のURLがすべて自動的に「https://~」へと修正され、ブラウザのブロックが解除されて一瞬で元の綺麗なデザインに戻ります。
貼り付けたら、ファイルを保存（Ctrl + O ➔ Enter）し、nanoエディタを終了（Ctrl + X）します。
最後に、WordOpsのコマンドで全体の再読み込みを行います。
wo stack reload --nginx📄 ステップ3：ブラウザで最終チェック！「この接続は保護されています」のステータスを拝む
すべての設定ファイルを書き換え、Nginxの再起動とリロードが完了したら、いよいよお楽しみの動作確認です。 スマホやPCのブラウザ（ChromeやSafariなど）を開き、自分のドメインへアクセスしてみましょう。
https://test-site.online🔒 アドレスバーのアイコン（安全な接続）を確認する
アクセスした瞬間、先ほどまで発生していたレイアウトの崩壊が嘘のように消え去り、元の綺麗なデザインのWordPressサイトが表示されるはずです。
ブラウザのアドレスバーの左端にある、サイト設定を表す「チューナーマーク（スライダーのような2本の線のアイコン）」をクリックしてみてください。
ポップアップの上部に「この接続は保護されています」と表示されていれば、あなたの自宅サーバーが完全に見事なHTTPS化を果たした証拠です！おめでとうございます！✧*｡٩(ˊωˋ*)و✧*｡
まとめ
これで表向きの常時SSL化は一通り完了し、安全に外部からアクセスできる状態になりました。
しかし、実は「玄関（VPS）はHTTPS、中身（自宅）はHTTP」という構成のままWordPressを運用し始めると、いくつかの機能においてシステム内部で矛盾が生じ、正常に動作しない不具合が発生する原因になります。
自宅サーバー自体がHTTP（ポート80）のままで動いていると、WordPress内部で行われるローカル通信（ループバック通信）でどのような問題が起きるのか。そして、ポートが全滅している自宅環境において、この矛盾を根本からどうやってクリアするのか。
次回、『主要ポート全滅の10G回線で自宅サーバーを安全に「常時SSL化」する方法（後編） 〜内側のSSL化編〜』にて、その解決アプローチを詳しく解説します。
次の記事は2026年7月27日公開です。
最後まで読んでいただきありがとうございました！次回、後編でお会いしましょう！
コメント