Linuxのネットワーク高速化というと、以前は「/etc/sysctl.confへ大量の設定を追記する」「TCPバッファを大きくする」「BBRとfqを固定する」「NICオフロードを全部ONにする」といった方法が定番でした。
しかし、2026年現在のLinuxカーネルは、TCPバッファの自動調整、TCP pacing、NICキュー、輻輳制御、qdiscなどを標準で高度に制御しています。
環境を確認せずに数値を一括変更すると、通信速度が上がるどころか、Loaded latencyの増加、短い通信の速度低下、メモリ消費、パケットドロップ、VPNや仮想NICへの誤適用などを引き起こすことがあります。
そこで本記事では、Linuxのネットワーク設定を「確認→一時変更→実測→比較→必要な設定だけ永続化」の順番で見直します。
対象はUbuntu、Linux Mint、Debian系Linuxを中心にしていますが、sysctl、iproute2、ethtoolを利用できる一般的なLinuxでも考え方は共通です。
- 簡単に設定したい人へ
- 旧記事の一括設定をそのまま使わない理由
- 最初にネットワーク構成を確認する
- 現在の設定を保存する
- 現在のTCP輻輳制御とqdiscを確認する
- CUBICとBBRの違い
- fqとfq_codelの違い
- 設定は一時的に切り替えて比較する
- 正しい比較方法
- TCPバッファを大きくすれば速くなるとは限らない
- netdev_max_backlogはドロップを確認してから
- NICオフロードは全部ON・全部OFFにしない
- NICリングバッファは最大値を確認する
- RPS・RFS・RSSはCPUボトルネックがある場合だけ
- tcp_mtu_probingを常時2にしない
- サーバー向け設定とデスクトップ向け設定を分ける
- 勝者が決まった後だけ永続化する
- 元へ戻す方法
- 2026年版の結論
- 参考資料
簡単に設定したい人へ
コマンドを一つずつ切り替えて、CUBIC、BBR、fq、fq_codelを何度も測定するのは大変です。
簡単に診断・比較・最適化したい場合は、筆者が開発した「Tenyendama Linux Network Optimizer」を利用してください。
現在の設定を保存したうえで候補を一時適用し、速度、Loaded latency、p05、p95、変動係数、遅延スパイクを比較します。
さらに、HTTP/3・QUICをTCP比較から除外し、IPv4・IPv6の通信が実際にどのNICを通ったか確認します。
探索テストと確認テストの両方で明確な改善が再現した場合だけ、設定を永続化するか確認されます。
差が小さい場合、通信経路を確認できない場合、VPNや別NICを経由した場合は、現在の設定を維持します。
導入方法と使い方はこちらです。
GitHubリポジトリはこちらです。
以降は、Linuxネットワーク設定を手動で確認・比較したい人向けの解説です。
旧記事の一括設定をそのまま使わない理由
以前の記事では、次のような設定をまとめて適用していました。
- TCP送受信バッファを32MiBへ拡大
- netdev_max_backlogを250000へ拡大
- BBRとfqを固定
- tcp_timestampsを無効化
- tcp_tw_reuseを有効化
- tcp_mtu_probingを常時有効化
- TSO・GSO・GROをまとめて有効化
これらは特定の高帯域・高遅延回線、サーバー、受信処理が追いつかないNICなどで有効になる可能性があります。
一方で、一般的なデスクトップPCや家庭回線へ一律適用する根拠にはなりません。
たとえば、net.core.netdev_max_backlogは、NICが受信したパケットをカーネルが処理しきれないときにINPUT側へ保持する最大数です。
受信ドロップやsoftnet dropが発生していない環境で極端に増やしても、通信そのものが速くなるとは限りません。
また、tcp_timestampsのLinux標準値は有効です。tcp_tw_reuseについても、Linuxカーネルの公式ドキュメントは専門家の助言や明確な要請なしに変更しないよう注意しています。
TCP Fast Open、PMTU probing、socket bufferにも用途と副作用があるため、まとめて高速化設定として扱わないほうが安全です。
最初にネットワーク構成を確認する
ネットワーク設定を変更する前に、デフォルトルートと実際の物理NICを確認します。
ip route show default
ip -6 route show default
ip -details link show
一般的な環境では、次のように物理NICが表示されます。
default via 192.168.1.1 dev enp1s0
bridgeを利用している環境では、ルーティングインターフェースと物理NICが異なる場合があります。
default via 192.168.1.1 dev bridge0
この場合、物理NICを確認します。
bridge link show master bridge0
たとえば「bridge0 → enp1s0」という構成なら、IPアドレスとデフォルトルートはbridge0にあり、qdiscやNICオフロードを調整する対象はenp1s0です。
bridge0側に「qdisc noqueue」と表示されても、bridgeデバイスとしては異常とは限りません。
bondを利用している場合：
cat /proc/net/bonding/bond0
VLANや仮想リンクを確認する場合：
ip -details link show
VPN、Wi-Fi、有線LANが同時に接続されている場合は、実際の接続先への経路も確認してください。
ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111
現在の設定を保存する
変更前の状態を記録します。
mkdir -p "$HOME/linux-network-backup"
sysctl net.ipv4.tcp_available_congestion_control \
net.ipv4.tcp_congestion_control \
net.core.default_qdisc \
net.core.rmem_max \
net.core.wmem_max \
net.ipv4.tcp_rmem \
net.ipv4.tcp_wmem \
net.ipv4.tcp_mtu_probing \
net.core.netdev_max_backlog \
| tee "$HOME/linux-network-backup/sysctl.txt"
tc qdisc show \
| tee "$HOME/linux-network-backup/qdisc.txt"
ip -details link show \
| tee "$HOME/linux-network-backup/link.txt"
ip -s link show \
| tee "$HOME/linux-network-backup/link-statistics.txt"
物理NICを「enp1s0」とした場合、ethtoolの状態も保存します。
sudo apt install ethtool
ethtool enp1s0 \
| tee "$HOME/linux-network-backup/ethtool.txt"
ethtool -k enp1s0 \
| tee "$HOME/linux-network-backup/offload.txt"
ethtool -g enp1s0 \
| tee "$HOME/linux-network-backup/ring.txt"
ethtool -S enp1s0 \
| tee "$HOME/linux-network-backup/nic-statistics.txt"
現在のTCP輻輳制御とqdiscを確認する
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
tc qdisc show dev enp1s0
「net.core.default_qdisc」は既定qdiscですが、sysctlの値を変更しても、稼働中の物理NICのqdiscが直ちに切り替わるとは限りません。
実際の状態は、必ず「tc qdisc show dev 物理NIC名」で確認してください。
CUBICとBBRの違い
CUBIC
CUBICは多くのLinux環境で標準的に使われるTCP輻輳制御です。
幅広いネットワーク条件で安定しやすく、家庭回線、Web閲覧、ダウンロード、短い通信を含む一般用途の基準として使いやすい方式です。
BBR
BBRは帯域幅と往復遅延を推定しながら送信量を制御するTCP輻輳制御です。
高帯域・高遅延の経路や大容量転送で有利になることがありますが、すべての回線でCUBICより速くなるわけではありません。
利用可能か確認します。
sudo modprobe tcp_bbr
sysctl net.ipv4.tcp_available_congestion_control
次のように「bbr」が表示されれば比較できます。
reno cubic bbr
表示されない場合は、カーネルの構成やモジュールを確認してください。外部カーネルへ安易に入れ替える前に、現在のディストリビューションが提供するカーネルで対応状況を確認することを推奨します。
fqとfq_codelの違い
fq
fqはフローを分離し、TCPスタックが要求するpacingを扱えるqdiscです。
ローカルPCから発生する通信の公平性やpacingを重視する構成で、BBRと組み合わせて比較されることも多い方式です。
fq_codel
fq_codelはFair QueuingとCoDelのAQMを組み合わせ、フロー間の公平性とキュー遅延の制御を行います。
通信速度の最大値よりも、混雑時の応答性やbufferbloat対策を重視する環境で候補になります。
ただし、ホストPCのqdiscだけで、ルーターや回線終端に発生するすべてのbufferbloatを解消できるわけではありません。
実際のボトルネックが家庭用ルーターや上り回線にある場合は、ルーター側のSQMやCAKEなどが必要になることがあります。
設定は一時的に切り替えて比較する
いきなり/etc/sysctl.confや/etc/sysctl.dへ保存せず、まず一時適用します。
CUBIC＋fq
sudo sysctl -w net.ipv4.tcp_congestion_control=cubic
sudo tc qdisc replace dev enp1s0 root fq
BBR＋fq
sudo modprobe tcp_bbr
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo tc qdisc replace dev enp1s0 root fq
CUBIC＋fq_codel
sudo sysctl -w net.ipv4.tcp_congestion_control=cubic
sudo tc qdisc replace dev enp1s0 root fq_codel
切り替えるたびに実効値を確認します。
sysctl net.ipv4.tcp_congestion_control
tc qdisc show dev enp1s0
既に確立しているTCP接続では、変更前の輻輳制御が残る場合があります。
設定変更後はブラウザや測定アプリの接続を作り直し、新しいTCP接続で測定してください。
正しい比較方法
ネットワーク速度テストは、測定サーバー、ISP経路、時間帯、バックグラウンド通信などによって大きく変動します。
一回の最大値だけで設定を選ばないでください。
測定前の準備
- クラウド同期、OS更新、動画再生、ダウンロードを停止する
- 有線とWi-Fiを同時利用している場合は経路を確認する
- VPNやプロキシを停止する
- 同じ測定サーバー、同じブラウザ、同じ条件を使う
- 最初の一回はウォームアップとして集計から外す
A-B-A方式で比較する
たとえば、CUBICとBBRを比較する場合は次の順番にします。
CUBIC
BBR
CUBIC
BBR
CUBIC
BBR
CUBICを三回まとめて測り、その後BBRを三回測る方法では、時間経過による回線状態の変化が設定差に混ざります。
各構成を交互に測定し、最低でも三回分の中央値を比較してください。
見るべき指標
- 下り速度の中央値
- 上り速度の中央値
- 遅い側の値であるp05
- Idle latency
- Loaded latencyの中央値
- Loaded latencyのp95
- 100msを超える遅延スパイク
- 測定ごとのばらつき
「一回だけ900Mbps」より、「毎回700Mbps前後でLoaded latencyも安定する」構成のほうが、日常利用では快適な場合があります。
HTTP/3・QUICに注意する
BBRとCUBICはTCPの輻輳制御です。
ブラウザ速度テストがHTTP/3・QUICを利用している場合、通信はUDP上で動作するため、TCP輻輳制御の比較としては扱えません。
Chromium系ブラウザでは、開発者ツールのNetwork画面へProtocol列を追加し、「http/1.1」または「h2」であることを確認します。
「h3」の測定はCUBIC・BBR比較から除外してください。
TCPバッファを大きくすれば速くなるとは限らない
LinuxはTCP受信バッファを自動調整します。
現在値を確認します。
sysctl net.core.rmem_max
sysctl net.core.wmem_max
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem
sysctl net.ipv4.tcp_moderate_rcvbuf
tcp_rmemとtcp_wmemは「最小値・初期値・最大値」の三つで構成されます。
最大値を32MiB、64MiB、128MiBへ増やしても、その容量が必要な帯域遅延積を持つ経路でなければ、速度向上につながらないことがあります。
バッファを変更する場合は、送信側と受信側を一度に変えず、片方ずつ比較してください。
効果が再現しない場合は標準値へ戻します。
netdev_max_backlogはドロップを確認してから
現在値を確認します。
sysctl net.core.netdev_max_backlog
NICのエラーとドロップを確認します。
ip -s link show dev enp1s0
sudo ethtool -S enp1s0
tc -s qdisc show dev enp1s0
cat /proc/net/softnet_stat
受信ドロップ、missed、overrun、softnet dropなどが発生しておらず、CPUにも余裕があるなら、backlogを250000のような大きな値へ変更する必要性は低いです。
ドロップが確認できた場合も、NICキュー、IRQ、RSS、RPS、CPU使用率、ドライバを先に確認してください。
NICオフロードは全部ON・全部OFFにしない
現在の機能を確認します。
sudo ethtool -k enp1s0
主な項目：
- TSO：TCPセグメント分割をNICへ任せる
- GSO：送信側のセグメンテーション処理をまとめる
- GRO：受信パケットをまとめて上位層へ渡す
- SG：scatter-gather I/Oを利用する
- checksum offload：チェックサム計算をNICへ任せる
オフロードはCPU負荷を減らせますが、ドライバ、仮想化、bridge、VPN、パケットキャプチャ、NICとの相性で結果が変わります。
次のように全部を一度に変更すると、どの項目が効いたのか判断できません。
sudo ethtool -K enp1s0 tso on gso on gro on
変更する場合は一項目ずつ切り替え、速度、CPU使用率、遅延、エラーを比較してください。
ドライバが「fixed」と表示する項目は変更できません。
NICリングバッファは最大値を確認する
sudo ethtool -g enp1s0
「Pre-set maximums」と「Current hardware settings」が同じなら、すでに最大値です。
受信ドロップがなく、現在値も最大なら調整する必要はありません。
RPS・RFS・RSSはCPUボトルネックがある場合だけ
マルチキューNICとRSSに対応している場合、受信処理はハードウェア側で複数CPUへ分散されます。
物理NICが単一RXキューで、特定CPUのsoftirqだけが飽和する場合は、RPSやRFSが候補になります。
ethtool -l enp1s0
ethtool -x enp1s0
grep -E 'NET_RX|NET_TX' /proc/softirqs
CPUボトルネックが確認できていない状態で、RPSやRFSのCPUマスクを一律設定しないでください。
tcp_mtu_probingを常時2にしない
現在値を確認します。
sysctl net.ipv4.tcp_mtu_probing
値の意味：
- 0：無効
- 1：通常は無効で、ICMPブラックホールを検出した場合に有効化
- 2：常に有効
特定サイトだけ接続が止まる、VPN経由で大きなパケットだけ通らないなど、PMTUブラックホールが疑われる場合は「1」を検証候補にできます。
問題が確認されていないデスクトップPCへ「2」を一律適用する必要はありません。
サーバー向け設定とデスクトップ向け設定を分ける
次の設定は主に、多数の接続を受け付けるWebサーバー、プロキシ、ロードバランサーなどで検討する項目です。
- net.core.somaxconn
- net.ipv4.tcp_max_syn_backlog
- net.ipv4.ip_local_port_range
- net.ipv4.tcp_fin_timeout
- net.ipv4.tcp_max_tw_buckets
ブラウザやゲーム、動画視聴を行う一般的なクライアントPCで、これらを大きく変更しても回線速度が直接上がるわけではありません。
勝者が決まった後だけ永続化する
たとえば「CUBIC＋fq」が繰り返し勝った場合、必要最小限の設定だけを保存します。
printf '%s\n' \
'# Verified by repeated benchmark' \
'net.ipv4.tcp_congestion_control = cubic' \
'net.core.default_qdisc = fq' \
| sudo tee /etc/sysctl.d/99-local-network-tuning.conf
sudo sysctl --system
sudo tc qdisc replace dev enp1s0 root fq
BBRが勝った場合は、tcp_congestion_controlだけをbbrへ変更します。
実効値を確認します。
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
tc qdisc show dev enp1s0
再起動後も物理NICへqdiscを確実に適用するには、NetworkManager dispatcherやsystemd oneshotなど、ネットワーク構成に合った永続化処理が必要です。
bridge、bond、VLAN、Wi-Fiなどがある環境では処理が複雑になるため、簡単に設定したい場合はTenyendama Linux Network Optimizerを利用してください。
元へ戻す方法
作成したsysctlファイルを削除します。
sudo rm /etc/sysctl.d/99-local-network-tuning.conf
sudo sysctl --system
開始前に記録したTCP輻輳制御とqdiscへ戻します。
例として、開始前がCUBIC＋fq_codelだった場合：
sudo sysctl -w net.ipv4.tcp_congestion_control=cubic
sudo tc qdisc replace dev enp1s0 root fq_codel
元の値は環境によって異なるため、必ず作業前に保存した記録を使ってください。
2026年版の結論
Linuxネットワーク高速化で重要なのは、設定項目を増やすことではありません。
現在の通信経路、物理NIC、TCP輻輳制御、qdisc、ドロップ、CPU負荷を確認し、候補を一つずつ実測することが大切です。
BBRが速い環境もあれば、CUBICのほうが安定する環境もあります。
fqが大容量転送で強い場合もあれば、fq_codelが混雑時の応答性で有利になる場合もあります。
TCPバッファ、backlog、リング、オフロード、RPS、PMTUは、問題を示す証拠がある場合だけ調整してください。
手動で比較する場合は、設定を一時適用し、A-B-A方式で複数回測定し、中央値とLoaded latencyを確認します。
簡単かつ安全に設定したい場合は、診断、実測比較、経路検証、復元、永続化、ロールバックを一本化したTenyendama Linux Network Optimizerを利用してください。
参考資料
コメント