プロキシプロトコル
ノード名の後ろの括弧にある単語が、暗号化方式・ハンドシェイク速度・コアの互換性を決める。まずこれらを理解してから選ぶと、選定で迷わない。
Shadowsocksプロキシプロトコル
初期から広く使われている暗号化プロキシプロトコル。構造が単純でハンドシェイクの負荷も小さい。設定はサーバーアドレス・ポート・パスワード・暗号化方式の4項目のみ。リソース消費が少なく、古い端末やルーターでも安定動作するため、今もサブスクリプションでよく見かける。
VMessプロキシプロトコル
V2Ray プロジェクトが設計したプロトコル。ユーザーID認証と時刻検証を備え、Shadowsocksより機能が豊富で、WebSocketやTLSなど複数のトランスポート層と組み合わせられる。注意点:端末の時刻が90秒以上ずれていると接続に失敗する。ノードの不調を調べる際はまず時刻を確認する。
Trojanプロキシプロトコル
プロキシ通信を標準的なHTTPSに偽装するプロトコル。通常のWebアクセスに近い挙動を示す。有効なTLS証明書が必須で、設定項目が少なく実装も軽量。速度と安定性はトップクラス。
VLESSプロキシプロトコル
VMess を簡略化した後継プロトコル。内蔵の暗号化を廃止し、暗号化を完全にTLS層に委ねることでオーバーヘッドを抑える。REALITYやXTLSなど新しいトランスポート方式と組み合わせて使われることが多い。Clashエコシステムではmihomoコアが必要。
Hysteria2プロキシプロトコル
QUIC(UDP)をベースにした新世代プロトコル。独自の輻輳制御により高パケットロス環境で速度を確保する。長距離・不安定な回線での体感向上が顕著。ただし一部ネットワークはUDPを制限するため、そのような場合はTCP系プロトコルに切り替える。mihomoコアが必要。
TUICプロキシプロトコル
同じくQUICを基盤とする軽量プロトコル。0-RTTによる高速ハンドシェイクと多重化が特徴。Wi-Fiとモバイル回線の切り替え時に再接続が速く、設定もHysteria2よりシンプル。mihomo系コアのみ対応。
コアとクライアント
コアが実際の処理を担い、クライアントはUIを提供する。この2つの層を分けて理解すれば、「どのソフトを使うか」「どのプロトコルに対応しているか」の答えが見えてくる。
mihomoコアとクライアント
現在のClashエコシステムで事実上の主力コア。Clash Meta プロジェクトを継承したもので、元のコアにVLESS・Hysteria2・TUICなどの新プロトコルや追加のルールタイプを実装している。Clash Verge Rev や FlClash など主流クライアントに内蔵されているのはこれ。
Clash 原版コアコアとクライアント
Clash プロジェクト最初のコアプログラム。YAML設定形式とルール分流モデルを定義した。2023年に開発が停止し、以降の新プロトコルや新機能はすべてmihomoが引き継いでいる。古いチュートリアルで言う「Clashコア」はこれを指すことが多く、設定は概ね互換性があるが新しいフィールドは動作しない。
Clash Verge Revコアとクライアント
Windows・macOS・Linuxの3プラットフォームに対応する主流クライアント。Clash Verge の開発停止後、コミュニティが引き継いだフォーク。mihomoコアを内蔵し、サブスクリプション管理・TUNモードの切り替え・システムプロキシの引き受けに対応。Windowsでは WebView2 コンポーネントが必要で、インストールエラーが出たらまずこれを確認する。
FlClashコアとクライアント
Flutterで開発されたマルチプラットフォームクライアント。一つのUIでデスクトップとAndroidをカバーする。同じくmihomoを内蔵し、初期設定不要で使いやすく、初心者にも親切な画面設計。モバイルとデスクトップで操作ロジックが統一されており、端末を変えても迷わない。
設定ファイルのフィールド
config.yaml を開いたときに見える主なトップレベルフィールド。理解しておけば、エラーメッセージが指す箇所をすぐに特定できる。
YAML設定ファイルのフィールド
Clash設定ファイルで使われるテキスト形式。インデントで階層を表現する。鉄則はひとつだけ:インデントは必ず半角スペースを使うこと。タブが1つ混じるだけで設定全体の解析に失敗する。編集前にエディタがインデントを自動変換しないか確認しておく。
mixed-port設定ファイルのフィールド
混合リスニングポート。同じポートでHTTPとSOCKS5両方のプロキシ要求を受け付ける。デフォルト値は7890がよく使われる。個別に設定するportやsocks-portと並ぶ方式だが、新しい設定ではmixed-portの一項目だけで十分で、システムプロキシもターミナルツールもここを指定すればよい。
proxies設定ファイルのフィールド
ノード一覧フィールド。各項目にサーバーの名前・種類・アドレス・ポート・プロトコルパラメータを記述する。サブスクリプション更新の実体はこのリストの書き換えにほかならない。ノードを手動で書く際はnameを重複させないこと。後に書いたものが上書きされる。
proxy-groups設定ファイルのフィールド
策略組(プロキシグループ)フィールド。proxiesのノードを用途別にグループ化し、選択ロジックを定義する。ルールが一致した時点で直接ノードを指すのではなく、まず策略組を指し、グループ内の戦略が最終的な出口を決める。クライアント画面の「ノード切り替え」で変更しているのはこれ。
サブスクリプションリンク設定ファイルのフィールド
プロバイダーが提供する1本のURL。アクセスすると完全なノード設定が返される。クライアントは一定間隔または手動操作で再取得し、ノード一覧が自動的に更新される。リンク自体はアカウント認証情報と同等であり、公開グループへの投稿やスクリーンショットへの写り込みに注意する。
ルールと分流
rules リストは上から順に照合され、一致した時点で処理を止める――これをまず覚えておけば、以下の5項目はすべてこの原則の延長にある。
ルールモード(mode: rule)ルールと分流
Clashの3つの動作モードのひとつで、日常使いでの推奨モード。通信を rules リストと上から順に照合し、一致した時点で処理を止める。他の2つはglobal(全通信をプロキシ経由)とdirect(全通信を直接接続)で、一時的な検証に使い、終わったら元に戻すこと。
DOMAIN-SUFFIXルールと分流
ドメインの末尾で一致させるルールタイプ。例えばDOMAIN-SUFFIX,youtube.comはyoutube.comとそのすべてのサブドメインに一致する。ルール一覧で最も出現頻度の高いタイプ。末尾のみに一致し、「ドメインに特定の単語を含む」場合には一致しない点に注意。
GEOIPルールと分流
宛先IPの地理的所属で一致させるルールタイプ。最も一般的な書き方はGEOIP,CN,DIRECT――中国本土のIPを直接接続にする設定。ローカルのGeoIPデータベースに依存し、データベースが古いと一部アドレスの判定を誤ることがある。通常はルール一覧の後方に受け皿として配置する。
MATCHルールと分流
ルール一覧の最後に置く受け皿ルール。それまでに一致しなかった通信すべてに一致する。これがないと未一致通信の挙動が不定になる。設定を確認する際は、まず最終行がMATCHかどうか、次にそれがどの策略組を指しているかを見る。
url-test と selectルールと分流
最も使われる2種類の策略組タイプ。url-testはテスト先へ定期的にリクエストを送り、最も低遅延のノードを自動選択する。selectは完全手動で、選んだノードにそのまま接続する。動画視聴はurl-testで安定性を確保し、IPに敏感なサービスへのログインはselectで固定ノードを指定する。
動作モードとネットワーク
「プロキシを有効にしたのに反映されない」といった問題の答えは、ほぼこの5項目のどこかに隠れている。
システムプロキシ動作モードとネットワーク
OSレベルのプロキシ設定で、クライアントがワンクリックで書き込む。ブラウザなど「規則を守る」アプリは従うが、多くのターミナルツールやゲーム、一部のクライアントソフトは無視する。こうした通信は環境変数を個別設定するか、TUNモードで引き受ける必要がある。
TUN モード動作モードとネットワーク
クライアントが仮想ネットワークカードを作成し、ネットワーク層で全通信を引き受ける方式。アプリの協力を必要とせず、システムプロキシより網羅性が高く、ターミナルやゲームもすべてプロキシ経由になる。有効化には管理者権限またはシステム拡張の許可が必要で、システムプロキシとは二択、同時に有効化しないこと。
Fake-IP動作モードとネットワーク
DNS処理方式の一種:クライアントが予約アドレス帯の偽IPを先に返し、実際の解決は通信発生時まで遅延させる。DNS往復が1回省けるため接続確立が速く、DNS汚染も回避できる。実IPに依存する一部のLANアプリで異常が出る場合は fake-ip-filter で除外できる。
DNS リーク動作モードとネットワーク
プロキシ有効時でも、ドメイン解決要求がローカルネットワークから直接送られてしまう現象。通信内容はプロキシ経由でも、「どのドメインを問い合わせたか」がローカルネットワークに漏れてしまう。TUNモードとFake-IPの併用が一般的な対策で、設定変更後はオンラインDNS検査ページで確認しておく。
ノード遅延動作モードとネットワーク
クライアントがテスト用URLにリクエストして測る応答時間(ミリ秒単位)。これは「端末からノードを経由してテスト先まで」の経路全体を反映するもので、ノード自体の性能とは限らない。すべてタイムアウトする場合はノードを疑う前に、サブスクリプションの有効期限、端末の時刻、ポートの占有状況の順に確認する。
用語を確認できたら、次は2つの選択肢。概念は分かるが手を動かせていないならチュートリアルでサブスクリプションのインポートから始めよう。具体的なエラーで詰まっているならトラブル対処にすでに答えがある可能性が高い。クライアントがまだ入っていないならクライアントダウンロードページでプラットフォームに合ったインストーラーを入手できる。