Clashのよくある質問
とトラブルシューティング

まずクライアントの設定画面でサブスクリプションを読み込み、設定を有効にしてからプロキシグループを選びます。クライアントはウィンドウやメニューバー、システムとの連携を提供します。mihomoカーネルは接続の受け付け、DNSの解決、ルールの照合、通信の転送を担います。サブスクリプションにはサーバー情報が含まれ、プロキシグループやルールが設定されている場合もあります。クライアントをインストールしただけでは、利用可能なプロキシ接続は作成されません。問題を切り分ける際は、画面設定・カーネルの起動・サブスクリプションの内容のどこに原因があるかを確認し、何度も再インストールする前にそれぞれを区別しましょう。

普段はルールモードを選び、接続画面で実際に適用されたルールと出口を確認します。ルールモードでは設定に沿って接続ごとにDIRECTかプロキシかを決定します。グローバルモードではカーネルに入った接続にグローバルポリシーを適用しますが、利用可能な出口の選択は必要です。DIRECTモードでは接続先に直接アクセスします。グローバルモードは短時間の比較テストには便利ですが、アプリの通信を取り込む機能の代わりにはなりません。アプリの通信がカーネルに届いていない場合、モードを切り替えても結果は変わりません。テスト後はルールモードに戻し、接続を張り直して、既存の接続による影響を避けてください。

ブラウザーなどシステムプロキシ設定に従うアプリでは、まずシステムプロキシを使います。システムプロキシを参照しないアプリや一部のUDP通信も取り込みたい場合は、TUNを検討してください。システムプロキシはOSのプロキシ設定を変更し、TUNは仮想ネットワークインターフェースとルーティングを通じて通信を取り込み、必要な権限も求めます。両方を有効にしたときの挙動は、クライアントの実装とルーティング設定によって異なります。切り分けでは一度に一つの通信経路だけを確認し、接続履歴に記録されることを確かめてから組み合わせを調整してください。ほかのVPNがデフォルトルートを制御していないかも確認しましょう。

macOSではAppleメニューから「このMacについて」を開き、AppleシリコンならAppleシリコン版、IntelプロセッサならIntel版を選びます。Windowsでは設定のシステム情報からシステムの種類を確認し、Androidでは端末のアーキテクチャとクライアントの要件に合うパッケージを選びます。ダウンロードページのクライアント情報と配布元の要件を照合し、特に必要なOSの最低バージョンを確認してください。mihomoカーネルのパッケージは主にコマンドライン、サーバー、ルーター向けです。GUIが必要な場合は、ウィンドウ表示や設定管理に対応したクライアントを選びましょう。

クライアントの設定画面を開き、新規作成または設定の読み込みを選択して、サブスクリプションURL全体を入力欄に貼り付けます。ダウンロードが完了したら、その設定を現在の使用項目に指定してください。ローカルファイルはファイル読み込みを選ぶか、クライアントが対応していればconfig.yamlをドラッグ＆ドロップします。読み込み後は設定名とエラーメッセージを確認し、プロキシ画面でプロキシグループを選択します。ボタン名はクライアントによって異なりますが、「読み込む」「設定を有効にする」「出口を選ぶ」の順に操作してください。サブスクリプションURLに含まれる認証情報はそのまま保持し、公開の掲示板などには貼り付けないでください。

まずエラーメッセージに行番号が表示されているか確認し、ダウンロードした内容がClashまたはmihomoで読み込めるYAMLであることを確かめます。ログイン画面やエラーページ、別のクライアント専用形式ではないかも確認してください。YAMLのインデントには半角スペースを使い、同じ階層の項目をそろえます。手動編集では、コロンの後のスペースやリストの階層にも注意してください。通常のBase64形式のノード一覧は、完全な設定としてそのまま有効化できるとは限りません。サービス提供元から対応する形式のサブスクリプションを取得しましょう。元ファイルをコピーしてから編集し、修正後に設定を再読み込みしてください。認証情報を含む設定全体を、信頼できない変換サイトに渡さないでください。

まずTUNを無効にし、クライアント設定からサービスモード、補助サービス、権限のインストールなどの項目を探して、画面の指示に従いシステムの認証を完了してからTUNを再度有効にします。Windowsでは通常、管理者権限のバックグラウンドサービスをインストールして起動する必要があります。macOSでは特権ヘルパーツールの許可が必要な場合があるため、クライアントの案内に従ってください。それでも解決しない場合は、ログで権限・デバイス・ルーティングに関するエラーを確認し、ほかのVPNを一時的に終了して再試行します。権限エラーの解消だけを目的に、すべてのアプリを常に高い権限で実行しないでください。組織管理端末では、ネットワークとセキュリティのポリシーで許可されているか事前に確認しましょう。

まずクライアントの設定で、実際に待ち受けているmixed-portと、待ち受けアドレスがローカルループバックアドレスかを確認します。ポートが使用中と表示されたら、別のプロキシプロセスを終了するか、空いているポートに変更し、そのポートを使うアプリ側の設定も合わせて変更してください。ターミナルのツールはシステムプロキシを参照しない場合があります。curl -x http://127.0.0.1:7890 https://example.comを使って明示的なプロキシ接続をテストできます。ポート番号は実際の設定値に置き換えてください。環境変数が必要な場合は、必要なターミナルセッションだけで設定し、テスト後に削除します。ローカル接続のために、LANからの接続を安易に許可しないでください。

まずプロキシグループの種類を確認し、手動選択か自動チェックかを選びます。selectは手動で選んだ出口を保持するため、固定して使う場合に適しています。url-testは設定されたテストURLとチェック間隔に基づいて候補を選択します。fallbackは順番に候補を確認し、利用可能なものを選ぶため、障害時の切り替えに向いています。テスト結果が示すのは指定したURLへの接続状況であり、すべてのサービスの動作を保証するものではありません。特定のサイトに接続できない場合は、まず出口を手動で固定して比較し、ルールに適用されたプロキシグループを確認しましょう。自動切り替えでテスト条件が変わり続けないようにしてください。

毎回再ダウンロードされるサブスクリプションファイルを直接編集するのではなく、クライアントのオーバーライド、設定のマージ、追加ルールなどの項目にカスタム設定を保存してください。更新時には通常、リモートの内容が置き換えられます。ローカルの変更が保持されるかは、クライアントの実装によって異なります。優先して適用したいカスタムルールは、関連する汎用ルールより前に配置し、参照先のプロキシグループ名が実在することを確認します。保存後に最終的な有効設定を確認し、接続画面で適用結果を検証してください。別のクライアントに移行する場合、オーバーライドの設定場所やマージ構文が異なることがあるため、新しいクライアントの説明に従って移行しましょう。

クライアントの接続画面を開き、対象サイトに再アクセスして、該当するドメインまたは接続先アドレスを探します。適用されたルール、プロキシグループ、最終的な出口を確認してください。新しい記録が見つからない場合は、ルールを変更し続けるのではなく、システムプロキシまたはTUNで通信が取り込まれているかを先に確認します。ルール変更後は対象アプリの既存接続を切断してから再テストしてください。確立済みの接続は通常、すぐには別経路に切り替わりません。ブラウザーのキャッシュ、アプリ内蔵プロキシ、暗号化DNSも確認結果に影響することがあります。必要に応じて単独のテストリクエストを使い、DNSログと合わせてドメインが正しく認識されているか確認しましょう。

まず問題がFake-IPモードのときだけ発生することを確認し、ログから影響を受ける実際のドメインを特定します。必要なドメインだけをfake-ip-filterに追加し、設定を保存して再読み込みした後、アプリの接続を張り直してください。フィルターの動作はfake-ip-filter-modeなどの設定にも左右されるため、現在の設定と合わせて確認しましょう。LAN内機器については、プライベートアドレスのルーティングとDIRECTルールが正しいことも確認します。DNSモードを切り替えると古い名前解決のキャッシュが残る場合があります。関連アプリを再起動し、システムDNSのキャッシュを更新してください。多数のパブリックドメインを一括で除外すると、ドメインの識別や振り分けに影響するため避けましょう。

まず端末の日時、ネットワーク接続、サービス提供元のアカウント状態を確認し、次に更新ログのHTTPステータスとエラー内容を確認します。401は認証情報の不足や期限切れが原因の場合が多く、403はアクセス制限などが関係することもあります。詳しくはサービス提供元の案内を確認してください。タイムアウトの場合は、サブスクリプションURLに直接接続できないのか、現在のプロキシ経路がダウンロードに影響しているのかを切り分けます。クライアントで更新時の通信経路を選べる場合は、DIRECTとプロキシの両方を試してください。最後に使えた設定は残し、すべて削除するのは避けましょう。ログを共有する前に、サブスクリプションURL、認証情報、サーバーの認証情報を伏せてください。

まず候補の出口を一つに固定し、ログからDNSの名前解決失敗、接続拒否、ハンドシェイク失敗、単なるタイムアウトのどれかを確認します。次に別のネットワークでも比較してください。クライアントのテスト先に接続できないと、接続テストは失敗しても一部のサービスは使える場合があります。実際の接続先サイトも合わせてテストしましょう。サブスクリプションが有効であることと端末の日時が正しいことを確認し、セキュリティソフトやファイアウォールがカーネルのプロセスをブロックしていないか調べます。同じネットワークですべての候補が失敗する場合は、まず端末とネットワーク経路を確認してください。一部の候補だけが失敗する場合は、エラー発生時刻とログから個人情報を除いてサービス提供元に問い合わせましょう。

まずOSで現在のネットワーク接続に設定されているプロキシを確認し、アドレスとポートが起動中のクライアントに対応しているか確かめます。次に、ブラウザーの拡張機能や個別のプロキシ設定がシステム設定を上書きしていないか確認してください。明示的なプロキシリクエストは成功するのにブラウザーの接続記録がない場合は、アプリ側の通信経路を優先して調べます。クライアント終了後に接続できない場合は、停止したポートを指すプロキシ設定がOSに残っていることがあります。システムのネットワーク設定で残ったプロキシを無効にして再試行しましょう。macOSでは使用中のネットワークサービスを確認し、WindowsではユーザープロキシとWinHTTPの設定を区別して、無関係な項目を変更しないようにしてください。

まず対象アプリがAppContainerで実行されており、ローカルループバックアドレスを指すシステムプロキシを使っていることを確認します。クライアントにUWPのループバック制限を解除するツールがある場合は、許可を得たうえで、プロキシへのアクセスが必要なアプリだけを選択します。その後、アプリを完全に終了して再起動してください。管理者ターミナルでCheckNetIsolation LoopbackExempt -sを実行すると、既存の例外を確認できます。追加する場合は、正確なパッケージファミリ名が必要です。ループバック制限の解除で解決するのは、アプリからローカルプロキシへのアクセスだけです。サブスクリプションやDNSの問題は修復できません。TUNは別の通信経路として個別に検証し、組織管理端末では管理ポリシーに従ってください。