Steam ストアが開かない／ダウンロードが 0？Clash の分流ルールと UDP オンラインを順に切り分ける（2026）

症状：ブラウザは通るのに Steam だけがおかしい

Steam クライアントでは、ストアやコミュニティの表示、ゲーム本体・パッチのコンテンツダウンロード、ボイスチャットや一部タイトルのオンラインが、それぞれ別系統のホストへ分散します。回線自体は速いのに「ページは開くが速度メーターが 0 のまま」「更新だけ固まる」「フレンドやボイスだけ不安定」といった切り分けが起きやすく、Clash／Mihomo（旧 Clash Meta）をルールモードで運用している環境では、分流の取りこぼしとDNS、さらにUDP まわりの制約が重なると原因が見えにくくなります。

本稿は、Disney+ や Netflix 向けに長尺 CDN を束ねる記事（例：Netflix の分流ガイド）とはドメイン設計を分け、Valve 系クライアント特有の「クライアントがシステムプロキシを無視しがち」「コンテンツサーバが広いサブドメインに散らばる」「UDP ゲームや VoIP が別経路を要する」点に焦点を当てます。利用規約・コンテンツ提供地域・オンラインサービスに関する取り決めは各公式の案内に従う前提で、経路と名前解決の技術話に限定します。

ステップ 1：どのトラフィックが詰まっているかを層で分ける

まず、不調が（A）ストアの HTML／API、（B）steamcommunity などコミュニティ系、（C）実ファイル取得の CDN、（D）フレンド／チャット／一部マルチの UDP、のどこに出ているかをメモします。同じ「繋がらない」でも、層が違えば疑うべきルールとログの見方が変わります。

Clash のダッシュボードや接続ログで、評価されたホスト名・チェーン・プロトコル（TCP／UDP）を短時間だけスナップショットするのが実務的です。広い GEOIP や末尾の MATCH より手前に、細かい DOMAIN-SUFFIX を置く方針はルール分岐の詳解と同じですが、Steam はホスト名が増えやすいので「一度に巨大ルールを貼る」より、ログで足りない名前を足す運用が安全です。

ステップ 2：DNS と Fake-IP の食い違いを潰す

ストアが開かないに近い症状の多くは、実は名前解決が意図と違う出口に出て、クライアントが別リージョンのエッジへ誘導されることに起因します。dns.enhanced-mode が fake-ip のとき、ルール評価に使う名前と実接続の解決経路が一瞬でもズレると、DOMAIN-SUFFIX が掛からず「ブラウザの診断は成功するがクライアントだけ失敗」が起きます。

• DoH／DoT の初回：リゾルバ URL 自体がプロキシ必須ドメインだと、初回だけタイムアウトが連鎖することがあります。
• IPv6：AAAA が返るが下りだけ不通な環境では、再試行が増えて体感が「0bps で固まる」に見えます。
• ルータ DNS：親機が別 DNS を強制していないか、VPN クライアントと二重にリゾルバが競合していないかを確認します。

遅延テストや健康チェック自体が不安定なときは、ノードが全て赤に見えるときの記事で DNS・UDP・STUN を先に切り分けると、Steam 専用ルールに入る前に無駄な試行を減らせます。

ステップ 3：DOMAIN-SUFFIX で Valve／Steam 系を束ねる

以下は出発点の例です。実際の配信ドメインはタイトルや地域・CDN 契約で変わるため、手元のログに出た名前を優先して追記してください。独立した proxy-groups（ここでは 🎮 Steam と仮置き）へ寄せるイメージです。

proxy-groups:
  - name: "🎮 Steam"
    type: select
    proxies:
      - "低遅延ノード"
      - "高帯域ノード"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,steampowered.com,🎮 Steam
  - DOMAIN-SUFFIX,steamcommunity.com,🎮 Steam
  - DOMAIN-SUFFIX,steamstatic.com,🎮 Steam
  - DOMAIN-SUFFIX,steamusercontent.com,🎮 Steam
  - DOMAIN-SUFFIX,steamserver.net,🎮 Steam
  - DOMAIN-SUFFIX,valvesoftware.com,🎮 Steam
  - DOMAIN-SUFFIX,steam-chat.com,🎮 Steam

コンテンツ配信は Akamai 等の汎用 CDN 名で出ることがあり、その場合は広すぎるサフィックスを足すと他サービスまで巻き込むため、ログで「Steam 操作の前後だけ増えるホスト」を確認してから追加するのが無難です。嗅探（sniffer）や override-destination を使う構成では、Sniffer と fake-ip の記事の評価順もあわせて点検してください。

ステップ 4：ダウンロードが 0 のまま／極端に遅いとき

クライアント内のダウンロード地域やキャッシュ設定、実際に選ばれたコンテンツサーバの所在地は、表示帯域と一致しないことがあります。ここで重要なのは、ログ上で該当ホストが本当に 🎮 Steam グループへ入っているか、別ポリシーに落ちていないかです。

また、一部 ノード は長時間・大容量の TCP に対して中間装置の制限が掛かり、速度テストは通るが実ダウンロードだけ伸びないことがあります。別ノードへの切り替え、あるいはダウンロードだけ一時的に DIRECT で比較するのが早い実測です。ゲーム機向けのゲートウェイ構成の考え方はSwitch 2 の eShop 分流記事とも通底しますが、PC 版 Steam は OS 上で TUN を掛けやすい点が異なります。

ステップ 5：UDP ゲーム・ボイスと NAT／プロキシの限界

ロビーやマッチングは TCP で済んでも、実戦やボイスが UDP 中心のタイトルでは、商用プロキシの UDP 扱い・ポート制約・対称型 NAT の組み合わせで、ルールを正しくしても不安定が残ることがあります。これは DOMAIN-SUFFIX を増やすだけでは解決しない層です。

• ノード側：UDP パススルーや Full Cone に近い挙動を期待する前に、プロバイダ記載の仕様と実測ログを照合します。
• クライアント設定：Steam のネットワーク診断や、OS のファイアウォールがゲーム実行ファイル・Steam サービスをブロックしていないかを確認します。
• 切り分け：オンライン用途だけ一時的に DIRECT へ、もしくは別ノードへ──症状が消えるかで層を切ります。

家庭内では UPnP や手動ポート転送と、Clash ゲートウェイの整合もあわせて見ます。ルールが「正しい」のに直らないときは、プロキシを挟まない経路との A/B が最も時間対効果が高いです。

チェックリスト（短時間版）

1. Steam のパケットが TUN／ゲートウェイで本当に取り込まれているか（システムプロキシのみに依存していないか）。
2. DNS：fake-ip、DoH、親ルータ、IPv6 の片道不通を疑う。
3. ログで steam／valve 系ホストが意図した プロキシグループ に入っているか。
4. ダウンロード：別ノード・一時 DIRECT でスループットが変わるか。
5. UDP オンラインだけ不調なら、ノード仕様と NAT／ファイアウォールをルールとは独立に検証。

ドキュメントと入手経路

YAML の詳細は当サイトのチュートリアル・ドキュメントも参照してください。実行ファイルは説明が一貫した配布導線としてダウンロードページから入手するのがおすすめです。

まとめ

Steam の不調を Clash 側で直すとき、ブラウザとの差は「クライアントがどの層でプロキシを見るか」と「ホストがどれだけ分散しているか」に集約されがちです。DNS → ルール順と DOMAIN-SUFFIX → ノード実測 →（必要なら）UDP／NAT の順に切り分けると、手戻りが減ります。ストリーミング向け分流記事と役割を分けつつ、ログを軽く回す運用は共通です。

同種のクライアントでも、Mihomo／Clash Meta 系はルールとログを手元で制御しやすく、不足ドメインを追記しやすいのが強みです。環境に合ったビルドはダウンロードページにまとめています。購読と DNS を一度整理したうえで導入すると、Steam の再現と修正がはるかに楽になります。→ Clash クライアントを無料でダウンロードし、Steam 向け分流と UDP 切り分けを試す