- 0. 前日譚：アメブロの重さに絶望したあの日から17年、我が家の自宅サーバー変遷史
- 1. 10G回線を引いたのに自宅サーバーが公開できない！？
- 2．死闘の末に辿り着いた、10G一本化の「最適解」
- 2-5. 💸 悲願の1GB回線解約と、二重課金デスゲームへの勝利
- 第3章：大食い旧型機からの脱却。ローコスト最新鋭サーバー機ビルドと、新世代管理ツール「WordOps」への全面移設転生編
- 第4章. 💰 月2万5千円からの脱却！新生エコ10Gサーバー、驚異の最終リザルト編
0. 前日譚：アメブロの重さに絶望したあの日から17年、我が家の自宅サーバー変遷史
管理人のブログ運営は、今から17年前に遡ります。 当初はアメブロなどの無料ブログサービスを利用して執筆していましたが、ある時、画像の読み込みが異常に重くなり、執筆どころではない状態に陥りました。
「サービスの重さに振り回されるくらいなら、いっそ自分でサーバーを建ててやる！」
そう、レンタルサーバーとかまだ良いお値段がする時代でしたからね。これが、管理人の自宅サーバー人生の原点となった訳です。
最初に手を出したのは、Windows環境にXAMPPを入れ、当時主流だったMovable Type（MT）を動かす構成。時にはPukiWikiに乗り換えてみたりと、試行錯誤しながら自宅サーバーとしての運用ノウハウを蓄積していきました。
そして2018年頃、超高速WordPress環境である「KUSANAGI」の存在を知ります。 ここから私の環境は「仮想化」へとシフトし、OSをCentOS 7に変えてVMware上でKUSANAGI 7を動かす時代へと突入しました。
余談：アメブロから脱出して始まった、CMS彷徨記
17年前、アメブロの重さにブチ切れてXAMPPを立ち上げた当初、今のように「とりあえずWordPress」という時代ではありませんでした。当時はMovable Type（MT）が全盛期。しかし、MTは記事を更新するたびにシステムが静的HTMLをビルドする「再構築」という儀式があり、記事が増えるたびにこの再構築がどんどん重くなるという別の罠が待っていました。
「じゃあ、データベースを使わずにテキストファイルだけで爆速で動くPukiWikiでブログっぽく運用したら最強では？」と血迷った時期もありました。そんな数々のCMSの歴史を自らのサーバーで看取ってきたからこそ、現在の「WordOpsによるNginx＋FastCGIキャッシュ」の組み合わせがいかに合理的で、バカみたいに速いかが五臓六腑に染み渡るのです。
🔌 ハイエンドPCがもたらした「電気代の恐怖」
その後、KUSANAGIのアップグレードを機に、ホストをWindowsに変えてCentOS Stream 9 ＋ KUSANAGI 9を動かすという環境までアップデートを重ねていました。
しかし、ここで物理的かつ致命的な問題が発生します。当時サーバーとして24時間フル稼働させていたマシンのスペックがこちら。
- CPU: Core i7-6950X Extreme Edition
- M/B: ASUS X99 GAMING
- RAM: 64GB
- GPU: GeForce GTX 1080×2
- PSU: Corsair AX1200i
そう、ただのゴリゴリのハイエンド・ゲーミングPCです。 近年の電気代高騰も相まって、このモンスターマシンを常時起動させておくのは、毎月の電気代がお財布にとってホラー映画以上の恐怖でした。
「電気代がお財布に優しくもっとシンプルに、OSのネイティブ環境で動く軽量爆速なシステムはないか？」
そうして行き着いたのが、コマンド一発で最強のNginx環境を作れる「WordOps」でした。長年慣れ親しんだCentOS（Red Hat系）がWordOps非対応だったため、これを機にUbuntuへの完全移行を決意したのです。
余談： Corsair AX1200iという贅沢すぎるオーバースペック
当時、電源マニアなら誰もが憧れたフルデジタル制御の最高峰電源「Corsair AX1200i」。1200Wもの大容量で、変換効率は最高峰の80PLUS PLATINUM。
バリバリにパーツを積んで高負荷をかける自作PCには最高のお供なのですが、自宅サーバーとして文字ベースのWebトラフィックを捌いているときの消費電力なんて、1200Wの足元にも及びません。電源は「容量の50%付近」で一番変換効率が良くなる性質があるのですが、負荷が低すぎて効率が良い領域にすら届いていなかった可能性があります。ロマンを求めて組んだ結果の「超・贅沢な電気の無駄遣い」も、今となっては良い思い出です。
1. 10G回線を引いたのに自宅サーバーが公開できない！？
我が家の自宅サーバーの心臓部として長年愛用してきたのが、超高速WordPress環境である「KUSANAGI」です。その付き合いは長く、システムの進化とともに幾度となくメジャーアップデートを繰り返してきました。
当初の CentOS 7 + KUSANAGI 7 時代は、WEB構築（プロビジョン）とSSLコマンドが完全に分離していた手探りの時期。そこから KUSANAGI 8 へ移行した際にはプロビジョン時にSSL認証が強制的に組み込まれる仕様変更があり、自宅サーバー勢をザワつかせたものでした。
しかし当時は、ルーターが優秀な RS-500MI（1GB回線） だったため、外からのポート80/443が素直に自宅サーバーまで届いていました。変動IP対策として MyDNS をフル活用し、お名前.comから自宅へ直接HTTPS通信を引き込む「無駄のない直通ルート」を確立。たまに3ヶ月毎の自動更新でコケては直す、お決まりの「すったもんだ」を経験しながらも、インフラは極めて平和に、かつ安定して回り続けていたのです。
- その「すったもんだ」の記事はこちら
そして、システムをさらに最先端の KUSANAGI 9 へ移行しようとした際、自宅サーバーとしての最大の試練が訪れます。KUSANAGI 9は、大元のOSである CentOS Stream 9とシステムがあらかじめ一体化したイメージファイルとして配布されるのがデフォルト。つまり、仮想環境（VM）にインポートする時点で、強制的にStream 9上のKUSANAGI 9という新システムが更地に組み上がる仕様だったのです。
大元がCentOS 7だった旧環境から、OSだけをインプレースでアップデートするルートなど存在しません。さらに悪いことに、Stream 9になったことでネットワーク設定の作法がこれまでと激変しており、当時の私はStream 9上でのネットワーク構築コマンドが分からず、IPの固定すらままならないという壁にぶち当たりました。
「CUIのStream 9上で直接ネットワークが組めないなら、いっそ使い慣れたGUIでネットワークを直感的に制御できるWindowsをホストOSにしよう。その上のVMwareにKUSANAGI 9のイメージをインポートして運用すればいい！」
そう考えた私は、当時自分がメイン使いしていたWindowsマシンのVM環境にKUSANAGI 9を入れ、居候させる形で運用を開始しました。ブログ環境の移行自体もその時はまだ便利なマイグレーションコマンドなんて発表されていなかったため、データベースのダンプからWordPressのコアファイル、各種設定の移植まで、すべて自力の力技でデータを流し込み、なんとか再構築を完了させました。（※ちなみに、この涙ぐましい手動移行がすべて完了した後に、公式から「マイグレーションコマンド発表！」の通知が届いたときは、流石に乾いた笑いが出ましたｗ）
💸 月1.5万円の二重課金デスゲームの開幕
「これでさらに爆速の自宅サーバー環境が作れるぞ！」と意気揚々とフレッツ光クロスを契約し、NTTから最新ルーター XG-100NE がレンタルされた瞬間、運命の歯車が狂い始めます。
通信クラスタを絶望のどん底に突き落とす、悪名高き仕様。
それが、「IPoE（IPv4 over IPv6）環境におけるウェルノウンポート（80番・443番ポート）の宅内開放不可」という罠です。
ひかり電話の有無や接続方式（MAP-E方式など）の組み合わせによって、宅内に割り当てられた固有のIPv6アドレス（回線そのもの）をベースに、利用可能なIPv4ポートが機械的に計算されて細切れに割り振られる仕組みになっています。
そのため、外部からのWebアクセス（標準 of 標準である80/443番ポート）は、ルーターに届くよりも手前の網内の段階でそもそも自分の回線には存在しない状態になっているのです。当然、このポート制限のせいで、自宅サーバーの命綱であるSSL証明書（Let’s Encrypt）の自動更新が完全にストップしてしまいます。
そんなある日、私のメールボックスに本家から無慈悲な一通のメールが届きました。 Let's Encrypt certificate expiration notice（お前のブログの証明書、あと数日で切れるぞボケ）
インフラ屋の心臓に最悪に悪い、恐怖のカウントダウンメールです。10G回線一本では、このまま証明書が切れてブログが即死（アクセス不可）するのは火を見るより明らかでした。
「10G一本じゃブログを維持できない……クソッ、背に腹は変えられん！！」
この警告メールのせいで、私は「メインブログ（WEBサーバー）の生存権を死守するためだけに、これまでの1GB回線（RS-500MI）の契約も毎月残し続ける」という、毎月の通信費が1万5〜6千円に膨れ上がる重すぎる二重課金デスゲームへの突入を決断したのです。
こうして10G（メイン普段使い用）と1G（サーバー用）の回線を物理的に切り分けて併用することになったわけですが、ここで致命的な問題が発生します。
私自身とメインPCは、当然お目当ての「爆速10G回線」へと引っ越します。しかし、ブログ（サーバー）はポートが開いている「1G回線」側に残さなければなりません。PCが1台しかなければ、1G回線に直結して24時間サーバーを常時起動させておくことは不可能です。つまり、10Gへ行くメインPCとは別に、1G回線に繋ぎっぱなしにしておくための「サーバー専用の物理マシン」が絶対にもう1台必要になったのです。
「1G回線に直結して24時間パケットを待ち受ける、サーバー専用の『別PC』が絶対に要る──」
そうなった私は、部屋を見渡しました。すると、当時パーツの状態で現役を退いて放置されていた、かつてのモンスターマシンのパーツ一式（Core i7-6950X、RAM 64GB、GTX 1080×2など）が目に留まります。
「お、このパーツ使えるやん、これで組んだろ♪」
そんな軽いノリで急遽パーツ一式を現世に召喚してサーバー専用の別PCとして組み上げ、前日譚で触れた、あの贅沢すぎる「1G回線に直結してWindowsホストの裏でVMwareを動かす専用サーバー」が爆誕したのです。こうして、我が家の重すぎる二重課金運用が本格的にスタートしました。
🛡️ 救世主「ConoHa串」の爆誕、そして地獄のルーティングパズル
回線とマシンは無事に別れたものの、毎月1万5〜6千円という重すぎるコストのプレッシャーが数年にわたり毎月お財布を削り続けます。この泥沼を終わらせるため、私はある日、ウルトラCの設計図を閃くことになります。
「フロントの盾として外部のVPSを導入して443番ポートをそこで受け持ち、裏側で通信を特殊ポートに曲げて自宅の10G回線にリレーさせればいい。そうすれば、月1.5万円もかかっている1GB回線を今すぐ解約して10G一本にできるじゃないか！」
このコストカットの劇的な費用対効果に気づき、すぐさま実戦に移るべくVPS探しを始めました。最初は王道のXserverあたりで組もうと考えてアカウントを作ろうとしたのですが、なぜかユーザー登録時の認証メールが一向に届かないという謎のトラブルに遭遇。
「じゃあ他の安いVPSを探すか…」と探していたところ、目に留まったのが ConoHa VPS でした。「そういえば大昔、アカウント作ったことがあったような…？」と、普段使いのメールアドレスとパスワードを試しに入力してみたところ、なんとあっさりログイン成功ｗｗｗ
しかも月額も800円を切る手頃な最安プランがあり（リバースプロキシとして通信を右から左へ流すだけならこれで十分！）、毎月800円弱の出費で1.5万円の回線が丸ごと解約できるなら実質タダのようなものです。
「これはもうConoHaでやれという運命だな」
この大いなる偶然に導かれ、ConoHa VPSの契約を即決。しかし、ここからが本当の「すったもんだ」の始まりでした。
お名前.comのDNSネームサーバー設定にガッツリ切り込んでドメインの枠組みを再構築しつつ、ConoHa側でリバースプロキシとして443番パケットを特殊ポートへ曲げるNginx設定。さらにそれを受け取る自宅のKUSANAGI 9側でも、転送されてきたパケットを正常に処理してWordPressを動かすためのNginx設定を噛み合わせる必要があります。
ConoHa側のプロキシ設定が悪いのか、ルーター（XG-100NE）のポート転送が詰まっているのか、それとも受け手である自宅サーバーのNginxが通信を拒絶しているのか。
原因の切り分けすらままならない中、泥臭い設定変更の末に、URLの後ろに特殊ポートを明示的に付けた https://ドメイン名:64975 であれば、自宅のIPに向けてダイレクトに叩くことでようやく「繋がる」という状態までこぎ着けました。しかし、本当の闘いはここからでした。
「パイプは繋がった。さあ、如何にしてこの不格好な『:64975』を取り除き、通常の443番（ポート番号なし）の状態で美しくアクセスできるようにするか──」
お名前.comのDNSが向いているConoHaのIPに向けて叩けば、フロントの盾が正常に受けるため綺麗に 200 OK が返ってくるのに、そこから自宅へと中継されるルートでは、どうしても :64975 を付けないと通信が繋がらない。このリバースプロキシ特有のねじれを完全に解消するためには、自宅の10G回線側（XG-100NE）へダイレクトにテストパケットを送り込んで検証を繰り返すための「専用の実験場」が必要でした。
そこで私は、このすったもんだの真っ最中に、お名前.comのDNSレコード設定へ切り込み、検証用サブドメイン bridge を新設。そのTYPEに『CNAME』を指定し、変動IPを常に追従してくれるMyDNSのホスト名（mydnsXXXXXX.mydns.jp）をVALUEへ直接叩き込むという、ピンポイントな中継ルートを爆誕させたのです。
この bridge 経由の検証用URLを用意し、ブラウザのキャッシュに騙されないよう、ターミナルから何度となく curl コマンドを乱打しては、返ってくるHTTPヘッダーのステータスコードやリダイレクトの挙動を生パケットレベルで凝視。
ConoHa側のNginxの proxy_set_header や、自宅のKUSANAGI 9のconfig、迅速なホスト認識制御をミリ単位で調整し、お名前.comのDNS設定からMyDNSのDDNSへとパケットをリレーさせながら、地獄のルーティングパズルを狂ったように解き続けました。
何度も心が折れそうになりながらも、数日間の激闘の末にようやくポート番号の消えた綺麗なURLでブログが画面に映し出されたあの瞬間の興奮は、今でも鮮明に覚えています。
こうして無事にConoHa VPSによる「串（プロキシ）構成」の第一歩が完成し、ようやく1GB回線を解約するという長年の悲願を達成することができたのです。
2．死闘の末に辿り着いた、10G一本化の「最適解」
🌐2-1. 脳内ルーティングの具現化：これが我が家のネットワーク構成図だ！
数日間に及ぶ curl 乱打戦と、お名前.com・ConoHa・MyDNSを巻き込んだすったもんだの末に辿り着いた、我が家の「10G一本化・完全リバースプロキシ構成」の全貌がこれです。
── フェーズ①：読者のブラウザによる「名前解決」
読者がブラウザにURLを入力した瞬間、まずは図の左側【インターネット（表側）】の司令塔へ問い合わせが行われます。
- ユーザー ➔ お名前.com DNS
読者のブラウザが「https://example.comにアクセスしたい！IPアドレスを教えて！」とお名前.comのDNSレコードを参照します。 - お名前.com DNS ➔ ユーザー
お名前.comは、登録されているAレコード（ConoHaの固定IP203.0.113.111）を読者に返却します。
── フェーズ②：ConoHaを盾にした「HTTPSパケットのワープ航路」
住所が分かった読者のブラウザは、ここから実際のWEB通信（HTTPSパケット）をブチ込みます。ここからが我が家のインフラの本番です。
- ユーザー ➔ ConoHa VPS（ポート:443）
読者の通信は、標準のHTTPSポート「443」を目がけてConoHa VPSへと着地します。ConoHaはフロントの盾としてこれをバシッと受け止め、読者に対して即座に★ここで200 OKを返します。外（読者）から見れば、この時点で不格好なポート番号を見ることもなく通信開通です。 - ConoHa VPS ➔ 【自宅ネットワーク（裏側）】
通信を受けたConoHaの内部では、Nginxが「よし、裏の自宅サーバーに転送（proxy_pass）するぞ。転送先はhttps://bridge.example.com:64975だな」と身構えます。 - MyDNS ➔ 自宅ルーター（IPを常に追従）
ここで、図の右上にあるMyDNSが真価を発揮します。我が家の10G回線（自宅ルーター）は固定IPではないためIPがコロコロ変わりますが、自宅側からMyDNSへ定期的に通知を行っているため、MyDNSのパラボラアンテナは常に最新の自宅IPを捕捉しています。ConoHaは内部でbridgeのIPを引くことで、迷子になることなく現在の自宅IPを割り出します。 - ConoHa VPS ➔ 自宅ルーター ➔ 自宅サーバー（裏でリレー:64975番）
行き先が分かった通信は、ConoHaから特殊ポート「64975番」に乗せ替えられて射出され、ひかりクロス10Gのポート閉鎖網を完全にバイパスして自宅ルーター（XG-100NE）へ突入。ルーターの静的マスカレード（ポート転送）を抜けて、最深部にある自宅サーバーへと安全に引き渡されます。 - 自宅サーバー（KUSANAGI 9）
待ち受けていた自宅側のNginx ＋ WordPressが、ConoHaから引き継いだヘッダー情報を元に:64975の存在を完全に隠蔽したまま処理を完了。読者の画面へ一瞬でブログのデータを送り届けるのです。
📝 2-2. 【ConoHa VPS側】443番を特殊ポートへ曲げるNginx設定
数日間に及ぶ curl 乱打戦の果てに、我が家のフロントの盾（ConoHa VPS）側に構築された、実際の設定ファイル（config）から、本質的なコアロジックだけを限界まで抽出したコードを大公開します。
リバースプロキシの構築で同じように「URLの後ろにポート番号が付いちゃう地獄」に沼っている自宅サーバー勢は、ぜひ穴が空くほど見つめてみてください。
# ==========================================================================
# 🛡️ 1. フロントの盾（ConoHa VPS：443番ポート受け）
# ==========================================================================
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# 👑 SSL更新チャレンジは自宅に転送せずConoHa側でダイレクト処理
location ^~ /.well-known/acme-challenge/ {
root /var/www/html;
allow all;
}
# 🌐 【一般公開用】すべてのアクセスを自宅の10G回線（bridge経由）へ転送
location / {
proxy_pass https://bridge.example.com:64975;
proxy_ssl_server_name on;
# ★ここが最重要！URLから「:64975」を消し去る魔法のヘッダー書き換え
proxy_set_header Host $http_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 Connection "";
proxy_buffering on;
}
}💡 このconfigに仕込まれた「4つの執念と美学」
ただ右から左へ通信を流しているように見えて、この設定ファイルの中には、1章の地獄から生還するために組み上げられた「数々のギミック」が仕込まれています。
1. ついに:64975が消えた！プロトコル反転の魔法
1章で最大の壁となった「動くには動くけど、強制的にポート番号が付与されてしまう問題」。これをねじ伏せたのが、location / 内に仕込まれたヘッダー書き換え設定です。
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;ここで注目すべきは、ConoHa側からの転送先が proxy_pass http://bridge.example.com:64975; と、あえて『http（非暗号化）』になっている点です。 技術的な知識があると「裏側も https にすればいいのでは？」と思いがちですが、ここを https に書き換えた瞬間、SSL証明書のドメイン不一致やハンドシェイクのエラーに引っかかり、通信は100%遮断されて繋がらなくなります。
そのため、ConoHaから自宅へは http:// で特殊ポートへパケットを射出するしかありません。しかし、これを受けた自宅サーバー側がURLを崩壊させずにポート番号を隠蔽できるように、本来のホスト名（$http_host）と、読者がアクセスしてきた本来のプロトコルである『https（$scheme）』をヘッダーに偽装して自宅へパスするという、執念のルーティングが組まれているのです。
2. 恐怖の失効メールを過去にする「LE自動更新のConoHaローカル完結」
1章で管理人を二重課金デスゲームへと引きずり込んだ最大の元凶、Let’s Encryptからの「あと数日で証明書が切れるぞ」という恐怖の失効メール。 これを根本から解決するため、外からのSSL更新チャレンジ（.well-known/acme-challenge/）の通信だけは、自宅の10G回線側へ転送せず、すべてConoHa VPSのローカル側（クラウド側）でダイレクトに処理して完結させる仕様にしました。
これにより、フロントの盾であるConoHa側はガッチリ24時間365日、443番で外部向けの証明書を維持し続けてくれます。
これでフロントの盾（ConoHa）側の迎撃・リレー陣形は完全に整いました。
しかし、ここで自宅サーバー勢なら絶対に一つの疑問にぶち当たるはずです。 「ConoHaから自宅へ『http（非暗号化）』でパケットを投げたってことは、自宅側はそれをどうやって受け止めてるんだ？」
読者のブラウザに対してはHTTPS（443）で「安全な通信ですよ」とドヤ顔をしておきながら、裏側の身内スペースではHTTP（生の通信）でパケットが飛び交っている。この強烈な『ねじれ』を、受け手である自宅サーバー側は一体どうやって辻褄を合わせ、WordPressを正常に動かしているのか。
そのすべての謎を解き明かす、最深部「自宅サーバー側」の受け皿設定を、次の節で丸裸にします。
🏠 【当時の自宅サーバー側】KUSANAGI 9でHTTPSを受け止める設定
フロントの盾であるConoHa VPSから、10G回線の特殊ポート（:64975）を経由してワープしてきたパケットを、自宅サーバー側でどう受け止めるか。
当時はまだWindowsの仮想環境（VM）に居候させていた『KUSANAGI 9』環境。リバースプロキシの受け皿として、Nginxの作法とKUSANAGI特有の自動生成される構成に悪戦苦闘しながら、URLからポート番号を隠蔽し、セキュリティを担保するために叩き込んだ実際のコアconfig（.conf）がこれです。
### PST Section Installed ###
# vim: ft=conf et sw=4
#=======================================
# www.example.com
#---------------------------------------
server {
listen 80;
listen 443;
listen 64975;
listen [::]:64975;
server_name www.example.com example.com;
set $do_not_cache 0; ## page cache
set $expire_days 90d;
access_log /home/kusanagi/profiles/log/nginx/access.log main;
error_log /home/kusanagi/profiles/log/nginx/error.log warn;
charset UTF-8;
client_max_body_size 2G;
root /home/kusanagi/profiles/DocumentRoot;
# --- 25行目から追記 ---
# location / {
# proxy_pass http://192.0.2.254:7616;
# 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_buffers 16 16k;
# proxy_buffer_size 32k;
# }
# --- 追記ここまで ---
include conf.d/505.inc;
include conf.d/favicon.inc;
include conf.d/acme.inc;
include conf.d/profiles.wp.inc;
include conf.d/profiles/common.inc; #### PST Config Insert include common
include conf.d/profiles/default_static.inc; #### PST Config Insert include static
}
server {
include conf.d/ssl_listen.inc;
server_name www.example.com example.com;
set $do_not_cache 0; ## page cache
set $expire_days 90d;
set_real_ip_from 192.0.2.1; # VPS（ダミーIP）を信頼できる中継点として登録
real_ip_header X-Forwarded-For; # 中継された IP を「真の IP」として扱う
ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;
include conf.d/ssl.inc;
## OCSP stapling
ssl_stapling off;
ssl_stapling_verify off;
resolver 8.8.4.4 8.8.8.8 valid=300s;
resolver_timeout 10s;
access_log /home/kusanagi/profiles/log/nginx/ssl_access.log main;
error_log /home/kusanagi/profiles/log/nginx/ssl_error.log warn;
charset UTF-8;
client_max_body_size 2G;
root /home/kusanagi/profiles/DocumentRoot;
include conf.d/505.inc;
include conf.d/favicon.inc;
include conf.d/acme.inc;
include conf.d/profiles.wp.inc;
include conf.d/profiles/common.inc; #### PST Config Insert include common
include conf.d/profiles/default_static.inc; #### PST Config Insert include static
include conf.d/fcache_purge.inc;
location ~ \.php$ {
fastcgi_keep_conn on;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}💡 KUSANAGIの仕様と戦った「3つの急所」
1. コメントアウトに刻まれた「試行錯誤の残像」
Configの25行目あたりにある、丸ごとコメントアウトされた location / { proxy_pass ... } の記述。これは「どっちをフロント（盾）にして、どっちを裏（本尊）にするか」の構築初期、パケットを逆に投げようとして盛大に詰まっていた当時の乱戦の記憶（デバッグの爪痕）がそのまま残っている、生々しい歴史の跡です。
2. 盾（ConoHa）の身元偽装を暴く set_real_ip_from
プロキシを挟むと、普通に設定しただけでは自宅サーバーに届くアクセスの発信元がすべて「ConoHa VPSのIP」になってしまいます。これだと悪質なアクセスがあっても犯人のIPが分からず、アクセス解析も全滅します。 そこで、set_real_ip_from 192.0.2.1;（※実際のVPSのIP）でConoHaを「信頼できる盾」として明記。これにより、ConoHaがパスしてくれた X-Forwarded-For ヘッダーをNginxが自動で剥ぎ取り、自宅側でも「読者の生のIP」を正常にログへと刻むことに成功しました。
3. KUSANAGI独自のインクルード迷宮
KUSANAGI 9は、include conf.d/wordpress.wp.inc; のように、WordPressを動かすためのコアな設定やFastCGIの処理が独自のインクルードファイルへと厳重に隠蔽されている仕様です。このカチカチに固められたシステムテンプレートの隙間に割り込み、手動で外から叩き込まれる特殊ポート（64975番）のlistenを追加し、プロキシ用のヘッダーを正常にPHP（WordPress）に解釈させるまでのミリ単位の微調整こそが、このconfig最大の泥臭い戦いでした。
2-4. 🛠️ 【2章総括】特殊ポート環境を生き抜く「手動DNS-01の儀」
表のConoHa（2-2）でパケットをひねって射出し、裏の自宅サーバー（2-3）でそのねじれを完璧に吸収する。この表裏一体のNginxパズルがカチッと噛み合ったことで、URLの後ろから不格好な特殊ポートが1文字残らず消滅し、美しくスマートな独自ドメインのまま、完璧に 200 OK が開通する瞬間を迎えました。
しかし、インフラの世界は甘くありません。最後に一つだけ、避けて通れない「運用のリアル」が残されていました。それが、自宅サーバー（本尊）側のSSL証明書の維持です。
自宅側を完全なHTTPS（常時SSL挙動）として動かしている以上、裏側に鎮座する本尊の証明書が切れたらブログは一発で即死します。ですが、本尊は特殊ポートに閉じ込められているため、通常のWEB認証（HTTP-01）による自動更新をかけようとすると、プロキシのねじれに巻き込まれて100%エラーを吐いて失敗します。
クラウド側（ConoHa）は自動でいけた。では、自宅側はどうするのか？
その答えこそが、お名前.comのDNSパネルに直接文字を書き込んでドメインの所有権を証明する「手動DNS-01認証」という、泥臭くも確実なラストリゾート（最終手段）でした。
我が家では、以下のCertbotコマンドを自宅サーバー側から直接叩き、お名前.comのDNSを書き換えることで、プロキシを完全にスルーして個別SSL証明書を手動でもぎ取って延命しています。
sudo certbot certonly \
--manual \
--preferred-challenges dns-01 \
-d example.com \
-d *.example.com指示通りにお名前.comの管理画面を開き、TXTレコード（_acme-challenge）をペッと貼り付けて、世界に反映されたらEnterをッターン！と叩く。フロントはConoHaで自動化させつつ、心臓部はこうして確実な手動の手続きでお名前.comのDNSを直接叩いて命を繋ぎ止める。
これにて、我が家のリバースプロキシ要塞は、理論上も運用上も100%完全に「常時稼働できる開通」を迎えたのでした。
2-5. 💸 悲願の1GB回線解約と、二重課金デスゲームへの勝利
技術的なパズルがすべて噛み合い、手動による運用の持続性も完全に証明されたその瞬間。それは我が家のインフラ史における、長きにわたる「二重課金デスゲーム」の完全終了を意味していました。
「よし、これで10G回線一本で完全に生きていける！」
確信を得た翌日、管理人は即座にこれまでブログの生存権を維持するため「だけ」に契約し続けていた、旧1GB回線の解約手続きを行いました。
この旧1GB回線ですが、ファミリータイプ（戸建てタイプ）の回線基本料金が月々7,000円近くかかっていた上に、プロバイダも当然2回線分の契約が必要だったため、そのISP追加料金が毎月1,200円ほどきっちり上乗せされ、トータルで毎月8,200円近くもの固定費が重くのしかかっていました。メインの10G回線側と合わせれば、毎月の通信費だけで16,000円を超えるという、正気の沙汰ではない大赤字状態です。
この「月8,200円」の金食い虫が丸ごと消滅。代わりにフロントの盾として導入したConoHa VPSの「月額800円弱」が加わる形へとインフラコストが劇的に最適化されたのです。コストの置き換えだけで、毎月7,400円以上（年間にして約9万円）の純利益（固定費カット）が確定した瞬間でした。
もちろん、今メインで動いているOCN光 with フレッツ（フレッツ光クロス）10G回線そのものの基本料金（こちらもファミリータイプ＋プロバイダ代で月9,000円程度）は当然発生し続けます。しかし、これまでのように「10G回線とは別に、別の回線代とプロバイダ代をドブに捨て続ける」という異常事態は完全に過去のものとなりました。
結果として、毎月合計9,000円そこそこの適正なコストだけで、「爆速の宅内10G環境」と「24時間365日絶対に途切れないブログ公開基盤」を完璧に両立させることに成功したのです。
クラウドの圧倒的な「安定性」と、自宅サーバー特有の潤沢なマシンパワー・超大容量ストレージ。
その2つが、10G回線のポート制限を完全にバイパスしながら一本の「架け橋（bridge）」で美しく融合した、我が家だけの次世代インフラ要塞の完成です。
──しかし、インフラ屋の業（さが）とは恐ろしいものです。 無事に回線問題が片付いた私は、のんびり余韻に浸る間もなく、すぐさま次なる深淵へと突き進むことになります。
当時の私を現実に引き戻したのは、足元で24時間うなりを上げる「旧・サーバー機」の存在でした。 Windowsの仮想環境に居候させていたとはいえ、その中身はかつてのウルトラハイエンドの遺物──Core i7-6950XにASUS X99 Gamingマザー、臨戦態勢の1200W電源（AX1200i）という、サーバーとして常時稼働させるにはあまりにも非効率なとんでもない電気食い虫だったのです。
前日譚でも触れた通り、10コア20スレッドのパワー自体は今でも十二分に潤沢で、WordPressを回すだけなら何の不満もありません。直近世代の最新パーツに組み替えたところで、体感できる処理性能に大差はないのです。
──しかし、消費電力（電気代）だけは、今の省エネな最新世代と比べたら文字通りダンチ（段違い）。せっかく回線の固定費を最適化したのに、これでは今度はおうちの電気メーターが24時間365日ガリガリ削られていくばかりです。
「性能が変わらないなら、直近世代の効率的なパーツで1から組み直した方が、同じパワーを維持したまま電気代だけを劇的に落とせるはずだ」
そう確信した管理人の行動は早かった。回線問題が片付いたまさにその翌月には、すでに新しいサーバー機のパーツの半分を買い揃えて自宅に転がしていたのです。非効率なシステムを1秒でも長く動かし続けることほど、インフラ屋の精神衛生に悪いものはありません。
回線代の次は、ハードウェアのランニングコスト（電気代）とワットパフォーマンスの超特急最適化へ。
こうして物語は、次なる戦いへと引き継がれるのです。
第3章：大食い旧型機からの脱却。ローコスト最新鋭サーバー機ビルドと、新世代管理ツール「WordOps」への全面移設転生編
3-1. 🛒 始まりはアリエクの衝動ポチ──1ヶ月で揃えたワッパ至上主義の布陣
🛠️ 怒涛の1ヶ月と、リサーチの裏側 ＆ 新生エコマシンの起動テスト
- ネットワーク：Intel X540-T2 (10Gbps PCIe x8) ※初期構成
今回の10G要塞化における最大の主役。ネットをディグっていたところ、AliExpressでなんと本体2,934円＋送料758円（総額3,692円）という、10G対応カードとしてはバグのような破格で転がっているIntelチップ搭載のLANカードを発見。「この値段なら最悪動かなくてもいい」と、人柱覚悟で即座にポチった（※ちなみにこのカード、驚いたことに今でもまだアリエクで普通にこの価格帯で売られている）。これがすべての始まりとなる。 - CPU：Intel Core i3-14100 BOX（アリエクから半月後に入手）
アリエク便の到着を待つ半月の間に、基本パーツの選定を開始。当初はさらにコストを下げるため、一世代前のi3-13100にする予定だった。ところが、ドスパラの製品ページを見つめていたら「なぜか最新の14100の方が安い」という謎の価格逆転現象に遭遇。自作市場特有のバグを確信した瞬間、最速で14100をポチった。 - マザーボード：ASRock B760M Pro RS/D4（CPUと同時に入手）
実は管理人は筋金入りの「ASUS信者」。当然、最初はASUS製でいろいろと吟味していた。コンパクトに収めるためAmazonで良さげなMini-ITXマザーを見つけたものの、仕様を見るとM.2ポートが1つしかなく、将来の拡張性を考えて断念。そこでAI（人工知能）に「Mini-ITXサイズで、M.2が2ポート以上ある高コスパなマザーはないか？」と相談したところ、弾き出された最適解がこのASRock（Micro-ATXだが条件に完璧に合致）だった。手持ちのDDR4メモリ資産をそのまま流用できる（D4仕様）点も含め、AIの提案に納得して浮気することに決めた。 - ストレージ：キオクシア SSD-CK1.0N4B/J (1TB NVMe)（翌週に入手）
CPUとマザーを揃えた翌週、トドメにM.2 SSDを発注。24時間密閉されるサーバー機だからこそ、値段重視でありながら「発熱が低めで、しっかり速度が出るやつ」という条件で探し抜いた結果、最も信頼できる国産のキオクシア（EXCERIA G2）に辿り着いた。
アリエクの衝動ポチから始まったパーツ集めは、わずか1ヶ月で「極限まで無駄を削ぎ落とした実利型・ワッパ構成」の布陣として私の部屋に揃うことになったのです。
パーツが揃えば、あとは組むだけ。 我が家の検証環境の要であるベンチ台の上から、かつての爆熱ハイエンド構成（X99）を下ろし、AIの導きによってやってきた ASRock B760M Pro RS/D4 を新たに鎮座させる。
X99の形見であるDDR4メモリを合計48GB分、デュアルチャネルの作法に合わせてスロットへと突き刺し、発熱の低いキオクシアのM.2 SSDを固定。すべての導火線となった10G LANカード（X540-T2）をPCIeスロットへとドッキングする。
ちなみに、電源に関してはまだ載せ替え作業が終わっておらず、あのウルトラハイエンドの遺物である1200W電源（AX1200i）が現役でそのままシステムを支えている。 物理的にもシステム的にも過剰すぎる巨大電源が横たわっているため、サーバーはケースに収めることなく、ベンチ台の上でむき出しのまま稼働させるスタイルだ。
最小限の構成でベンチ台の上へ組み上がった新・自宅サーバー機に、いざ運命の火を入れる。
サーバー運用の鉄則として「Fast Boot」なんてチャラチャラした機能は当然オフにしているため、起動自体は別に速くもなんともない。じわじわと立ち上がるUEFI（BIOS）の画面を眺め、まずは無事に全パーツがハードウェアレベルで通電・認識していることを確認し、ホッと胸をなでおろす。
しかし、ベンチ台運用のむき出しの環境だからこそ、この「ただ通電させているだけの初期検証」の段階から、教科書通りにはいかないある明確なリスクが牙を剥き始めました。仮組みのまま少し動かしているだけで、LANカードのヒートシンクにふと触れてみた瞬間、指先に走る激痛。
「ｱｯｯﾂ！！！ なんだこれ、尋常じゃなく熱い……！！！」
有名な話ではありますが、Intel X540チップセットは「爆熱仕様の電気食い虫」。カードの購入価格こそ総額3,692円とバグ級に破格でしたが、24時間常時稼働させる自宅サーバーにおいて、このチップ自体が放つ熱量は尋常ではありませんでした。
インフラ屋としてこの熱をそのまま放置するわけにはいきません。そこで私は、12cmファンをベンチ台の横にセットし、爆熱のヒートシンクへ向けてダイレクトに冷風をブチ当てる物理ハックを敢行。強引にチップを冷却する環境を整え、まずは無事に「ハードウェアの起動テスト」をコンプリートしたのです。
──器（ハードウェア）としての骨組みはベンチ台の上に整った。
次なる問題は、このむき出しの最新鋭エコ機の上に、一体どんな「OS」と「ソフトウェア環境」を構築するか、です。
3-2. 📦 さらばKUSANAGI、こんにちはWordOps ── 未知なるDebian系への殴り込みと認証の迷宮
ハードウェアがベンチ台の上で産声をあげ、12cmファンが回り始めたところで、いよいよ本尊であるWordPress環境の構築へと舵を切る。ここからのミッションは、このまっさらな新サーバーに一体何のOSを入れ、どうWeb環境を構築するかだ。
第1章で語った通り、旧環境では『XG-100NE』のポート開放制限に阻まれ、KUSANAGIをVM上で二重運用しながら動かすという地獄を強いられていた。また、過去には「Docker（KUSANAGI Runs on Docker）でコンテナにマウントする」というルートも検証してみたものの、ボリュームマウントやネットワークの挙動がどうにも噛み合わず、何をやっても動く気配すら見出せないレベルの完全な壁にぶち当たった経験もある。そもそも当時の私にとってDockerすら未知の領域で、不具合の切り分けすらままならず撤退したのだ。
だからこそ、今回の新サーバーにおける絶対条件は「VMもDockerも一切挟まず、ベアメタル上でネイティブにWebサーバーを動かすこと」。
そこで一筋の光明となったのが、海外の自作サーバー界隈で評価が高く、ベアメタルのOS上にスクリプト一発でネイティブにインストールできる超軽量管理ツール『WordOps』だった。これならベアメタル上でNginxのキャッシュ環境を極限まで最適化できる。新サーバーにはこれしかない。
しかし、仕様を調べると、このWordOpsはRed Hat系には一切非対応、Debian/Ubuntu専用のツールだったのだ。 これまでずーーーっとCentOS一筋でサーバーを弄ってきた人間であり、直近のCentOS Stream 9も抜群に使いやすくて気に入っていた私にとって、これは非常に切ない現実だった。OS自体には何の不満もなかったのだから。
「……Stream 9は本当に使いやすかったんだけどね。こればかりは致し方なし、か」
惚れ込んだツールをベアメタルで動かすため『だけ』に、最高に使いやすかった相棒（CentOS Stream 9）に後ろ髪を引かれつつも宗旨替えを決意。全く知らんDebian系の文化圏へと殴り込みをかける──こうして、私のソフトウェア編のデスゲームの幕が上がった。
罠その1：最新安定版「Ubuntu 24.04.4」の拒絶
そうと決まればOSとWordOpsのインストールだ。しかし、いざインストーラーを走らせると、内部のPython 3.12環境の仕様変更や依存関係の兼ね合いにより、スクリプトが牙を剥く。画面のログには、無情にもインストーラーの内部コードである variables.py の不具合が走り、メールアドレスの入力待ちプロンプト（wo_email = input("Enter your email: ")）の段階で、システムが完全にハングアップしてしまったのだ。
KeyboardInterruptこの時、力業でCtrl+Cを押して処理をねじ切ったこと、そしてこの瞬間に内部で「中途半端な初期化ファイル」が生成されてしまったことこそが、この後に続く長い長い夜の引き金になるとは、当時の管理人はまだ知る由もなかった。
罠その2：牙をもがれた10Gカード
Ubuntu 24.04のインストールでコケるならその前のバージョンの方が安定しているはず、そう考えてUbuntu 22.04に切り替えてクリーンインストール、ようやくシステムが立ち上がった。よし、これで今度こそWordOpsを……進める前に、私はインフラ屋の習慣としてネットワークのリンク速度を確認した。すると、そこでまたしても想定外の事態に直面する。なんと、アリエクで買ったあの10Gカード（X540-T2）が、なぜか「2.5Gbps」までしか認識していないのだ。
「オイィィ、Intelチップ積んでおいてUbuntuの初期ドライバのままだと牙をもがれるのか」
アジアンプロキシ経由の中華クローンゆえの挙動か、はたまたLinuxカーネルの気まぐれか。私は普通にターミナルから wget でIntel公式のLinux用ドライバ（ixgbe）のソースコードを入手し、そのままコンパイルしてビルド・適用。このごく当たり前のドライバ当て作業を経て、ようやくネットワークインターフェースが本来の力を解放し、バッチリと「10Gbps」の極太土管が開通した。
3-3. 💀 罠その3：発行されないIDとパスワード、そして「再インストール・オンパレード」の地獄
10Gの土管も無事に通り、Ubuntu 22.04の上でWordOps自体のインストールは驚くほどすんなり完了した。そのまま本番のWordPressインストールコマンドを叩く。検証用の仮運用ということで、最初はアカウント名を深く考えず test-user で作成したのだが、この1回目は奇跡的に、画面に管理画面用の初期ユーザーIDとパスワードがパッと発行された。
「これで勝つる！」
そう確信した次の瞬間、すべての地獄の引き金となる、あるインフラ屋の「こだわり」が頭をもたげる。
「ヨシ、テスト起動は完璧だ。でも、この自動生成された管理者アカウント名が test-user のままなのは不細工だな。やっぱり本番用として、別の目当てのアカウント名で綺麗に作り直したい」
環境をクリーンに構築したいがゆえの、ごく自然な欲求だった。私は本番環境を美しく仕上げるため、一度WordOpsをサクッとアンインストールし、アカウント設定を目当ての名前に弄ってから、再びインストールを試みた。
だが、ここから「再インストール・オンパレード」の地獄が始まる。
2回目以降、どれだけコマンドを叩いても、画面のどこを見回してもログイン用のIDとパスワードが一切発行されなくなってしまったのだ。「SUCCESS」と表示されているのに、認証情報だけが虚空に消え去る。
「は？ 嘘だろ？ さっき test-user の時は普通に出たじゃん！」
焦ってアンインストールとインストールを繰り返すも、画面は沈黙を保ったまま。
（※この怪奇現象の真の原因が「最初の1回目にID/パスワードが発行された時点で、システム内部にアカウント情報のファイルが自動生成されており、2回目以降のインストールではそのファイルの残骸があるせいで、コンソールへのパスワード表示処理がスキップされる」という冷徹な仕様トラップだったと知るのは、無事にWordPressが入り、平和な運用が始まってしばらく経ってからの話である）
当時の私はそんな仕様は知る由もない。ツールを単にアンインストールしただけでは、その隠しファイル（過去の遺物）は削除されずにシステムに残る。だからへそを曲げたように二度とパスワードを吐き出さなかったのだ。どこにそのゴミが残っているのか、初見のUbuntuでは切り分けすら不可能な完全なブラックボックスだった。
「……チッ、何が原因か分からん。こうなったらOSごと真っ新にしてやり直しだ！！！」
私は覚悟を決め、Ubuntu 22.04のOSクリーンインストールからすべてをやり直す（物理的にファイルを消し去る）決断を下した。
しかし、OSを入れ直すということは、さっき開通させたばかりの10Gネットワークも初期化されることを意味する。
OSを入れる ➔ ネットワークが2.5Gに丸め込まれる ➔ ターミナルから wget でIntel公式ドライバを引っ張ってくる ➔ ixgbe をコンパイルしてビルド・適用して10Gを開通させる ➔ 再びWordOpsを仕込む ➔ スクリプトを叩く ➔ またしても設定変更のタイミングを誤り、パスワードが出ない。
「オィマジかよ！？ 何でだよ！？ まだダメなのかよ！？」
原因が一切分からないまま、「WordOpsインストール ➔ 出ない ➔ アンインストール ➔ OSから入れ直し ➔ ドライバビルド」という、1周するだけでも気が遠くなるようなフルコースのセットを、文字通りオンパレードで数回にわたって何度も何度もループさせたのだ。深夜の部屋に、キーボードを叩く音とベンチ台の12cmファンの風切り音だけが虚しく響く。
──傷だらけになりながら挑んだ、何度目かのクリーンインストールループの果て。 今度こそ1ミリのミスもなく、目当てのアカウント名が一発で通るように設定を完璧に整え、祈るようにコマンドを叩いた。次の瞬間、画面に待望の【WordPress username / WordPress password】の文字列がババッと綺麗に吐き出された。
「……出た、やっと、やっと繋がった……！！」
気がつけば、この未知のOSでの再インストール・オンパレード、初期ドライバとの格闘、数回におよぶOSフォーマットの全行程。時間にすれば、文字通り一昼夜。 画面の前で一歩も引かずに執念で駆け抜けた、濃密すぎる丸一日の限界バトルの果てに、私の足元（ベンチ台）には、ついに「電気代を極限まで削ぎ落とし、10Gの超極太土管を従え、最軽量のキャッシュサーバーで武装した、名実ともに完全体の新型WordPressサーバー」が、静かに、そして爆速で産声をあげたのだった。
だが、インフラ屋の夜明けはまだ遠い。 OSとミドルウェアという「個体」が組み上がったに過ぎず、外部のインターネットからこの新サーバーへトラフィックを引き込むための「道」は、いまだ遮断されたままである。
息をつく暇もなく、お名前.com、ConoHa VPS、リストア、そして宅内Nginxのすべてを巻き込む、壮絶なネットワーク切り替えの「第2回戦」のゴングが鳴り響いた。
3-4. 🌐 お名前.com・ConoHa・WordOps ── ネットワーク固定化とNginx「第2回戦」
自宅のベンチ台の上でUbuntuとWordOpsという「本営」が覚醒した。しかし、これだけでは外部のインターネットから我が家のブログへは繋がらない。
外部からのアクセスを一番最初に受け止める防衛線であり、宅内へとパケットをバイパスする役割を持つ中継基地「ConoHa VPS」のリバースプロキシ設定、そしてお名前.comのDNSを、新サーバー（192.168.1.80：64975）の構成へと完全に作り替える必要があるからだ。
長年稼働し続けていた本営（www.ice-military.com）のサイトを、リプレイス作業のために一時的に停止させる。とはいえ、インフラ屋として無謀な一発勝負の賭けに出るつもりは毛頭ない。「なんか怪しい挙動があれば、割とすぐ止める」のが大事故を防ぐための鉄則だ。
だが、ひとたび止めて賽が投げられた以上、そこからはフットワークの軽さと引き換えに、「あっちを立てればこっちが立たず」の連発による壮絶な泥沼戦へと引きずり込まれることになった。
そんなヒリつくフットワークの軽さと執念を胸に、スマートかつ迅速に「遷都の儀」へと突入した。
私は Tera Term から中継基地である ConoHa VPS（[ConoHa-VPS]） へとログインし、設定ファイルを書き換えていく。同時に自宅ルーター（XG-100NE）側のIPマスカレード（ポート転送）も連動させるが、繋いだ瞬間からエラーの連鎖が牙を剥く。
「あっちを立てればこっちが立たず」の連発。ConoHaのフロント側で443（HTTPS）のSSLを受け止め、そこから自宅の特殊ポートである 64975番 をめがけてパケットを串（プロキシ転送）。自宅側はその64975番でパケットを受け止め、そこから内部の443番へとマスカレード（ポート変換）させてWordOpsの「443 ssl」コアコンフィグへと着地させるという、極めて変則的かつ緻密な多層ルーティング構造。
この構造のせいで、Nginxの設定を少し調整すればWordPress側が「自分は今どのポートのどのプロトコルで動いているんだ？」と大混乱を起こして無限リダイレクトループに陥り、画面が真っ白になる。どこか1箇所を立てれば別のレイヤーがへそを曲げてエラーを吐き出す、終わりなきコンフリクトの無限ループ。
使い慣れたCentOS系ならアタリがつけられるエラーも、こちらは初見のUbuntu環境。決してサクサクとスマートに進んだわけではない。ディレクトリの構造やコマンドの勝手の違いに戸惑い、画面の向こうで次々と発生する想定外の挙動に冷や汗を流しながら、手探りで一つ一つ原因を調べ、泥臭くロジックをねじ伏せていく執念の復旧作業となった。
Lineの向こうで次々と発生する想定外の挙動。しかし、管理人は一歩も引かなかった。「すぐ止める」冷静さで傷口を最小限に抑えつつ、持てる全力を注ぎ込んで1つずつロジックをねじ伏せていく。
そして──すべての土管が一本の直線に繋がり、Nginxが最後のリロードを受け入れた瞬間、ブラウザの画面には新サーバーのWordOps上で完全覚醒した、完璧にセキュアな本営（www.ice-military.com）のトップ画面、Hello World!の文字が一瞬で描写された。
「……ｯｼｷﾀｧ！完全開通だ！！！」
🛠️ ［技術的知見］結実した三位一体のルーティング資産
「なんか動いたからヨシ！」で記憶は揮発したものの、泥沼のコンフリクトをねじ伏せて完成した「ConoHa（リバプロ） ➔ 自宅ルーター ➔ WordOps（本営）」の最終的な設定こそが、この記事最大の技術的資産だ。後続のインフラ屋のために、本番稼働に成功した最終的な構成をここに書き残しておく。
1. お名前.com（DNS設定）
本営ドメインのネームサーバー（DNS）にて、すべてのトラフィックの玄関口を自宅ではなく、固定IPを持つ「ConoHa VPS」へと向ける。
www.ice-military.com➔Aレコード➔ [ConoHa VPSのグローバルIP]
2. 中継基地：ConoHa VPS側（Nginxリバースプロキシ設定）
外部からの443（HTTPS）パケットをLet’s Encryptで安全に受け止め、プロキシヘッダーを1ミリの狂いもなく付与した上で、自宅の10Gルーターが待ち受ける「64975番ポート」へとバイパスさせる中継地点の設定。
server {
listen 443 ssl http2;
server_name www.example.com;
# Let's Encrypt SSL設定
ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;
location / {
# 自宅ルーター経由で本営の64975番ポートへと「串」を通す
proxy_pass http://[自宅のグローバルIP]:64975;
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;
# 504 Gateway Timeout対策
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
}
}3. 本営：自宅新サーバー側（WordOps / Nginx設定）
自宅ルーター（XG-100NE）の静的IPマスカレードにて「外部ポート64975 ➔ 内部192.168.1.80の443番」へとそのままフォワーディングされたパケットをキャッチ。
そこから本営内部の443番へとマスカレード（ポート変換）させて流し込み、WordOps標準の強力なPHP8.3高速化 include 郡と連動。すでに公式の配布が終了してしまった貴重なツールやソフトのアーカイブ（大容量ZIP等）を自サーバー内で完結してホスト・高速配信しつつ、何者にも邪魔させない、実戦投入された本営の真のコアコンフィグ。
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
server_name example.com www.example.com;
# 自宅側本営のLet's Encrypt SSL設定
ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;
root /var/www/example.com/htdocs;
index index.php index.html index.htm;
# --- WordOps 標準の高速化 include 設定 ---
include common/php83.conf;
include common/wpcommon-php83.conf;
include common/locations-wo.conf;
include /var/www/example.com/conf/nginx/*.conf;
# 自前でホストする配布終了ツールのZIP等の安定した格納・ハンドリングに備えた超極太マージン
client_max_body_size 2G;
access_log /var/log/nginx/example.com.access.log rt_cache;
error_log /var/log/nginx/example.com.error.log;
# プロキシ環境下（64975 ➔ 443マスカレード）でのHTTPS認識を強制する
fastcgi_param HTTPS on;
}さらに、WordPress本尊（wp-config.php）の最頭部に以下のコードを注入したことで、リバプロ経由のパケットをWordPress側が正しく「HTTPS環境下のアクセス」だと認識し、画面が真っ白になる無限ループ地獄は完全に終わりを告げた。
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}第4章. 💰 月2万5千円からの脱却！新生エコ10Gサーバー、驚異の最終リザルト編
すべての罠、すべての仕様の闇、そして「あっちを立てればこっちが立たず」の空中戦をねじ伏せた強行軍。その果てに勝ち取った、すべてが報われるリザルト発表の時が来た。
■ 1. コスト＆消費電力リザルト：二重課金デスゲームの完全終了
旧システム（X99）時代は、空調（エアコン）を除いたサーバー単体の電気代だけで「月2万5千円〜」という絶望的なランニングコストに加え、インフラ維持（ブログの生存権維持）のためだけに、メインの10G回線とは別に、旧1GB回線を維持し続けるという正気の沙汰ではない大赤字状態（二重課金デスゲーム）だった。
それが、今回の新型エコサーバー（Core i3-14100 / メモリ48GB / WordOps）への完全リプレイスを遂げ、固定費の大鉈を振るった結果、驚異の最終リザルトが叩き出される。
- 電気代リザルト：
- 旧環境（X99）：月25,000円〜（空調抜きの絶望）
- 新環境（i3）：月17,000円前後（空調・エアコン費まで【すべて込み】の超平和） ➔ 【毎月約8,000円の浮き！】
- 通信費リザルト： 技術的なパズルがすべて噛み合い、手動による運用の持続性も完全に証明された瞬間。「よし、これで10G回線一本で完全に生きていける！」と確信を得た翌日、これまでブログの生存権を維持するため「だけ」に契約し続けていた、旧1GB回線の解約手続きを即座に執行。 ファミリータイプの回線基本料金（月々約7,000円）に、プロバイダ（ISP）追加料金（毎月約1,200円）が重くのしかかっていた【毎月合計8,200円】の金食い虫が丸ごと消滅。代わりにフロントの盾として導入したConoHa VPSの【月額800円弱】が加わる形へとインフラコストを劇的に最適化。コストの置き換えだけで、毎月7,400円以上（年間にして約9万円）の純利益（固定費カット）が確定した。
★ トータル維持費リザルト：毎月「計15,400円前後（年間約18万5千円）」の圧倒的コストカットに成功！
今メインで動いているOCN光 with フレッツ（フレッツ光クロス）10G回線そのものの基本料金（ファミリータイプ＋プロバイダ代で月9,000円程度）は当然発生し続けるものの、これまでの「別の回線代とプロバイダ代をドブに捨て続ける」という異常事態は完全に過去のものとなった。
結果として、部屋全体のエアコン代まで全てガチでひっくるめてなお電気代が激減した上に、回線解約による通信費の劇的最適化が炸裂。毎月合計9,000円そこそこの適正なコストだけで、「爆速の宅内10G環境」と「24時間365日絶対に途切れないブログ公開基盤」を完璧に両立させるという、エコインフラとしての完全大勝利を収めたのだ。
■ 2. ネットワークリザルト：10G（クロス）＋ X540-T2 が叩き出す爆速の数字
すべてのインフラ最適化、そして「なんか動いたからヨシ！」の執念のデバッグの果てに、新生本営ベアメタル環境（Ubuntu / Core i3-14100 / X540-T2）のポテンシャルを完全開放する時が来た。
1回線に一本化したフレッツ光クロス（10G）の実力を測定すべく、ターミナルから speedtest コマンドを撃ち込む。IPA CyberLabの400G超巨大バックボーンを相手に、最新10Gカードが叩き出した実測ベンチマークの数字は、まさに驚天動地のリザルトだった。
Speedtest by Ookla
Server: IPA CyberLab 400G - Tokyo (id: 48463)
ISP: Open Computer Network
Idle Latency: 5.58 ms (jitter: 0.13ms, low: 5.18ms, high: 5.66ms)
Download: 7783.71 Mbps (data used: 8.2 GB)
31.62 ms (jitter: 25.32ms, low: 4.76ms, high: 350.36ms)
Upload: 6585.13 Mbps (data used: 8.2 GB)
12.82 ms (jitter: 28.31ms, low: 4.47ms, high: 240.31ms)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/6aae6f05-3469-4b1e-9279-ae985f2e1699驚異の下り「7.7Gbps（7783.71 Mbps）」オーバー！！！
実測データ使用量8.2GBのパケットを文字通り一瞬で吸い込み、上りも「6.5Gbps（6585.13 Mbps）」という異次元の速度を記録。これほどの超暴走帯域を誇りながら、パケットロスは完全なる「0.0%」。執念で最新ドライバをビルドし、ベアメタルUbuntuでX540-T2カードをネイティブにドライブさせた苦労が、この上ない形で完全証明された瞬間だった。
電気代を月17,000円（エアコン込み）まで削ぎ落とし、無駄な旧回線を解約して年間約9万円の純利益を確定させ、その上で手に入れたのが、この「下り7.6Gbps」という国内最速クラスの超極太配信土管。
もうWordPress君が何と言おうと、どれだけ大容量の歴史的アーカイブZIPをホストしようと、中継基地（ConoHa）を経由した10Gネイティブの最強インフラが、世界中からのリクエストを圧倒的なレスポンスで一瞬でさばき切る。
コスト、熱、仕様の罠、そしてネットワークの空中戦──そのすべてをロジックとフットワークでねじ伏せた丸二日の強行軍。私の足元で、静かに、そして爆速の青い光を放ちながら、名実ともに「完全体」となった我が家の新型本営サーバーが、インフラ史に新たな伝説を刻み込んで咆哮していた。
──自宅サーバー遷都物語、これにて完全大勝利の終幕。
コメント