Clashのよくある質問

Clashは一般に、ルールベースのプロキシツールとその設定エコシステムを指します。Mihomoは継続的に開発されている互換性のあるコアで、接続やルール照合、DNSなどのネットワーク処理を担います。クライアントはサブスクリプションやプロキシグループ、各種スイッチを操作する画面を提供します。同じ名称の画面でも、コアの機能が同じとは限りません。設定を読み込む前に、クライアントが実際に使用するコアと対応項目を確認してください。設定の解析エラーが発生した場合は、ノードを何度も変更するのではなく、機能の互換性を確認しましょう。

クライアントは設定を読み込んで接続を確立するためのもので、インストールしただけでプロキシサービスが使えるようになるわけではありません。利用権限のあるサブスクリプションまたは設定ファイルを読み込み、有効なノードとプロキシグループが含まれていることを確認してください。まず設定一覧に項目があるか確認し、対象の設定を有効にしてから、プロキシ画面で利用可能なノードを選びます。ルールだけでノードがないファイルでは、プロキシ接続を確立できません。サブスクリプションの期限や利用上限、サービスの状態は提供元に確認してください。

通常はルールモードを使い、ルールに従って接続を指定のプロキシグループに振り分けます。振り分けが原因か一時的に切り分ける場合は、グローバルモードに切り替えて利用可能なノードを選び、テスト後にルールモードへ戻します。DIRECTモードでは、通常、コアに入った接続が宛先へ直接アクセスします。ここでいうグローバルはコアの処理方式を指し、すべてのアプリがプロキシ経由になるという意味ではありません。アプリの通信がコアに入るかどうかは、システムプロキシやアプリの設定、TUNにも左右されます。

必ずしもそうではありません。ノードの速度テストは通常、コアがノード経由で指定のテスト先にアクセスした際の所要時間を測るもので、通信帯域を測定するものではありません。テスト先やネットワークの混雑状況、接続先サイトの場所によって結果は変わります。ノードを選ぶ際は、まず実際のアクセスが安定しているかを確認し、利用するサイトやダウンロードで比較してください。短時間に何度も測定するのは避けましょう。同時に大量のテストを行うと接続に負荷がかかり、正常なノードでも一時的にタイムアウトすることがあります。

当サイトのダウンロードページでiOS向けのClash Plusを確認し、ページ内のApp Storeリンクからインストールしてください。製品公式サイトはclashplus.ioです。初回接続時は、システムの案内に従ってVPN構成の追加を許可し、このクライアントに対応したサブスクリプションを読み込みます。プラットフォームによって設定項目や画面が異なるため、デスクトップ版のサービスインストール、システムプロキシのポート、ドライバー操作をそのまま当てはめないでください。対応機能は、利用中のクライアントの説明を確認しましょう。

まずURLを最初から最後までコピーし直し、前後の空白や改行、チャットアプリが付け加えた句読点を取り除いてください。次に、提供元が案内するClash形式または互換形式を選んでいるか確認します。エラーがダウンロード失敗か解析失敗かも確認しましょう。前者はネットワークやURLの有効期限、ログイン状態を確認し、後者は取得した内容が設定ファイルになっているか確認します。個人認証情報を含むサブスクリプションURLを公開フォーラムに貼らないでください。相談する際は、機密情報を取り除いたエラー情報だけを共有しましょう。

現在使える設定は残し、すぐに再インストールする必要はありません。更新リクエストとノード接続では異なる経路を使う場合があるため、古いノードが使えてもサブスクリプションURLが有効とは限りません。サブスクリプションの期限やURLの変更、更新リクエストにDIRECTまたはプロキシ経由を選べる設定があるかを確認してから、手動で更新してください。ログイン画面やエラーページが返る場合は、提供元に問い合わせましょう。古い設定を削除する前にバックアップをエクスポートし、動作中の設定を失わないようにしてください。

デスクトップでは、まずシステムプロキシを有効にし、ブラウザーでアクセスできることを確認してから、必要に応じてTUNを有効にします。システムプロキシはその設定に従うアプリに適しています。TUNはより多くのネットワーク接続を取り込むため、追加のシステム権限やルーティング、DNSの設定が必要です。初回設定で複数の通信制御方式を同時に有効にすると、原因の切り分けが難しくなります。モバイル端末は通常、システムのVPN機能を使うため、デスクトップと同じスイッチを探す必要はありません。まず利用中のクライアントの接続状態を確認してください。

まずクライアントのサービスモードまたは補助サービスの設定を確認し、案内に従って必要なサービスをインストールまたは起動してください。Windowsでは管理者権限、macOSでは補助コンポーネントの許可、LinuxではTUNデバイスへのアクセスやネットワーク管理の権限が必要な場合があります。許可したらクライアントを再起動し、TUNだけを有効にしてテストします。警告を消すためにシステムのセキュリティ機能を無効にしないでください。それでも失敗する場合は、サービスの起動エラーを記録し、クライアントが対応するOSバージョンを確認しましょう。

サブスクリプションを更新すると、リモート設定が再ダウンロードされて置き換わることが多く、ダウンロードしたファイルを直接編集すると変更が上書きされる可能性があります。長期間維持したいルールは、クライアントが対応するローカルオーバーライドや拡張スクリプト、マージ設定に追加し、更新後も適用されることを確認してください。オーバーライド機能の名称やマージ順序はクライアントによって異なるため、追加前にバックアップを取ります。変更後は最終的に適用された設定を確認し、ルールの位置やプロキシグループ名が正しいか確かめてください。エディターで保存できたという表示だけでは不十分です。

システムプロキシが適用されるのは、その設定を参照するアプリだけです。独自のプロキシ設定を使うアプリや、システムのHTTPプロキシを経由しない接続もあります。まずクライアントの接続一覧を開き、対象アプリからリクエストを送信してください。記録がなければ、アプリ内のプロキシ設定を確認するか、TUNの利用を検討します。記録がありDIRECTになっている場合は、モードや適用されたルール、プロキシグループを確認しましょう。スイッチがオンというだけで通信が取り込まれているとは限りません。また、DIRECTの接続をすべてノードの障害と判断しないでください。

クライアントの接続一覧またはログを開いてから対象サイトにアクセスし、ドメイン名やプロセス名で新しい接続を探します。適用されたルール、使用中のプロキシグループ、最終的なノードを確認してください。ウェブページは複数のドメインに同時にリクエストすることが多いため、重要なリクエストを個別に確認します。ルールは通常上から順に照合されるため、広範囲に一致する項目を先に置くと、接続が意図せず先に処理されることがあります。変更後はリクエストを再送し、必要なら既存の接続を閉じてください。接続が再利用されると、変更が反映されていないように見えることがあります。

スマートフォンとパソコンが相互に通信できるLANに接続されていることを確認し、パソコンのクライアントでLAN接続を許可して、待ち受けアドレスとmixed-portを確認します。スマートフォンのWi-Fiプロキシには、127.0.0.1ではなく、パソコンのLAN内IPアドレスと対応ポートを入力してください。必要に応じてパソコンのファイアウォールで通信を許可し、ルーターの端末間通信制限も確認します。共有する前に適切なアクセス制御を設定し、プロキシポートをインターネットに公開しないでください。使い終わったら、不要になった共有設定を無効にしましょう。

まずはサブスクリプションに含まれる、動作中のDNS設定を維持し、名前解決の問題や特定アプリとの互換性の問題が明確な場合にだけ変更してください。Fake-IPはドメイン名を仮想アドレスに対応付けてコアが接続を識別できるようにするもので、ウェブサイトの実際のアドレスが変わるわけではありません。名前解決モードや上流DNSサーバー、フィルターリストを変更する際は、一度に一項目だけ変更して接続を確立し直し、動作を確認します。特定の機器の検出、ゲーム、ローカルドメインに問題がある場合は、対象を絞ったフィルタリングを検討し、すべてのドメインを対象にした例外を安易に追加しないでください。

まずシステムのバッテリー使用状況を確認し、消費の原因がクライアントなのか、実際の通信量なのかを切り分けてください。Androidで画面ロック後に切断される場合は、バックグラウンド実行の権限やバッテリー最適化、常時通知を確認します。設定場所はメーカーによって異なります。バッテリー消費が大きい場合は、不要なノードのヘルスチェックや頻繁なサブスクリプション更新を減らし、ログで再接続が繰り返されていないか確認してください。iOSはシステムのVPN状態やネットワーク切り替えを確認し、Android向けの常駐設定をそのまま適用しないでください。変更後はしばらく安定して使い、結果を比較しましょう。

まずプロキシを無効にし、通常は直接アクセスできるサイトに接続できるか確認してから、端末の時刻とサブスクリプションの有効状態を確認します。次にノードを一つ選んで実際に対象サイトへアクセスし、速度テストを繰り返すのではなく接続エラーを確認してください。実際のアクセスが正常なら、テスト先との相性が悪いだけかもしれません。すべての接続に失敗する場合は、可能であれば別のネットワークでも試します。1つのノードだけが失敗する場合と、すべてのノードが失敗する場合では、確認すべき点が異なります。最初から設定をすべて消したり、DNSやポート、ルールを同時に変更したりしないでください。

まずTUNを無効にして、ネットワークが復旧するか確認します。まだ問題がある場合はシステムプロキシも無効にしてクライアントを通常終了し、システムに手動プロキシの設定が残っていないか確認してください。復旧後はTUNのログでルーティングやDNS、仮想ネットワークアダプターのエラーを確認し、ほかのVPNや通信制御ツールを停止して単独でテストします。見覚えのないシステムのネットワークアダプターを削除したり、ルーティングを一括リセットしたりしないでください。再度有効にするときは一項目ずつ確認し、どのスイッチで問題が起きるか記録して、該当する設定を調べましょう。

ブラウザーは正常なのに、サンドボックス化されたネットワーク環境のストアアプリがローカルプロキシに接続できない場合は、UWPのループバック制限を確認できます。ただし、すべてのストアアプリに同じ制限があるわけではありません。まずクライアントに付属するループバック除外ツールを使い、必要なアプリだけを許可してください。CheckNetIsolation LoopbackExempt -sで現在の除外設定を確認する方法もあります。除外設定の変更には管理者権限が必要な場合があります。変更後に対象アプリを再起動し、接続記録から通信がコアに入っているか確認しましょう。

まずクライアントを複数起動していないか、別のプロキシプロセスが動いていないか確認し、重複しているプログラムを終了してください。待ち受けポートを変更する必要がある場合は、未使用のポートを選び、システムプロキシやブラウザー拡張、そのポートを手動で指定しているほかのアプリも更新します。mixed-portはHTTPとSOCKS5の両方の接続を受け付けますが、利用する側で正しいプロトコルを選ぶ必要があります。変更後はコアを再起動し、正常に待ち受けていることを確認してください。設定だけ変更してアプリ側を更新しなければ、接続は失敗します。

問題が発生した時刻、クライアントとOSの情報、現在のモード、対象ドメイン、失敗したリクエストの前後にあるエラーログを記録してください。まずルールモードと、ノードを選択したグローバルモードを比較し、ブラウザーのプロキシ拡張機能や暗号化DNS、キャッシュが結果に影響していないか確認します。共有する前にサブスクリプションURLやノードの認証情報、コントロールAPIのキー、個人のアドレス情報を削除してください。設定ファイル全体をアップロードするより、問題に関係する短いログだけを共有するほうが原因を見つけやすく、機密情報の漏えいも防げます。