Clashのよくある質問

Clashは一般に、プロキシのコアとその設定エコシステムを指します。mihomoはClash設定との互換性を保ちながら機能を拡張しているコアプロジェクトです。GUIクライアントは設定のインポート、プロキシグループの選択、システムプロキシやコアプロセスの管理を担います。画面が似ていても、対応するコア機能が同じとは限りません。プロトコルや設定項目の互換性を調べる際は、まずクライアントの「バージョン情報」画面や起動ログでコア名を確認し、対応するドキュメントを参照してください。このページの応用設定はmihomoを基準としており、旧バージョンのコアではすべての項目を利用できない場合があります。

クライアントはプロキシ接続や通信の振り分けを行いますが、インストーラー自体が利用可能なプロキシサービスを提供するわけではありません。サブスクリプションやローカルのYAML設定には、通常プロキシサーバー、プロキシグループ、ルールが含まれています。実際に接続できるかどうかは、サービスの有効性と現在のネットワークからの到達性にも左右されます。インポート後は、その設定が現在の設定として選択されていることを確認し、プロキシグループに選択可能なプロキシがあるかチェックしてください。サブスクリプションURLには他人が設定を取得できるアクセス情報が含まれる場合があるため、公開の掲示板などに投稿しないでください。

普段の通信振り分けにはRuleモードがおすすめです。接続はrulesを上から順に照合し、最初に一致したルールで行き先が決まります。Globalモードでは、コアに届いた接続をGLOBALプロキシグループに渡しますが、実際に使うプロキシはそのグループ内で選ぶ必要があります。Directモードでは、コアに届いた接続を直接接続します。モードを切り替えても、すべてのアプリの通信が自動的にコアへ入るわけではありません。通信がコアに届くかどうかは、システムプロキシやTUNの設定で決まります。そのため、Globalにしてもアクセスできない場合は、モードを何度も切り替えるのではなく、通信の取り込みとプロキシ接続を確認してください。

システムプロキシは、OSのプロキシ設定をクライアントの待ち受けポートに向けます。通常はその設定に従うブラウザーやアプリで利用できますが、直接接続するプログラムや独自のプロキシ設定を使うプログラムは経由しないことがあります。TUNは仮想ネットワークインターフェースを作成し、ルーティングを通じてより広範なIP通信を取り込みます。DNS、ルート、権限の設定も必要です。初めて使う場合は、まずシステムプロキシで設定を確認し、ほかのアプリの通信も取り込む必要がある場合にTUNを有効にしてください。原因を調べる際は、一度に複数の通信経路を変更せず、ひとつずつ有効にして確認しましょう。

必ずしもそうではありません。遅延テストで確認できるのは通常、指定されたテスト先へのリクエストがプロキシ経由で完了するまでの時間です。すべてのWebサイトやUDP、目的のサービスが利用できることを保証するものではありません。テスト先、タイムアウト設定、コネクションの再利用、現在のネットワーク環境によって結果は変わります。まず、テスト時のプロキシグループが実際のアクセス時と同じか確認してください。目的のWebサイトにアクセスし、接続パネルで一致したルールと出力先のプロキシを確認するのも有効です。特定のサービスだけに接続できない場合は、出口の地域制限、サーバー側の拒否、ドメインの誤った振り分けも確認してください。

クライアントの設定管理またはサブスクリプション管理画面でリモート設定を追加し、URL全体を貼り付けてダウンロードまたはインポートします。メニュー名はクライアントによって異なる場合があります。ダウンロード後は、その設定を現在の設定に指定し、コアの再読み込みが成功したことを確認してください。続いて、プロキシグループ内のプロキシ名、ルールの内容、更新ログを確認します。画面に古い内容が表示される場合は、更新した設定が現在使用中のものか、ローカルの上書き設定に置き換えられていないか確認してください。サブスクリプション一覧の更新日時だけで、すべての設定が反映されたと判断しないでください。

まずURLが完全か、サービス提供元によってリセットされていないか確認し、次にアカウントの有効期限と通信量の状態を確認してください。ログにHTTP 401または403がある場合は、認証やアクセス制限を優先して確認します。404はURLのパスが変更された可能性があり、タイムアウトの場合は現在のネットワークからサブスクリプションURLにアクセスできるか調べてください。プロキシ経由でのみアクセスできるURLなら、クライアントが対応している場合、設定更新時のプロキシ接続方法を変更できます。見知らぬサブスクリプション変換サイトに何度もURLを送信しないでください。URLが漏えいした場合は、サービス提供元の管理画面でサブスクリプション識別情報をリセットしてください。

ダウンロードしたものがYAML設定であり、ログインページやエラーページ、プロキシURLの一覧だけではないことを確認してください。ログに行番号が表示されている場合は、その行と直前の行のインデント、コロン、引用符を確認します。YAMLのインデントにはスペースを使い、タブは使わないでください。解析を通過しても、存在しないプロキシグループをルールが参照している、旧バージョンのコアがプロキシタイプに対応していないなど、設定内容のエラーが残ることがあります。修正前に元のファイルを保存し、一度に変更するのは一箇所にとどめてください。クライアントの設定チェック機能やコアのテスト機能で再検証しましょう。

まずログを確認し、権限不足、サービスの未起動、仮想インターフェースの作成失敗を切り分けてください。クライアントにサービスモードのインストールや起動機能がある場合は、そちらを優先し、システムの指示に従って権限を許可します。サービスモードがない場合は、プログラムの提供元を確認したうえで、管理者権限で起動して動作を確認できます。サービスのインストール後、クライアントの再起動が必要な場合があります。その後、TUNを有効にしてください。それでも失敗する場合は、セキュリティソフトのブロック履歴や、ほかのVPNが作成した仮想インターフェースを確認します。原因調査の代わりにファイアウォール全体を無効にしたり、ドライバーのインストールを何度も繰り返したりしないでください。

mixed-portはHTTPとSOCKSの両方のプロキシ接続を受け付ける待ち受けポートです。7890はよく使われる設定例であり、固定値ではありません。address already in useが表示された場合は、ほかのプロキシを終了するか、システムツールでポートの使用状況を確認してください。その後、クライアントのポート設定またはローカル設定で未使用のポートを選びます。再読み込み後に待ち受けが成功したことを確認し、ブラウザー、ターミナルなどのアプリで手動設定しているプロキシアドレスも更新してください。リモートサブスクリプションによって変更が上書きされることがあります。設定を維持するには、クライアントの永続化できる上書き機能を使いましょう。

Ruleモードで、対象ドメインのDIRECTルールを汎用プロキシルールとMATCHより前に配置します。たとえばDOMAIN-SUFFIX,example.com,DIRECTはexample.comとそのサブドメインに一致し、DOMAIN,example.com,DIRECTはそのドメインだけに一致します。設定を再読み込みしたら、既存の接続を閉じてから再アクセスし、接続パネルで一致したルールを確認してください。ルールは最初に一致したものが適用されるため、通常はMATCHの後ろに追加しても機能しません。リモートサブスクリプションを利用している場合は、ローカルの上書き設定でカスタムルールを保持してください。

selectはメンバーを手動で選択する方式で、特定の回線を固定して使う場合に適しています。url-testはテスト結果をもとに適切なメンバーを自動選択しますが、判定はテスト先や許容値などの設定に左右されます。fallbackはメンバーの順序に従って利用可能なものを選ぶため、主回線の障害時に予備回線へ切り替える用途に適しています。自動選択グループが各Webサイトのアクセス制限を判断できるわけではなく、テストに成功しても目的のサービスが利用できるとは限りません。出口を固定するのか、テスト結果で選ぶのか、順番に従って切り替えるのかを決めてから、テスト間隔を設定しましょう。頻繁な切り替えが安定性を保証するわけではありません。

Fake-IPでは、コアがアプリに仮想アドレスを返し、保存されたドメインとの対応関係をもとに接続を処理します。これはリモートプロキシサーバーの実際のアドレスではありません。mihomoでは通常、dns.enableとdns.enhanced-modeで設定します。TUNを使う場合は、DNSリクエストが実際にコアへ取り込まれていることも確認してください。LAN内のデバイス検出、一部のゲーム、実際の名前解決結果に依存するアプリでは、fake-ip-filterの調整が必要になる場合があります。互換性の問題が確認されたドメインだけを例外に追加し、その後アプリやシステムのDNSキャッシュを消去してください。問題を隠すために、すべてのドメインを除外するのは避けましょう。

まずスマートフォンとパソコンを相互に通信できるLANに接続します。パソコンの設定でallow-lanを有効にし、bind-addressがLANインターフェースでの待ち受けを許可していることを確認してください。スマートフォンのWi-Fi設定で手動HTTPプロキシを選び、サーバーにはパソコンのLAN内IPアドレス、ポートには実際に使用しているmixed-portを入力します。127.0.0.1は指定しないでください。その後、信頼できるプライベートネットワークに限って該当する受信ポートを許可し、接続可能なネットワーク範囲を制限します。手動HTTPプロキシではスマートフォンのすべての通信が取り込まれるわけではありません。パブリックネットワークで待ち受けを公開せず、必要に応じてプロキシ認証を設定してください。

リモート設定を更新すると通常、設定ファイル全体が再ダウンロードされるため、ファイルを直接編集したルールは置き換えられることがあります。クライアントが提供する上書き、マージ、スクリプト処理の機能を使い、適用順序と対象範囲を確認してください。プロキシの選択が保持されるかどうかは、クライアントやprofile.store-selectedなどの設定にも左右されます。プロキシグループ名やプロキシ名が変わると、以前の選択肢が見つからなくなることもあります。更新前にローカルの上書き設定を保存し、更新後は実際に生成された設定を確認してください。特にカスタムルールが汎用ルールより前にあることを確認しましょう。

まず、システムプロキシのアドレスが起動中のクライアントの待ち受けポートを指しているか確認します。次に、ブラウザーのプロキシ拡張機能、独自のプロキシ設定、システムの自動構成スクリプトが設定を上書きしていないか確認してください。新しい接続でWebサイトにアクセスしながら、クライアントの接続パネルを確認します。記録がまったくない場合は、まず通信の入口を調べてください。記録はあるもののDIRECTで接続されている場合は、モードとルールを確認します。ターミナルのプログラムはシステムプロキシを参照しないことがあるため、各プログラムのドキュメントに従って個別に設定してください。企業の管理ポリシーでプロキシが強制されている場合もあります。スイッチを何度も切り替える前に、デバイスの管理制限を確認しましょう。

まずプロキシを無効にして、ローカルネットワークから正常にアクセスできるか確認します。次に、システム時刻、サブスクリプションの有効期限、現在の設定を確認してください。ログのエラー内容も調べます。ドメイン名の解決に失敗する場合はDNS、接続タイムアウトの場合はサーバーへの到達性、認証エラーやTLSエラーの場合は認証情報、時刻、プロトコルの設定を確認します。その後、利用可能と分かっている別の回線を試すかネットワークを切り替え、障害が回線やネットワークに応じて変化するか確認してください。テストページのタイムアウトだけで、すべてのプロキシが利用できないと判断しないでください。実際のアクセスも失敗する場合は、エラー内容から個人情報などを除いてサービス提供元に問い合わせましょう。

まず、システムにローカルポートを指す手動プロキシ設定が残っていないか確認してください。クライアント終了後はそのアドレスを待ち受けるプログラムがないため、ブラウザーの接続に失敗することがあります。残っている手動プロキシを無効にして、もう一度接続を試してください。TUNを使っていた場合は、クライアントを再起動してTUNを無効にし、正常に終了します。システムのDNSが、停止済みのローカルサービスを参照したままになっていないかも確認してください。最初からすべてのネットワーク設定をリセットするのは避けましょう。会社や学校の端末では、必要なプロキシやDNSが設定されている場合があります。現在の設定を記録してから、管理者が指定した状態に戻してください。

一部のUWPアプリはネットワーク分離の制限により、ローカルPCのループバックプロキシに直接アクセスできません。まず、問題のアプリがシステムプロキシを使用していることを確認します。次に管理者としてコマンドプロンプトを開き、CheckNetIsolation LoopbackExempt -sを実行して除外リストを確認してください。必要であれば、CheckNetIsolation LoopbackExempt -a -n=Microsoft.WindowsStore_8wekyb3d8bbweを実行してMicrosoft Storeを除外します。他のアプリには実際のパッケージファミリー名が必要です。ストア上の表示名をそのまま使わないでください。除外は必要なアプリに限ってください。TUNを使う場合は、ルーティング、DNS、ルールの一致状況も別途確認しましょう。

まずTUNを無効にし、システムプロキシで同じWebサイトにアクセスして、プロキシサービス自体が使えることを確認します。次にTUNだけを有効にし、ログのDNSリクエスト、出力先への接続、ルーティングエラーを確認します。ほかのVPNが同時に動作していないかも調べてください。Fake-IPを使っている場合は、システムのDNS問い合わせがコアに届いていることと、アプリが古いキャッシュを使っていないことを確認します。LAN内のドメインでは、直接接続時の名前解決設定も確認してください。ブラウザーのセキュアDNSは独立した名前解決経路を使うことがあるため、一時的に設定を切り替えて比較します。元の設定を保存し、一度にひとつずつ変更してください。DNS、ネットワークスタック、すべてのルールを同時に変えると原因を特定しにくくなります。