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

GUIクライアントはサブスクリプションのインポート、メニュー操作、システムプロキシ、ログ表示を担当し、コアはプロトコル接続、DNS処理、ルール判定を担います。ClashXはmacOS向けクライアントの名称であり、同名のクライアントや派生版がすべてmihomoコアを使っているとは限りません。互換性の問題を調べる際は、まず「このアプリについて」の画面や起動ログで実際のコアを確認し、設定の対応範囲を調べてください。画面を変更してもコアが変わるとは限らず、コアを入れ替えても旧クライアントで新機能を管理できるとは限りません。

クライアントは接続や通信の振り分け機能を提供し、設定ファイルにはノード、プロキシグループ、DNS、ルールなどの実際の設定が含まれます。インストーラーだけで利用できる設定がなければ、通常プロキシ接続は確立できません。信頼できるサービスから提供されたサブスクリプションURLを用意するか、自分で管理しているYAMLファイルをインポートしてください。インポート後はその設定を選択し、プロキシグループも確認します。サブスクリプションURLにはアカウント認証情報が含まれる場合があるため、公開フォーラムやスクリーンショット、オンライン変換サービスに貼り付けないでください。このサイトのクライアントインストール案内は、ノードサービスの提供を意味するものではありません。

普段はルールモードを選び、ルールに従って通信を順番に判定させます。グローバルモードでは通常、コアに届いた通信をグローバルプロキシグループに渡しますが、そのグループで利用可能なノードを選ぶ必要があります。DIRECTモードでは通信を直接接続します。モードが決めるのは、コアが受け取った通信の処理方法です。すべてのアプリの通信がプロキシに届くわけではありません。アプリの通信が接続一覧にまったく表示されない場合は、モードを何度も切り替えるのではなく、システムプロキシ、アプリ独自のプロキシ設定、またはTUNによる取り込みを確認してください。

mixed-portは、クライアントがローカルで待ち受けるHTTP・SOCKS共用ポートです。7890はよく使われる例であり、すべての環境で固定されているわけではありません。ノードのポートはリモートサーバー側のもので、ノード設定によって決まり、ローカルポートとは別です。ブラウザーやコマンドラインにローカルプロキシを設定する場合は、クライアントが現在待ち受けているアドレスとポートを指定します（例：127.0.0.1、7890）。画面上の設定やオーバーライドによって設定ファイルの値が上書きされている場合は、実行中のポート画面と起動ログを確認してください。

接続できるのは、設定形式に互換性があり、サーバーが稼働しているノードに限られます。無料だからといって、信頼できる、または継続して使えるとは限りません。公開サブスクリプションは複数人で共有されていたり、速度制限や突然の停止があったりするほか、現在のコアに対応しない設定が含まれることもあります。インポート前に配布元を確認し、アカウント情報を含むサブスクリプションを見知らぬ変換サービスに送信しないでください。接続後も、ウェブサイトのHTTPS証明書検証は有効にしておきましょう。ノードを使うために出所不明のルート証明書をインストールしたり、クライアントのインストール成功をノードの品質の証明とみなしたりしないでください。

クライアントの設定またはサブスクリプション画面でURLからのインポートを選び、URL全体を貼り付けて保存します。ローカルファイルはファイルのインポート機能から読み込みます。メニュー名はクライアントによって異なります。ClashXではメニューバーの設定メニューから設定を管理できます。ダウンロード後に該当する設定を選択し、プロキシグループにノードが含まれていることを確認してから、システムプロキシを有効にし、接続確認用のサイトにアクセスしてください。ダウンロード履歴だけがありノードが表示されない場合は、選択中の設定と取得内容の形式を確認します。すぐにポートを変更したりTUNを有効にしたりする必要はありません。

まずログに表示された行番号とエラーの種類を確認し、その行と前後数行のインデント、コロン、リスト記号を調べます。YAMLのインデントにはスペースを使い、タブを混在させないでください。特殊文字を含む文字列は適切に引用します。応答の先頭にHTMLタグ、ログイン案内、アクセス拒否のメッセージがある場合、取得できたのは設定ファイルではありません。インデントを直しても解決しません。編集前に元ファイルを保存し、一度に一か所だけ変更して再読み込みしてください。サブスクリプションが出力する設定形式が、現在のコアに対応しているかも確認しましょう。

まず、使用中のクライアントがTUNに対応していることを確認し、設定画面の案内に従ってサービスコンポーネントをインストールまたは修復します。Windowsでは通常、管理者権限でサービスをインストールする必要があります。macOSでは補助コンポーネントの許可、Linuxでは適切なネットワーク管理権限が必要な場合があります。すべてのファイルのアクセス権をむやみに緩めないでください。許可した後はログを確認し、仮想ネットワークアダプターの作成とルート設定が成功したかを確認します。解決しない場合は、他のVPNやTUNクライアントを終了し、ログに記録された具体的なエラーを確認してから続けてください。

起動時の自動起動は、通常クライアントを起動する設定であり、システムプロキシやTUNを自動で有効にする設定とは別です。ログイン時の起動、起動後のプロキシ有効化、サービスモード、選択中の設定をそれぞれ確認してください。Windowsではタスクマネージャーのスタートアップアプリ、macOSではシステム設定のログイン項目と機能拡張を確認します。起動時にネットワークがまだ使えないと、サブスクリプションの更新に失敗する場合があります。利用可能なローカル設定を手元に残し、ネットワーク復旧後に手動で更新してください。起動のたびに設定を再ダウンロードする運用は避けましょう。

まずサブスクリプションURL、自分で構築したノード、互換性を確認済みのルールを移行します。アプリのデータフォルダー全体をそのままコピーしないでください。システムプロキシの状態、サービスコンポーネント、TUNアダプター、画面上のオーバーライドはクライアント固有の場合が多く、YAMLをコピーするだけでは移行できません。旧クライアントとそのシステムプロキシを停止してから、新しいクライアントに設定をインポートし、ポートとプロキシグループ名を確認して接続をテストします。新しい環境が安定したことを確認してから旧データを削除し、複数のクライアントが同時にルートを変更したり、同じポートを取り合ったりしないようにしてください。

ルールは上から順に判定されます。カスタムルールは、先に一致する広範なルールやMATCHより前に配置してください。たとえばDOMAIN-SUFFIX,example.com,DIRECTは、そのドメインとサブドメインを直接接続する設定です。適用先には組み込みのポリシー、または既存のプロキシグループ名を指定し、大文字・小文字も確認します。クライアントのオーバーライド機能や永続ルールの設定箇所を使うのがおすすめです。リモートサブスクリプションから生成されたファイルを直接編集すると、次回の更新で変更が失われることがあります。保存後に再読み込みし、接続詳細で適用されたルールを確認してください。

まず各端末を、相互に通信できる信頼済みのLANに接続します。パソコンのクライアントでLAN接続を許可し、他の端末からアクセスできるアドレスで待ち受けていることを確認してください。次にスマートフォンやテレビのプロキシ設定に、パソコンのLAN内IPアドレスと実際の混合ポートを入力します。127.0.0.1は指定しないでください。パソコンのファイアウォールでは、必要なローカルネットワークに限ってポートを許可し、公共のネットワークには公開しないようにします。プロキシを利用するかどうかは各アプリの実装にも左右され、手動のHTTPプロキシではすべてのUDP通信を取り込めないのが一般的です。

多くのコマンドラインツールはデスクトップのシステムプロキシを参照しないため、プロキシオプションや環境変数を個別に設定する必要があります。curlなら、curl -x http://127.0.0.1:7890 https://example.comを実行して明示的なプロキシ接続をテストできます。ポートはクライアントで実際に使用している値に置き換えてください。テストに成功したら、ツールがHTTP_PROXY、HTTPS_PROXY、ALL_PROXYに対応しているか確認します。環境変数が影響するのは、その変数を読み込むプロセスだけです。起動済みのターミナルやバックグラウンドサービスは再起動が必要な場合があります。テスト用の設定を削除するときは、環境変数も忘れずに削除してください。

AppContainerで分離された一部のアプリは、ローカルのループバックプロキシに直接アクセスできません。まず、同じポートを使ってブラウザーが接続できることを確認します。次にクライアント付属のUWPループバックツールを使い、必要なアプリだけにループバックの例外を設定してください。ツールの実行に管理者権限が必要な場合があります。クライアントに機能がない場合は、WindowsのCheckNetIsolationツールで該当パッケージの例外設定を確認できます。すべてのアプリに一括で許可しないでください。原因がDNS、アプリへのログイン、ファイアウォールの場合、ループバックの例外を設定しても解決しません。

サービス提供元が管理するノードと、ローカルで継続利用する設定は分けて管理します。クライアントがオーバーライド、設定のマージ、スクリプト処理に対応している場合は、mixed-port、DNS、カスタムルールを適切な永続設定の場所に置き、最終的に生成された実行設定を確認してください。設定のマージ順や配列の扱いはクライアントごとに異なり、ルールが自動で追加されるとは限りません。初回設定後にサブスクリプションを手動更新し、ノードが更新されてもローカルの変更が残っていることを確認します。永続化機能がないクライアントでは、独立した設定をバックアップし、管理方法を明確にしてください。

まず設定画面で、どのサブスクリプションの更新に失敗したかを確認し、ログのステータスコードを調べます。401や403は認証、期限切れ、アクセス制限が関係する可能性があり、404はURLが変更された可能性がありますが、ステータスコードだけで原因を断定することはできません。URLが完全か、アカウントが有効か、取得した内容が互換性のある設定形式かを確認してください。更新時の通信が現在のプロキシに依存する場合もあるため、クライアントの直結更新機能も試します。そのサブスクリプションだけ失敗する場合は提供元に問い合わせ、すべて失敗する場合はローカルネットワーク、DNS、システム時刻を優先して確認してください。

タイムアウトは、現在のテストが制限時間内に完了しなかったことを示すだけです。ローカルネットワーク、DNS、テスト先URL、プロトコル設定、サーバーの状態などが原因として考えられます。まず同じサブスクリプション内の別ノードに切り替え、次に別のネットワークでも試し、そのノード経由でテスト先URLにアクセスできることを確認してください。遅延テストに失敗してもウェブページを開ける場合は、テスト先URLの設定を確認します。すべてのノードと直接接続が失敗する場合は、まず通常のネットワーク接続を復旧してください。ログに認証失敗がある場合はサブスクリプションと認証情報を確認し、接続タイムアウトの場合はサーバーへの到達性を調べます。異なる種類のエラーを混同しないでください。

まず、クライアントの接続一覧にブラウザーからの通信が表示されるか確認します。表示されない場合は、システムプロキシのアドレスと実際の待ち受けポートが一致しているか確認し、システム設定を上書きするブラウザー拡張機能を無効にしてください。通信が表示されるのに直接接続される場合は、適用されたルールとポリシーを確認し、DIRECTになっていないか調べます。ブラウザーが使うHTTPプロキシと、取り込まれていない他の通信も区別してください。明示的なプロキシコマンドでローカルポートをテストできます。ポートに接続できない場合は、コアの起動失敗やポートの競合を先に解決してください。

まずTUNを無効にし、通常のネットワーク接続が復旧することを確認してから、一つずつ調べます。ルート設定を次々に追加・変更しないでください。エラーログを保存し、別のVPN、仮想ネットワークアダプター、セキュリティソフトが同時に通信を制御していないかを確認してから、DNSと自動ルート設定を調べます。IPアドレスには接続できてもドメイン名を解決できない場合は、DNSの待ち受け、上流DNSへの到達性、ルーティングループを重点的に確認してください。必要であればクライアントを正常に終了してネットワークに再接続します。それでも復旧しない場合は、端末を再起動してください。管理対象の業務端末では管理者のポリシーに従い、システムのネットワークアダプターを独断で削除しないでください。

終了後にネットワークへ接続できない場合は、システムプロキシにローカルアドレスが残っていないか確認して無効にし、ターミナルの環境変数とブラウザー拡張機能も確認してください。証明書警告は別の問題です。まずシステムの日付と時刻を合わせ、証明書の発行者とアクセス先ドメインを確認し、HTTPS検査やMITMの設定がないか調べます。警告を無視して続行したり、出所不明のルート証明書をインストールしたりしないでください。特定のノードだけで警告が表示される場合は、そのノードの使用を中止してサービス提供元に連絡します。直接接続でも同じエラーが出る場合は、端末またはウェブサイト側の問題を調べてください。