ProtonVPN/Gluetunスレッドのこの部分から得られる最も重要な教訓は単純です。qBittorrentをgluetunという名前のDockerネットワークに接続することは、qBittorrentのすべての通信をGluetun VPNコンテナ経由でルーティングすることと同じではありません。元のユーザーはテスト用トレントを正常にダウンロードできましたが、qBittorrent内からのパブリックIP確認ではISPのアドレスが返り続けました。
コミュニティは最終的に、問題をDockerのネットワークセマンティクスに絞り込みました。Gluetunのネットワークスタックを共有するには、qBittorrentに次のようなCompose上の関係が必要です。 network_mode: "service:gluetun"、そしてスタックが後から互換性のない方法で編集されると、ZimaOSのUIによってその設定が上書きまたは削除される可能性があります。
Gluetun自体はすでに接続済みだった
元のトラブルシューティングでは、GluetunのログにVPNのパブリックIPとトンネルの正常な起動がすでに表示されていました。つまり、VPNコンテナ自体はもはや問題ではありませんでした。
次の疑問は、qBittorrentが実際に同じネットワーク名前空間を使用しているかどうかでした。
qBittorrentは独自のVPNを管理していなかった
ZimaOSのネットワークドロップダウンでは、Dockerネットワークが選択されていた
gluetun qBittorrentを同じネットワークセグメントに接続しただけで、Gluetunのネットワーク名前空間を共有したわけではありません。元の回答者は、2つのDocker概念を正しく区別しました：
- 同じユーザー定義Dockerネットワークに参加すること；
- 別のサービスのネットワーク名前空間を共有することと
network_mode: service:gluetun.
2つ目のモデルだけが、qBittorrentのすべてのネットワーク通信をGluetunのネットワークスタック経由にします。
パブリックIPテストにより、qBittorrentがVPNをバイパスしていることが証明された
コミュニティは、qBittorrentコンテナ内からパブリックIPを確認し、Gluetunのログに表示されたVPNのIPと比較するよう勧めました。
元のユーザーがテストを実行したところ、どちらも通常のISPのIPアドレスを返しました。これは、インターフェース名から推測するのではなく実際の通信経路を測定したため、ページ2の議論で最も強力な証拠となりました。
network_mode は ZimaOS Compose インポートを通過する必要がある
後の参加者が、ZimaOSのUIでアプリを編集した後にエクスポートすると、次のことが表示される場合があると発見しました。 network_mode 行が欠落していました。ネットワークモードの関係を維持し、互換性のない設定を避けたCompose定義をインポートした後、正常に動作したと報告しています。 ports/networks qBittorrentサービスの設定。
これは2026年時点でコミュニティによって検証されたZimaOSの動作であり、現在のすべてのApp Store YAMLエディターについてIceWhaleが公式に保証しているものではありません。
GluetunとqBittorrentを1つのComposeプロジェクトにまとめる
元のスレッドでは、コミュニティが次のように説明していました。 service:gluetun 両方のサービスが同じComposeプロジェクトに属している場合に機能します。その場合、qBittorrentはGluetunのネットワーク名前空間を共有するため、qBittorrentのWebUIと受信ポートはGluetunサービス側で公開されます。
上流のGluetunコミュニティでも、同じDocker Composeアーキテクチャが使用されています。古い環境変数をコピーする前に、現在のGluetunプロジェクトとプロバイダー設定を確認してください。
通常のProtonアカウントパスワードではなく、ProtonVPN WireGuard認証情報を使用する
スレッド全体では、もう1つのよくある間違いも明らかになりました。GluetunのWireGuard設定には、通常のアカウントログインパスワードではなく、適切なProton VPN WireGuardキー／設定値が必要です。
WireGuardの秘密鍵を公開フォーラムに絶対に投稿しないでください。元のユーザーは誤って1つを公開しましたが、その後、正しく失効させました。
正常系だけでなく、キルパスを確認する
統合スタックの起動後、次を確認します。
- Gluetunのログに期待されるVPNのパブリックIPが表示されること。
- qBittorrentの外向きパブリックIPがそれと一致すること。
- Gluetunトンネルが停止または不健全な状態になると、qBittorrentはインターネットにアクセスできなくなります。
- WebUIには、Gluetunで公開されたポートを通じて引き続きアクセスできます。
これにより、アプリケーションがISP接続へひそかにフォールバックしていないことを確認できます。
ARRアプリをすべてVPNの背後に置く必要はありません
元の長いスレッドでは、通信を簡素化する方法としてARRスタック全体をVPNの背後に置くことについても議論されていました。これは機能しますが、必ずしも必要ではありません。多くのユーザーは、Gluetun経由でダウンロードクライアントのみをルーティングし、Sonarr/Radarrは通常のDockerネットワーク上に残して、明示的なホスト／コンテナのパスとポートを通じて通信させています。
1つの通信問題を解決できるからといって、すべてのサービスをトンネルの背後に移すのではなく、アーキテクチャを意図的に選択してください。
qBittorrentではなくGluetunでqBittorrentのポートを公開します
qBittorrentが network_mode: "service:gluetun"独立したネットワーク名前空間を持たなくなります。つまり、WebUIと受信BitTorrentポートはqBittorrentサービスではなくGluetunサービスで公開する必要があります。
共有ネットワークモードに移行した後でqBittorrentのWebUIが表示されなくなった場合は、アプリケーションの起動失敗と判断する前にGluetunのポートリストを確認してください。
ZimaOSのUIでインポート済みスタックを編集する際は注意してください
後のコミュニティ報告は、ZimaOSユーザーにとって特に重要です。インポートしたComposeファイルには、もともと network_modeは維持されましたが、UI変更後にエクスポートされた定義では維持されなくなりました。同じ参加者は、競合する ports および networks エントリを追加してスタックを再インポートすると、正常に動作していた関係が維持されました。
これは、現在のすべてのZimaOS YAML編集が必ずそのように動作することを証明するものではありません。ただし、グラフィカルエディターでネットワーク設定を変更した後は、生成されたComposeを再確認する必要があることを意味します。
DockerトポロジーはVPNプロバイダー間で再利用できますが、認証情報は再利用できません
2ページにはSurfsharkのトラブルシューティング例がありますが、元のスレッドはProtonVPNから始まりました。Dockerネットワークに関する教訓は共通しています。Gluetunがトンネルを提供し、qBittorrentはその名前空間を経由してルーティングする必要があります。プロバイダー固有の鍵、サーバーセレクター、ポートフォワーディングオプション、認証情報は互換性がありません。
Gluetunの環境は、別のユーザーのSurfsharkやProtonの値をコピーせず、必ず現在のプロバイダー設定から構築してください。
WireGuardの秘密鍵を公開スクリーンショットやフォーラム投稿に貼り付けないでください
元の投稿者は誤ってWireGuardの秘密鍵を公開し、別の参加者に警告された後でその鍵を失効させました。公開されたVPN鍵は侵害されたものとして扱い、直ちにローテーションしてください。
サポートを求める際は、秘密鍵、トークン、パスワード、Cookie、プロバイダーのアカウント識別子を伏せたうえで、秘密情報ではないログやエラーメッセージは見える状態にしてください。
Gluetunのルーティングに関するFAQ
gluetunという名前のDockerネットワークに接続すると、通信はVPN経由になりますか？
いいえ。元の内容では、qBittorrentがそのネットワークに接続されたままISP経由の経路を使えることが示されています。
Gluetunのネットワーク名前空間を共有する設定はどれですか？
元のComposeパターンと上流のComposeパターンでは、 network_mode: "service:gluetun".
ルートはどのように確認しますか？
qBittorrent内から確認できるパブリックIPと、Gluetunが報告するVPNのIPを比較します。
