Clashのよくある質問

クライアントはインストール、設定管理、システムプロキシ、画面操作を担当します。コアは設定の解析、ルールの照合、接続の確立を担い、mihomoはClashエコシステムで広く使われるコアです。サブスクリプションは設定やプロキシ情報の提供元であり、有効なURLを別途入手する必要があります。クライアントをインストールしただけでは、利用可能なプロキシサービスが使えるわけではありません。初めて使うときは、サブスクリプションの提供元が現在のコアに対応していることを確認し、設定画面からインポートして有効化します。その後、プロキシグループに選択可能な出站先が表示されているか確認してください。画面が起動しただけで設定が有効になったと判断しないでください。

普段はルールモードを選び、rulesの記述順に接続先の出站先を決めるのが一般的です。グローバルモードでは、コアに入った接続をグローバルプロキシグループに渡します。振り分けルールが原因かを短時間で確認するのに便利ですが、すべてのアプリの通信を自動で取り込むわけではありません。ダイレクトモードでは、コアに入った接続が接続先へ直接アクセスします。モード切り替えとシステムプロキシ、TUNは別の設定です。前者は出站先の決め方、後者は通信をコアに取り込む方法を指定します。トラブルシューティング後はルールモードに戻し、接続画面で実際に適用されたルールと出站先までの経路を確認してください。

mixed-portは、同じ待ち受けポートでHTTPとSOCKSのプロキシリクエストを受け付ける設定です。7890はよく使われる値ですが、すべてのクライアントで固定されているわけではありません。クライアントを1つだけ使い、ポートの競合がなければ、通常は変更不要です。ブラウザーやターミナルにプロキシを手動設定する場合は、クライアントに表示されている現在の混合ポートを確認してください。アドレスには通常127.0.0.1を使います。外部コントロールポートはコアの管理用で、アプリのプロキシ設定には指定しません。ポートを変更したら、アプリの設定やターミナルの環境変数も更新し、古いポートへの接続が残らないようにしてください。

新規インストールなら、まずClash Plusを候補にし、画面や操作性の好みに応じてClash Verge Rev、FlClash、Clash Nyanpasuも比較してみてください。選ぶ際は、対応OSとプロセッサのアーキテクチャを確認し、必要なTUN、サービスモード、設定項目がサポートされているかもチェックします。移行前に元のサブスクリプションURL、手動ルール、オーバーライドファイルを保存してください。旧アプリのフォルダーをそのままコピーするのではなく、新しいクライアントでサブスクリプションを再インポートするのがおすすめです。2つのクライアントでシステムプロキシやTUNを同時に有効にしないでください。新しいクライアントで接続できることを確認してから、旧クライアントの自動起動とバックグラウンドサービスを停止します。

iPhoneではApp StoreからClash Plusを入手できます。製品の公式サイトはclashplus.ioです。インストール後、設定またはサブスクリプションの画面で有効なURLを追加するか、クライアントが対応するファイルインポート機能で設定を読み込み、使用する設定を選んで有効化してください。初回接続時は、システムの案内に従ってVPN構成の追加を許可し、端末で求められる認証を完了します。ステータスバーにVPNアイコンが表示されても、トンネルが確立したことを示すだけです。対象のWebサイトを開き、ルールと出站先が機能しているか確認してください。組織管理下の端末でVPNの追加が禁止されている場合は、端末の管理ポリシーを先に確認し、クライアントを何度も再インストールしないでください。

クライアントの「設定」「サブスクリプション」または「Profiles」画面を開き、新しいリモート設定を作成します。サブスクリプションURL全体をURL欄に貼り付けて保存してください。プロキシアドレスや外部コントロールアドレスの欄には貼り付けないでください。ダウンロード後は、その設定を現在の設定として選択し、プロキシ画面で該当するプロキシグループの出站先を選びます。最後にシステムプロキシを有効にするか、必要に応じてTUNを有効にし、対象のWebサイトにアクセスしてください。メニュー名はクライアントによって多少異なりますが、インポート、有効化、出站先の選択、通信の取り込みはそれぞれ別の手順です。どれかを飛ばすと接続できないことがあります。

まずログで最初に出ている解析エラーを確認し、項目名と行番号を特定します。次にYAMLのインデント、コロンの後の空白、リスト項目のハイフンを確認してください。インデントにはスペースを使い、タブを混在させないでください。未対応のプロキシタイプや項目が表示された場合は、インデントだけを直すのではなく、現在のコアがサブスクリプションの形式に対応しているか確認します。URLからインポートした場合は、取得した内容が本当に設定ファイルかも確認してください。ログイン画面、期限切れの通知、通常のWebページはYAMLとして使えません。編集前に元ファイルを保存し、修正後に再読み込みして、同じエラーがログに出ないことを確認してください。

まず通常のシステムプロキシで接続できることを確認してから、TUNの問題を個別に調べます。Windowsではクライアントの設定にあるサービスモードまたはサービスのインストール項目を探し、案内に従って許可を与え、サービスをインストールして起動してください。macOSではクライアントの案内に従い、ヘルパーサービスやネットワーク拡張機能に必要な権限を与えます。Linuxでは通常、管理者権限が必要です。クライアントのドキュメントに従って必要なネットワーク機能を設定してください。セキュリティ機能を無効にすることを、最初の対処法にしないでください。権限を設定したらクライアントを再起動し、ログで仮想インターフェースが正常に作成されたか確認します。まだ失敗する場合は、他のVPNや仮想ネットワークアダプターを停止してから、具体的なドライバーやルーティングのエラーを調べてください。

Androidクライアントは通常、システムのVPNインターフェースを使ってアプリの通信をローカルのプロキシコアに渡すため、初回接続時にVPNの確立を求めます。インストールして現在操作しているクライアントからの要求だと確認してから許可してください。一般的な個人利用では、同じユーザー領域で通常のVPNサービスを2つ同時に実行できません。他のVPN、VPNベースのフィルタリングアプリ、ファイアウォールが動作している場合は、競合するサービスを先に停止してください。接続後、一部のアプリだけがプロキシを経由しない場合は、アプリごとのプロキシ設定にある対象アプリの許可・除外リストや、仕事用プロファイルに独自のネットワークポリシーが適用されていないか確認します。

通常は、待ち受けアドレスまたはポートがすでに使用されています。他のプロキシクライアントを完全に終了し、現在のクライアントが二重に起動していないか確認してください。メインウィンドウを閉じただけでは、バックグラウンドのコアが停止しないことがあります。Windowsではリソースモニターのネットワーク画面で待ち受けポートを確認できます。macOSとLinuxでは、システムのネットワークツールで使用中のプロセスを特定してください。用途を確認してからプロセスを停止するか、設定で空いている混合ポートに変更します。見覚えのないシステムプロセスをむやみに終了しないでください。変更後に設定を再読み込みし、システムプロキシと手動でプロキシを設定したアプリの両方が新しいポートを使っていることを確認します。

必ずしもそうではありません。遅延テストは通常、指定した出站先からテスト用URLへアクセスするため、結果はテスト先、DNS、ハンドシェイク、接続先の応答に左右されます。回線そのものの物理的な遅延と同じではありません。まずその出站先を手動で選んで実際の接続先にアクセスし、接続ログを確認してください。Webサイトにアクセスできるのにテストだけタイムアウトする場合は、テスト先へのアクセスがブロックされていないか確認するか、テストのタイムアウト時間を調整します。実際のアクセスも失敗する場合は、サブスクリプションの状態とローカルネットワークを確認してください。一度のタイムアウトだけで設定をまとめて削除したり、異なるテスト先の結果をそのまま比較したりしないでください。

遅延テストでは、接続の確立とテストリクエストにかかる時間を主に確認します。ダウンロード速度テストでは継続的なデータ転送能力を測るため、実際に通信量が発生します。遅延が小さくても大きなファイルのダウンロードが速いとは限りません。また、スループットが高くても、操作に伴うリクエストの応答が短いとは限りません。比較する場合は、できるだけ同じネットワーク、テスト先、時間帯で測定し、バックグラウンドのダウンロードを止め、複数のクライアントで同時にテストしないようにしてください。モバイルデータ通信や従量制のサブスクリプションでは、特に測定回数に注意が必要です。普段使う出站先は、単発の速度テストだけで選ばず、接続先サービスの安定性を確認したうえで、遅延と実際の使い心地を参考にしてください。

ルールモードのままクライアントの接続画面を開き、対象サイトに新しいリクエストを送信します。ドメイン名またはプロセスで接続を絞り込み、ルールの種類、内容、出站先までの経路を確認してください。必要に応じてログも確認します。ルールは通常、上から順に照合され、最初に一致した項目で以降の出站先が決まります。そのため、新しいルールはフォールバックのMATCHより前に追加してください。変更後は設定を再読み込みし、既存の接続を閉じてから再テストします。確立済みの接続では、以前の出站先が引き続き使われることがあります。ページが複数のドメインを使う場合は、アドレスバーのメインドメインだけでなく、静的リソース、ログイン、APIのリクエストも個別に確認してください。

クライアントにオーバーライド、設定のマージ、拡張ルールなどの機能があれば、ローカルの変更とリモートのサブスクリプションを分けて管理してください。ダウンロードしたサブスクリプションファイルを直接編集すると、次回の更新でリモートの内容に置き換えられることがあります。ルールを追加する前に、参照するプロキシグループ名が現在の設定に存在することと、ルールを挿入する位置を確認してください。サブスクリプション更新後は、最終的に適用された設定を確認し、接続画面でルールの適用結果を検証します。クライアントによって設定のマージ順や構文は異なります。移行時は改めて確認し、同じオーバーライドファイルをすべてのクライアントでそのまま使えるとは考えないでください。

この端末だけで使う場合は、無効のままで問題ありません。同じLAN内の別端末とプロキシを共有する必要がある場合は、「LANからの接続を許可」を有効にし、待ち受けアドレスに該当するネットワークアダプターが含まれていることを確認します。ファイアウォールでは、信頼できるネットワークに必要なポートだけを許可してください。他の端末には、クライアントを実行しているPCのLAN内アドレスと実際の混合ポートを入力します。別のPCを指すアドレスとして127.0.0.1は使えません。プロキシ認証を設定し、公共のネットワークでは待ち受けを公開しないことをおすすめします。外部コントロールインターフェースはプロキシポートとは用途が異なります。共有のために管理インターフェースを公開しないでください。共有を終えたら、関連する設定とファイアウォールルールを無効にします。

まずサブスクリプションURLが完全にコピーされているか確認します。末尾のパラメーター、改行、余分なスペースに注意してください。401や403は通常アクセス拒否を示しますが、具体的な理由はサブスクリプションサービスの案内を確認してください。URLの再発行、アカウントの状態、アクセス制限などが原因の可能性があります。端末の日付と時刻を確認し、サービスのページに新しいサブスクリプションURLが掲載されていないか確認します。更新時にネットワークエラーが出る場合は、クライアントが更新にダイレクト接続とプロキシ接続のどちらを使っているか確認し、接続可能な方法で再試行してください。サブスクリプションURLにはアクセス情報が含まれることがあるため、公開の掲示板に全文を貼り付けないでください。URLが漏えいした場合は、サービス側で再発行してから再インポートします。

まずクライアントの接続画面で、リクエストがコアに届いているか確認します。ブラウザーのリクエストが記録されない場合は、プロキシ拡張機能、ブラウザー独自のプロキシ設定、システムの除外リスト、他のクライアントによるシステムプロキシの上書きを確認してください。ターミナルのツールはシステムプロキシを自動で読み込まないことがあります。各ツールのドキュメントに従ってhttp_proxyやhttps_proxyを設定するか、リクエストごとにプロキシを指定し、クライアントと同じポートを使ってください。リクエストがコアに届いている場合は、システムプロキシを切り替え直すのではなく、適用されたルールと出站先を確認します。システムプロキシに従わないアプリの通信を取り込む必要がある場合は、TUNの利用を検討してください。環境変数が反映されるのは、それを読み込むプロセスだけです。更新後の値は、新しく開いたターミナルで引き継がれます。

AppContainerの分離環境で動作する一部のWindowsアプリでは、ローカルのループバックアドレスへのアクセスが制限されます。ブラウザーは使えるのに、特定のアプリだけ接続できない場合があります。まず問題のアプリがこの環境で動作しているか確認し、プロキシとルールが有効になっていることを確認してください。クライアントにUWPのループバック許可機能がある場合は、管理者の許可を得たうえで、ローカルプロキシを使う必要があるアプリだけを選択し、アプリを再起動します。すべてのストアアプリに同じ制限があるわけではなく、すべてのアプリに許可を与える必要もありません。許可後も接続できない場合は、アプリ自体のプロキシ対応、DNS、ファイアウォールの設定を引き続き確認してください。すべての接続エラーをループバック制限のせいにしないでください。

まずシステムプロキシとTUNを無効にし、ローカルネットワークから通常は直接アクセスできるWebサイトに接続できるか確認します。クライアントを再び有効にしたら、設定が有効化されているか、サブスクリプションが有効か、プロキシグループで利用可能な出站先が選ばれているかを確認し、最初に出た接続エラーを確認してください。すべての出站先で同時に失敗する場合は、端末の時刻、DNS、ローカルファイアウォール、他のVPNとの競合、ネットワーク制限など、共通する要因から調べます。一部の出站先だけが失敗する場合は、接続先の状態を確認します。テスト中は一度に1つだけ設定を変更し、結果を記録してください。ルールモードからグローバルモードへ一時的に切り替えると、振り分けの問題かどうかを切り分けられますが、接続先のサービス自体の停止は解決できません。

クライアントを再度開き、システムプロキシとTUNを明示的に無効にしてから、通常の手順で終了してください。プロセスを強制終了すると、システムプロキシや不正なルート設定が残ることがあります。その後、システムのネットワーク設定がローカルのプロキシアドレスを指したままになっていないか確認します。TUNを有効にしたときだけ問題が起きる場合は、DNS設定、名前解決のログ、他のVPNとのルート競合を調べてください。複数のDNS項目を同時に変更しないでください。fake-ipを使っている場合、一部のアプリに古い名前解決結果が残ることがあります。設定を元に戻した後、アプリを再起動し、OSの方法でキャッシュを更新してください。それでも改善しない場合はネットワーク接続を再起動し、ログを確認して残ったインターフェースを特定します。用途が分からないシステムルートを直接削除しないでください。