前編の設定により、中継VPSを玄関口としてSSL化し、プロキシヘッダーを自宅サーバーに引き継ぐことで、ブラウザから無事に「保護された通信（HTTPS）」でWordPressにアクセスできるようになりました。
これで一件落着……と言いたいところですが、実はこの「外側（VPS）はHTTPS（ポート443）、内側（自宅）はHTTP（ポート80）」という歪なネットワーク構成のまま運用を始めると、WordPressがシステム内部で深刻な拒絶反応を起こし始めます。
🚨 怪奇現象：「完全に削除」を押すとトップページへ強制送還される
一見、サイトの閲覧やダッシュボードの移動は問題なく動いているように見えます。しかし、いざ本格的に運用を始めると、以下のようなインフラのねじれ特有の不気味なエラーに直面します。
- 記事やメディアを「完全に削除」しようとすると、処理が拒絶されてフロント（トップページ）に飛ばされる
- プラグインを無効化・削除しようとすると、白い画面になったりダッシュボードから叩き出される
「データベースが壊れたのか？」「プラグインのバグか？」と疑いたくなりますが、原因はWordPressが持つセキュリティ機能「Nonce（ナンス：使い捨てトークン）」の検証エラーです。
WordPressは重要な操作を行う際、現在のアクセスが「HTTP」なのか「HTTPS」なのかを厳格にチェックしています。今回の環境では、ブラウザ（管理者）側はVPSがSSL化されているため https://... で操作していますが、自宅サーバーに届くパケットはHTTP（80番）に変換されているため、WordPressの内部システムは「俺はHTTPのサイトだ」と思い込んでいます。
このプロトコルの不一致を検知したWordPressは「URLの改ざん、または第三者による通信ハイジャック（CSRF攻撃）の危険あり」と大誤認を起こし、安全のために処理を強制遮断した上で、管理者をトップページへと叩き出すのです。
この矛盾をクリアし、WordPressを100%正常に動かすためには、自宅の着地サーバーでも「ポート443」かつ「信頼された本物のSSL証明書」を通して、内外の通信プロトコルを完全に統一しなければなりません。
🚀 Certbotインストール
まず自宅サーバー側にCertbotをインストールします。
インストール手順は前回の記事でVPS側にインストールした手順と同じです。
🧱 王道の「HTTP-01チャレンジ」を自宅から叩く
「自宅サーバーの内側もSSL化すればいいんだな？よし、じゃあいつものようにWeb認証（HTTP-01）でサクッと証明書を取ろう！」
そう考えて、自宅サーバー側で一般的なコマンドを叩くとどうなるでしょう。例えば、以下のようなお馴染みのCertbotコマンドを実行してみます。
# 自宅サーバー側でHTTP-01認証を試みるコマンド
sudo certbot certonly --webroot -w /var/www/test-site.online/htdocs -d test-site.onlineすると概ねこうなります。画面には無慈悲な「404エラー」が叩きつけられます。
実際のCertbot失敗ログ（1回目の404エラー）
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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.8-July-06-2026.pdf. You must agree in
order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
Account registered.
Requesting a certificate for test-site.online
Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: test-site.online
Type: unauthorized
Detail: 118.27.203.45: Invalid response from https://test-site.online/.well-known/acme-challenge/soOeYBG6Mo57NCsvHqCiOCxpBij0iVwnL5my8wJGvHI: 404
Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.
Some challenges have failed.
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.「あれ？404？URLは自宅側 http:// なのに……」
そう、ここに最初の絶望があります。 認証局（Let’s Encrypt）は、仕様として最初は必ず http://（ポート80） を狙ってドメインに通信を叩き込んできます。自宅側のCertbotも、コマンドで指定された通り「ポート80のドキュメントルート」に検証ファイルを置いて待機しています。
しかし、前編で構築したVPS側の設定では、外に向けて開いている表玄関は「ポート443（HTTPS）」のみ。
認証局が80番（HTTP）を叩きにきているのに、VPS側の待ち受けが443番になっているため、当然そんな場所に検証ファイルは見つかりません。結果として「ファイルが見つからない（404）」と正常に突っぱねられて爆死するのです。
🛠️ VPSにポート80の待ち受けを「追記」してみる
「じゃあ、VPS側に臨時でポート80番の待ち受けを作って、ACME認証の通信だけ自宅のHTTPポートへストレートにスルーさせれば突破できるのでは？」と、VPS側の設定変更を試みます。
VPS側は認証を取った時点でポート80番の記述がコメントアウトで無効化されています。そこで、以下のようにLet’s Encryptの認証通信（/.well-known/acme-challenge/）だけを狙い撃ちして、ポート80のまま自宅のHTTPポートへ流すためのブロックを「追記」し、意地でもHTTPのまま自宅へねじ込もうとしてみます。
# 🛠️ VPS側へポート80の待ち受けとACME専用ルートを「追記」する
server {
listen 80;
server_name test-site.online;
# 💡ここを追記！認証通信だけを自宅のHTTPポートへストレートにスルーさせる
location ^~ /.well-known/acme-challenge/ {
proxy_pass http://153.156.79.69:50080; # 自宅のHTTP受付ポート
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;
}
# それ以外の通常アクセスは404で弾くかHTTPSへ
location / {
return 404;
}
}VPSのNginxを再起動し、「これで80番の門も開けたし、今度こそ通信が通るはずだ！」と意気揚々と再度Certbotを叩きます。しかし、結果は非情にも再び「404 Not Found」を突きつけられて完全に行き詰まります。
実際のCertbot失敗ログ（2回目の404エラー）
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for test-site.online
Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: test-site.online
Type: unauthorized
Detail: 118.27.203.45: Invalid response from http://test-site.online/.well-known/acme-challenge/kUhqHtSEtr6QFQ7iEUrLQPxJRk_LzCNPSO3iO_Akaqk: 404
Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.
Some challenges have failed.
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.「なぜだ！80番ディレクティブを付けたのにまた404！？」と頭を抱えますが、この挙動こそがこの中継インフラにおける最大の物理的限界を証明しています。
「VPS側が80番で待ち受けてパケットを受け付けたところで、実際に中を覗いてもコマンドで用意した一次検証ファイルがVPSの中には存在しないから」です。
当然ですが、Certbotコマンドを実行して一時検証ファイルを生成しているのは「自宅サーバー」のローカルディスク側です。 VPSがポート80番を開けたことで、認証局はDNSレコードの示すIP（VPS）の80番へ正しく到達しますが、そこから自宅の80番ポートへ流れることはなく、VPSの直下にあるファイルを読みに行きます。しかし、アクセスされた肝心の窓口（VPS）側にはそんな検証ファイルは1ミリも存在しません。
結果として、Certbotは実直に「DNSに記述された場所にアクセスはできたけれど、このサーバー内にはそんなファイルはない」と判定し、再び「404」を叩き出すのです。
どれだけVPS側でポート80番の受け皿を泥臭くチューニングしようとしても、「検証ファイルが生成される場所（自宅）」と「認証局がファイルを読みに行く場所（VPS）」が物理的に違うというこのネットワーク構造がある限り、Web通信ベースの認証（HTTP-01）をストレートにパスすることは極めて困難なのです。
🚀 Webポートを一切使わない「DNS-01チャレンジ」
Web通信を中継するHTTP-01がダメなら、どうすればいいのか。 そこで登場するのが、ポートの開け閉めや一時ファイルの配置といったWebの仕組みを「1ミリも使わない」最強の認証方式、DNS-01チャレンジです。
💡 DNS-01チャレンジとは？
HTTP-01が「サーバー内に特定のファイルを置いて実在証明をする」のに対し、DNS-01は「ドメインのDNSレコード（TXTレコード）に、指定された暗号文字列を登録して実在証明をする」という方式です。
認証局（Let’s Encrypt）は、あなたのウェブサーバーにアクセスするのではなく、あなたのドメインを管理しているDNSサーバーに「TXTレコード」を読みに行きます。
- 認証のトリガー：
自宅サーバーでCertbotを叩く - 実在証明の場所：
お使いのDNSサービス（お名前.comやConoHa DNSなど）のコントロールパネル（またはAPI） - 検証の流れ：
- 自宅サーバーから「証明書をくれ」と要求する。
- 認証局から「じゃあ、DNSのTXTレコードに
_acme-challenge.test-site.onlineという名前で、この暗号値（ランダムな文字列）を登録して」と言われる。 - DNSレコードにその値を書き込む。
- 認証局が世界中のDNSサーバーに向けて「そのレコードはあるか？」とDNS引きを行い、一致すれば合格。
- 一瞬もWebポート（80/443）を使わずに、安全に証明書が発行される！
これなら、10Gクロス回線のポート制限だろうが、VPSとの二重ルーター・中継構成だろうが、一切関係ありません。「ドメインの所有権さえ持っていれば、自宅の中で完結して証明書を発行できる」という、まさに今回の環境における伝家の宝刀なのです。
🛠️ DNS-01チャレンジで証明書を発行する手順
お名前.comでドメイン（test-site.online）を管理している場合、APIによる自動更新プラグインが公式・非公式含め提供されていないため、手動（Manual）モードでDNS-01チャレンジを行います。
手順は驚くほどシンプル。Webのポートなんて一切無視して、お名前.comの管理画面からポチポチッとレコードを足すだけで、自宅サーバーに最強のSSL証明書が降臨します！
🚀 お名前.comで行う「DNS-01チャレンジ」証明書発行手順
お名前.comのDNSレコードに、Certbotが指定する「検証用の暗号テキスト（TXTレコード）」を一時的に登録して証明書を発行します。
ステップ 1：自宅サーバーで手動（manual）コマンドを叩く
自宅サーバー側で、以下のCertbotコマンドを実行します。 （Webサーバーを止めたり、ポートを開け閉めしたりする必要は一切ありません！）
sudo certbot certonly \
--manual \
--preferred-challenges dns-01 \
-d test-site.online \
-d www.test-site.online💡 wwwも同時に取得！-d www.test-site.online も指定しておくことで、サブドメインwwwの証明書も一緒に申請します。
ステップ 2：Certbotから提示される「TXTレコード」をメモする
コマンドを実行すると、ターミナル上で以下のように「このレコードをDNSに登録して！」と一時停止します。
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for test-site.online and www.test-site.online
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name:
_acme-challenge.test-site.online.
with the following value:
Insy1D3pAK6DzR3CQWuzf904yuMCWVON97jQPxwYxaw
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue- ホスト名（名前）：
_acme-challenge - 値（VALUE）：
Insy1D3pAK6DzR3CQWuzf904yuMCWVON97jQPxwYxaw(※画面に表示されたランダムな英数字)
🚨注意：ここでまだ「Enter」キーを押してはいけません！この画面のままキープします。
ステップ 3：お名前.comの管理画面でTXTレコードを登録する
- お名前.com Navi（管理画面）にログインします。
- サイドバーメニューの 「ネームサーバー/DNS」 から、「ドメインDNS設定」 をクリックします。
- 対象ドメイン（
test-site.online）を選択して「次へ進む」をクリックします。 - 「DNSレコード設定を利用する」 の右側にある 「設定する」 ボタンをクリックします。
- 入力画面（レコード追加）にて、以下のように入力します。
| 項目 | 入力・選択内容 |
|---|---|
| ホスト名 | _acme-challenge |
| TYPE | TXTを選択 |
| TTL | 3600（デフォルトのままでOK） |
| VALUE | 画面に表示された Insy1D3pAK6DzR3CQWuzf904yuMCWVON97jQPxwYxaw をそのまま貼り付け |
入力したら 「追加」 ボタンを押し、画面下部の 「確認画面へ進む」➔「設定する」 をクリックして確定させます。
ステップ 4：【10分待機】1つ目の反映を確認して、Enterキーを叩く！
安全のためにおよそ10分ほど待ち、別ターミナル等で以下のコマンドを実行して、登録した暗号値が正しく返ってくるか確認します。※暗号値が返ってくる前にCertbotのTerminalでEnterキーを押すと検証に失敗してしまいます。
# レコードがちゃんと反映されているか確認するコマンド
nslookup -type=TXT _acme-challenge.test-site.online💡 正常に反映された場合の応答
Non-authoritative answer:
_acme-challenge.test-site.online text = "Insy1D3pAK6DzR3CQWuzf904yuMCWVON97jQPxwYxaw"上記のように、お名前.comで設定した1つ目の暗号文字列がピンポイントで返ってくることを確認したら、温めておいたCertbotのターミナルに戻り、満を持して Enterキー を叩きます！
🚨重要：ここでEnterを押すと、1つ目の検証が通り、すかさず以下の「2つ目」の指示が画面に降ってきます。
ステップ 5：2つ目のTXTレコードが表示される（一時停止）
1つ目の認証がその場で通ると、画面が切り替わり、今度は2つ目のwwwドメイン用（www.test-site.online）の検証キーが降ってきて、再び一時停止します。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name:
_acme-challenge.www.test-site.online.
with the following value:
IXEQ-GXIP4hZ6ZwqpcZDuLoZKSm-vW7LKpPaVf-k9ok
(This must be set up in addition to the previous challenges; do not remove,
replace, or undo the previous challenge tasks yet. Note that you might be
asked to create multiple distinct TXT records with the same name. This is
permitted by DNS standards.)
Before continuing, verify the TXT record has been deployed. Depending on the DNS
provider, this may take some time, from a few seconds to multiple minutes. You can
check if it has finished deploying with aid of online tools, such as the Google
Admin Toolbox: https://toolbox.googleapps.com/apps/dig/#TXT/_acme-challenge.www.test-site.online.
Look for one or more bolded line(s) below the line ';ANSWER'. It should show the
value(s) you've just added.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue- ホスト名（名前）：
_acme-challenge.www - 値（VALUE）：
IXEQ-GXIP4hZ6ZwqpcZDuLoZKSm-vW7LKpPaVf-k9ok(※画面に表示されたランダムな英数字)
🚨超重要：ここでもまだ Enterキー を押してはいけません！この画面のままキープしてお名前.comの画面に戻ります。
ステップ 6：お名前.comに「2つ目」のレコードを登録する
- お名前.comの画面に戻ります。（1つ目のレコードは消さずに残したままにします！）
- 以下の内容を新規に追加し、設定を保存（確定）させます。
| 項目 | 入力・選択内容 |
|---|---|
| ホスト名 | _acme-challenge.www |
| TYPE | TXTを選択 |
| TTL | 3600（デフォルトのままでOK） |
| VALUE | 画面に表示された IXEQ-GXIP4hZ6ZwqpcZDuLoZKSm-vW7LKpPaVf-k9ok をそのまま貼り付け |
ステップ 7：【10分待機】2つ目の反映を確認する
2つ目をお名前.comに登録し終えたら、再び安全のためにおよそ10分ほど待ちます。 ホスト名自体が別々になっているため、1つのコマンドで2つの値が同時に返ってくることはありません。必ず、新しく登録した「2つ目のホスト名」をダイレクトに指定して反映を確認します。
# 2つ目の反映確認コマンド（末尾に .www が入ることに注意！）
nslookup -type=TXT _acme-challenge.www.test-site.online💡 正常に反映された場合の応答
Non-authoritative answer:
_acme-challenge.www.test-site.online text = "IXEQ-GXIP4hZ6ZwqpcZDuLoZKSm-vW7LKpPaVf-k9ok"上記のように、2つ目のコマンドに対して2つ目の暗号値がピンポイントで返ってくることを確認したら、Certbotのターミナルに戻り、最後の Enterキー を叩きます！
ステップ 8：完全勝利！証明書の生成と注意点
2つ目の反映を確認してEnterキーを叩くと、ついに画面に完全勝利のログが流れます！
実際のCertbot出力（成功ログ）
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/test-site.online/fullchain.pem
Key is saved at: /etc/letsencrypt/live/test-site.online/privkey.pem
This certificate expires on 2026-10-12.
These files will be updated when the certificate renews.
NEXT STEPS:
- This certificate will not be renewed automatically. Autorenewal of --manual certificates requires the use of an authentication hook script (--manual-auth-hook) but one was not provided. To renew this certificate, repeat this same certbot command before the certificate's expiry date.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -自宅サーバー内の /etc/letsencrypt/live/test-site.online/ の中に、世界が認める本物の証明書（fullchain.pem）と秘密鍵（privkey.pem）が完璧に生成されました！
ステップ 9：自宅Nginxの設定ファイルに証明書のパスを記述する
Nginxのサイト設定ファイル（例：/etc/nginx/sites-available/test-site.online など）を開き、server ブロックのSSL設定部分に、先ほど取得した証明書のパスを記述します。
server {
listen 80;
listen [::]:80;
server_name test-site.online www.test-site.online;
ssl_certificate /etc/letsencrypt/live/test-site.online/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/test-site.online/privkey.pem;
root /var/www/html;
index index.html index.htm;
location / {
try_files $uri $uri/ =404;
}
}ファイルを保存し、一旦閉じます。
💡 【検証】一度接続をテストしてみる
証明書が指定できたので、一度自宅サーバーのターミナルから、自分自身（ローカルホスト）の443番ポートに対してSSL接続の確認コマンドを叩いてみます。
openssl s_client -connect 127.0.0.1:443 -servername test-site.online🚨 返ってくる結果
4087A8B38D7D0000:error:8000006F:system library:BIO_connect:Connection refused:../crypto/bio/bio_sock2.c:114:calling connect()
4087A8B38D7D0000:error:10000067:BIO routines:BIO_connect:connect error:../crypto/bio/bio_sock2.c:116:ごめんなさい。実はここで終わりではないんです。
💡 なぜこれで終わりではないのか？
エラーログの Connection refused（接続拒否）という文字を見て、焦る必要はありません。これは「狙い通りの大正解」です。
今、私たちは「自宅Nginxの設定ファイルに証明書のパスを書き加えた」だけです。 しかし、このシステムはあなたの大事な自宅サーバーを守るために、一度「VPS」を玄関として挟み、そこから自宅へとパケットを流すリバースプロキシ構成（二重構造）になっています。
通信を暗号化（HTTPS化）するということは、この「インターネット ➔ VPS ➔ 自宅ルーター ➔ 自宅Nginx」という一本の配管すべてを、HTTPS仕様に作り替える必要があります。
まだ自宅Nginxに「証明書はこれだよ」と教えただけで、肝心の配管はどこもかしこも「昔のHTTP仕様（ポート80番）」のまま。だから、通信が途中でシャットアウトされて繋がらないのは当然なのです。
ここから、この配管を「外側から順番に」HTTPS仕様へ切り替えていきます。
「なぜ外側からなのか？」 それは、外側（インターネット側）から順番に設定を変えていかないと、万が一どこかで繋がらなくなったときに「どこが原因なのか」の切り分け（デバッグ）ができなくなり、一生迷宮入りするからです。
では、配管をHTTPS化する最初の工事（ステップ 10）へ進みましょう。
ステップ 10：VPS側で自動生成された「リダイレクト設定」を確認・修正する
「前回の記事からVPSの設定ファイルなんて一度も触っていないのに、どうやってHTTPSで待ち受けるんだ？」と疑問に思うかもしれません。 実は、ステップ 1でCertbotを実行した時点で、Certbotが裏で自動的にVPSの設定ファイルをHTTPS仕様に改造してくれています。
人間がやることはコードの追記ではなく、「自動でどう書き換わったか」を自分の目で確認し、HTTPで来たアクセスを自動でHTTPSに回すリダイレクトの仕組みを完成させる作業です。
📄 Certbot実行直後のVPSの設定（例：/etc/nginx/sites-available/test-site.online）
VPSの設定ファイルを開くと、前回の記述をベースに、Certbotによって以下のように自動変形しているはずです。
server {
server_name test-site.online;
# 外からのアクセスを自宅へ流す、前回作ったメイン処理
location / {
# 💡 ここは「http」のままでOK！
# 外側（インターネット）からVPSまではHTTPSで暗号化されていますが、
# VPSから自宅ルーターの間は、あえて「http」のままパケットをスルーさせます。
proxy_pass http://153.156.79.69:50080;
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;
}
# 🛠️ 【自動追加】Certbotが自動で付け足した443番（HTTPS）の待ち受けルール
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/test-site.online/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/test-site.online/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
#server {
# if ($host = test-site.online) {
# return 301 https://$host$request_uri;
# } # managed by Certbot
# listen 80;
# server_name test-site.online;
# return 404; # managed by Certbot
#}🚨 確認したらNginxを再起動して確定！
念のため、設定ファイルに構文エラーがないかを確認し、Nginxを再起動して設定を確定させます。
sudo nginx -t
sudo systemctl restart nginxステップ 11：自宅ルーターの静的マスカレード（ポート転送）を書き換える
VPS（外側）の転送設定が https:// に書き換わったことで、VPSから自宅に向けて飛んでくるパケットは、これまでの「HTTP」から「暗号化されたHTTPS通信」へと姿を変えました。
次にやるべきことは、このパケットが自宅のルーター（玄関）に到達した際、迷子にならずに「自宅サーバーの443番（HTTPS）ポート」へと正しくすり抜けられるように、ルーターの静的マスカレード（ポート転送）設定を変更することです。
🛠️ ルーターの設定変更
ルーターの管理画面（http://192.168.1.1/t/など）を開き、前回設定したポート転送ルール（静的マスカレード）を見つけて、以下のように書き換えます。
- 変換対象プロトコル（TCP/UDP）：
TCP（そのままでOK） - 外部ポート（WAN側ポート）：
50080（VPSのproxy_passで指定した、例の「当選ポート」のまま） - 転送先IPアドレス（LAN側IP）： 自宅サーバーのローカルIPアドレス（
192.168.X.Xのまま） - 内部ポート（LAN側ポート）： ~~
80~~ ➔443に書き換える！
💡 ワンポイント：
前回のHTTP編では、外から来た 50080 番への通信を自宅サーバーの 80 番（HTTP）に流していました。今回は暗号化を維持したまま自宅サーバーに処理させたいので、出口を 443（HTTPS）へと変更するわけです。
ステップ 12：自宅Nginx（WordOps）の待ち受けを「443 ssl」に書き換える
ルーターを抜けてきた暗号化通信を受け止めるため、自宅サーバーの設定ファイルを書き換えます。
やることはシンプルです。前回作成したWordOpsの設定ファイルを開き、待ち受けポートを「80」から「443 ssl」に変更する。ただそれだけです。ステップ 9で記述した証明書のパスや、前回仕込んだ中継ヘッダー設定はそのまま活きます。
📄 自宅Nginxの設定（例：/etc/nginx/sites-available/test-site.online）
server {
# 🚨 待ち受けを「80」から「443 ssl」に書き換える！
listen 443 ssl;
listen [::]:443 ssl;
server_name test-site.online www.test-site.online;
# （※STEP 9で追記した証明書のパスや、前回のリアルIP・ヘッダー引き継ぎ設定はそのまま下に続いています）
ssl_certificate /etc/letsencrypt/live/test-site.online/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/test-site.online/privkey.pem;
set_real_ip_from VPSのグローバルIP;
real_ip_header X-Forwarded-For;
proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
access_log /var/log/nginx/test-site.online.access.log rt_cache;
error_log /var/log/nginx/test-site.online.error.log;
# （以下略）
}ファイルを保存し、閉じます。
🚨 【最後】保存したら即・再起動！
外側（VPS）から内側（自宅サーバー）までの配管が、これで一本の「HTTPSの強固なトンネル」として繋がりました。 最後に、設定を適用させるために自宅側で「本日2回目の再起動の呪文」を叩き込みましょう！
# 1. 記述に文法エラーがないか最終テスト
sudo nginx -t
# 2. テストが通ったらNginxを再起動して完全適用！
sudo systemctl restart nginxステップ 13：wp-config.php 先頭の「プロキシ中継設定」を確認する
前編のステップ 2-②で記述したコードが確実に記述されているか、自宅サーバー側でWordPressの wp-config.php を開き、一番最初の行（<?php のすぐ下の行）に以下のコードが記述されていることを確認します。
※もし記述がなかった場合は<?phpのすぐ下の行に追記してください。
// 🚨 VPS経由のHTTPS通信をWordPressに正しく認識させる設定
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
/**
* The base configuration for WordPress
...💡 なぜこのコードが絶対必要なのか？
VPS（Nginx）は、外からのアクセスを自宅に転送するときに「これは元々HTTPSで来たアクセスだよ」という目印（X-Forwarded-Proto: https）をヘッダーに刻印しています。
上記のコードを入れることで、WordPressがその目印を読み取り、内部的に $_SERVER['HTTPS'] = 'on'; をシミュレートします。これにより、WordPressは自身がHTTPS空間で動いていると確信し、すべての内部リンクやアセット（CSS/JS）を正しく https:// で生成してくれるようになります。
ステップ 14：ブラウザからアクセスして「完全HTTPS化」を確認する
すべての設定と再起動が完了したら、いよいよ運命の瞬間です。ブラウザを開いて、あなたのサイトにアクセスしてみましょう。
1. シークレットウインドウでアクセスする
過去のキャッシュがブラウザに残っていると、古いリダイレクト情報などが悪さをして正しく検証できないことがあります。 必ず「シークレットモード（プライベートブラウズ）」で新しいウインドウを開いてください。
2. ドメインを入力してアクセス
ブラウザのアドレスバーに以下を入力します。
https://test-site.online🔍 最終チェックリスト（すべてクリアできれば完全勝利！）
- アドレスバーに「鍵マーク」が出ているか？
チューナーマーク（スライダーのような2本の線のアイコン）をクリックし、「この接続は保護されています」と表示され、VPS側（Certbot）で取得した証明書が正しく反映されていることを確認します。 - WordPressの表示崩れが起きず、正しく表示されているか？
トップページや記事ページを開き、CSS（スタイルシート）が正常に読み込まれ、デザインが崩れずに美しく表示されているか確認します。 - WordPressの管理画面（ダッシュボード）にログインできるか？
http://からhttps://に変わると再度ログインを要求されます。再ログイン後、管理画面が正常に動き、記事の投稿や設定変更が問題なく行えるかテストします。
まとめ
さて、絶望的なMAP-Eの縛りプレイから始まった本連載ですが、ステップを一つずつ踏み進めてきた結果、ついに「ポートが開いている格安VPSを外壁（リバースプロキシ＋SSL処理）にし、中身の重たい処理はすべて自宅の最強10Gサーバーに丸投げする」という、非常に美しく、かつ実用的なハイブリッド環境を完成させることができました。
固定IPのオプション料金を毎月払い続けたり、スペックの割に維持費の高いハイエンドVPSを借りたりする必要はもうありません。
ネットワークの制限という高い壁は、アイディアとLinuxの基本設定、そして仕様を逆手にとる小細工だけで、いくらでもブチ破ることができます。
せっかく引き込んだ爆速の10G回線と、苦労して組み上げた大切な自作サーバーです。ぜひこの「VPS中継による常時SSL化」を実践して、あなただけの最強の自宅サーバーライフをここからスタートさせてみてください！
🔒 次回予告：10G光クロス×MAP-Eサバイバル。最強の急所「wp-login.php」をVPS中継環境で鉄壁に縛り上げる【セキュリティ編】
中継VPSを玄関口にして常時HTTPS化（SSL化）を完了し、ついに世界中から「保護された通信」として安全に閲覧できるようになったWordPress。
「セキュリティなんてプラグインを入れておけば安心でしょ？」
――いいえ、自宅サーバー環境においてそれは最もやってはいけない悪手です。重いPHPプログラムを動かしてログイン画面を守ろうとすれば、botの猛攻を受けた瞬間に自宅サーバーのCPUは限界を迎え、あなたのWordPressはあっけなく撃沈します。
だからこそ、私たちはプラグインに一切頼りません。
次回は、中継VPSを「盾」とし、自宅の超高速10G光クロス回線（MAP-E）の制限を乗り越えながら、「悪意あるアクセスを自宅サーバーに1ミリも触れさせずに水際で叩き落とす、最強のプロキシ防御システム」を構築していきます。
このセキュリティ編のロードマップとして、中継VPS（リバースプロキシ）のNginxを駆使し、
- 最も狙われる
wp-login.phpへのアクセスを遮断し、 - 乗っ取りの踏み台にされやすい
xmlrpc.phpを無効化し、 - ユーザー名を割り出すための
?author=への攻撃を弾き、 - 漏洩しやすい
REST APIを鍛え上げる、 といった極悪ボット撃退設定を段階的に組んでいきます。
まずはその第一弾。 最も狙われやすく、突破されたら全てが終わりである最大の急所「wp-login.php（管理画面）へのアクセス制限」からスタートします！
中継VPSという最強の「関所」があるからこそできる、鉄壁のIP制限とアクセス遮断のテクニックを余すことなく教えます。
次のセキュリティ編は2026年7月28日公開です。
最後まで読んでいただきありがとうございました！
コメント