聴取Diiamoの提案を受け、WP Panelパネルのインストールスクリプトにシステムカーネル最適化工程を追加しました。インストール完了後、選定されたネットワークとカーネルチューニングパラメータ（BBR+FQ、TCPバッファ、接続キュー、ファイルディスクリプタ）が自動適用されます。
最適化項目一覧
| カテゴリー | 最適化項目 | 効果 |
|---|---|---|
| 輻輳制御 | BBR + FQ（2コア以上でデフォルト有効） | カーネルデフォルトのCubicアルゴリズムを置き換え、高遅延・パケットロス環境でのスループットを向上 |
| 接続キュー | somaxconn / tcp_max_syn_backlog / netdev_max_backlog | バーストトラフィック時に接続要求をドロップしない |
| TCPバッファ | rmem_max / wmem_max / tcp_rmem / tcp_wmem | ネットワーク送受信バッファを増やし、大容量ファイル転送速度を向上 |
| TIME-WAIT | tcp_tw_reuse / tcp_fin_timeout / ポート範囲拡大 | 接続回収を加速し、ポート枯渇を軽減 |
| Keepalive | アイドル検出間隔を短縮 | デッド接続を迅速にクリーンアップし、サーバーリソースを解放 |
| ファイルディスクリプタ | nofile 65535 | 単一プロセスのファイルオープン数制限を解除し、高並行処理をサポート |
| 基本セキュリティ | tcp_syncookies / tcp_sack / tcp_timestamps | SYN flood防御 + 選択確認 + タイムスタンプ |
シングルコアマシンは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 のインストールスクリプトがこの手順を自動化しています。
比較テスト
テスト環境
| BBR グループ | Cubic グループ | |
|---|---|---|
| サービスプロバイダー | Vultr | Vultr |
| データセンター | シカゴ | シカゴ |
| インスタンスタイプ | 共有 CPU、2 コア 2GB、65GB SSD | 共有 CPU、2 コア 2GB、65GB SSD |
| OS | Debian 13 | Debian 13 |
| 輻輳制御 | BBR | Cubic（Vultr はデフォルトで BBR を有効にしていますが、手動で無効にしてテストしました） |
| キューイングアルゴリズム | FQ | FQ |
特別な注意点：Vultr の Debian 13 イメージはデフォルトで BBR が有効になっています。Cubic グループのマシンで手動で
sysctl -w net.ipv4.tcp_congestion_control=cubicを実行して BBR を無効にした後、比較を行いました。
| テストクライアント | |
|---|---|
| サービスプロバイダー | Tencent Cloud |
| データセンター | 広州 |
| インスタンスタイプ | 軽量クラウドサーバー |
| テストツール | wrk 4.1.0、curl |
低負荷テスト（2 スレッド / 10 接続 / 30 秒）
両方のサーバーで同一の WordPress サイトを運用。テストマシンは国内から HTTPS リクエストを発行し、実際の訪問者が太平洋を越えてサイトにアクセスする状況をシミュレート。
wrk -t2 -c10 -d30s https://bbr.wp-panel.org/
wrk -t2 -c10 -d30s https://nobbr.wp-panel.org/
| 指標 | BBR | Cubic | BBR の優位性 |
|---|---|---|---|
| 平均レイテンシ | 793.08 ms | 524.09 ms | — |
| 総完了リクエスト数 | 367 | 313 | +17.3% |
| 1秒あたりのリクエスト数 | 12.22 | 10.43 | +17.2% |
| 1秒あたりの転送量 | 828.88 KB | 712.44 KB | +16.3% |
| タイムアウトリクエスト数 | 1 | 41 | 97.6% 減少 |
| リクエスト成功率 | 99.7% | 86.9% | +12.8 パーセントポイント |
平均遅延が高いのに、結果が良いのはなぜ？
直感に反するデータ：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 の効果は出せません。
サイトの体感を本当に決める要素を優先順位順に並べると：
- ハードウェアと帯域 — CPU コア数、メモリ容量、ネットワーク帯域が物理的な天井
- サーバー全体の最適化 — Nginx 設定、PHP-FPM プロセス管理、データベースインデックス、Redis キャッシュ、Swap 戦略、ファイルディスクリプタ制限… WP Panel インストールスクリプトがこれらを一括カバー
- TCP 輻輳制御 — つまり BBR は、あくまで「錦上添花」（良い上にさらに良くする）であり、「雪中送炭」（緊急時の助け）ではありません
BBR をトランスミッションのチューニングに例えると、エンジンの動力をより効率的にホイールに伝えられるようにするものです。しかし、エンジン自体が小排気量であれば、どんなにチューニングしても 5 秒以内に 100km/h に達することはできません。
WP Panel のシステムカーネル最適化モジュールが BBR をデフォルトにしているのは、それが確実に有益でコストゼロ——追加のハードウェア不要、追加費用不要、メンテナンス不要だからです。しかし、これはパネル全体の最適化計画の一部であり、すべてではありません。
単一ファイルダウンロードテスト
curl -o /dev/null -w "%{speed_download}" https://****/twentytwentyfive/style.css
3回ダウンロードして平均（単位：B/s）：
| 回数 | BBR | Cubic |
|---|---|---|
| 第 1 回 | 3,885 | 3,403 |
| 第 2 回 | 2,311 | 2,286 |
| 第 3 回 | 4,628 | 4,263 |
| 平均 | 3,608 | 3,317 |
小ファイルのダウンロード速度、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 インストールスクリプトを使用すれば、すべての最適化が自動的に完了します。