サブスクリプション
サブスクリプションは、クライアントがノードや設定一式を取得するためのリモート接続先で、アクセス情報を含むURLとして提供されるのが一般的です。提供元によって形式が異なり、ブラウザーで開けても、使用中のクライアントにそのままインポートできるとは限りません。サブスクリプションを更新するとリモートの内容が更新されますが、クライアントアプリは更新されません。スクリーンショットを共有する際は、サブスクリプションのURLを隠してください。
設定項目 · 接続ログ · クライアント設定
Clash 用語集
まず接続の入口、コア、出口を区別してから設定を読みましょう。ここではよく使う用語25項目を5カテゴリに分け、それぞれの意味や使用条件、混同しやすい点を解説します。
初めて設定する場合は入門ガイドをご覧ください。手順全体を確認したい場合は使い方ガイドへ。用語名の横にあるリンクは、ブックマークや共有に使えます。
基本概念
まず確認するのは3点です。設定の取得元、通信の入口、接続を処理する先です。
ノード
ノードは、プロキシサーバーへの接続に必要なパラメーターのまとまりで、通常はサーバーアドレス、ポート、プロトコル、認証情報を含みます。ノード名は提供元が付けたラベルにすぎず、実際の出口の場所や現在の負荷を示すものではありません。トラブルシューティングでは、ノードへの接続失敗とサブスクリプションの取得失敗を分けて考えます。前者は接続パラメーターやネットワーク経路を、後者は設定の取得元を確認してください。
遅延
クライアントに表示される遅延は、指定されたテスト先と方法で測定した応答時間であり、ICMP pingとは限りません。テスト先のサイト、接続の再利用、タイムアウトのしきい値、現在のネットワーク状況によって結果は変わります。遅延が小さくても帯域幅が大きいとは限らず、タイムアウトしてもすべての通信が使えないとは限りません。比較する際は、まず測定条件をそろえましょう。
システムプロキシ
システムプロキシは、OSの設定にローカルプロキシのアドレスを書き込み、その設定に従うアプリからクライアントへ接続できるようにします。ブラウザーは通常この設定を利用しますが、一部のゲーム、コマンドラインツール、独自にネットワークを管理するアプリは利用しない場合があります。システムプロキシを有効にする操作と、ルールモードを選ぶ操作は別です。前者は通信の入口を、後者はコアに入った後の振り分け方法を決めます。
TUNモード
TUNは仮想ネットワークデバイスでIPパケットを受け取り、コアに渡して対応する接続を確立します。システムプロキシに従わないアプリの通信にも適しています。実際に取り込まれる通信は、システムのルーティング、実行権限、除外設定、DNS設定によって異なり、有効にしただけですべての接続を処理できるわけではありません。まずシステムプロキシでノードが使えることを確認してから、TUNを項目ごとに確認すると、入口の問題とノードの問題を切り分けやすくなります。
プロキシプロトコル
プロトコルは接続の確立方法やデータの転送方法を定めるもので、速度の順位を直接示すものではありません。選ぶ前に、コアとサーバーの対応状況を確認してください。
HTTPプロキシ
HTTPプロキシは、アプリがプロキシサーバーを経由してアクセスする方法の一つで、ローカル接続の入口にもリモートノードにも使われます。HTTPSサイトへのアクセスでは通常、CONNECTでトンネルを確立し、TLS接続はブラウザーと接続先サイトの間で行われます。このプロキシを有効にしただけで、クライアントがHTTPSの本文を復号するわけではありません。証明書エラーが発生した場合は、システム時刻、証明書チェーン、接続環境を別途確認してください。
SOCKS5
SOCKS5は汎用プロキシプロトコルです。TCP接続を転送でき、UDP転送の仕組みも定義されていますが、アプリとサーバーがUDPに対応しているかはそれぞれ確認が必要です。プロトコル自体に通信を暗号化する機能はないため、SOCKS5を使っているだけで通信の安全性を判断することはできません。ドメイン名をローカルとプロキシのどちらで解決するかは、アプリがドメイン名と解決済みのIPアドレスのどちらを渡すかによって異なります。
Shadowsocks
Shadowsocksは、双方で合意した暗号方式と鍵を使ってプロキシサーバーに接続します。設定では通常、type: ssと記述します。暗号方式、パスワード、追加の転送パラメーターをサーバー側と一致させる必要があり、プロトコル名を変えるだけでは切り替えられません。比較的新しい暗号方式には、新しいコアが必要な場合があります。インポート時にエラーが出たら、まず該当する項目とコアの対応状況を確認してください。
Trojan
Trojanは通常、TLSでプロキシ接続を確立するため、サーバーアドレス、ポート、認証パラメーターをクライアント側でも一致させる必要があります。TLSハンドシェイクではSNIや証明書のドメイン名も影響するため、ノードのアドレスに到達できても、ハンドシェイクが成功するとは限りません。証明書の問題が起きたら、まずドメイン名、時刻、サーバー設定を確認してください。証明書検証の無効化を恒久的な解決策にするのは避けましょう。
Hysteria2
Hysteria2はQUICベースのため、UDP通信が可能なネットワーク経路と、対応するクライアントコアが必要です。認証、TLS、任意の難読化パラメーターをサーバー側と一致させてください。旧バージョンのHysteria設定がそのまま使えるとは限りません。ネットワークでUDPが制限されていると、同じサーバー上のTCPサービスが正常でも、このプロトコルでは接続に失敗する場合があります。
ルールと振り分け
ルールが適用するポリシーを決め、プロキシグループが使用する出口を選びます。この2つの関係を理解するほうが、モードを何度も切り替えるより役立ちます。
ルールベース振り分け
ルールベース振り分けでは、ドメイン名、IPアドレス、プロセスなどの条件で接続先を決めます。通常は上から順に評価し、最初に一致したルールが適用されます。具体的なルールは広い範囲に一致するルールより前に置き、最後にフォールバック用のルールを置くのが一般的です。ルールモードで想定外の出口が使われた場合は、接続ログで一致したルールとポリシーの経路を確認してから、順序や条件を変更してください。
プロキシグループ
プロキシグループはノードやほかのポリシーをまとめたもので、ルールからグループ名を参照すれば、特定のノードに固定せずに済みます。selectは通常、手動選択に使います。url-testはテスト結果に基づく選択、fallbackは利用可能な候補への切り替えに使います。自動グループの動作はテスト先や周期に左右されるため、すべての通信で同じ最適な出口が選ばれるとは限りません。
ルールセット
ルールセットを使うと、ドメイン名やIPアドレスの項目をメイン設定から分離して、個別に管理・更新できます。rule-providersにデータを定義したうえで、ルール一覧からRULE-SETで参照する必要があります。ダウンロードに成功しても、振り分けに使われているとは限りません。データの形式とbehaviorなどの定義が一致しているか確認してください。更新に失敗した場合は、ログに出力された解析エラーも確認しましょう。
GeoIPとGEOSITE
GeoIPはIPアドレスの割り当て先、GEOSITEはドメイン名のリストに基づいて分類するもので、利用するデータや照合対象が異なります。分類結果は、データの提供元、収録範囲、更新状況に左右されます。リアルタイムの物理的な位置情報や、サイトの所有者を示すものではありません。IPベースのルールではドメイン名の名前解決が発生する場合もあるため、DNS設定とあわせて照合結果を確認してください。
直接接続・拒否・フォールバック
DIRECTはローカルのネットワークから直接接続し、REJECTは接続を拒否するポリシーです。どちらもルールから参照できます。MATCHは残りの接続に一致するルールタイプで、MATCH,PROXYのように後続のポリシーが必要です。PROXYには、定義済みのポリシー名を指定してください。MATCHを早い位置に置くと、後続の通常ルールが評価されなくなります。
詳しく見る：ルールの順序と接続の確認方法。
ネットワークとDNS
ドメイン名の問い合わせ経路と、サイトへの接続経路は、分けて確認する必要があります。
DNS
DNSは、ドメイン名に対応するIPアドレスなどのレコードを調べる仕組みです。アプリはアドレスを取得した後、接続を開始します。OS、ブラウザー、プロキシコアがそれぞれ結果をキャッシュしたり、異なるリゾルバーを使ったりする場合があります。DNSの問題を調べるときは、どこから問い合わせが行われ、どこに渡されたかをまず確認してください。システムDNSを変更しても、コアやブラウザーの設定まで自動的に変わるとは限りません。
Fake-IP
Fake-IPはアプリに合成アドレスを返し、コア内にアドレスとドメイン名の対応を保存して、後続の接続をドメイン名に基づいて処理できるようにします。合成アドレスは接続先サーバーの実アドレスではなく、その通信は対応表を保持するコアに戻す必要があります。実アドレスを必要とするアプリでは、除外設定が必要な場合があります。DNSモードの切り替え後は、検証に古いキャッシュが影響していないかも確認してください。
DNSリーク
DNSリークは通常、DNSの問い合わせが想定した名前解決経路から外れることを指します。たとえば、プロキシ経由にする予定のドメイン名を、アプリがローカルのリゾルバーに直接問い合わせるケースです。異常に当たるかどうかは振り分け先を踏まえて判断してください。直接接続する通信でローカルのDNSを使っても、それだけで問題とは限りません。検出ページに表示されるリゾルバーは再帰問い合わせの経路上にある場合もあります。ブラウザーの暗号化DNS、システム設定、実際の問い合わせ記録をあわせて確認しましょう。
リゾルバーのグループ設定
nameserverとfallbackは、mihomoのDNS設定で使用するリゾルバーのリストです。結果の選択にはフィルターやポリシーの設定も影響します。fallbackは、プライマリーDNSの停止後にだけ使う単純な予備ではありません。fallback-filterも結果の選択に関与します。変更する前に、ドメイン名ごとにリゾルバーを指定する設定がほかにないか確認し、一部だけで判断しないようにしてください。
DNSリダイレクト
TUN設定におけるDNSリダイレクトは通常、条件に一致したDNSリクエストをコアのリゾルバーに転送することを指します。これは通信を取り込む機能であり、サイトの証明書を変更するものではありません。有効になるかどうかは、リクエストがTUNに入るか、ルールが対象のプロトコルとポートに一致するかによって決まります。アプリ独自のDoHやDoT接続は、一般的なDNSリダイレクトを設定しただけでは自動的に取り込まれないため、別途接続経路を確認する必要があります。
詳しく見る：DNS設定とトラブルシューティングの手順。
クライアントとコア
画面は操作を担当し、コアは接続を処理します。互換性の問題を調べるときは、この2つを確認してください。
GUIクライアント
GUIクライアントには、サブスクリプションのインポート、ポリシー選択、ログ確認、プロキシのオン・オフなどを行う画面があります。バックグラウンドで別のコアプロセスを起動することもあります。同じコアを使っていても、設定管理、権限の要求、OSとの連携はクライアントによって異なります。選ぶ際は画面の使いやすさだけでなく、搭載コアが現在の設定やプロトコルに対応しているかも確認しましょう。
mihomoコア
mihomoは旧称Clash Metaで、プロトコル接続、ルール照合、DNS処理を担うプロキシコアです。GUIクライアントから呼び出して使うことも、単独で実行することもできます。元のClashと共通する設定の書き方もありますが、対応する項目やプロトコルは完全には一致しません。設定に互換性がない場合は、クライアント名にClashが含まれているかだけで判断せず、実際に動作しているコアとそのドキュメントを確認してください。
YAML
YAMLはClashの設定によく使われるデータシリアライズ形式です。インデントで階層を表し、リストやキーと値の組み合わせで内容を記述します。インデントにはスペースを使い、特殊文字を含む値では引用符のルールに注意してください。同じキーを重複させると、意図しない上書きが起きる場合もあります。構文が正しいことは第一歩にすぎません。ポリシー名の参照、項目の型、コアの対応状況も設定チェックや起動ログで確認する必要があります。
設定のオーバーライド
設定のオーバーライドは、サブスクリプションの元データにマージ、パッチ、スクリプトなどを適用し、実行時の設定を生成する仕組みです。ローカルのDNSやルールの変更を保持するのに便利です。リストの置き換えや追加の順序、優先順位はクライアントによって異なるため、別のクライアントの手順をそのまま使わないでください。変更が反映されないように見える場合は、サブスクリプション編集画面の元ファイルだけでなく、実際に実行されている最終設定を確認しましょう。
外部制御インターフェース
external-controllerは、コアの制御APIがリッスンするアドレスを指定します。画面から接続の確認、ポリシーの切り替え、設定の管理などを行うために使います。ブラウザーの通信に使うプロキシポートではないため、システムプロキシに設定しても意図した動作にはなりません。ローカルで管理する場合はループバックアドレスに制限してください。ほかのデバイスから接続する必要がある場合は、認証とファイアウォールのアクセス範囲も設定しましょう。