WP Panel にシステムカーネル最適化を追加、BBR+FQ をデフォルトで有効化、越洋アクセス成功率が 13% 向上

聴取Diiamoの提案を受け、WP Panelパネルのインストールスクリプトにシステムカーネル最適化工程を追加しました。インストール完了後、選定されたネットワークとカーネルチューニングパラメータ（BBR+FQ、TCPバッファ、接続キュー、ファイルディスクリプタ）が自動適用されます。

最適化項目一覧

シングルコアマシンはBBRをスキップ：学術研究によると、CPU がホストの隣接プロセスに占有されるシングルコア VPS では、BBR のスループットが低下する可能性があります。WP Panel のインストールスクリプトは自動的に CPU コア数を検出し、シングルコア環境ではシステムデフォルトの Cubic を維持し、強制的に置き換えません。

コア最適化：BBR + FQ

BBR とは？

BBR（Bottleneck Bandwidth and Round-trip propagation time）は Google が開発した TCP 輻輳制御アルゴリズムです。Linux カーネルのデフォルトである Cubic アルゴリズムは 2006 年に誕生し、その中核ロジックは"パケットロス = 輻輳"であり、パケットロスを検出すると大幅に速度を落とします。これは光ファイバーが普及し、無線ネットワークが主流となった現在では時代遅れです。パケットロスは必ずしも輻輳によるものではなく、無線信号の変動や物理回線のノイズが原因である可能性があります。

BBR はパケットロスを輻輳のシグナルと見なさず、代わりにネットワークのボトルネック帯域幅和とを継続的に測定し、それに基づいて送信速度を制御します。結果として、パケットロスはあるが帯域幅が十分な長距離リンクでは、BBR のスループットは Cubic を大幅に上回ります。

なぜ FQ との併用が必要か？

FQ（Fair Queue）は Linux カーネルの公平キューイングスケジューラです。BBR は正確なパケット送信レート制御に依存しており、FQ を併用しないと、カーネルは高精度タイマーモードにフォールバックし、各接続で余分な CPU オーバーヘッドが発生します。両方を同時に有効にする必要があります。

BBR は通常のサーバーでそのまま使えるか？

完全にそうとは限りません。Debian 13 のカーネルには BBR モジュールが組み込まれています（tcp_bbr）が、デフォルトでは有効になっていません。手動で sysctl 設定 + カーネルモジュールのロードが必要です。WP Panel のインストールスクリプトがこの手順を自動化しています。

比較テスト

テスト環境

特別な注意点：Vultr の Debian 13 イメージはデフォルトで BBR が有効になっています。Cubic グループのマシンで手動で sysctl -w net.ipv4.tcp_congestion_control=cubic を実行して BBR を無効にした後、比較を行いました。

低負荷テスト（2 スレッド / 10 接続 / 30 秒）

両方のサーバーで同一の WordPress サイトを運用。テストマシンは国内から HTTPS リクエストを発行し、実際の訪問者が太平洋を越えてサイトにアクセスする状況をシミュレート。

wrk -t2 -c10 -d30s https://bbr.wp-panel.org/
wrk -t2 -c10 -d30s https://nobbr.wp-panel.org/

平均遅延が高いのに、結果が良いのはなぜ？

直感に反するデータ：BBR グループの平均レイテンシは 793ms、Cubic グループは 524ms。一見 Cubic の方が速い？

実際には、太平洋を越えるリンクでは避けられないランダムパケットロスが発生。Cubic はパケットロスを輻輳とみなし、ロスが発生すると速度を半減させ、低下後はタイムアウトで諦める——テストでは 41 リクエストが直接失敗し、平均レイテンシの統計に含まれていない。Cubic の"低レイテンシ"は、実際には遅いリクエストを除外した生存者バイアス。

BBR はパケットロスを輻輳とみなさず、安定した送信ペースを維持するため、ほぼすべてのリクエストが正常に完了。367 リクエスト中タイムアウトは 1 回のみで、成功率 99.7%。一方、Cubic の 313 リクエスト中 41 回失敗し、成功率は 86.9% にとどまる。

言い換えれば：BBR は各リクエストを高速化するのではなく、より多くのリクエストを完了させるためのものです。

BBR を過信しないでください

テストでは BBR は成功率で Cubic に完勝しましたが、これは BBR を有効にすればサイトが劇的に改善されることを意味するわけではありません。

BBR が最適化するのは TCP トランスポート層、つまりデータが"どのようにサーバーから送信されるか"です。その上限はサーバーのハードウェア構成とネットワーク帯域に制限されます。1コア1GB、10Mbps 帯域の VPS では、どの輻輳制御アルゴリズムを使っても 100Mbps の効果は出せません。

サイトの体感を本当に決める要素を優先順位順に並べると：

1. ハードウェアと帯域 — CPU コア数、メモリ容量、ネットワーク帯域が物理的な天井
2. サーバー全体の最適化 — Nginx 設定、PHP-FPM プロセス管理、データベースインデックス、Redis キャッシュ、Swap 戦略、ファイルディスクリプタ制限… WP Panel インストールスクリプトがこれらを一括カバー
3. TCP 輻輳制御 — つまり BBR は、あくまで「錦上添花」（良い上にさらに良くする）であり、「雪中送炭」（緊急時の助け）ではありません

BBR をトランスミッションのチューニングに例えると、エンジンの動力をより効率的にホイールに伝えられるようにするものです。しかし、エンジン自体が小排気量であれば、どんなにチューニングしても 5 秒以内に 100km/h に達することはできません。

WP Panel のシステムカーネル最適化モジュールが BBR をデフォルトにしているのは、それが確実に有益でコストゼロ——追加のハードウェア不要、追加費用不要、メンテナンス不要だからです。しかし、これはパネル全体の最適化計画の一部であり、すべてではありません。

単一ファイルダウンロードテスト

curl -o /dev/null -w "%{speed_download}" https://****/twentytwentyfive/style.css

3回ダウンロードして平均（単位：B/s）：

小ファイルのダウンロード速度、BBR 平均で約 8.8% 高速。

まとめ

WP Panel 今回追加されたシステムカーネル最適化の核心は、BBR + FQ をデフォルトのネットワーク転送方式とすることです。WordPress サイトの場合、訪問者はさまざまなネットワーク環境に分散しており、地域間やキャリア間のアクセスは避けられません。BBR がこのシナリオで持つ利点——サイトを高速化するのではなく、より多くの人がスムーズに開けるようにする。

まだ BBR を有効にしていない場合、手動で有効にするには次の2行のコマンドを実行するだけです：

echo "net.core.default_qdisc=fq" >> /etc/sysctl.d/99-bbr.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.d/99-bbr.conf
sysctl --system
modprobe tcp_bbr

または、直接WP Panel インストールスクリプトを使用すれば、すべての最適化が自動的に完了します。