Clashのよくある質問

Clashはプロキシツールのエコシステムで広く使われる名称です。mihomoはClashの設定形式に対応しながら開発が続くプロキシカーネルで、接続処理、DNS、ルール照合を担います。GUIクライアントはサブスクリプションの管理、ポリシーの選択、ログの確認、システムプロキシの設定などを提供します。画面が似ていても、カーネルのバージョンや機能が同じとは限りません。トラブル対処では、クライアント名とそのバージョン、カーネルのバージョンをあわせて記録してください。設定内のプロトコルや項目が使えるかどうかは、実際に動作しているカーネルの対応状況で判断し、クライアント名だけで決めないようにしましょう。

クライアントは設定を実行するもので、それ自体が利用可能なプロキシサービスというわけではありません。サブスクリプションには通常、プロキシノード、ポリシーグループ、ルールなどが含まれます。ノードのみが提供され、クライアントの設定テンプレートと組み合わせる必要がある場合もあります。読み込む前に、提供元が信頼できること、サービスの有効期限内であること、現在のカーネルに適した形式であることを確認してください。読み込み後は設定を有効にし、ポリシーグループとプロキシモードを選択する必要があります。リンクを保存するだけでは、通信経路は変わりません。サブスクリプションURLにはアクセス用の認証情報が含まれている場合があります。スクリーンショットや公開チケット、チャットにURL全体を載せないでください。

ルールモードはrulesの記載順に照合し、該当したポリシーに接続を振り分けます。ドメインやネットワーク範囲に応じた日常的な振り分けに適しています。グローバルモードは、カーネルに届いた接続をすべてグローバルポリシーに渡すため、ルールが原因かどうかを一時的に切り分ける際に便利です。DIRECTモードでは、カーネルに届いた接続を宛先へ直接接続します。グローバルモードでも、すべてのアプリの通信がクライアントを通るわけではありません。システムプロキシやTUNを経由していない通信は、そもそもカーネルに届かないことがあります。モードを切り替えたら新しい接続で確認してください。既存の長時間接続は、切り替え前の経路を使い続ける場合があります。

システムプロキシは、OSにプロキシアドレスを登録する仕組みです。主に、その設定を参照するアプリに適用されます。TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込み、システムプロキシに従わないアプリの通信などに利用されます。必ずしも両方を有効にする必要はありません。初めて使う場合は、まずシステムプロキシで動作を確認し、必要に応じてTUNを有効にしてください。TUNは権限やルーティング、DNS、ほかのネットワークソフトとの互換性にも関係します。有効化後にネットにつながらなくなった場合は、サブスクリプションを何度も切り替えるのではなく、まずTUNを無効にして比較してください。具体的な組み合わせ方は、クライアントの実装と説明を確認しましょう。

まず設定画面で更新エラーを確認し、URLへのアクセス失敗と内容の解析失敗を切り分けます。401や403が返る場合は、サブスクリプションの期限切れ、認証情報の変更、提供元によるアクセス制限を確認してください。404の場合は、URLが変更されていないか提供元に問い合わせます。ログイン画面やウェブ認証ページ、形式エラーが返る場合、受信した内容は設定ファイルではない可能性があります。タイムアウトする場合は、ローカルネットワークと、クライアントがサブスクリプションを取得する際にDIRECTとプロキシのどちらを使っているかを確認してください。更新に成功するまでは、以前の正常な設定を残しておきましょう。サブスクリプションの失効に対し、クライアントの再インストールを最初の手段にしないでください。

まず元のファイルをコピーし、ログに表示された行番号の前後を確認します。YAMLの階層はスペースでインデントし、タブを混在させないでください。リスト項目のハイフン、コロンの後のスペース、特殊文字を含む文字列にも注意が必要です。構文が正しくても、ルールの参照先が存在するか、ポリシーグループが参照するノード名が完全に一致するか、現在のカーネルが使用している項目に対応しているかを確認します。行番号は解析が停止した位置を示すことがあり、実際のエラーはその前の行にある場合もあります。少しずつ修正してその都度確認し、読み込みに成功してから有効にすれば、問題が起きた際に元へ戻しやすくなります。

まずカーネルが正常に起動していることを確認し、クライアントが必要とするサービスモードや補助プログラム、管理者の許可が設定済みかを確認してください。Windowsではサービスのインストールと起動が必要な場合があります。macOSでは補助プログラムに必要な権限を確認します。Linuxでは仮想インターフェースへのアクセス権やネットワーク管理権限が関係することがあります。提供元が不明なプログラムに安易に権限を与えず、インストール元とクライアントの説明を確認してください。許可を設定したらクライアントを再起動し、ログでインターフェースの作成とルーティング設定が成功したか確認します。組織のポリシーで管理されている端末では、管理者に権限の範囲を確認してください。管理上の制限を回避しないでください。

一部のWindowsパッケージアプリはAppContainerのネットワーク分離の影響を受け、ローカルのプロキシアドレスへ接続するためにループバックの免除が必要な場合があります。ただし、ストアアプリの接続問題がすべてこれに起因するわけではありません。まず同じシステムプロキシを使ってブラウザーから接続できるか確認し、対象アプリの接続記録が残っているかを調べてください。クライアントにループバック免除ツールがある場合は、必要性と信頼性を確認したうえで対象アプリにだけ適用します。管理者はシステムツールで、該当するアプリパッケージの免除状態を確認することもできます。変更後はアプリを完全に終了してから開き直してください。ループバック権限で解決できるのはローカルアクセスの制限だけです。サブスクリプション、DNS、リモート接続の問題は解決できません。

まず、システムプロキシのアドレスとポートをクライアントの実際の待ち受け設定と照合し、カーネルが動作していることを確認してください。例にある既定値の7890が、現在の設定でも使われているとは限りません。次に、アプリ独自のプロキシ設定があるか、システムプロキシを無視していないか、システムのバイパスリストに対象のアドレスが含まれていないかを調べます。アプリから新しいリクエストを送り、クライアントの接続画面やログを確認してください。記録がまったくない場合は、振り分けルールではなく通信を取り込む経路を優先して調べます。ほかのプロキシソフトやネットワーク管理ツールがシステム設定を上書きしていないかも確認し、必要なら比較のため一つだけ残してください。

多くのコマンドラインツールは、デスクトップのシステムプロキシを自動では参照しません。ツールの説明に従ってHTTP、HTTPS、またはSOCKSプロキシを設定してください。mixed-portを使う場合、HTTPプロキシに対応したツールにはローカルアドレスとそのポートを指定できます。external-controllerを誤って指定しないでください。これは制御用のインターフェースであり、通信の入口ではありません。ターミナルの環境変数が影響するのは、それを読み取るプログラムだけです。変数名や適用方法もツールによって異なるため、変更後は同じターミナルから新しいプロセスを起動して確認します。まず現在のセッションだけで一時設定し、動作を確認してから永続化してください。クライアントを終了する際は設定も元に戻し、プロキシ設定が残って接続できなくなるのを防ぎましょう。

クライアントの速度テストは通常、指定したアドレスに接続して確認します。結果が示すのはその時点でのテスト接続の状態であり、すべてのウェブサイトにアクセスできることや、ダウンロード速度を保証するものではありません。まず、現在のポリシーグループで選択されているノードがテスト対象と一致するか確認し、ウェブページへの接続がどのポリシーに振り分けられたかを調べます。一部のサイトだけ失敗する場合は、ドメインの名前解決、ルールの適用先、接続先サービスのアクセス制限を確認してください。すべての接続先で失敗する場合は、ノードの有効性とローカルネットワークを調べます。テスト先自体に接続できず誤判定になることもあるため、ログと実際のアクセス結果をあわせて確認し、遅延値だけを見て頻繁にノードを切り替えないでください。

サブスクリプションファイルは更新時に再ダウンロードされることが多く、内容を直接編集すると上書きされる場合があります。長期的に維持したい設定には、クライアントが対応するオーバーライド、マージ、またはスクリプト機能を使い、リストが追加、先頭への挿入、全置換のどれで処理されるかを確認してください。カスタムrulesの配置も重要です。具体的なルールは先に一致する可能性のある広範なルールより前に置き、MATCHは通常、フォールバックとして末尾に置きます。変更後は最終的に適用された設定を確認し、ポリシー名の参照が有効なことを確かめてください。オーバーライドの形式はクライアント間で共通とは限りません。移行時はそのまま別のクライアントにコピーせず、あらためて確認してください。

まずクライアントのプロキシを無効にし、ローカルネットワークから通常のDIRECT接続先にアクセスできることを確認します。次にサブスクリプションの有効期限、ノードが正しく読み込まれているか、端末の時刻が正確かを調べてください。その後、ノードを一つ選んで実際に接続し、ログを見ながら名前解決エラー、接続タイムアウト、認証エラー、証明書エラーを切り分けます。すべてのノードで失敗する場合、共通のネットワーク経路やサブスクリプションに問題がある可能性があり、各ノードがすべて無効だとは限りません。可能であれば、信頼できる別のネットワークでも比較します。速度テストだけ失敗する場合は、テスト先も確認してください。問い合わせ時は個人情報などを伏せたエラー内容と操作手順を共有し、ノードのパスワードやサブスクリプションの認証情報を公開しないでください。

まずログで問題のドメインが名前解決できているか確認し、接続が正しいポリシーに振り分けられているかを調べます。Fake-IPはマッピングされたアドレスを使って通信を振り分けますが、一部のアプリやネットワーク環境では対応しないことがあります。ただし、ページが開かないだけでFake-IPが原因とは断定できません。元の設定を残したうえで、クライアントが対応する方法で名前解決モードを一時的に切り替えて比較してください。一部のドメインだけに非互換があると確認できた場合は、すべてのドメインを除外するのではなく、カーネルのドキュメントを確認してfake-ip-filterの利用を検討します。変更後は新しい接続を確立し、必要に応じてシステムやアプリのDNSキャッシュを更新してください。ブラウザーのセキュアDNSが想定した名前解決経路を迂回していないかも確認します。

まずクライアントを二重に起動していないか、ほかのプロキシツールが同時に動作していないか確認してください。Windowsではnetstatで待ち受けポートと対応するプロセスを調べられます。macOSとLinuxではlsofやssを使えます。プロセスの用途を確認してから終了するものを決め、見覚えのないシステムプロセスを強制終了しないでください。既存のプロセスを残す必要がある場合は、mixed-portを空いているポートに変更し、システムプロキシ、ブラウザー独自のプロキシ、ターミナルの設定もあわせて変更します。エラーがプロキシポートと制御ポートのどちらを指しているかも確認してください。両者は置き換えられません。変更後はカーネルが正常に待ち受けていることを確認し、新しい接続でテストします。

まず、システムプロキシがすでに待ち受けを停止したローカルポートを指していないか確認し、ブラウザーやターミナルに個別設定したプロキシも解除してください。TUNを使っていた場合は、クライアントを再度開き、通常の終了手順でTUNを無効にしてシステムプロキシを解除してから終了します。その後、仮想インターフェースとルーティングが復旧したか確認してください。まだ問題がある場合は、システムDNSが現在到達できないアドレスに手動設定されていないかを調べ、ネットワークに再接続します。操作前に元のネットワーク設定を記録してください。特に社内ネットワークや固定アドレスの環境では注意が必要です。必要な設定まで失わないよう、最初からネットワーク設定全体をリセットしないでください。