Clashのよくある質問

Clashはプロキシツールのエコシステムにおけるプロジェクト名です。mihomoはClashの設定体系に対応し、機能を継続的に拡張しているコアです。GUIクライアントはサブスクリプション管理、プロキシグループの選択、システムプロキシの設定、ログ表示を担い、実際の接続処理は通常コアが行います。同じクライアントでも、リリースによって搭載されるコアが異なる場合があります。画面上の名称だけで設定項目の対応状況を判断しないでください。トラブルシューティングの前に、バージョン情報画面や起動ログでクライアント名、コア名、バージョンを確認し、該当する設定ドキュメントを参照しましょう。別のコア向けの設定ブロックを現在のファイルにそのまま追加するのは避けてください。

通常はルールモードを使います。接続はrulesの上から順に評価され、指定したプロキシグループ、DIRECT、REJECTに振り分けられます。グローバルモードでは、クライアントが処理する接続にグローバルポリシーを適用しますが、すべてのプロセスが自動的にプロキシを通るわけではありません。対象範囲はシステムプロキシまたはTUNで決まります。直結モードでは、処理対象の接続を直接宛先へ送るため、切り分けに使えます。テストではモードだけを切り替え、DNSやノードは同時に変更しないでください。同じ宛先への接続記録を比較すると、違いがルールによる振り分けか、出口によるものかを判断できます。

クライアントは接続と通信の振り分けを行うツールで、インストールしただけで利用可能な出口が得られるわけではありません。サブスクリプションは、自分で管理するサーバー、所属組織が提供するサービス、または利用許可が明確なサービス提供元から入手してください。公開されている無料ノードはすぐに使えなくなることがあり、接続情報を記録される可能性もあるため、機密性の高い用途には適しません。読み込む前に提供元、有効期限、対応クライアントを確認してください。当サイトではノードやサブスクリプションを提供していません。サブスクリプションURLにはアカウント情報が含まれることが多いため、認証情報として管理しましょう。問い合わせ時はURL全体、ノードのパスワード、個人情報を隠し、設定ファイルをそのまま公開しないでください。

システムプロキシは、HTTPまたはSOCKSの接続先をOSに登録します。実際に使うかどうかはアプリのネットワーク実装次第で、一部のゲーム、コマンドラインツール、独自のネットワークスタックを持つアプリは従わないことがあります。TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込み、通常はより広い範囲をカバーしますが、必要な権限に加え、DNSやルート、ほかのVPNとの調整が必要です。まずシステムプロキシで基本的な接続を確認し、必要に応じてTUNを有効にしてください。TUNはノードを高速化する機能ではなく、出口の停止、サブスクリプションの期限切れ、サーバーによる接続拒否も解決できません。

まず更新ログに記録されたHTTPステータスコードと解析エラーを確認します。403は一般にサーバーがリクエストを拒否したことを示しますが、原因は提供元に確認してください。アカウントの状態、サブスクリプションの有効期限、クライアントの種類を確認しましょう。解析に失敗する場合は、URLから互換性のある設定が返っているか確認します。ログインページやエラーページ、通常のノード一覧では読み込めません。クライアントで更新時の接続方法を選べる場合は、直結とプロキシの両方を試し、ダウンロード経路の問題をサブスクリプションの失効と誤認しないようにしてください。引き続き使える古い設定は残し、何度も削除・再作成するのは避けましょう。提供元に問い合わせる際は、機密情報を伏せたエラー情報だけを送ってください。

まずエラー行の前後にあるインデント、コロン、リストのハイフンを確認します。YAMLのインデントにはスペースを使い、タブを混在させないでください。次に、構文エラーと項目の検証エラーを切り分けます。前者はファイルを解析できない状態、後者はプロキシグループ名の不一致、ノード項目の不足、現在のコアが機能に対応していない状態などです。proxy-groupsとrulesで参照している名前が完全に一致するか、MATCHがルールの末尾にあるかも確認しましょう。一度に変更するのは1か所だけにし、保存後にクライアントの設定チェックを実行してください。アカウント情報を含むファイルを公開のオンライン解析ツールにアップロードするのは避けましょう。

まずログを確認し、仮想インターフェースの作成失敗、権限不足、ルートの競合を切り分けます。Windowsではサービスモードのインストールや起動が必要なクライアントが一般的で、管理者権限での実行に対応したものもあります。macOSでは補助サービスの許可が必要な場合があり、Linuxではサービス権限や/dev/net/tunの利用可否によって異なります。使用中のクライアントの案内に従い、必要最小限の権限を付与してください。出所の不明なスクリプトをそのまま実行するのは避けましょう。ルートを制御しているほかのVPNを終了してから再試行します。インターフェースの作成に成功しても通信できない場合は、権限をさらに引き上げるのではなく、DNSとルートを確認してください。

トレイ機能、サブスクリプション管理、プロキシグループの視覚的な選択が必要なら、GUIクライアントを選びましょう。サーバーやルーターでは、環境に合わせてmihomoコアを導入できます。まずuname -mを実行してアーキテクチャを確認します。x86_64は通常AMD64、aarch64は通常ARM64に対応します。次にディストリビューションに合わせてdeb、rpm、またはプロジェクトが提供する形式を選んでください。CPUのメーカー名だけでインストールパッケージを判断しないでください。インストール後はデスクトップ環境の依存関係、サービス権限、設定ファイルの場所も確認します。コアが起動しても、システムが通信を取り込んでいるとは限りません。プロキシの待ち受け先またはTUNのルートを確認しましょう。

接続パネルで実際のリクエストを探し、宛先ドメイン、宛先IP、適用ルール、最終的な出口を確認します。ブラウザーのアドレスバーだけで判断しないでください。ルールは上から順に評価されるため、広い条件のDOMAIN-KEYWORDやGEOIP、先に置かれたMATCHが後続の詳細ルールに優先することがあります。接続にIPしか表示されない場合、DNSのマッピングやスニッフィング結果がドメインルールに影響している可能性もあります。該当する広いルールより前に一時的なドメイン指定ルールを追加し、既存の接続を終了してから再リクエストしてください。期待どおりに適用されることを確認してから恒久的なルールを整理します。すべての振り分け確認をグローバルモードで代用しないでください。

サブスクリプションから生成された設定を直接編集すると、次回の更新時にリモートの内容で上書きされることがあります。ルール、DNS、プロキシグループの変更を継続して保持するには、使用中のクライアントが対応するオーバーライド、マージ、設定スクリプトの仕組みを使い、完全な設定を扱うのか部分的な設定を扱うのかを確認してください。特に、配列が追加ではなく置換される場合があり、ルールの挿入位置も適用結果に影響します。変更前に元の設定をバックアップし、更新後はエディターの内容だけでなく、最終的に有効な設定を確認しましょう。別のクライアント向けのオーバーライド構文をそのまま流用するのは避けてください。マージの動作はクライアントごとに異なります。

ログイン後にクライアントを起動する設定、バックグラウンドサービスの自動起動、起動後にシステムプロキシを復元する設定は、別々のスイッチで管理されている場合があります。デスクトップでは、まずクライアントの自動起動を有効にし、プロキシ設定が保持されるか確認してください。TUNを使う場合は、必要なサービスも自動起動するか確認します。再起動後は、プロセス、現在の設定、実際の接続記録を確認しましょう。トレイアイコンだけで成功と判断しないでください。Linuxのsystemdサービスでは、実行ユーザーと設定ファイルのパスも確認します。起動時にネットワークへ接続できずサブスクリプションの更新に失敗する場合は、接続後に手動更新して確認できます。

パソコンとデバイスを相互通信できるLANに接続し、クライアントでLAN接続の許可を有効にします。allow-lan、bind-address、実際の待ち受けポートも確認してください。デバイス側にはパソコンのLAN内IPアドレスを指定します。127.0.0.1は指定できません。ポートには現在の設定にあるHTTPまたはmixed-portを入力します。接続できない場合は、ファイアウォールの受信規則、ゲストネットワークの分離、パソコンのIPアドレス変更を確認しましょう。待ち受けを許可するのは信頼できるネットワークに限り、必要に応じてauthenticationを設定して接続元を制限してください。プロキシポートをインターネットに直接公開したり、調査のためにファイアウォールを全面的に無効化したりしないでください。

まずプロキシを無効にして、本機の基本的なネットワーク接続を確認します。次に、サブスクリプションの有効期限、ノードのホスト名が名前解決できるか、システム時刻が正確かを確認してください。レイテンシテストの失敗は、そのテストリクエストが完了しなかったことを示すだけで、ノードが完全に利用できない証拠にはなりません。実際のWebリクエストとコアのログもあわせて判断しましょう。特定のノードだけが失敗する場合は、別の利用可能な出口に切り替えます。すべて失敗する場合は、DNS、ネットワーク制限、認証情報、ほかのVPNとの競合を重点的に確認してください。異なるネットワークで再テストすると切り分けに役立ちますが、一度に変更する条件は1つだけにし、エラー発生時のログを保存してください。

まずコアが起動していることと、待ち受けポートがシステムに登録された値と一致していることを確認します。次に接続パネルで対象アプリのリクエストが表示されるか確認してください。ブラウザーが独自のプロキシ拡張機能や設定を使っていることがあります。コマンドラインツールはHTTP_PROXYやHTTPS_PROXYなどの環境変数だけを参照する場合もあります。変数名にHTTPSが含まれていても、接続先がHTTPSプロトコルとは限りません。プロキシの除外リスト、以前使っていたプロキシソフト、アプリ固有の設定も確認し、変更後に対象アプリを再起動してください。アプリがシステムプロキシに従わない場合は、専用のプロキシ設定を行うか、基本的な接続を確認してからTUNを使い、通信の取り込み範囲を再確認します。

一部のAppContainerアプリはループバック分離の制限により、ローカルのプロキシ接続先へ直接接続できません。まず通常のブラウザーが同じプロキシを利用できることを確認し、クライアント付属のUWPループバックツールで、必要なアプリだけを例外に設定します。ツールの実行に管理者権限が必要な場合があります。管理者ターミナルでCheckNetIsolation LoopbackExempt -sを実行すると、現在の例外を確認できますが、すべてのアプリを一括で許可するのは避けてください。例外を設定したら、対象アプリを完全に終了してから再起動します。解決しない場合は、システムプロキシ、アプリのエラーコード、接続ログを確認してください。ループバックの例外設定では、サブスクリプションやノードの問題は解決できません。

まずTUNを無効にしてシステムプロキシは残し、比較できる状態にします。そのうえで、仮想インターフェース、デフォルトルート、DNSの待ち受けアドレス、dns-hijackが実際に機能しているかを確認してください。IPアドレスには接続できるのにドメイン名で開けない場合は、まず名前解決の経路を調べます。ブラウザーのセキュアDNS、OSの暗号化DNS、別のVPNが想定した経路を迂回している可能性があります。fake-ipモードではドメインのマッピングとルーティングの連携が必要です。enhanced-modeを切り替えるだけでは解決しません。修正後は既存の接続を終了して名前解決をやり直し、接続ログとDNSテストを併用して再確認しましょう。テストページに表示されるDNSサービスの場所は手がかりの1つにすぎず、所在地だけでリークの有無を判断できません。