Clashのよくある質問
とトラブル対処

コアはプロキシ接続、DNSの名前解決、ルールの照合を担います。GUIクライアントは設定の読み込み、プロキシグループの選択、システムプロキシの管理を行います。MihomoはClashエコシステムで開発が続く互換コアですが、クライアントによって搭載コアや対応フィールドは異なります。トラブル時は、設定 → バージョン情報またはコア情報でクライアント名とコアのバージョンを確認してください。「Clashをインストールした」だけでは特定できません。別のクライアントで読み込めた設定でも、現在のコアがすべてのフィールドに対応しているとは限りません。unsupportedまたはunknown fieldが表示された場合は、画面の再インストールを繰り返すのではなく、現在のコアの対応範囲に合わせて設定を調整してください。

クライアントとサブスクリプションサービスは別のものです。アプリをインストールしても、プロキシ回線が自動で提供されるわけではありません。自分の設定ファイルを読み込むか、サービス提供元から入手したClash対応サブスクリプションを利用してください。通常は「設定」または「Profiles」で「新規作成」→「URLから読み込む」を選びます。ダウンロード後、その設定を有効にしてからプロキシ画面でプロキシグループを選択します。サービスのログインページのURLをサブスクリプションURLとして使ったり、単一の共有リンクだけを含む内容を完全なYAMLとみなしたりしないでください。サブスクリプションURLのtokenはアクセス認証情報です。スクリーンショットや公開ログで共有しないでください。漏えいした場合は、サービスの管理画面でリンクを再発行してください。

普段はルールモードがおすすめです。通信をrulesに沿って照合し、該当するプロキシグループに振り分けます。グローバルモードでは、コアに届いたリクエストをグローバル用のプロキシ選択に従って処理しますが、すべてのアプリを自動で制御するわけではありません。システムプロキシ、TUN、明示的なプロキシ設定を使わないアプリは、コアを経由しない場合があります。直接接続モードでは、コアに届いた通信をそのまま宛先へ接続します。グローバルモードにしても速度が上がるわけではありません。変わるのは経路の選択だけです。一時的な切り分けには、同じノードでルールモードとグローバルモードを比較します。ルールモードだけ失敗する場合は、適用されたルールとプロキシグループを確認してください。テスト後はルールモードに戻し、グローバル用と用途別のグループで異なるノードを選んでいないか確認しましょう。

遅延テストで測るのは、特定の宛先への短いリクエストにかかる時間であり、継続的なダウンロード速度ではありません。テスト先やタイムアウト時間、プロキシ経由かどうかによって結果は変わります。遅延が小さくても、夜間の混雑時に十分な回線容量があるとは限りません。実際の接続でテスト対象のノードが使われていることを確認してください。自動選択のプロキシグループが別のノードを選んでいる場合があります。同じファイルを同じ時間帯にダウンロードして比較しましょう。速度には、接続先サイトの速度制限、Wi-Fi環境、ネットワーク間の混雑、サービス側の上限も影響します。全ノードを短時間に何度もテストすると、負荷が増えたり制限されたりするおそれがあります。timeoutが出ても、そのテストが失敗したというだけです。実際の接続状況やログも確認し、数値ひとつでノードが完全に使えないと判断しないでください。

まず、ダウンロード失敗と設定の解析失敗を切り分けます。ログに401または403がある場合は、サブスクリプションURLが再発行されていないか、契約期間が終了していないか、サービス側でリクエストが制限されていないかを確認してください。403はアクセス保護による場合もあり、必ずしもパスワードの誤りではありません。接続タイムアウトの場合は、システム時刻が正しいか、現在のネットワークからサブスクリプションのドメインにアクセスできるか、更新時に無効なプロキシを経由する設定になっていないかを確認します。更新経路を切り替えられるクライアントなら、一時的に直接接続で試してください。ダウンロードは成功するのに読み込みに失敗する場合は、取得した内容がYAMLではなくログインページやエラー説明になっていないか確認しましょう。サービスの管理画面からClash対応リンクをコピーし直してください。クエリパラメーターをむやみに削除したり、URL全体を公開の掲示板に投稿したりしないでください。

エラーに表示された行番号とフィールドのパスを確認し、その行と直前の行を調べます。YAMLのインデントには半角スペースを使い、Tabは混ぜないでください。リスト項目の前にはハイフンを付け、キーの後には半角コロンを使います。値に特殊文字が含まれる場合は、引用符で囲みます。よくある原因は、コードのコピー時に全角記号が入る、dns配下のフィールドを最上位に置く、同じ階層にrulesを重複して書くことです。変更前に元のファイルをバックアップし、一度に一か所だけ修正して、クライアントの設定チェック機能を使いましょう。構文エラーが解消しても、プロキシグループやプロキシが存在しないと表示される場合は、名前の参照先を確認してください。これはインデントの問題ではありません。リモートのサブスクリプション設定は更新時に上書きされることがあります。継続的に変更する場合は、クライアントのオーバーライドまたはマージ機能を使ってください。

まず、使用中のクライアントとコアがTUNに対応しているか確認し、起動ログから具体的な失敗原因を調べます。Windowsでは通常、クライアントのサービスモードをインストールまたは有効にする必要があります。必要に応じて、クライアントの説明に従い、初回設定を管理者権限で行ってください。macOSでは、クライアントの実装によってバックグラウンドサービスやネットワーク機能の許可が必要になる場合があります。Linuxでは/dev/net/tunが存在するか、サービスにインターフェースの作成やルート変更に必要な権限があるかを確認します。デスクトップアプリ全体を常に高い権限で実行することだけを解決策にしないでください。ルートの競合を避けるため、ほかのVPNによる仮想ネットワークインターフェースの制御も一時的に停止します。通信を制御する方式は一度に一つだけ有効にしてください。ログでインターフェースの作成成功を確認してから、DNSとアプリの接続を調べましょう。

起動時にシステムのVPN接続リクエストを許可し、クライアントの実行通知が表示されていることを確認します。通常、Androidでは同じユーザー環境で同時に有効にできるVPNは一つです。別のVPNや、VPNインターフェースを使うフィルタリングアプリが現在の接続に置き換わる場合があります。画面ロック後だけ切断される場合は、システム設定 → アプリ → 対象のクライアント → バッテリーで、バックグラウンド実行を許可するか「制限なし」に設定します。メーカー独自の自動起動、バックグラウンド動作、タスクロックの設定も確認してください。メニュー名はシステムによって異なります。最近使ったアプリの一覧に残すだけでは、許可リストに追加されたことにはなりません。通知が表示されたまま通信が止まる場合は、ネットワーク切り替えやノードの再接続失敗がログにないか確認し、Wi-Fiとモバイル通信をそれぞれ試してください。

システムプロキシのスイッチは、OSにプロキシのアドレスを書き込むだけで、コアの待ち受けが成功したことを意味しません。まずログでmixed-portの実際の待ち受けアドレスとポートを確認し、システムのネットワーク設定にあるHTTP・HTTPSプロキシと照合してください。ブラウザーの拡張機能や独自のプロキシ設定、一部アプリのネットワーク設定がシステム設定を上書きすることがあります。テスト時は、こうした設定を一時的に無効にしてください。宛先にアクセスしたあと、クライアントの接続画面を確認します。接続記録がなければ、リクエストはまだコアに届いていません。記録がありDIRECTと表示される場合は、システムプロキシを切り替え続けるのではなく、ルールとプロキシグループを確認してください。システムプロキシを参照しないアプリでは、明示的な設定またはTUNが必要です。プロキシの除外リストにも注意してください。対象ドメインが除外されていると、想定どおりにプロキシを経由しません。

まずポートを使用しているプロセスを確認してから、ポートを変更するか判断します。Windowsではnetstat -ano | findstr :7890を実行し、PIDからプロセスを特定できます。macOSまたはLinuxではlsof -nP -iTCP:7890 -sTCP:LISTENを使います。別のクライアントが使用している場合は、古いインスタンスを通常の方法で終了してください。正体の分からないシステムプロセスを強制終了しないでください。ポートを変更する必要がある場合は、次の設定例のように混合ポートを7891に変更し、接続先をローカルに限定します。保存後に設定を再読み込みし、コアの待ち受けが成功したことを確認してください。その後、システムプロキシをいったんオフにしてから再度オンにし、アドレスを同期します。ブラウザー、ターミナル、プロキシを明示的に設定しているほかのツールも、同じポートに変更してください。クライアントに独立したポート設定画面がある場合は、最終的に有効な設定とログを優先してください。

mixed-port: 7891
allow-lan: false

スマートフォンからPCのプロキシポートに接続するには、通常、PCでallow-lanを有効にし、待ち受けアドレスがLANからの接続を受け付けるようにします。127.0.0.1だけで待ち受けている場合、ほかのデバイスからは接続できません。2台のデバイスが互いに通信できる安全なLANに接続していることを確認してください。スマートフォンのWi-Fi設定で手動HTTPプロキシを指定し、PCのLAN内IPアドレスと実際のmixed-portを入力します。127.0.0.1は指定できません。PCのファイアウォールでは必要なネットワーク範囲だけを許可し、コアが対応している場合はプロキシ認証を設定してください。ルーターでプロキシポートをインターネットに公開しないでください。同じWi-Fiに接続していても、クライアント分離機能によりデバイス間で通信できないネットワークがあります。また、スマートフォンのHTTPプロキシはすべてのアプリやプロトコルを制御するわけではありません。まずブラウザーで基本的な接続を確認しましょう。

まず、そのアプリが実際にローカルプロキシを利用しているか確認します。一部のUWPやAppContainerアプリはネットワーク分離の制限により、ローカルのループバックアドレスに直接アクセスできません。そのため、ブラウザーが正常でも、この問題がないとは限りません。クライアントにUWPループバックまたはLoopbackツールがある場合は、対象アプリに必要なループバックの例外を追加してください。CheckNetIsolation LoopbackExempt -sで既存の例外を確認してから、正確なアプリのパッケージファミリー名を指定し、Windowsのツールの説明に沿って追加する方法もあります。変更には通常、管理者権限が必要です。すべてのアプリで一度にネットワーク分離を解除しないでください。また、ループバックの例外は接続問題を何でも解決する機能ではありません。TUNを使うと接続できる場合は、元のシステムプロキシ経路を確認しましょう。それでも失敗する場合は、アプリのアカウント、DNS、適用されたルールを調べてください。

まずプロキシを無効にした状態で、ローカルネットワークが正常にインターネットへ接続できることを確認します。次に、サブスクリプションが有効か、利用可能な通信量が残っているか、システムの日付と時刻が正しいかを確認してください。ノードをテストする際はログも確認し、サーバーへの接続タイムアウト、TLSハンドシェイクエラー、ドメインの名前解決失敗を区別します。この3つは対処法が異なります。すべての速度テストだけが失敗する場合は、確実にアクセスできる別のテストURLを使い、対象サイトも実際に開いてください。テスト先の不具合を、すべての回線が使えないと誤認するのを防げます。プロキシクライアントやVPNを複数同時に実行していないかも確認します。同じノードが別のネットワークでは使える場合、現在のネットワークの制限やローカルルートを優先して調べてください。複数のデバイスとネットワークで失敗する場合は、サービス提供元にサーバーの状態を確認します。

DNSが原因の可能性はありますが、まずログで名前解決の失敗、タイムアウト、異常なアドレスがないか確認してください。システムのnslookupは通常、OSの名前解決先を問い合わせるため、アプリがコアを経由するときの名前解決経路と同じとは限りません。そのため、nslookupが成功してもコアのDNSが正常だとは判断できません。有効な設定のdns.enable、enhanced-mode、nameserverを確認し、現在のネットワークから上流のDNSサーバーに接続できるかも調べます。fake-ipを使う場合は、TUN、DNSリダイレクト、アプリのキャッシュが連携しているか確認してください。モードを切り替えたあとは、影響を受けるアプリを再起動し、DNSキャッシュを消去すると改善する場合があります。出所の分からないDNS設定を丸ごとコピーしたり、fallbackを追加すれば必ず汚染が解消すると考えたりしないでください。まずサブスクリプションの元設定に戻し、一度に一つのフィールドだけ変更して、同じドメインの結果を確認しましょう。

よくある原因は、待ち受けが停止したローカルプロキシをシステムが引き続き参照していることです。Windowsでは設定 → ネットワークとインターネット → プロキシで手動プロキシを確認します。macOSではシステム設定 → ネットワーク → 現在の接続 → 詳細 → プロキシで、HTTP、HTTPS、SOCKSの設定を確認してください。クライアントが追加したと確認できた設定だけを無効にします。会社のネットワークで使っていたプロキシは、記録せずに消去しないでください。ターミナルでHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを設定した場合は、現在のセッションと起動時の設定も確認します。以前TUNを使っていた場合は、クライアントを再起動し、TUNをオフにしてから通常の手順で終了すると、ルートやDNSが整理されます。まだ解決しない場合は、現在のネットワーク設定を記録してから再接続してください。最初からネットワーク設定全体をリセットするのは避けましょう。

再インストールを検討する前に、設定とログを保存してください。クライアントのデータディレクトリやシステムのクラッシュレポートから終了直前のログを確認し、設定の解析失敗、コアファイルの起動失敗、権限拒否、GUIの実行環境不足を切り分けます。設定を変更した直後に発生した場合は、バックアップを取ってから、以前の正常な設定に戻してください。設定を戻してもクラッシュする場合は、インストーラーのアーキテクチャがシステムに合っているか、セキュリティソフトがコアファイルを隔離していないかを確認します。セキュリティ機能を全面的に無効にした状態で使い続けないでください。再インストール前に、サブスクリプション、オーバーライド、プロキシの選択をバックアップしてください。プログラムを再インストールしても、破損したユーザーデータが削除されるとは限りません。問い合わせ時は、クライアントとコアのバージョン、OS情報、再現手順、機密情報を伏せたログを添えてください。サブスクリプションの認証情報は含めないでください。