Shadowsocks #
SS / Shadowsocks 2022Shadowsocksは暗号化プロキシプロトコルのファミリーで、設定には通常、サーバーアドレス、ポート、パスワード、暗号化方式が含まれます。従来のAEADとShadowsocks 2022では、方式名や鍵の要件が異なります。名称だけを置き換えてもアップグレードにはなりません。インポート時に暗号化方式がサポートされていないと表示されたら、ポートを何度も変更するのではなく、まずコアの対応状況を確認してください。
用語インデックス / TERM INDEX
Clash用語集と用語早見表
サブスクリプションの項目からクライアントのスイッチまで、まず用語が属する層を見分けてから設定を調整しましょう。よく使われる概念を5つのカテゴリに分けて解説します。各用語カードは、見出し横のリンクから個別に開けます。
よく使う用語25件
設定項目と仕組み
mihomo / Clashエコシステム
プロトコルと通信方式
接続プロトコルと通信方式
プロトコル名は速度の順位ではありません。まずクライアントが対応しているかを確認し、次にサーバー側の設定を照合しましょう。設計上の違いについてはプロトコルとコアの技術ガイドをご覧ください。
VMessとVLESS #
UUID-based proxy protocols異なるプロトコルで、どちらもユーザー識別にUUIDを使うことがありますが、UUIDが同じだからといって設定を流用できるわけではありません。VMessにはプロトコル層の暗号化機能がありますが、VLESSはペイロードを暗号化しません。実際の安全性はTLSなどの設定によって異なります。問題を調べる際は、プロトコルタイプだけでなく、通信方式、サーバー名、パスも確認しましょう。
Trojan #
TLS-based proxy protocolTrojanは通常、TLS接続上でプロキシ通信を行い、認証にはパスワードを使います。アドレス、ポート、パスワードに加え、証明書の検証とサーバー名が一致している必要があります。IPアドレスで接続する場合は、特にサーバー名の設定を確認してください。証明書エラーが出たら、検証を無効にするのではなく、まず時刻、名前、証明書チェーンを確認しましょう。
Hysteria2とTUIC #
QUIC-based proxy protocolsどちらもQUICをベースとする別々のプロキシプロトコルで、基盤となるネットワークでUDP通信が可能である必要があります。QUICの輻輳制御や多重化が一部のネットワークで有効な場合はありますが、TCP方式より必ず速い、あるいは省電力とは限りません。現在のネットワークでUDPが制限されている場合、Webサイトに直接接続できても、これらのプロトコルが接続できるとは限りません。
トランスポート層とTLS #
Transport / TLS / SNITCPとUDPは基本的なトランスポート方式、WebSocketなどは通信を運ぶ方式、TLSは暗号化と認証を担います。それぞれ異なる層の仕組みです。SNIはTLSハンドシェイクで接続先のサーバー名を指定するもので、ノードの表示名とは異なります。設定をインポートする際は、プロトコル、通信方式、パス、TLSパラメーターをまとめて確認してください。
コアとクライアント
処理エンジンと通信の入口
ボタンがオンになっていても、設定が有効になっていることを示すだけで、アプリの通信がプロキシに取り込まれたとは限りません。操作手順はClashの使い方ガイドをご覧ください。
コアとクライアント #
Core / GUI clientコアはプロトコル接続、ルール判定、DNS処理を担い、クライアントはGUI、サブスクリプション管理、システム連携を提供します。画面が似ていても機能が同じとは限らず、同じクライアントでもアップデート後に別バージョンのコアへ切り替わる場合があります。設定項目がサポートされない場合は、Clashという名称だけでなく、クライアント名と実際に動作しているコアのバージョンを記録してください。
mihomo #
Clash.Meta lineagemihomoはClashの設定体系を引き継ぐプロキシコアで、名称にはClash.Metaとの歴史的なつながりがあります。特定のPC・スマートフォン用アプリを指すものではありません。対応プロトコルや設定拡張は初期のClashと異なるため、古いガイドの互換性情報をそのまま当てはめないでください。クライアントを選ぶ際は、必要なコア機能が画面やオーバーライド設定から利用できるかも確認しましょう。
システムプロキシ #
System proxyシステムプロキシは、クライアントが待ち受けるHTTPポートや混合ポートなどのローカルプロキシアドレスをOSに登録します。通常、この設定に従うアプリだけが利用するため、一部のゲーム、コマンドラインツール、独自のネットワーク機能を持つアプリは迂回する場合があります。クライアント終了後にネットワークの問題が起きたら、待ち受けが停止したプロキシアドレスがOSに残っていないか確認してください。
TUNモード #
Virtual network interfaceTUNは仮想ネットワークインターフェースとルーティング設定を使ってIP通信を取り込み、システムプロキシに従わないアプリの処理に使われます。有効化には通常、追加の権限が必要です。また、他のVPNや仮想ネットワークアダプター、ルーティング設定と競合する場合があります。TUNが担うのは通信を取り込む入口であり、コアに入った通信は引き続きルールに従って処理されます。すべての通信先がプロキシノードを使うわけではありません。
ルールとルーティング
マッチ条件と出口ポリシー
ルーティングの問題を調べるときは、一致したルールと最終的な出口をあわせて確認しましょう。ルールが正しく一致していても、参照先のプロキシグループで適切なノードが選ばれているとは限りません。
ルールベースルーティング #
Rule-based routingルールベースルーティングでは、ドメイン名、IPアドレス、プロセスなどの条件に基づいて、通信に適用するポリシーを決めます。通常は上から順に確認し、最初に一致したルールが適用されます。範囲の広いルールより先に、対象を絞った例外ルールを置きましょう。例外が後ろにあると、適用されないことがあります。問題を調べる際は、まず通信ログの一致ルールを確認し、次に条件を調べます。最初からノードを変える必要はありません。
ルールモードとグローバルモード #
Rule / Global / Directルールモードではルール一覧に従ってポリシーを選び、グローバルモードではコアが処理する通信にグローバルポリシーを適用します。DIRECTモードでは、原則として直接接続します。グローバルモードにしても、コアに取り込まれていない通信は自動的に捕捉されません。また、グローバルポリシー自体も適切に選択する必要があります。問題の切り分けに一時的なモード変更を使った場合は、調査後に元のルーティング方式へ戻しましょう。
プロキシグループ #
select / url-test / fallbackプロキシグループはノードや他のポリシーをまとめ、ルールから参照できる出口として使います。selectは手動選択、url-testは測定結果に基づく選択、fallbackは利用可能性と設定順に応じた切り替えに使われます。自動選択の結果は指定した測定の結果にすぎません。測定先のサイトが快適でも、すべてのサービスで同じように使えるとは限りません。
DIRECT、REJECT、MATCH #
Built-in policies / Catch-all ruleDIRECTは直接接続、REJECTは拒否を表すポリシーです。MATCHは追加条件を必要としないルールタイプで、ほかの2つとは役割が異なります。たとえばMATCH,PROXYは、残りの通信をPROXYという名前のポリシーに渡す指定です。参照先の名前が実際に存在する必要があります。MATCHは通常、後続のルールが先に処理されないよう末尾に置きます。
GeoIPとGeoSite #
IP datasets / Domain datasetsGeoIPはIPアドレスのデータセット、GeoSiteはドメイン名のリストに基づいて分類するため、同じ用途ではありません。データファイルの更新が遅れることもあり、Webサイトが複数地域のCDNを利用する場合もあるため、分類結果だけでサイトの運営地域やノードの品質は判断できません。意図しないマッチが起きたら、データベースの入手元と更新日、ルールの順序を確認してください。更新方法はGeoIP・GeoSiteデータの更新ガイドをご覧ください。
DNSとネットワーク
名前解決と接続状況の確認
名前解決の成功、接続の成功、十分なダウンロード速度はそれぞれ別のものです。まずどの段階で失敗したかを特定してから、DNSモードを切り替えるか判断しましょう。
DNS #
Domain Name SystemDNSはドメイン名をIPアドレスなどに変換します。アプリは通常、接続の確立にこの結果を使います。プロキシ接続とDNSクエリで経路が異なる場合があるため、ノードに接続できても、名前解決の経路が正しいとは限りません。調査では、名前解決のタイムアウト、返されたアドレスの異常、解決後の接続失敗を区別してください。それぞれ確認すべき設定が異なります。
Fake-IP #
Mapped address / fake-ip-filterFake-IPはアプリにマッピング用アドレスを返し、コアがそのアドレスとドメイン名の対応を管理します。198.18.0.1/16はよく使われる設定用アドレス範囲で、接続先Webサイトの実アドレスではありません。実際の名前解決結果を必要とするアプリでは、fake-ip-filterで該当ドメインを除外する必要がある場合があります。予約済みアドレスが表示されても、必ずしも異常ではありません。アプリが利用できるか、DNSリクエストがコアを経由しているかをあわせて確認しましょう。
redir-host #
Real-address DNS moderedir-hostは通常、名前解決後の実際のアドレスをアプリに返します。Fake-IPとはマッピングの方式が異なります。実IPを必要とする一部のアプリでは互換性を保ちやすいものの、名前解決にかかる時間やドメインとの対応付け、IPアドレスの共有などが処理に影響する場合があります。モードを切り替えた後も、アプリやシステムに古いキャッシュが残ることがあります。関連キャッシュを消去するか、接続を再確立してから結果を比べてください。
DNS漏れ #
Unexpected resolver pathDNS漏れとは、DNSクエリが想定した名前解決経路から外れる現象です。たとえば、指定したリゾルバーで処理するつもりが、別のリゾルバーからリクエストが送信される場合があります。ブラウザーのセキュアDNS、アプリ内蔵の名前解決、システム設定、IPv6などによって経路が変わるため、スイッチの状態だけでは判断できません。検査ページに表示されるリゾルバーのアドレスが、転送先やパブリックDNSのものの場合もあります。実際のクエリ経路を踏まえて結果を確認しましょう。
レイテンシとスループット #
Latency / Throughputレイテンシは特定の測定にかかる時間、スループットは単位時間あたりに転送できるデータ量で、同じ指標ではありません。クライアントのHTTP測定には、ハンドシェイクや応答待ちが含まれる場合があり、単純なICMPの往復時間とは異なります。キャッシュ、測定先、ネットワークの変動も結果に影響します。ノードを比較する際は条件を揃え、実際のサービスへの接続でも確認しましょう。単一の数値だけで判断しないことが大切です。
サブスクリプションと設定ファイル
設定の取得元と更新時の注意点
サブスクリプション、ノード一覧、完全な設定ファイルは、必ずしも同じ内容ではありません。インポートに失敗したら、まず形式を確認しましょう。操作手順はサブスクリプションURLと形式の解説をご覧ください。
サブスクリプション #
Subscription URLサブスクリプションは、URLから設定やノード情報を取得・更新する仕組みであり、プロキシプロトコルそのものではありません。URLから完全なYAML設定が返される場合も、ノード一覧だけの場合もあります。直接インポートできるかどうかは、クライアントが対応する形式によって異なります。URLにはアカウントを特定できる情報が含まれることがあるため、機密情報として扱ってください。問い合わせ用のスクリーンショットではURL全体を隠し、見知らぬオンライン変換サービスに不用意に渡さないようにしましょう。
ノード #
Proxy entry / Endpoint profileノードは接続に必要なパラメーターのまとまりで、通常はプロトコル、サーバーアドレス、ポート、認証情報を含みます。TLSや通信方式の設定が必要な場合もあります。ノードの表示名は識別用のラベルにすぎず、物理的な設置場所、帯域幅、安定性を証明するものではありません。サブスクリプションに複数のノードが含まれていても、一覧に追加されただけでは、現在のルールやプロキシグループで選択されているとは限りません。
YAML設定ファイル #
config.yaml / Structured configurationYAMLはインデントで階層を表す、Clashエコシステムでよく使われる設定形式です。通常、待ち受けポート、DNS、ノード、プロキシグループ、ルールなどを記述します。編集時はスペースでインデントし、同じ階層の位置を揃え、特殊文字に引用符が必要か確認してください。構文を解析できても、現在のコアがすべての項目に対応しているとは限りません。インポートエラーが起きたら、形式、項目名、コアとの互換性をあわせて確認しましょう。
Base64形式のサブスクリプション #
Encoded proxy URI listBase64形式のサブスクリプションには、エンコードされたノードURIの一覧がよく使われます。デコードすると、行ごとに接続情報が表示される場合がありますが、完全なClash設定とは限りません。Base64はエンコードであり、暗号化ではないため、アカウントやパスワードの保護には使えません。直接インポートできるかはクライアントの解析機能によります。あるノードプロトコルに対応していても、あらゆるサブスクリプション形式に対応しているとは限りません。
Provider #
proxy-providers / rule-providersProviderを使うと、一部のリソースを分けて個別に読み込み、更新できます。proxy-providersはノード一覧、rule-providersはルール一覧を提供します。リソースのダウンロードだけでは不十分です。ノード一覧はプロキシグループから、ルール一覧は対応するルールから参照する必要があります。調査時はリソースの状態に加え、参照名、内容の形式、最終的なルール順序も確認しましょう。
オーバーライドと設定のマージ #
Override / Merge / Local patchオーバーライドを使うと、サブスクリプション更新の影響を受けずにローカル設定を保持できます。たとえばDNSや待ち受けポートの変更、カスタムルールの追加などが可能です。ダウンロードした設定ファイルを直接編集すると、更新時に変更が上書きされることがあります。マージ、置き換え、配列への追加方法はクライアントによって異なり、同じ設定がどのクライアントでもそのまま使えるとは限りません。変更後は最終的に適用された設定を確認し、特にルールの挿入位置とプロキシグループ名が合っているか確かめましょう。