Lovable・Bolt プレビュー安定【2026】AI サイトビルダーと Clash 分流

なぜ「IDE 向け記事」と違うのか

Cursor や Claude Code のような IDE／CLI 中心の記事では、GitHub や単一 API ドメインにルールを束ねれば済む場面が多いです。一方、Lovable や Bolt.new はブラウザ内で完結し、チャット UI・生成パイプライン・プレビュー用 iframe・ホスティング先のサブドメインが同時多発で動きます。ここで出口が分断すると、画面上は「ずっとスピナー」でも、開発者ツールでは特定ホストだけ ERR_CONNECTION_TIMED_OUT になっている、というパターンが出やすいです。

アプリ本体：プロダクトのメインドメイン（ログイン・プロジェクト一覧など）。
プレビュー：デプロイ先やサンドボックスのサブドメイン、しばしば Vercel 系ホスト名。
静的資産：*.vercel-storage.com や各種 CDN、フォント・スクリプトのホスト。

「全部 PROXY」でも動くことはありますが、粗いルールセットだと新しいエッジドメインが最終 MATCH に落ちて不安定なノードへ流れたり、逆に DIRECT 側の DNS だけ別解像度になって 証明書名と実 IP の組み合わせが崩れる、といったジレンマが起きます。

トラフィックの層を揃える

まずブラウザの開発者ツール（Network）で、詰まっているのがドキュメントなのか、WebSocket なのか、フォント／JS の CDN なのかを切り分けます。AI サイトビルダーでは 長めの HTTPS と ストリーミング的な応答が混ざるため、ダウンロード専用に強いノードでもプレビュー iframe の TTFBが悪化することがあります。

考え方

同じ「海外出口」でも、レイテンシの安定と帯域の大きさは別物です。プレビューは小さなリクエストが多段になりやすいので、スピードテストだけ良くても体感が悪いことがあります。

分流：プロダクト用のルール束を作る

Clash（特に Clash Meta／Mihomo）では、proxy-groups に「ブラウザ・生成系向け」のグループを用意し、DOMAIN-SUFFIX や DOMAIN-KEYWORD で既知のプロバイダ帯を先に吸い上げます。具体的なホスト名はサービス側の変更で増減するため、ここではパターンだけ示します（実際の購読ルールの上に、自分用のローカル行を足してください）。

プロダクトのルートドメインと、プレビューに使うワイルドカードに近いサフィックス。
Vercel 周辺：vercel.app やデプロイに伴うサブドメイン（プレビュー URL がこれに乗ることが多い）。
認証・決済・メールリンクが別ドメインの場合は、ログイン直後だけ失敗しないよう幅を持たせる。

リモートの巨大ルールセットをそのまま信じるより、自分が使うツールのホスト名をログで確認してから追記するほうが長持ちします。詳しい DNS と fake-ip の食い違いは「接続中なのに繋がらない？DNS と fake-ip」と合わせて読むと整理しやすいです。

ルール順と YAML の例（イメージ）

以下は構造のサンプルです。グループ名・ドメインは環境に合わせて置き換え、実際に接続が必要なホストをログで確認してください。

# Illustrative — replace AI-BUILDER with your proxy group; verify domains in logs
rules:
  - DOMAIN-SUFFIX,lovable.dev,AI-BUILDER
  - DOMAIN-SUFFIX,bolt.new,AI-BUILDER
  - DOMAIN-SUFFIX,vercel.app,AI-BUILDER
  - DOMAIN-SUFFIX,vercel.com,AI-BUILDER
  - DOMAIN-SUFFIX,nextjs.org,AI-BUILDER
  - MATCH,DIRECT

AI-BUILDER は url-test や fallback など、応答が安定しているノードを集めたポリシーグループにするとプレビューに向きやすいです。逆に、広告ブロック系のリモートルールを上から強く当てすぎると、ビルド用スクリプトのドメインまで落として白画面になることがあるので、詰まったら一時的に緩めて差分を確認します。

切り口	向く場面	注意
`DOMAIN-SUFFIX`	プロダクトの基準ドメインがはっきりしている	CDN が別 TLD になると取りこぼす
ログからの単発 `DOMAIN`	プレビューだけ別ホストのとき	運用追記が増える
プロセスルール（ブラウザ）	同一端末で開発ツールだけ分けたい	ブラウザのマルチプロセスと相性確認が必要

DNS・fake-ip を出口と一致させる

プレビューが「開いたり閉じたり」する場合、ルールより先に DNS の解像度を疑います。fake-ip を使う構成では、ブラウザと Clash の解決結果がズレると一瞬だけ繋がる／証明書警告のように見えることがあります。設定をいじるときは一度に一変数（DNS モード、nameserver、fallback の順）に留めると切り分けが早いです。

長時間 Global モードは避ける

切り分けのための短時間は構いません。普段は Rule と明示的なドメイン束で、不要なトラフィックまで同一ノードに載せないほうが、他タブへの副作用が減ります。

ノード選び：プレビューとビルドの両方

Bolt.new のようにブラウザ上でパッケージ取得やリモートビルドに近い動きをする場合、npm レジストリや GitHub への経路も絡みます。すでに「ターミナルと HTTP 代理」で CLI 側を整えているなら、ブラウザと同じ出口に揃えてホストの期待を一致させます。逆に IDE 記事の「Cursor／開発者向け」と併用するときは、「エディタ用」と「ブラウザの AI ビルダー用」で別グループに分け、ログでどちらに流れたかを確認できるようにしておくと混乱が減ります。

症状別：白画面・スピナー・ビルドタイムアウト

プレビューだけ真っ白

iframe 内のドキュメント要求が PROXY に乗っていない、または 混在コンテンツでブロックされているパターンです。Network で該当フレームの URL を特定し、ルールをそのサフィックスまで広げすぎない範囲で追加します。

中央のスピナーが止まらない

API のストリームが途中で切れている、WebSocket が別出口に逃げている、HTTP/2 の下で中間ノードが詰まっている、などが考えられます。同じ操作を別ブラウザプロファイル（拡張機能なし）で試し、Clash 側のログの最終ポリシー列と照合します。

ビルドやデプロイがタイムアウト

ローカルではなくクラウド側のキュー遅延の可能性もありますが、クライアント側では長い TLS ハンドシェイクや DNS の再試行が見えないボトルネックになります。時刻ずれ（OS の時計）も、証明書検証で奇妙な失敗を招くので合わせて確認します。

Windows／macOS の土台

ブラウザ全体を安定させる前提として、TUN やシステムプロキシの組み合わせは端末ごとに差があります。Windows では「Clash for Windows 完全設定ガイド」、macOS では「Clash Verge Rev の初回設定」で権限とモードを固めてから、本稿のドメイン分流を足すと手戻りが少ないです。

よくある質問

Lovable と Bolt を同じルールにまとめてよい？

同一グループに寄せて構いませんが、失敗時のログでどちらのホストか判別できるよう、コメントやルールプロバイダを分けておくと後で楽です。

Vercel 以外のホスティングにも使える？

プレビュー URL の TLD が変われば、同じ手順でそのサフィックスを追加します。静的ファイルだけ別 CDN のときは、テーブル画像やフォントのホストもログで拾ってください。

チェックリスト

開発者ツールで失敗しているホスト名とステータスを特定する。
そのサフィックスを「AI ビルダー用」ポリシーグループに束ね、ルール順を確認する。
DNS・fake-ip・実出口が同じ前提かを DNS 記事の手順で確認する。
プレビューと API でノード要件が違わないか、url-test のフラップを見る。
問題が解決したら、広告ブロック等の上乗せルールを戻しつつ再発しないか見る。

まとめ

2026 年のAI サイトビルダーは、単一モデル API よりブラウザと CDN に散らばった依存が支配的です。Clash でプロダクト・プレビュー・静的資産を同じ論理出口に寄せ、DNS とノードをログで突き合わせれば、「プレビューだけ壊れる」体感はかなり減らせます。利用規約とローカル法令を踏まえ、自分の管理下の端末での最適化に留めてください。

Clash を無料ダウンロードして、ルールとログで経路を確認する

Lovable と Bolt のプレビューがぐるぐる？2026 年、Clash の分流で AI サイトビルダーを安定させる