OpenClaw CLI・ゲートウェイ・npm が詰まる？2026 は Clash 分流

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

ブラウザは OS のプロキシ設定や拡張に従いやすい一方、node や npm、pnpm、yarn、gh などの CLI は HTTPS_PROXY を参照したりしなかったりします。OpenClaw CLI は親シェルから起動される本体と、バックグラウンドで動く取得処理で経路が割れると、画面には出ずログにだけ失敗が残ります。さらに CLI ゲートウェイ は長めの TLS セッションやウェブソケット／SSE に依存する実装もあり、ノードの頻繁な切り替わりと相性が悪いことがあります。

ドキュメントと実 API の分離：docs.openclaw.ai は通るが、実際の機能ホストや CDN が別ルールに落ちて初回接続だけ詰まる。
npm のリダイレクト連鎖：registry.npmjs.org から tarball CDN 行への飛び先が、広い GEOIP より下に吸われて初回 TCP が不安定になる。
GitHub のオブジェクト分散：github.com は速いが objects.githubusercontent.com だけ遅延し、Release 資産や raw の取得が途中で切れる。
ゲートウェイと依存取得の二系統：同一の測定グループに載せると、長いストリームがレジストリ取得の体感やログの見え方を悪化させる。

切り口

「モデルが弱い」の前に、Connections のホスト名と実 outbound を一行ずつ照合する。出口名が同じでも当たっているルール行が違えば結果は別物です。

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

環境や設定によって増減しますが、ターミナルで OpenClaw 系を動かすときは次のようなバケット分けが扱いやすいです。本番投入前に、必ず自ホストのログで実名を確認してください。

バケット	代表ホスト（例）	メモ
公式ドキュメント	`docs.openclaw.ai` と関連 CDN	検索意図の入口であり、別ホストへのリンク生成で実通信が増える
CLI ゲートウェイ／API	CLI が参照するベース URL（ログで特定）	握手タイムアウトは経路より先に疑うべき TLS／中間機器問題もあるが、分流ズレが典型
npm / JS レジストリ	`registry.npmjs.org`、CDN 系	プラグイン tarball・メタデータ取得で同時接続が跳ねやすい
GitHub	`github.com`、`raw.githubusercontent.com`、`objects.githubusercontent.com`、API 系	clone、Release、スクリプト取得でオブジェクト行が増える
モデル／外部ゲートウェイ（任意）	利用する推論・ルーティング提供者の API ドメイン	OpenRouter 等を併用するなら OpenRouter 分流の観点と重複確認

CLI が参照するマニフェストが任意 URL を指すと、上表に無いホストが一気に増えます。辞書を無限に広げるより、失敗 URL をログから逆引きして安全に 1 行ずつ足す方が事故が少ないです。リモートの rule-providers に頼る場合は、取得失敗と更新間隔も合わせて確認してください。

端末の HTTP(S)_PROXY とシステムプロキシを揃える

Clash Verge Rev でシステムプロキシや TUN を有効にしていても、ターミナルだけ別経路になることがあります。HTTPS_PROXY／HTTP_PROXY／ALL_PROXY を明示し、混在している古い値を一度整理すると、OpenClaw CLI が踏む最初の出口が読みやすくなります。Git や npm の個別設定まで含めた具体例はターミナル HTTP／Git プロキシを参照してください。

シェルで確認したい観点

env | grep -i proxy で競合する値がないか。
IDE 統合ターミナルが親プロセスの環境を継承しているか。
コンテナや devcontainer ではホスト側の Clash ポートへ到達できるか。

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

広い GEOIP や最終 MATCH の直前まで細かい行を置き忘れると、npm や GitHub だけ意図せず直結したり、遅いデフォルト出口へ吸われたりします。OpenClaw が密集して触るホストをまとめ、エンタメ向けの遅延測定グループとは別の低遅延・安定優先ポリシーへ流すのが実務的です。

# Illustrative snippet — replace PROXY_DEV with your policy group name
rules:
  - DOMAIN-SUFFIX,openclaw.ai,PROXY_DEV
  - DOMAIN-SUFFIX,npmjs.org,PROXY_DEV
  - DOMAIN-SUFFIX,github.com,PROXY_DEV
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY_DEV
  - DOMAIN-SUFFIX,npm.community,PROXY_DEV
  # Add gateway/API suffixes you actually use (verify in logs)
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

DOMAIN-KEYWORD は誤爆しやすいので、最初は DOMAIN-SUFFIX とログで裏取りした DOMAIN 行から始めます。社内の Nexus／Verdaccio がある場合は、そのホストは DIRECT 固定が安全なことが多いです。

DNS・fake-ip と長接続

fake-ip では、アプリによって名前解決と実接続の見え方がズレ、再試行ループが増えます。CLI だけおかしいときはブラウザのセキュア DNS を一時オフにして検証経路を一本化し、切り分け後に元へ戻すのが定石です。詳細は DNS 漏れと fake-ip を参照してください。

二重解決：DoH と Clash 内 DNS が別回答を返すと、ルールと実接続の組み合わせがブレる。
長めの読み取りタイムアウト：CLI ゲートウェイ のストリームと tarball 取得が重なると、ノード側アイドル切断が表面化しやすい。
IPv6：IPv4 だけ安定している出口に、AAAA が先行して失敗するケース。

コンプライアンス

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

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

開発者向けポリシーは「帯域テストで一位のノード」より、小さな TLS ハンドシェイクが安定するノードを選びたい場面が多いです。url-test の間隔が短すぎると出口が頻繁に切り替わり、進行中の npm／ゲートウェイ長セッション が張り直されてタイムアウトに見えます。間隔と tolerance を緩め、フォールバック鎖の深さを抑えると改善することがあります。

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

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

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

ルーターで OpenClash を動かし、PC や開発ボックスを LAN 経由で全屋プロキシする構成では、単体 PC の Clash Verge Rev とはデフォルトゲートウェイ・DNS の渡り・透明プロキシの組み合わせが変わります。OpenClaw を LAN 上のマシンから使うと、npm のみ別経路・別 DNS に落ちてタイムアウトが増えることがあります。OpenWrt・OpenClash の全屋プロキシで押さえた要点に加え、次をログで確認すると切り分けが早いです。

LAN 側の DNS：ルーター DNS と端末固定 DNS が食い違っていないか。
国内除外リスト：意図せず直結しているドメインがレジストリ行だけ漏れていないか。
二重プロキシ：PC 側のシステムプロキシとルーター側の透明キャプチャがループしていないか。

よくある質問

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

ブラウザは OS のプロキシ設定に従いやすい一方、CLI は HTTPS_PROXY を無視する実装やサブプロセスの環境継承がズレることがあります。Connections で実際の outbound とホスト名を照合し、シェルと CI で同じ環境変数になるか確認してください。

ゲートウェイ握手だけ証明書エラーに見える

TLS ハンドシェイク前に経路タイムアウトすると、クライアントによっては証明書検証失敗のように表示されることがあります。まず RTT と途中プロキシのループを疑い、ノードのフラップや IPv6 優先も切り分けてください。

ルーターで OpenClaw を動かすと npm だけ不安定

OpenClash では LAN→ゲートウェイ→DNS の経路が PC 単体の Clash と異なります。該当ホストが意図せず国内直結している、または透明プロキシと二重 NAT が噛み合っていないケースをログで確認し、必要なドメインだけ上位ルールへ寄せてください。

チェックリスト

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

2026 年の CLI エージェント開発では、単一の「速いノード」より、公式ドキュメント・CLI ゲートウェイ・npm／GitHub が別々の測定グループに飲み込まれていないかを先に潰すほうが効きます。ブラウザ向けに最適化された汎用 VPN や拡張だけに頼ると、ターミナル子プロセスの出口が追いにくく、ログに散らばったタイムアウトの原因を特定しづらいまま時間が溶けることがあります。

一方、Clash／Mihomo エコシステムはルール順とポリシー分離、DNS、長接続、ノード切り替わりといった開発者トラフィック特有の詰まりを、クライアントの Connections で観測しながら調整しやすい設計です。ドメイン単位で意図した出口を先に決め、必要なら TUN とプロセス束ねまで踏み込めば、OpenClaw のような CLI 中心ワークフローでも取得失敗の体感は大きく減らせることが多いです。もし同じ課題を抱えているなら、Clash を無料ダウンロードし、まずは Connections ログから出口を揃えるところから試してみてください。

OpenClaw CLI とゲートウェイ・npm・GitHub がタイムアウトしがちなとき：2026 年、Clash／Mihomo の分流で docs と依存取得を安定させる