【完全版】Clash Metaとは？設定・使い方・特徴を徹底紹介

By /

【完全版】Clash Metaとは？設定・使い方・特徴を徹底紹介

インターネットの自由な利用や、高度なネットワーク制御を実現したいと考えるユーザーにとって、プロキシソフトウェアは非常に重要な役割を果たします。中でも、近年注目を集めているのが「Clash」とその派生プロジェクトです。本記事では、数あるClashフォークの中でも特に高機能で柔軟性が高いと評判の「Clash Meta」に焦点を当て、その全てを徹底的に解説します。

約5000語にわたる詳細な解説を通じて、Clash Metaの基本的な概念から、具体的な設定方法、高度な使い方、そして利用上の注意点まで、初心者から上級者まで役立つ情報を網羅しています。ぜひ最後までお読みいただき、Clash Metaの強力な機能を使いこなすための一歩を踏み出してください。

はじめに：なぜClash Metaに注目するのか？

現代において、インターネット上の情報へのアクセスは、国や地域、ネットワーク環境によって制限されることがあります。また、セキュリティやプライバシー保護の観点から、自身の通信経路をコントロールしたいというニーズも高まっています。こうした課題を解決するためのツールとして、プロキシソフトウェアが広く利用されています。

Clashは、その洗練されたルールベースルーティング機能と多様なプロトコルサポートにより、多くのユーザーから支持を得てきたプロキシソフトウェアです。しかし、オリジナルのClashプロジェクトは開発が停滞したり、特定の機能が不足していたりといった課題も抱えていました。

そこで登場したのが、Clashのソースコードを基に開発された様々なフォークプロジェクトです。これらのフォークは、オリジナルのClashにはない新機能の追加、バグ修正、パフォーマンス改善などを行い、ユーザーの多様なニーズに応えようとしています。

「Clash Meta」もそうしたClashフォークの一つですが、特に最新のプロトコルへの対応の速さ、高度なカスタマイズ機能（特にLuaスクリプト）、動的な設定管理機能などにおいて、他のフォークやオリジナルClashと比較して一歩リードしていると評価されています。そのため、より高度なネットワーク制御や、最新技術を活用した安定した通信環境を求めるユーザーの間で急速に普及しています。

この記事では、Clash Metaがなぜここまで注目されているのか、その秘密を解き明かし、導入から活用までを完全にガイドします。

1. Clash Metaの基本的な概念

まず、Clash Metaを理解するための前提として、プロキシソフトウェアの基本的な概念と、Clashプロジェクト全体について解説します。

1.1 プロキシソフトウェアとは？

プロキシソフトウェアは、あなたの端末（PCやスマートフォン）とインターネット上のサーバーの間に入り、通信を中継する役割を果たします。これにより、以下のような様々なメリットが得られます。

  • 匿名性・プライバシー保護: プロキシサーバーを経由することで、あなたの実際のIPアドレスを隠し、通信元を特定されにくくします。
  • 地理的制限の回避: アクセスしたい情報やサービスが特定の地域からしか利用できない場合、その地域に設置されたプロキシサーバーを経由することでアクセス可能になります。
  • 検閲の回避: 特定のウェブサイトやサービスへのアクセスがネットワーク管理者や政府によってブロックされている場合、プロキシを経由することでブロックを迂回できることがあります。
  • セキュリティ向上: プロキシサーバー側で悪意のあるサイトへのアクセスをブロックしたり、通信を暗号化したりすることができます。
  • ネットワーク制御: 通信の種類や宛先に応じて、使用するプロキシサーバーや通信経路を細かく制御できます。

1.2 Clashとは？（オリジナルのClashプロジェクト）

Clashは、もともとGo言語で書かれた、ルールベースのネットワークルールを記述できるプロキシコアです。その最大の特徴は、YAML形式で記述された柔軟な設定ファイルに基づいて、通信の宛先（ドメイン、IPアドレス）、通信プロトコル、プロセスなどの条件に応じて、どのプロキシサーバーを使うか、あるいは直接接続するか、接続を拒否するかといったルーティングを自動的に行う点です。

Clashは、様々なプロトコル（Shadowsocks, Vmess, Trojanなど）をサポートし、HTTP/SOCKS5プロキシとして動作したり、TUNモードを使用してOSレベルでトラフィックを捕捉したりするなど、多機能性も備えていました。この強力なコア機能が、多くのサードパーティ製クライアント（Clash for Windows, ClashX, Clash for Androidなど）を生み出し、Clashエコシステムを形成する原動力となりました。

1.3 Clash Metaとは？（Clashのフォーク）

「Clash Meta」は、オリジナルのClashコアをフォーク（派生・複製）して開発されているプロジェクトです。オリジナルのClashのソースコードをベースに、開発者たちが独自の機能追加や改善を行っています。

フォークが行われる背景には、オリジナルの開発が停止・遅延したり、特定の機能要望が取り入れられなかったり、あるいは単に開発者が独自のビジョンを追求したいといった様々な理由があります。Clash Metaは、特に新しいプロトコルへの迅速な対応や、オリジナルのClashにはない高度な機能（Luaスクリプト、最新のVLESS/Trojan拡張、Hysteria2など）の実装に力を入れています。

Clash Metaはあくまで「プロキシコア」であり、単体のGUIアプリケーションとして提供されるわけではありません。多くのユーザーは、Clash Metaコアを内蔵したサードパーティ製クライアントアプリケーション（例: Clash Verge、Stash (iOS) など）を利用するか、あるいはCLI版のClash Metaを直接実行し、WebUI（Yacdなど）を通じて管理します。

1.4 Clash Metaが登場した理由・Clashとの違い

Clash Metaが登場した主な理由は、オリジナルのClashプロジェクトの保守状況と、ユーザーが求める新機能への対応の遅れにあったと言われています。特に、VLESSプロトコルのXTLSやRealityといった新しい技術、あるいはHysteria/Hysteria2のようなUDPベースの高速プロトコルなどは、オリジナルのClashでは公式にはサポートされないか、サポートされても時間がかかりました。

Clash Metaは、こうした新しい技術を積極的に取り込み、ユーザーに提供することで、より高性能かつ安定した、そして検閲耐性の高い通信手段を提供することを目指しています。

オリジナルのClashと比較したClash Metaの主な違いは以下の通りです。

  • サポートプロトコル: VLESS XTLS/Reality, Hysteria/Hysteria2など、Clash Metaが先行してサポートしているプロトコルが多い。
  • Luaスクリプト: 設定ファイル内でLuaスクリプトを実行し、より複雑なロジックやトラフィック操作を可能にする機能はClash Meta独自の強力な機能。
  • 設定機能: Rule Provider, Proxy Providerなど、設定を外部から動的に取得・更新する機能がより洗練されている。また、Rule Setの機能などもClash Metaでより進化している。
  • 開発状況: オリジナルClashの開発が停滞気味であるのに対し、Clash Metaは比較的活発に開発・アップデートが行われている（ただし、開発者の意向や状況により変動する可能性はある）。
  • パフォーマンス・安定性: 実装によっては、特定の環境やプロトコルにおいてClash Metaの方がパフォーマンスや安定性が優れる場合がある。

ただし、Clash Metaもまたオープンソースプロジェクトであり、その開発状況は常に変動する可能性があります。利用にあたっては、最新の情報を確認することが重要です。

2. Clash Metaの主な特徴

Clash Metaが他のプロキシソフトウェアやオリジナルのClashと一線を画す、主な特徴を具体的に見ていきましょう。

2.1 高性能で柔軟なルールベースルーティング

Clash Metaの核となる機能です。YAMLファイルで定義されたルールに基づいて、あらゆるネットワークトラフィックを自動的に適切な経路に振り分けます。

  • 豊富な条件: ドメイン、IPアドレス（CIDR形式）、国・地域（GEOIP）、AS番号（GEOASN）、通信ポート、プロセス名、Rule Setなど、多様な条件でルールを記述できます。
  • 柔軟なポリシー: 条件にマッチしたトラフィックを特定のプロキシノード経由にする、プロキシグループ（後述）を使用する、直接接続する（DIRECT）、接続を拒否する（REJECT）といったポリシーを適用できます。
  • ルールの優先順位: 設定ファイルの上から順に評価され、最初にマッチしたルールが適用されるため、より具体的なルールを上に記述することで、意図した通りのルーティングを実現できます。

2.2 多様なプロトコルサポート

Clash Metaは、最新のプロトコルを含む、非常に多くのプロキシプロトコルをサポートしています。これが、検閲耐性やパフォーマンスの高い通信を実現する鍵となります。

  • 主流プロトコル: Shadowsocks(SS), Vmess, VLESS, Trojan, Snell, SOCKS5, HTTP
  • 新しい・高機能プロトコル: VLESS XTLS/Reality, Trojan gRPC/WebSocket, Hysteria, Hysteria2
  • TLS/WebSocket/gRPC: 各プロトコルは、TLSによる暗号化、WebSocketやgRPCといった汎用的なプロトコルによるカモフラージュにも対応しています。
  • Reality/XTLS: VLESSとTrojanで利用可能な技術で、TLSハンドシェイク時に偽のTLS証明書を利用することで、トラフィックをTLS通信として自然に見せかけ、ブロックされにくくする効果が期待できます。非常に強力な検閲回避手法として注目されています。
  • Hysteria/Hysteria2: UDPをベースとしたプロトコルで、TCPの遅延問題を回避し、高速で安定した通信を可能にします。特にパケットロスが多い環境や、動画視聴などで効果を発揮します。

2.3 Luaスクリプトによる高度なカスタマイズ

Clash Metaの最もユニークで強力な機能の一つです。設定ファイルの一部にLuaスクリプトを埋め込むことで、静的な設定だけでは難しい、より複雑で動的な処理を実現できます。

  • トラフィックの変更: リクエスト/レスポンスヘッダーの追加・削除・変更、コンテンツの置換など。
  • カスタムルーティング: 宛先や内容に応じたより高度なルーティングロジック。
  • 外部システム連携: 外部APIを呼び出して情報を取得し、ルーティング判断に利用するなど（制限あり）。
  • ロギング・デバッグ: より詳細なログ出力やデバッグ情報の取得。

Luaスクリプトを使いこなすには多少のプログラミング知識が必要ですが、これを活用することでClash Metaの可能性は飛躍的に広がります。

2.4 Rule Provider, Proxy Providerによる設定の動的管理

大規模な設定や、頻繁に更新されるプロキシリスト・ルールリストを扱う場合に非常に便利な機能です。

  • Rule Provider: 外部のURLからルールリストを自動的にダウンロードし、設定に組み込むことができます。GitHubなどのリポジトリで公開されている共有ルールリストを利用したり、自作のリストを管理したりするのに役立ちます。
  • Proxy Provider: 外部のURLからプロキシノードのリストを自動的にダウンロードし、設定に組み込むことができます。プロキシサービスから提供されるサブスクリプションURLを利用したり、自作のノードリストを管理したりするのに便利です。特定のタグやプロトコルでフィルタリングすることも可能です。

これらの機能により、手動で設定ファイルを編集する手間を減らし、常に最新のルールやプロキシノードを利用できるようになります。

2.5 Enhanced mode (TUN/TAP)

Clash Metaは、HTTP/SOCKS5プロキシとして動作させるだけでなく、「Enhanced mode」と呼ばれるモードで実行することができます。このモードでは、OSの仮想ネットワークインターフェース（WindowsではTUN、macOS/LinuxではTUN/TAP）を利用して、システム全体のネットワークトラフィックを捕捉・制御します。

  • システム全体のプロキシ: アプリケーションがプロキシ設定に対応しているかに関わらず、全てのトラフィック（一部制限あり）をClash Meta経由にすることができます。
  • 透過プロキシ: アプリケーション側で特別な設定は不要です。
  • Fake IP: DNSリクエストに対して偽のIPアドレスを返し、その偽IP宛ての通信を捕捉して本来の宛先にルーティングする高度なDNS/ルーティング手法も利用可能です（Fake IPモード）。

TUNモードは、システム全体の通信を網羅的に制御する上で非常に強力な機能ですが、OSのネットワークスタックと深く関わるため、設定によっては他のネットワーク機能と競合したり、トラブルが発生したりする可能性もあります。

2.6 GEOIP/GEOSITEデータベースの活用

IPアドレスの国・地域情報（GEOIP）や、特定のウェブサイトがどの地域に紐づいているか（GEOSITE）といったデータベースを利用して、よりインテリジェントなルーティングを行うことができます。

  • GEOIP: アクセス先のIPアドレスがどの国に属するかを判断し、その情報に基づいてルールを適用します。「国内のIPアドレスはDIRECT」「特定の国のIPアドレスはプロキシ経由」といった設定が容易になります。
  • GEOSITE: 主要なウェブサイト（例: Google, Facebook, Netflixなど）がどの地域に紐づいているかをまとめたデータベースです。ドメイン名に基づいて、そのサイトが属する地域のルールを適用できます。「中国国内サイトはDIRECT」「特定の海外ストリーミングサイトはプロキシ経由」といった設定に利用できます。

これらのデータベースは定期的に更新する必要があり、Clash Metaはその更新にも対応しています。

2.7 WebUIによる管理

Clash Metaコア自体はCLIアプリケーションですが、Webベースのユーザーインターフェース（WebUI）を通じて、現在のステータス確認、プロキシノードの切り替え、ログの表示、基本的な設定変更などを行うことができます。

最も一般的に利用されているWebUIは「Yacd (Yet another clash dashboard)」です。WebブラウザからClash Metaが提供するAPIポートにアクセスすることで利用できます。GUIクライアントを使用しない場合でも、Yacdを利用することで比較的容易にClash Metaの状態を把握・操作できます。

2.8 クロスプラットフォーム対応

Clash MetaコアはGo言語で書かれており、様々なOS向けにコンパイルされたバイナリが提供されています。

  • Windows
  • macOS
  • Linux (x86, ARMなど)
  • Android (Clash for Androidの派生アプリなど)
  • iOS (StashなどClash Meta互換クライアント)

これにより、デスクトップ、サーバー、モバイルデバイスなど、幅広い環境でClash Metaを利用することができます。

2.9 設定ファイルの柔軟性 (YAML形式)

設定ファイルは人間が読み書きしやすいYAML形式で記述されます。これにより、複雑なルーティングルールやプロキシ設定も構造的に分かりやすく記述できます。後述する設定ファイル詳解で、その柔軟性と記述方法を詳しく解説します。

2.10 その他の機能

  • HTTP/SOCKS5プロキシサーバー機能: Clash Meta自体をHTTP/SOCKS5プロキシサーバーとして起動し、他のデバイスから接続させることができます。
  • Relayプロキシ機能: 複数のプロキシノードをカスケード接続する機能です（ただし、設定ファイルでの明示的な定義が必要な場合が多い）。
  • Health Check機能: 定義されたプロキシノードが正常に動作しているか定期的にチェックし、利用可能なノードを判断するのに役立ちます（Proxy Providerなどと連携）。
  • Mixin機能: 複数のYAMLファイルを組み合わせて最終的な設定ファイルを生成する機能。設定の分割や再利用に便利です。

これらの特徴が組み合わさることで、Clash Metaは非常に強力で柔軟なプロキシソフトウェアとして機能します。

3. Clash Metaの導入・インストール方法

Clash Metaコアの導入は、各プラットフォーム向けのバイナリを取得し、適切な場所に配置して実行する形になります。ここでは、主要なプラットフォームにおける基本的な導入方法を説明します。なお、多くのユーザーは後述するClash Metaコアを内蔵したGUIクライアントを利用することが多いですが、ここではコア単体の導入を解説します。

注意: Clash Metaの公式バイナリは通常、GitHubのリリースページで公開されています。非公式なサイトからダウンロードしたバイナリはマルウェアなどが含まれている可能性があるため、必ず公式の情報源を利用してください。

公式GitHubリポジトリ: https://github.com/MetaCubeX/mihomo （Clash Metaの現在のリポジトリ名は mihomo です）

3.1 各プラットフォームごとのバイナリ取得方法

  1. GitHub Releasesにアクセス: 上記のGitHubリポジトリにアクセスし、「Releases」または「Tags」セクションを探します。
  2. 最新リリースを選択: 通常、最新のリリースバージョンをダウンロードします。
  3. 対応するバイナリをダウンロード: リリースアセットの中に、各OSおよびアーキテクチャ（例: windows-amd64, linux-arm64, macos-amd64 など）に対応した.zipや.tar.gz形式の圧縮ファイルがあります。ご自身の環境に合ったファイルをダウンロードします。ファイル名に premium と含まれるものは、オリジナルのClash Premium機能を一部含むバージョンですが、通常版（clash-meta または mihomo という名前を含む）で十分な機能が利用できます。

3.2 Windows版のインストールと起動

  1. バイナリの解凍: ダウンロードした.zipファイルを解凍します。解凍されたフォルダの中に mihomo.exe (または clash-meta.exe) という実行ファイルがあります。
  2. 設定ファイルの準備: Clash Metaの設定ファイル（例: config.yaml）を同じフォルダ内に用意します。設定ファイルの作成方法は後述します。
  3. コマンドプロンプトまたはPowerShellで起動:
    • 解凍したフォルダに移動します。
    • mihomo.exe -f config.yaml (または clash-meta.exe -f config.yaml) というコマンドを実行します。
    • -f オプションで設定ファイルのパスを指定します。
  4. サービスとしての実行: Windowsサービスとして登録して自動起動させることも可能ですが、別途ツールやスクリプトが必要になります。

3.3 macOS版のインストールと起動

  1. バイナリの解凍: ダウンロードした.tar.gzまたは.zipファイルを解凍します。mihomo (または clash-meta) という実行ファイルがあります。
  2. 設定ファイルの準備: 設定ファイル（例: config.yaml）を用意します。macOSの場合、デフォルトの設定ファイル探索パスは ~/.config/mihomo/config.yaml などですが、実行ファイルと同じディレクトリに置いても構いません。
  3. ターミナルで実行:
    • 解凍した実行ファイルがあるディレクトリに移動します。
    • chmod +x mihomo (または chmod +x clash-meta) で実行権限を付与します。
    • ./mihomo -f config.yaml (または ./clash-meta -f config.yaml) というコマンドを実行します。
    • -f オプションで設定ファイルのパスを指定します。
  4. 自動起動設定: Launchdなどを利用して自動起動を設定することも可能です。

3.4 Linux版のインストールと起動

  1. バイナリの解凍: ダウンロードした.tar.gzファイルを解凍します。mihomo (または clash-meta) という実行ファイルがあります。
  2. 設定ファイルの準備: 設定ファイル（例: config.yaml）を用意します。Linuxの場合、デフォルトの設定ファイル探索パスは /etc/mihomo/config.yaml または ~/.config/mihomo/config.yaml などですが、実行時に -f オプションで指定するのが確実です。
  3. ターミナルで実行:
    • 解凍した実行ファイルがあるディレクトリに移動します。
    • chmod +x mihomo (または chmod +x clash-meta) で実行権限を付与します。
    • ./mihomo -f config.yaml (または ./clash-meta -f config.yaml) というコマンドを実行します。
    • -f オプションで設定ファイルのパスを指定します。サーバーなどで利用する場合、バックグラウンド実行 (nohup ./mihomo -f config.yaml &) や screen/tmux を利用すると便利です。

  4. Systemdサービスとしての実行: サーバー環境などでは、Systemdのサービスとして登録し、システムの起動時に自動的にClash Metaが起動するように設定するのが一般的です。

    • mihomo バイナリを /usr/local/bin/ など適切な場所に配置します。
    • 設定ファイルを /etc/mihomo/config.yaml などに配置します。

    • /etc/systemd/system/mihomo.service のようなサービスファイルを以下の内容で作成します（パスは適宜修正）。

      “`ini
      [Unit]
      Description=Mihomo Proxy Service
      After=network.target

      [Service]
      Type=simple
      User=root # または非特権ユーザー
      ExecStart=/usr/local/bin/mihomo -f /etc/mihomo/config.yaml
      Restart=on-failure

      [Install]
      WantedBy=multi-user.target
      ``
      *      sudo systemctl daemon-reloadで設定を再読み込みします。
      *      sudo systemctl enable mihomo.serviceで自動起動を有効にします。
      *      sudo systemctl start mihomo.serviceでサービスを開始します。
      *      sudo systemctl status mihomo.service` でステータスを確認できます。

3.5 Android版 (Clash for Android派生)

Androidでは、Clash Metaコアを内蔵したクライアントアプリが利用可能です。代表的なものとしては、オリジナルのClash for Androidをフォークし、Clash Metaコアをサポートしたバージョンなどがあります。GitHubのClash for Android関連リポジトリや、Telegramグループなどで情報が共有されています。インストールは、提供されているAPKファイルをダウンロードして行うのが一般的です（Google Playストアには通常ありません）。

3.6 iOS版 (StashなどClash Meta互換クライアント)

iOSでは、App Storeで配信されているプロキシアプリの中に、Clash Metaコアをオプションとして選択・利用できるものがあります。代表的なものに「Stash」があります。これらのアプリはApp Storeで購入・インストールできます。アプリ内でClash Metaコアを選択し、設定ファイルをインポートして利用します。

これらの導入方法はいずれもコアを直接利用するものです。多くの場合、GUIクライアントアプリケーションがこれらのコアを内蔵しており、より簡単に設定や操作を行うことができます。GUIクライアントについては後述しますが、まずはコアの起動方法を理解しておくことが重要です。

4. Clash Metaの設定ファイル詳解

Clash Metaの機能のほぼ全ては、YAML形式で記述された設定ファイルによって制御されます。この設定ファイルを理解し、適切に記述することが、Clash Metaを使いこなす上で最も重要です。ここでは、主要なセクションとその記述方法、様々な設定例を詳しく解説します。

設定ファイルは基本的に以下の主要なセクションで構成されます。

  • port, socks-port, redir-port, tproxy-port, mixed-port, tun: リスニングポートとモードの設定
  • proxies: 個々のプロキシノードの定義
  • proxy-groups: プロキシノードをまとめたグループ定義
  • rules: ルーティングルールの定義
  • rule-providers: ルールリストを動的に取得する設定
  • proxy-providers: プロキシリストを動的に取得する設定
  • dns: DNSサーバーの設定
  • tun: TUNモードの詳細設定
  • mixin: 設定ファイルのインクルード設定
  • general: 全体的な設定（ロギングなど）

これらのセクションを順に見ていきましょう。

4.1 YAML形式の基本

YAMLは構造化されたデータを表現するための形式です。インデント（スペースまたはタブ）によって階層構造を示します。

  • キー: 値: 基本的な記述。コロンの後にスペースが必要です。
  • キー:: 値がリストの場合。
    • - 値1
    • - 値2
  • キー:: 値がネストされた構造の場合。
    • サブキー1: 値1
    • サブキー2: 値2
  • コメントは # から行末までです。

Clash Metaの設定ファイルでは、これらの記法を使ってプロキシ、ルール、グループなどを定義していきます。

4.2 主要セクション (リスニングポートとモード)

Clash Metaがどのポートで待ち受け、どのようなモードで動作するかを設定します。

“`yaml

HTTP プロキシポート

port: 7890

SOCKS5 プロキシポート

socks-port: 7891

HTTP および SOCKS5 プロキシポート (両方有効)

mixed-port: 7890

Redir/TProxy ポート (Linux 透明プロキシ)

redir-port: 7892

tproxy-port: 7893

TUNモードを有効にするか

tun:

enable: true

stack: system # または gvisor

auto-route: true

auto-redir-dns: true

disallow-raise-privileges: false

strict-route: false

device: utun

“`

  • port: HTTPプロキシとしてのみ待ち受けるポート。
  • socks-port: SOCKS5プロキシとしてのみ待ち受けるポート。
  • mixed-port: HTTPとSOCKS5の両方として待ち受けるポート。通常はこちらを使用します。
  • redir-port / tproxy-port: Linux環境での透明プロキシ（RedirTproxy）に使用するポート。iptablesなどの設定が必要です。
  • tun: TUNモードを有効にする際の設定。enable: true で有効になります。stack はネットワークスタックの実装を選択（通常は system）。auto-route はシステム全体のトラフィックを自動的にTUNインターフェース経由にするか。

これらのポート設定のうち、使用するモードに合わせて少なくとも1つ以上を有効にする必要があります。GUIクライアントを使用する場合、これらのポートはクライアントの設定画面で指定できることが多いです。

4.3 proxies: プロキシサーバーの定義

使用する個々のプロキシノードを定義します。各ノードはユニークな名前を持ち、そのプロトコルと接続情報（サーバーアドレス、ポート、認証情報など）を記述します。

“`yaml
proxies:
# Shadowsocks
– name: “Example-SS”
type: ss
server: example.com
port: 443
password: “your_password”
cipher: aes-256-gcm
udp: true # UDPを有効にするか

# Vmess + TLS + WebSocket
– name: “Example-Vmess-TLS-WS”
type: vmess
server: example.org
port: 443
uuid: “your_uuid”
alterId: 0
cipher: auto
tls: true
servername: example.org # SNI (Server Name Indication)
network: ws
ws-path: /ws
ws-headers: # WebSocket ヘッダー
Host: example.org

# VLESS + TLS + gRPC
– name: “Example-VLESS-TLS-gRPC”
type: vless
server: example.net
port: 443
uuid: “your_uuid”
tls: true
servername: example.net
network: grpc
grpc-servicename: YourServiceName

# Trojan + TLS
– name: “Example-Trojan-TLS”
type: trojan
server: example.io
port: 443
password: “your_password”
tls: true
servername: example.io

# VLESS + Reality (Clash Meta特有)
– name: “Example-VLESS-Reality”
type: vless
server: example.real # 偽装先のサーバー
port: 443
uuid: “your_uuid”
tls: true
servername: example.real # RealityではSNIは不要だが、クライアントによっては必要
network: tcp
flow: xtls-rprx-vision # XTLS フロー制御 (Realityで推奨)
client-fingerprint: chrome # クライアントTLSフィンガープリント偽装

# Hysteria2 (Clash Meta特有)
– name: “Example-Hysteria2”
type: hysteria2
server: example.cloud
port: 443
password: “your_password”
tls: true
servername: example.cloud
obfs: none # obfs 設定 (none, wechat-video など)

# SOCKS5
– name: “Example-SOCKS5”
type: socks5
server: 192.168.1.100
port: 1080
# username: “user” # 認証が必要な場合
# password: “pass”

# HTTP
– name: “Example-HTTP”
type: http
server: 192.168.1.101
port: 8080
# username: “user” # 認証が必要な場合
# password: “pass”

``
*name: プロキシノードのユニークな名前。後述のプロキシグループやルールで使用します。
*type: プロトコルタイプ (ss, vmess, vless, trojan, hysteria, hysteria2, snell, http, socks5など)。
*server: サーバーのアドレス (ドメイン名またはIPアドレス)。
*port: サーバーのポート番号。
* 各プロトコル固有のパラメータ (password,uuid,cipher,tls,servername,network,ws-path,grpc-servicename,flow,client-fingerprint,obfsなど) は、使用するプロトコルの仕様に合わせて正確に記述する必要があります。特にTLS関連の設定 (tls: true,servername,skip-cert-verify) は重要です。
*udp: true` は、そのプロキシ経由でUDPトラフィックも転送するかどうかを設定します。DNS over UDPやQuicプロトコルなどで必要になる場合があります。

4.4 proxy-groups: プロキシグループの定義

複数のプロキシノードをまとめたグループを定義します。これにより、負荷分散、フェイルオーバー、手動選択などの機能を実現できます。グループ自体も別のグループのメンバーになることができます。

“`yaml
proxy-groups:
# 手動選択グループ (Select)
– name: “Proxy”
type: select
proxies:
– “Example-VLESS-Reality”
– “Example-Hysteria2”
– “Example-SS”
– “DIRECT” # 直接接続
– “REJECT” # 接続拒否

# URLテストグループ (Url-Test) – 応答時間の速いノードを自動選択
– name: “Auto”
type: url-test
proxies:
– “Example-Vmess-TLS-WS”
– “Example-Trojan-TLS”
url: http://www.gstatic.com/generate_204 # テスト用URL (インターネット接続確認用)
interval: 300 # テスト間隔 (秒)
tolerance: 50 # テスト結果の許容誤差 (ms)

# フェイルオーバーグループ (Fallback) – 順番に試して最初に成功したノードを使用
– name: “Fallback”
type: fallback
proxies:
– “Example-Hysteria2”
– “Example-VLESS-Reality”
– “Example-SS”
url: http://www.gstatic.com/generate_204
interval: 300

# 負荷分散グループ (Load-Balance) – ランダムまたはラウンドロビンでノードを使用
# type: load-balance (Clash Metaではurl-testやfallbackで代用することが多い)

# 別のグループをメンバーにすることも可能
– name: “Global”
type: select
proxies:
– “Proxy” # Proxy グループを選択肢として含む
– “Auto”
– “DIRECT”
“`

  • name: プロキシグループのユニークな名前。ルールで使用します。
  • type: グループの動作タイプ。
    • select: 手動でメンバーから一つを選択します（WebUIなどで切り替え）。最も一般的です。
    • url-test: 設定されたURLに対して定期的に疎通確認（テスト）を行い、応答時間が最も短いプロキシノードを自動的に選択します。urlとintervalが必要です。
    • fallback: 設定された順番にプロキシノードを試し、最初に正常に接続できたノードを使用します。ノードがダウンした場合、次のノードに自動的に切り替わります。urlとintervalが必要です。
    • load-balance: ロードバランシング（負荷分散）を行います。Clash Metaではurl-testやfallbackがより実用的であるため、あまり使われないかもしれません。
  • proxies: このグループに含まれるプロキシノードの名前または他のプロキシグループの名前のリスト。
  • url, interval: url-testおよびfallbackタイプで使用するテスト用URLとテスト間隔。

4.5 rules: ルーティングルールの定義

どのトラフィックをどのプロキシグループまたはポリシーに振り分けるかを定義します。リスト形式で記述し、上から順に評価されます。最初にマッチしたルールが適用されます。

“`yaml
rules:
# 特定のドメイン (厳密一致)
– DOMAIN,example.jp,DIRECT

# 特定のドメインとそのサブドメイン (ドメインサフィックス)
– DOMAIN-SUFFIX,google.com,Proxy
– DOMAIN-SUFFIX,google.co.jp,Proxy

# ドメインに特定のキーワードが含まれる場合
– DOMAIN-KEYWORD,facebook,Proxy

# IPアドレス範囲 (CIDR)
– IP-CIDR,192.168.0.0/16,DIRECT,no-route
– IP-CIDR,10.0.0.0/8,DIRECT,no-route
– IP-CIDR,172.16.0.0/12,DIRECT,no-route
– IP-CIDR,127.0.0.0/8,DIRECT,no-route # localhost

# 国・地域 (GEOIP)
– GEOIP,CN,REJECT # 中国への通信を拒否
– GEOIP,JP,DIRECT # 日本への通信は直接接続
– GEOIP,US,Proxy # アメリカへの通信は Proxy グループ経由

# GEOSITE データベース (Clash Meta特有の拡張機能)
– GEOSITE,geolocation-cn,DIRECT,no-route # 中国国内サイトは直接
– GEOSITE,category-games@cn,Proxy # 中国国内のゲームサイトは Proxy 経由
– GEOSITE,netflix,Proxy # Netflix は Proxy 経由
– GEOSITE,youtube,Proxy # YouTube は Proxy 経由

# プロセス名 (Windows/macOS/Linux, TUNモードなど)
# – PROCESS,firefox.exe,Proxy # Firefox の通信を Proxy 経由
# – PROCESS,qv2ray,DIRECT # 特定のアプリは直接

# 宛先ポート
# – DST-PORT,22,DIRECT # SSH (ポート22) は直接

# 送信元ポート
# – SRC-PORT,53,DIRECT # ローカルDNS (ポート53) からの通信は直接

# ルールセット (Rule Providerなどで取得したリスト)
# – RULE-SET,global,Proxy # global ルールセットにマッチしたら Proxy グループ

# 上記いずれにもマッチしない場合の最終ルール (必須)
– MATCH,Global # 最後のルールとして、Global グループに振り分ける
“`

  • ルールタイプ,条件,ポリシー[,パラメータ]: 各ルールの基本的な形式。
  • ルールタイプ:
    • DOMAIN: ドメイン名と厳密に一致する場合。
    • DOMAIN-SUFFIX: ドメイン名が指定したサフィックスで終わる場合（サブドメインを含む）。最もよく使われます。
    • DOMAIN-KEYWORD: ドメイン名に指定したキーワードが含まれる場合。
    • IP-CIDR: 宛先IPアドレスが指定したCIDR範囲に含まれる場合。
    • GEOIP: 宛先IPアドレスが指定した国コード（ISO 3166-1 alpha-2）に属する場合。
    • GEOSITE: 宛先ドメインが指定したGEOSITEデータベースに含まれる場合。Clash Meta独自の強力な機能です。@cnなどを付けると、データベース内の特定地域に関連する項目のみに絞ることができます。
    • PROCESS: 通信を開始したプロセス名にマッチする場合（TUNモードなどで有効）。
    • DST-PORT: 宛先ポートにマッチする場合。
    • SRC-PORT: 送信元ポートにマッチする場合。
    • RULE-SET: Rule Providerなどで定義されたルールセットにマッチする場合。
    • MATCH: 上記いずれのルールにもマッチしない場合。これは必ずリストの最後に配置する必要があります。
  • 条件: 各ルールタイプに対応した条件値（ドメイン名、IPアドレス/CIDR、国コード、キーワードなど）。
  • ポリシー: 条件にマッチした場合に適用するポリシー。
    • プロキシグループの名前 (Proxy, Auto, Fallback, Global など)
    • DIRECT: プロキシを使用せず直接接続。
    • REJECT: 接続を拒否。
  • パラメータ: 一部のルールタイプで追加パラメータを指定できます。
    • no-route: TUNモードなどで使用。IPルールがマッチしても、OSのルーティングテーブルを変更しないように指示します。ローカルIPアドレスのDIRECTルールなどで使用します。

ルールの記述順序は非常に重要です。より具体的なルール（例:特定のドメイン）を上に、より一般的なルール（例: GEOIP, MATCH）を下に配置するのが基本です。

4.6 rule-providers: ルールセットの動的取得

外部のURLからルールリストを自動的にダウンロードし、rulesセクションで参照できるようにします。

“`yaml
rule-providers:
# 中国国内サイト向けルールセット
cn_rules:
type: http
behavior: domain # ルールの形式 (domain, ipcidr, classical)
url: “https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/CN.yaml”
path: “./rules/cn.yaml” # ダウンロードしたファイルを保存するパス
interval: 86400 # 更新間隔 (秒)

# 海外サイト向けルールセット (例)
global_rules:
type: http
behavior: domain
url: “https://example.com/rules/global.yaml”
path: “./rules/global.yaml”
interval: 86400

rules セクションで参照

rules:
– RULE-SET,cn_rules,DIRECT
– RULE-SET,global_rules,Proxy
# … その他のルール
“`

  • [provider_name]: プロバイダーの名前（任意）。
  • type: 取得方法。現在は http が一般的です。
  • behavior: ルールリストの形式。domain, ipcidr, classical などがあります。多くの場合、ルールリストの提供元が形式を指定しています。domain は主に DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD ルール、ipcidr は IP-CIDR ルール、classical は Clashespecの従来のルール形式に対応します。
  • url: ルールリストのダウンロード元URL。
  • path: ダウンロードしたファイルをローカルに保存するパス。./ は設定ファイルからの相対パスです。
  • interval: ルールリストを更新する間隔（秒単位）。

Rule Providerで取得したルールセットは、rulesセクションで RULE-SET,[provider_name],[ポリシー] の形式で参照します。

4.7 proxy-providers: プロキシノードの動的取得

外部のURLからプロキシノードのリストを自動的にダウンロードし、proxiesセクションと同様に利用できるようにします。Proxy Providerで取得したノードは、proxy-groupsセクションで名前を指定して利用します。

“`yaml
proxy-providers:
# サブスクリプションURLからノードを取得
my_service:
type: http
url: “https://your.proxy.service/subscribe?token=xxx”
interval: 3600 # 更新間隔 (秒)
path: “./proxies/my_service.yaml” # ダウンロードしたファイルを保存するパス
health-check: # ヘルスチェック設定 (オプション)
enable: true
interval: 600 # チェック間隔 (秒)
url: http://www.gstatic.com/generate_204
filter: “名前をフィルタリングするための正規表現 (例: .(JP|US).” # ノード名を正規表現でフィルタ

proxy-groups セクションで参照

proxy-groups:
– name: “My Proxies”
type: select
# Proxy Provider で取得したノードは provider/[provider_name] の形式で参照
proxies:
– “provider.my_service” # my_service プロバイダーで取得した全てのノード
– “DIRECT”
“`

  • [provider_name]: プロバイダーの名前（任意）。
  • type: 取得方法。現在は http が一般的です。
  • url: プロキシノードリストのダウンロード元URL。プロキシサービスから提供されるサブスクリプションURLなどを使用します。
  • interval: プロキシリストを更新する間隔（秒単位）。
  • path: ダウンロードしたファイルをローカルに保存するパス。
  • health-check: 取得したノードに対して定期的にヘルスチェックを行うかどうかの設定。enable: true で有効化し、intervalでチェック間隔、urlでテスト用URLを指定します。
  • filter: 正規表現を使用して、取得したノードの中から特定の名前のノードのみを選択的に含めることができます。

Proxy Providerで取得したノードは、proxy-groupsセクションのproxiesリスト内で "provider.[provider_name]" の形式で参照します。これにより、プロバイダーが提供する全てのノードをグループに含めることができます。特定のノードだけを選びたい場合は、手動でproxiesセクションに定義するか、フィルタ機能を利用します。

4.8 dns: DNS設定

DNS（Domain Name System）は、ドメイン名をIPアドレスに変換する仕組みです。Clash Metaは独自のDNSサーバー機能を持っており、高度なDNS制御が可能です。

“`yaml
dns:
enable: true # DNS サーバー機能を有効にするか
listen: 0.0.0.0:53 # 待ち受けIPアドレスとポート (通常は 0.0.0.0:53)
enhanced-mode: fake-ip # または redir-host, tun
# fake-ip-range: 198.18.0.1/16 # Fake IP で使用する IP アドレス範囲

# アップストリーム DNS サーバー (優先的に使用される)
nameserver:
– 114.114.114.114 # 中国国内向け DNS (例)
– 223.5.5.5 # 中国国内向け DNS (例)
– https://doh.pub/dns-query # DNS over HTTPS (DoH)
– tcp://8.8.8.8:53 # DNS over TCP (DoT)

# フォールバック DNS サーバー (アップストリームが失敗した場合や特定のルールにマッチした場合に使用)
fallback:
– 8.8.8.8 # Google Public DNS
– 8.8.4.4 # Google Public DNS
– https://cloudflare-dns.com/dns-query # Cloudflare DoH

# フォールバックを使用する条件
fallback-filter:
geoip: true # GEOIP データベースで中国国内と判断された IP アドレスに対してはフォールバックを使用しない (中国国内 DNS の結果を優先)
geoip-code: CN # geoip: true の場合に、どの国コードを対象とするか
ipcidr: # これらの CIDR に含まれる IP アドレスに対してはフォールバックを使用しない
– 240.0.0.0/4
domain: # これらのドメインにマッチする場合はフォールバックを使用しない
– +.google.com
– +.facebook.com
– +.twitter.com
– +.youtube.com

# 特定のドメインに使用する DNS サーバー (ルールベース DNS)
# nameserver-policy:
# “geosite:cn”: [114.114.114.114] # 中国国内サイトは中国国内 DNS
# “rule-set:private”: [tcp://192.168.1.1:53] # プライベートなルールセットにマッチするドメインはローカル DNS

# Fake IP モードで、Fake IP を返さないドメイン
# fake-ip-filter:
# – +.cn
# – +.lan
# – localhost
# – +.local
# – captive.apple.com
“`

  • enable: DNSサーバー機能を有効にするか。通常は true にします。
  • listen: DNSサーバーが待ち受けるIPアドレスとポート。他のデバイスからアクセスさせたい場合は 0.0.0.0:53、ローカルホストのみで十分なら 127.0.0.1:53 など。
  • enhanced-mode: DNS処理のモード。
    • fake-ip: Fake IPモードを有効にします。Clash MetaがDNSリクエストを受け取ると、Fake IPアドレスを返し、そのIPアドレス宛ての通信を捕捉して本来の宛先にルーティングします。これにより、アプリケーションはプロキシ設定を意識せず透過的に動作できます。
    • redir-host: DNSリクエストをアップストリームDNSサーバーに直接転送し、返ってきたIPアドレスに基づいてルーティングします（TUNモードで有効）。
    • tun: TUNモードで使用されるデフォルトのモード（?）。
  • nameserver: 優先的に使用するアップストリームDNSサーバーのリスト。通常のDNS (UDP/53)、DNS over TLS (DoT), DNS over HTTPS (DoH) などが指定できます。
  • fallback: アップストリームDNSサーバーが応答しない場合や、特定の条件にマッチした場合に使用するフォールバックDNSサーバーのリスト。
  • fallback-filter: どのような場合にフォールバックDNSを使用しないかの条件を設定します。GEOIPや特定のIP/ドメインリストに基づいて制御できます。中国国内のIPアドレスに対しては海外のDNSを使用しないようにする、といった設定に利用されます。
  • nameserver-policy: Clash Meta独自の機能。特定のドメインやルールセットにマッチするドメインに対して、使用するDNSサーバーを個別に指定できます。これにより、より柔軟なDNSルーティングが可能になります。
  • fake-ip-filter: Fake IPモードを使用している場合に、これらのドメインに対してはFake IPを返さず、通常のIPアドレスを返すように設定します。ローカルネットワーク内のデバイスや、特定のサービスのドメインなどでFake IPを使用しないようにする場合に役立ちます。

適切なDNS設定は、高速かつ正確なルーティング、そして検閲回避において非常に重要です。特に中国国内と海外で異なるDNSサーバーを使い分けたい場合などは、fallback-filterやnameserver-policyが役立ちます。

4.9 tun: TUNモードの詳細設定

tunセクションでは、Enabled mode（TUN/TAP）に関する詳細な設定を行います。

yaml
tun:
enable: true # TUNモードを有効にするか
stack: system # ネットワークスタック (system または gvisor)。Windows では system のみ。
auto-route: true # システムのルーティングテーブルを自動的に変更して、全てのトラフィックを TUN デバイスにリダイレクトするか。
auto-redir-dns: true # システムのDNS設定を自動的に変更して、Clash Meta の DNS サーバーに向けるか。
disallow-raise-privileges: false # 特権昇格を許可するか (Windows)。通常は false で良い。
strict-route: false # 厳密なルーティングを使用するか (より正確だが互換性の問題が生じる可能性)。
device: utun # macOS の場合、使用する TUN デバイス名 (utun が一般的)。
# dns-hijack: # DNS ハイジャック設定 (auto-redir-dns が true の場合、通常は自動設定される)
# - 0.0.0.0:53
# - 1.1.1.1:53

  • enable: TUNモードを有効にするか。
  • stack: 使用するネットワークスタック実装。systemはOSネイティブの機能を利用し、gvisorはGo言語で書かれたユーザー空間のネットワークスタックを利用します。互換性やパフォーマンスに違いがありますが、通常はsystemが推奨されます。Windowsではsystemのみサポートされます。
  • auto-route: trueにすると、Clash Metaが起動時にシステムのルーティングテーブルを変更し、ほとんど全てのトラフィックをTUNインターフェースにリダイレクトします。これにより、アプリケーション側でプロキシ設定をしなくても、自動的にClash Metaを経由するようになります。
  • auto-redir-dns: trueにすると、システムのDNS設定をClash MetaのDNSサーバー（通常はlistenで指定したアドレス/ポート）に自動的に変更します。これにより、DNSリクエストもClash Metaを経由するようになります。
  • device: macOSの場合、TUNデバイスの名前を指定します。通常はutunで動作しますが、環境によっては異なる場合があります。

TUNモードは非常に便利ですが、他のVPNソフトウェアやネットワーク仮想化ソフトウェアと競合する可能性があります。また、auto-route: trueはシステムのネットワーク設定に影響を与えるため、使用する際は注意が必要です。

4.10 mixin: 設定ファイルの分割・結合

設定ファイルを複数のファイルに分割し、それを組み合わせて最終的な設定ファイルを生成する機能です。大規模な設定や、設定の一部を再利用したい場合に便利です。

“`yaml

config.yaml (メイン設定ファイル)

port: 7890
mixed-port: 7890

…その他の設定

mixin 設定で他のファイルをインクルード

mixin:
# proxies セクションを proxies.yaml から読み込む
proxies:
– ./proxies.yaml
# proxy-groups セクションを groups.yaml から読み込む
proxy-groups:
– ./groups.yaml
# rules セクションを rules.yaml から読み込む
rules:
– ./rules.yaml

proxies.yaml

proxies:
– name: “Node A”
type: vmess
# …
– name: “Node B”
type: trojan
# …

groups.yaml

proxy-groups:
– name: “Main Proxy Group”
type: select
proxies:
– “Node A”
– “Node B”
– “DIRECT”

rules.yaml

rules:
– DOMAIN-SUFFIX,example.com,Main Proxy Group
# …
– MATCH,DIRECT
“`

mixinセクションで、各セクションに対応するキーの下に、インクルードしたいYAMLファイルのパスをリスト形式で指定します。Clash Meta起動時に、これらのファイルの内容が読み込まれ、メインの設定ファイルに統合されます。

4.11 general: 全体的な設定

ロギング、API設定、外部コントローラー設定など、全体的な動作に関する設定を行います。

“`yaml
general:
# ロギングレベル (debug, info, warning, error)
log-level: info

# API 設定
external-controller: 127.0.0.1:9090 # WebUI などが接続する API アドレスとポート
secret: “your_api_secret” # API 接続用の認証トークン (オプション)
# external-ui: /path/to/webui # WebUI ファイルのパス (Clash Meta に内蔵させる場合)
# external-ui: https://yacd.haishoku.me/ # WebUI の URL を指定 (WebUI ファイルを内蔵させない場合)

# DNS サーバーの応答 TTL を強制的に上書きするか (秒)
# min-ttl: 300
# max-ttl: 3600

# HTTP Keep-Alive を有効にするか
# http-keepalive: true

# HTTP プロキシ経由で DNS リクエストを転送するか (DoH/DoT が使えない場合など)
# dns-over-http: false

# ルールマッチング時にプロセス情報を取得するか (パフォーマンスに影響する場合あり)
# enable-meta-rules: true # Clash Meta 独自のルール拡張機能
# enable-process-rule: true # PROCESS ルールを有効にするか

# 接続タイムアウト (秒)
# connect-timeout: 10

# 遅延テスト URL とタイムアウト (url-test/fallback グループで使用)
# url-test-url: http://www.gstatic.com/generate_204
# url-test-timeout: 5

# リモートプロファイル更新の際にキャッシュを無視するか
# skip-verify: false # SSL 証明書の検証をスキップ (非推奨)
“`

  • log-level: Clash Metaが出力するログの詳細度を設定します。デバッグやトラブルシューティング時にはdebugにすると多くの情報が得られます。
  • external-controller: WebUIなどがClash Metaと通信するためのAPIのアドレスとポートを指定します。通常はローカルホスト (127.0.0.1) の適当なポート (9090 など) を使用します。
  • secret: API接続に認証が必要な場合に設定します。任意の文字列を指定し、WebUI側で同じ値を設定します。セキュリティのため設定することを推奨します。
  • external-ui: WebUIのファイルをローカルに配置するか、外部URLを参照するかを設定します。pathを指定するとClash MetaのバイナリにWebUIが内蔵されている場合にそれを利用するか、ローカルに配置したWebUIファイルを利用します。URLを指定すると、WebブラウザでそのURLにアクセスしてClash MetaのAPIに接続する形になります。
  • enable-meta-rules: Clash Meta独自の高度なルール機能を有効にするか（例えば、Luaスクリプトなど）。通常はtrueにします。
  • enable-process-rule: PROCESSルールタイプを有効にするか。
  • その他の設定項目は、必要に応じて調整します。

4.12 設定ファイルの作成と管理のヒント

  • サンプル設定から始める: ゼロから全てを記述するのは大変なので、公式やコミュニティで公開されているサンプル設定ファイルをベースにカスタマイズするのがおすすめです。
  • Rule Provider/Proxy Providerを活用: 特にノードやルールが多い場合、これらの機能を使って設定を外部化・自動化すると管理が楽になります。
  • 設定ファイルのチェック: YAML形式の構文エラーはClash Metaの起動失敗につながります。オンラインのYAMLバリデーターなどを活用すると便利です。
  • バックアップ: 重要な設定ファイルは必ずバックアップしておきましょう。
  • WebUIで確認: 設定ファイルを編集したら、Clash Metaを再起動（またはGUIクライアントでプロファイルを更新）し、WebUIで期待通りにプロキシノードやルールが読み込まれているか確認しましょう。

5. Clash MetaのWebUI (Yacdなど) の使い方

Clash Metaコアを直接実行している場合でも、WebUIを利用することで視覚的にClash Metaを管理・操作できます。最も一般的なWebUIはYacd (Yet another clash dashboard) です。ここではYacdを例に、WebUIの使い方を解説します。

5.1 WebUIへのアクセス方法

設定ファイルのgeneralセクションでexternal-controllerとsecretを設定している必要があります。

yaml
general:
external-controller: 127.0.0.1:9090 # 例
secret: "your_api_secret" # 例

  1. Clash Metaを起動: 設定ファイルを使ってClash Metaコアを起動します。
  2. WebUIにアクセス: Webブラウザを開き、Yacdの公開インスタンス（例: https://yacd.haishoku.me/）にアクセスします。または、ローカルにYacdのファイルをダウンロードして起動します。
  3. Clash Metaに接続: Yacdの画面が表示されたら、設定ボタン（通常は歯車アイコン）をクリックし、Clash MetaのAPI設定を入力します。
    • Host: 127.0.0.1 (Clash Metaを実行しているサーバーのIPアドレス)
    • Port: 9090 (external-controllerで設定したポート)
    • Secret: "your_api_secret" (secretで設定した値)
  4. 接続: 入力後、「Connect」ボタンなどをクリックします。接続に成功すると、Clash Metaのステータスが表示されるダッシュボード画面に遷移します。

5.2 WebUIの主な機能

WebUIを通じて、以下の主要な操作や情報の確認が可能です（WebUIの実装によってインターフェースや機能は異なります）。

  • ステータス表示: Clash Metaのバージョン、稼働時間、現在のモード（TUN/HTTP/SOCKS5）、メモリ使用量などが表示されます。
  • プロキシ選択: selectタイプのプロキシグループが表示され、使用するプロキシノードをリストから手動で選択・切り替えることができます。URLテストの結果（遅延時間）も表示されることが多いです。
  • 設定のロード: 設定ファイルを再ロードしたり、外部URLから新しい設定ファイルをインポートしたりする機能があります。
  • 接続リスト: 現在Clash Metaを経由しているアクティブな接続の一覧を表示します。接続元IP、宛先ドメイン/IP、使用しているルールとポリシー、アップロード/ダウンロード速度、転送量などが確認できます。不要な接続を閉じたりすることも可能です。
  • ログ表示: Clash Metaが出力するログをリアルタイムで表示します。ルールのマッチング状況、エラー情報などが確認でき、トラブルシューティングに非常に役立ちます。
  • 設定の確認: 現在適用されている設定ファイルの内容をWebUI上で確認できます（編集機能は限定的または無し）。
  • プロファイル管理: 複数の設定プロファイルを切り替える機能を持つWebUIもあります。

WebUIはClash Metaの現状把握と簡単な操作に便利ですが、詳細な設定変更はYAMLファイルを直接編集して行うのが基本です。

6. Clash Metaの応用的な使い方

基本的な設定と使い方をマスターしたら、さらにClash Metaの高度な機能を活用してみましょう。

6.1 Luaスクリプトによる高度なカスタマイズ

設定ファイル内にLuaスクリプトを記述することで、静的なルールだけでは不可能な動的な処理を実現できます。Luaスクリプトはrulesセクション内で特定のルールタイプとして定義されます。

“`yaml
rules:
# Lua スクリプトを定義 (rule-providers のように外部ファイルにすることも可能)
– SCRIPT,my_script,Proxy

スクリプト本体を定義

scripts:
my_script: |
function main(metadata)
— metadata は現在の接続に関する情報を含むテーブル
— metadata.host: 宛先ホスト名
— metadata.dst_ip: 宛先 IP アドレス
— metadata.dst_port: 宛先ポート
— metadata.src_ip: 送信元 IP アドレス
— metadata.process: プロセス名 (TUNモードなど)

  -- 例: 特定の時間帯だけ特定のプロキシを使用する
  local hour = tonumber(os.date("%H"))
  if hour >= 9 and hour < 18 then -- 平日 9時-18時
    if metadata.host and string.find(metadata.host, "work.com") then
      return "Work_Proxy" -- 会社のサイトは会社のプロキシ
    end
  end

  -- 例: 特定のポートへの通信を拒否
  if metadata.dst_port == 25 then -- SMTP ポート
    return "REJECT"
  end

  -- 例: 特定の IP アドレス範囲を直接接続
  if metadata.dst_ip then
    if metadata.dst_ip:find("^192\\.168\\.") or metadata.dst_ip:find("^10\\.") then
      return "DIRECT"
    end
  end

  -- 例: HTTP リクエストの User-Agent ヘッダーを書き換える
  -- Luaスクリプトでトラフィックの内容にアクセスするには、別途設定が必要な場合や特定のイベントフックを利用する場合がある
  -- (Clash MetaのLuaスクリプト機能は進化しているため、最新のドキュメントを参照)

  -- 上記の条件にマッチしない場合は、通常のルール処理にフォールバックするか、デフォルトのポリシーを返す
  -- SCRIPT ルールがマッチした場合、Lua 関数が返す値がポリシー名となる
  -- 値が nil の場合、次のルールが評価される
  -- 値が文字列 ("DIRECT", "REJECT", "ProxyGroupName", "ProxyNodeName") の場合、そのポリシーが適用される
  return nil -- この例では、スクリプトで処理しない場合は次のルールへ
end

“`

  • rulesセクションで SCRIPT,[script_name],[fallback_policy] の形式でルールを記述します。マッチした場合、指定したスクリプトが実行されます。
  • scriptsセクションで、[script_name]に対応するLuaスクリプト本体を記述します。|の後にインデントしてスクリプトを書きます。
  • main(metadata) 関数がエントリポイントとなります。metadataテーブルを通じて現在の接続情報にアクセスできます。
  • main関数は、適用したいポリシーの名前（"DIRECT", "REJECT", プロキシグループ名、プロキシノード名など）を文字列で返します。nilを返すと、次のルールが評価されます。
  • Luaスクリプトの機能はClash Metaのバージョンによって拡張されています。HTTP/HTTPSトラフィックの内容を操作するためのイベントフックなどが追加されています。詳細は公式ドキュメントを参照してください。

Luaスクリプトは非常に強力ですが、設定ミスが全体の動作に影響を与える可能性があるため、慎重に使用する必要があります。

6.2 Rule Provider/Proxy Providerを活用した大規模設定管理

多数のルールやプロキシノードを扱う場合、Rule ProviderとProxy Providerは不可欠です。

  • 複数のプロバイダー: 異なる目的や提供元ごとに複数のRule Provider/Proxy Providerを定義し、それぞれ異なるURLからリストを取得できます。
  • フィルタリング: Proxy Providerのfilter機能を使って、取得したノードの中から特定の条件（名前、プロトコルなど）に合致するものだけを選択できます。
  • Rule-Setの組み合わせ: 複数のRule Providerで取得したRule-Setをrulesセクションで組み合わせることで、複雑なルーティングポリシーを構築できます。
  • 自動更新: intervalを設定しておけば、Clash Metaが起動中に自動的にリストを更新してくれるため、常に最新の状態を保てます。

6.3 Fake IPモードの詳細な解説と注意点

dns.enhanced-mode: fake-ip を有効にすると、Clash Metaは独自のFake IPプール（fake-ip-rangeで指定）からIPアドレスをクライアントに返します。アプリケーションは返されたFake IPに接続しようとしますが、実際の通信はClash Metaが捕捉し、内部的に本来の宛先にルーティングされます。

メリット:

  • 透過性: アプリケーション側はプロキシ設定を意識する必要がありません。システム全体のトラフィックを容易に制御できます。
  • DNS漏洩防止: DNSリクエストは全てClash Metaが処理するため、外部に漏洩しにくくなります。

注意点:

  • ローカルネットワーク: Fake IPモードはローカルネットワーク内のリソース（プリンター、NAS、他のデバイス）へのアクセスに問題を引き起こすことがあります。fake-ip-filterでローカルIP範囲やローカルホスト名を除外設定する必要があります。
  • 特定のアプリケーションとの非互換性: 一部のアプリケーションやゲームは、IPアドレスを直接参照したり、特定のIPレンジに依存したりするため、Fake IPモードで正常に動作しないことがあります。その場合は、該当するアプリケーションの通信をPROCESSルールなどで除外するか、Fake IPモード以外の方法（HTTP/SOCKS5プロキシを手動設定など）を検討する必要があります。
  • DNS結果への依存: Fake IPモードはDNSリクエストがClash Metaに到達し、Fake IPが返されることが前提です。DNS設定やファイアウォールでDNSトラフィックがClash Metaに正しくリダイレクトされていることを確認する必要があります。
  • IPベースのルール: Fake IPモードでは、クライアントはFake IPに接続するため、IP-CIDRルールはFake IPに対して評価されることになります。本来の宛先IPに基づくルーティングを行いたい場合は、Rule-Setなどでドメインベースのルールと組み合わせる必要があります。

6.4 Dockerコンテナでの運用

サーバー環境などでは、Clash MetaをDockerコンテナとして実行するのが一般的です。これにより、環境構築が容易になり、依存関係の問題を避け、システムの他の部分から隔離して運用できます。

Dockerイメージは非公式なものが多く存在しますが、GitHub Actionsなどを使って公式リポジトリからビルドされたイメージや、信頼できるコミュニティが提供するイメージを利用することを推奨します。

Dockerで実行する場合、設定ファイルやGEODATデータベースファイルはボリュームとしてコンテナにマウントし、リスニングポートはホストOSに公開する必要があります。TUNモードを使用する場合は、コンテナに特別な権限やcapabilitesを与える必要があるなど、少し複雑な設定が必要になります。

6.5 Home Assistantなど他のシステムとの連携

Clash MetaのAPI (external-controller) は、他のアプリケーションやスクリプトからClash Metaの状態を監視したり、プロキシを切り替えたりするために利用できます。例えば、Home Assistantのようなスマートホームプラットフォームから、ネットワークの状態に応じてプロキシ設定を自動的に変更するといった連携が考えられます。

7. Clash Meta利用上の注意点とトラブルシューティング

Clash Metaは強力なツールですが、その設定や運用には注意が必要です。問題が発生した場合のトラブルシューティング方法も知っておきましょう。

7.1 設定ミスによる接続不可

最も一般的な問題は設定ファイルの記述ミスです。YAMLの構文エラー、プロキシノード情報の誤り、ルール記述の論理的な誤りなどが原因となります。

  • YAML構文チェック: Clash Meta起動時にYAML構文エラーがあればメッセージが表示されます。オンラインツールで事前にチェックすると良いでしょう。
  • ログの確認: general.log-levelをdebugに設定し、Clash Metaのログを詳しく確認します。プロキシへの接続エラー、DNSエラー、ルールマッチングの状況などが記録されています。
  • WebUIの接続リスト: WebUIの接続リストを確認し、トラフィックが意図したプロキシやポリシーを経由しているか確認します。REJECTされている、意図しないプロキシに行っているなどの状況から原因を特定します。
  • ルールの見直し: ルールは上から順に評価されます。意図しないルールが先にマッチしていないか確認します。MATCHルールがリストの最後に正しく配置されているかも確認します。

7.2 パフォーマンス問題 (CPU使用率、帯域幅)

  • CPU使用率: 大量の接続がある場合や、特定のプロトコル（例: 不安定なUDPベースのプロトコル）を使用している場合にCPU使用率が高くなることがあります。設定ファイルに過剰な数のルールやプロキシノードがある場合も影響することがあります。不要なノードやルールを削減したり、Rule Provider/Proxy Providerの更新間隔を調整したりすることを検討します。
  • 帯域幅: プロキシサーバー自体の帯域幅が不足している、プロトコルのオーバーヘッドが大きい、同時に多数の接続を処理しているなどが原因として考えられます。可能であれば、より帯域幅の広いプロキシノードを使用したり、パフォーマンスの高いプロトコル（Hysteria2など）を検討したりします。
  • ログの確認: パフォーマンス関連のエラーや警告が出ていないかログを確認します。

7.3 ログの見方

Clash Metaのログは、問題解決の重要な手がかりとなります。

  • [INFO]: 情報レベルのメッセージ。起動、設定ロード、プロキシ選択、接続確立などの通常の動作が表示されます。
  • [DEBUG]: デバッグレベルのメッセージ。ルールの評価プロセス、DNSクエリ、ネットワークイベントなどの詳細な情報が表示されます。トラブルシューティング時によく使われます。
  • [WARNING]: 警告メッセージ。すぐにエラーにはならないが、問題の兆候がある場合に表示されます（例: プロキシノードの遅延が大きい）。
  • [ERROR]: エラーメッセージ。接続失敗、設定ロード失敗、予期しないエラーなどが表示されます。

特にDEBUGレベルでは、どのルールにマッチしてどのポリシーが適用されたかが詳細に表示されるため、ルーティングのデバッグに非常に役立ちます。

7.4 ファイアウォール設定

Clash Metaがリスニングするポート（mixed-portなど）や、TUNモードが使用するネットワークインターフェースが、OSやネットワーク機器のファイアウォールによってブロックされていないか確認が必要です。特にサーバー環境で運用する場合や、他のデバイスからClash Metaを経由してインターネットにアクセスさせたい場合は、ファイアウォールで適切なポートを開放する必要があります。

7.5 プロトコルの互換性問題

特定のプロキシプロトコルは、サーバー側とクライアント側（Clash Meta）で正確な実装バージョンや設定が一致している必要があります。特に新しいプロトコルや機能（例: Reality, XTLS, Hysteria2の特定のObfs設定）は、サーバー側のソフトウェアもClash Metaがサポートしているバージョンに対応している必要があります。接続できない場合は、サーバー側の設定やソフトウェアバージョンを確認してみましょう。

7.6 法的な側面と利用リスク

プロキシソフトウェアの利用は、その目的や使用するプロキシサーバーの場所、アクセスする情報の内容によって、法的な問題やリスクを伴う可能性があります。

  • 利用目的: 検閲回避の目的でプロキシを使用する場合、その国の法律によっては違法となる可能性があります。
  • プロキシサーバーの提供: 許可なく他人にプロキシサービスを提供することは、法的な責任を問われる可能性があります。
  • 著作権侵害: プロキシを利用して著作権保護されたコンテンツに不正にアクセスしたりダウンロードしたりすることは違法です。
  • 悪用: プロキシを利用して違法行為（サイバー攻撃、詐欺など）を行うことは、重大な犯罪行為です。

Clash Metaはあくまでツールであり、その使用方法については個人の責任が伴います。利用にあたっては、居住国の法律や利用するプロキシサービスの利用規約を遵守し、自己責任で行ってください。特に、検閲の厳しい地域で利用する場合は、技術的な対策だけでなく、法的なリスクについても十分理解しておく必要があります。

8. Clash Metaの将来性・コミュニティ

Clash Metaはオープンソースプロジェクトであり、その開発はコミュニティによって支えられています。

8.1 開発状況、アップデート頻度

Clash Metaは比較的活発に開発が行われており、新しいプロトコルのサポートや機能改善が頻繁に行われています。しかし、オープンソースプロジェクトの性質上、開発者のモチベーションや状況によって開発ペースは変動する可能性があります。

8.2 GitHubリポジトリ、Telegramグループなどの情報源

最新の情報や開発状況、設定例、トラブルシューティングのヒントなどは、以下の情報源で得られます。

  • 公式GitHubリポジトリ: https://github.com/MetaCubeX/mihomo (現在のリポジトリ) – ソースコード、Issueトラッカー、リリース情報など。
  • Telegramグループ: Clash Metaに関する非公式なユーザーコミュニティがTelegramなどに多数存在します。情報交換や質問が活発に行われていますが、参加には注意が必要です。
  • Wikiやドキュメント: GitHubリポジトリやコミュニティによって、設定方法や機能の詳細に関するWikiやドキュメントが整備されている場合があります。

8.3 他のClashフォークとの比較 (Clash Premiumなど)

Clash Meta以外にも、オリジナルのClashから派生した様々なフォークが存在します。代表的なものに「Clash Premium」があります。Clash PremiumはオリジナルのClashに一部追加機能（Rule Setなど）が組み込まれた、より古い派生ですが、開発は停滞しています。

Clash Metaは、特にLuaスクリプト、GEOSITEデータベースの活用、新しいプロトコル（Reality, Hysteria2など）への対応において、他のフォークと比較して先行していることが多いです。どのフォークを選ぶかは、利用したい機能や開発の活発さによって判断すると良いでしょう。ただし、機能が多いほど設定が複雑になる傾向もあります。

9. まとめ

本記事では、Clash Metaについて約5000語の詳細な解説を行いました。Clash Metaは、オリジナルのClashから派生した高機能なプロキシコアであり、その最大の特徴は、高性能で柔軟なルールベースルーティング、多様な最新プロトコルサポート、そしてLuaスクリプトによる高度なカスタマイズ性にあります。

Clash Metaを使いこなすためには、YAML形式の設定ファイルを正確に記述することが不可欠です。proxiesでプロキシノードを定義し、proxy-groupsでそれらをまとめ、rulesでトラフィックの振り分け方法を定義します。さらに、rule-providersやproxy-providersで設定の動的管理、dnsで高度なDNS制御、tunでシステム全体の透過プロキシを実現できます。WebUIを利用することで、視覚的な管理やプロキシの切り替えも容易になります。

Clash Metaは、以下のようなユーザーにおすすめです。

  • 複数のプロキシノードを使い分けて、宛先に応じて自動的に最適な経路を選択したい。
  • VLESS XTLS/Reality, Hysteria2などの最新かつ検閲耐性の高いプロトコルを利用したい。
  • Luaスクリプトを使って、より高度で独自のネットワーク制御ロジックを実装したい。
  • Rule Provider/Proxy Providerを使って、大規模なプロキシリストやルールリストを効率的に管理したい。
  • Windows, macOS, Linux, Android, iOSなど、様々なプラットフォームで統一された設定と機能を利用したい。

一方で、設定が比較的複雑であるため、プロキシソフトウェアやネットワーク設定に慣れていない初心者にはややハードルが高いと感じるかもしれません。しかし、基本的な設定から始め、必要に応じて高度な機能に挑戦していくことで、Clash Metaの強力な恩恵を受けることができます。

利用にあたっては、設定ミスによるトラブルや、法的なリスクについても十分に理解しておく必要があります。公式の情報源や信頼できるコミュニティの情報を参考にしながら、安全かつ適切にClash Metaを活用してください。

インターネットの自由な利用やプライバシー保護に対するニーズが高まる中、Clash Metaのようなツールはますます重要性を増していくでしょう。本記事が、あなたがClash Metaを理解し、そのポテンシャルを最大限に引き出すための一助となれば幸いです。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール