1 「総タイムアウト」の正体を分岐通信として捉えること
オンラインのブラウザ IDE とエージェントを日常の開発ワークフローに組み込むチームほど、アウトバウンドの状態がワークスペース内部の状態と離れ、「画面全体が読み込みだけで固まっている」体感を強く報告します。2026 年時点でも、Replit が提供しているのは複数サービスへの HTTPS／WSS と内部ジョブ制御であり、問題は単一サービスだけが落ちるというよりむしろ、開発者側の環境にあるプロキシと DNS とセレクタの組み合わせにより、サービスチェーンどころかサービス順序が細かく入れ替わることへの耐性が試されている場面があります。
典型のフェイルパターンとしては、アカウントサイトとランタイム接続だけが異なる地域の CDN に張り、その間にあるトークンの更新処理がクロスオリジンで順番依存になっている状態が繰り返し観察されます。その結果、アプリ画面上は「コンテナ準備済み」のままでもログストリームが止まり、並行していたエージェントのタスクキュー側タイマーだけが順番に打ち切られて見えます。ここでの最初のチェックリストは単純であり、開発者コンソールのネットワーク列で失敗コードとホスト一覧を並べ、同じタイムスタンプ帯にある Clash ログの結果と並べられるかだけです。そのうえで、UI 側に表示されるメッセージが「コンテナ側に刺さっているのか」「auth サイトに張り続けられているのか」を言語として揃えると復旧順序が明確になります。
Electron より軽めのワークスペース主体の IDE とは異なり、Replit はタブとパネルだけで済まず、ワークスペースの裏にあるパッケージレジストリやエッジ関数のような周辺リソースにも触れるため、アウトバウンド側に「コンテナとは別グループ」を切り過ぎるとコンテナ側のビルドは速いというのに UI 側チャットのみ伸び続ける状態ができます。並行読みでも役立つのが、GitHub／Copilot 向け認証レイヤーを DOMAIN-SUFFIX で束ねている記事および、ターミナル主体の開発者ワークフローで npm と API を両建てしている記事であり、共通して「認証サイトとモデルサイトとコンテナサイトを混ぜ過ぎない」ことが安定の鍵と書かれています。
2 ログインからランタイムまでに触れる代表的ホスト類
公式のリストは更新されやすい前提で、この節での列挙はあくまで接続ログ上で頻発する名前の一例です。replit.com 配下のアカウントサイトとドキュメント、replit.dev 付近へ落ちていくワークスペース側の開発者ポートレット、コンテナ一覧からの転送レイヤーを含んだ repl.co 系の名前、あるいは古いワークフローを含む開発者環境にある repl.it とリダイレクトを担う名前が同時に並ぶケースがあります。エージェントが外部レジストリへ pull を要求するワークフローでは、コンテナとは別グループにある Docker Hub またはチーム運用しているプライベートレジストリに触れる名前が増え、このレイヤだけが異なる経路に落ちるとコンテナ一覧は成功にもかかわらずパッケージ取得ログだけが総タイムアウトになります。
「公式リストに載っているホストだけ切れば十分」という誤読は避け、チームのテンプレと依存だけが決まっている最小セットをログから並べられるかが重要です。逆に増え過ぎたルールセットは順番依存を誘発します。Replit と並行して使うモデルサービスや Git のドキュメントまで広げすぎると往復が増えてタイムアウトしやすくなるだけのトレードオフになります。手順が軽いチームほど名前の集合だけを増やさず経路評価の順だけを並べられるよう保つほうが再現調査が単純化されます。
- 認証サイトとワークスペース UI：
replit.com配下のホストおよびそれに準ずるワークスペース管理系の名前。Cookie とリダイレクトを跨ぐため順番整合が効きやすく、並行ウィンドウを開いたままログイン状態が食い違うとワークスペースだけが復帰しません。 - ワークスペースとランタイム露出：
replit.devと周辺、公開プレビューに必要な開発者側トンネルを含んだ名前。DIRECTに張り過ぎるとコンテナとは別グループにある認証名前と往復しないままクロスサイトに触れなくなり、プレビューだけが総タイムアウトになります。 - レガシープレフィックス：
repl.coや過去ワークフローからの名前。ワークスペースを跨いだタブ復元時にのみ触れる開発者ワークフローがあり、並行ウィンドウの一方だけが異なる状態を保持していると名前は同じにもかかわらず別セッションだけが異なる状態を読み込み続けます。
3 DOMAIN-SUFFIX と YAML で骨組みから束ねる
実運用での骨格としては共通セレクタに Replit と関係あるホスト名を順番にもれなく並べ、アウトバウンドグループ側で可用性だけを評価するのが読みやすいです。DIRECT を維持しておく国内向けの名前と衝突する場合でも、開発者ワークフロー側を優先させるときは順番だけを入れ替えてよく、並行ウィンドウの一方だけ異なるワークフローを触っている開発者ワークフローでは個別名前を先頭に並べれば十分収束します。このあとで説明しますがGLOBAL 丸投げとは別のグループ運用になり、ワークスペース内部のワークフローを束ねられるのが Mihomo と Clash 互換 YAML の読み書き側の強みになります。
# Place ABOVE the final MATCH rule. Replace REPLIT_PROXY with your selector or policy name.
- DOMAIN-SUFFIX,replit.com,REPLIT_PROXY
- DOMAIN-SUFFIX,replit.dev,REPLIT_PROXY
- DOMAIN-SUFFIX,repl.it,REPLIT_PROXY
- DOMAIN-SUFFIX,repl.co,REPLIT_PROXYYAML の例は骨格に過ぎず、ワークスペースが参照する鏡像レジストリや追加の外部 API が別ドメインに伸びる場合は、接続ログに出た名前をその都度並べていきます。パッケージ取得だけ長く伸びやすいならコンテナとは別グループへ切り出し、アウトバウンド評価は url-test とフォールバックだけを独立させると原因のレイヤーを追いやすくなります。逆にコンテナ側と UI のチャネルを常に同一セレクタに載せ続けるなら、セレクタ内部の並び順をシンプルに保つだけでも「HTTP は通っているのにイベントだけ詰まる」症状を間引けます。
GEOIP や広い DIRECT が混線しやすい理由
「国内サイトはすべて直結」と「Replit は常に迂回」の二つの方針を同じリストに並べたときに起きやすいのが、ワークスペースと認証サイトの間でルール評価の順だけが開発者環境によって食い違うケースです。ブラウザのタブ復元順や拡張のバックグラウンド更新だけが異なる状態を読み込み続けると、アプリ画面上は同じ URL に見えていても内部セッションの整合が崩れタイムアウトに繋がります。画面上の短文メッセージだけではレイヤーを特定できないため、開発者コンソールのタイムスタンプと Clash 側の評価結果を並べたうえで名前単位のアウトバウンド一覧を並べられれば、復旧順序は大幅に単純化します。
4 Rule Provider を補助に据えつつログで追記する
開発者 SaaS に触れる名前を広く載せている Rule Provider が既にあるなら、そのまま再発明せず上流に載せられるドメイン群を活用しつつ、Replit 固有の名前が抜けていないかだけを重点的に足します。上流ルールセットは変更頻度が高く、ときにワークスペースが必要とする開発者ワークフローとズレます。自分のワークフローを守るときはログで拾った不足サフィックスをローカルの小さなリストにだけ書いておき、上流の自動更新とは切り離すのが再現ワークフローの観察を楽にします。メンバーがチームワークフローで共有するときにも、ローカルの追記はリポジトリにコミットしやすいテキスト形式のリストとして差分管理するとトラブルシュート記録が読みやすくなります。
「Rule Provider を信用すれば名前は自動で揃う」という期待自体がズレで、ワークスペース実体と通信するのは常に手元の開発者側です。そのため依存テンプレやパッケージを更新した直後だけでも接続ビューを数分並べて新規ホストだけを別ファイルへ追記する運用がもっとも再現試行だけを抑えられます。追記リストの命名だけ合意しておけば、問題が再び出たときのレビュー往復だけを短時間で終わらせられるでしょう。
5 WebSocket と REST の観察：API タイムアウトとの切り分け
Agent が絡むセッションは長めのイベントストリームを前提にしていて、進捗表示も WebSocket と短い HTTPS 往復の組み合わせに分散します。そのため HTTP 側ばかりがタイムアウトしているのか、イベントだけ RST で切れるのかを先に並べられると打ち手が早く単純化され、前者はセレクタ可用性のみを見直し後者は中経路やローカルポートとアウトバウンド評価のズレだけを読み込めば済みやすくなります。MCP と npm と Git を束ねた記事とも接点があり、ワークスペース外にある長時間通信だけを別セレクタへ切れば観察のノイズを減らせます。
ブラウザ拡張やセキュリティ製品が余計なフェッチを挟んでいる場合でも、Replit を開いたタブの開発者コンソールに出る名前と Clash ログを突き合わせればレイヤ単位での切り分けはほぼ同じ手順になります。別タブだけが並行状態を読み込み続けるならウィンドウを閉じ直すだけでワークスペースだけが復帰するような簡単な原因も残るためログと画面を両方並べられるかが鍵になります。
6 クラウドビルドとプレビュー周辺の切り分け
ワークスペースとコンテナ側は同じセレクタに載っていても、ビルド引数だけが公開 npm、GitHub Container Registry (ghcr.io)、または社内 Maven／PyPI のミラーへ伸びていると「ランタイムは立ち上がるのにログ取得だけ総タイムアウト」のように読めます。その場合ログに出ているレジストリ名とプレビュー用サブドメインを別リストとして束ねれば、ワークスペース UI とビルド基盤の間でノード評価が食い違うケースだけを単独に検証できます。npm と Git をクラウド IDE ワークフローで両建てする記事はビルド層だけを切り出すときの並べ方にも流用できます。
ブラウザ上のリアルタイムプレビューは短命な WebSocket と静的アセット取得へ分割されるため、ワークスペースそのものが成功していても拡張のブロックリストだけが画像やフォントだけを続けて落とすような症状が現れます。まずワークスペース専用のブラウザプロフィールへ切り替えて拡張を無効化し、開発者コンソールのネットワーク列とログを並べられるかだけ見れば切り分けが早く済みます。
7 DNS／FakeIP／DoH とルールを揃える
ルールだけ整えても、ブラウザと Clash の名前解決が別経路を見ていると WebSocket と REST が別アウトボックスへ落ち、認証ワークフローだけがクロスサイト制約で順番依存になることがあります。Meta／Mihomo の DNS と FakeIP 実務に沿って fake-ip と redir-host、DoH エンドポイントだけをワークスペースセッション前にセットで並べられると名前の食い違いだけ単独に収束しやすくなります。
ワークスペースだけでなくローカル CLI やブラウザまで同一の構成を当て込むほど症状の再現条件が単純化されるため複数ノート PC をまたぐチーム運用ほど差分リストを短文でまとめておきます。そのうえで TUN とシステムプロキシを両方オンにすると往復評価が食い違うケースだけを避けるだけでもトラフィック順序だけが単純化します。
8 トラブルシュート早見表（API と WebSocket タイムアウト）
- ブラウザで replit.com は開けるのに Agent だけ総タイムアウトになる：
replit.devとrepl.coなどランタイム系サフィックスが同一セレクタに並んでいないケースや、イベントだけ異なる評価に落ち続けているケースがあります。開発者コンソールでwss://の失敗だけを並べられると順番依存が単純化されます。 - ログイン済みワークスペースだけが復帰しない： Cookie とリダイレクト状態だけがワークスペース以外の並行ウィンドウで食い違っているケースがあります。余計なタブを閉じたうえでもう一度ワークスペースだけを単独ウィンドウで開きログインフローを試すだけで収束することが多くなります。
- コンテナが起動したのにログ取得だけタイムアウトになる：
ghcr.ioや公開 npm がワークスペース UI と異なる評価に落ち続けているとビルド層だけが詰まります。開発者コンソールと Clash ログを並べ不足サフィックスだけをリストへ追記します。 - プレビューだけが詰まる： 広告ブロッカーやコンテンツスクリプトが静的アセットだけ別経路へ送っているときに起きやすく、ワークスペースとは無縁にも見えるホストだけ評価の底へ落ち続けます。専用プロフィールへ切り替えて拡張を無効化しアセット名前だけ並べられるかを確かめます。
- ルールセットや購読を更新した直後だけ異常になる： 評価順だけが並び換わっているケースを疑い、更新直前のログと並べられるかだけを単純比較できると復旧試行のみが単純化されます。
- 証明書エラーだけが並ぶとき： HTTPS 復号を挟む企業構成ではワークスペースのみが総タイムアウトにも見えることがあります。まず一時的に Clash をオフにしてブラウザの証明書警告だけ確認し、復号側の許可リストとトラフィック経路だけをインフラ担当とセットで並べられるよう調整します。
9 よくある質問（Replit Agent と Clash 分流）
Q. Replit が「総タイムアウト」のようにすべて止まって見える原因は何ですか。
A. 多くは単一サービスですべてダウンしたのではなく、認証用ドメイン、ランタイム用ドメイン、ビルド用外部レジストリ、およびプレビュー用ホストへの経路や WebSocket が一部だけルール順で異なる経路に落ち、クライアント側が順番にタイムアウトしている状態です。
Q. グローバル VPN と Clash のルール運用、Replit での安定性はどちらですか。
A. グローバル VPN は国内銀行やクラウド社内コンソールの往復にも影響しやすく再現性差が増えます。国内向けを DIRECT で残せるクラスは残し、SaaS とビルド用外部資産だけ別セレクタへ載せる Clash／Mihomo のルールモード運用が、長時間の開発セッションでは切り分けやすいことが多くなります。
Q. ビルドは速いがプレビューだけ落ちます。優先チェックすべき項目はどれですか。
A. コンテナ側は通ってもウェブ側の WebSocket と CDN ヒットだけが異なるポートやホストにある場合があります。開発者コンソールのネットワーク列と Mihomo／Clash Verge Rev の接続ログで、wss:// と静的アセットのアウトバウンドを並べられるかだけを確認します。
10 まとめ
Replit Agent を含むセッションは、認証 UI、ワークスペース側ランタイム、ビルド用レジストリ、プレビューと CDN、そして状態ストリーム用の WebSocket が同じ画面に並んでも複数レイヤーを跨いだ通信として走り続けます。Clash で DOMAIN-SUFFIX を使い replit.com と replit.dev、repl.co／repl.it を束ね、アウトバウンド評価順だけが読み換わってもログで追えるよう Rule Provider とローカルの追記リストを二分すると、「総タイムアウト」に見える事象でも原因レイヤーを切り分けやすくなります。
システムプロキシと TUN、環境変数をどこまで効かせるかはチームの端末ポリシー次第ですが、DNS をルールと一貫させ、TLS 切断と単純なタイムアウトだけを並べられるようにしておくと復旧が速くなります。単機能のブラウザ拡張型プロキシより、DNS とログを並べられる Clash 互換スタックの方が、長時間のクラウド IDE 開発には向きやすい場面が増えています。
端末丸ごとのグローバル VPN は一時しのぎにも見えますが、オンラインバンキングや社内向けサイト、その他会社 VPN までひとつのトンネルに載せ換えられがちです。細かくホストを選びたい Replit と相性が悪く、再現調査が難しくなりやすくなります。またブラウザ拡張だけをオンにするとタブだけに効きワークスペースとローカル CLI で名前解決の前提がずれやすく、タイムアウトがワークスペース側だけ長く続く場合もあります。それに対し Clash Verge Rev と Mihomo コアでは、DOMAIN-SUFFIX・Rule Provider・DNS・接続一覧を並べられるためログイン〜ビルド〜プレビューまで順に整えられます。Windsurf や Cursor と同様に、クラウド IDE ごとの手順だけを別ドキュメントへ分けておくとオンボーディングや障害レビューの分担が楽になります。
→ 無料で Clash をダウンロードし、Replit のログインとクラウドビルド用ホストだけを分流で並べられるようにする
