Clash よくある質問

Clash はルールベースで通信を振り分けるプロキシクライアントの総称で、ドメイン・IP の所属地域・プロセスなどの条件に応じて通信を別々の出口へ振り分けるのが核心機能です。従来の VPN が全通信を一本のトンネルに通すのに対し、Clash では一部を直接接続、一部をプロキシ経由、一部を遮断するといった細かい制御ができ、通信効率と柔軟性に優れます。現在主流のクライアントはほぼ Mihomo カーネルを採用しています。

ルールモードは設定ファイル内のルールを順に照合し、条件に一致した通信を振り分ける方式で、通常はこれを既定にします。グローバルモードは全通信を現在選択中のノードに流すモードで、ルールが一時的に機能しない場合や全通信をプロキシ経由にしたい場合に向いています。直接接続モードは全通信をプロキシを経由させずに流すモードで、トラブル調査や一時停止時によく使われます。基本的にはルールモードのままで問題ありません。3つのモードの詳しい比較はテックノートのモード比較記事をご覧ください。

サブスクリプションリンクは、ノード情報とルールを含む設定データを指す URL で、利用しているサービス提供元のユーザーパネルから取得します。クライアントはこのリンクから設定を取得・定期更新するため、ノードが変更されても手作業での更新は不要です。サブスクリプションリンクはアカウント情報と同等に扱うべきもので、フォーラムやチャットグループに公開して貼らないようにしてください。

Mihomo(旧名 Clash Meta)は実際のプロキシ処理・通信振り分け・DNS 処理を担うコマンドラインカーネルです。Clash Plus、Clash Verge Rev、FlClash などの GUI クライアントは、このカーネルを包む操作画面で、サブスク管理やシステムプロキシの ON/OFF、ノード選択の可視化などを担います。一般ユーザーは GUI クライアントを導入すれば十分で、カーネル単体のダウンロードはサーバーやルーター用途が主です。入手先はダウンロードページのカーネルセクションを参照してください。

Clash for Windows は元リポジトリがアーカイブされ、更新が停止しています。新しい設定項目やプロトコルに対応できない可能性があります。Windows では Clash Plus または Clash Verge Rev への移行を推奨します。いずれも Mihomo カーネルをベースにしており、現行のサブスク形式に対応しています。移行時は新しいクライアントでサブスクリプションリンクを再度読み込むだけで済み、サブスク自体を変更する必要はありません。インストーラーの入手はダウンロードページの Windows セクションからどうぞ。

オープンソースクライアントのインストーラーを初めて実行すると、SmartScreen が「Windows によって PC が保護されました」と表示することがあります。これは商用の署名証明書を購入していないアプリに対する一般的な警告で、具体的な問題が検出されたわけではありません。「詳細情報」をクリックし、続けて「実行」を選べばインストールを続行できます。実行前には、インストーラーが本サイトのダウンロードページや対象プロジェクトの公式配布元から入手したものであることを確認してください。

これは Gatekeeper が App Store 以外から配布されたアプリに隔離属性を付与するために起こる現象です。まず「システム設定 → プライバシーとセキュリティ」の下部にある「このまま開く」を選択します。この項目が見当たらない場合は、ターミナルで xattr -cr /Applications/クライアント名.app を実行して隔離属性を解除してから再度開いてください。あわせて Apple Silicon 用と Intel 用のインストーラーを間違えていないかも確認しましょう。アーキテクチャの取り違えも起動失敗の原因になります。

基本的な流れは次のとおりです。サービス提供元から発行された URL をコピーし、クライアントの「サブスク/設定」ページを開いて「新規追加」または「インポート」を選択、URL を貼り付けて確定します。クライアントが設定を取得したら、一覧からそれを有効化します。導入に成功すると、プロキシページにノードグループの一覧が表示されます。プラットフォームごとの詳しい操作は使い方ガイドを参照してください。

iOS 版クライアントは App Store から配布されており、まず候補となるのは Clash Plus(公式サイト clashplus.io)です。本サイトのダウンロードページ内 iOS セクションに App Store へのリンクを掲載しています。インストール後は「サブスク導入 → ノード選択 → 接続を有効化」の3手順で、他プラットフォームと同様です。初回有効化時に VPN 構成の追加を求められるので、指示に従って許可してください。

2016 年以降に発売された主流スマートフォンはほぼすべて arm64 アーキテクチャなので、容量が小さい arm64 版を優先しましょう。デバイスのアーキテクチャが分からない場合や、エミュレーターや古い端末にインストールする場合は、複数アーキテクチャのライブラリを含み互換性が高い universal 版を選んでください。インストール時に「不明な提供元のアプリ」と表示された場合は、設定でブラウザやファイル管理アプリにインストール権限を許可する必要があります。

システムプロキシは OS に対して HTTP/SOCKS プロキシの入口を伝えるだけの機能で、これに従うブラウザやアプリはプロキシを経由しますが、システムプロキシを読み取らないプログラム(一部のゲームやコマンドラインツールなど)には影響しません。TUN モードは仮想ネットワークアダプタを作成し、ネットワーク層で全通信を横取りするため、カバー範囲が最も広くなります。通常のブラウジングではシステムプロキシで十分で、システムプロキシに対応しないアプリに遭遇したときに TUN モードを使うのがおすすめです。

主要なクライアントはいずれもサブスクごとの更新間隔設定に対応しています。サブスク項目の編集画面で「自動更新」または「更新間隔」を探し、時間数(よく使われるのは 12 または 24)を入力します。あわせて手動更新の習慣も残しておき、ノード変更の通知を受けたらすぐに手動更新するようにしましょう。自動更新が長期間失敗する場合は、トラブル解決分類のサブスク更新に関する項目を参照してください。

プロキシページにある遅延テストボタン(通常は雷アイコンや循環矢印アイコン)をタップすると、クライアントがテスト先にリクエストを送り、ミリ秒単位の値を表示します。この数値はハンドシェイクの遅延を示すもので、帯域幅とは異なります。単に数値が最も低いノードを選ぶより、遅延が安定していて振れの少ないノードを選ぶほうが信頼性が高い傾向があります。グループタイプが url-test の場合、クライアントが自動的に遅延最小のノードを選択します。

多くのコマンドラインツールはプロキシの環境変数を読み取ります。既定の混合ポート 7890 を例にすると、ターミナルで export https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890 を実行すれば、そのセッション内の curl や git などがプロキシ経由になります。Windows の PowerShell では $env:https_proxy を使って設定します。ポート番号はクライアントの設定ページに表示される実際の値に合わせてください。

クライアントのルール設定またはオーバーライド設定に、優先度の高い直接接続ルールを追加します。例えば DOMAIN-SUFFIX,example.com,DIRECT と記述すれば、そのドメインはプロキシを経由しなくなります。多くのクライアントには「ルールオーバーライド」や「カスタムルール」の画面が用意されているので、サブスクの元ファイルを直接編集しないようにしましょう。手動で編集した箇所はサブスク更新時に上書きされてしまいますが、オーバーライドルールなら更新後も維持されます。

次の3段階で確認します。まず、サブスクリプションの URL をブラウザで直接開いてみて、404 や期限切れの表示が出たらリンクが失効しているので、サービス提供元のパネルでリセットして新しいリンクに差し替えます。次に、現在のネットワークがサブスクのドメインをブロックしている可能性があるため、まず使用可能なノードに接続し、更新方式を「プロキシ経由で更新」に切り替えて再試行します。最後に、一部のサービス提供元はリクエストの UA を検証しているため、クライアントのサブスク UA を clash またはサービス提供元が指定する値に設定してください。

まずクライアントのログで通信が流れているか確認します。リクエストの記録があればプロキシ経路自体は機能しており、問題の大半はノード側にあるので、遅延が正常なノードに切り替えて再試行します。次にブラウザに他のプロキシ拡張機能が入っていて設定を横取りしていないか確認します。さらにシステムプロキシのポートとクライアントのリスニングポート(既定では多くの場合 7890)が一致しているか確認してください。ログに通信が全く記録されていない場合は、システムプロキシのスイッチが正しく反映されていないことが多いので、いったんオフにして再度オンにするか、TUN モードに切り替えてみてください。

TUN モードは仮想ネットワークアダプタの作成が必要です。Windows では管理者権限でクライアントを起動するか、設定でシステムサービスをインストール(または再インストール)してから再試行してください。macOS では初回有効化時にネットワーク拡張機能の許可を求めるダイアログが表示されるので、「システム設定 → プライバシーとセキュリティ」で許可する必要があります。Linux ではプログラムに CAP_NET_ADMIN 権限を付与するか、root 権限で実行してください。有効化後にネットに接続できない場合は、TUN スタックを system と gvisor の間で切り替えて試してみてください。

Windows は既定で UWP アプリによるループバックアドレスへのアクセスを禁止しており、これが原因で 127.0.0.1 上のプロキシポートを利用できません。クライアントの設定内にある「UWP ループバック除外」または「Loopback」ツールを探し、対象アプリにチェックを入れて保存してください。クライアントにこのツールが搭載されていない場合は、TUN モードへの切り替えも有効です。TUN モードはネットワーク層で通信を処理するため、ループバックの制限を受けません。

全ノードがタイムアウトする場合、単一ノードの問題であることは少ないです。まず、直接接続を使わないサイトを開いてみて、通常のインターネット接続自体に問題がないか確認します。次に、サブスク全体が期限切れになっている可能性があるので、まずサブスクを更新します。さらに、遅延テストの宛先が現在のネットワークで干渉を受けている可能性があるため、設定で http://www.gstatic.com/generate_204 のような標準的なアドレスに変更してみます。最後に、システムのファイアウォールやセキュリティソフトがクライアントのプロセスをブロックしていないか確認し、必要であれば許可ルールを追加してください。

3段階の順序で確認します。まず異なる地域のノードを2〜3個切り替えて比較し、特定のノードだけ遅い場合はそのノードを変更します。多くのノードがピーク時に同時に遅くなる場合は回線の混雑が原因である可能性が高く、別のプロトコルや通信方式のノードを試してみてください。それでも遅い場合はローカル設定を確認します。不要なルールセットを無効化する、DNS を変更する、複数のプロキシを重ねて使用していないかを確認するといった対応が有効です。段階的な調査手順の詳細はテックノートの通信速度診断記事をご覧ください。