Shadowsocks
SS · Shadowsocks暗号化プロキシプロトコルの一種で、ノード設定には通常、サーバーアドレス、ポート、パスワード、暗号化方式が含まれます。クライアントとサーバーの双方が対応する暗号化方式を使う必要があります。Shadowsocks 2022などの派生方式では、鍵の形式も一致させてください。インポートできても接続できない場合は、ノード名を変える前にこれらの項目を確認しましょう。
用語早見表 · よく使う26の用語
Clash用語とFlClashの設定ガイド
サブスクリプションから出力ルールまで、設定のレイヤー別に用語を確認できます。各項目には個別のアンカーがあり、直接共有できます。初めて設定する場合は初期設定ガイド、プロトコルの選び方やコアの違いについてはプロトコル解説をご覧ください。
プロキシプロトコル
ノードの接続方式を決めるプロトコル
プロトコルは、クライアントとサーバーがデータをやり取りする方式を定めます。ノードを選ぶ際は、クライアントが対応していることを確認したうえで、認証方式、セキュリティ層、通信設定を照合してください。プロトコル名だけで通信速度は判断できません。
VMess
VMess protocolV2Rayエコシステムのプロキシプロトコルで、通常はUUIDを使ってユーザーを識別します。ノードによってはWebSocketやTLSなどの設定もあり、通信方式やパスをサーバー側と一致させる必要があります。端末の時刻が大きくずれていると認証に影響することがあるため、接続に問題がある場合は時刻設定も確認してください。
Trojan
Trojan protocol通常はTLS接続上で動作し、パスワードで認証するプロキシプロトコルです。サーバーアドレスだけでなく、SNI、ドメイン名、証明書の検証設定も接続結果に影響します。証明書関連のエラーが発生した場合は、サーバー情報、端末の時刻、証明書の状態を確認し、証明書検証は有効なままにしてください。
VLESS
VLESS protocolUUIDで認証する軽量なプロキシプロトコルです。プロトコル自体は通信内容を暗号化しないため、実際の運用ではTLSやREALITYなどのセキュリティ層を組み合わせます。インポート時は通信方式、セキュリティ層と関連設定をすべて保持してください。どちらもVLESSのノードでも、構成が異なれば必要なクライアント機能も異なる場合があります。
Hysteria2
Hysteria 2 · QUICQUICをベースとするプロキシプロトコルで、通信にはUDPを使用します。実際の性能はUDPの疎通状況、輻輳制御、帯域設定によって変わります。適したネットワーク環境で利用し、実際の用途に合わせて動作を確認してください。Hysteriaの第1世代と第2世代にはプロトコル上の違いがあるため、名称だけを書き換えて旧設定を使うことはできません。
TUIC
TUIC · QUIC-based proxyQUICをベースとするプロキシプロトコルで、TCPとUDPの通信を扱えます。サーバー側のプロトコルバージョン、認証項目、クライアントのコアが対応している範囲を確認してください。UDPの通信経路に制限がある場合、同じプロトコルの別ノードに切り替えても解決しないことがあります。まずローカルネットワークの状態を確認しましょう。
コアとクライアント
画面、コア、Clashエコシステム
クライアントは操作画面を提供し、コアは接続とルール処理を実行します。同じ設定でもアプリによって動作が異なる場合、原因は画面の違いだけでなく、コアのバージョン、設定の上書き、OSとの連携方法にある可能性があります。
Clash
Clash ecosystemソフトウェアのエコシステムでは、元のルールベース型プロキシコアを指す場合と、その設定方式に対応するクライアント全般を指す場合があります。名称にClashが含まれていても、同じプロジェクトが開発しているとは限らず、対応プロトコルも同じとは限りません。解説が使えるか判断するには、アプリ名、コア、バージョンを確認してください。
mihomo
Formerly Clash.MetaClash.Metaプロジェクトから名称変更されたルールベース型プロキシコアです。プロトコル接続、DNS処理、ルール判定を担います。Clashの設定体系を引き継いで機能を拡張しており、古い解説ではMetaという名称が使われている場合があります。新しい設定項目には対応バージョンが必要です。すべてのClashコアで読み込めるとは限りません。
クライアント
Client applicationサブスクリプション管理、ノード選択、接続のオン・オフ、ログ確認などの操作画面を提供するアプリです。FlClashはこの層にあたります。画面では設定を保存・整理し、実際の通信転送は通常、組み込まれたプロキシコアが行います。アプリによってサブスクリプションとローカル設定が統合されるため、元ファイルを編集する前に、現在有効な設定を確認してください。
プロキシコア
Proxy coreプロキシプロトコル、通信の転送、DNS、ルーティングルールを処理する基盤プログラムです。クライアントの画面更新とコアの更新は別のものです。新しいボタンが追加されても、機能の利用にはOSの権限が必要な場合があります。機能が見つからないときは、画面の見た目だけでなく、アプリとコアの情報も記録しておくと原因を調べやすくなります。
サブスクリプションと設定ファイル
インポートする内容と更新元
サブスクリプションは設定の取得・更新先、設定ファイルは実際の設定、ノードは接続情報です。これらは一緒に扱われることが多いものの、変更や更新の対象はそれぞれ異なります。操作する前に、クライアントがどの設定を使っているか確認してください。
サブスクリプション
Subscriptionリンクを使ってノードや設定全体を取得・更新する仕組みです。ノードだけを含むものもあれば、プロキシグループ、ルール、DNS設定も含むものがあります。更新するとリモートの内容が再取得されるため、サブスクリプションの設定に直接加えた変更は上書きされる場合があります。リンクに含まれる認証情報は機密情報として扱ってください。インポート方法はサブスクリプションの設定方法をご覧ください。
プロキシノード
Proxy nodeクライアントで使うプロキシサーバーの接続設定で、通常はアドレス、ポート、プロトコル、認証情報を含みます。ノード名は識別しやすくするためのラベルにすぎず、名前に含まれる地域が実際の出口の所在地とは限りません。接続できるかどうかは、設定値、サーバーの状態、ネットワーク経路によって決まります。一覧に表示されるのは、設定が読み込まれたことを示すだけです。
YAML設定ファイル
YAML configurationインデント、キーと値、リストで設定を記述するテキストファイルです。Clash系の設定では一般的にこの形式を使います。インデントにはスペースを使用し、階層を変更するときは同じ階層の位置をそろえてください。引用符やコロンの扱いにも注意が必要です。YAMLとして解析できても、項目が有効かどうかはコアの設定仕様によります。
プロキシプロバイダー
Proxy provider · proxy-providers設定内にノード一覧を取り込むための仕組みで、リモートからノードを取得し、プロキシグループから参照できます。ノードの更新をメイン設定の構成から切り離せるため、ローカルのルールを保ったまま接続設定を更新できます。プロバイダーファイルはコアが要求する形式にする必要があり、任意のサブスクリプション全体をそのまま使えるとは限りません。
サブスクリプション変換
Subscription conversionノードのリンクや特定形式のサブスクリプションを、利用するクライアントが読み込める形式に変換する処理です。変換先が対応していないプロトコル項目は失われることがあります。テンプレートによってプロキシグループやルールが追加される場合もあります。オンライン変換サービスにはサブスクリプションの内容が渡るため、まず提供元が明確で互換性のあるサブスクリプションを利用し、変換が必要な場合は処理方法を確認してください。
ルールとトラフィック分岐
リクエストの判定と出力先の選択
ルールはリクエストを判定し、プロキシグループは出力先をまとめ、データファイルは判定条件を提供します。この3つの役割を理解すると、ルールの問題をノードの障害と取り違えにくくなります。
ルール分岐
Rule routingドメイン、IPアドレス、ルールセットなどの条件に基づき、リクエストの出力先をDIRECT、プロキシ、その他のポリシーから選ぶ仕組みです。ルールは通常上から順に評価され、最初に一致したものが適用されます。末尾のMATCHは、ほかのルールに一致しない通信を処理するためによく使われます。ルールモードですべての通信がプロキシ経由になるわけではありません。適用されたルールと出力先のポリシーを確認してください。
プロキシグループ
Proxy group · proxy-groupsノードやほかのポリシーをまとめ、共通の出力先として扱う設定です。ルールの出力先には、固定ノードではなくプロキシグループを指定できます。手動選択、速度テストによる選択、フェイルオーバーでは選択ロジックが異なります。グループ内のノードを切り替えても、通常はルールを変更する必要はありません。テスト先での結果は特定の接続先に対するものです。自動選択の結果は、実際のアプリでの通信も確認してください。
ルールセット
Rule set · rule-providers個別に管理・更新できる条件のまとまりで、通常はrule-providersで宣言し、RULE-SETで参照します。ルールセットは判定条件を提供し、最終的な出力先は通常、それを参照するルールで指定します。ファイル形式、behaviorの種類、参照名を一致させる必要があります。ダウンロードに成功しても、正しく判定されるとは限りません。
GeoIP
IP geolocation dataIPアドレスの地域情報に基づいて判定するためのデータで、よく使われるルール形式はGEOIP,CN,DIRECTです。判定対象はIPアドレスの地域情報であり、Webサイトの言語、企業の所在地、コンテンツのカテゴリを直接特定するものではありません。データベースの更新、アドレスの割り当て変更、CDNの振り分けによって結果が変わることがあります。GeoIPは分岐条件の一つとして利用してください。
GeoSite
Domain category dataドメインをカテゴリ別にまとめたデータで、GEOSITEルールから参照できます。ラベル名や収録範囲はデータソースによって異なり、同じカテゴリ名でもデータベース間で内容が一致するとは限りません。IPアドレスを判定するGeoIPとは役割が異なります。使用前に、コアの対応状況、データファイルの提供元、対象のラベルが存在するかを確認してください。
ネットワークモードとDNS
通信の取り込み口、名前解決の経路、テスト結果
通信をコアに取り込む方法と、取り込んだ後の出力先は別の仕組みです。TUNとシステムプロキシは主に通信の取り込み口に関わり、最終的な接続先はルール、プロキシグループ、DNS設定によって決まります。
TUNモード
Virtual network interface仮想ネットワークインターフェースとルーティング設定を使って、IP通信をプロキシコアに取り込む方式です。対象範囲はOS、ルート、権限、除外設定によって異なります。有効にした後も、出力モードとルールに従って通信の直結・プロキシが選ばれます。ほかのVPN、仮想ネットワークアダプター、LANのルーティングと競合する場合があります。原因を調べるときは、取り込みに関する設定を一度に一つだけ変更してください。
システムプロキシ
System proxyOSのプロキシ設定をクライアントのローカル待ち受けポートに向ける方式で、ブラウザーなどシステムプロキシに従うアプリでよく使われます。独自のネットワーク設定を使うアプリは、この入口を自動的に利用するとは限りません。システムプロキシが決めるのは通信の取り込み方です。コアに入った後に直結するかどうかは、現在のモードと設定ルールによって決まります。
DNS
Domain Name Systemドメイン名をIPアドレスなどのレコードに変換する仕組みで、Webサイトへの接続に欠かせない処理です。システムDNS、クライアントDNS、アプリ内蔵の暗号化DNSでは、異なる経路で名前解決が行われる場合があります。一か所の設定を変更しても、ほかの経路に影響するとは限りません。キャッシュや分岐ポリシーも結果に影響するため、原因を調べる際は問い合わせ元、上流のDNSサーバー、接続ログを確認してください。
Fake-IP
Synthetic IP mappingクライアントがドメイン名に合成IPアドレスを割り当て、ドメイン名との対応関係を保持するDNS処理方式です。接続時にドメイン名でルール判定しやすくなります。合成アドレスはWebサイトの実サーバーのアドレスではないため、出口の所在地を直接判断する材料にはなりません。実際の名前解決を必要とするアプリで問題が起きた場合は、除外リストを確認し、変更後に関連するキャッシュを処理してください。
DNS漏れ
DNS leakDNS問い合わせが想定した名前解決経路から外れる状態です。たとえば、クライアントが処理する想定の問い合わせが、アプリやシステムから別のDNSサーバーに送信されるケースがあります。まず想定するポリシーを明確にし、アプリの暗号化DNS、システム設定、クライアントが通信を取り込む範囲を確認してください。テストページに表示されるDNSサーバーの地域は手がかりにすぎず、地域表示だけでDNS漏れとは断定できません。
レイテンシ
Latency · URL test特定のテスト条件で、往復通信やリクエストの完了にかかる時間です。クライアントはテストURLへのアクセスで測定することが多く、ICMP Pingを使うとは限りません。テスト先、タイムアウト設定、接続の再利用、ネットワーク経路によって数値が変わります。レイテンシが低くてもダウンロード速度が速いとは限りません。タイムアウト表示もテスト先に到達できないだけの場合があるため、実際の通信で判断してください。