深夜 2 時の帯域幅危機
ある火曜日の深夜 2 時、ネットワーク監視アラートが鳴り響きました。WAN リンクは 100% に張り付き、Discord の Ping 値は安定した 20ms から不安定な 400ms へと跳ね上がりました。
ルーターを確認すると、家の中の 3 台の異なるマシンが、120GB という巨大な Call of Duty のアップデートをダウンロードするために帯域を奪い合っていました。プロバイダーが提供する 100Mbps 回線では太刀打ちできません。これは、すべての HomeLab 愛好家がいずれ直面する典型的なボトルネックです。つまり、内部の 1Gbps（あるいは 10Gbps）の LAN 速度と、外部世界への限られたパイプとの間にある、もどかしいギャップです。
私の実体験から言えば、これは習得すべき必須スキルの 1 つです。複数の PC、コンソール、あるいは仮想マシンを運用している場合、同じ 5GB の Ubuntu ISO や 100GB の Steam ゲームを何度もダウンロードするのは時間とお金の無駄です。LanCache は透過的なキャッシュプロキシとして機能することで、この問題を解決します。ファイルが最初に要求されたときにインターネットから取得してサーバーに保存し、それ以降のネットワーク内のマシンからの要求にはすべてローカルのハードウェア速度で対応します。
背景と理由：なぜ HomeLab にキャッシュが必要なのか
現代のゲームや OS 管理は、遅いインターネット回線にはますます厳しくなっています。Steam、Epic Games、Windows アップデート、そして Linux ディストリビューションの間で、通常の 1 週間でも簡単に 0.5 テラバイトもの重複データがゲートウェイを通過します。LanCache（具体的には lancachenet/monolithic プロジェクト）は、Valve、Microsoft、Apple などの特定の CDN トラフィックをターゲットにし、HTTP 経由で提供されるデータのチャンクをキャッシュします。
なぜ一般的な Squid プロキシを使わないのでしょうか？それは、これらのサービスの多くが、標準的なプロキシでは無視される可能性のある複雑な範囲リクエスト（Range Request）や特定のヘッダーを使用しているからです。LanCache は、ゲームランチャーやシステムアップデート特有の癖を最初から処理できるように設定されています。DNS クエリを LanCache コンテナにリダイレクトすることで、クライアントはローカルサーバーと通信していることさえ気づきません。ただ、ダウンロードバーが 110MB/s で進んでいくのを目にするだけです。
インストール：Docker による LanCache のデプロイ
私は Docker Compose を好んで使用します。DNS とキャッシュサービスを 1 つのユニットとして管理できるからです。十分なストレージ容量を持つマシンが必要になります。2、3 タイトル以上の AAA ゲームをキャッシュする予定なら、少なくとも 1TB 以上を推奨します。
1. ストレージの準備
キャッシュディレクトリに適切な権限があることを確認してください。通常、私は専用の SSD または高速な HDD アレイを /mnt/cache にマウントします。
sudo mkdir -p /mnt/cache/data /mnt/cache/logs
sudo chown -R 1000:1000 /mnt/cache2. Docker Compose ファイル
設定用のディレクトリを作成し、以下の docker-compose.yml を配置します。LANCACHE_IP は、お使いの HomeLab サーバーの固定 IP アドレスに置き換えてください。
version: '2'
services:
dns:
image: lancachenet/lancache-dns:latest
env_file: .env
restart: always
ports:
- ${LANCACHE_IP}:53:53/udp
- ${LANCACHE_IP}:53:53/tcp
sniproxy:
image: lancachenet/sniproxy:latest
env_file: .env
restart: always
ports:
- ${LANCACHE_IP}:443:443/tcp
monolithic:
image: lancachenet/monolithic:latest
env_file: .env
restart: always
ports:
- ${LANCACHE_IP}:80:80/tcp
volumes:
- /mnt/cache/data:/data/cache
- /mnt/cache/logs:/data/logs設定：環境のチューニング
重要なのは .env ファイルです。ここで何をキャッシュし、どれくらいの容量を割り当てるかを定義します。UPSTREAM_DNS の設定を間違えると、家中のインターネット接続が切れてしまうので、注意が必要です。
# .env ファイルの設定
LANCACHE_IP=192.168.1.50
DNS_BIND_IP=192.168.1.50
UPSTREAM_DNS=1.1.1.1
# キャッシュのチューニング
CACHE_DISK_SIZE=1000g
CACHE_INDEX_SIZE=500m
CACHE_MAX_AGE=3650d
# オプション：キャッシュする特定のサービス
USE_GENERIC_CACHE=trueドライブがいっぱいになったときに OS が動かなくなるのを防ぐため、CACHE_DISK_SIZE は実際のディスク容量より少し小さめに設定しています。制限に達すると、LanCache は LRU（Least Recently Used）アルゴリズムを使用して古いデータを削除します。これは非常に重要です。ファイルシステムのオーバーヘッドを考慮しなかったために、多くのセットアップがクラッシュするのを見てきました。
ネットワーク統合
これを機能させるには、クライアントが DNS プロバイダーとして LanCache サーバーを使用する必要があります。2 つの選択肢があります：
- 手動： ゲーミング PC の DNS 設定を
192.168.1.50に変更する。 - 自動： ルーター（pfSense、OPNsense、または標準的な ISP ルーター）の DHCP 設定を更新し、LanCache の IP をプライマリ DNS サーバーとして配布するようにする。
検証とモニタリング：実際に動作しているか？
docker-compose up -d でコンテナを起動した後、私は必ずログを確認します。キャッシュしているつもりだったのに、DNS の不一致のせいで、すべてがサーバーをバイパスしていたと気づくことほど最悪なことはありません。
1. DNS 解決のテスト
クライアントマシンから、既知のゲーム CDN に対して nslookup コマンドを実行します：
nslookup steamcontent.com結果が公開されている Valve の IP ではなく、ローカルの LanCache IP（192.168.1.50）を返せば、リダイレクトは完璧に動作しています。
2. キャッシュログの監視
ここからが満足感を得られる場面です。ターミナルを開き、Steam でダウンロードを開始しながらアクセスログを tail します：
docker logs -f monolithicTCP_HIT または TCP_MISS を探します。TCP_MISS は（初回のため）インターネットから取得していることを意味します。TCP_HIT はローカルディスクから提供されていることを意味します。TCP_HIT が表示され、Steam のダウンロード速度が 900Mbps 以上に跳ね上がれば、深夜 2 時のトラブルシューティングは報われたと言えるでしょう。
3. スループットのモニタリング
ここからが満足感を得られる場面です。Grafana のようなダッシュボード（他の HomeLab プロジェクトで使用したことがあります）があれば、LanCache コンテナのネットワークインターフェースを監視できます。キャッシュヒット中、コンテナからの高い送信トラフィックと、WAN からのほぼゼロの受信トラフィックが見られるはずです。3 台の PC がフルスピードでアップデートされている間、外部インターネットが完全にアイドル状態に保たれ、他の全員がラグなしで 4K 動画をストリーミングしたりゲームをしたりできる十分な帯域幅が残っているのを見るのは、実に素晴らしい光景です。
この環境を構築したことで、私の HomeLab は単なるファイルサーバーから、高性能なネットワーク資産へと変貌しました。もうダウンロードを深夜にスケジュールする必要はありません。「アップデート」をクリックするだけで、ローカルストレージが重労働をこなしてくれます。
