Clashのサブスクリプション更新に失敗したときの対処法｜よくある原因と自動更新間隔の設定

ターミナル通信では、プロキシ設定とTUNの役割を分けて考える

ブラウザーではWebサイトを開けるのに、ターミナルからのgit cloneやnpm installだけがタイムアウトすることがあります。原因のひとつは、ブラウザーがOSのシステムプロキシ設定を利用している一方、GitやNode.jsの通信は独自の設定で動作していることです。クライアントに「接続中」と表示されていても、すべてのコマンドラインアプリが同じプロキシを使うとは限りません。

Clashのシステムプロキシは、主にOSのプロキシ設定を参照するアプリに通信経路を知らせます。これに対し、TUNモードは仮想ネットワークインターフェースを使い、IPパケットを mihomo などのコアへ転送します。そのため、アプリごとにプロキシ設定を追加しなくても、対応する通信をルールに従って処理できる場合があります。ただし、TUNを有効にしただけで、すべての通信が必ずプロキシ経由になるわけではありません。ルールがDIRECTを選ぶ場合や、OS・アプリ側に独自のネットワーク処理がある場合は、想定した経路と異なることがあります。

まずは「コマンドがローカルのプロキシポートに接続できるか」と「TUNで通信が捕捉され、意図したルールに一致するか」を別々に確認しましょう。どちらを使う場合も、設定変更前に現在のプロファイルをバックアップし、クライアントとコアのバージョン、選択中の設定、TUNの状態を記録しておくと、問題が起きたときに元へ戻しやすくなります。

最初は明示的なプロキシ指定で確認し、必要に応じてTUNを使う

問題の範囲を絞るには、TUNをいったん無効にし、コマンドからローカルのプロキシを明示してテストする方法が分かりやすいです。明示的なプロキシ指定で成功するなら、ノードとプロキシポートは利用でき、Gitやnpmの個別設定、またはTUNのルーティングを次に確認できます。ポートへの接続自体が拒否される場合は、アプリの設定を変える前に、クライアントが起動しているか、ポート番号が一致しているか、別のプロセスがポートを使っていないかを調べてください。

次の例は、テスト用ドメインへのHTTPSリクエストをローカルのHTTPプロキシ経由で送ります。WindowsのPowerShellではcurlが別コマンドのエイリアスになっている環境があるため、curl.exeを指定します。macOSとLinuxでは通常curlを使います。

curl.exe -v --connect-timeout 5 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/ -o NUL

curl -v --connect-timeout 5 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/ -o /dev/null

HTTPレスポンスを受け取れるのにGitだけ失敗する場合は、Gitのプロキシ設定や認証、Gitの通信方式を確認します。コマンドが127.0.0.1:7890に接続できない場合は、クライアントのポート設定と起動状態を先に確認してください。403などの応答が返る場合は、ネットワークのタイムアウトとは異なり、接続先または中継側から応答が届いたうえで拒否されている可能性があります。

TUNはアプリごとの環境変数を設定しなくても通信を扱えることがありますが、経路全体の切り分けはプロキシ指定より複雑になります。まずコマンド単体のテストでポートとノードを確認し、それからTUNを有効にすると、どの段階で問題が起きたか判断しやすくなります。

Gitとnpmに一時的なプロキシ設定を追加する

Git：設定範囲を選び、不要なら元に戻す

Gitは環境変数を参照する場合もありますが、Git自身の設定にHTTPプロキシを指定することもできます。まず一度だけ試すなら、次のようにコマンド単位で設定します。リポジトリのURLは自分の接続先に置き換えてください。

git -c http.proxy=http://127.0.0.1:7890 clone https://example.com/owner/project.git

複数のリポジトリで利用する場合は、ユーザー全体の設定として追加できます。これは現在のリポジトリだけでなく、そのユーザーで実行する他のGit通信にも影響するため、利用する範囲を考えて選んでください。

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

テスト後に設定を解除する場合は、次のコマンドを実行します。リポジトリ単位で--localを指定した設定を追加した場合は、同じリポジトリ内でgit config --local --unset http.proxyを使います。

git config --global --unset http.proxy

プロキシのユーザー名やパスワードをURLに直接書き込む方法は避けてください。Gitの設定ファイル、シェル履歴、ログに認証情報が残る可能性があります。認証が必要な環境では、組織やサービスが案内する安全な認証方法を確認してください。また、https://のリポジトリを取得する際のHTTPプロキシ設定と、SSH形式のgit@...接続は別の経路です。HTTPプロキシの設定を追加しても、SSH接続の問題が自動で解決するとは限りません。

npm：環境変数とnpm設定の重複に注意

npmは環境変数やnpm設定にあるプロキシ情報を使ってレジストリへ接続できます。まずは現在のターミナルだけで環境変数を設定し、インストールを試すと影響範囲を限定できます。Windows PowerShellでは次のように設定します。

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
npm view npm version

macOSやLinuxのシェルでは、同じターミナルセッション内で次のように設定できます。テストが終わったら環境変数を解除するか、ターミナルを閉じてください。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
npm view npm version

npmの設定として保存する場合は、現在の値を確認してから設定します。設定ファイルに残したままTUNへ切り替えると、npmのプロキシ指定とTUNの経路制御が重なり、原因を見分けにくくなることがあります。不要になったら、設定した項目を解除してください。

npm config get proxy
npm config get https-proxy
npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

npm config delete proxy
npm config delete https-proxy

npmが指定しているレジストリも確認しましょう。組織内のミラーや独自レジストリを使用している場合、公開レジストリへ接続できるかだけを試しても、実際のインストール失敗を再現できないことがあります。npm config get registryで現在の値を調べ、使用中のレジストリに対してテストしてください。プロキシの認証情報をnpm設定に保存する場合も、設定ファイルの共有やログ出力に注意が必要です。

TUNを有効にし、開発ツールの通信経路を確認する

TUNを使う前に、クライアントが使用しているコアがTUNに対応していることを確認します。Clash VergeやClash Verge Revなどの画面では、設定項目の名称や配置がバージョンによって異なりますが、一般に「設定」または「ネットワーク」からTUNを有効にします。Windowsでは仮想ネットワークデバイスの作成に管理者権限が必要な場合があります。macOSやLinuxでも、OSの権限や他のVPN・ネットワークフィルターとの競合で起動に失敗することがあります。表示されたエラーを記録し、権限を無条件に変更するのではなく、クライアントの案内に沿って操作してください。

1. プロファイルを保存：現在利用中の設定を複製またはバックアップし、変更前の状態を戻せるようにします。
2. TUNを有効化：クライアントの設定画面でTUNを有効にし、必要な権限や仮想アダプターの作成を許可します。再起動が求められた場合は、画面の案内に従います。
3. 状態とログを確認：クライアントにTUNが稼働中と表示されるか、ログにインターフェース作成やルート設定のエラーが出ていないかを確認します。
4. 同じ通信で再テスト：先ほど失敗したGitまたはnpmのコマンドを同じネットワーク、同じ接続先で実行し、接続ログに対象ドメインが現れるか確認します。
5. 設定を一つずつ戻す：環境変数やGit・npmのプロキシ設定を追加していた場合は、一時的に解除してからTUN単独でテストします。複数の方式を同時に使うと、実際にどの経路を通ったか判断しにくくなります。

接続ログでは、通信先のホスト名またはIPアドレス、適用されたルール、選択されたプロキシグループ、最終的な接続結果を確認します。対象のリクエストがログに出ない場合は、コマンドがTUNを通っていない、別のプロセスで通信している、またはテストしたコマンドが通信を開始していない可能性があります。ログに出ていてDIRECTが選ばれる場合は、ルールの順序やドメインの分類を確認してください。プロキシグループが選ばれて接続に失敗する場合は、そのグループの選択先とノードの状態を調べます。

TUNの設定項目にある自動ルートやDNSの処理方式は、OSやコアのバージョンによって挙動が異なります。原因が分からないまま複数の項目を切り替えるのではなく、まず既定値で接続を確認し、ログにルート追加やDNSのエラーが出た場合に該当項目を調査します。既に別のVPN、仮想マシン、コンテナ用ネットワークを利用している端末では、経路の競合が起きることもあります。競合が疑われる場合は、他のVPNを一時停止した状態と比較してください。

Git・npmのエラーを段階別に切り分ける

エラー表示だけで設定を変更する前に、発生したコマンド、時刻、ネットワーク、クライアントとコアの状態を記録します。同じコマンドをプロキシ指定あり・なし、TUN有効・無効で比較すると、通信経路のどこに差があるかを把握できます。認証トークンやプライベートなリポジトリURLを含むログを共有するときは、先に情報を伏せてください。

certificateエラーを避けるために、証明書検証を無効化する設定を常用しないでください。TLSの相手先確認が弱まり、ネットワーク上でのなりすましを検知しにくくなります。まず端末の時刻、組織のネットワークで必要な証明書、接続先の証明書状態を確認しましょう。プロキシノードの証明書設定と、GitHubやnpmレジストリなど接続先サーバーの証明書検証は別の問題として扱います。

また、サブスクリプションやルールをすぐに変更するのも避けましょう。コマンドの通信がログに記録され、意図したグループが選ばれているなら、次はノードや接続先の応答を確認します。反対にログがないなら、まずTUNの状態、シェルの環境変数、Gitやnpmに残っているプロキシ設定を見直します。変更は一度に一つにし、同じコマンドで結果を比較すると、原因を再現しやすくなります。

よくある質問