なぜ「全体プロキシ ON」でも Web プレイヤーだけ怪しくなるのか

Spotify の体験は、トップの spotify.com や Open Spotify のランディングだけでは完結しません。プレイリストを開くと open.spotify.com 系のルーティング、埋め込みウィジェット、画像・スクリプト・計測、そして実際の ストリーミング に向く CDN ホストへと、短時間に多数の接続が走ります。ここで GEOIP の広い行や購読に入った巨大な RULE-SET が先に当たると、ページ用は希望の国なのに 音声だけ別出口、あるいは逆、というねじれが起きます。デスクトップ公式クライアントはランタイムが一つのプロセスにまとまりやすい一方、ブラウザはタブ単位・拡張機能・サイト隔離の影響を受けるため、「グローバルに見える設定でも一部だけ直ルート」という報告も検索語に残りやすい分野です。だから最初に疑うべきは帯域の良しあしだけではなく、マッチしたルール名がログで揃っているか です。Netflix 稿 で書いた「ルールの上から順」「GEOIP の置きどころ」は、そのまま 音声 CDN にも転用できます。

検索される症状整理：ログイン、Premium、回転マークの違い

ユーザーが入力しがちな意図は、大きく三つです。ひとつ目はサービス自体が応答しない、ふたつ目は Web プレイヤー の UI は出るが再生が始まらない、みっつ目は Premium やファミリーなどの契約表示がおかしい、です。いずれもネットワークだけが原因とは限りませんが、Web の場合は 認証トークン 取得と コンテンツ配信 が別ドメイン列になっているため、片方だけ DIRECT に落ちていると、「ログインは通ったように見えるのにキューだけ回る」ような中途半端な状態が出やすいです。Open Spotify リンクでアプリ起動まで誘導されるケースでは、さらに OS の URI ハンドラやアプリ側のプロキシ未対応が加わり、原因の切り分けが難しくなります。本稿ではブラウザ内の再生を軸に、まず同一セッションで増え続けるホスト名をログで押さえる方針にします。

DOMAIN-SUFFIX と CDN：ログを正とした追記の仕方

ここでのドメイン例は 執筆時点での一般的パターン であり、サービス側の変更で入れ替わります。名前としては spotify.com、配信・アセット側の scdn.co、サードパーティ CDN（例：akamai 系ホストへ解決される *.akamaized.net など）がログに並ぶことがあります。設定を一気に増やしたくなるほど試行錯誤は進みますが、ログに現れたFQDNそのものを DOMAIN,hostname,STREAM-SPOTIFY として MATCH より上に足すのが一番事故が少ないです。DOMAIN-KEYWORD,spotify のような短いキーワードは、同名を含む無関係ホストを拾ってしまうので避けます。ある程度安定してきたら、繰り返し出る枝を DOMAIN-SUFFIX,scdn.co,STREAM-SPOTIFY にまとめて書くとメンテは楽になりますが、最初から広げすぎると別サービスごと吸い込む危険もあるため、音声が通ったあとで段階的にが安全です。ライブ CDN 分流 の記事で触れた「メインドメイン以外のセグメント用ホスト」問題は、音楽でも同型です。

ルールの順序は購読とセットで読む subscription から降ってくる RULE-SET が先に評価される構成だと、手元で足した Spotify 向けの行より上で別ポリシーに吸われることがあります。GUI 側の「セットの順番」だけでなく、生成 YAML の実並びか、運用ガイドの優先度表をセットで確認してください。

ポリシーグループ：ストリーミングだけ出口を固定する

一般ブラウズ向けに url-test で自動遅延選択していると、計測のたびに国が変わり、Spotify がアカウント側の適用地域ともめて挙動がブレます。視聴用には select 型で ポリシーグループ をひとつ切り（例：STREAM-SPOTIFY）、手動で国を決められるようにします。家族共有で複数マシンから使うなら、そのマシンの Clash が同じ名前のグループを指し、説明するときも「音声はいつもそのグループ」で済みます。DIRECT を残すかどうかは、ご自宅キャリアと地域ライセンスのバランス次第です。GEOIP,JP,DIRECT のような行をお使いなら（地域ごとに国コードは異なります）、Spotify の行がそのより上か、音声ホストだけは例外で上にあるかを必ずログで確認します。

proxy-groups:
  - name: "STREAM-SPOTIFY"
    type: select
    proxies:
      - "us-node-stable"
      - "jp-node-stable"
      - "DIRECT"

rules:
  - DOMAIN-SUFFIX,spotify.com,STREAM-SPOTIFY
  - DOMAIN-SUFFIX,scdn.co,STREAM-SPOTIFY
  # Add per-host DOMAIN lines from your logs above GEOIP/MATCH
  - MATCH,GLOBAL

上の YAML はあくまで 雛形 です。実環境では購読のプロキシ名や、自前の終端ルールへ置き換えてください。コア側の機能差が気になる場合は Clash Meta の更新 もセットで確認すると、ダッシュボードでの接続一覧や DNS ログの見え方が揃います。

DNS 漏洩検知：Fake-IP、ブラウザの「安全 DNS」、nameserver-policy

DNS 漏洩 という言葉は、ひとことを言っても名前解決がプロキシ意図と別経路に抜ける状態を指します。Clash が fake-ip で返しているつもりでも、OS の暗号化 DNSやブラウザの Secure DNS が並走すると、同じホストでも参照 IP の帰属だけがぶれることがあります。Spotify は地域や契約との整合チェックがあるため、このズレが「プレイリストは読めるが広告だけおかしい」「Premium トグルが不安定」のように見えることもまれにあります。設定の細部は Fake-IP と Redir-Host、購読鮮度は 購読自動更新 と併せて読むと、切り分けの打ち手が増えます。Android での端末側挙動は Clash for Android の DNS 記事とも接続されます。

実測の五ステップ（迷子になりにくい順番）

ステップ1：アカウント側の地域イメージとノードの国を書く

まずブラウザ上の適用サービス地域と、自分が選んだ出口の国・ASNに矛盾がないかを確認します。Premium や請求のアドレス周りとも食い違うと、アプリ側のエラーだけをネットワークのせいにしがちになります。

ステップ2：読み込み中に増えるホストを一つだけ取る

Clash の接続ビューや開発者ツールで、キューが回っているあいだだけ現れる名前をひとつメモします。それが DOMAIN 行で自分のグループへ向いているか、もっと広い GEOSITE に飲まれていないかを見ます。

ステップ3：グループ・ルール・YAML の順で足し算する

足りない DOMAIN を挿入したら、関連する音声・画像・JWT まで同じグループ側に載るか再生で検証します。ここでのコツは広い許可を増やす前に狭い許可が効いているかを確認することです。

ステップ4：安全DNSと競合VPNを切って同じ再生を試す

症状が単純な二重化なら、この比較で一気に差がつきます。企業ポリシーや常駐のセキュリティ製品がある環境でも、家庭用ルールとは別レイヤでの DNS 強制があります。

ステップ5：公開の漏洩診断ページと自分のログを並べて読む

診断ツール側に出たリゾルバ一覧と、同じタイミングの Clash DNS 側のクエリログを突き合わせます。TUN で端末全体を押さえる運用へ寄せたいときは TUN とシステムプロキシ を参照してください。

システムプロキシと TUN：Web だけ直したいときの判断

ブラウザならポート指定のプロキシでも足りる一方、別タブだけ直ルート、拡張が独自に DNS を叩く、などが混ざると破綻しやすいです。すべての名前解決を Clash に寄せ切りたいなら TUN モードや OS 側のプロキシ例外の見直しが候補になります。その際も「例外リストに Spotify 関連が紛れていないか」を確認します。競技配信ほど過酷ではありませんが、長時間キューだけ回る状態はユーザー体験としては苦痛なので、出口固定＋ログ起点のDOMAIN追記の二本柱を崩さずに検討するのが安全です。

利用規約と法令 サービス側の地域条件・アカウント規約およびお住まいの法域に従ってください。本稿は一般的なネットワーク設定の整理であり、未提供地域での継続利用を唆す意図はありません。

よくある質問

グローバルプロキシでも Web が回り続けるのはなぜ？

実際には音声 CDN だけルール順で別出口になっている、DNS が端末側に抜けている、安全 DNS が二重、といった組み合わせがよく見えます。ログのホスト単位・ポリシー名単位で並べます。

Open Spotify だけ挙動が違っても不思議ではない？

ランディングとアプリ起動、アプリ側のログイン状態が絡むためです。ブラウザ再生に絞って切り分けると単純化しやすいです。

Premium 表示の異常もネットだけの問題？

必ずしもそうとは限りませんが、ページと API と CDN の経路ねじれは機能フラグや課金表示にまで見えることがあります。まずログの一貫性を取り、アカウント側の制約は別窓で確認します。

まとめ

2026 年時点でも、Spotify は Web 再生 が分散した CDN と認証経路へ依存しているため、「全体 ON」だけでは音声が最後の一歩で止まることがあります。Clash ではログに出た FQDNを正として DOMAIN-SUFFIX や個別の DOMAIN で束ね、ポリシーグループで出口を手動選択に寄せ、次いでDNS 漏洩やGEOIP／MATCH の順番を疑う、という順が迷いが少ないです。YAML の骨格設計や Rule Provider は YAML ガイド、DNS の深掘りは DNS 記事 を基点にすると抜けが減ります。

市販や無料の「ワンクリック VPN」だけに頼ると、しばしばブラウザ外の名前解決が残ったままだったり、アプリ単位で切れない環境だったり、アップデートのたびにプロファイルが不透明になる製品があります。グラフィカルにもシンプルな反面、ログでホスト単位を追いにくく、音声 CDN だけ意図せず迂回するケースの説明にも弱いものもあります。ClashNote が案内している Clash 系クライアントは、YAML とダッシュボードの両面から分流ルールを見える化でき、自分の環境で足したDOMAIN 行やポリシーグループがそのまま再現できる点が強みです。このあたりまで整うと、「とりあえず別ソフトを増やして重ねがけする」より、原因の説明可能性と再現テストが高くなります。クライアントのアップデートや入手はダウンロード一覧から済ませるのが筋なので、その流れも含めて下のリンクから確認してみてください。

→ Clashを無料ダウンロード — 各 OS 向けクライアントを比較し、購読取り込みから接続ログの確認までひと続きで試せます。

ほかの解説は 技術コラム からどうぞ。