Clashのよくある質問

クライアントは、設定のインポートやプロキシグループの選択、サービスの起動を行う操作アプリです。mihomoは接続とルールを処理するコアです。サブスクリプションはサービス提供元が発行する設定URLで、通常はノード、プロキシグループ、ルールが含まれます。クライアントをインストールしただけでは使えず、対応する設定をインポートする必要があります。トラブル時は、アプリが起動しないのか、設定を読み込めないのか、ノードに接続できないのかを切り分けましょう。すべてをサブスクリプションの問題と決めつけないことが大切です。

VPNアイコンが示すのは、クライアントがAndroid上にローカルVPNインターフェースを作成したことだけで、接続先ノードが使えるとは限りません。VpnServiceは、端末のネットワーク通信を受け取るためにAndroidが提供するシステム機能です。クライアントは設定に応じて通信を処理します。アイコンが表示されたら、プロキシグループで選択中のノードを確認し、実際のWebページやアプリで接続をテストしてください。ページを開けない場合は、接続ログで名前解決、ハンドシェイク、タイムアウトなどを確認しましょう。アイコンだけを頼りにアプリを何度も再インストールする必要はありません。

普段はRule（ルールモード）を選び、プロキシグループでノードを指定します。ルールに従って、直接接続する通信とプロキシ経由にする通信を振り分けます。Globalは、コアに入った通信をグローバルポリシーに渡すモードです。ポリシーで使うノードは別途選択します。Directでは、コアに入った通信を直接接続します。モードが適用されるのはコアに渡された通信だけで、対象外のアプリまで自動的にプロキシ経由になるわけではありません。ルールの問題を切り分けるために一時的にGlobalへ切り替えても、テスト後は元のモードに戻してください。

関連はありますが、同じスイッチではありません。TUNはIP層の通信を受け取る仮想ネットワークインターフェースの方式です。Androidのクライアントは通常、VpnServiceを利用してシステム通信を受け取ります。アプリによって設定項目が「VPN」「サービス」「TUN」など異なる名称の場合があります。デスクトップ版のTUNでは、管理者権限やサービスコンポーネント、ルーティングの設定が必要になることもあります。PC向けの権限コマンドをそのまま使わず、まず端末のプラットフォームを確認し、利用中のクライアントの手順に従ってください。

まず、サブスクリプション提供元の端末数や同時接続数の上限を確認し、両方のクライアントがサブスクリプション内のプロトコルや設定項目に対応しているか調べてください。インポートできても、すべての設定が両方のプラットフォームに適しているとは限りません。待ち受けアドレス、ファイルパス、TUN、DNSのシステム連携方法は端末ごとに異なる場合があります。リモートサブスクリプションは共有し、プラットフォーム固有の差分は各端末のローカルオーバーライドに設定するのがおすすめです。オーバーライドは、設定更新後に適用するローカルの変更です。端末ごとのシステム設定を上書きしないよう、アプリのデータフォルダー全体を同期しないでください。

まずクライアントに設定をインポートして選択し、プロキシサービスを起動します。AndroidにVPN接続の確認画面が表示されたら、アプリ名がインストール済みのクライアントと一致することを確認して許可してください。確認画面が表示されない場合は、ほかのVPNアプリを停止してからサービスを再起動します。仕事用プロファイルや端末管理ポリシーによって、許可が制限されることもあります。許可後はシステム設定のVPN画面で接続状態を確認してください。VPN接続を許可しても、ノード提供元に端末内のファイルへのアクセスを許可したことにはなりません。

設定画面でURLからのインポート項目を開き、サービス提供元からサブスクリプションURLをもう一度、すべてコピーしてください。URLの前後に空白や改行、チャットアプリが付けた記号が混ざっていないか確認し、管理画面のURLではなくサブスクリプションURLをコピーしたか確かめます。それでも失敗する場合はインポートログを確認します。ネットワークタイムアウトなら別の回線で試し、形式エラーならURLがログイン画面やエラーページを返していないか確認してください。サブスクリプションURLにはアクセス情報が含まれることがあるため、全文を公開フォーラムに貼ったり、スクリーンショットで共有したりしないでください。

まずサービス提供元の管理画面で、有効期限や残りの利用量を確認し、サブスクリプションURLがリセットされていないか調べます。HTTP 401や403はアクセス許可に関係することが多いものの、サイト側のアクセス制限が原因の場合もあります。ステータスコードだけで期限切れと判断しないでください。URLを再コピーして手動更新し、更新後の設定がクライアントで選択されていることを確認します。ダウンロードできてもノードが表示されない場合は、形式が違うデータや空の設定を取得していないか調べてください。すぐに古い設定を削除せず、戻せるよう使える設定を残しておきましょう。

アプリアイコンを長押ししてアプリ情報を開き、バッテリーまたはバックグラウンド実行の設定で、クライアントを「制限なし」またはバックグラウンド動作を許可する設定にします。機種によっては自動起動の許可や、最近使ったアプリ画面でのロックも必要です。設定名はメーカーや機種によって異なるため、実際のシステムメニューを確認してください。設定後にサービスを起動し、数分間画面をロックしてテストします。Wi-Fiとモバイル通信の切り替え時だけ切断される場合は、ネットワーク切り替えのログも確認しましょう。バッテリー最適化の対象外にしても、ノード自体の切断や設定ミスは解決できません。

まずTUNを無効にし、クライアントの設定でサービスモードやサービスコンポーネントがインストール済みで、実行中か確認します。Windowsでは通常、画面の案内に従って管理者権限での操作を許可します。macOSではシステム設定で関連する権限の確認が必要な場合があります。Linuxではクライアントのドキュメントに従って、サービスやネットワーク権限を設定してください。設定後にクライアントを再起動してからTUNを有効にします。提供元が不明なプログラムを高い権限で使い続けたり、ルーティングコマンドを何度も追加したりしないでください。解決しない場合は具体的なエラーを記録し、以前使っていたVPNの仮想ネットワークアダプターとの競合も確認しましょう。

クライアントのオーバーライド、ルール編集、拡張設定の項目を探し、サブスクリプション更新で置き換わらないよう、継続して使うルールはローカルオーバーライドに追加します。ルールは通常上から順に評価され、最初に一致したルールが適用されます。そのため、特定のドメイン向けルールは、範囲の広いルールや最後のフォールバックルールより上に配置してください。追加後に設定を再読み込みし、接続ログで一致したルールを確認します。ルールで指定したプロキシグループ名は設定内の名前と一致している必要があります。名前が異なると読み込みに失敗することがあり、近くのノードへ自動的に切り替わるわけではありません。

クライアントの接続画面を開き、対象アプリから新しいリクエストを送って、該当ドメイン、一致したルール、最終的なポリシーを確認します。既存の長時間接続は切り替え前の経路を使い続ける場合があるため、ノード変更後は対象アプリを終了して再起動してください。Androidでアプリごとのプロキシ設定を有効にしている場合は、対象アプリが適用範囲に含まれているかも確認します。ノードの速度テストは指定された確認用アドレスへの通信を測るもので、対象アプリのサーバーに接続できることを示すものではありません。実際のサービス画面でテストし、リクエスト時刻とログの時刻を照合してください。

両方の端末に同じリモートサブスクリプションを追加し、それぞれにローカルオーバーライドを作成して、維持したいDNS、ルール、プラットフォーム設定を記録します。まずサブスクリプションを手動更新し、オーバーライドが有効なままか確認してから設定を再読み込みしてください。設定項目の統合方法はクライアントによって異なるため、ルールが追加、先頭に挿入、置換のどれになるか特に確認が必要です。移行前に必要なローカル設定をエクスポートし、プロキシグループの選択も記録します。稼働中の設定ファイルを同期ツールで直接上書きすると、書き込み途中のファイルが読み込まれるおそれがあるため避けてください。

AndroidのVPN設定で、使用中のクライアントの横にある設定項目を開き、2つのオプションを確認します。「VPNを常時接続」はシステムがVPNサービスを維持または再接続するための設定です。「VPN未接続時の通信をブロック」を有効にすると、VPNを経由しない通信が制限され、サービスに問題が起きた際に端末全体がインターネットに接続できなくなる場合があります。クライアントがこれらの動作に対応していることを確認し、再起動やネットワーク切り替えをテストしてから、必要に応じて有効にしてください。有効にした後に接続できなくなった場合は、まず同じ画面でブロック設定をオフにし、設定やアプリごとの対象範囲を確認しましょう。

まず問題がどの層にあるかを確認します。ノード一覧が古い、または提供元がURLを変更した場合はサブスクリプションを更新します。設定で未対応のプロトコルや項目が表示された場合は、クライアントやコアの更新が必要か確認してください。通常の利用では、すべての設定を同時に変更する必要はありません。クライアントを更新する前にローカルオーバーライドと重要な設定を保存し、更新後は元の設定を読み込んでテストします。クライアント、サブスクリプション、DNS、モードを一度に変更すると、問題の原因を特定しにくくなります。一度に一項目だけ変更し、変更前後の接続状況を記録してください。

まずプロキシサービスを停止し、端末の通常のネットワーク接続で普段使うサイトにアクセスできるか確認します。次に、サブスクリプションの有効期限と利用量、ノード一覧の更新状況を確認してください。その後、システムの日付と時刻が自動同期されているか確認し、ログにDNS名前解決の失敗、接続タイムアウト、ハンドシェイクエラーがないか調べます。別のノードと別のネットワークを組み合わせてテストし、実際に対象のWebページを開きます。速度テストだけが失敗し、ページは開ける場合は、テスト用アドレスに接続できない可能性があります。最初からクライアントを再インストールすると、現在の設定が失われるうえ、接続先ノードの障害も解決できません。

まずクライアントでローカルプロキシのポートが待ち受け中か確認し、Windowsの「ネットワークとインターネット」設定でプロキシのアドレスとポートが一致しているか調べます。ブラウザー拡張機能や個別のプロキシ設定、一部の組織ポリシーがシステムプロキシを上書きすることがあります。該当する拡張機能を無効にするか、システム設定に従うよう変更し、ブラウザーを再起動してください。次にクライアントの接続ログに対象のリクエストが記録されているか確認します。記録がなければ通信の入口を、記録があるのにアクセスできない場合はポリシー、ノード、DNSを確認しましょう。システムプロキシのスイッチを何度も切り替えるのは避けてください。

多くのコマンドラインツールはデスクトップのシステムプロキシ設定を自動で読み込みません。まずツールが対応するプロキシ引数や環境変数を調べ、クライアントが実際に待ち受けているアドレス、ポート、プロトコルを設定してください。HTTPプロキシとSOCKSプロキシは、プロトコルを無視してポートだけ変えても使えません。プログラムによってはALL_PROXYも必要です。詳しくはツールのドキュメントを確認してください。設定後は新しいターミナルでテストし、接続ログも確認します。複数のプログラムの通信をまとめて制御する必要がある場合は、TUNの利用も検討できます。認証情報を含む環境変数の出力や、ターミナル全体のスクリーンショットを公開しないでください。

まずログで、名前解決に失敗しているのが接続先サイトのドメインかノードサーバーのドメインかを確認します。次に、設定したDNSの上流サーバーに現在のネットワークから接続できるか調べてください。暗号化DNSのサーバーアドレス自体も、先にドメイン名の解決が必要な場合があります。同じく到達できない別のアドレスに安易に変更しないでください。AndroidのプライベートDNS、ブラウザーのセキュアDNS、クライアントのDNSで名前解決経路が分かれることがあります。テストでは一度に一項目だけ変更しましょう。fake-ip（合成アドレス方式）を使っている場合は、ブラウザーのキャッシュを消すだけでなく、クライアントがDNS通信を正しく処理しているか確認します。

まず、対象アプリが制限付きのアプリコンテナーで実行されていることを確認し、デスクトップブラウザーが同じプロキシ経由で接続できるか調べます。一部のUWPアプリは、初期状態では127.0.0.1などのローカルループバックアドレスに接続できません。そのため、クライアントのローカルプロキシポートに接続できない場合があります。クライアントにUWPループバックツールがある場合は、必要なアプリだけを対象に例外を追加し、案内に従って許可してください。ツールがない場合は、WindowsのCheckNetIsolationのドキュメントを確認します。必要なアプリだけ設定し、変更後にアプリを再起動して接続ログを確認してください。