ShadowsocksSS
Shadowsocksは共有鍵と指定された暗号化方式で通信を中継します。ノード設定には通常、サーバーアドレス、ポート、パスワード、暗号化方式が含まれます。クライアントとサーバーの暗号化方式は一致させてください。従来方式とShadowsocks 2022では必要な設定項目も異なります。追加プラグインやプロトコル拡張を使う場合は、コアの対応状況を個別に確認してください。SSという表示だけで読み込み可能とは判断できません。
プロトコルの選び方を見る →
CONFIGURATION GLOSSARY
Clash用語集
サブスクリプションの読み込みからネットワーク接続まで、設定の階層ごとに用語を解説します。プロトコルはサーバーへの接続方法、コアは設定の実行、ルールは接続先のポリシーを決め、システムプロキシとTUNはアプリの通信をコアに取り込む方法を担います。
各用語は関連していますが、互いに置き換えられるものではありません。サブスクリプションを読み込んでもシステム接続が有効になるとは限らず、ノードを切り替えても振り分けルールは変わりません。それぞれの解説では、用語の役割、利用条件、よくある誤解を説明します。実際に使える機能は、起動中のクライアントとコアで確認してください。
01 / PROTOCOLS
プロキシプロトコル
プロトコル名が示すのは接続方法や認証方式であり、速度の順位ではありません。ノードを選ぶ際は、サーバー側の設定、通信方式、TLS設定、コアの対応状況も確認してください。
VMessV2Ray protocol
VMessはV2Rayのエコシステムから生まれたプロトコルで、通常はUUIDでユーザーを識別し、独自の認証と通信保護の仕組みを備えています。同じVMessでも、通信方式やTLSの設定はノードによって異なります。アドレスが正しくても、他の項目を省略できるとは限りません。認証方式によっては正確なシステム時刻が必要です。接続時に認証エラーが出た場合は、まず端末の時刻とサブスクリプションの設定を確認してください。
プロトコルの違いを見る →TrojanTLS-based proxy protocol
Trojanは通常、TLSでクライアントとサーバー間の通信を保護し、パスワードで認証します。接続時のサーバー名と証明書の信頼性はTLSハンドシェイクに影響するため、サーバーアドレス、SNI、認証パスワードをそれぞれ確認してください。証明書エラーを検証の無効化で回避するのではなく、名前の一致、端末の時刻、証明書チェーンの信頼性を先に確認しましょう。
TLSとプロトコルの解説を見る →VLESSUUID-based authentication
VLESSはシンプルな認証方式を使い、通常はUUIDでユーザーを識別しますが、プロトコル自体に通信の暗号化機能はありません。安全性や互換性を判断するには、TLS、REALITY、通信方式、flowなどの関連設定も確認してください。読み込みに失敗した場合は、ノード名だけを比べるのではなく、現在のコアが設定の組み合わせに対応しているかを確認します。各設定はサーバー側の構成と一致している必要があります。
コアの互換性を見る →Hysteria2QUIC / UDP
Hysteria2はQUICをベースとし、UDP通信が可能な経路を必要とします。帯域幅に応じた輻輳制御も設定できます。パケットロスの多い環境ではTCP方式と異なる挙動を示す場合がありますが、速度はサーバー性能、回線品質、設定に左右されます。UDPが遮断されている場合や帯域幅の設定が適切でない場合、接続できなかったり不安定になったりすることがあります。モバイル端末では実際のバッテリー消費も比較してください。
用途に合わせた選び方を見る →TUICQUIC-based proxy protocol
TUICもQUICをベースとし、接続の多重化とUDP転送に対応しています。設定時には、サーバーのプロトコルバージョンや認証項目、クライアントのコアが対応する形式を確認してください。異なるバージョンの設定項目は混在させないでください。通信にはUDPが必要です。ノードをテストする際は、疎通テストの結果だけでなく、実際に使うアプリが動作するかも確認しましょう。
QUICプロトコルを比較する →
02 / CORE & CONFIG
コアと設定ファイル
クライアントの画面、実行コア、設定ファイルはそれぞれ異なる階層にあります。互換性を調べるときは、まず実際に読み込まれているコアを特定し、次に設定の構文や機能項目が対応しているか確認してください。
プロキシコアProxy core
プロキシコアは設定を読み込み、ローカルの待ち受けポートを作成し、ルールやDNSを処理してプロキシサーバーに接続します。GUIクライアントは通常、サブスクリプションの管理、設定画面、実行制御を担います。画面上の設定も、最終的にはコアが認識できる形に変換される必要があります。見た目が似たクライアントでも、使用するコアは異なる場合があります。プロトコルの対応状況は、実際に動作しているコアを確認してください。
コアの系譜を見る →mihomoClash Meta lineage
mihomoはClash Metaプロジェクトから発展したプロキシコアで、ルーティングルール、DNS、TUN、多様なプロキシプロトコルに対応しています。元のClashから設定を引き継げる場合もありますが、拡張項目が他のコアで読み込めるとは限りません。新しいプロトコルや特定のDNS設定がサブスクリプションに含まれている場合は、クライアント名だけで機能を推測せず、実際に使うバージョンのドキュメントを確認してください。
mihomo設定の互換性を見る →Clash MetaHistorical project name
Clash Metaは、Clashエコシステムの拡張コアに使われていた旧プロジェクト名です。後継プロジェクトではmihomoの名称が使われていますが、古い解説やクライアント名にMetaが残っている場合があります。名称にMetaが含まれていても、現在のコアのバージョンやソフトウェアの更新状況はわかりません。解説を読むときは、旧プロジェクト名、GUIクライアント名、実行中のコア情報を分けて確認してください。
名称と機能の違いを見る →YAMLData serialization format
YAMLはインデントでデータの階層を表す形式で、Clashの設定ではポート、ノード、プロキシグループ、ルールなどの記述に使われます。インデントにはスペースを使い、リストとキー・値の構造を正しく記述してください。特殊文字を含む文字列は、必要に応じて引用符で囲みます。YAMLとして解析できても、設定項目名や値、参照関係が正しいかはコアで別途確認が必要です。
設定の読み込み手順を見る →config.yamlRuntime configuration
config.yamlはよく使われる設定ファイル名です。ファイルには通常、ローカルの待ち受け設定、プロキシノード、プロキシグループ、DNS、ルーティングルールなどを記述します。ファイル名は変更できます。クライアントがサブスクリプションの内容にローカル設定を追加する場合、実際に読み込まれる設定はダウンロードした内容と異なることがあります。編集する前に元の設定と生成後のファイルを見分けてください。手動変更が次回の更新で上書きされる場合があります。
03 / ROUTING
ルールと振り分け
ルールが接続に適用するポリシーを判定し、プロキシグループが実際のノードを決めます。ログを確認するときは、プロキシのオン・オフだけでなく、一致したルールと最終的に使われたポリシーをあわせて見ると原因を特定しやすくなります。
ルール振り分けRule-based routing
ルール振り分けでは、ドメイン、IP、プロセスなどの条件に基づいて接続の処理方法を選びます。通常はルールモードで使われ、上から順に照合して最初に一致したルールが接続先を決めます。そのため、具体的な条件は広い範囲に適用されるルールより前に置きます。DIRECTは直接接続、REJECTは接続拒否を表します。PROXYは設定内で定義されることが多いプロキシグループ名で、標準で用意されたグループとは限りません。
ルールの順序とポリシーを見る →GeoIPIP geolocation database
GeoIPはデータベースに基づいてIPアドレスを国や地域に分類します。たとえばGEOIP,CN,DIRECTは、CNに分類されたアドレスへの接続にDIRECTを適用します。データベースの情報は物理的な位置を正確に示すものではなく、アドレス割り当てやデータ更新によって結果が変わることがあります。接続先がドメイン名の場合はIPルールの照合に名前解決が関わるため、DNS設定もあわせて確認してください。
GeoSiteCategorized domain sets
GeoSiteは、サービス、用途、地域などのラベルごとにまとめたドメイン一覧で、カテゴリ単位のルール照合に利用できます。IPの所属地域を照合するGeoIPとは異なり、GeoSiteの照合対象はドメインです。ラベルの意味はデータソースによって異なります。利用前にコアの対応状況、データファイルの有無、ラベルが存在するかを確認してください。分類名が異なるデータソース間で共通とは限りません。
ドメインルールの参考情報を見る →MATCHFinal catch-all rule
MATCHは、それまでのルールに一致しなかった接続を処理するため、通常はルール一覧の末尾に置きます。たとえばMATCH,PROXYは、残りの接続をPROXYというポリシーに渡します。ただし、そのポリシーが設定内に存在している必要があります。フォールバックルールを早い位置に置くと、後続のルールが照合されません。接続先が想定と異なる場合は、ルールの位置と適用先を確認してください。
プロキシグループProxy group
プロキシグループはノードや他のポリシーをまとめ、ルールから参照できる選択先を作ります。グループ名は設定で定義します。selectは通常、手動選択に使います。url-testはテスト結果に基づいて自動選択し、fallbackは設定順に従って障害時に切り替えます。グループ内でノードを選んでも、すべての通信がそのノードを使うわけではありません。そのグループに一致した通信だけが選択したノードを使います。
04 / SUBSCRIPTIONS
サブスクリプションとノード
サブスクリプションは設定やノードの更新元、ノードは接続情報、テスト結果は特定の時点での測定値です。それぞれを個別に確認すると、ダウンロードの失敗、設定の非互換、通信経路の問題を切り分けられます。
サブスクリプションSubscription
サブスクリプションは通常、リンクからノードや設定を取得・更新します。返される内容はYAML設定全体の場合も、ノード一覧だけの場合もあります。クライアントで対応する形式として読み込んだ後、実際に使うには設定を選択または有効化する必要があります。リンクにはアクセス用の認証情報が含まれることがあるため、パスワードと同様に管理してください。スクリーンショットやログを共有するときは、サブスクリプションのURL全体を隠しましょう。
サブスクリプションリンクの読み込み方を見る →ノードProxy node
ノードはプロキシサーバーへの接続に必要な設定一式で、通常はサーバーアドレス、ポート、プロトコル、認証情報を含みます。TLSや通信方式の設定が必要な場合もあります。ノード名は識別用のラベルにすぎず、地域名が実際の接続元や出口の所在地を保証するものではありません。選択時は、プロトコルの互換性、サーバーの稼働状況、利用するアプリでの動作も確認してください。
ノードの選び方と接続方法を見る →ノードの遅延Latency test
クライアントに表示されるノードの遅延は、ノード経由で指定されたテスト先にアクセスする所要時間を示すのが一般的です。ハンドシェイクや接続の再利用を含むかどうかは実装によって異なります。この値は利用可能な帯域幅を示すものではなく、動画、ダウンロード、ゲームの快適さを直接判断できる指標でもありません。テスト先を変えると結果も変わることがあります。タイムアウトした場合は、ログと実際のアクセス状況を確認し、認証、名前解決、通信経路の問題を切り分けてください。
ノードの速度テストの見方を見る →proxy-providersExternal node collections
proxy-providersは、mihomoの設定で外部のノード一覧を読み込む項目です。取得元にはリモートURLやローカルファイルを指定でき、プロキシグループからuseで参照します。これにより、ノードの更新とローカルのポリシーやルールを分けて管理できます。Provider用ファイルはノード一覧の形式に合っている必要があり、あらゆるサブスクリプションをそのまま利用できるとは限りません。更新間隔とキャッシュも個別に確認してください。
05 / NETWORK ACCESS
ネットワークモードとシステム接続
システムプロキシとTUNは通信を取り込む入口を担い、ルールモードはコアに入った後の経路を決めます。DNSはドメインをIPアドレスに変換する方法に関わるため、接続方式やルーティングとあわせて確認してください。
TUNモードVirtual network interface
TUNモードは仮想ネットワークインターフェースでIPパケットを受け取り、コアに渡して処理します。システムプロキシに従わないアプリの通信も取り込める場合があります。対象範囲はシステムのルーティング、権限、除外設定によって異なり、単一のスイッチだけで決まるものではありません。プロキシ経由でUDPを使えるかはノードの対応状況によります。他のVPNや仮想ネットワークアダプターと併用する場合は、ルーティングやDNSの競合も確認してください。
TUNの権限と設定を見る →システムプロキシSystem proxy settings
システムプロキシは、OSの設定でプロキシの接続先をクライアントのローカル待ち受けポートに指定する機能です。アプリがこの設定に従う場合に限り、プロキシが使われます。コマンドラインツール、独自のネットワーク処理を行うアプリ、UDP通信などは、この経路を通らない場合があります。有効にする前にクライアントが待ち受け中であることを確認してください。終了後も古いプロキシ設定が残ると、システム設定に従うアプリが接続できなくなることがあります。
システムプロキシの接続を確認する →混合ポートmixed-port
混合ポートは、同じ待ち受けポートでHTTPとSOCKSのプロキシリクエストを受け付けます。たとえばmixed-port: 7890はよく使われる設定ですが、ポート番号は変更できます。システムプロキシやアプリの設定を、実際の待ち受けアドレスとポートに合わせ、他のプロセスとの競合も避けてください。これはローカル通信の入口であり、リモートノードのポートではありません。LANからアクセスできるようにする場合は、待ち受け範囲とアクセス制御にも注意が必要です。
DNSリークDNS leak
DNSリークとは、ドメインの問い合わせが想定した名前解決経路を外れ、別のDNSリゾルバーへ送信される状態です。問い合わせたドメインが外部に知られたり、名前解決結果と実際の接続経路が食い違ったりする可能性があります。OS、ブラウザー、アプリはそれぞれ個別に問い合わせる場合があり、暗号化DNSを使っていても想定どおりにルーティングされるとは限りません。DNS設定、ブラウザー設定、コアのログを確認してください。テストページに表示された事業者名だけで判断しないようにしましょう。
DNSと接続設定を見る →Fake-IPSynthetic DNS mapping
Fake-IPは、管理対象のDNS問い合わせに合成IPアドレスを返し、元のドメインとの対応関係を保持します。後続の接続がコアに届くと、ドメインを復元してルール照合に利用できます。これらのIPアドレスは接続先サーバーの実アドレスではないため、出口の所在地を判断する材料にはなりません。LAN内のサービス、ゲーム、特殊なアプリでは除外設定が必要な場合があります。DNSモードを切り替えた後は、アプリやOSに残った古いDNSキャッシュの消去が必要になることもあります。
ドメインのルーティングについて見る →