1 よくある症状と、通信が分岐する理由
Suno の Web クライアントやスマートフォンアプリは、画面に表示される suno.com だけを見ると単一サービスに見えますが、実際の HTTPS トラフィックは次のように分岐します。まず フロントと API が *.suno.com 系へ向かい、続いて ソーシャルログイン（Google や Apple など）を選ぶと IdP 側のホストへリダイレクトが飛びます。課金やクレジット購入では 決済プロバイダ（多くの場合 Stripe 系ホスト）が挟まり、生成済みオーディオやカバー画像の取得では CDN／オブジェクトストレージの別ドメインに名前が切り替わることがあります。2026 年時点でも「短尺動画の BGM を素早く量産する」「プロモーション用に複数バリエーションを試す」といった用途で AI 音楽需要は高く、経路が一本化されていない環境ではタイムアウトやログイン異常が起きやすいです。
Clash 互換（Mihomo コア搭載の Clash Verge Rev など）で ルールモードを使う場合、問題の本質は「悪意ではなく MATCH の落ち先の不一致」にあります。例えば suno.com だけを海外プロキシに載せ、Google ログインや Stripe の通信が DIRECT のまま不安定な回線に落ちていると、ブラウザ上では一瞬進んで見えても コールバック URL の読み込みで止まったり、課金確認だけ失敗したりします。生成ジョブは完了まで数十秒〜長いとそれ以上かかることもあるため、途中で 長めの TLS セッションが切れるノードでは ETIMEDOUT が出やすくなります。
本稿は公式が公開する固定の「プロキシ用ホスト一覧」があるわけではない前提で、接続ログと開発者ツールの Network タブを正としてドメインを積み上げる方針です。テキスト生成や画像生成の分流はChatGPT／OpenAI 向け記事、Discord を伴うクリエイティブ系はMidjourney × Discord の記事、Google 研究ツールまわりはNotebookLM の記事と併読すると、創作パイプライン全体のルール設計がしやすくなります。
2 suno.com を軸にしたホスト整理
まず確実に押さえるべきは DOMAIN-SUFFIX,suno.com です。ランディング、作成 UI、共有リンク、ヘルプなど、ユーザーが目にする大部分はこのサフィックス配下に収まります。アプリ内 WebView やディープリンクで別サブドメインが増えても、サフィックス 1 行で追随しやすいのが利点です。社内ポリシーで特定パスだけ直結させたい場合は、より細かい DOMAIN ルールを上に積む形にします。
次に多いのが Google で続行です。ブラウザの開発者ツールで、ログイン直後に accounts.google.com、oauth2.googleapis.com、www.googleapis.com、ssl.gstatic.com などへ飛んでいないかを確認し、いずれも意図したアウトバウンドに載せます。Google 全体をプロキシに載せると他の Google サービスまで遠回りになるため、チーム方針と相談しつつ、まずは Suno 再現手順で実際に出たホストだけを足すのが現実的です。Apple サインインを使う場合は appleid.apple.com や *.apple.com 周辺が増えるため、同様にログで拾います。
課金フローでは stripe.com や *.stripe.com、場合によっては決済カードの 3-D セキュア用の銀行ドメインが追加されます。ここが DIRECT で地域制限に引っかかると「クレジットが買えないが生成は動く」という中途半端な状態になります。メディア配信については、プロダクトのリリースタイミングでホストが変わり得るため、本文では特定 CDN のドメイン名を断定せず、後述の「ログで SNI を見る」手順に委ねます。
sunoapi.org など、第三者が提供する HTTP API も流通しています。利用規約とセキュリティを自己責任で確認したうえで、必要ならそのベース URL 用の DOMAIN-SUFFIX を別グループに分けると、本家 Web UI との切り分けがしやすくなります。
3 Clash 分流：DOMAIN-SUFFIX と YAML の骨格
実務では、購読している Rule Provider に「海外メディア」「グローバル SaaS」などのカテゴリを任せつつ、Suno 向けに明示サフィックスをローカルルールで上書きする二段構えが扱いやすいです。以下は 例示です。最終 MATCH より上に置き、SUNO_PROXY は利用中のセレクタ名に置き換えてください。GEOIP,JP,DIRECT など国内直結ルールとの優先順位には必ず衝突がないかログで確認します。
# Place ABOVE the final MATCH rule. Replace SUNO_PROXY with your selector or policy name.
- DOMAIN-SUFFIX,suno.com,SUNO_PROXY
# If you use Google sign-in and logs show these hosts, route them consistently:
# - DOMAIN-SUFFIX,googleapis.com,SUNO_PROXY
# - DOMAIN-SUFFIX,gstatic.com,SUNO_PROXY
# Payment flow (uncomment if Stripe appears in your capture):
# - DOMAIN-SUFFIX,stripe.com,SUNO_PROXY
DOMAIN-SUFFIX はサブドメイン増減に強い一方、意図せず広い範囲を巻き込むと国内サイトまで遠回りします。コメントアウトした Google／Stripe 行は、「Suno 操作時の接続ログに実際に出たときだけ」有効化する運用が安全です。Mihomo では Sniffer や GEOSITE と併用することもありますが、HTTPS の SNI が取れない経路ではルールが空振りするため、Sniffer まわりの記事とあわせて挙動を確認してください。ノードを load-balance で分散する場合は、ジョブ途中で接続が切れないよう 一貫性のあるハッシュの使い方も検討します。
4 Rule Provider で保守ラインを引く
コミュニティ製のルールセットには「海外サイト」や「グローバル AI」といったタグが付いたリストが含まれることがありますが、Suno のような新興サービスは更新頻度の差で数日〜数週間の空白が出がちです。対策として、(1) 信頼できるリモート rule-providers を定期更新し、(2) ローカルの rules セクションに Suno 用の数行を置いて「最後の安全网」にする、のが運用負荷と安定性のバランスが取りやすいです。
Provider を複数束ねるときは、同じドメインが二重に定義されて意図しないアウトバウンドに吸われていないか、設定のマージ結果を GUI またはプレビューで確認します。チームで Git 管理する場合は、Pull Request に「追加したホスト名と根拠（接続ログのスクリーンショット等）」を残すと、後任が迷いません。
5 生成リクエスト、CDN、長めのセッション
AI 音楽生成は、プロンプト送信から完了通知まで 待ち時間が長い処理です。ブラウザは同一オリジン上でポーリングやストリーミング風の更新を続ける一方、完成した音声ファイルのダウンロード URL だけ別ドメイン（CDN）になる構成は一般的です。ここで CDN 側だけが DIRECT に落ち、本体と地理的に遠いエッジに刺さると、プレビューは始まるがフル尺の取得だけ遅い、といった症状が出ます。
切り分けの手順は次のとおりです。まずブラウザの Network で失敗しているリクエストのホスト名をメモし、Clash の接続一覧で同じホストがどのルールにマッチしたかを見ます。必要なら一時的に「そのホストだけ別セレクタ」に逃がして品質を比較します。CDN ドメインを安易にワイルドカードで広げすぎると、無関係なサイトまで同じ経路に載るので、実測で出たホストから順に足すのがおすすめです。
6 システムプロキシ、TUN、DoH のすり合わせ
ブラウザは Chromium 系であれば システムプロキシ設定を参照します。Clash の mixed ポート（例: 127.0.0.1:7890）を OS に登録する方法と、TUN モードで仮想 NIC から全体を捕捉する方法は、どちらも有効ですが「ブラウザだけプロキシを見る」「ターミナルの curl は見ない」といったズレが起きると、Suno だけ不調に見えます。CLI とブラウザを揃えたい場合は TUN か、シェルに HTTPS_PROXY を明示する運用が安定しやすいです。
ルールが正しくても名前解決がバラけると、同じ suno.com でもエッジの所在地が変わり、ログイン Cookie の扱いや CDN の選択が微妙にずれます。Meta カーネル向け DNS／DoH／FakeIP のベストプラクティスで述べているとおり、Clash 内の DNS と fake-ip、および OS 側の DoH 設定を一本化するイメージで揃えると、再現性が上がります。特に「ブラウザだけ独自 DoH を有効にしている」構成では、Clash ログの SNI と実際の宛先 IP の対応が取りづらくなる点に注意してください。
企業ネットワークでは TLS インスペクションがあり、証明書エラーで WebSocket や長めの API が落ちる例もあります。Clash は転送層の装置なので、エラーが TLS か単純タイムアウトかを切り分けたうえで、CA の信頼設定かプロキシ経路のどちらを直すべきか判断します。
7 トラブルシューティング
- トップは開くが「Create」が終わらない：
suno.com以外に API 用サブドメインが増えていないかログで確認し、同じアウトバウンドに載せます。並行してノードの遅延とパケットロスを見ます。 - Google ログイン後に白画面／リダイレクトループ： IdP 側ホストが意図した経路に乗っているか、サードパーティ Cookie や ITP の影響でセッションが欠落していないかを確認します。
- 課金だけ失敗する： Stripe 等の決済ドメインがブロックまたは別経路になっていないか、決済画面の Network タブでホスト名を洗い出します。
- 生成は成功したが再生だけカクつく： 音声ファイルのホストが CDN に分かれている可能性があります。該当ホストをログで特定し、低遅延のノードに載せ替えて試します。
- DNS のせいで挙動が日によって違う： OS の DoH と Clash の DNS を二重に使っていないか、
fake-ipの返答と実ルーティングが一致しているかを再確認します。
8 まとめ
Suno のような AI 音楽サービスは、見た目は単一ドメインでも、認証・決済・メディア配信にホストが分岐します。Clash／Mihomo では DOMAIN-SUFFIX,suno.com を起点に、接続ログで実際に現れた Google／Stripe／CDN ホストを同じ品質のアウトバウンドへ束ねるのが再現性の高いやり方です。Rule Provider に任せきりにせず、ローカルに短い追記ルールを置いておくとプロダクト更新にも追従しやすくなります。
システムプロキシ、TUN、DoH の組み合わせは端末ごとに最適解が異なりますが、ブラウザと OS の名前解決をばらけさせないこと、長めの生成ジョブに耐えるノードを選ぶこと、の二点を押さえると体感は大きく改善します。文章・画像・音楽とツールが増えるほど、ドメイン単位で記事や社内 Runbook を分けておく価値が高まります。
類似の創作系ツールとして、テキスト側は ChatGPT、画像コミュニティは Midjourney、調査メモは NotebookLM など、すでに本ブログで分流パターンをまとめています。Suno はその「音楽」スロットを埋める存在として、ルールセットに 1 ブロック足しておくと運用が楽になります。
