1. よくある症状と切り分けの軸
ゲームのダウンロードが極端に遅い、残り時間の表示が跳ねる、ワークショップやクラウド同期だけが不安定、マルチプレイでロビーに入れない・NAT 表示が厳しい、といった症状は、出口ノードの品質だけでなく、どの実行ファイルのトラフィックがルールに乗っているかと、UDP が意図した経路を通っているかが絡みます。
まず大枠を次の三つに分けると議論が整理されます。（1）TCP 中心のコンテンツ取得（クライアント更新やゲームファイルの取得）、（2）Steam サービスへの HTTPS／WebSocket 的な通信（ストア表示、フレンド、一部マッチングシグナル）、（3）タイトルごとのゲーム実行ファイルとボイスチャットなどが使う UDP。いずれも「すべて同じポリシーに載せればよい」とは限りません。
インストーラやコアの入手は 当サイトのダウンロードページを、設定の全体像は ドキュメントと併せて参照してください。
2. Steam はなぜ「プロセス」単位の話になりやすいか
Steam クライアントは単一の巨大な steam.exe だけで完結するわけではなく、ブラウザ埋め込みやヘルパー、ゲームごとの子プロセスが動きます。ドメインだけでルールを書く方法もありますが、同一ドメインに別用途の通信が混ざる、IP 直打ちやカスタムプロトコルが混ざる、といったときに、ログ上の プロセス名を手掛かりにするのがプロセス分流です。
Clash 系コアでは PROCESS-NAME やクライアントによっては同等の UI 項目で、特定の .exe を指定のポリシーへ寄せられます。典型例としては steam.exe、steamwebhelper.exe、そして実際にマルチを張るゲーム本体の実行ファイルです。名前はタイトルや配布形態で変わるため、ここに固定表は置きません。タスクマネージャーとクライアントログの両方で実名を確認してください。
3. プロセス分流とルールの書き方
ルール分流は rules: セクションの上から順の評価です。PROCESS-NAME,steam.exe,PROXY のように書くイメージはシンプルですが、実際にはより一般化された GEOIP や DOMAIN ルールに先に飲まれていないかが成否を分けます。広い MATCH や誤った RULE-SET が先にあると、プロセス指定が評価される前に決着がつきます。
# Example only — process names and policy groups must match your client
rules:
- PROCESS-NAME,steam.exe,PROXY
- PROCESS-NAME,steamwebhelper.exe,PROXY
# Add your game executable names from Task Manager when needed
- MATCH,DIRECT実務では、まずログに出たプロセス名をルールに足し、安定したら購読ルールへ戻す二段構えが扱いやすいです。PROCESS-PATH を使える構成であれば、インストール先の違いに強い書き方もできます。いずれにせよ、ゲームの利用規約とチート対策に抵触する操作（不正なパケット操作やチート行為）は行わない前提です。
ダウンロード地域と CDN
クライアント内のダウンロード地域を変えると、接続先のホスト群が変わります。出口ノードの地域とあわせて「遠回り」が増えないかも見ます。ここはルールというより運用の話ですが、帯域が頭打ちに見えるときの最初のつまみになります。
4. UDP とマルチプレイ・ボイス
多くのオンラインゲームでは、同期やボイスに UDP が使われます。HTTP プロキシや従来型のシステムプロキシだけでは、UDP がトンネルに乗らず、意図せず DIRECT のまま別経路へ出ることがあります。結果として「プロキシ越しではストアは開くが、マルチだけ不安定」というパターンが起きます。
TUN モードやコアの UDP 転送設定を有効化できる構成では、ゲームトラフィックをまとめてトンネルに載せやすくなります。ただし TUN は OS 全体のルーティングに影響するため、他 VPN や社内ネットワークと競合しやすい点には注意が必要です。詳しくは TUN とファイアウォールの切り分け記事を参照してください。
5. TUN とシステムプロキシの使い分け
ざっくり言えば、システムプロキシは主に TCP のアプリケーションに効きやすく、ゲーム全体の UDP を含めて取り込みたい場合は TUN 側の検討が中心になります。どちらを選んでも、例外リストに Steam やゲームが入っておらず、意図せず直結していないかを確認します。
また、同一 PC でブラウザだけプロキシ、ゲームだけ直結、といった非対称が起きていると、表示上は問題なくてもマルチのシグナリングが失敗することがあります。切り替え実験をするときは、一度に変える要素を一つに絞るとログの解釈が楽です。
6. クライアント側の確認ポイント
Clash Verge や Clash for Windows など、GUI のあるクライアントでは TUN のオンオフ、システムプロキシの連動、管理者権限、ルールプロファイルの選択が画面に出ます。バージョンごとに名称が異なるため、ここでは固定ラベルを列挙しませんが、次を順に確認すると手戻りが減ります。
- コアと GUI のバージョン：古い組み合わせだと UDP 周りの挙動が変わることがある
- ルールの優先順位：プロセス指定が評価される位置にあるか
- DNS：Fake-IP や redir-host と、ゲームの名前解決が矛盾していないか
- 他 VPN：Wintun 系ドライバやルートが二重になっていないか
Windows でポート共有や LAN からの利用を扱う場合は、ミックスドポートとファイアウォールの記事も参考になります（本稿の主題とは別軸ですが、待受と許可の考え方は共通です）。
7. 実測で見るべきログ
推測でルールを増やすより、接続ログに出た宛先とプロセス名をメモしてからルールを足す方が安全です。ダウンロード中にどのホストへ多く流れているか、マルチ試行中に UDP の行が出ているか、を見ます。ログの取り方はクライアントによりますが、verbose 系のオプションを一時的に上げると切り分けが速いことがあります。
改善したかどうかの確認は、可能なら同一時間帯・同一マップ設定で繰り返し、体感だけでなく再接続回数やパケットロスの表示も参照してください。家庭内の Wi‑Fi 混雑や電源管理による NIC の省電力も、見かけ上の「プロキシのせい」に見えることがあります。
8. 症状対照表
| 症状 | ありがちな原因 | 先に試すこと |
|---|---|---|
| ストアは速いがダウンロードだけ遅い | CDN 経路・地域設定・帯域 | ダウンロード地域、ルールのヒット確認 |
| マッチングだけ失敗・NAT が厳しい | UDP がトンネル外、二重 VPN | TUN と例外、他 VPN の停止で比較 |
| フレンドや UI は動くがゲームだけ落ちる | ゲーム exe が別ポリシー／直結 | プロセス分流で本体 exe を明示 |
| 短時間だけ速くなるがすぐ落ちる | ノード輻輳、セッション切断 | 別ノード、時間帯変更、ログで再現性確認 |
10. まとめ
Steam のダウンロードとマルチプレイを Windows 上の Clash で扱うとき、ドメインだけのルールでも足りることはありますが、症状が分かれる場合はプロセス分流で steam.exe 系とゲーム本体を分け、UDP が期待する経路に乗っているかを TUN とシステムプロキシの観点から確認するのが実践的です。ログに出た実名を正にしてルールを育て、変更は一つずつ。これが 2026 年時点でもいちばん再現性の高い切り分けです。
同種のクライアントと比べて、Clash 系は接続ログとルールの対応が追いやすい場合があり、試行錯誤のコストを下げられます。帯域とノード品質が揃えば、ストア体験とゲームプレイの両方が安定しやすくなることも珍しくありません。