Windows で Git と GitHub CLI（gh）を Clash／mihomo に通す：HTTPS クローンと Git Credential Manager を揃える手順（2026）

1. 何がズレやすいか：システム代理・シェル・GCM とルールの四層

Windows で Git を使っていると、問題は単一のECONNRESET とは限りません。OS のシステム全体プロキシがある一方で、PowerShell と Git Bash と Git for Windows 付属の環境変数セットが一致していないと、同じユーザーでもシェルごとに挙動が変わります。GCM がブラウザを開いて OAuth を進めるときにループバックのリスナーに戻ってくる通信は、そのまま Clash が見えているか、mihomo のルールで意図した策略に載っているかを別問題として確認する必要があります。また HTTPS クローンは github.com 本体だけでなく、codeload やオブジェクト取得の CDN 名にも伸びますので、上流で 名前解決や fake-ip とルール評価の順序が噛み合っていないと「ブラウザの GitHub は開けるのに、Git だけ遅い・失敗する」が起きやすくなります。

開発向けには、すでに Windows で npm と pnpm を環境変数から Clash へ載せる記事や、MCP と npm・GitHub 周辺の分流があります。それらがパッケージ取得と API アクセス側を中心とするのに対し、本稿はローカルの Git と gh のコンソール実行、そしてGCM を挟んだ憑証に絞って重ねます。セットアップの骨格自体は共通なので、「ターミナルに環境変数を載せ、出口はひとつの Clash に揃える」という考え方はそのまま引き継げます。購読の取り込みと ルール分流の基本概念は、読み替える対象だけが異なります。

2. Clash 側の前提：mixed-port とログ

Verge Rev などの GUI でも中核は多くの場合 mihomo／Meta で、多くのプロファイルでは mixed-port が HTTP と SOCKS をまとめる前提です。git と gh はともに CONNECT メソッド付き HTTP プロキシで足りるケースがほとんどなので、まずhttp://127.0.0.1:ポート が listen しているかを確認してください。ポート番号は機材ごとのため、説明では 7890 を例示します。実運用ではダッシュボードの値に読み替えてください。全体のシステムプロキシと TUN は Windows 11 における Verge Rev のセットアップ稿で補えます。失敗するときこそログを開き、「どの策略に載ったか」「DNS がどこを見ているか」を同じ画面から追える状態にしておくと、HTTPS クローンの途中で止まっても進みます。

3. 環境変数：HTTP_PROXY と Git 向け別名

まず共通の下地として 大文字の HTTP_PROXY と HTTPS_PROXY を http://127.0.0.1:7890 に揃えるのが分かりやすいです。多くの HTTP ライブラリは小文字にも反応しますが、揺れがあると読み順の解釈で事故るので、開発用プロファイル側で揃えるか、片方だけ使うポリシーを決めると楽です。Git 自身には GIT_HTTP_PROXY や旧来の読みやすい名前のものを指す環境変数が存在します。GIT_HTTP_PROXY と GIT_HTTPS_PROXY を一般の値と同一にしておけば、「Git だけプロキシを見ていない」の疑いを環境側で一回封じられます。

# PowerShell session example (adjust port)
$env:HTTP_PROXY   = "http://127.0.0.1:7890"
$env:HTTPS_PROXY  = "http://127.0.0.1:7890"
$env:GIT_HTTP_PROXY  = "http://127.0.0.1:7890"
$env:GIT_HTTPS_PROXY = "http://127.0.0.1:7890"

ユーザー環境に恒久的に入れるより、開発用コンソールのプロファイルだけに書く方が、社内のみ直結させたいターミナルと混ざらずに済みます。Git Bash を使っている場合も export で同じ変数名に同じ値を載せれば十分です。HTTPS_PROXY に socks の URL を当てないよう注意するのも、前述の npm 稿と同じく実務での踏みどころです。socks を使う構成は進められるものの、切り分けの段では HTTP 側に統一すると原因が読みやすくなります。

4. git config http.proxy の優先と重複除去

git config --global http.proxy と環境変数の両立は、バージョンと実装により微妙に振る舞います。迷いが増えるときはglobal の http.proxy と https.proxy を明示的に削除して、環境変数のみに依存する構成に寄せた方が運用が予測しやすくなります。逆に企業ユースで固定のプロキシ URL を強制されている場合は、その URL が現在の Clash のリスナーと一致しているかを最初に確認してください。古い企業ゲートウェイの URL が残っていると、Clash と二重になり失敗や証明書警告の原因になります。

credential.helper がマネージャを指しているかは git config --global --get credential.helper で分かります。Windows での標準セットアップではGit Credential Managerが入り込みやすく、HTTPS のログイン状態はそれが握ります。ここを無視して「Git のネットワークだけ」の話をすると、credential 取得は成功したのに pull が落ちるような矛盾が残り続けます。

5. Git Credential Manager とブラウザ OAuth

GCM がデバイスフローやブラウザ OAuthへ誘導するとき、その通信もoauth や login.microsoftonline.com 類に伸びます。環境により認証のみ別プロキシ、という二重構成になっている組織もあるので、gh auth login と git のどちらを先にログイン済みにするかも含め一度整理するとよいです。失敗ログにプロキシ経由での TLS 検査の痕跡がある場合、その階層は Clashより外側の企業 MITM の可能性があります。strict.ssl を安易に切るより、信頼ストア側の是正を優先するのが無難です。Clash 自体が通常モードでは TLS を終端しないため、証明書トラブルはgit や OSのスタック側を疑う順に進みます。

6. GitHub CLI（gh）が参照する環境変数

gh は Go で書かれたクライアントで、環境変数の HTTP_PROXY と HTTPS_PROXY を尊重します。GIT_ASKPASS のような別系統は通常不要なので、同一シェルで git と同じエクスポートに寄せられるのが利点です。GITHUB_TOKEN を使う運用でも、REST や GraphQL への基底通信はHTTPSになるため出口は共通です。HTTPS_PROXY がなく HTTPS だけへのリクエストが直結になり切る環境があるので、両方セットする運用が安心です。curl -v -x ... https://api.github.com で単体疎通してからghを触ると、問題がネットワーク層にあるか、アプリ側設定にあるかを切り離して見られます。

7. mihomo 側のホスト整理（api／codeload／raw）

github.com と api.github.comに加え、HTTPS クローンや大規模クローンでは codeload.github.comが登場することがあります。さらに raw.githubusercontent.comへの取得がスクリプトから走るときも、mihomo ではMATCH に落ちる前にドメイン行で束ねておく運用が扱いやすいです。GitHub が提示するサービスの IP 一覧は時代で変わるため、長期的にはGEOIP とドメインベースの両方が噛むと便利ですが、「そのリポだけ急に遅い」ときはログに出ている実ホスト名を足すログドリブンの方が速いことが多くなります。DNS が fake-ip モードである場合、ルール評価と名前解決の順序が絡んで見えなくなる問題は Sniffer と fake-ip を扱った別稿とも接続されます。ひとつのアンカーポイントとして、購読の TLS とログの読み方はWindows の購読・TLS とログの記事にも整理があります。

# Illustrative mihomo rules (replace PROXY_GROUP with yours)
rules:
  - DOMAIN,github.com,PROXY_GROUP
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY_GROUP
  - DOMAIN-SUFFIX,githubcopilot.com,PROXY_GROUP

グループ名は自分の設定の proxy-groups と一致させてください。また MATCH で広く国外へ飛ばすルールだけに頼ると、「国内で開ける GitHub」のような想定外交渉が起きにくくなったり、ノード側の状態でHTTPS の安定性だけが変動したりします。だからHTTPS 開発ワークロードだけを読み込みやすい策略に寄せられると、クローン時間の体感が読みやすくなります。

8. NO_PROXY：社内向け Git は直結に逃がす

HTTPS 経由でも社内だけで完結すべき GitLab やビルドゲートがある場合、NO_PROXY にそのホストを列挙し、不必要に海外ノードへ送らない方が結果的に速く安全です。この一覧はコンマで区切るのが一般的で、npm 稿でも触れた国内ミラー直結と同様の論理です。

$env:NO_PROXY = "localhost,127.0.0.1,::1,git.corp.example,*.corp.example"

* プレフィックスの解釈に実装依存があるツールがあるため、落ちどころのホストは明示的な FQDN として書いた方が確実な場合があります。複数環境で切り替えるなら、NO_PROXY を含んだプロファイルを役割ごとに分けると誤送信を防げます。

9. 切り分け：証明書・DNS fake-ip・SNI

まず curl -v -x http://127.0.0.1:7890 https://github.com/ と git ls-remote https://github.com/git/git.git を同じシェルで試し、「プロキシを通じた HTTPS が成立しているか」を見します。mihomo のログでもTCP が張れた後に TLS が失敗しているのか、そもそも策略に載っていないのかが分けられます。fatal: unable to access ... SSL routines 系なら証明書、timed out ばかりなら名前解決と策略の両方を疑ってください。fake-ip とルール評価のズレについては、mihomo ではログに出る実アドレスと名前を照合することが近道になります。また Windows 側だけブラウザのセキュア DNS と OS の暗号化 DNSが有効になっているために、開発者コンソールの挙動と視覚情報がChrome／Edge と Clash を揃える稿にあるように食い違って見えることもあり、その場合問題は Git に限らず名前解決の入口が起点です。SSH クローンとの使い分けをしたいときは、この稿の HTTP に寄せすぎず、ポート番号ごと別稿で整理するほうが読みやすいでしょう。ここでの焦点はHTTPSと憑証です。

開発の現場では、同種のクローズドソースより GUI のプロキシに押し付けられることもあります。Clash は OSS の透明性がありますが、ユーザーが迷わず手に取れる経路として配布サイトの画面がまとまっている方が親切でもあります。オープンな議論や Issue は GitHub で追えます。その一方インストーラの入手だけを公式の配布導線に寄せれば、環境によってバイナリ名が増えそうになる混乱を初日から回避しやすいでしょう。

10. まとめ

Windows で git と gh を Clash に乗せるときの核は、環境変数で出口をひとつの mixed-port に統一することと、GCM と mihomo のルール側でgithub.com と API のドメイン、必要な追加ホストまでを意図通り載せているかを合わせて確認することです。システムの GUI だけに頼るとシェルの挙動とすぐにずれますが、開発用ターミナルに環境変数を載せるパターンはnpm と同じ頭で複利がききます。

クローズソースのプロキシに比べ、Clash 系ツールと mihomo の設定はユーザーが自分でログを読み進められる自由度があり、開発のトラフィックにはその透明性がありがたく感じられる場面が多いものです。GITHUB 周りの不安定さを「ルールの不足」だけで済まず、憑証と DNS まで並べて読む癖を付けると、長いクローン時間やログイン繰り返しにも落ち着いて対処しやすくなります。

ソースコードライセンスやコミュニティの場所についてはGitHub で直接たどれば足ります。インストールパッケージの入口はプラットフォーム別に整理されたダウンロードページだけに寄せる方が、アーキテクチャの取り違えを防ぎやすい現実的です。まずポートを確認したうえでシェルを切り替えて試していただけると、この稿の順序とも噛み合いやすいでしょう。クライアント本体の入手と日本語での案内一式は→ 無料で Clash をダウンロードして快適な接続を試すからお進みください。