Clashのよくある質問

Clashは、プロキシコアとその設定エコシステムを指す名称として広く使われています。mihomoは、このエコシステムで継続的に開発されているコアプロジェクトです。Clash Verge RevやFlClashなどのクライアントはGUIを提供し、設定の読み込み、システムプロキシ、コアプロセスの管理を担います。ルールの解析や接続を実際に行うのはコアです。トラブル対処の際は、「バージョン情報」や「コア」の画面で、クライアント名とコアのバージョンをそれぞれ確認してください。画面が似ていても、同じ設定に対応しているとは限りません。特にTUN、DNS、プロトコル関連の項目には注意が必要です。ダウンロード時は端末のOSに合ったクライアントを選び、設定を変更する前に、インストーラーの名前だけでなく実行中のコアを確認しましょう。

利用可能なプロキシ設定が必要です。クライアントは設定を読み込み、リクエストを転送しますが、インストールするだけでリモートプロキシが使えるようになるわけではありません。通常は、利用中のサービスのアカウントページからClashまたはmihomo形式のサブスクリプションを取得し、「設定」画面から追加します。自分で管理しているYAMLファイルを読み込むこともできます。追加後は、設定が選択されているか、「プロキシ」画面にプロキシグループが表示されているか、選択したグループに利用可能な出口があるかを確認してください。サブスクリプションURLにはアカウント情報が含まれることがあるため、機密情報として扱い、スクリーンショットを共有する際はURL全体を隠しましょう。出所不明の設定を重要なアカウントで使わないでください。また、単一のノードリンクを設定ファイル全体と取り違えないようにしましょう。

普段は「ルール」を使い、リクエストをrulesの上から順に照合して、対応するプロキシグループに振り分けます。「グローバル」では、コアに入ったリクエストをすべてグローバル用のプロキシグループに送ります。ルールが原因かどうかを一時的に確認するのに便利ですが、そのグループで利用可能な出口を選ぶ必要があります。「DIRECT」では、コアに入ったリクエストを直接接続します。比較テストに使えます。モードが決めるのは、コアが受け取ったリクエストの処理方法です。システムプロキシやTUNの代わりにはならず、すべてのアプリの通信を自動的に取り込むわけでもありません。グローバルに切り替えてもWebページが開かない場合は、まずリクエストがログに記録されているか、次に出口へ接続できているかを確認してください。モードの切り替えと同時にDNSも変更すると、どの設定が影響したのか判断しにくくなります。

システムプロキシはOSのプロキシ設定を利用し、その設定に従うアプリをローカルの待ち受けポートに接続させます。TUNは仮想ネットワークインターフェースで、そこへルーティングされたIP通信を受け取るため、システムプロキシに従わないアプリに向いています。どちらも、すべての通信が必ずプロキシ経由になることを意味するものではありません。実際の動作はルーティング、アプリの仕様、ルールにも左右されます。初めて設定する場合は、まずシステムプロキシだけを有効にしてブラウザーで動作を確認し、必要に応じてTUNを有効にしてください。併用する場合は、クライアントの案内に従いましょう。トラブル対処のために、複数のプロキシクライアントやVPN、仮想ネットワークアダプターによる通信制御を一度に有効にしないでください。通信を取り込む経路を一つに絞ると、原因を特定しやすくなります。

「設定」画面で「URLからインポート」または「サブスクリプションを追加」を選び、サービスから提供されたClash形式のURLを貼り付けて保存します。ダウンロードが完了したら、その設定をクリックして現在の設定にします。次に「プロキシ」画面でプロキシグループが読み込まれていることを確認し、「ログ」画面で解析エラーがないか確認してください。リストにファイルが表示されても、設定が保存されたことを示すだけで、有効になったとは限りません。yaml: unmarshal errorsが表示された場合は、まずサブスクリプションの形式とコアの互換性を確認してください。見慣れない項目をすぐに削除するのは避けましょう。最後にシステムプロキシを有効にして対象サイトへアクセスし、接続履歴を確認します。実際に有効かどうかは、記録されたルール、プロキシグループ、出口を見て判断してください。

まずOSのプロセッサアーキテクチャを確認してから、対応するインストーラーを選びます。Windowsでは「設定 → システム → バージョン情報」でシステムの種類を確認できます。macOSでは「このMacについて」でチップを確認し、Apple Silicon搭載機は通常ARM64、Intel搭載機はx64を選びます。Androidの比較的新しい端末の多くはarm64-v8aですが、端末とインストーラーの対応状況を確認してください。Linuxではuname -mを実行します。x86_64は通常AMD64、aarch64は通常ARM64に該当します。アーキテクチャが合っていても、最低システム要件を満たしているか確認が必要です。インストールや起動に失敗した場合は、エラーメッセージをそのまま控え、まずアーキテクチャとOSバージョンの不一致を確認しましょう。インストール段階の問題を解決するために、サブスクリプションを何度も変更する必要はありません。

「自動起動」は通常、クライアントの起動を意味するだけで、コア、システムプロキシ、TUNの状態まで復元されるとは限りません。一度ログアウトして再ログインし、タスクトレイにアイコンが表示されるか確認してから、コアの状態、現在の設定、通信の取り込み設定を確認してください。Windowsでは「スタートアップ アプリ」でこのアプリが無効になっていないかも確認します。TUNを使う場合は、クライアントに必要なサービスがインストールされ、起動できることを確認してください。管理者権限でのスタートアップと通常ユーザーのスタートアップを二重に設定しないようにしましょう。ログイン直後にサブスクリプションの更新だけが失敗する場合は、ネットワーク接続後に手動で更新するか、クライアントに遅延起動の設定があれば利用してください。起動の流れを項目ごとに確認し、タスクマネージャーにプロセスが表示されているだけで接続が復旧したと判断しないでください。

まず、表示された警告がサービスのインストール、仮想インターフェースの作成、ネットワーク拡張機能の許可のどれに関するものか確認してください。Windowsクライアントに「サービスモード」や「サービスをインストール」がある場合は、案内に従ってインストールを許可し、TUNを再度有効にします。サービスの不具合を放置して、毎回管理者権限で起動する方法に頼らないでください。macOSでは実際のダイアログに応じて、システム設定で該当するネットワーク拡張機能またはVPN構成を許可します。手順はクライアントによって異なります。Linuxでは通常、/dev/net/tunへのアクセスと適切なネットワーク管理権限が必要です。プロジェクトが推奨するサービス設定を使用してください。許可した後、ログでインターフェースの作成に成功したか確認します。それでもネットワークに接続できない場合は、ルーティングとDNSを確認してください。ネットワークと関係のないディスク権限を繰り返し許可する必要はありません。

レイテンシテストで分かるのは、テスト先への接続性と応答時間が中心です。継続的な通信速度を示すものではなく、対象サイトへの通信が同じ経路を通るとも限りません。まず出口とダウンロードURLを固定し、接続履歴を見て、リクエストがルールによって別のプロキシグループに振り分けられていないか確認してください。次に、DIRECTとプロキシ、異なる出口、時間帯を比較し、ローカルネットワーク、リモート側の回線、対象サイトの速度制限を切り分けます。テスト中は他の端末による大容量通信を止め、速度テストとダウンロードが競合しないようにしましょう。特定のアプリだけ遅い場合は、そのアプリのプロキシ設定や同時接続数の制限を確認してください。レイテンシが最小のノードだけを基準に選んだり、1回のテスト結果を継続的な速度の保証と見なしたりしないでください。

まず「接続」画面で対象リクエストに適用されたルールとプロキシグループを確認し、名前が似ている別のグループではなく、実際に使われているグループを変更したか確認してください。selectグループは手動で選択できますが、url-testなどの自動グループはテスト結果に基づいて再選択されることがあります。グループが入れ子になっている場合は、選択経路を順に確認してください。既存の長時間接続は、ノードを切り替えてもすぐに移行しないことがあります。該当する接続を閉じるか、リクエストを送信したアプリを再起動してから、新しい接続で確認してください。サブスクリプションの更新でグループ構成が変わったり、選択状態がリセットされたりすることもあります。動作はクライアントが選択状態を保存するかどうかによります。トラブル対処では一度に変更するグループを一つにし、新しい接続の出口を記録してください。再利用中の古いページの接続で切り替えの成否を判断しないようにしましょう。

mixed-portはHTTPとSOCKSのプロキシリクエストを受け付ける混合待ち受けポートです。アプリの手動プロキシ設定には、このポートを指定します。external-controllerはコアを管理するAPIのアドレスで、インターネット接続用のプロキシポートではありません。7890や127.0.0.1:9090はよく使われる例ですが、実際の値は利用中のクライアントで確認してください。ログにbind: address already in useと表示された場合は、ほかのプロキシアプリを終了してからポートの使用状況を確認します。mixed-portを変更した場合は、アプリ側の手動プロキシ設定も更新してください。管理インターフェースは、まずループバックアドレスにバインドします。外部からアクセスさせる必要がある場合は、アクセス制御を設定してください。ローカルアプリから接続するためだけに、管理インターフェースをLANやインターネットに公開しないでください。

まず、影響を受けているのがアプリコンテナーで分離されたUWPアプリであり、すべてのWindowsアプリではないことを確認します。一部のアプリは初期状態でローカルのループバックプロキシにアクセスできないため、ブラウザーは使えてもストアアプリは接続できないことがあります。クライアントに「UWPループバックの免除」機能がある場合は、必要な権限でツールを開き、対象アプリだけに免除を設定してから、そのアプリを再起動して確認してください。免除で許可されるのはループバックアドレスへのアクセスです。プロキシが自動設定されるわけではなく、無効なノードも修復されません。ツールがない場合は、Microsoftのドキュメントを参考にCheckNetIsolationで指定アプリのループバック免除を設定できます。すべてのアプリに一括で許可しないでください。それでも接続できない場合は、アプリがシステムプロキシに従うか、接続ログにリクエストが記録されているかを確認します。

まず、HTTPエラーとネットワークエラーを切り分けます。401や403は、URLの無効化、アクセス制限、アカウント状態などが原因のことがあります。アカウントページでサービスの状態を確認し、ClashのサブスクリプションURLを最初から最後までコピーし直してください。404の場合は、パスをすべてコピーできているか確認します。YAML設定ではなくHTMLのログイン画面が返っている場合も、読み込み時に解析エラーが発生します。i/o timeoutの場合は、現在のネットワークとサブスクリプションのドメインに接続できるか確認してください。クライアントで更新時にプロキシを経由するか選べる場合は、DIRECTと、利用できることを確認済みのプロキシ出口をそれぞれ試します。まだ更新できていない設定にサブスクリプションの取得を依存させないようにしましょう。エラーを共有する際はステータスコードとドメインだけを残し、URL内のアカウント情報やクエリパラメーターは削除してください。

まずエラー全文を確認します。dial tcp自体は原因ではなく、TCP接続を確立する処理の情報です。後ろにi/o timeoutが続く場合は、制限時間内に接続できなかった可能性があります。connection refusedは、接続先ポートで待ち受けていない、または明示的に拒否された状態を示します。no such hostの場合は、まずドメインの名前解決を確認してください。サブスクリプションが有効か、ノードのアドレスとポートが最新か確認してから、別の出口でも試します。ルーティングの競合を避けるため、ほかのVPNは一時的に無効にしてください。すべてのノードで失敗する場合は、まずローカルネットワーク、DNS、クライアントの通信取り込み状態を確認します。特定のノードだけ失敗する場合は、該当サービスの提供元に問い合わせてください。原因の切り分けをせず、タイムアウト時間を際限なく延長したり、ファイアウォール全体を無効にしたりしないでください。

まず「接続」画面を開き、対象サイトを再読み込みします。新しいリクエストがまったく表示されない場合は、ルールではなく通信の取り込みに問題がある可能性が高いです。OSのプロキシアドレスとポートが現在のmixed-portと一致しているか確認し、次にブラウザー独自のプロキシ拡張機能やネットワーク設定が使われていないか確認してください。Firefoxなど、システム設定をそのまま使わないアプリもあります。システムプロキシ設定を上書きしないよう、ほかのプロキシクライアントは終了してください。リクエストがコアに届いているのにDIRECTと表示される場合は、システムプロキシを再起動するのではなく、適用されたルールとモードを確認します。クライアントを終了する前にシステムプロキシを無効にしてください。終了後にネット全体が切断される場合は、システムプロキシの設定から、ローカルポートを指している手動プロキシ設定を削除します。

まず、ノードのドメイン名解決の失敗と、接続先サイトの名前解決の失敗を切り分けます。ログに記録されたドメインが特定の手がかりになります。現在のdns設定を記録してから、一度に一か所だけ変更してください。使用するリゾルバーに到達できるか、リゾルバーのドメイン名自体を最初に解決できるか、DNSリクエストがほかのVPNやセキュリティソフトに横取りされていないか確認します。fake-ipを使っている場合は、仮想アドレスへの通信が正しく取り込まれているかも確認してください。キャッシュを消すだけでは、誤ったルーティングは直りません。ブラウザーで独自のセキュアDNSが有効になっている場合は、一時的にシステム設定に従う状態にして比較します。設定を修正したら、システムとアプリのキャッシュを消去して接続を作り直してください。複数の解説からDNS設定を丸ごとつなぎ合わせないようにしましょう。特に、現在のコアが対応していない項目を混在させないでください。