開発者向けClash設定ガイド GitHub・Git・SSHを快適化

開発環境の通信を分解する：Clash、Git、SSH、開発ツール

GitHubからリポジトリを取得できない、npm install が途中で止まる、VS CodeやCopilotの接続が不安定になるといった問題は、すべて同じ「Clashの速度不足」が原因とは限りません。開発環境では、ブラウザー、GitのHTTPS通信、GitのSSH通信、パッケージマネージャー、エディター拡張機能が、それぞれ異なるプロキシ設定を参照します。Clashでシステムプロキシを有効にしただけで、すべての通信が自動的にプロキシを通るとは限りません。

最初に確認すべきなのは、通信方式と設定の入口です。GitHubをHTTPS URLで利用する場合は、GitがHTTPプロキシまたは環境変数を参照します。SSH URLを使う場合は、OpenSSHが独自にTCP接続を作成するため、システムのHTTPプロキシ設定をそのまま利用しません。npmや各種CLIは、環境変数、ユーザー設定ファイル、ツール独自の設定の順に動作することがあります。Copilotのような拡張機能は、エディターまたは拡張機能側のネットワーク実装に依存します。

開発用のClash設定：ルール、DNS、モードを安定させる

開発作業では、すべての通信を同じポリシーへ送るより、用途ごとにルールを整理したほうがトラブルを追跡しやすくなります。GitHub、npmレジストリ、コンテナレジストリ、コード署名サービスなど、接続先が明確なサービスは、対応するルールセットやドメインルールで同じプロキシグループへまとめます。一方、社内Gitサーバー、ローカルネットワーク、プライベートレジストリは、誤って外部プロキシへ送らないようにDIRECTまたは社内向けの経路を設定します。

開発中はルールモードを使うのが一般的です。グローバルモードは原因を単純化するテストには便利ですが、ローカルサービス、社内アドレス、パッケージミラーまで一律にプロキシへ送る可能性があります。ルールモードで対象ドメインへのリクエストを行い、接続履歴にマッチしたルールと最終的なポリシーを確認してください。GitHubへアクセスできない場合でも、github.comだけでなく、認証、API、リリース、rawコンテンツなど複数のドメインが関係することがあります。

DNS設定も見落としやすいポイントです。ドメイン名をローカルで解決してからプロキシへ接続する構成では、DNSの応答や地域差によって接続先が変わることがあります。Fake IPを使うTUN構成では、除外が必要なドメインやローカルネットワークを確認し、DNSの横取りとルールの組み合わせを理解しておきます。設定を変更する前に元のYAMLを保存し、サブスクリプションの更新でローカルの変更が消えないよう、対応クライアントのオーバーライド機能を利用してください。

Git HTTPSを設定する：最初は環境変数とGit設定を確認

GitHubのリモートURLが https://github.com/組織名/リポジトリ.git の形式なら、GitはHTTPクライアントとして動作します。Clashのmixed-portまたはHTTPポートを確認し、Gitが参照するプロキシを明示します。ポート番号はクライアントや設定によって異なるため、例の番号をそのまま使わず、Clashの設定画面に表示された実際の待受ポートを使用してください。

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

HTTPSリモートに対してHTTPSプロキシを使う場合でも、プロキシのアドレスが http:// で始まることがあります。これは「プロキシサーバーとの接続方式」を示すもので、GitHubへの最終的な通信がHTTPで平文になるという意味ではありません。ClashのHTTPポートとSOCKSポートを混同しないようにし、SOCKSポートを使う場合はGitや環境によって対応形式が異なるため、公式ドキュメントで確認できる方式を選びます。

一時的な検証では、現在のシェルだけに環境変数を設定する方法もあります。設定を恒久化したくない場合や、直接接続とプロキシ接続を比較したい場合に便利です。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
git ls-remote https://github.com/example/example.git

Windows PowerShellでは環境変数の書式が異なります。会社やチームの端末で共有スクリプトを使う場合、プロキシURLに認証情報を直接書き込まないでください。設定内容は git config --global --list で確認し、不要になったプロキシ設定は削除します。

git config --global --unset http.proxy
git config --global --unset https.proxy

動手操作：Git SSHをClash経由で接続する

GitのSSH URLは、一般に [email protected]:組織名/リポジトリ.git の形式です。SSHはHTTPプロキシの設定を読み取らないため、システムプロキシを有効にしても接続できないことがあります。SSHをClashへ渡すには、ClashのSOCKSポートを利用する ProxyCommand をOpenSSHへ設定する方法が分かりやすいでしょう。

まず、ClashでSOCKSまたはmixedポートが有効になっていることを確認します。次に、SOCKS接続を中継できるコマンドを端末へ用意します。環境によって利用できるコマンドは異なるため、ここでは例としてNcatを使います。Ncatがインストールされていない場合は、OSや組織のパッケージ管理方針に従って導入してください。

Host github.com
  HostName github.com
  User git
  Port 22
  ProxyCommand ncat --proxy 127.0.0.1:7891 --proxy-type socks5 %h %p

この設定を ~/.ssh/config に保存したら、詳細ログで接続経路を確認します。

ssh -vT [email protected]
git ls-remote [email protected]:example/example.git

ポート22がネットワーク側で制限されている場合、GitHubが提供するSSH over 443の入口を使えることがあります。OpenSSHのホスト設定で HostName ssh.github.com、Port 443 を指定し、元の接続先を github.com のまま扱う構成です。

Host github.com
  HostName ssh.github.com
  User git
  Port 443
  ProxyCommand ncat --proxy 127.0.0.1:7891 --proxy-type socks5 %h %p

ただし、SSH over 443が利用できるかは接続環境やサービス側の状態に左右されます。鍵の権限、SSHエージェント、接続先ホスト、Clashの接続ログを順番に確認してください。秘密鍵を設定ファイルやリポジトリへコピーしたり、秘密鍵の内容をログやチャットへ貼り付けたりしないでください。

npm installが止まる場合：レジストリ、プロキシ、証明書を分けて確認

npm install は一つの接続だけで完了するとは限りません。設定されたレジストリからパッケージのメタデータを取得し、tarball、依存パッケージ、認証エンドポイントへアクセスします。そのため、ブラウザーでnpmのトップページが開いても、実際のパッケージ取得先が同じルールを通るとは限りません。まず現在のレジストリを確認します。

npm config get registry
npm config get proxy
npm config get https-proxy
npm ping

ClashのHTTPポートを使う場合は、npmにプロキシを設定できます。実際のポート番号は環境に合わせて変更してください。

npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890
npm install --verbose

認証付き社内レジストリや独自CAを使っている環境では、TLS検証を無効にして解決しようとしないでください。strict-ssl=false は通信の安全性を下げ、原因を隠すだけになる可能性があります。社内の正しいCA証明書、レジストリの認証設定、Clashのルールを確認します。npmの設定に古いプロキシや誤った認証情報が残っている場合は、設定を整理してから再試行します。

pnpm、Yarn、pip、Composer、Dockerなどは、npmと同じ設定を自動的に共有するとは限りません。プロジェクトのREADME、CI設定、ユーザー設定ファイル、環境変数を確認し、ローカルだけでなくCIやコンテナ内部の通信経路も分けて考えましょう。DNSエラー、TLS証明書エラー、401・403、タイムアウトは原因が異なるため、表示されたエラーの種類を記録してください。

VS CodeとCopilot：エディター独自のプロキシ設定を確認する

VS Codeはシステムプロキシを利用できる場合がありますが、プロキシの自動検出、手動設定、証明書検証、拡張機能の通信方式はバージョンや環境によって異なります。Clashの接続一覧にGitHub関連の通信が表示されない場合、まずVS Codeのネットワーク設定とログを確認します。設定ファイルへプロキシURLを直接書く場合は、設定値がユーザー設定、ワークスペース設定、起動引数のどこから来ているかを把握してください。

Copilotの接続が不安定なときは、拡張機能が利用する認証、API、補完要求、ストリーミング接続を一つのドメインだけで判断しないことが大切です。Clashの接続履歴で、接続が作成されてすぐ切断されていないか、ルールがREJECTやDIRECTになっていないか、DNSエラーやTLSエラーが発生していないかを確認します。企業ネットワークでは、HTTPS検査、ファイアウォール、認証プロキシ、WebSocket制限が影響することもあります。

開発ツールをすべてTUNで処理する方法は便利ですが、まずシステムプロキシとツール固有の設定で再現性を確認することをおすすめします。TUNを使う場合は、仮想インターフェース、DNS、ルーティング、VPN、Dockerネットワークとの競合を確認し、問題が起きたときに一時的にTUNを無効化して差分を比較します。Clashのモードを何度も切り替える前に、同じノード、同じコマンド、同じ接続先で結果を記録してください。

接続障害の切り分け：ログ、コマンド、ルールを同じ順番で見る

開発環境の障害は、次の順序で確認すると設定を無闇に増やさずに済みます。最初にClashのコアが起動し、対象プロファイルが読み込まれていることを確認します。次にノードを一つへ固定し、接続テストを行います。その後、ブラウザーではなく対象の開発コマンドを実行し、Clashの接続履歴にドメインが記録されるかを見ます。

1. Clashのコア、プロファイル、ノード、待受ポートの状態を確認します。
2. Git HTTPSなら git config、Git SSHなら ssh -vT で別々に検査します。
3. npmではレジストリ、proxy、https-proxy、認証状態を確認します。
4. Clashの接続履歴で、対象ドメイン、マッチしたルール、最終ポリシー、エラーを確認します。
5. 直接接続、システムプロキシ、TUNを一つずつ比較し、変更した項目を記録します。

GitHubのHTTPSは成功するのにSSHだけ失敗するなら、SSHのProxyCommand、ポート、鍵認証を優先します。Gitは成功するのにnpmだけ止まるなら、レジストリやnpm独自設定を調べます。ブラウザーとGitHubは正常なのにCopilotだけ失敗するなら、拡張機能、認証、企業ネットワークの制限を確認します。症状が似ていても、通信経路が違えば解決策も変わります。

よくある質問：開発者向けClash設定