用語の本文へ移動

設定項目・プロトコルの基礎・利用上の注意

Clash用語集

設定の場面ごとに用語を確認できます。まず仕組みを把握し、クライアントの設定項目、必要な権限、実際に適用された設定を確認しましょう。

よく使われる用語を25項目掲載しています。設定の理解に役立つ解説ですが、メニュー名や対応範囲は使用するクライアントとコアのバージョンによって異なります。

コアとクライアント

クライアントは操作画面、コアは接続処理を担います。機能の違いを確認するときは、両方を調べましょう。

クライアント: Client application; サブスクリプション管理、ポリシー選択、システム設定を行うアプリの画面です。デスクトップクライアントには、トレイメニュー、スタートアップ、ログを管理する機能もあります。クライアントが操作をまとめ、コアが接続を処理します。画面が似ているアプリでも、採用するコアのバージョンや設定の統合方法は異なる場合があります。選ぶ際は、OSへの対応状況、メンテナンス状況、必要な機能をそれぞれ確認してください。

mihomo: Proxy core; Clash Metaから発展したプロキシコアで、プロトコル接続、ルール判定、DNSなどを処理します。特定のGUIクライアントと同じものではありません。設定を読み込めるかどうかは、実行中のコアのバージョンと項目の対応状況で決まります。新機能の説明を見つけたら、設定を変更する前にクライアントのコア情報や起動ログでバージョンを確認してください。

Clash Meta: Historical core name; Clashエコシステムで拡張コアを指した旧称で、後にmihomoへと発展しました。そのため、古いチュートリアル、サブスクリプションの選択肢、アプリ名にはMetaが残っていることがあります。この名称だけではインストールパッケージの公開時期はわからず、現在のmihomoの機能すべてに対応しているとも限りません。古い設定を移行するときは、ファイル名やクライアントの表示名だけでなく、項目の互換性を確認してください。

TUNモード: Virtual network interface; 仮想ネットワークインターフェースを通じて通信を取り込む方式です。システムプロキシ設定に従わない一部のアプリも対象にできます。有効化には通常、管理者権限、仮想インターフェース、ルーティング、DNSの制御が関わります。対象範囲はOSとクライアントの実装によって異なります。有効化後に通信できなくなった場合は、ルートの競合、他のVPN、DNS設定を確認し、すぐにノードの障害と決めつけないでください。

システムプロキシ: System proxy settings; OSが提供するプロキシアドレスの設定で、この設定に従うアプリのリクエストをクライアントのローカル待ち受けポートへ送ります。システムプロキシを有効にしても、すべての通信がプロキシ経由になるわけではありません。ゲーム、コマンドラインツール、一部のアプリは独自のネットワーク設定を使うことがあります。クライアント終了後に通常のWebページも開けなくなった場合は、停止したポートを指すプロキシアドレスがシステムに残っていないか確認してください。

プロキシプロトコル

プロトコルの種類はサーバー側の設定と一致させる必要があります。接続状況は回線、トランスポート方式、ネットワーク環境にも左右されます。

Shadowsocks（SS）: Shadowsocks; 事前共有鍵と指定の暗号化方式を使って接続するプロキシプロトコルです。ノードには通常、サーバーアドレス、ポート、暗号化方式、パスワードが必要です。クライアントとサーバーで互換性のあるプロトコル世代と認証パラメーターを使う必要があり、種類名をSSに書き換えるだけで別プロトコルのノードが使えるようにはなりません。認証に失敗した場合は、まずサブスクリプションの内容とコアの対応状況を確認し、その後で回線の接続性を調べてください。

VMess: VMess protocol; ユーザー識別子で認証し、複数のトランスポート方式を利用できるプロキシプロトコルです。ノード設定にはWebSocket、TLS、サーバー名などが含まれる場合もあります。プロトコルの種類が同じでも、トランスポート層のパラメーターが異なれば接続に失敗します。古い設定を調べる際は、すべてのパラメーターとシステム時刻を確認してください。ノード名を比べたり、ユーザー識別子だけをコピーしたりするだけでは不十分です。

Trojan: Trojan protocol; 通常はTLS接続を利用し、パスワードで認証するプロキシプロトコルです。接続にはTLSの確立とプロトコル認証の両方が必要です。サーバー名、証明書の検証、パスワードをサーバー側と一致させてください。ポートに接続できても、ノードが使えるとは限りません。証明書エラーが出た場合は時刻、ドメイン名、証明書の設定を確認し、証明書検証の無効化を常用しないでください。

VLESS: VLESS protocol; 認証と外側の通信保護を分けた軽量なプロキシプロトコルで、単体ではデータを暗号化しません。実際のセキュリティは組み合わせるトランスポート設定によって異なります。TLS、REALITY、トランスポート方式と関連パラメーターで接続方法が決まるため、VLESSという名称だけで互換性を判断できません。インポート後に項目が無視されたり非対応と表示されたりする場合は、現在のコアがその組み合わせを実装しているか確認してください。

Hysteria 2とTUIC: QUIC-based proxy protocols; どちらもQUICベースですが、異なるプロキシプロトコルです。利用にはネットワークでUDP通信が許可されている必要があり、認証方式や設定項目に互換性はありません。パケットロスがある環境ではTCP方式と異なる挙動を示すことがありますが、どの回線でも速くなるとは限りません。選ぶ際はサーバー側の対応、ネットワークによるUDP制限、モバイル端末のバッテリー消費を考慮し、実際の用途で確認してください。

トランスポート方式の違いを比較する場合は、プロトコルとコアの技術リファレンスをご覧ください。

ルールと振り分け

ルールで接続の処理先を決め、ポリシーグループで出口を選びます。問題を調べるときは、まず実際に適用されたルールを確認してください。

ルールによる振り分け: Rule-based routing; ドメイン、IP、その他の接続属性に応じて、通信に適用するポリシーを選ぶ仕組みです。ルールは通常、上から順に判定され、最初に一致した項目で処理が決まります。そのため、具体的な条件は広い条件より上に配置するのが基本です。アプリの通信先が想定と異なる場合は、接続ログで適用されたルールを確認してから、順序や条件を調整してください。ノードを何度も切り替えるのは先決ではありません。

ポリシーグループ: Proxy group; ノードや他のポリシーをまとめ、手動選択、自動テスト、フェイルオーバーに使う集合です。ルールからグループ名を直接参照できます。これにより、用途ごとのルールと実際の接続先を分けて管理できます。ルールを変えずに、グループ内の選択だけを調整できます。ポリシーグループの種類ごとに切り替え条件は異なります。また、自動テストの結果は指定したテスト先に対するもので、すべてのアプリへの接続を保証するものではありません。

GeoIP: IP geolocation database; IPデータベースを使い、接続先アドレスを地域などに分類するルール判定の基準です。たとえばGEOIP,CN,DIRECTは、データベース内の該当アドレスに一致させます。データが古い場合や、同じサービスが複数の地域のアドレスを使う場合もあるため、すべてのドメインルールを置き換えることはできません。データを更新しても振り分けが改善しない場合は、実際の名前解決結果と、先に適用されるルールも確認してください。

GeoSite: Categorized domain datasets; サービスや用途ごとにまとめたドメインの集合で、GEOSITEルールから参照でき、ドメインを一つずつ管理する手間を減らせます。利用できる分類は読み込んだデータファイルによって異なり、すべてのデータソースに同じ分類があるとは限りません。ドメインの分類を扱うもので、GeoIPによるアドレス分類とは別です。分類が見つからない場合は、データソースと更新ログを確認してください。

DIRECT・REJECT・MATCH: Actions and catch-all rule; DIRECTとREJECTは処理ポリシーで、それぞれ直接接続と接続拒否を意味します。MATCHは残りの通信に一致させるルール種別で、通常は末尾に配置します。例のMATCH,PROXYでは、PROXYは通常、設定内で任意に定義するポリシー名であり、自動的に存在するノードではありません。参照する名前は設定内の定義と一致させてください。

ネットワークとDNS

名前解決、通信の取り込み、ノードへの接続はそれぞれ別の段階です。個別に確認しましょう。

DNS: Domain Name System; ドメイン名をネットワークアドレスなどに変換する仕組みです。アプリは通常、名前解決の結果を得てから接続します。クライアントのDNS設定はリクエストの経路や結果、一部のルール判定に影響しますが、リゾルバーを変更してもノードの帯域幅は直接向上しません。ドメインには接続できないのにIPアドレスには接続できる場合は、名前解決ログ、キャッシュ、アプリ独自のDNS設定を優先して確認してください。

Fake-IP: Synthetic address mapping; コアがアプリに合成アドレスを返し、そのアドレスとドメイン名の対応を保持するDNS方式です。合成アドレスは接続先サービスの実際のグローバルIPアドレスではありません。接続がコアに戻ると、対応情報を利用してドメイン名を保持したまま振り分けできます。一部のLAN内サービスやアプリでは実際の名前解決結果が必要な場合があります。互換性に問題があるときは必要な項目だけをフィルターに設定し、古いDNSキャッシュにも注意してください。

DNSリーク: DNS leak; DNSリクエストが想定した名前解決経路を通らず、別のリゾルバーに送信される現象です。判断する前に、どのリゾルバーがどの経路で名前解決する想定なのかを確認してください。ブラウザーのセキュアDNS、アプリ内蔵のリゾルバー、システムDNSによってリクエストの送信先が変わることがあります。検査ページに表示されたリゾルバーの地域は手がかりにすぎず、それだけでリークの有無は判断できません。ログと実際のネットワーク設定も確認してください。

レイテンシ: Latency; 特定の方法でテスト先から応答が返るまでの時間です。クライアントでよく使われるURLテストには、接続の確立やリクエストへの応答が含まれる場合があり、ICMP pingとは異なります。数値はテスト先、キャッシュ、ネットワーク状況、タイムアウト設定に左右されるため、異なるツールの結果をそのまま比較するのは適切ではありません。レイテンシが低いと操作への応答性は向上しやすいものの、継続的なダウンロード速度や動画の安定性を直接示すわけではありません。

LAN接続を許可: Allow LAN access; 他のデバイスから、この端末のプロキシ待ち受けサービスへのアクセスを許可する設定で、通常はallow-lanに対応します。この設定だけでLAN全体の通信を自動的に取り込むわけではありません。実際のアクセス可否は、待ち受けアドレス、ファイアウォール、プロキシポート、無線ネットワークのクライアント分離設定にも左右されます。信頼できるネットワークに限定し、必要に応じて認証とアクセス範囲を設定して、不要なネットワークに待ち受けサービスを公開しないでください。

サブスクリプションと設定

サブスクリプションは設定内容を提供し、設定は動作を定義します。上書きによって最終的な統合結果が決まります。

サブスクリプション: Subscription; リンクからノード一覧や設定全体を取得・更新する仕組みです。内容はプロトコルリンクの一覧の場合もあれば、ルールやポリシーグループを含むYAMLファイルの場合もあります。クライアントが該当形式に対応している必要があり、ファイルをダウンロードできてもインポートできるとは限りません。サブスクリプションリンクには認証情報が含まれる場合があるため、スクリーンショット、ログ、問い合わせ文に貼り付けて公開しないでください。自動更新の間隔は提供元の指定も考慮して設定しましょう。

ノード: Proxy endpoint; プロキシの接続先に必要なパラメーターをまとめた項目です。通常、プロトコル、サーバーアドレス、ポート、認証情報が含まれ、トランスポートやTLSの設定が付く場合もあります。ノード名は識別用のラベルにすぎず、サーバーの所在地、回線品質、現在の利用可否を保証するものではありません。表示名を変えても接続は改善しないため、完全な設定、サーバーの状態、ネットワーク経路を確認してください。

YAML: YAML configuration format; マッピング、リスト、スカラー値などを表すテキスト形式で、Clashの設定ではプロキシ、ルール、DNSの記述によく使われます。インデント、項目の階層、データ型はすべて解析結果に影響します。同じ行でも置く階層によって意味が変わることがあります。編集時はスペースでインデントし、バックアップを残してください。構文が解析できても、コアによる項目の検証と参照先の確認が必要です。

設定の上書き: Configuration override; サブスクリプションの設定を読み込む際に、指定した項目を統合または変更する仕組みです。ローカルのDNS、ルール、待ち受け設定などを保持し、更新のたびに編集し直す手間を減らせます。統合順序、リストへの追加、項目の置き換え方はクライアントによって異なるため、同じ名前の機能が同じ結果になるとは限りません。変更後は実際に適用された設定を確認し、次回のサブスクリプション更新後も意図どおりか確かめてください。

プロキシプロバイダーとルールプロバイダー: Proxy providers / Rule providers; proxy-providersとrule-providersは、それぞれノード一覧とルール一覧を個別に読み込み、メイン設定と分けてリソースを管理するために使います。定義しただけでは適用されず、ポリシーグループやルールから参照する必要があります。更新に失敗した場合は、メインのサブスクリプションと各リソースのログを分けて確認し、形式、パス、更新間隔、ローカルキャッシュを調べてください。

Clashをダウンロード