Clashのよくある質問

クライアントは設定の読み込みや画面操作、システムとの連携を担当します。mihomoコアはプロキシポートの待ち受け、DNSの名前解決、振り分けルールの適用を行います。サブスクリプションは、サービス提供元から設定やノード情報を受け取るためのものです。クライアントをインストールしただけでは、利用できるノードが手に入るわけではありません。また、サブスクリプションを読み込んでも、アプリの通信が自動的にコアを通るとは限りません。初めて使うときは、設定が有効になっていること、プロキシグループで利用可能な出口を選んでいることを確認してから、システムプロキシまたはTUNを有効にしてください。この3つの役割を分けて考えると、アカウントの期限切れをインストール失敗と誤認したり、システムプロキシの問題をノード障害と取り違えたりせずに済みます。

普段はruleモードを選びます。コアはrulesを上から順に照合し、接続を該当するポリシーに振り分けます。globalモードでは接続がGLOBALポリシーに渡されますが、実際に選択されている出口の確認が必要です。directモードでは接続先に直接つなぎます。グローバルモードにしても、コアを経由していないアプリの通信が自動的に取り込まれるわけではなく、無効なノードが復旧するわけでもありません。特定のサイトが想定どおりに振り分けられない場合は、接続履歴で一致したルールと最終的なポリシーを確認してから、ルールやプロキシグループを調整してください。出口を確認せずにモードだけを切り替えると、振り分けの問題とノードの接続可否を混同しやすくなります。

公開ノードは、稼働状況や運営元、データの取り扱いを確認しにくいため、重要なアカウントや業務での利用は避けてください。HTTPSは通常の暗号化通信を保護しますが、クライアントや証明書、サービスの提供元が信頼できるかどうかを判断する代わりにはなりません。サブスクリプションURLにはアカウント情報やアクセス資格情報が含まれることが多く、機密情報として管理してください。公開フォーラムへの投稿、スクリーンショットへの掲載、見知らぬ変換サイトへの入力は避けましょう。トラブルの相談に必要なのは、資格情報を削除したエラー情報と設定項目の構造です。URLが漏えいした場合は、サービス提供元のアカウントページからサブスクリプションURLを再発行し、クライアントの設定も更新してください。

サブスクリプションURLや標準的なYAML設定は移行できることが多いものの、旧クライアントの設定をすべてそのまま取り込めるとは限りません。必要なプロトコルに対応し、現在もメンテナンスされているクライアントを選び、サブスクリプションを再読み込みします。そのうえで、プロキシグループやルール、ノードのプロトコルが現在のコアで利用できるか確認してください。旧クライアントの画面設定、サービスのインストール方法、スクリプト、上書き設定などは個別に再構築が必要な場合があります。移行時は旧クライアントを終了し、システムプロキシとバックグラウンドサービスを停止してから新しいクライアントを起動してください。2つのプログラムがポートを取り合ったり、プロキシ設定を繰り返し変更したりするのを防げます。元の設定をバックアップし、正常に接続できることを確認してから旧環境を削除しましょう。

コピーしたURLがアカウントページではなく、完全なサブスクリプションURLであることを確認し、空白や改行が混入していないかもチェックしてください。次にクライアントの更新ログを確認します。401や403は認証やアクセス制限、404はURLの変更を示すことがあります。更新が成功しても解析できない場合は、取得内容がログインページ、エラーページ、または非対応形式ではないか確認してください。アカウントの期限切れや通信量の上限到達、サービス提供元によるURLの変更が原因で、サブスクリプションを利用できなくなることもあります。更新にプロキシが必要な場合は、クライアントが対応していれば、利用可能な出口を指定してください。設定を何度も上書きせず、最後に使えた設定を保存してから、サービス提供元にURLの状態を問い合わせましょう。

エラーの行番号を参考に、インデント、コロンの後のスペース、リストの階層を確認してください。インデントにはスペースを使い、タブを混在させないようにします。行番号はエラーが検出された場所を示しているだけで、原因が1行前にあることもあります。ノード名やパスワードに特殊文字が含まれる場合は、YAMLの構文に従って引用符で囲んでください。構文に問題がないのに未知の項目や未対応のプロキシタイプが表示される場合は、インデントを直し続けるのではなく、クライアントが実際に使用しているコアと、そのバージョンの対応状況を確認します。設定のバックアップを使い、最近の変更を少しずつ戻してください。一度に変更するのは1か所だけにし、読み込みに成功したことを確認してから次の項目を追加しましょう。

mixed-portは同じポートでHTTPとSOCKSのプロキシ接続を受け付けます。portはHTTPプロキシ用、socks-portはSOCKSプロキシ用です。アプリには対応するプロキシプロトコルに合わせてアドレスとポートを設定してください。ポート番号が同じというだけで、設定が正しいとは限りません。mixed-port: 7890の場合、通常はローカルのアプリから127.0.0.1:7890に接続しますが、実際のポート番号は現在読み込まれている設定を確認してください。address already in useが表示された場合は、まずポートを使用しているプロセスを特定し、古いインスタンスを終了するかポートを変更します。変更後は、システムプロキシ、ブラウザー拡張機能、ターミナルの環境変数も更新してください。

TUNは仮想ネットワークインターフェースを作成し、ルーティングを変更するため、通常は適切なシステム権限が必要です。ただし、クライアント全体を常に管理者として実行しなければならないとは限りません。一部のクライアントはサービスをインストールして、権限が必要な処理をそのサービスに任せます。具体的な方式はプラットフォームや実装によって異なります。まずサービスがインストールされ、実行中か、仮想インターフェースが作成されているかを確認し、ログに権限やルーティングのエラーがないか調べてください。ほかのVPNと同時に使用すると、インターフェースやルートが競合することがあります。比較のため、別のネットワーク制御ソフトを一時的に終了してみてください。権限エラーを解決するためにファイアウォールを常時無効にするのではなく、サービスの状態や許可設定、具体的な競合を修正しましょう。

速度テストで確認できるのは、通常、指定されたテスト先へのリクエスト結果だけです。すべてのWebサイトやプロトコル、ポートが利用できることを保証するものではありません。まず、失敗した通信がコアに届いているか、最終的に適用されたプロキシグループでテストしたノードが選ばれているかを確認してください。次に、対象ドメインの名前解決、ノードからサイトへの接続可否、サーバー側の制限をそれぞれ調べます。以前のテスト結果を参照している場合は、再テストして対象サイトにも実際にアクセスしてください。動画、ゲーム、音声だけに問題がある場合は、UDP対応と振り分け設定も確認します。速度順だけを見てノードを頻繁に切り替えるのは避け、同じ接続先とネットワーク条件で比較しましょう。

更新時に置き換えられるリモート設定の本文に、長期間使うルールだけを書き込まないでください。クライアントの上書き、マージ、拡張設定機能を利用して、個人用ルールをリモートサブスクリプションと分けて保存し、マージの順序も確認します。ルールは通常、最後の受け皿となるMATCHより前に置く必要があります。そうでないと、先に接続がMATCHに一致することがあります。また、参照するプロキシグループ名が最終的な設定に存在することも確認してください。配列を追加、先頭に挿入、置換する動作はクライアントによって異なります。更新後はエディターの一部だけでなく、実際に動作中の設定を確認しましょう。初期設定後にサブスクリプションを手動で更新し、ルールが引き続き適用されることを確かめてください。

まず、2台のデバイスがLAN内で相互に通信できることを確認します。次にallow-lanを有効にし、bind-addressでLAN側インターフェースからの接続が許可されているか確認してください。もう一方のデバイスには、PCのLAN内IPアドレスをプロキシのアドレスとして設定します。127.0.0.1は指定しないでください。ポートには、現在待ち受けているHTTPまたは混合ポートを入力します。PCのファイアウォールで、信頼できるネットワークに限ってそのポートが許可されているか、無線アクセスポイントでクライアント分離が有効になっていないかも確認しましょう。待ち受けを許可するのは信頼できるネットワークだけにし、必要に応じてプロキシ認証を設定してください。プロキシポートをインターネットに公開しないでください。HTTPプロキシの設定だけでは、デバイス上のすべての通信がプロキシ経由になるとは限りません。

多くのコマンドラインツールは、デスクトップのシステムプロキシを自動的に参照しません。ツール固有のプロキシオプションや環境変数を設定する必要があります。まずcurl -x http://127.0.0.1:7890 https://example.comを実行して接続を確認できます。ポートは現在の待ち受けポートに置き換えてください。この方法で接続できたら、ターミナルやツールのドキュメントに従ってhttp_proxy、https_proxy、またはALL_PROXYを設定し、no_proxyで接続先が除外されていないか確認します。環境変数が影響するのは通常、設定したプロセスとその子プロセスです。開いたままのターミナルは再起動が必要な場合があります。HTTPSの接続先にローカルのHTTPプロキシを使う場合も、プロキシのアドレスにはhttp://を指定できます。

すべてのノードがタイムアウトする場合は、まずローカルネットワークから通常のWebサイトへ直接接続できるか確認します。次に、サブスクリプションの更新が成功していること、アカウントが有効であること、正しい設定がクライアントに読み込まれていることを確かめてください。その後、システム時刻、ノードのドメイン名解決、ポートへの接続、ログに記録されたプロトコルエラーを確認します。別のネットワークで同じノードを試すと、ローカルネットワークの制限とサービス側の障害を切り分けられます。一部のノードだけがタイムアウトする場合は、サーバーアドレス、ポート、プロトコルの設定、サービスの稼働状況を優先して比較してください。DNS、TUN、ノード設定を同時に変更すると、原因を特定できなくなります。エラーが発生した時刻と、資格情報を除いたログを保存し、サービス提供元に該当する出口の状態を問い合わせましょう。

システムプロキシの接続先アドレスとポートが、コアの待ち受け設定と一致しているか確認し、コアが実行中であることも確かめてください。次に、ブラウザーのプロキシ拡張機能、独自のプロキシ設定、組織のポリシーによって設定が上書きされていないか確認します。競合する拡張機能を一時的に無効にし、同じURLに再度アクセスしてください。特に役立つのはクライアントの接続履歴です。該当する接続が記録されていない場合は、通信の入口を確認します。接続が記録されていてもDIRECT経由なら、ルールとポリシーの選択を確認してください。プロキシ経由で接続して失敗する場合は、ノードとDNSを調べます。システムプロキシを変更するほかのプログラムは終了し、設定が繰り返し上書きされないようにしましょう。TUNを有効にする前に原因を特定し、あらゆる問題に対する既定の解決策として使わないでください。

アプリコンテナーを使う一部のWindowsアプリは、既定ではローカルのループバックアドレスにアクセスできません。そのため、ブラウザーが正常でも、これらのアプリが127.0.0.1のプロキシを利用できるとは限りません。まずアプリがシステムプロキシを参照していることを確認し、クライアントのループバック免除機能を使って必要なアプリだけに許可を与えてください。システムツールの使い方を理解している場合は、既存の免除リストを確認する方法もあります。操作には管理者権限が必要なことがあり、アプリによってネットワークの実装も異なります。すべてのアプリに一律で許可を与えないでください。設定後は対象アプリを完全に終了して再起動し、接続履歴も確認します。それでも接続できない場合は、アプリ側のサービスやアカウントの状態、振り分けルールを調べてください。

問題を隠すためにDNSを無効にするのは避けてください。Fake-IPはドメインに合成アドレスを割り当てるため、実際のIPアドレスを必要とするLANサービスやアプリには例外設定が必要な場合があります。まず、LAN内のドメインをどのDNSサーバーで解決するか確認し、fake-ip-filterとnameserver-policyを使って該当ドメインをフィルターするか、特定の名前解決経路を指定してください。redir-hostに切り替えるだけでは、ルーティングやキャッシュ、マルチキャストによるデバイス検出の問題が解決するとは限りません。設定変更後は関連するDNSキャッシュを消去し、影響を受けるアプリを再起動して、名前解決の結果と接続履歴を確認します。デバイス検出がマルチキャスト通信を使う場合は、ネットワーク分離やTUNのルーティングも別途確認してください。ドメインの名前解決だけを調整しても解決しません。