なぜBitTorrentとClashの「全体代理」が衝突するのか
多くの人は、ClashをONにすると「PC全体の通信」が一つの出口にまとまると想像しますが、実際には TCP／UDPのフロー単位 でルールが評価されます。プロファイル末尾が MATCH,PROXY のような広い落とし穴になっていると、ブラウザだけでなく qBittorrent のピア接続も同じポリシーグループを継承しがちです。Web閲覧では便利でも、BT の大量セッションを同じ商用ノードに流すのは、課金帯域とノード運営の双方にとって負担になりやすい構成です。
遅延の観点でも、チョーク／アンチョークやピア選択は往復時間の安定を前提にします。混雑したリレー経由ではジッターが増え、アップロード枠を割り当ててもらいにくくなることがあります。PT ではトラッカーや自動化が「出口IPの変化」「データセンターASN」をリスク要因として扱う例もあり、クライアント自体は正規でも見え方が悪化しうる——こうした背景から、トラントクライアントのバイナリだけは家回線の DIRECT に固定し、ブラウザや開発ツールは従来どおり 分流 させる、という設計が現場ではよく採られます。
トラッカーのアナウンスURLなら DOMAIN-SUFFIX で拾えることもありますが、メタデータ交換のあと主体は任意IP同士のピア通信です。IPを網羅的に列挙するルールは現実的ではありません。そこで「どの実行ファイル起点のフローか」で切る PROCESS-NAME が、運用者にとって読みやすく、差分も取りやすい抽象化になります。
システムプロキシ・TUN・qBittorrentがClashに届く条件
YAMLを触る前に、トラフィックがコアに届く経路を言語化しておくと手戻りが減ります。Windows の「プロキシサーバーを使う」設定でClashのmixed／HTTPポートを指している場合、WinINETに従うアプリはローカルリスナーへ送りますが、すべてのアプリが従うわけではありません。qBittorrent は接続設定に独自のHTTP／SOCKS欄があり、ここがローカルClashを指していると、OSの既定よりクライアント側の指定が優先され、意図と異なる経路になります。
TUN は仮想アダプタを介してパケットをコアへ取り込む方式で、「とにかく多くのフローをClashで分類したい」場合の基盤になります。このとき PROCESS-NAME の価値が最大になります。逆にTUNを使わず、qBittorrent側のプロキシも空で、クライアントが素のソケットを開いているなら、ログ上はもともと DIRECT に見える——その状態でPROCESS-NAMEを足しても症状は変わりません。自分のトポロジーに合わせて読み替えてください。有効化と切り戻しの順序は TUNのトラブルシュート記事 にまとめています。
「ブラウザだけ代理、BTは直結」を目指すなら、取り込み方式（TUN等） と qBittorrentの接続タブ の両方を一貫した物語にそろえるのが近道です。どちらかだけ片付けても、ログでは想定外のポリシー名が残り続けます。
PROCESS-NAMEがマッチするもの（Clash Meta前提）
Clash Meta（mihomo） では、接続に関連付けられた実行イメージ名をキーにマッチングします。一般的には qbittorrent.exe のような .exe のファイル名 であり、製品表示名の「qBittorrent 5.x」とは別物です。長時間・多目的地に話すバイナリ——典型的な BT ワークロード——を短い行で束ねられるのが利点です。
セキュリティポリシの代替ではありません。別名の実行ファイルが同名を装う可能性はゼロではないため、本稿の範囲はトラフィック工学に限定します。とはいえ、購読YAMLやGit管理プロファイルの中で、購読URLやノード名と並んで diff しやすい行になるのは運用上のメリットです。
.exe の綴りを確認します。ポータブル版やフォークでは別名になることがあるため、記憶より列表示を優先してください。
コピー用：qBittorrent向け rules ブロック
以下は たたき台 です。rules: 配列の先頭寄り（後述の順序を守る位置）へ追記し、環境に合わせてポリシー名を置き換えてください。素直に DIRECT へ送る例：
rules: - PROCESS-NAME,qbittorrent.exe,DIRECT - PROCESS-NAME,qbittorrent_x64.exe,DIRECT # Add only names that appear in your logs for portable builds
2行目は配布形態によって異なる実行体がある場合の保険です。ログに現れるまで推測で十数行足すのは避け、実測で名前が分かったときだけ増やすのが安全です。監査用に「直結相当の出口」を select で一本化したい場合もありますが、家庭用途では DIRECT のままが読みやすいことが多いです。
ルール順：PROCESS-NAMEを足したのに「効かない」典型原因
Clashは 上から最初の一致 だけを採用します。購読プロファイルが展開する大量の GEOIP や IP-CIDR、あるいは RULE-SET が、あなたが貼った PROCESS-NAME より上にあると、常にそちらが先に勝ちます。「末尾に一行足した」だけでは、支援掲示板で最も多い失敗パターンになります。
置き場所の目安：
- 社内LANやリンクローカル向けの例外
DIRECTを先頭に置く設計なら、その直後に PROCESS-NAME をまとめる。 - 国別に一括
PROXYへ送るような巨大なプロバイダ行より 前 に、重いデスクトップバイナリ用の行を置く。 - 最終の
MATCHやフォールバックは本当に末尾へ。
rule-providers と RULE-SET を併用する場合、インラインルールとマージされた結果の 出現順 がそのまま評価順です。短い例外（PROCESS-NAME含む）を先にまとめ、購読セットを後ろへ回す二段構成が読みやすいです。ポリシーグループとプロバイダ全般は YAML分流ガイド を参照してください。
注意点として、RSS取得や埋め込み検索も同一プロセスから出るため、PROCESS-NAME,qbittorrent.exe,DIRECT と書くとそれらのHTTP(S)も直結側へ寄ります。通常はトラッカーアナウンスに都合が良い一方、「メタデータだけ代理、スウォームだけ直結」のような細かい分割は PROCESS-NAME単体では不可能 です。ホスト名ルールや別プロセス構成が必要になります。
qBittorrent側の接続設定がClashと喧嘩するパターン
ツール → オプション → 接続 のHTTP／SOCKS欄がローカルClashを指していると、OSが直結でもクライアントは自発的にプロキシへ流します。「BTは直結」の意図と矛盾するので、方針に合わせて空にするか、意図的な構成にそろえます。「ピア接続にもプロキシを使う」系のチェックが有効だと、wireトラフィックまでプロキシ経由になりがちで、ピアリングの目的と逆行します。
インターフェース束縛やUPnP／NAT-PMPの設定を変えたあとは、リスニングソケットを張り直すためにクライアントの再起動を挟むと切り分けが早いです。大きなネットワーク変更のあとに「片方だけ古い経路」が残ると、ログ上のポリシー名と体感が食い違います。
パスに空白・大小文字・別名exe：よくある誤解
C:\Program Files\qBittorrent\qbittorrent.exe のようにフォルダに空白があっても、標準の PROCESS-NAME ルールにパス文字列を書く必要はありません。照合対象は実行イメージ名のトークンです。YAMLが壊れたという報告の多くは、別行のインデントやコロン引用の問題であり、PROCESS-NAMEのセマンティクスとは無関係なことが多いです。
大小文字は環境によって見え方が変わり得るため、タスクマネージャーの列を真とします。推測で qBittorrent.exe と書き、実体が qbittorrent.exe だった——というミスはログが静かなまま後段へ落ちるので気づきにくいです。
PTまわりの運用メモ（技術以外のリスクも含めて）
各トラッカーにはシードボックスIP、商用VPNレンジ、ヒットアンドラン比率などのポリシーがあります。VPN出口が頻繁に変わると、ポート開放の提供や自動スコアと相性が悪いことがあります。トラントバイナリだけ DIRECT に寄せ、ブラウザやIMは従来の出口設計のまま、という差別化は説明責任の面でも扱いやすいです。法令・利用規約・組織方針は各自で順守してください。本稿はネットワーク設定の一般論にとどまります。
ログで検証する手順
プロファイルを再読み込みしたあと、許諾のあるテスト転送（例：よく知られたLinuxディストリビューションのISOなど）で短時間試し、接続ログで qbittorrent.exe 起点の行が想定ポリシー（DIRECT 等）になっているかを見ます。まだ名前付きプロキシに乗るなら、一致インデックスがより上のルールであることを疑い、PROCESS-NAME行を上へ移動します。
ブラウザで無関係なHTTPSサイトを開き、従来どおり別グループへ流れていることも確認すると、「誤って全体をDIRECTにしてしまった」ミスを早く潰せます。同一PCからスマホへLAN共有している場合、スマホのフローはWindowsのexe名には紐づかないため、別途ポリシーが必要です。LAN共有の記事 を参照してください。
切り分け早見表
| 見え方 | まず疑うこと |
|---|---|
| 再読み込み後もトラントがプロキシ名のまま | PROCESS-NAMEがより広いルールより下にある。またはクライアント側プロキシ設定が有効 |
| ログにqBittorrentの行が一切出ない | TUN／システムプロキシ／クライアント設定のいずれかでClashがフローを取り込めていない |
| ルールは当たっているが速度が悪い | ISPシェイピング、ディスク、遠方ピア品質など経路以外の要因 |
| RSSだけ別経路、スウォームだけ失敗など不整合 | qBittorrentの接続タブのプロキシ関連チェックが混在 |
コアを現行に保つ
PROCESS-NAME の利用可否や細部の挙動はバンドルされるMetaの世代に依存します。謎の不一致に悩む前に Metaへのアップグレード を検討し、再読み込み後に同じスモークテストを繰り返すと無駄が減ります。
オープンソースと入手経路
マッチャー表の正確な定義はリリースノートで変わり得ます。疑わしいときは mihomo リポジトリ のドキュメントを参照してください。インストーラの入手は 当サイトのダウンロードページ を主にし、GitHubはソース透明性の確認用として切り分けると安全です。
FAQ
パスに空白があるとPROCESS-NAMEの書き方が変わりますか？
変わりません。照合は実行ファイル名です。フォルダパスはWindowsのACLやショートカットの話であり、ルールの第2フィールドには通常 qbittorrent.exe のような名前だけを書きます。
アップロードだけ代理、ダウンロードだけ直結のように分けられますか？
同一プロセス文脈では難しく、単一のPROCESS-NAME行では実現しません。プロセス分割やプロトコル特化ルールが必要になり、BitTorrentでは脆くなりがちです。
WebUIをブラウザで開いた通信は？
ブラウザのプロセスがHTTPを握るため、ブラウザ向けルール側に乗ります。エンジン本体のピア通信は qbittorrent.exe 側のままです。
まとめ
2026年時点でも、Windows で Clash を広くONにしつつ qBittorrent の BT／PT だけを家回線へ戻したいなら、PROCESS-NAME で qbittorrent.exe を DIRECT へ送る一行がもっとも説明コストの低い解の一つです。成否は ルール順（MATCH や巨大 RULE-SET より上）、タスクマネージャー由来の 正確なexe名、取り込み方式（多くは TUN）と qBittorrentの接続タブ の整合、の三点に集約されます。検証は接続ログで十分で、毎回プロファイルをマージしたあとに短いスモークテストを挟む癖がつくと運用が楽になります。
クライアント種別の比較と入手は ダウンロードページ から行えます。購読プロファイルの一般論は YAML分流ガイド、一覧検索は 技術コラム一覧 が便利です。