この記事で分かること

Clashを有効にしているときだけGitHubがタイムアウトする、ブラウザではトップページが表示されるのにgit cloneやReleaseファイルの取得だけ失敗する、というトラブルは珍しくありません。原因はノードの速度だけとは限らず、GitHub関連のドメインが異なるルールへ分流されている、DNS応答だけが別経路になっている、GitがClashのプロキシ設定を読んでいない、といった複数の要因が重なっている場合があります。

本稿では、Clash Verge RevやMihomo系クライアントを前提に、ブラウザ表示・Git操作・ファイルダウンロードを分けて確認します。ログで接続先を特定し、ルールとDNSを整え、必要に応じてGitへ明示的にプロキシを渡す順番で進めれば、むやみにノードを入れ替えずに原因を絞り込めます。なお、職場や学校のネットワークでは管理者ポリシーが優先されるため、許可された範囲で設定を変更してください。

GitHubだけ失敗する症状と主な原因

まず「GitHubが使えない」という一つの症状を、通信の種類ごとに分解します。ブラウザとGitは同じHTTPSを使っていても、プロキシの参照方法や接続先が異なります。ブラウザだけ成功したからといって、Gitの経路も正常とは限りません。

症状 確認したい接続先・設定 よくある原因
github.comが開かない Clashの接続ログ、DNSモード、ルール DIRECT経路の遅延、DNS汚染、ノード障害
画面は開くがリポジトリを取得できない github.com、Gitのプロキシ設定 Gitがシステムプロキシを参照していない
git cloneは進むが途中で止まる objects.githubusercontent.com、通信ログ 大容量オブジェクト用ホストの分流漏れ
Releaseや画像だけタイムアウトする github-releases系のリダイレクト先 CDNやアセット用ドメインが別ルールに落ちている
名前解決エラーが出る ClashのDNS設定とOSのDNS DNSだけDIRECT、またはIPv6経路との不整合

GitHubのWeb画面は主にgithub.comへ接続しますが、Gitリポジトリのオブジェクト、Release、パッケージ、画像や添付ファイルは別ホストへ移動することがあります。特に「トップページは正常なのにcloneだけ失敗する」ケースでは、最初からノード全体を疑うより、Clashのログに表示された実際のホスト名を確認する方が効率的です。

また、タイムアウトと認証エラーは意味が異なります。407 Proxy Authentication Requiredならプロキシ認証、Could not resolve hostならDNS、Connection timed outなら経路やファイアウォール、SSL certificate problemなら証明書検証を優先して確認します。エラーメッセージを「GitHub全体の障害」と一括りにしないことが重要です。

実際に切り分ける手順

ここからは、設定を大きく変える前に現状を記録します。Clashの画面でログを開き、GitHubへのアクセスを発生させながら、接続先、使用ルール、出口グループ、結果がどのように表示されるかを見てください。ログが増えない場合は、ブラウザやターミナルの通信がClashを通っていない可能性があります。

ブラウザから接続を確認する

最初にブラウザのプライベートウィンドウでGitHubのトップページ、対象リポジトリ、Releaseページを順番に開きます。ログにgithub.comが現れ、想定したPROXYグループへ入っているかを確認します。トップページだけでなく、リポジトリ内の大きなファイルやReleaseのダウンロードも試すと、アセット用ホストの漏れを発見しやすくなります。

ブラウザが完全に失敗する場合は、まずClashのシステムプロキシが有効かを確認します。OS側に古いプロキシが残っていたり、別のVPNクライアントが仮想アダプターを占有していたりすると、Clashの画面上では起動中でも通信が別経路へ流れることがあります。不要なVPNやプロキシを一度停止し、Clashだけを有効にして再試行してください。

Gitとcurlを個別に確認する

ブラウザが動くのにGitだけ失敗するなら、Gitがシステムプロキシを自動利用していない可能性が高いです。Clashの混合ポート番号を確認し、テスト用に次のような環境変数を設定します。ポート番号は実際のClash設定に合わせて変更してください。

export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1

curl -I -v https://github.com
git ls-remote https://github.com/OWNER/REPOSITORY.git

Windows PowerShellでは環境変数の書き方が異なりますが、考え方は同じです。curl -I -vでTLS接続まで進むか、Clashログに接続が記録されるかを照合してください。curlは成功するのにGitだけ失敗する場合は、Git固有の設定を確認します。

git config --global --get http.proxy
git config --global --get https.proxy
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

設定後は、実際のリポジトリに対してgit ls-remoteを実行します。これはcloneよりデータ量が少なく、認証や到達性を確認するテストに向いています。公開リポジトリで成功したあと、社内リポジトリやSSH形式のURLを試す場合は別の注意が必要です。

HTTPSではなく[email protected]:OWNER/REPOSITORY.gitというSSH形式を使っている場合、通常のHTTPプロキシ設定はそのまま適用されません。SSHのポート22がネットワークで制限されているときは、組織の方針に従い、HTTPS方式へ切り替えるか、許可されたSSHプロキシやポート設定を利用します。無理に複数のトンネルを重ねると、原因が追いにくくなります。

ClashのルールとDNSを整える

ルールモードでは、GitHub関連の通信を意図したプロキシグループへ送ります。一般的にはgithub.comだけでなく、ログに出たアセット・API・CDN系ホストも確認します。ただし、インターネット上のドメイン一覧をそのまま大量に追加するのは安全とは限りません。まず実際に失敗した通信のホストを記録し、必要な範囲だけルールへ加える方が、誤分流や速度低下を防げます。

  • Web本体：github.com、必要に応じてapi.github.com。
  • Git転送や大容量データ：ログに表示されたGitオブジェクト用ホストを確認する。
  • Release・添付ファイル：リダイレクト後のホスト名をブラウザ開発者ツールやClashログで調べる。
  • 社内GitHub Enterprise：公開GitHubと同じルールにせず、組織のドメインと社内ネットワークを優先する。

ルールを変更したら、プロファイルを保存してから設定の再読み込みを行います。変更前の接続がKeep-Aliveで残ることがあるため、ブラウザのタブを閉じ、ターミナルも再起動してから同じ操作を再現してください。ルールの順序にも注意が必要です。広いMATCHやGEOIPルールが先にあると、GitHub用に追加したDOMAIN-SUFFIXが評価されない場合があります。

DNSでは、OSが解決したIPアドレスへ直接接続し、Clashのルールと食い違う状態が問題になります。ClashのDNS機能を使う場合は、DNSモード、Fake-IPまたはRedir-Hostの選択、IPv6の有効・無効、上流DNSの到達性を一つずつ確認します。Fake-IPへ変更した直後に一部アプリが動かなくなった場合は、GitHubだけでなく、ローカルネットワークや社内ドメインを除外対象へ入れる必要があることもあります。

TIP：DNS設定を変更する前に、現在のDNSモードと接続ログをスクリーンショットやメモで残してください。変更を一度に複数行うと、改善した理由と新しく発生した副作用を判断できなくなります。

まだ直らない場合の追加確認

ここまでで改善しない場合は、ノードの品質とクライアントの動作を分離して調べます。同じルールのまま別ノードへ切り替え、curlとgit ls-remoteを同じ順序で実行してください。特定ノードだけでタイムアウトするなら、DNSよりも出口の混雑、TLSハンドシェイクの失敗、上流サーバーの制限が疑われます。すべてのノードで同じ結果なら、プロキシ設定、ルール、DNS、またはローカルのファイアウォールを優先します。

Clash Verge RevのTUNを使うと、プロキシ環境変数を無視するアプリも捕捉できる可能性があります。ただし、TUNは便利な反面、企業VPN、Docker、仮想マシン、セキュリティソフト、IPv6設定と競合することがあります。まずはシステムプロキシとGitの明示設定で動作を確認し、それでも特定のGUIアプリやバックグラウンドサービスだけが直結する場合に限ってTUNを試すのが安全です。

証明書エラーが出たときは、GitのSSL検証を無効にして解決しようとしないでください。中間者攻撃や企業プロキシによる証明書差し替えを見逃す危険があります。PCの日時、ルート証明書、会社が指定するCA、ClashやOSのTLS関連ログを確認し、管理者の手順がある環境ではそれに従います。GitHubの障害情報も確認し、他の端末や別回線で同じURLが開けるかを比べると、ローカル問題かサービス側問題かを切り分けられます。

設定を安定させるには、最終的に「どのアプリが」「どのホストへ」「どのルールで」「どのノードを通ったか」を説明できる状態にします。成功したときのルール、ノード、DNSモード、Git設定を記録しておけば、プロファイル更新後に再びGitHubが遅くなっても、同じ確認手順を短時間で再現できます。購読プロファイルが自動更新される環境では、更新後にルールの順序やグループ名が変わっていないかも確認してください。

単純なVPNアプリは全通信を一括で扱うため、GitHubだけの不調でも原因となるルールやDNSを見つけにくく、アプリごとのプロキシ設定にも対応しにくいことがあります。一方、Clashはログ、ルール分流、DNS、システムプロキシ、TUNを段階的に選べるため、ブラウザはPROXY、社内GitはDIRECT、GitのHTTPSだけは明示プロキシ、といった構成を検証できます。GitHubのタイムアウトを経路ごとに整理して安定した接続を作りたい場合は、利用環境に合うClashクライアントを選んで試してみてください。

Clash を無料でダウンロードして、快適なネット体験を →