検索意図からみる五段階：GitHub → レジストリ → npm → ランタイム → モデル API
「OpenHands インストール 遅い」「OpenDevin docker pull」「GitHub API タイムアウト」「npm registry ETIMEDOUT」「Claude API OpenHands」——キーワードはばらつきますが、レイヤは五段に整理できます。第一段は github.com、api.github.com、raw.githubusercontent.com、場合によって ghcr.io へのソース・Release・認証。第二段は registry-1.docker.io（Docker Hub）、auth.docker.io、CDN 実体へのイメージ pull。第三段は UI やスクリプトが触る registry.npmjs.org と tarball CDN。第四段は Python の pip／uv が叩く pypi.org や社内 mirror（ローカル導入時）。第五段は各プロバイダのモデル API——api.anthropic.com、api.openai.com、generativelanguage.googleapis.com、OpenRouter 経由なら openrouter.ai など——への推論です。五段を頭に置けば、Connections 一覧に出ているのがどの層か切り分けてからルール増分へ進めます。
2026年5月の議論では、旧名 OpenDevin から OpenHands へリブランドしたリポジトリ・イメージタグの差で、検索結果と手元の compose ファイルがずれているケースもあります。まず再現したい操作をひとつに絞り（例：docker compose pull だけ、または git clone だけ）、その時間帯の Clash ログだけを読むのが近道です。MATCH が意図せず直行に落ちていないか、GEOIP と名前ルールの順序も併せて確認してください。
ブラウザは速いが Docker とターミナルだけ不安定になりやすい理由
デスクトップブラウザはシステムプロキシに従いやすい一方、Docker デーモンは /etc/systemd/system/docker.service.d/proxy.conf や Docker Desktop のプロキシ欄が空のまま、docker pull だけが別経路で直結することがあります。さらに OpenHands コンテナは起動後にコンテナ内からモデル API へ出るため、ホストで TUN が効いていても、bridge ネットワーク上のコンテナがプロキシを継承していないと「イメージは取れたが推論だけ止まる」という二段目の失敗が起きます。Mixed Port だけでは「標準環境変数を尊重しない」経路を拾えず、HTTP/3（QUIC）が UDP で抜ける構成もあります。Clash のTUN はホスト側の送出を拘束するため、docker CLI・git・npm・compose ビルドのどれを叩いても一覧に同じ FQDN が載りやすく、分流ルールの効果を検証しやすいです。
名前の前段では DNS も強い論点です。fake-ip とルール評価の順序、別製品の DoH と Mihomo の同時オン、企業 MITM による証明書差し替えは、画面上は抽象的なタイムアウトのまま、一覧側には IP だけの行が増えるなどの痕跡を残します。WSL2 上で Docker と OpenHands を動かす場合は Windows ホストの TUN と Linux ゲストのデーモンが二重になりやすいので、検証コンソールの所在を先にひとつに寄せてください。詳細は WSL2 × Git と npm の記事 を参照すると短絡になります。
最初のひと叩き：RULE で TUN を確実にオンにする
製品ごとのクリック順は異なりますが、方針は共通です。RULE（ルール）モードでプロフィールがエラーなく読み込めることを確認し、TUN をオンにして macOS のネットワーク拡張／Windows のヘルパー承認まで完了させてください。初めて TUN を触る場合は Clash Verge Rev TUN モードガイド を先に通すと安全です。スタックは gvisor と system の選択が環境依存なので、TUN スタック比較記事 も併読するとよいでしょう。
運用ヒント：HTTPS_PROXY・TUN・システムプロキシを同時に強く入れないでください。TUN を先、不足分だけ Docker デーモンや compose の environment に HTTP_PROXY を足す順がログを読むうえでも安全です。NO_PROXY に localhost と社内 LAN が入っているか毎回確認します。
フル機能 VPN と同居していると一覧が多重に見え理由が読めなくなるので、検証中だけ切り離す価値があります。TUN が OS 側でブロックされている端末では、docker pull を実行する同じシェルにだけ HTTP_PROXY／HTTPS_PROXY を export し、~/.docker/config.json の proxies セクションでデーモン層にも伝える二重運用が現実解になることもあります。
分流はログ優先：GitHub・Docker Hub・npm・各社モデル API
固定リストだけに頼ると CDN 切り替わりで陳腐化するので、「失敗ログに名前が並んだときだけ増やす」が持続可能です。GitHub 系では github.com、api.github.com、codeload.github.com、コンテナイメージが ghcr.io ならそちらも手前に。Docker Hub では registry-1.docker.io、auth.docker.io、production.cloudflare.docker.com が典型。npm 側では registry.npmjs.org、npmjs.org。各社モデル API ではログに現れた suffix を DOMAIN-SUFFIX で広い GEOIP,CN,DIRECT やデフォルト MATCH より手前に置き、手動で固定したいプロキシグループへマップします。
# Sketch: observe Connections panel first, paste only what fails
rules:
- DOMAIN-SUFFIX,github.com,DEV_PROXY
- DOMAIN-SUFFIX,ghcr.io,DEV_PROXY
- DOMAIN-SUFFIX,docker.io,REGISTRY_PROXY
- DOMAIN-SUFFIX,npmjs.org,PKG_PROXY
- DOMAIN-SUFFIX,anthropic.com,AI_PROXY
- DOMAIN-SUFFIX,openai.com,AI_PROXY
- DOMAIN-SUFFIX,googleapis.com,AI_PROXY
ルールの「量」より「順序」が重要です。Clash Meta ルール順序と MATCH を理解し、頻出ホスト集合は Rule Provider にまとめてメイン設定を肥大化させないでください。OpenHands がセッション中にプロバイダを切り替えるワークフローでは、url-test が推論中に出口を変えて WebSocket や長時間 SSE が途切れることもあるため、モデル API 用グループは更新頻度の低い手動選択に寄せる運用が安定しやすいです。
Docker と Docker Hub：デーモン・compose・コンテナの三層
OpenHands の公式手順は docker compose up が中心です。詰まりは (A) ホストの docker pull、(B) compose 内 build: の Dockerfile が叩く apt／pip／npm、(C) 起動後コンテナが叩くモデル API——の三層に分かれます。まず (A) だけ再現し、Connections に registry-1.docker.io が載るか確認してください。ホスト TUN だけでは足りず、Docker Desktop や systemd ユニットにプロキシが未設定のままデーモンが直結している例が多いです。Linux では /etc/systemd/system/docker.service.d/http-proxy.conf を整え systemctl daemon-reload && systemctl restart docker 後に再 pull します。
コンテナが bridge のままだと、ホストの分流とコンテナ内の名前解決がずれることがあります。検証段階では network_mode: host（Linux）や compose の extra_hosts、コンテナ environment への HTTP_PROXY／HTTPS_PROXY 注入で「ホストと同じ出口」を明示する方法があります。本番ではセキュリティとポート衝突を見て戻してください。サーバー側に Mihomo コンテナだけ立てる構成は Mihomo Docker compose 記事 が参考になりますが、OpenHands 本体の pull 経路とは別問題として切り分けます。
GitHub：GitHub API・clone・Release・トークン
ソース導入では git clone https://github.com/All-Hands-AI/OpenHands.git（組織名は公開リポジトリに合わせて読み替え）が第一段です。ブラウザでリポジトリが見えても、Git がシステムプロキシを読まない環境では git config --global http.proxy または TUN が必要です。Release バイナリやサブモジュール、Git LFS がある場合は codeload.github.com や LFS 用ホストがログに増えます。プライベート fork や GitHub API 連携では api.github.com への認証付き HTTPS が続くため、Copilot CLI 記事 と同様に github.com 系 suffix を DEV 用グループへまとめると運用が楽です。
# Probes before full OpenHands setup
curl -Iv https://github.com/
curl -Iv https://api.github.com/
curl -Iv https://registry-1.docker.io/v2/
curl -Iv https://registry.npmjs.org/
curl -Iv https://api.anthropic.com/
GITHUB_TOKEN を compose に渡す場合、トークンのスコープ不足は「タイムアウト」ではなく 401／403 になりますが、企業プロキシが API パスだけ別ポリシーだとタイムアウトに見えることもあります。失敗時刻のログ diff で api.github.com がルールに載っているか先に確認してください。
DNS と Fake-IP：TUN の内外で評価を同期させる
ルールに DOMAIN を書いても DNS モジュールが別経路だと、「命中したように見えて実送信が分叉」する静かな失敗が起きます。Meta コア DNS 漏洩防止ガイド と fake-ip-filter 記事 を参照し、FakeIP モードではローカル域・社内管理域を fake-ip-filter に入れ、nameserver-policy を使う場合はルールに現れるホストと整合させてください。Docker の内部 DNS（127.0.0.11）と Clash fake-ip が競合すると、コンテナ内だけ名前が解決不能になる例もあるため、問題がコンテナ限定なら bridge DNS を疑います。
npm と Python 依存：registry・mirror・ビルド段
OpenHands の UI やツールチェーンは npm を触る場面があり、npm config get registry と npm config list -l で「いまのシェルの実ソース」を確認します。社内 mirror や未同期の地域 mirror を指していると、メタデータは取れるが tarball が引けない中途半端な状態になります。Python 側は pip／uv の index URL が pypi.org か社内 Nexus かを compose の build ログと突き合わせ、npm registry だけ直しても build が止まるパターンを避けます。
strict-ssl と企業根証明書の不一致は「タイムアウト」に見えることがあります。TUN と npm レベル proxy が二重に効いていないかも確認し、必要なら npm の proxy 設定を空にして TUN に一本化する選択肢も検討します（社内が明示 upstream を強制する場合は IT 方針優先）。pnpm／yarn 混在ワークスペースでは lockfile 側の registry URL が二重になりやすい点にも注意してください。
各社モデル API：Claude・GPT・Gemini の聯調
イメージと依存が揃っても、OpenHands の自律ループは各社モデル API へのストリーミングに依存します。設定画面や .env の LLM_MODEL、ANTHROPIC_API_KEY、OPENAI_API_KEY、Google 系キーが正しくても、コンテナから api.anthropic.com へ直行しているとタイムアウトします。ホスト TUN で推論リクエストの時間帯にログが出るか確認し、出ない場合はコンテナの HTTP_PROXY または network_mode: host を試してください。OpenRouter や Azure OpenAI などベース URL を差し替える構成では、ログに現れるカスタム FQDN だけを増分します。
単一プロバイダだけ失敗する場合は、その suffix だけルール漏れか、url-test による出口切替かを切り分けます。Claude Code CLI 記事・Codex CLI 記事・Gemini CLI 記事 は各社 API 単体の論点が詳しく、OpenHands では「コンテナ経由」という追加変数がある点だけ意識してください。
compose 導入の再現ワークフロー
- RULE でプロフィール読み込みとダッシュボード異常なし。
- 再現操作をひとつに絞る（
git clone／docker compose pull／npm ci／UI からの推論のいずれか）。 - TUN オン〜権限確認〜同じシェルから再試行〜一覧増分を読む。
- ログにだけ現れた FQDN を
DOMAIN-SUFFIXで増やし、MATCH 手前評価を確認。 - Docker デーモンプロキシとコンテナ
environmentをホストと整合。 - DNS（fake-ip、DoH 競合、stack）を独立点検。
- npm／pip index／
.envの API キーとベース URL を突き合わせ、第五段のモデル API まで再走。
注意：TUN とプロフィール変更が契約・学校・社内規程と衝突する場合があります。許可されていないときはインフラ窓口の案内に従ってください。API キーは compose やシェル履歴に残さない運用を推奨します。
よくある質問
ウェブでも GitHub と Docker Hub が開けるのに pull だけ止まります。
ブラウザと Docker デーモンの経路差です。ホストで TUN を有効にし、デーモン側プロキシ設定を揃え、registry-1.docker.io が接続一覧に出るか確認してください。
コンテナは healthy だが Agent が応答しません。
第五段のモデル API がコンテナ内からプロキシを経由していない典型です。ホストログとコンテナの HTTP_PROXY、network_mode を突き合わせてください。
OpenDevin の古い compose を使っていますが同じですか？
イメージ名と環境変数名は変わることがありますが、五段の詰まり方は同型です。Connections を正として FQDN を増分してください。
まとめ
2026年5月の OpenHands ブームは、自律 Agent の体験以前にインフラの五段——GitHub、Docker Hub／ghcr、npm registry、ランタイム依存、各社モデル API——で足切りされやすい構造です。ブラウザとの経路非対称に見えるだけのとき、Clash のTUN でホストの git・docker・npm を拘束し、Connections をソースに分流ルールへ反映、DNS とデーモン／コンテナのプロキシ継承を並べれば、体感の大半はここで滑らかになります。デーモンごとに proxy URL を手コピーする暫定運用より、一覧とルール評価を揃える GUI クライアントの方が OpenHands の長い compose ログとも相性がよいです。試すなら 無料で Clash をダウンロード のうえ、TUN ガイドを先に通し、上記 curl プローブで五段それぞれを独立検証してください。IDE 専用の Cline／Copilot 向け記事と併用すると、Docker 主体の Agent 運用だけ切り出して再現しやすくなります。