設定構文とオープンソースカーネルのエコシステム
PLATFORM / CLIENT
まずOSを選び、次にCPUアーキテクチャを確認します。デスクトップアプリ、モバイルのネットワーク拡張機能、コマンドラインカーネルでは導入方法が異なりますが、設定の考え方は共通しています。
デスクトップで使い始めるなら、まずClash Plusを確認し、用途に応じてClash Verge RevやFlClashなどと比較しましょう。設定を読み込んでシステムプロキシを有効にすると、OSのプロキシ設定に従うアプリがローカルポートに接続します。より多くのアプリの通信を取り込む場合は、TUNモードと必要な権限を確認してください。
インストール前に、システム情報でCPUアーキテクチャを確認してください。古いクライアントがバックグラウンドで動作している場合は終了し、プロキシポートも確認して、複数のカーネルが同時に待ち受けないようにします。ストアアプリに接続できない場合、ループバック制限が原因のこともあります。ブラウザーでページを開けるかどうかだけで、すべてのアプリの接続状況を判断することはできません。
Apple SiliconまたはIntelプロセッサに合ったインストーラーを選び、Clash Plus、Clash Verge Rev、FlClashなどを比較できます。メニューバーのスイッチは通常システムプロキシを切り替えますが、カーネルが現在の設定を読み込んでいるかは、設定画面とログの両方で確認してください。
初回起動時は、システムの案内に従って必要な権限を許可してください。ネットワーク拡張機能の許可と、通常のアプリ起動は別の操作です。別のクライアントに切り替える前に、現在のクライアントのプロキシとバックグラウンドサービスを停止してください。ClashX Metaのアーカイブは互換性の確認に利用できますが、継続利用には現在もメンテナンスされている選択肢を優先しましょう。
Clash Plus、Clash Meta for Android、FlClash、Surfboardから選び、各アプリが対応する設定形式を確認してください。多くのモバイルクライアントはシステムVPNインターフェースを通じて通信を取り込みます。初回接続時にはシステムの許可が必要です。また、通常、通信を取り込めるVPNサービスは同時に1つだけです。
バックグラウンドで接続が切れる場合は、まずバッテリー最適化とアプリのバックグラウンド実行制限を確認し、次にサブスクリプションとDNSを確認してください。アプリごとの振り分けはクライアントの設定にも左右されます。YAMLにルールがあっても、通信の取り込み対象から除外されたアプリには適用されません。調査時は両方の設定を確認しましょう。
ダウンロードページではClash PlusのApp Storeページと公式サイトclashplus.ioを案内しています。インストール後、アプリが対応する設定を読み込み、システムの案内に従ってVPN構成を追加してください。デスクトップのポート設定、サービス管理、権限操作をそのままスマートフォンに当てはめず、アプリで実際に利用できる設定を確認しましょう。
設定の読み込みに成功しても、すべてのプロトコル項目が同じように実装されているとは限りません。一部の接続に失敗する場合は、まずノードの種類とクライアントの互換性を確認し、次にポリシーグループの選択を確認してください。ネットワークの切り替え、オンデマンド接続、バックグラウンド動作も影響するため、複数の設定を一度に変更せず、個別に記録して確認しましょう。
Ubuntuデスクトップでは、Clash Verge RevやFlClashを確認し、ディストリビューションとパッケージ形式に合った方法でインストールできます。サーバーやルーターではmihomoを個別に導入できます。GUIクライアントはトレイ、設定管理、システム連携を担当します。単独で動かすカーネルでは、作業ディレクトリ、設定ファイルのパス、サービスの起動方法を自分で指定する必要があります。
GNOMEのシステムプロキシが影響するのは、主にその設定に従うデスクトップアプリです。ターミナルのプログラムには、プロキシ環境変数を別途設定する必要がある場合があります。systemdを使う場合は、サービスアカウントが設定ファイルを読み込めるか、ログにポートのバインド失敗が記録されていないか、TUNに必要な権限があるかを確認してください。すべてのプログラムを管理者権限で実行する方法は避けましょう。
CONFIG / FIELD NOTES
「リクエストの受信、ドメイン名の解決、出口の選択、ルールの照合」の順に確認します。以下の例は項目の関係を示すもので、利用可能なノードを含む完全な設定ではありません。
YAMLではインデントで階層を表します。項目名だけでなく記述する位置も重要です。変更前に現在のファイルをバックアップし、毎回1種類の設定だけを変更してから、クライアントの設定チェックやカーネルのテストで構文を確認しましょう。画面に表示される設定名、ディスク上のサブスクリプションファイル、実行時にマージされた設定は異なる場合があります。調査時は実際に読み込まれた内容を基準にしてください。
左側のgeneralは、基本項目を分類するための説明上の見出しであり、ファイルに記述するトップレベルキーではありません。ほかのタブは実際の設定セクションに対応します。各セクションの役割を理解してから必要な項目を追加すると、複数のサンプルをそのままつなぎ合わせるより、競合を見つけやすくなります。各クライアントのデフォルト値やオーバーライドの仕組みは、個別の説明も確認してください。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info基本項目は、カーネルがリクエストをどのように受け付けるかを決めます。mixed-portはHTTPとSOCKS5の共用ポートです。変更した場合、プロキシアドレスを手動設定しているアプリも合わせて変更してください。allow-lanはLANからの接続を許可するかどうかを指定します。個人用PCでは、通常は無効のままにします。modeをruleにするとルールによる振り分けが有効になります。ログレベルはまずinfoに設定し、問題が発生した場合に必要に応じて詳細度を上げましょう。これらの項目はYAMLのルート階層に直接記述し、外側にgeneralを追加しないでください。意図したとおりにカーネルが設定されなくなります。
設定ガイドで確認する →dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
nameserver:
- https://dns.alidns.com/dns-querydnsセクションでは、カーネルがドメイン名を解決する方法を設定します。fake-ipはドメイン名に仮想IPアドレスを割り当て、後からドメイン名を復元してルールに照合しやすくしますが、一部アプリとの互換性は実際に確認してください。nameserverは上流のDNSサービスを指定します。listenは待ち受けアドレスを指定するだけで、システムからのDNSリクエストが自動的にそこへ送られるわけではありません。システムの名前解決、ブラウザーの暗号化DNS、TUNによる横取りは、それぞれ異なる経路です。DNS漏えいや名前解決の失敗を調べる際は、まずリクエストが実際にどの経路を通っているかを確認してから、上流サーバーやフィルターを調整しましょう。
設定ガイドで確認する →proxies:
- name: サンプルノード
type: ss
server: proxy.example.com
port: 443
cipher: aes-128-gcm
password: "your-password"proxiesは、プロキシノードを明示的に定義するリストです。各ノードには一意の名前を付け、プロトコルに必要なアドレス、ポート、認証情報を指定します。例にあるドメイン名やパスワードは構造を示すためのもので、実際の接続情報ではありません。ノード名はポリシーグループから参照されるため、名前を変更する場合は参照先も合わせて変更してください。サブスクリプションやproxy-providersを使う場合、ノードは外部設定から提供されることがあるため、手動で重複して記述する必要はありません。ノードを読み込めない場合は、まずプロトコルの種類とカーネルの対応範囲を確認しましょう。名前だけを変えても、互換性の問題が解決するとは限りません。
設定ガイドで確認する →proxy-groups:
- name: 手動選択
type: select
proxies:
- DIRECT
- サンプルノードポリシーグループを使うと、ルールが参照する出口名と実際のノードを分けられます。selectは手動選択を提供します。グループのメンバーには、定義済みのノード、ほかの適切なポリシーグループ、またはDIRECTなどの組み込み出口を指定できます。この例はproxies内の同名ノードを参照しており、単独で使える完全な設定ファイルではありません。自動テストやフォールバックを行うグループには追加のパラメーターが必要です。typeだけを変更しても、動作が同じになるとは限りません。画面でノードを切り替えても通信が変わらない場合は、ルールが実際にそのグループを参照しているか、既存の接続が引き続き再利用されていないかを確認してください。
設定ガイドで確認する →rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,手動選択rulesは上から順に照合され、最初に一致したルールで出口が決まります。範囲を限定したルールは、広範なルールより前に記述し、MATCHは最後のフォールバックとして配置します。MATCHを先に置くと、その後のルールは適用されません。DOMAIN-SUFFIXはドメインのサフィックスで、IP-CIDRはIPアドレスの範囲で照合します。no-resolveを指定すると、そのIPルールのためにドメイン名の解決を行わなくなります。ルールで指定するポリシー名は、あらかじめ定義されている必要があります。カスタムルールの動作を確認するときは、新しい接続のマッチ記録を確認してください。既存の接続は開始時の経路を使い続けることがあるため、画面が正常に再読み込みされたかだけでは判断できません。
設定ガイドで確認する →tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53TUNは仮想ネットワークインターフェースとルートを使って、より多くのアプリの通信をカーネルに取り込みます。システムプロキシに従わないプログラムに適しています。auto-routeやインターフェースの自動検出は通信経路の設定に役立ちますが、システム権限、ほかのVPN、既存のルートの影響を受けます。dns-hijackは条件に一致するDNS通信を処理する設定であり、アプリ内の暗号化DNSをすべて制御できるわけではありません。この例はこれらの項目に対応するmihomo環境を対象としています。モバイルではアプリの実装に従ってください。起動に失敗した場合は、まず権限とログを確認します。リモートサーバーで自動ルートを有効にする前に、別の復旧手段も用意してください。
設定ガイドで確認する →OPEN SOURCE / CONTEXT
クライアント名を覚えるより、ソフトウェア間の関係を理解することが重要です。オープンソースのリポジトリでは、コード、リリース情報、課題の議論を確認できます。具体的な機能は、実際に使われているカーネルに基づいて判断してください。
Clashでは当初、YAMLを中心とする設定方式が採用されました。入口がアプリからのリクエストを受け付け、ノードが利用可能な出口を定義し、ポリシーグループがノードをまとめ、ルールが接続先を決めます。Clash Metaはこれを基にプロトコルやネットワーク機能を拡張し、後続プロジェクトはmihomoの名称で開発が続いています。そのため、解説に登場するClash Metaとmihomoには歴史的なつながりがありますが、Clashの名を冠したソフトウェアがすべて同じ機能を備えているとは限りません。見慣れない項目を見つけたら、サブスクリプションを何度も再読み込みするより、まず実行中のカーネル名を確認し、対応するドキュメントを参照しましょう。
オリジナル版Clashの主要な公開実装はすでにメンテナンスが終了しており、古い解説に記載されたデフォルト値、プロトコル一覧、導入方法が現在のクライアントに当てはまらない場合があります。移行時は、使用中のプロトコル、DNSモード、ルールセット、ローカルのオーバーライドを記録し、新しい環境で対応しているか一つずつ確認してください。基本的なYAML構造を読み込めることは互換性の第一歩にすぎません。ノードの接続パラメーター、ルールプロバイダーの動作、OSとの連携には違いがあることがあります。以前の設定をバックアップしておけば、移行やトラブル対応の際に比較できます。
デスクトップクライアントは通常、サブスクリプションの読み込み、設定の切り替え、トレイメニュー、自動起動、システムプロキシの切り替えを担当します。カーネルは設定を解析し、実際の接続を処理します。画面上で起動済みと表示されていても、対象アプリがプロキシ経由で接続しているとは限りません。また、カーネルが正常に動作していても、システムプロキシやDNSが正しく設定されているとは限りません。特にUbuntuでは、GNOMEデスクトップのプロキシ、ターミナルの環境変数、TUNルートを区別する必要があります。それぞれ適用範囲が異なるため、対象アプリに合った経路を選ぶと、二重の通信取り込みやルートの競合を避けやすくなります。
コマンドラインのみの導入は、単独での実行、サービス管理、リモート保守が必要な場合に適しています。その一方で、GUIが担っていた作業は自分で行うことになります。設定ファイルの配置場所、サービスの実行アカウント、ログの確認方法、障害時の停止手順をあらかじめ決めておきましょう。systemdの作業ディレクトリは相対パスに影響し、アクセス権限はルールファイルの読み込みに影響します。まずフォアグラウンドで設定を読み込めることを確認してからバックグラウンドサービスを構成すると、設定の誤りとサービス管理の問題を切り分けやすくなります。
クライアント、カーネル、サブスクリプションの更新は、それぞれ異なる操作です。クライアントの更新では画面やシステム連携が変わることがあり、カーネルの更新では設定項目の挙動が変わる場合があります。サブスクリプションの更新では通常、ノードやルールの内容が更新されます。変更前に何を更新するのかを確認し、現在の設定を記録してください。設定のマージに対応するクライアントでは、ダウンロード済みのサブスクリプションファイルを直接編集するより、専用のオーバーライド層に個人ルールを置くほうが管理しやすい場合があります。ただし、マージの順序を確認し、個人のDNS設定がほかの設定元に上書きされないようにしてください。
オープンソースライセンスは、コードの利用や再配布の条件を定めるものであり、クライアント間でライセンスや配布方法が完全に同じであることを意味しません。本サイトは設定解説とダウンロード先をまとめたもので、各プロジェクトのリリース情報に代わるものではありません。問題の議論を参照するときは、タイトルが似ているかだけでなく、OS、カーネルの種類、再現手順を照らし合わせてください。ログや設定を共有する際は、サブスクリプションURL、認証情報、個人のネットワーク情報を削除しましょう。項目の構造とエラー発生時の状況が残っていれば、多くの場合、技術的な議論に十分です。
アプリに最も近い層から確認しましょう。まずアプリがシステムプロキシ、手動プロキシ、TUNのどれを使っているかを確かめ、次にローカルポートとカーネルの状態、ルールの一致状況、ポリシーグループの選択、ノードへの接続性、最後にDNSと接続先サービスを確認します。ブラウザーでページを開けても、そのアクセス経路が機能していることしか確認できず、ほかのプログラムやプロトコルの検証にはなりません。一度に変更する項目を1つにし、変更前後のログを残すと、設定と現象の因果関係を把握しやすくなります。
DNSの問題では、「名前解決に失敗する」場合と「名前解決は成功するが接続できない」場合を区別することが特に重要です。前者はリクエストの入口、上流DNSへの到達性、名前解決モードを確認します。後者ではさらにルール、出口、接続先アドレスを調べます。HTTPSの証明書警告も、単純にプロキシが原因とは限りません。システム時刻、証明書チェーン、パケットキャプチャツール、接続先サービスが関係することもあります。ページを表示するために証明書検証を無効にせず、エラーを記録して層ごとに調査してください。プロトコルの違いやカーネルの選び方はプロトコルリファレンスを参照し、手順に沿って始める場合は入門ガイドをご覧ください。
NOTES / TROUBLESHOOTING
実際のエラーや症状から原因を探します。まず問題がどの層で発生しているかを特定し、設定を変更する必要があるか判断しましょう。
システム時刻のずれ、中間者型のパケットキャプチャツール、ノードによる通信の改変、DNS汚染など、証明書警告の原因を整理します。Clashが関係するケースとプロキシに関係しないケース、それぞれの対処法を解説します。
証明書エラーの種類を記録し、接続先サイト自体の問題と通信経路上の介入を切り分けて確認します。異常を隠すためにセキュリティ検証を無効にする必要はありません。
Windows、macOS、Linuxでnetstat、lsof、ssを使い、7890などのポートを使用しているプロセスを特定する方法を解説します。ポート変更後にシステムプロキシやブラウザーの設定を合わせる方法も紹介します。
まず旧クライアントやバックグラウンドサービスがポートを使用しているか確認し、プロセスを停止するかポートを変更するか判断します。YAMLだけ変更してアプリの古いプロキシアドレスをそのままにすると、接続は失敗します。
UbuntuデスクトップへのGUIクライアントの導入と、サーバーへのコマンドラインのみの導入をそれぞれ解説します。バイナリの配置、config.yamlのパス、systemdのサービスファイル、TUNに必要な権限設定も取り上げます。
デスクトップ画面が必要かどうかで導入方法を選び、フォアグラウンドでの設定テスト、サービスの起動、自動起動を分けて確認します。作業ディレクトリや権限の問題を混同せずに調査できます。