前回の記事「自宅サーバーをネットに公開する!HGW&Decoによる二重NAT環境のポート転送設定ガイド」では、ホームゲートウェイ(HGW)とTP-Link Decoの二重NAT環境でポート転送を設定し、自宅サーバーをインターネットに公開できるようにしました。
しかし、ポートを開放しただけではHTTPによる平文通信になってしまい、セキュリティ上の問題があります。
本記事では、自宅のNUCBox G3 Plus上にNginxをリバースプロキシとして設定し、Let’s Encrypt(Certbot)でSSL証明書を取得してHTTPS化する手順を解説します。ドメインアクセスには鍵マーク付きのHTTPS接続が実現し、安全に外部公開できるようになります。
なぜこの機能を作ったのか?
自宅スマートホームシステムでは、Flaskで作ったAPIサーバー、Grafanaのダッシュボード、LINEミニアプリなど複数のサービスが動いています。
これらを外部から安全にアクセスするには、通信の暗号化(HTTPS)が必須です。特にLINEのWebhookやAPIへのアクセスはHTTPSが前提となっており、HTTPだとそもそも動作しません。
また、Nginxをリバースプロキシとして一元管理することで、ポート番号を意識せずにパスベースで各サービスに振り分けられる構成を実現したいと考えました。

自宅サーバーをHTTPS化して、外部から安全にアクセスしたい!
実現したいこと
- Let’s Encrypt(Certbot)で無料SSL証明書を取得し、NginxでHTTPS化する
- HTTPアクセスは自動的にHTTPSへリダイレクトする
- Nginxをリバースプロキシとして使い、パスベースで複数サービスへ振り分ける
/external/→ Flaskアプリ(ポート8000)/webhooks/→ GoogleHome用Webhook(ポート8000)/grafana/→ Grafana(ポート3000)/liff/→ LINEミニアプリ専用ページ
- 外部向けサーバー(HTTPS)とLAN内向けサーバー(HTTP、IPアクセス)を分けて管理する
- セキュリティヘッダーを設定し、クリックジャッキングなどの攻撃に対策する
この記事でわかること
- Nginxのインストール方法と基本的な設定ファイルの構成
- Let’s Encrypt(Certbot)を使った無料SSL証明書の取得手順
- NginxでHTTP→HTTPSリダイレクトを設定する方法
- Nginxをリバースプロキシとして設定し、複数サービスへパスルーティングする方法
- 外部向けサーバーとLAN内向けサーバーを1つの設定ファイルで分けて管理する方法
- セキュリティヘッダー(X-Frame-Options、CSPなど)の設定方法
- CMAN・curl・openssl s_clientによる疎通確認・SSL証明書確認の方法
必要な準備と用意するもの
- Linux サーバー(本記事では NUCBox G3 Plus を使用)
- Ubuntu / Debian系であれば同様の手順で設定可能。Raspberry Piも同手順でOK
- LAN内固定IP:
192.168.68.89
- インターネット接続環境(ポート80/443の外部公開が完了していること)
- 前の記事「HGW&Decoによる二重NAT環境のポート転送設定ガイド」の設定が完了していること
- Nginx
- リバースプロキシ&Webサーバーとして使用
- Certbot(Let’s Encrypt クライアント)
- 無料SSL証明書の取得・自動更新に使用
- DDNSドメイン(本記事では
xxxx.tplinkdns.com)- Let’s EncryptはIPアドレスではなくドメイン名に対して証明書を発行するため、DDNSドメインが必須
- (オプション)バックエンドサービス
- Flaskアプリ(ポート8000):
/external/および/webhooks/のプロキシ先 - Grafana(ポート3000):
/grafana/のプロキシ先
- Flaskアプリ(ポート8000):
完成イメージ
設定完了後のネットワーク構成と通信フローは以下の通りです。外部からのHTTPS接続がNginxに届き、パスに応じて各サービスへプロキシされます。
インターネット (外部クライアント)
↓ https://xxxx.tplinkdns.com
HGW → Deco(二重NAT越え:前の記事で設定済み)
↓ ポート443/80
NUCBox G3 Plus (192.168.68.xxx)
└─ Nginx(リバースプロキシ)
├─ listen 443 ssl ← Let's Encrypt証明書
│ ├─ / → 静的ファイル (/srv/nginx/public/html)
│ ├─ /liff/ → LINEミニアプリ静的ファイル
│ ├─ /external/ → Flask API (127.0.0.1:8000/api/)
│ ├─ /webhooks/ → GoogleHome Webhook (127.0.0.1:8000/webhooks/)
│ └─ /grafana/ → Grafana (127.0.0.1:3000/)
├─ listen 80 ← HTTP→HTTPSリダイレクト (外部向け)
└─ listen 80 ← LAN内向けサーバー (192.168.68.xxx のみ)
├─ / → 静的ファイル (/srv/nginx/private)
├─ /internal/ → Flask内部API (127.0.0.1:8000/internal/)
└─ /grafana/ → Grafana (127.0.0.1:3000/) ※LAN限定システムの仕組み
リバースプロキシとは?
リバースプロキシは、クライアントとバックエンドサーバーの間に立って通信を中継するサーバーです。
クライアントはNginxにアクセスするだけでよく、Nginxがリクエストのパスを見て適切なバックエンドサービスへ転送します。
リバースプロキシのメリット
・ポート番号をURLに含めなくてよい(:8000 や :3000 を隠せる)
・SSL終端をNginxに集約できる(バックエンドはHTTPのまま)
・セキュリティヘッダーの一括管理が可能
・アクセスログの一元管理ができる
Let’s Encrypt(Certbot)とは?
Let’s Encryptは、非営利団体ISRGが運営する無料のSSL証明書発行機関(CA)です。
Certbotはそのクライアントツールで、証明書の取得・Nginx設定への自動組み込み・自動更新をまとめて行ってくれます。
証明書の有効期限と自動更新
Let’s Encryptの証明書の有効期限は90日間です。Certbotをインストールすると systemd タイマー(または cron)が自動で設定され、有効期限が30日以内になると自動で更新されます。手動更新の手間が不要です。
HTTPS化の仕組み(SSL終端)
外部からの通信フローは以下の通りです。NginxがSSLの暗号化・復号を担当し(SSL終端)、バックエンドへはHTTPで転送します。
- クライアントが
https://xxxx.tplinkdns.com/external/statusにアクセス - NginxがHTTPS(ポート443)で接続を受け付け、SSL証明書でハンドシェイク
- Nginxがパス
/external/を見て、http://127.0.0.1:8000/api/statusへプロキシ - Flaskアプリがレスポンスを返し、Nginxがクライアントへ送信
実装のポイント
CertbotはNginxプラグインを使うと設定まで自動化certbot --nginx オプションを使うと、証明書取得だけでなくNginxの設定ファイルへのSSL設定の書き込みまで自動で行ってくれます。手作業によるミスを減らせます。
外部向けとLAN内向けを同一ファイルで管理
Nginxの設定ファイルで server_name によってブロックを分けることで、外部向け(HTTPS、DDNSドメイン)とLAN内向け(HTTP、IPアドレス)を1ファイルで管理できます。
LAN内アクセスは allow/deny で制限
LAN内向けの location ブロックに allow 192.168.68.0/24; deny all; を追加することで、外部IPからのアクセスを遮断できます。内部APIをインターネットに晒さないための重要な設定です。
証明書取得前にポート80が開いていることを確認
Let’s EncryptのHTTPチャレンジ(http-01)はポート80へのアクセスで所有者確認を行います。証明書取得コマンドを実行する前に、HGW&Decoのポート転送(ポート80)が正しく設定されていることを確認してください。
証明書取得時はNginxを停止するか standalone モードを使う
Certbotのスタンドアロンモードはポート80を一時的に占有します。Nginxが起動中の場合は certbot --nginx プラグインを使うか、一時的にNginxを停止してから証明書を取得してください。本記事では --nginx プラグインを推奨します。
事前準備
サーバーのIPアドレスを固定する
NginxサーバーのLAN内IPアドレスが変わるとDecoのポート転送が機能しなくなります。Decoアプリの「アドレス予約」でMACアドレスに固定IPを割り当てておきましょう。
本記事の環境では 192.168.68.89 を固定で使用しています。
ポート転送の確認
前の記事で設定したHGW&DecoのポートTCP 80・443転送が正しく機能しているか確認します。
スマートフォンのモバイル回線(自宅WiFiをOFF)から下記URLにアクセスしてみてください。この時点ではNginxがHTTPSに対応していないため、http://でのアクセスとなります。
# モバイル回線からHTTPアクセスでNginxのデフォルトページが返ることを確認
curl -v http://xxxx.tplinkdns.comこの時点でNginxのHTMLが返ってくれば、ポート転送は正しく設定されています。「接続できない」場合は前の記事のポート転送設定を見直してください。
実装方法(設定手順)
① Nginx のインストール
まずNginxをインストールします。
sudo apt update
sudo apt install -y nginxインストール後、Nginxが起動していることを確認します。
sudo systemctl status nginx
# active (running) と表示されればOK
# 自動起動を有効にする
sudo systemctl enable nginx② Certbot のインストール
次に、Let’s Encrypt クライアントの Certbot をインストールします。Ubuntu/Debian系では snapd 経由でのインストールが公式推奨です。
# snapd のインストールと更新
sudo apt install -y snapd
sudo snap install core
sudo snap refresh core
# Certbot のインストール
sudo snap install --classic certbot
# certbot コマンドへのシンボリックリンク作成
sudo ln -s /snap/bin/certbot /usr/bin/certbotapt版 certbot について
apt でもインストールできますが(sudo apt install certbot python3-certbot-nginx)、バージョンが古い場合があります。特に問題がなければ snap 版の利用を推奨します。
③ 仮の Nginx 設定(HTTP のみ)
Certbot が証明書取得時にドメイン所有確認(HTTPチャレンジ)を行うため、まずはHTTPで動作するNginxの設定を行います。
設定ファイルは /etc/nginx/sites-available/default または /etc/nginx/conf.d/default.conf を編集します。
本記事の環境では /etc/nginx/conf.d/default.conf を使用しています。
server {
listen 80;
server_name xxxx.tplinkdns.com;
location / {
root /srv/nginx/public/html;
index index.html index.htm;
}
}# 設定ファイルの構文チェック
sudo nginx -t
# Nginx の再起動
sudo systemctl reload nginx④ Let’s Encrypt SSL 証明書の取得
Certbot の Nginx プラグインを使って証明書を取得します。このコマンドは証明書の取得と Nginx 設定への SSL 設定の自動追記を行います。
sudo certbot --nginx -d xxxx.tplinkdns.comコマンド実行後、メールアドレスの入力や利用規約への同意を求められます。指示に従って入力してください。
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices)
(Enter 'c' to cancel): your-email@example.com # メールアドレスを入力
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at

404 Page not foundLet's Encrypt is a free, automated, and open Certificate Authority brought to you by the nonprofit Internet Security Res... You must agree
in order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: Y # Yを入力
...(中略)...
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/xxxx.tplinkdns.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/xxxx.tplinkdns.com/privkey.pem
This certificate expires on 2026-08-28.
Deploying certificate to VirtualHost /etc/nginx/conf.d/default.conf
Redirecting all traffic on port 80 to ssl in /etc/nginx/conf.d/default.confSuccessfully received certificate. と表示されれば証明書取得成功です。証明書は /etc/letsencrypt/live/xxxx.tplinkdns.com/ に保存されます。
証明書の自動更新が正しく設定されているか確認します。
# 自動更新のドライランテスト
sudo certbot renew --dry-runCongratulations, all simulated renewals succeeded と表示されれば自動更新も正しく設定されています。
⑤ Nginx の本番設定
証明書取得後、本番用のNginx設定ファイルを作成します。以下が実際の設定内容です。
# ログフォーマット定義(リモートIP・ユーザーエージェント等を記録)
log_format detailed '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
# ===================================================
# 外部向けHTTPSサーバー (DDNS経由)
# ===================================================
server {
listen 443 ssl;
server_name xxxx.tplinkdns.com;
# SSL証明書(Let's Encrypt Certbot管理)
ssl_certificate /etc/letsencrypt/live/xxxx.tplinkdns.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/xxxx.tplinkdns.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
access_log /srv/nginx/log/access.log detailed;
error_log /srv/nginx/log/error.log;
# / ルートディレクトリ(外部向け静的ファイル)
location / {
root /srv/nginx/public/html;
index index.html index.htm;
limit_except GET HEAD { deny all; }
autoindex off;
disable_symlinks if_not_owner from=/srv/nginx/public/html;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; connect-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline';" always;
add_header Cache-Control "no-store, no-cache, must-revalidate, proxy-revalidate";
}
# /liff/ : LINEミニアプリ専用(LINE SDNのスクリプト読み込みを許可)
location /liff/ {
alias /srv/nginx/public/liff/;
index index.html;
limit_except GET HEAD { deny all; }
autoindex off;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' blob: https://static.line-scdn.net https://*.line.me; ..." always;
access_log /srv/nginx/log/liff_access.log detailed;
}
# /external/ : 外部向けAPI(Flaskアプリへプロキシ)
location /external/ {
proxy_pass http://127.0.0.1:8000/api/;
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_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_cache_bypass $http_upgrade;
proxy_set_header Authorization $http_authorization;
access_log /srv/nginx/log/api.log detailed;
}
# /webhooks/ : GoogleHome用Webhook
location /webhooks/ {
proxy_pass http://127.0.0.1:8000/webhooks/;
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_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_cache_bypass $http_upgrade;
}
# /grafana/ : Grafana外部アクセス
location /grafana/ {
proxy_pass http://127.0.0.1:3000/;
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_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_cache_bypass $http_upgrade;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html { root /usr/share/nginx/html; }
}
# ===================================================
# HTTP→HTTPSリダイレクト(外部向け)
# ===================================================
server {
listen 80;
server_name xxxx.tplinkdns.com;
return 301 https://$host$request_uri;
}
# ===================================================
# LAN内向けサーバー(IPアクセス、LAN限定)
# ===================================================
server {
listen 80;
server_name 192.168.68.xxx;
root /srv/nginx/private;
location / {
index index.html index.htm;
autoindex on;
}
location /internal/ {
proxy_pass http://127.0.0.1:8000/internal/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
allow 192.168.68.0/24;
deny all;
access_log /srv/nginx/log/webapi_internal.log detailed;
}
location /grafana/ {
proxy_pass http://127.0.0.1:3000/;
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;
allow 192.168.68.0/24;
deny all;
}
}設定ファイルを保存したら、構文チェックと反映を行います。
# 構文チェック
sudo nginx -t
# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
# nginx: configuration file /etc/nginx/nginx.conf test is successful
# 設定の反映(サービスを止めずにリロード)
sudo systemctl reload nginx⑥ ログ出力ディレクトリの作成
設定ファイルで指定したログディレクトリが存在しない場合、Nginxが起動できません。事前に作成しておきます。
sudo mkdir -p /srv/nginx/log
sudo mkdir -p /srv/nginx/public/html
sudo mkdir -p /srv/nginx/public/liff
sudo mkdir -p /srv/nginx/private
sudo chown -R www-data:www-data /srv/nginx設定のポイント解説
セキュリティヘッダーについて
外部向けの静的ファイル配信では、以下のセキュリティヘッダーを設定しています。
| ヘッダー | 値 | 目的 |
|---|---|---|
| X-Frame-Options | DENY | クリックジャッキング攻撃を防ぐ |
| X-Content-Type-Options | nosniff | MIMEタイプのスニッフィングを防ぐ |
| X-XSS-Protection | 1; mode=block | XSS攻撃をブラウザ側でブロック |
| Referrer-Policy | strict-origin-when-cross-origin | リファラー情報の漏洩を制限 |
| Content-Security-Policy | default-src ‘self’ | 外部スクリプト等の読み込みを制限 |
リバースプロキシ設定のポイント
プロキシブロックで設定している主要なヘッダーの意味を解説します。
proxy_set_header X-Real-IP $remote_addr;
# → バックエンド(Flask等)に実際のクライアントIPを伝える
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# → プロキシを経由した場合のクライアントIP履歴を伝える
proxy_set_header X-Forwarded-Proto $scheme;
# → バックエンドに元のプロトコル(https)を伝える
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
# → WebSocket接続のアップグレードをサポートする(Grafana等で必要)LAN内サーバーのアクセス制限
LAN内向けの /internal/ と /grafana/ のパスには、LAN内のIPアドレスからのアクセスのみを許可する制限を設けています。
allow 192.168.68.0/24; # LAN内(192.168.68.xxx)のみ許可
deny all; # その他は全て拒否LAN内サーバーはIPアドレスで server_name を指定
LAN内向けサーバーの server_name にはDDNSドメインではなく、サーバーのLAN内IPアドレスを直接指定します。これにより、http://192.168.68.xxx/ でアクセスした場合のみこのサーバーブロックが使用されます。
動作確認
CMAN でポート疎通確認(外部からのポート確認)
CMAN(https://www.cman.jp/network/support/port.html)を使うと、外部からポートが開いているかを確認できます。
- 上記URLにアクセスする
- 「確認するホスト名またはIPアドレス」に DDNSドメイン(
xxxx.tplinkdns.com)を入力 - 「確認するポート番号」に
443を入力して「チェック」をクリック - 「ポートは開いています」と表示されればOK
ポートは開いています と表示されれば、外部からのHTTPS(443)アクセスが正しく届いています。
ポートはフィルタリングされています(または閉じています) と表示された場合は、HGW・DecoのポートTCP 443転送設定を確認してください。
curl コマンドによる疎通確認
サーバー本体またはLAN内の別マシンから curl コマンドで確認します。
# HTTP→HTTPSリダイレクトの確認(301が返ればOK)
curl -v http://xxxx.tplinkdns.com
# < HTTP/1.1 301 Moved Permanently
# < Location: https://xxxx.tplinkdns.com/
# HTTPS接続確認(200が返ればOK)
curl -v https://xxxx.tplinkdns.com
# SSL証明書の検証を無視して接続テスト(証明書エラーのデバッグ時)
curl -vk https://xxxx.tplinkdns.com
# レスポンスヘッダーのみ確認(セキュリティヘッダーの確認)
curl -I https://xxxx.tplinkdns.comセキュリティヘッダーが正しく設定されているか確認します。
HTTP/2 200
x-frame-options: DENY
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
referrer-policy: strict-origin-when-cross-origin
content-security-policy: default-src 'self'; ...openssl s_client による SSL 証明書確認
openssl s_client コマンドを使うと、SSL証明書の詳細情報(発行者、有効期限、証明書チェーンなど)を確認できます。
# SSL証明書の詳細確認
echo | openssl s_client -connect xxxx.tplinkdns.com:443 2>/dev/null | openssl x509 -noout -text | grep -E "(Subject:|Issuer:|Not Before|Not After)" Issuer: C=US, O=Let's Encrypt, CN=R10
Not Before: May 30 00:00:00 2026 GMT
Not After : Aug 28 00:00:00 2026 GMT
Subject: CN=xxxx.tplinkdns.comIssuer: Let's Encrypt と表示され、Subject にドメイン名が表示されれば証明書は正しく設定されています。Not After が現在日から90日以内であることも確認してください。
# 証明書の有効期限のみ確認
echo | openssl s_client -connect xxxx.tplinkdns.com:443 2>/dev/null | openssl x509 -noout -enddate
# notAfter=Aug 28 00:00:00 2026 GMTブラウザでの最終確認
スマートフォンのモバイル回線(自宅WiFiをOFF)またはPCのブラウザから https://xxxx.tplinkdns.com にアクセスし、以下を確認します。
- 鍵マーク(セキュリティ表示)が表示されること
- 証明書の発行者が「Let's Encrypt」であること(鍵マークをクリックして確認)
http://でアクセスすると自動的にhttps://にリダイレクトされること- 各パス(
/grafana/等)へのアクセスが正しくプロキシされること
トラブルシューティング
証明書取得時に「Connection refused」エラーが出る
Let's Encrypt の HTTP チャレンジがポート80に到達できていません。HGW・DecoのポートTCP 80転送設定と、Nginxがポート80でリッスンしているかを確認してください。
nginx -t でエラーが出る
設定ファイルの構文エラーです。エラーメッセージに行番号が表示されるので確認してください。特に ssl_certificate のパスに証明書が存在するか確認します(ls /etc/letsencrypt/live/xxxx.tplinkdns.com/)。
502 Bad Gateway が返る
プロキシ先のサービスが起動していないか、指定したポート番号が間違っています。curl http://127.0.0.1:8000/ 等でバックエンドサービスが動いているか確認してください。
まとめ
本記事では、NginxをリバースプロキシとしてセットアップしてLet's Encrypt(Certbot)で無料SSL証明書を取得し、自宅サーバーをHTTPS化する手順を解説しました。
- Certbot の --nginx プラグインで証明書取得と設定を自動化:コマンド1つで証明書取得から Nginx 設定反映まで完結する
- HTTP→HTTPS リダイレクトでセキュリティを強化:
return 301 https://の1行でHTTPアクセスを全てHTTPSへ誘導できる - パスベースのリバースプロキシで複数サービスを一元管理:Flask API・Grafana・LINEミニアプリなどを443番ポートで統合して公開できる
- 外部向けとLAN内向けを server_name で分けて管理:DDNSドメインとLAN内IPアドレスで別々のサーバーブロックを使い分けることで、内部APIをインターネットから隔離できる
- 証明書は90日ごとに自動更新:Certbot が systemd タイマーで自動更新するため、証明書切れの心配が不要
この設定が完了すると、外出先から安全なHTTPS接続でGrafanaのダッシュボードを確認したり、LINE WebhookやFlask APIを外部サービスと連携させたりできるようになります。
次のステップとして、Nginxのアクセスログを解析してセキュリティ監視を強化したり、WordPressのリバースプロキシ設定を追加するのもおすすめです。

