v0.dev が読み込めない・真っ白？Vercel と v0 周辺ドメインを Clash（mihomo）で分流し、DNS・Fake-IP・QUIC まで校準する実測メモ（2026）

1. なぜ v0 だけ「半分壊れた」ように見えるか

第一に、トラフィックが単一ドメインに収まっていないことです。v0.devの表ページ、認証まわり、生成結果のプレビュー、裏側の API 呼び出しは、環境や機能追加のタイミングで別ホストへ振り分けられることがあります。ルールで v0.dev だけをプロキシへ載せても、残りの Vercel 系名が直結や別策略のままだと、見た目は動いているのに生成ボタンだけ失敗するといった症状が出ます。

第二に、エッジや WAF 側の応答です。経路や出口 IP が変わると、403・レート制限・ボット対策のメッセージが出る場合があります。これは「プロキシの設定ミス」と「サービス側ポリシー」が混ざって見えやすい領域なので、本稿はホスト名と出口を揃える技術的切り分けに限定し、規約違反となる回避行為は扱いません。

第三に、静的アセットと計測スクリプトの遅延です。フロントのバンドルやフォント、Vercel Insights系のホストが別策略に落ちると、白画面のままネットワークだけ忙しい状態が続くことがあります。Figma 稿で述べた表と CDN の分離と同型の発想で、ログに出た名前から束ねる単位を決めると扱いやすいです。

2. Cursor・MCP 記事との違い（ブラウザ型 AI UI 生成）

Cursor 向けの記事は、デスクトップ IDE・拡張マーケット・npmなど、ローカルプロセスと CLIが絡む名前空間が中心です。一方 MCP 稿は registry.npmjs.org・GitHub API／tarballのように、パッケージ取得と Gitに寄せています。

本稿の焦点は、ブラウザで開く v0.dev と、その背後の Vercel エコシステムです。つまり 同一タブ内の fetch が複数オリジンへ散らばる点を前提に、DOMAIN ルールで束ねる優先度を決めます。IDE や npm の細部は上記の各稿に譲り、ここでは生成 UI・AI ページビルダーの読み込み失敗に絞ります。

購読の取り込みやルールの評価順の基礎は、サブスクリプション導入とルールルーティング解説を併読してください。

3. まず押さえるドメイン：v0・Vercel・インサイト

ドメインはプロダクト改修で増減し得るため、以下は切り分けの出発点として読み、開発者ツールのネットワークパネルとコアログで実名を確認してください。典型的には次が並びがちです。

v0 本体：v0.dev および関連する v0.app など（環境により異なる）。Vercel コア：vercel.com、プレビュー／本番に使われる *.vercel.app。計測・インサイト：vercel-insights.com 配下の名前が混じることがあります。

フォントやサードパーティ CDN が別名になる場合もあるため、失敗しているリクエストのホストをその都度メモし、ルールに必要なサフィックスだけ足す運用が安全です。広すぎる MATCH や過大な GEOIP より先に、細かい DOMAIN 行を置くこと——これは ルールの順序の基本です。

4. mihomo ルール例：DOMAIN-SUFFIX と評価順

実務では 「Vercel / v0 用」の策略グループを一つ用意し、関連サフィックスをそこへ送る形が読みやすいです。プロキシ名は環境に合わせて置き換えてください。コメントは英語表記としています。

# proxy-groups: bundle v0 + Vercel under one selector
proxy-groups:
  - name: V0_VERCEL
    type: select
    proxies:
      - LOW_LATENCY
      - NODE_STABLE
      - DIRECT

# rules: keep these above broad MATCH / GEOIP
rules:
  - DOMAIN-SUFFIX,v0.dev,V0_VERCEL
  - DOMAIN-SUFFIX,v0.app,V0_VERCEL
  - DOMAIN-SUFFIX,vercel.com,V0_VERCEL
  - DOMAIN-SUFFIX,vercel.app,V0_VERCEL
  - DOMAIN-SUFFIX,vercel-insights.com,V0_VERCEL
  - MATCH,PROXY

v0.app の要否は環境差があるため、ログで実際に出た名前に合わせて追加・削除してください。社内プレビュー URL が独自ドメインの場合は、その DOMAIN 行を個別に足します。

自動フェイルオーバーの組み方は url-test／fallback 稿も参照し、v0 向けだけ別グループで固定するか、低遅延グループへ丸ごと載せるかを方針として決めると迷いが減ります。

5. 策略グループと Sniffer（HTTPS の名前）

TLS 越しの通信では、コアが接続先 IP だけを見ている段階ではルールが期待通りにマッチしないことがあります。mihomo の Sniffer で SNI 等からドメインを復元し、DOMAIN ルールと整合させる——このパターンは開発者サイト全般で繰り返し登場します。

ただし Sniffer は設定とプライバシー・互換性のトレードオフがあるため、有効化するかどうかはポリシーに従ってください。有効化する場合も、まずはドメインルールと DNS を揃え、それでも残るケースを Sniffer で詰める順が切り分けとして素直です。

TUN モードと併用する場合は TUN の解説も参照し、ループバックや UWPが絡む Windows では UWP 回環稿のようにプロセス例外が要る場面があります。

6. DNS・fake-ip と名前解決のズレ

fake-ip や redir-host など、DNS モードによっては「ブラウザの見え」と「コアのルール評価」がずれ、意図した策略に乗っていないように見えることがあります。v0 のような同一オリジンに見えても裏で別名のサービスでは、そのズレが部分的な白画面として現れやすいです。

つまずいたら、失敗ホストの解決がどこで行われたかをログに残し、ルールのサフィックスと一致するか確認してください。ブラウザ側の 安全な DNS（DoH） が有効だと、OS や Clash の DNS 設定と二重に解決が走ることがあります。Windows の Chrome／Edge では 安全な DNS 稿の手順で揃えると差分が減ります。

別サービスで fake-ip を深く扱った Claude 稿も、名前と出口のセットを疑うときの参照になります。

7. QUIC / HTTP3 の補足（ブラウザのみ不安定なとき）

HTTP/3（QUIC）は UDP を使うことが多く、ノードの UDP 扱いやローカル FW の影響で、TCP の HTTPS より先に失敗する場面があります。症状が「ドメインは揃えたのにブラウザだけ不安定」に寄っているときは、QUIC を一時的に切って比較するのが有効です。

Google 系と QUIC をまとめて扱う場合は Gemini／Google AI 稿を参照し、フォントやライブラリが Google CDN 経由になるケースではそちらの切り分けと相互補完になります。v0／Vercel 本体のホストは本稿のルールセット側に寄せ、QUIC はブラウザと CDN の組み合わせで疑う、と役割を分けると迷子になりにくいです。

8. 切り分け手順：開発者ツールとログ

実務では次の順が扱いやすいです。（1）ブラウザの開発者ツールで、赤くなっているリクエストのホスト・ステータス・失敗理由をメモする。（2）コアログで、そのホストがどの策略にマッチしたかを確認する。（3）意図したグループに入っているのに 403 や TLS エラーが続くなら、ノードを入れ替えつつ、サービス側メッセージやレート制限の有無を確認する。

「なんとなく直った」ではなく、どのホスト名をルールに足したかを残すと、数週間後のプロダクト更新でも追いやすくなります。チーム利用なら、共有用の策略名と追記サフィックスを短い README に書いておくと、個人設定差による切り分け地獄を減らせます。

9. まとめ

v0.devのようなAI フロント生成ツールの不調は、Vercel 系ホストへの分散と策略・DNS のばらつきが重なると、表面だけでは原因が見えにくくなります。まず mihomo の DOMAIN ルールで v0 と Vercel 周辺を同じ出口に揃え、DNS・fake-ip・ブラウザの DoH を校準し、必要なら QUIC と Snifferで詰める——この流れは、Cursor・MCP・Gemini 各稿と重ならない補助線になります。

同じ Clash 系クライアントでも世代差はあります。手元を最新に近づけ、購読と手元ルールを整理したうえでログを追うのがいちばん確実です。クライアントの入手から始めるなら、 → 無料で Clash をダウンロードし、快適な接続体験を試す ところから整えるのがおすすめです。