Steam コミュニティ・ワークショップ不通を Clash で出口固定（2026）

症状の切り分け：クライアントは動くのに「コミュニティ」「ワークショップ」だけ弱い

Steam は長年にわたり高い同時接続数を維持しており、日本語圏でも「Steam コミュニティが開かない」「クリエイティブ・ワークショップのサムネイルや説明文がずっと読み込みのまま」といった相談が、新作発売や大型セールの前後で周期的に増えます。Clash（多くは Mihomo コア）を使っている場合、一見すると「プロキシはオンだし、ライブラリも更新できるのに、ブラウザで開いた掲示板だけ真っ白」「ゲーム内オーバーレイのコミュニティタブだけタイムアウト」といった部分的症状になりがちです。

ここで重要なのは、Steam が単一のドメインに集約されていないことです。クライアントの認証やライブラリ同期、大容量パッチの取得は、利用者の回線や地域に応じてSteam CDN へ振り分けられる一方、掲示板・プロフィール・ワークショップの HTML や API は、別ホスト名に乗っているケースが多く、ルールの取りこぼしで DIRECT とプロキシが混在すると見え方だけが壊れることがあります。分流の共通原理はルール分流ガイドで押さえつつ、本記事では Steam 特有の「どこを先に拾うか」に絞ります。一覧から辿る場合はブログ一覧も参照してください。

ℹ️

用語：GUI では「ルールモード」「Rule」と表示されることが多いです。ドメインごとに出口を変えるには、基本的に mode: rule（または同等）で、すべてを GLOBAL の一ノードに固定しない前提が必要です。

「全部プロキシ」より「必要ドメインだけ」：体感と帯域の両取り

ゲーム用 VPN の説明では、しばしば「とにかく海外ノードへ丸ごと流す」イメージが強調されますが、Steam の実運用では逆に負担が大きいこともあります。数十ギガバイト級のアセット取得が、わざわざ遠回りのプロキシを通ると、レイテンシだけでなくノード側の帯域制限や切断に当たりやすくなります。そこで本記事で推すのは、コミュニティ／ワークショップ関連のホスト名だけを、レイテンシよりも到達性と出口の一貫性を重視したポリシーグループへ載せ、ストア画面やコンテンツ配信は DIRECT、あるいは別の「高速・国内寄り」グループへ残す最小プロキシの発想です。

これは「ゲームを速くする」ためのチューニングではなく、閲覧系・ UGC 系のホストがブロックや不安定経路に乗らないようにするための構成です。生成 AI の API や IDE 拡張向けに書いた分流記事が「TLS ハンドシェイクとタイムアウト」中心であるのに対し、Steam では大量の小さな HTTPS リクエストと画像 CDNがボトルネックになりやすく、論点が少し異なります。ストリーミング向けの Disney+ のルール記事が「長尺動画の出口一貫性」なら、Steam コミュニティは「多数ドメインの網羅」と「テキスト・画像の欠けない読み込み」が前面に出ます。

まず押さえるホストの型：コミュニティ・ワークショップとストアの分離

環境やクライアントの世代によって実際に出る名前は変わりますが、切り分けの出発点としては次のような型を頭に置くとよいでしょう。（1）掲示板・プロフィール・ワークショップの UI に関わる steamcommunity.com 系。（2）アセット配信や画像 に使われがちな steamusercontent.com や steamuserimages を含むホスト。（3）クライアント内ブラウザ が参照する store.steampowered.com やヘルプ系。大容量のゲームコンテンツは steampowered.com 以外の CDN 名へ振られることも多く、ここを誤ってコミュニティ用プロキシへ寄せると、かえってダウンロードだけ遅くなる、というパターンもあります。

実務では、まずクライアントやブラウザの開発者ツール、あるいは Clash のログで失敗しているホスト名を十数件ほど書き出し、共通するサフィックスを見つけるのが確実です。「コミュニティが開かない」と一口に言っても、DNS タイムアウトなのか TLS エラーなのか、HTTP 403 なのかで打ち手が変わります。本記事では特定の購読テンプレート名に依存せず、自分のログに基づいてリストを磨く前提で説明します。

ルールの書き方：上に置く DOMAIN-SUFFIX と専用 proxy-groups

Clash 系の設定では、ルールは上から先勝ちです。広い GEOIP や購読ルールの MATCH より前に、Steam のコミュニティ系サフィックスを置かないと、意図せず DIRECT へ落ちたり、逆に全体が別グループに飲み込まれたりします。典型例として、専用のポリシー名 PROXY_STEAM_SOCIAL を用意し、次のような行を自分のリストの上位へ移動させます（例示であり、そのままコピーしたら動く保証はありません）。

# Example only — adjust policy names to match your config
rules:
  - DOMAIN-SUFFIX,steamcommunity.com,PROXY_STEAM_SOCIAL
  - DOMAIN-SUFFIX,steamusercontent.com,PROXY_STEAM_SOCIAL
  - DOMAIN-SUFFIX,steamuserimages-a.akamaihd.net,PROXY_STEAM_SOCIAL
  # Store / CDN: often left DIRECT or a separate "DOWNLOAD" group
  - DOMAIN-SUFFIX,steampowered.com,DIRECT
  - DOMAIN-SUFFIX,steamstatic.com,DIRECT

proxy-groups 側では、PROXY_STEAM_SOCIAL を url-test や fallback で同じ地域に見えるノードに寄せ、手動の select だけだと家族が別地域へ切り替えてしまう、といった運用事故を減らすとよいでしょう。ルール末尾のグループ名と YAML 内の定義が一致しているかは、リネーム時に必ず確認してください。YAML の骨格や DIRECT の意味づけはルール分流ガイドと対応づけて読むとミスが減ります。

✅

ヒント：ワークショップのプレビュー画像だけ欠けるときは、HTML のドメインは通っているが Akamai 等の画像 CDN が DIRECT のまま届いていないケースがあります。ログで「欠けているファイル名のホスト」を特定してからサフィックス行を足してください。

Steam CDN 分流：ダウンロードを速くする話ではなく「意図した経路に乗せる」話

検索キーワードに含まれる Steam CDN 分流 は、誤解されやすいので整理します。目的が「国内 CDN を選んで ping を下げる」のであれば、それは ISP や Steam クライアントのダウンロード地域設定の話であり、Clash の役割とは限りません。一方、プロキシ利用者が直面するのは、「コミュニティだけ海外出口が必要だが、パッチ取得は国内直結の方が安定する」といった経路の切り分けです。このとき Clash がするのは、名前解決とルールマッチによって接続をどのソケットへ載せるかを決めることであり、CDN の契約側でどのエッジが選ばれるかまでを完全に保証するものではありません。

そのうえで、ダウンロード用ドメインを DIRECT に固定し、掲示板系だけ PROXY_STEAM_SOCIAL に載せると、セッションごとの出口のブレが減り、掲示板の API が途中で別国の IP に切り替わるリスクを抑えられます。大容量取得がプロキシを通らないぶん、ノード事業者のフェアユース規約に触れにくい、という副次効果もあります。IPv6 が有効な回線では、IPv4 ルールだけでは取りこぼすことがあるため、詰まったら OS 側のスタックも含めて一度切り分けてください。

DNS と fake-ip：ルールが効かない「見かけ上のバグ」

dns.enhanced-mode: fake-ip を使っている場合、ドメインルールが効くタイミングと実接続がズレ、ブラウザでは直結に見えることがあります。Steam クライアントは独自のスタックを持ち、OS のシステムプロキシや TUN の取り込み方によって挙動が変わるため、「Chrome ではコミュニティが開くがオーバーレイだけダメ」などの差も起きえます。不安なら Fake-IP と DNS の記事に沿って、名前解決が意図した DNS サーバへ行っているかを確認してください。

nameserver-policy で Steam 関連サフィックスだけ実解決寄りにする、fake-ip-filter に特定ドメインを足す、といった調整は副作用もあるため、変更前後でワークショップの一覧表示と画像読み込みをセットで検証するのが安全です。DNS だけが別経路に抜けていると、画面上はプロキシオンでも判定や証明書の見え方が食い違うことがあります。

検証のしかた：ログで「どの行にマッチしたか」を追う

設定を変えたら、（1）問題のページを開いたときにどのドメインが並ぶか（2）それぞれがどのルール行で止まったか（3）実際に使われたプロキシグループ名とノードが期待どおりか、をログで追うのが確実です。ワークショップは一度に多数のホストへ並列リクエストが飛ぶため、欠けているのが HTML 本体なのか CSS なのか画像なのかを切り分けると、足すべき DOMAIN-SUFFIX が絞れます。

なお、Steam の利用規約や地域ごとの提供条件は事業者側のポリシーであり、本記事はネットワーク設定の一般情報に限定します。契約やアカウントの請求国と矛盾している場合は、ルール以前の要因です。技術的な切り分けと、アカウント設定の確認は並行して見てください。

他ジャンルの分流記事との違い：同じ YAML でも狙いが異なる

同じ「ドメインを書いてポリシーへ流す」でも、Disney+ のようなストリーミングは長時間の TCP セッションと出口地域の一貫性が中心です。ChatGPT や各種 AI API は TLS とタイムアウト、特定 API ホストの前置きが中心です。対して Steam コミュニティ／クリエイティブ・ワークショップ は、多数のサブドメインと静的アセットの組み合わせが前面に出るため、「1 本の API ホストを固定する」よりサフィックスの網羅と画像 CDN の取りこぼし防止が鍵になります。記事同士を読み比べるときは、「同じ DOMAIN-SUFFIX 行でも、安定させたい挙動の意味が違う」と捉えると設定がブレません。

まとめ：コミュニティは「ホストの網羅」、CDN は「無理に寄せない」

Steam は高トラフィックなゲーム配信と、テキスト・UGC 中心のコミュニティ機能が別のインフラ名に乗りやすいプラットフォームです。Steam コミュニティが開かない症状の多くは、プロキシ自体の死活以前に、一部ホストだけ意図した出口に載っていないことに起因します。クリエイティブ・ワークショップ Clash という組み合わせで検索に来た方は、まずログでホストを洗い出し、コミュニティ系だけを安定グループへ、Steam CDN や大容量取得は DIRECT または別グループへ、と役割を分けると再現性のある改善がしやすくなります。

クライアントの導入や更新は、配布元が分かりやすいダウンロードページから行うと、後からルールや購読を調整するときも同じ土台に立てます。YAML と GUI の両方から運用できる柔軟さは、長く使うほど差が出る Clash 系の強みです。

→ 無料で Clash をダウンロードし、Steam 向けに必要なドメインだけを自分のルールへ組み込む