Grok Build CLI・Clash

なぜ「ブラウザは動くのに Grok Build の CLI だけ不安定」になりやすいか

ブラウザは OS のプロキシ設定や拡張機能に追従しやすい一方、node や npm、pnpm、yarn、CLI 本体が内部で呼ぶサブプロセスは HTTPS_PROXY を読まなかったり、親シェルから環境変数が伝搬しなかったりします。xAI Grok Build のような製品では、認証やモデル応答だけでなくツール実行・ファイル取得・GitHub 連携までがワンフローに繋がる設計になりやすく、ログには単一のドメインでは収まらない複数ホスト連続アクセスが並びます。そのためブラウザでは問題なく見えていても、CLI が別出口へ落ちているだけでタイムアウトや中途半端な TLS エラーが増えることがあります。

静的サイトと実 API の分離：x.ai のマーケページは速いが、実際の機能や資産は別サフィックス／別 CDN にあり、広い GEOIP より下へ滑って初回だけ詰まる。
npm のリダイレクト連鎖：registry.npmjs.org から tarball のCDN 行へのリダイレクトが、意図しない低速出口へ吸われる。
GitHub のオブジェクト分散：github.com は速いが objects.githubusercontent.com だけ遅いと、Release 資産や raw の取得だけが途中で切れる。
MCP サーバの副作用：MCP が追加で叩くホストが一覧に載っておらず、CLI のタイムアウトとしてしか見えない。

切り口

症状を「モデルの質」へ結びつける前に、Connections のホスト名と実 outbound を一行ずつ突き合わせる。分流ルールの当たり順がズレているだけで体感は別物になります。

Grok Build 周辺で束ねたいドメインバケット

製品のアップデートで増減するため、ここでは典型的な束ね方だけ示します。運用では必ず失敗ログから実ホスト名を拾い、未知のドメインは一つずつ安全に追加してください。rule-providers の取得失敗と更新間隔に依存する構成では、リストが古いままだと新ホストだけ漏れる点にも注意します。

バケット	代表ホスト（例）	メモ
xAI 公開サイト／ブランド	`x.ai` と関連 CDN（ログで確認）	入口ページと実機能ホストが一致しないことがある
CLI／コンソール実通信	CLI が報告するベース URL と証明書 CN が一致するホスト群	早鳥版では変更頻度が高いのでログ起点が必須
npm / JS レジストリ	`registry.npmjs.org`、 tarball CDN	プラグインや CLI 本体が npm で配られる場合に密集
GitHub	`github.com`、`raw.githubusercontent.com`、`objects.githubusercontent.com`、API	スクリプト取得や Actions／Release と相性の良いノード選択が要る場面あり
MCP と外部ツール	MCP が宣言する upstream（ログで確認）	MCP が npm でサーバを落として動かす場合は上のバケットと重なる

DOMAIN-KEYWORD は誤爆しやすいので、最初は DOMAIN-SUFFIX と確定済みの DOMAIN から始めます。社内の Nexus／Verdaccio を挟む場合は、そのホストは DIRECT 固定が無難なことが多いです。詳細なターミナル設定はターミナル HTTP／Git プロキシと合わせて読むと早いです。

開発者ターミナルの HTTPS_PROXY とシステムプロキシを揃える

Clash Verge Rev でシステムプロキシや TUN を有効にしていても、IDE の統合ターミナルや別ペインのシェルだけ古い環境変数を抱えていることがあります。HTTPS_PROXY／HTTP_PROXY／必要なら ALL_PROXY を明示し、競合する値を一度整理すると Grok Build CLI が最初に踏む出口が読みやすくなります。コンテナや devcontainer ではホスト側の混合ポートへ到達できるかも別問題なので、ブリッジ／ホストネットワーク設定まで含めて確認してください。

シェルで確認したい観点

env | grep -i proxy で矛盾や空設定がないか。
IDE のターミナルが親プロセスの環境を継承しているか。
GUI から起動したプロセスだけ別ユーザー環境になっていないか。

分流ルールの順序：開発者出口を GEOIP より上へ

広い GEOIP や最終 MATCH の直前まで細かい行を置き忘れると、npm や GitHub のオブジェクト配布だけ意図せず直結したり、低速デフォルトへ吸われたりします。xAI Grok Build が短時間に複数ホストを叩くほど、この種の順序ミスがログに散らばって気づきにくくなります。開発者向けに低遅延・安定優先のポリシー群を用意し、エンタメ向けの測定グループとは分離するのが実務的です。

# Illustrative snippet — replace PROXY_DEV with your policy group name
rules:
  - DOMAIN-SUFFIX,x.ai,PROXY_DEV
  - DOMAIN-SUFFIX,npmjs.org,PROXY_DEV
  - DOMAIN-SUFFIX,github.com,PROXY_DEV
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY_DEV
  # Add CLI/API suffixes verified in Connections logs (avoid blind KEYWORD rules)
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

実際には xAI 側で追加されたエッジホストや証明書チェーンに対応する中間 CDN が増えることがあります。スクリプト例はあくまで説明用で、運用値へのそのままの転載は避け、ログで確定したサフィックスだけを足してください。

DNS・fake-ip と長接続

fake-ip を使う構成では、アプリによって名前解決と実接続の見え方がズレ、CLI の再試行ループだけが増えることがあります。Grok Build のような長めの TLS／ストリームを含むワークロードでは、ノード側のアイドル切断とも相まってタイムアウトに見えやすいです。詳細な切り分けは DNS 漏れと fake-ip を参照してください。

二重解決：ブラウザのセキュア DNS と Clash 内 DNS が別回答を返すと、ルールと実接続の組み合わせがブレる。
IPv6：AAAA が先行して不安定な出口へ落ちるケース。
読み取りタイムアウト：CDN 経由の tarball と応答ストリームが重なると RTT が跳ねやすい。

コンプライアンス

企業ネットワークでは許可されていない経路変更が禁止されていることがあります。本稿は許可された環境での経路最適化を想定しています。

ノード選択：url-test のフラップを避ける

開発者向けポリシーは「帯域テストで一位のノード」より、小さな TLS が連続しても途切れないノードが向く場面があります。url-test の間隔が短すぎると出口が頻繁に切り替わり、進行中の npm 取得や長めの CLI セッション が張り直されてタイムアウトに見えます。間隔と tolerance を緩め、フォールバック鎖の深さを抑えると改善することがあります。url-test／fallback／lazy と tolerance の読み替えも参照してください。

TUN とプロセス名：Node 子プロセスを捕まえる

環境変数だけでは拾えないトラフィックは、Mihomo（Clash Meta）系の TUN と PROCESS-NAME／PROCESS-PATH で IDE 付属の node や CLI ランチャーを明示的にマークする手があります。プロセス名は OS ごとに異なるため、タスクマネージャや ps で実名を確認してからルール化してください。GUI 初期構成は Clash Verge Rev macOS 初回設定と権限まわりを揃えると詰まりにくいです。

MCP を使うときのホスト増殖とログ観測

MCP はエディタや CLI から外部サーバへ橋渡しするため、単体の Grok Build CLI より上流ホストが増えやすい構成になります。サーバ実装が npm パッケージとして配られている場合は npm／CDN のバケットと合成されますし、追加でクラウド API を叩くなら別ポリシーが必要になります。Claude Code と MCP／CLI の分流で整理した観測の癖——サブプロセスの環境継承や長寿命コネクション——は、そのままGrok Build 側にも転用できます。

OpenClash／LAN：ゲートウェイと DNS を踏み分ける

ルーターで OpenClash を動かし、開発ボックスを LAN 経由で全屋プロキシする構成では、単体 PC の Clash Verge Rev とは既定ゲートウェイ・DNS の渡り・透明プロキシの組み合わせが変わります。Grok Build を LAN 上のマシンから試すと、GitHub のオブジェクト行だけ別経路になるなど、ホスト単位のズレが表面化しやすいです。OpenWrt・OpenClash の全屋プロキシの要点に加え、次をログで確認すると切り分けが早いです。

LAN 側 DNS：ルーター DNS と端末固定 DNS が食い違っていないか。
国内除外：意図せず直結しているドメインがレジストリやオブジェクト配布だけ漏れていないか。
二重プロキシ：PC のシステムプロキシとルーター側トランスペアレントがループしていないか。

よくある質問

ブラウザでは x.ai が開けるのに CLI だけ失敗する

ブラウザは OS のプロキシ設定に従いやすい一方、CLI は HTTPS_PROXY を無視したり子プロセスへ環境が伝搬しなかったりします。Connections で実際の outbound とホスト名を照合し、シェル・IDE・CI で同一の環境変数になるか確認してください。

npm は速いのに Grok Build の取得だけ遅い

registry と tarball CDN、npm のミラー設定が別経路になるケースがあります。objects.githubusercontent.com など GitHub 配布と npm CDN が別ルールに落ちていないかログで確認し、開発者向けポリシーへまとめてください。

SuperGrok を契約していてもタイムアウトする

認可や招待状態と無関係に、経路・DNS・ノードのフラップで切断されることがあります。まず実ホスト名と RTT をログで確定し、ルール順と url-test を調整してください。サービス側メンテ情報も併せて確認します。

チェックリスト

ブラウザと CLI で、同一ホストの outbound が一致しているか確認する。
x.ai 系・npm・GitHub・CDN・CLI 実ホストを GEOIP より上に置く。
DNS／fake-ip を切り分け、必要なら検証期間だけ経路を揃える。
開発者用ポリシーの url-test がフラップしていないか見る。
MCP がある場合は追加ホストをログから拾い、別ポリシーに逃がす。
OpenClash 環境では LAN の既定ゲートウェイと DNS を再確認する。

2026 年に増えつつある xAI Grok Build のようなプロキシ型コーディング支援では、「単一の速い VPN」よりホスト単位で出口が割れていないかを先に潰したほうが効くことが多いです。ブラウザ向けに最適化された汎用拡張だけに頼ると、ターミナル子プロセスの経路が追いにくく、ログに散らばったタイムアウトの原因特定に時間が溶けることがあります。

一方、Clash／Mihomo エコシステムは分流ルールの順序、DNS、長接続、ノード選択といった開発者タラフィック特有の詰まりを Connections で観測しながら調整しやすい設計です。npm／GitHub／CDN と xAI 側ホストを先に束ね、必要なら TUN とプロセス束ねまで踏み込めば、CLI と MCP を含む試行環境でも依存取得の体感は大きく安定する場合があります。もし同じ課題を抱えているなら、Clash を無料ダウンロードし、まずは Connections ログから出口を揃えるところから試してみてください。

xAI Grok Build の CLI と依存取得がタイムアウトしがちなとき：2026 年、Clash／Mihomo の分流でターミナルと CDN を安定させる