Clashサブスクリプション形式徹底解説:YAML・Base64・サブスクリプション変換の正しい使い方
Clash YAML、汎用Base64、各クライアント独自形式の違いを解説し、サブスクリプション変換サービスの仕組み、よくある変換失敗の原因、異なるカーネル・クライアント間で同じサブスクリプションを移行する方法を紹介します。
READ →オープンソースプロジェクト・5大プラットフォーム対応クライアントがカーネル更新に継続追従
Clash全プラットフォーム対応クライアントのダウンロード窓口と設定マニュアル。サブスクリプションリンクの導入からルール分流、TUN仮想ネットワークアダプタまで、どのステップも「どこをクリックし、何が表示され、次に何をするか」が明確な手順として書かれています。トラブル対処記事と用語集も併用でき、エラーメッセージを項目別に対処できます。
Clashは単一のソフトではなく、同じカーネルを軸にした複数クライアントの集合体です。各プラットフォームにはそれぞれ活発に開発が続くGUIクライアントがあり、ダウンロードページではプラットフォームごとに選択肢・システム要件・インストール手順をまとめています。以下から該当セクションへ直接移動できます。
ルールはClashの中核機能です。すべての接続はドメイン名・IPの地域情報・プロセス名で順に照合され、条件に一致したものは対応する出口に振り分けられ、一致しなければ最後のMATCHルールで処理されます。よく使われるルールタイプにはDOMAIN-SUFFIX(ドメイン接尾辞)、DOMAIN-KEYWORD(ドメインキーワード)、GEOIP(IP地域データベース)、IP-CIDR(IPセグメント)などがあります。ルールは上から順に照合され、最初に一致したものが優先されます。手動で個別に代理設定を切り替える方式と比べ、ルール分流は一度設定すれば長期的に有効です。日本国内のサイトは直接接続、目的の海外サイトはプロキシ経由、広告ドメインは即拒否と、3種類の通信を自動で仕分けます。多くのサブスクリプションには既に実用的なルールセットが組み込まれているため、初心者がゼロから手書きする必要はありません。
ルールに一致した後の行き先を決めるのが出口で、基本は3種類あります。DIRECT(ローカルネットワークへ直接接続)、PROXY(プロキシノード経由で転送)、REJECT(接続を拒否)です。PROXYは単一ノードとは限らず、多くはポリシーグループとして構成されます。手動選択グループ(select)はユーザーがノードを指定し、自動速度テストグループ(url-test)は定期的に遅延を測定して最速のノードを選び、フェイルオーバーグループ(fallback)は優先ノードが使えなくなった際に自動的に予備ノードへ切り替えます。ポリシーグループは入れ子にできるため、たとえば「地域別グループの中に自動速度テストを組み込む」といった構成も可能です。出口ポリシーを理解すれば、ノード切り替えは謎の操作ではなくなります。クライアントのパネルで選ぶ各項目は、設定ファイル内の明確なグループとノードに対応しています。
サブスクリプションとは、サービス提供者がホストするノード情報とルール一覧を指すHTTPリンクです。クライアントの設定・サブスクページにリンクを貼り付けると、完全な設定として自動的にダウンロード・解析され、以降は設定した周期で自動更新されるため、ノードが変わってもファイルを手動で書き換える必要はありません。形式は2種類に分かれます。Clash YAML形式はそのまま直接導入可能、汎用のBase64形式はサブスクリプション変換サービスでYAMLに変換してから使用します。導入に失敗した場合は次の3点を確認してください。リンクが途中で切れていないか、返ってきた内容がWebページではなくYAMLかどうか、クライアントのカーネルバージョンが設定内で使用しているプロトコルに対応しているか。当サイトの設定ガイドページでは、導入手順を画面単位のスクリーンショット付きで解説しています。
システムプロキシは、プロキシ設定に従うアプリにしか効果がありません。コマンドラインツールやゲームクライアント、一部のデスクトップソフトはこれを無視して直接通信します。TUNモードはシステム内に仮想ネットワークアダプタを作成し、すべての通信をネットワーク層で捕捉してClashカーネルにルール処理させる仕組みで、アプリ側の対応状況に依存しません。有効化の前提として、Windowsでは管理者権限でのサービスコンポーネントのインストール、macOSではシステム拡張機能の許可、Linuxでは相応の権限が必要です。有効化後はfake-ip方式のDNS設定と併用するのがおすすめで、DNS解決がルール照合より先に行われて分流が不正確になる事態を避けられます。通常のブラウジングはシステムプロキシで十分で、全体を丸ごと制御したい場合にTUNを使うのが基本です。
ドメイン名の解決はルール照合より先に行われるため、DNS設定が不適切だと2種類の典型的な問題が発生します。1つは解決結果が汚染され、直接接続の通信が誤ったIPを取得してページが開けなくなること。もう1つは解決経路自体が誤っており、GEOIPルールがプロキシ経由の通信を誤って直接接続と判定してしまうことです。Clashカーネルは内蔵DNSサービスを提供し、fake-ipとredir-hostの2モードに対応しています。fake-ipは予約アドレス帯の仮のIPを返し、実際の解決経路は接続確立時にカーネルが判断する仕組みで、TUNとの組み合わせが最も安定します。redir-hostは従来型の解決に近い挙動で、IPに敏感な一部アプリとの互換性に優れます。多くのサブスクリプションには既に使用可能なDNS設定が含まれているため、「接続済みなのにページが開けない」場合はまずここを確認してください。
Clashはもともと、Go言語で書かれたオープンソースのルールベースプロキシカーネルとして登場し、「1つのYAML設定ファイルで全動作を記述する」という設計思想により技術コミュニティで広く採用されました。オリジナルのリポジトリがアーカイブされた後、コミュニティのフォークであるClash.Metaが開発を継続し、Mihomoへと名称を変更。現在では事実上の標準カーネルとして、対応プロトコルの充実度、ルールタイプの豊富さ、TUN実装の完成度において優れており、主要なGUIクライアントはすでにこのカーネルへ移行しています。
GUIクライアントとカーネルは役割が分かれています。カーネルはプロトコルハンドシェイク、ルール照合、通信転送を担当し、クライアントはサブスクリプション管理、UI、システム統合を担当します。Clash Plus、Clash Verge Rev、FlClashなどのクライアントはそれぞれ独立して開発・保守されていますが、同一のYAML設定形式を読み込みます。つまりサブスクリプションとルールは異なるクライアント間でそのまま移行でき、クライアントを変えても設定をゼロから学び直す必要はありません。
カーネルと各クライアントのコードはすべて公開リポジトリで管理されており、コミット履歴・議論・リリース情報は誰でも確認できます。バージョン更新は各プロジェクトのコミュニティ主導で行われ、カーネルはプロトコルとルール実装を修正し、クライアントはカーネルのバージョンに追従しつつUIを改善していきます。当サイトのダウンロードページに掲載するバージョン情報とインストーラーは各プロジェクトの正式リリースチャンネルと同期しており、独自の改変配布は行っていません。
設定形式はプレーンテキストのYAMLです。これには実務上の利点があります。どんな設定上の問題も「ファイルの何行目に何が書かれているか」に還元できるため、バックアップも比較も、記事内での行単位の解説も可能になります。当サイトの設定ガイドとトラブル対処記事はすべてこの形式を前提に書かれており、自分の設定ファイルを手元に置いて照らし合わせながら操作できます。
git clone https://github.com/MetaCubeX/mihomo.git
カーネルのソースコードリポジトリです。一般ユーザーがビルドする必要はなく、ダウンロードページからGUIクライアントを入手すればそのまま使えます。
Clash YAML、汎用Base64、各クライアント独自形式の違いを解説し、サブスクリプション変換サービスの仕組み、よくある変換失敗の原因、異なるカーネル・クライアント間で同じサブスクリプションを移行する方法を紹介します。
READ →通信の遅さをノード・回線・ローカル設定の3層に分けて切り分ける方法を解説。まず遅延テストとノード切り替えで問題箇所を特定し、次にプロトコルとポートの選択を確認、最後にシステムプロキシ・DNS・分流ルールが直接接続の通信を遅くしていないかを確認します。
READ →起動時に bind: address already in use エラーが出た場合の対処手順を解説。netstatやlsofでポート7890を使用しているプロセスを特定し、プロセスを終了するかポートを変更するかを判断、ポート変更後にシステムプロキシ設定を合わせる手順まで紹介します。
READ →