Clashクライアントダウンロードサイト 全プラットフォーム対応クライアントと設定リファレンス

PROFILE INPUT / YAML

サブスクリプションURL、リモート設定、ローカルYAML

Clashクライアントは通常、サブスクリプションURLから設定を読み込みますが、ローカルのYAMLファイルをインポートすることもできます。サブスクリプションURLは設定を取得するための入口であり、YAMLファイルにはポート、プロキシノード、プロキシグループ、ルール、DNSなどの具体的な内容が保存されています。初回利用時は、完全なURLを設定管理画面に追加し、クライアントの解析が完了するまで待ってから、新しい設定を現在の設定に指定してください。WebページのURLをそのままノードとして扱ったり、URLの一部を欠落させたり、通常のテキストをインポートしたりすると、設定を認識できません。

インポートに成功しても、同じURLをすぐに何度も追加しないでください。まず設定名、更新日時、プロキシグループが表示されていることを確認し、その後プロキシグループ画面でノードを選択します。リモート設定の更新では、提供元が管理する一部の内容が置き換わります。ローカルで手動編集した内容は次回更新時に上書きされる可能性があるため、長期的に保持したいルールはクライアントのオーバーライド、マージ、またはスクリプト設定に記述するのが適しています。詳しい手順は使い方ガイドで確認できます。

POLICY GROUP / PROXY

まずプロキシグループを確認し、その中からノードを選ぶ

プロキシグループは、特定の種類の接続をどのノードまたは子グループで処理するかを決めます。よくある種類には、手動選択、自動速度テスト、フォールバック、負荷分散があります。クライアントのメイン画面に表示される選択肢は、必ずしも単一のサーバーとは限らず、別のプロキシグループが含まれる場合もあります。初回接続では、主要なプロキシ通信を担う選択グループを見つけ、グループ内で利用可能なノードを選んでください。設定ファイルを切り替えただけで実際の出口が変わらない、といった状況を避けられます。

遅延テストが示すのは、その時点のネットワーク環境におけるテスト先の応答であり、ダウンロード速度、安定性、すべてのWebサイトへの接続品質を意味するものではありません。ノードの地域、回線倍率、プロトコル対応、サーバー負荷なども結果に影響します。より確実に判断するには、候補ノードをまとめてテストし、実際のWebページやアプリで接続を確認したうえで、実行ログにタイムアウト、ハンドシェイク失敗、接続拒否がないかを確認してください。ノードの選び方はサイト内のノード選定記事も参考にできます。

RULE ENGINE / MATCH ORDER

ドメイン、アドレス、最終ポリシーを順に照合

ルールモードでは、設定内のルールリストを上から確認し、条件に一致する最初のルールが見つかると照合を終了します。一般的なルール種別には、ドメイン、ドメインサフィックス、キーワード、IPアドレス範囲、プロセス名、最終マッチがあります。順序は結果に直接影響します。範囲の広すぎるルールを前に置くと、後続ルールで処理すべき接続を先に捕捉する可能性があります。最終ルールがない場合や、指定したプロキシグループ名が一致しない場合も、想定と異なる通信になることがあります。

カスタムルールを追加するときは、まず照合対象を明確にし、指定先のプロキシグループが実際に存在することを確認してください。ドメインルールは特定のホスト名に、ドメインサフィックスは同じサイトの複数のサブドメインに適しています。IP-CIDRは既知のアドレス範囲に使えますが、DNS解決をスキップするパラメータを有効にする場合は、その影響を理解しておく必要があります。サイト名だけからすべての接続先ドメインを推測せず、ブラウザの開発者ツール、DNS検索結果、Clashの実行ログを使って実際のリクエストを確認してください。詳しい構文は設定リファレンスにまとめています。

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - DOMAIN,api.example.net,Proxy
  - IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
  - MATCH,Proxy

DNS PIPELINE / FAKE IP

ドメイン解決経路とルール判定の基準を統一

DNS設定は、ドメインをどこで解決するか、名前解決のリクエストがどのネットワーク経路を通るか、そしてルールエンジンがドメイン情報を保持できるかに影響します。Fake IPモードでは、まず予約アドレスを返し、コアが接続を元のドメインに対応付けることで、ドメインルールに基づく通信処理を行いやすくします。Redir Hostは、実際のアドレスを返す従来型の名前解決に近い方式です。両方式には互換性の範囲があり、LAN機器、ゲーム、プリンター、実アドレスに依存する一部のアプリでは個別の除外が必要になる場合があります。

DNSの問題を切り分けるときは、システムDNS、ブラウザのセキュアDNS、クライアントの待受ポート、上流リゾルバーを区別してください。一か所だけ変更しても、経路全体が変わるとは限りません。まずClashのDNSモジュールが有効か確認し、次にシステムからのリクエストが対象ポートに届いているか、最後にログで名前解決と接続の記録を確認します。ドメインは解決できるのにWebページが開けない場合は、ルールの転送先、ノード接続、IPv6の動作も確認してください。すべての接続失敗をDNSのせいにしてはいけません。

NETWORK MODE / TUN

アプリごとのプロキシ設定とシステム全体の通信制御を区別

システムプロキシは、OSのプロキシ設定に従うアプリ、たとえば多くのブラウザやデスクトップソフトに主に影響します。一部のゲーム、コマンドラインツール、ストアアプリ、独自にネットワーク接続を確立するプログラムは、この設定を読み込みません。TUNモードは仮想ネットワークインターフェースを通じて、より広い範囲のTCP、UDP、DNS通信を処理します。通信を一元的に制御したい場面に適していますが、管理者権限、ルーティングテーブル、ネットワークインターフェース、セキュリティソフトとの互換性も関係します。

初回設定では、まずシステムプロキシで基本的な接続を確認し、サブスクリプション、ノード、ルールが使えることを確かめてから、用途に応じてTUNを有効にするのがおすすめです。有効化後にネットワークへ接続できなくなった場合は、まずTUNを無効にして通信を復旧し、サービスが正常に起動したか、仮想インターフェースが作成されたか、DNSハイジャック設定が現在のシステムと一致しているか、ほかのVPNや仮想NICと競合していないかを確認してください。Windowsのサービスモード、macOSのシステム拡張、Linuxの権限設定では対応方法が異なります。