GitHub の clone と Actions がタイムアウト？Clash 分流・raw.githubusercontent.com を含む実測手順（2026）

検索の意図：GitHub の clone が止まる、GitHub Actions のジョブが途中で読めなくなるとき

2026 年においても、オープンソースのソース取得と自動化は GitHub を中心としたフローに収束しています。その一方で、社内ゲートウェイの外に出るタイミングだけが不安定な回線環境では、単純な ping では説明できないレイテンシで git clone が数十パーセントで止まる、ワークフローの依存インストールとキャッシュリストアだけが異常に遅く見える——といった相談は依然として開発チームによくあります。raw.githubusercontent.com で配布されているスクリプトをワークフローが毎ステップひっぱっている構成だと、その一行が律速にもなりやすく、画面上は「すべての Actions が壊れた」より先に単一ステップだけが異常時間を食うために原因の切り分けが難しいこともあります。

本稿は npm tarball 記事や Docker Desktop との併読を想定しています。npm と tarball CDN の分流がパッケージマネージャ側の細い出口を決めるのに対し、本テーマでは Git 転送レイヤと UI API、オブジェクト CDN、裸取得経路を束ね過ぎないことに注目します。また Docker Desktop と Clash と合わせると、コンテナビルド中の依存取得だけが別問題に見えるときの再現が早くなります。ルール評価の基本は共通のため、詳細はルールガイドにも戻れるようにしました。

注意：企業規程、セキュリティ方針、輸出管理、そして雇用契約上の開発機器運用要件に適合することは利用者側の責任です。本稿は経路選好の説明のみであり、サービス規約への違反や無許可のアウトバウンド迂回を唆すものではありません。

GitHub clone が跨ぐホスト名：Web UI と転送オブジェクトが別腹である理由

画面上で閲覧しているリポジトリの HTML と、実際に clone で落ちてくるパックファイルの配送経路は必ずしも同一ではありません。github.com や api.github.com への認可とレート制御周りの応答だけが先に終わっても、その後続の 大きめの転送フェーズがオブジェクト CDN 名前空間に移る構成は珍しくなく、広い一枚岩の GEOIP に吸い込まれるとブラウザの閲覧はそこそこ速いまま Terminal 側だけが頭打ち、という体感差が説明されます。

仕様と実運用では差分が入り込み得ますが、開発者ワークステーション上で最初に並べておく出発ドメインの例として、次をメモすると切り分けが速くなります。codeload.github.com は過去構成の裸取得にも遭遇するため、自分の環境ログに一度も出ないなら削除して問題ありません。逆にフェッチだけが詰むなら復活させます。オブジェクト名前空間 はリージョンと経路により表記ゆれがありますが、コンセプトとしては単一ホストだけで済まない設計側の意図を尊重し、広すぎる DOMAIN-KEYWORD よりログで名前を増やしてください。

  • コード閲覧と API：github.com、よく並ぶ関連で api.github.com
  • 裸転送レイヤー：codeload.github.com（ログに出れば）
  • オブジェクトストレージ名前空間：objects.githubusercontent.com
  • ブランチ単位の単一ファイル：raw.githubusercontent.com
  • Gist と一部スクリプト直リンクの派生：実ホストをログで拾い、必要なら gist.github.com から延長

ここで重要なのはテンプレ YAML を丸写しするよりも、手元リポジトリで 問題の再現手順があるかぎり接続一覧を並べ続けることです。ワークフローが Composer やセットアップスクリプトを curl で引いたり、モデル関連のヘルパーが gist の raw に依存しているときは、アプリ用の名前空間と GitHub を混ぜ過ぎるとログの読みにくさが増えます。

なぜ Clash で GitHub 専用のプロキシグループを用意するのか

開発者環境のグローバル出口一枚だけを切り替える運用でも、体感は改善することがあります。ただ長い HTTPS 転送と短いレイテンシ評価向きの経路には相性があります。画面上の自動選択グループだけを触り続けるとブラウザの読み込み評価に最適なノードで大きめの転送キューだけが細くなる、という偏りが起きます。GitHub 用の select か url-test を切り、日常の閲覧出口と分けると、次の運用がしやすくなります。

  • 律速だけ出口を差し替えて再試行し、コンテナ側とホスト側のログを並べられる
  • 社内許可リストで残したいサイトを DIRECT に置いたままでも、開発系だけ海外出口へ寄せやすい
  • ワークフローで大量フェッチするときだけ安定ノードへ固定できる

自動テスト側のモデル転送だけが別課題なら、Hugging Face LFS 記事の読み順と棲み分けしても混乱が少ないです。

Clash のルール評価順：GITHUB_DEV 行はでかいセットより先

Clash 系の設定では rules: の配列が上から評価され、最初に一致した行で終わりです。GEOIP と巨大な RULE-SET を先に並べ、そのあと細かく GitHub を足しても適用順が逆転します。DOMAIN-SUFFIX,githubusercontent.com,GITHUB_DEV のような親いっぽい名前は便利に見える一方、広すぎると意図しないサブセットまで同じ出口に載ってしまうリスクがあります。親サフィックスを使うときは自分のワークロード一覧で副作用を読み、そのうえで採否します。GEOIP と DIRECT の境界を引いているときほど、その境界の直上に開発者ホスト明示行があるか確認してください。

GitHub Actions はローカルの Clash と同じモデルとは限らない

GitHub が提供する Hosted Runner は利用者側でクリックひとつで Clash に相当する転送レイヤーを差し込めるわけではありません。そのためワークフロー全体が不安定という報告がある場合でも、第一段はブラウザ上のログとタイムスタンプ、ジョブ内の環境情報を読み、アウトバウンド許可リストに含まれていないレジストリや CDN に当たっているのかどうかを切り離します。そのうえで、オンプレや自購入のランナーに落としているチームへは、この記事ローカルの分岐モデルをそのまま輸送できます。http_proxy と https_proxy と すべての資格証明関連の環境変数の整合を取るときは、アクションのセットアップ段で一度だけ一覧表示するログを挟むなどして二重標準になっていないか確かめると早いです。

ワークフローが セットアップ JavaScript アクションや Marketplace の tar 配布をフェッチするときにも、名前解決だけは通っているのに実体転送だけが頭打ち、という並びがあります。フェーズ表示で止まっている URL をメモしたあと、ローカルの接続一覧に同様の並びがあるか読みます。

二重プロキシ：企業側の明示プロキシの内側でさらに Clash の TUN や明示プロキシを重ねた構成では CONNECT のレイヤが二重になり、ログのどこで止まっているかが読みづらくなります。セキュリティが許す範囲で上流と下流のどちらにルールを集約すべきか、一度整理してから追跡すると対応時間が縮みます。

TUN とターミナル：git と Docker とブラウザの経路ずれ

統合開発環境内蔵ターミナルや単体の Terminal.app はブラウザのプロキシ設定だけでは自動追従しません。TUN を使って OS レイヤまで捕まえるか、環境変数としてプロキシを明示するかの二択を現場で統一しないと、`git ls-remote` とブラウザの閲覧で別出口に載る状態が続きます。手順詳細はTUN ガイドに任せ、この記事側ではチェックリストの役割だけにしました。コンテナ側は前述の Docker 記事の節にも合わせてください。

DNS と fake-ip：ルール上は合っているように見えるのに転送だけ別腹になる理由

名前解決の経路が二重であったり、fake-ip とドメインベースの評価の境界が頭のなかではっきりしていないとき、YAML 側の並びだけをいじっても現象説明が追いつかないことがあります。ブラウザだけ Secure DNS、CLI は別、といった状態は開発者ワークステーションで珍しくなく、構成変更ごとに OS とブラウザの両方でキャッシュの flush を挟むだけでも再現確率が落ちます。IDE プラグイン向け経路だけを切りたい場合は開発者ツール側の名前空間とも混ぜ過ぎないよう注意してください。

YAML の骨格サンプル（概念レベルの例）

実際に利用しているコアのバージョンに合わせてキーを調整してください。ここでは GITHUB_DEV という名前のグループだけ示します。

proxy-groups:
  - name: GITHUB_DEV
    type: select
    proxies:
      - 🇯🇵 長転送重視ノード例
      - 🇸🇬 代替
      - 🌐 自動評価

rules:
  - DOMAIN,github.com,GITHUB_DEV
  - DOMAIN,api.github.com,GITHUB_DEV
  - DOMAIN,codeload.github.com,GITHUB_DEV
  - DOMAIN-SUFFIX,githubusercontent.com,GITHUB_DEV
  - DOMAIN,gist.github.com,GITHUB_DEV
  # GEOIP や広い RULE-SET、社内 DIRECT などは、このブロックの前後関係で再配置してください

親サフィックス行はご自身で副作用を評価してから追加してください。raw.githubusercontent.com だけ細かく切りたいワークロードがあるなら親ではなく単独行を先に置くと事故が少ないです。

実測チェックリスト：ローカルをまず通してからワークフローへ戻す

  1. GIT_TRACE_PACKET=1 と GIT_TRACE=1 を適度なレベルに付けたうえで git clone --progress を再実行し、接続一覧のホスト名と突き合わせます。
  2. ワークフロー同等の処理を単体ランナーかローカルの act 類似ツールでも再現し、Marketplace の tar フェッチだけを切り離してログを読みます。
  3. GITHUB_DEV に載っている接続だけを見て、時間とバイト転送が伸びない段階があるか順に並べます。
  4. 親サフィックス行を広げ過ぎたら一度狭めて、副作用のあるサードパーティの経路混入が止まったか確認します。
  5. ノードのみ差し替えてオブジェクト転送キューだけが改善するタイプかを複数時間帯で比較し、恒久対策として url-test に残す値を決めます。
  6. LFS が有効なリポでは追加ホストだけをリストに足しつつキャッシュ済み転送だけが速く見えるのか読みます。
  7. DIRECT に残すべきミラーと社内向けソースをリスト化し、その行を全開発者共通テンプレの最上部へ移します。

早見：Actions のログに出た単一 URL をその場でブラウザに貼っても再現しないことがあります。認可ヘッダとレートウィンドウとジョブランナーの出口が異なるときに起きやすいので、接続一覧の実名とセットで読むことをおすすめします。

よくある誤認

広いひとつのプロファイルだけで開発と日常を兼ねようとすること

閲覧向け自動選択だけを触り続けると大容量転送の律速だけが読みにくくなります。GitHub とnpm tarball と社内サイトを名前空間だけで離しておくだけでも改善が読みやすくなります。

Hosted Runner と手元環境が同一前提で読むこと

ワークフロー側の恒久対策としては許可リストとキャッシュレイヤ側の読みが主役になります。手元だけ直してチーム問題が続くときはモデルを切り替えないと時間が無駄になります。

raw が常に単純ファイルだと読むこと

raw.githubusercontent.com でも実データが重いワークロードはオブジェクト並みの体感になり得ます。-L 付き curl のリダイレクト先もログに残してください。

FAQ

セルフホストランナーにこの構成を適用するときの注意

ランマシン側で systemd サービス単位かユーザ単位でプロキシ環境変数を同一にしないと、アクションだけデーモンの出口がずれます。コンテナ実行ステップにも同じ名前空間を渡す運用規約があるとログが読みやすいです。

シークレットのフェッチだけ失敗するときは

api.github.com とブラウザのセッション周りだけが異なるときは名前解決の二重化が疑わしいです。dscacheutil -flushcache とブラウザのキャッシュ両方から切ります。

まとめ

GitHub clone のタイムラインは単一ホストだけでは説明できず、ワークフローが重ねるときはオブジェクト名前空間と API と raw.githubusercontent.com まで含めて段階的に並べられます。Clash 分流で出口を開発者ワークロード用にだけ切り、ルール評価順と DNS と TUN か環境変数を揃えれば、画面上の体感とターミナルの体感の差異も説明しやすくなります。GitHub Actions 単体への丸写し適用だけが万能ではなく、Hosted とローカルを混同しないのが第一段です。

一方でクローズドのオールインワン開発者製品には、画面上の自動化は充実している一方で名前空間細分化の説明文が薄いケースがあります。問題が出たときに再接続一覧と並べられるオープンな Mihomo／Clash 系のモデルには、開発者ワークロードの説明耐性という利点があります。狭い自動選択だけでは律速読みが回りきらなく感じられる場面でも、名前空間を積んで出口を分けられると復旧が現実的な時間になります。ClashSource はプラットフォーム別の読み順と一覧を用意しているので、本稿とチュートリアル一覧から環境だけ辿れば迷子になりにくい構成です。Clash 互換クライアントを無料ダウンロードして手元ワークフローを一度通してからチーム共通テンプレに転写すると、ログの共通言語まで揃いやすいです。