CONFIG.YAML / 用語一覧

Clash設定用語集。

画面に表示される名称から設定の意味を確認できます。5つのテーマに分けた25の用語を通じて、通信の取り込み、DNSの名前解決、ルールによる振り分けを整理し、異なる問題を混同しないように解説します。

手順に沿って使い方を見る詳細ドキュメントを見る

コアとクライアント

使用中のアプリ、コア、設定の読み込み元をまず確認しましょう。同じ画面上のボタンでも、クライアントによって設定の処理方法が異なる場合があります。

mihomo / Clash.Metamihomoコア: mihomoはClash.Metaから発展したプロキシコアで、プロトコル接続、DNS処理、ルール照合などを担います。Clash.Metaはその前身で使われていた名称です。GUIは通常、コアを管理するための窓口にすぎず、GUIとコアの更新時期が一致するとは限りません。設定項目が使えない場合は、アプリ名だけで判断せず、クライアントの「バージョン情報」やコア情報で実際のバージョンを確認してください。

client / GUIクライアント: クライアントは、インストールして操作するアプリです。サブスクリプションの読み込み、ノードの選択、システムプロキシの設定、コアの管理などを行います。起動前にサブスクリプション、上書き設定、拡張設定を統合する場合があるため、サブスクリプションの元ファイルを編集しても、最終的な設定に反映されるとは限りません。トラブル対処では、クライアント側のスイッチと実行中の設定の両方を確認してください。アプリ選びにはクライアント比較レビューも参考になります。

subscription / profileサブスクリプション: サブスクリプションは通常、ノードや設定全体を取得するためのリモート接続先を指し、更新するとそのリソースに再アクセスします。返される内容はYAML形式の設定全体の場合も、ノード一覧だけの場合もあり、クライアントや変換処理が形式を認識する必要があります。すべてのURLを相互に置き換えられるわけではありません。URLには個人用の認証情報が含まれることが多いため、スクリーンショットや公開ログ、オンラインでの質問に載せないようにしましょう。詳しい読み込み手順はサブスクリプションの読み込みをご覧ください。

proxies / serverノード: ノードは、プロキシサーバーへ接続するための情報一式です。通常、サーバーアドレス、ポート、プロトコル、認証情報が含まれます。ノード名に含まれる地域名は提供元の表記にすぎず、入口サーバーや実際の出口の場所を示すとは限りません。特定のノードだけ接続できない場合は、同じ設定にある別のノードでも試し、サーバーに到達できないのか、認証情報が無効なのか、ローカルの通信取り込み設定に問題があるのかを切り分けます。

config.yaml / indentationYAML設定形式: YAMLは設定の階層を表すテキスト形式です。インデントで親子関係を示し、リスト項目は通常ハイフンで始まります。インデントにはタブではなく半角スペースを使い、同じ階層の項目をそろえてください。項目がファイル内に見えていても、階層が変わると意図どおりに反映されないことがあります。編集前に元の設定を保存し、一度に一か所だけ変更しましょう。まずクライアントの設定チェックを実行し、その後、動作を確認してください。

プロキシプロトコル

ローカルアプリがプロキシの接続口につなぐ際のプロトコルと、コアがリモートノードにつなぐ際のプロトコルは別のものです。設定前に、どの接続区間のパラメーターなのかを確認しましょう。

HTTP / CONNECTHTTPプロキシ: HTTPプロキシは、アプリからプロキシの接続口へリクエストを送る方式です。HTTPSサイトへのアクセスでは、通常CONNECTメソッドでトンネルを確立します。接続先サイトがHTTPSでも、ローカルのプロキシ接続口がTLSを使うとは限りません。ブラウザーやコマンドラインにアドレスを設定する際は、クライアントが実際に待ち受けているポートを指定してください。mixed-portを使うと、同じ接続口でHTTPとSOCKSの接続を受け付けられます。

SOCKS5 / UDP ASSOCIATESOCKS5: SOCKS5は、アプリから明示的に指定できるプロキシプロトコルです。TCP接続に対応し、UDP転送の仕組みも定義されていますが、実際にUDPを転送できるかはアプリと接続経路全体の対応状況によります。ツールによっては、ドメイン名をローカルで名前解決するか、プロキシ側に任せるかを選べます。選択によってDNSの経路が変わります。アプリにSOCKS5を設定している場合は、システムプロキシだけでなく、この設定もトラブル対処時に確認してください。

ss / cipherShadowsocks: Shadowsocksは、コアとリモートプロキシサーバー間で使う暗号化プロキシプロトコルです。設定では通常type: ssと記述します。アドレス、ポート、暗号化方式、パスワードをサーバーの情報に合わせてください。ノードによっては追加のプラグイン設定も必要です。インポートに成功しても、認証やネットワーク接続が成功したとは限りません。また、古いコアでは新しい暗号化方式に対応していない場合があります。

trojan / TLS / SNITrojan: Trojanは通常、TLS接続上でプロキシ通信を行います。パスワードに加え、サーバー名と証明書の検証も確認してください。接続先アドレスと証明書のドメイン名が一致しない場合は、検証を無効にするのではなく、サブスクリプションに記載されたSNIなどのパラメーターを確認しましょう。端末の時刻ずれ、証明書の期限切れ、サーバー名の誤りはいずれもTLSハンドシェイクの失敗につながります。一般的なネットワークからノードに到達できるかどうかとは別の問題です。

hysteria2 / QUICHysteria 2: Hysteria 2はQUICベースのプロキシプロトコルで、利用するネットワークがUDP通信を許可している必要があります。パケットロスのある回線で有効な場合もありますが、プロトコル名だけで通信速度が速いと判断することはできません。同じネットワークでTCP系のノードは使えるのにHysteria 2が繰り返しタイムアウトする場合は、UDPの制限、サーバーポート、ファイアウォールを確認してください。帯域のパラメーターもサーバー側の要件に合わせて設定します。

動作モード

通信の取り込み方によって、リクエストがコアに届くかどうかが決まります。動作モードは、届いたリクエストをどう処理するかを決めるものです。まずこの2つを区別し、必要な設定を選びましょう。

mode: ruleルールモード: ルールモードでは、設定された条件に基づいて、コアに届いた接続を直接接続、プロキシ経由、拒否のいずれかに振り分けます。通常はこのモードから使い始め、接続一覧で対象ドメインにどのルールが適用されたかを確認します。ルールモード自体がすべてのアプリの通信を自動的にコアへ取り込むわけではありません。接続一覧に対象のリクエストが表示されない場合は、まず通信の取り込み方法を確認してください。モードの違いは動作モードの選び方で解説しています。

mode: global / GLOBALグローバルモード: グローバルモードでは、コアに届いた接続をグローバルポリシーで処理します。ルールの違いでアクセスに差が出るかを一時的に比較する際に便利です。ただし「グローバル」は端末全体の通信を取り込むという意味ではありません。システムプロキシを使わないアプリは、引き続きコアを迂回する可能性があります。テスト後はルールモードに戻し、グローバルポリシーで選択中のノードも確認しましょう。グローバルグループと通常のポリシーグループで異なるノードを選んでいると、誤った判断につながることがあります。

system proxy / mixed-portシステムプロキシ: システムプロキシは、OSにプロキシのアドレスとポートを登録する仕組みです。この設定に従うアプリは、リクエストをローカルクライアントへ送ります。ゲーム、一部のコマンドラインツール、独自のネットワーク機能を持つアプリなどはシステムプロキシ設定を参照しないため、スイッチがオンでもすべての通信が取り込まれるとは限りません。クライアントを終了した後もWebページを開けない場合は、停止済みポートを指すプロキシ設定がOSに残っていないか確認してください。

tun / auto-routeTUNモード: TUNは仮想ネットワークインターフェースでIPパケットを受け取り、ルーティング設定と組み合わせてコアへ通信を渡します。システムプロキシを使わない一部のアプリも対象にできます。デスクトップでは管理者権限、サービス、ドライバーが必要な場合があり、スマートフォンではVPN権限が関係します。有効にできない場合は、権限とほかのVPNとの競合を確認してください。TUNは通信を取り込む入口であり、DNS経路や振り分けルールが正しくなることを保証するものではありません。

url-test / timeout遅延テスト: クライアントの遅延テストでは通常、ノード経由で指定したアドレスにアクセスするまでの時間を測定します。ハンドシェイクなどを含めるかは実装によって異なります。ダウンロード速度を測るものではなく、テスト先、タイムアウト値、ネットワークの状態が異なる結果を単純に比較することもできません。タイムアウトしても、すべてのWebサイトにアクセスできないとは限りません。実際の接続状況とログをあわせて確認してください。詳しい手順はノードの遅延に関する問題をご覧ください。

DNSと名前解決

DNSの問い合わせとアプリの接続は、異なる経路を通る場合があります。設定を確認するときは、どのコンポーネントが名前解決を行い、どこへ問い合わせ、その通信を誰が取り込むのかも確認しましょう。

dns / nameserverDNSとドメイン名の名前解決: DNSはドメイン名をIPアドレスなどのレコードに変換し、アプリが接続先を見つけられるようにします。OS、ブラウザー、アプリ、プロキシコアは、それぞれ結果をキャッシュしたり問い合わせを行ったりすることがあります。そのため、コアのDNS設定を変更しても既存の接続がすぐに変わるとは限りません。ドメイン名では接続できず、アドレスを直接指定すると接続できる場合は、名前解決のログとキャッシュを確認してください。ただし、証明書や仮想ホストの設定によってはIPアドレスを直接指定しても接続できません。

enhanced-mode: fake-ipFake-IP（仮想IP）: Fake-IPはアプリに仮想IPを返し、コア内にIPアドレスとドメイン名の対応を保存します。これにより、後続の接続をドメイン名に基づくルールと照合できます。仮想IPが表示されても、実サーバーのIPアドレスに名前解決されたわけではなく、設定異常を示すものでもありません。LAN内のサービスやアプリがこの方式に対応していない場合は、DNS機能全体を無効にするのではなく、対象ドメインに対するfake-ip-filterの設定を確認してください。

DNS leak / resolver pathDNS漏えい: DNS漏えいとは、問い合わせが想定した経路を迂回し、別のリゾルバーに届く状態です。重要なのは、事前に設定したポリシーに沿った経路かどうかです。検査ページに表示されるリゾルバーの地域は手がかりにはなりますが、通信事業者が特定の問い合わせを知り得たことを単独で証明するものではありません。ブラウザーの暗号化DNS、OSの設定、TUNによる通信の取り込み、接続ログを照らし合わせて確認してください。直結するドメインでローカルのDNSを使う設定も、必ずしも異常ではありません。

DoH / DoT暗号化DNS: DoHはHTTPS、DoTはTLSを使ってDNSクエリを送信します。問い合わせの通信は保護されますが、自動的にプロキシノード経由になるわけではありません。DNSサービスは受け取ったドメイン名を処理できるため、接続経路も別途確認が必要です。上流DNSをドメイン名で指定する場合は、そのDNSサーバーのアドレスを最初にどう名前解決するかも考慮し、依存関係が循環しないようにしてください。

nameserver-policyドメイン別のDNS指定: nameserver-policyは、ドメイン名や対応する条件に応じて上流DNSを指定する設定です。たとえば、内部ドメインを組織内のDNSサービスに問い合わせるよう設定できます。変更されるのはリゾルバーの選択であり、アプリの接続先への出口ではありません。接続経路はルールによる振り分けもあわせて確認してください。この項目はdns階層内に記述します。複雑な条件式は使用中のコアの対応状況を確認し、別バージョンの設定例をそのまま流用しないようにしましょう。

ルールとトラフィック振り分け

ルールは通信を照合し、プロキシグループは接続先を選び、プロバイダーはリソースを読み込みます。似た名前の設定項目でも、役割はそれぞれ異なります。

rules / DIRECT / REJECT / MATCHルールによる振り分け: ルールによる振り分けでは、ドメイン名やIPアドレスなどの条件に基づいて接続をポリシーに割り当てます。通常のrulesリストは上から順に照合され、最初に一致したルールで接続先が決まります。DIRECTは直接接続、REJECTは拒否を意味します。末尾のMATCHは、ほかのルールに一致しなかった通信を処理するためによく使われます。例外ルールは、先に一致する範囲の広いルールより上に追加し、接続ログで結果を確認してください。

proxy-groups / select / url-testプロキシグループ: プロキシグループは、ノードやほかのポリシーをまとめ、ルールから参照できる接続先にします。手動選択、遅延テストによる選択、フェイルオーバーなどの種類があります。グループを切り替えても、すべての接続が新しいノードを使うとは限りません。ルールが別のグループを参照していたり、確立済みの接続が以前の経路を使い続けたりする場合があります。テストでは、まずどのグループがルールに一致したかを調べ、次にそのグループで実際に選択されているメンバーを確認してください。必要に応じて対象への接続を張り直します。

GEOIP / geodataGeoIPによるIPアドレスの地域判定: GeoIPはIPアドレスのデータベースを使い、接続先IPの地域などを判定します。IPアドレスの範囲に応じた振り分けによく使われます。データベースには更新周期や誤差があり、端末の所在地やサービス運営会社の地域と同じとは限りません。想定と異なる判定が出る場合は、実際の接続先IP、データベースの提供元、更新状況を確認してください。設定でno-resolveを使っているかどうかも、ドメイン名を含む接続の照合に影響します。

rule-providers / RULE-SETルールセットプロバイダー: rule-providersは、ローカルまたはリモートのルールセットを読み込みます。大きなドメイン名やアドレスのリストをメイン設定から分けて管理できます。プロバイダーを宣言しただけでは振り分けに使われません。ルール一覧からRULE-SETなどで参照し、振り分け先も指定する必要があります。更新に失敗した場合は、リソースのURL、内容の形式、動作タイプが合っているかを確認してください。ダウンロードできたことと、ルールが有効になったことは別です。

proxy-providers / useノードプロバイダー: proxy-providersはノードの一覧を個別に読み込み、更新するための設定です。通常、プロキシグループからuseで参照します。クライアント設定全体のサブスクリプションとは異なり、モード、DNS、ルールの設定を置き換えるものではありません。取得するリソースもコアが対応する形式である必要があります。更新後もグループが空のままなら、参照名、フィルター条件、読み込みログを確認してください。よくある対処法はサブスクリプションを更新できない場合をご覧ください。