症状：ストアが回り続けるときに疑う層
典型的には、(1) ストアタブだけが読み込みのまま、(2) ライブラリのサムネイルが一部だけ出ない、(3) ログインやセッション更新のタイミングだけ失敗、のいずれかです。単一 TCP が詰まったのではなく、複数ホストが別出口・別 DNS 応答になっていると、クライアント側では「全体が固まった」ように見えます。ゲームの UDP レイテンシや対戦マッチングは Clash×Steam：UDP とルールセット の論点に近く、本稿ではまずストア／HTTPS の連鎖を安定化する手順に絞ります。
コアと GUI の組み合わせは端末ごとに差があるため、クライアントの選び方 で「Linux で単体バイナリ運用するか、別 GUI を載せるか」を決めてから SteamOS に持ち込むと、設定ファイルの置き場所がブレにくいです。
SteamOS の前提（読み取り専用層と開発者向け機能）
SteamOS 3 系は Arch Linux 系のパッケージ構成をベースにしつつ、更新モデルはコンソール向けに最適化されています。/usr など一部がイメージ管理下にあり、従来の「apt で全部入れる」感覚とは異なります。Clash コアを置く場所は、ホーム配下や /etc 側のオーバーレイなど、自分で書き込み可能なパスに寄せるのが安全です。パッケージマネージャを使う場合も、OS アップデート後に手動で入れたバイナリやユニットが残るかをメモしておくと、トラブル時の再現が速くなります。
デスクトップモードで Konsole を開き、一般ユーザー（deck）で作業する想定で書きます。root 権限が必要なのは TUN デバイスの扱いや systemd のシステムユニット配置などに限られ、可能なら capabilities やユーザユニットで範囲を絞る方針が望ましいです。Linux デスクトップ全般の TUN＋systemd の骨格は Ubuntu での TUN と systemd と同型なので、パスと権限の考え方をそのまま移植できます。
全体方針：まず全局、次にストア向けルールへ絞る
切り分けのコツは、(1) 全局プロキシ／TUNでストアが開くかを先に確認し、(2) 開くならルールを段階的に DIRECT へ戻す、(3) 開かないなら DNS・証明書・ノード到達性を見る、の順です。いきなり細かいドメインリストだけ足しても、上流の ルール順序が広いマッチに奪われているケースが残ります。ルール分流のベストプラクティス で「上から評価される」前提を押さえておくと、Steam 用の RULE-SET を足す位置が判断しやすくなります。
コアの配置と起動（Mihomo 単体バイナリの例）
x86_64 向けの単一バイナリを公式ビルドから取得し、例として ~/bin/mihomo に配置、chmod +x します。設定ディレクトリは -d で明示し、config.yaml・ruleset キャッシュ・実行ログを同じツリーにまとめます。購読 URL にトークンが含まれる場合は、権限を chmod 600 相当に絞り、スクリーンショット共有に載せない運用が安全です。購読とノードの健康診断の習慣は サブスクリプションとノードの保守 が参考になります。
常時起動にするなら systemd ユーザユニットまたはシステムユニットを使い、Restart=on-failure と journalctl --user -u ユニット名 でログを追えるようにします。前景起動では成功するのにサービスだけ失敗する場合は、作業ディレクトリと -d、実行ユーザーが手動時と一致しているかを最初に疑ってください。
環境変数ルート：http_proxy 系で Steam を試す
Steam クライアントは libcurl 系のスタックを通じて HTTP(S) プロキシ環境変数を解釈する場面があります。シェルやデスクトップの起動スクリプトで、次のような変数を mixed-port や HTTP ポートに合わせて設定し、同じターミナルから steam を起動して試します（値は環境に合わせて置換してください）。
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export all_proxy="socks5://127.0.0.1:7891"
export no_proxy="localhost,127.0.0.1,::1"
no_proxy に社内帯や LAN プレフィックスを入れるかどうかは環境依存です。狭すぎるとローカル検証用ホストまでトンネルに流れ、広すぎると期待しないホストが DIRECT になります。コンテナや CLI と同じ変数運用の感覚は Docker・CLI と環境変数 の整理と地続きです。
デスクトップの「アイコンから Steam を開く」場合、シェルに書いた export が引き継がれません。デスクトップエントリの Exec= 行をラッパーに差し替える、またはセッション全体の環境に載せる仕組み（ディストリビューション依存）を検討してください。試験中は Konsole からの起動だけに絞ると、変数の有無を切り分けやすいです。
TUN ルート：デスクトップセッション全体を透過プロキシへ
環境変数が届かないコンポーネントがある、または DNS まで含めて一貫させたい場合は TUN が有力です。概念とルート競合の注意点は TUN モードの深掘り に譲り、SteamOS では「他の VPN や仮想化とルートを取り合わないか」を特に確認してください。CAP_NET_ADMIN 相当の権限が必要になるため、最小権限の専用ユーザー＋capabilities 付与が現実的な落としどころです。
TUN を有効にした直後に SSH やリモートデスクトップが切れるタイプの事故は Linux でも珍しくないため、手元で物理キーボードが使える状態で試し、ロールバック手順（tun.enable: false に戻す、ユニット停止）をメモしておくと安心です。
ルールとドメイン空間（ストアと CDN を割らない）
ストア画面は HTML／API／静的アセット／CDN エッジが別ホストに分散しやすく、ルールで片方だけ別ポリシーにすると「白画面のまま」になります。実務的には steampowered.com 系、steamstatic.com 系、計測で見えた Akamai／Fastly 等のエッジ名を、同一の PROXY グループに束ねる方針が安全です。細かいホスト名は環境と時間で変わるため、メンテ可能な ルールプロバイダに寄せ、更新頻度と信頼できるリスト源を決めておきます。
中国本土向けの「国内 CDN に寄せる」最適化や、利用規約に触れうる所在地偽装は本稿の対象外です。許可された用途の範囲で、自宅や職場のポリシーに沿って出口を選んでください。
DNS・fake-ip とストアホストの相性
fake-ip とルールの組み合わせが一致していないと、「ブラウザでは開けるのに Steam だけ失敗」のように見えることがあります。Clash Meta の DNS：nameserver・fallback・fake-ip-filter に沿って、nameserver と fallback、fake-ip-filter を揃え、ストア系が意図せずフォールバックだけに流れていないかを確認します。IPv6 デュアルスタック環境では、IPv6 と DNS の直結ルール も参照し、A/AAAA のどちらが先に使われているかをログで見ます。
検証の順序とログの見方
(1) コアの API またはログで、ストア起動時に どのドメインがヒットしたかを一覧化する。(2) それぞれについて CHAIN 上のノードと遅延、TLS エラー有無を確認する。(3) 失敗が timeout なのか 証明書なのか RESET なのかを分類する、という順が扱いやすいです。ログの読み方全般は timeout／TLS の切り分け が参考になります。ブラウザで同じホストを開いて比較すると、アプリ固有かネットワーク全体かを分けられます。
小型 Linux ルータで LAN 全体をバイパスする構成は Linux バイパスゲートウェイ の文脈に近く、Deck をクライアントとして載せるか、Deck 単体完結かで設計が変わります。
コンプライアンスと自己責任
Valve の利用規約や地域の法規、職場・学校のネットワークポリシーは利用者側で確認してください。本稿は技術的な切り分け手順の共有であり、未承認の迂回を推奨するものではありません。ゲーム配信やアンチチートとの相性はタイトルごとに異なり、プロキシや VPN を挟むこと自体が利用条件に抵触する場合もあります。
まとめ
Steam Deck でストアが回り続ける症状は、HTTPS の連鎖と CDN が別出口に割れたときに起きやすい典型です。SteamOS 上で Clash 系コアを動かし、環境変数で Steam からプロキシへ載せるか、TUN でセッション全体を透過的にルールへ流すかを選び、DNS・ルール順・ポリシーグループを揃えてからドメイン単位に戻すと、切り分けが破綻しにくいです。オンライン対戦の UDP 最適化は 別稿の Steam×UDP、Linux のサービス化は Ubuntu の systemd 例 と役割分担すると読みやすいでしょう。
→ クライアントの入手と更新リズムは Clash を無料でダウンロード から始め、Deck 上の Konsole で再現手順を短いメモに残しておくと、OS アップデート後の再検証が速くなります。ソースや Issue は GitHub で追い、パッケージの主たる導線はサイト側に揃えると混乱が減ります。