Suno が開けない・生成がずっとぐるぐる？suno.com 周辺とオーディオ配信系ホストを Clash（mihomo）で束ね、DNS・Fake-IP・QUIC まで含めた実測手順（2026）

1. 既稿との棲み分け（音楽聴取・動画生成・Suno 音楽生成）

Spotify 稿で扱う主戦場は、アカウント OAuth や国コード付き曲庫、常時ストリーミングの音声 CDNでした。本編は「既に市販曲がストリーミング再生される」体験に寄せています。一方 Sora 稿は、高ビットの動画配信、マニフェストと大きなバイト列、OpenAI 周辺の名前空間が中心です。Suno（公式サイトは suno.com ドメイン）のブラウザ体験は、短いプレビュー音や生成状況の通知、バックエンド上の 非同期ジョブ、そして 一括配布される静的 JS／CSSの三層に分解しやすいのが特徴です。したがって「トップの HTML は出ているのに、ジョブ成立後の 長めの接続 だけ黙る」といった、ストリーミング長尺版とも動画版とも被らない症状が出やすい、という点を出発点にします。

ルール群の入れ方の共通項は、サブスクリプションの導入で購読を食わせ、ルールの評価順のとおり、具体的な DOMAIN 行を広い MATCH より上に置くことです。以降の例もその前提で読んでください。

2. 症状の層別：UI・ジョブ・プレビュー音・書き出し

まず操作の段階を言語化しておきます。メニューや既存曲一覧、フォームの入力欄は描画できるのに、「Create」以降のプログレスが前進しないのは、多くの場合フロントからバックエンドのジョブ REST あるいはストリーミング応答が、意図しない出口・別の名前解決で宙に浮いています。逆に、ジョブは通る表示になっているのに、プレビュー再生の波形が鳴らないのは、短い 音声断片 を取りに行く別ホストが 直結や別国エッジに落ちている典型で、Suno に限らず生成系 PWA で起きるパターンと似ています。

書き出し（ダウンロード）専用が遅延・失敗するケースは、署名付き URL が別ドメインで一度だけ開く設計のとき、ルール表に入っていないサフィックスへ誘導されて止まることがあります。ここは「同じ商品なのにホスト名が毎回少し違う」というより、「同一セッション内でも表側と裏側で名前空間が違う」と捉えると切り分けが早いです。

3. 静的・API・配信の「別ホスト」仮説

Suno 公式はブランド上 suno.com 一体で案内されがちですが、実接続のレイヤーでは、suno.com 本体の HTTPS、サブドメイン上の API、計測や静的資産、および署名付きの一時的な配信に代表される 高エントロピーなホストが混在しやすい、という仮説でログを眺めると筋が通ります。特に、*.cloudfront.net 系や *.amazonaws.com 系のような、一見どのサービスか分かりにくい汎用サフィックスにプレビュー用オブジェクトが載ると、「suno 用の DOMAIN-SUFFIX を足したのに通らない」というズレ方をします。ここは「Suno 専用の行を増やしすぎて他サービスを誤爆しないか」とのバランスが難しいので、次節のルール例は 出発点に留め、不足分をネットワークログで足す、という方針を推奨します。

認証基盤がサードパーティの IdP ホスト（環境・年度で可変）に分かれていると、メイン域は通るのに、ポップアップのログインだけ失敗という Spotify 的な見え方にも重なります。そこは「実際のサインイン画面の FQDN をメモる」のが最短です。ブラウザの開発者ツールの「保護者」的ブロック、広告拡張、企業 SWG が WSS だけ抜いている、という層と混ぜないよう、まずは Clash だけをオンにして再現消滅を試す価値があります。

4. mihomo ルール例：Suno 用の専用策略

下記は 構造の雛形で、PROXY 名やノード名は手元の購読に合わせて置き換えてください。まず専用の proxy-groups を一つ作り、suno.com および関連しそうなサブドレイン、動画・Suno 用に一般的な suno.ai 系（別製品名が付くミラー的ドメインが存在する年もある）を、ログで本当に使われている範囲に合わせて DOMAIN-SUFFIX で積み上げます。コメントは英語表記にしています。

# proxy-groups: dedicated stack for music-generation web (Suno)
proxy-groups:
  - name: AI_MUSIC_WEB
    type: select
    proxies:
      - YOUR_NODE
      - DIRECT

# rules: place explicit DOMAIN* lines above broad MATCH/GEOIP
rules:
  - DOMAIN-SUFFIX,suno.com,AI_MUSIC_WEB
  - DOMAIN-SUFFIX,suno.ai,AI_MUSIC_WEB
  - DOMAIN-KEYWORD,suno,AI_MUSIC_WEB
  - MATCH,PROXY

DOMAIN-KEYWORD,suno は他サービスに誤爆しやすいため、長期運用なら最終的に捨て、ログで出た FQDN を DOMAIN-SUFFIX に落とし込むのが安全です。TUN モードでは、バックグラウンドのプロセスでブラウザ外からジョブ通知が来る例もゼロではないため、TUN の項を確認し、システムプロキシだけの環境と挙動差を比較すると原因が掴めます。同一 LAN の別端末を代理するなら、allow-lan 回りも視野に入れます。

5. DNS・fake-ip・Sniffer：ルールに載る名前を揃える

fake-ip 有効時は、クライアントが受け取る仮想 IP と、ルール評価に用いるドメインの整合が外れやすいです。Suno のような SPA では、初回 HTML 取得後、多数の XHR / fetch 呼び出しが別ホストに飛びます。ここで DNS だけ意図せず直結していると、「画面は生きているが、ジョブ登録 API だけ 403／タイムアウト」といった不揃いが出ます。

Sniffer（mihomo 系）で TLS の SNI から実名を復元し、再評価に回す、という手は Sniffer 稿に譲ります。ここに Claude 稿で使った 「出口と DNS の二正面」の図式を当てはめると、nameserver がローカル 53 から外れて経路制御できていない、という層の発見に繋がります。

6. QUIC / HTTP3：ブラウザを一瞬だけ平準化する

ブラウザは既定で UDP 上の HTTP/3に寄せ、ルール上は DIRECT に見えても、実体は 同じ FQDN でも 443/UDP だけ外に逃げることがあります。Suno のような帯域は巨大動画に比べて小さくても、短い区間の往復遅延に敏感な UI では、スピナーが目に見えて悪化します。対処の典型は、（1）ブラウザ側で一時的に QUIC 無効 や 互換寄りへ寄せる、（2）mihomo 側で PORT や スニッファ併用 まで含めて UDP/443 の出口を揃える、の二層です。理屈の同型例は Gemini 向けの QUIC 稿にまとまっています。あわせて、Windows でブラウザだけ DNS が別穴になる場合は Chrome/Edge の「安全な DNS」稿を先に揃えてから Suno へ戻ると、同じ作業の二度踏みを減らせます。

7. 実測フロー：DevTools／ログの見方

推奨手順の骨子は次のとおりです。（1）ブラウザの開発者ツールのネットワーク欄を開き、症状が出る操作を一巡させ、失敗色になっている API 行の FQDN と HTTP ステータス、(blocked) 相当の有無をメモする。（2）同じ再現中に mihomo のログを併用し、どの策略に Match したか、DIRECT に落ちていないかを確認する。（3）fake-ip 有効なら、Sniffer の有無を切り替えて、同一操作でマッチ行が矛盾しないか比較する。（4）差分が 大規模 CDN の汎用名だけに出るなら、行を広げるのではなく、Suno セッション内で実際に呼ばれている 短い期間有効の実名を起点に、必要最小限の DOMAIN-SUFFIX も検討する。自動選択系の出口が揺れてジョブがリトライ地獄に入る例は、url-test / fallback 稿の文脈と近いため、手動の単一出口で一度安定するか比較してください。

8. つまずきやすい点

第一に、suno.com 単体だけ通せば完結、という想定に立つこと。実際の生成フローは、同一ブランド内でも複数 FQDNの連続です。第二に、cloudfront.net など 共有 CDN を丸ごと専用策略に積むこと。誤爆が広がり、別サービスまで巻き込みます。第三に、本稿の技術的整理は、法域・利用規約・契約上許容される使い方の範囲を超えた「制限の回避」は扱いません。経路最適化は、正当な接続条件の下で、自宅や社内端末の安定稼働を目的にした一般的な知識に限られます。

9. まとめ

Sunoのような 音楽生成 Web では、表側 UI 用の静的アセットと、裏側の 非同期ジョブ 用の名が分かれやすく、Clash / mihomoでドメインを束ね、DNS・fake-ip・必要なら Snifferで「評価に乗る名前」を一致させ、QUIC の逃げ道を塞ぐ──この一連は、聴取型・動画生成型の既稿を補助線として併用すると、2024 年以降のコミュニティ相談で繰り返し見られる「半分だけ生きる」症状を、再現性のある手順に落とし込みやすくなります。ホスト名は運用で変わるため、実ログを正とする姿勢を忘れないでください。

導入の全体図のおさらいは チュートリアルに任せ、本稿の切り分けを一通り回した上で、クライアントを最新系に揃えて再試行すると、トラブルシュートの当たりが出やすくなります。

安定した GUI から mihomo を触るのが初めての方は、 → 無料で Clash をダウンロードし、接続体験を揃えてから Suno 側のログを再取得する のがおすすめです。