設定
操作イメージ1mixed-port: 78902allow-lan: false3mode: rule4log-level: info5dns:6 enable: true問題から設定を調べる
まずクライアントの設定またはサブスクリプション画面を開き、「URLから読み込む」を選びます。サービス提供元から届いたサブスクリプションURLをすべて貼り付けて、ダウンロードを実行してください。設定カードが表示されたら、それを選択して現在の設定として有効化します。ダウンロードしただけでは有効になりません。次にプロキシ画面を開き、プロキシグループを展開してプロキシを選択できることを確認します。サブスクリプションURLには通常、アクセスに必要な情報が含まれます。公開の掲示板などには貼らないでください。読み込みに失敗したら、まずURLが完全か、サブスクリプションが有効か、現在のネットワークからサーバーにアクセスできるかを確認します。すぐにDNSを変更したり、クライアントを何度も再インストールしたりする必要はありません。
設定 → URLから読み込む → ダウンロード → 設定を選択
プロキシ → プロキシグループを展開 → プロキシを選択ルールモードでは、設定ファイルのルールに従って接続先が決まります。一部のサイトは直接接続し、それ以外はプロキシグループを経由する、といった使い分けができます。グローバルモードでは、コアに渡された接続をすべてグローバル用のポリシーに振り分けます。グローバルグループでプロキシを選ぶ必要があり、端末上のすべての通信が自動的にプロキシ経由になるわけではありません。初めて使う場合は、サブスクリプションに含まれるルールモードのまま、よく使うサイトにアクセスできるか確認しましょう。特定のサイトで問題が起きたら、一時的にグローバルモードへ切り替えて比較します。グローバルではつながり、ルールモードではつながらない場合は、適用されたルールと振り分け先のプロキシグループを確認してください。確認後はルールモードに戻し、一時的な検証設定をそのまま使い続けないようにしましょう。
mode: rule
log-level: infoシステムプロキシは、プロキシのアドレスをOSの設定に反映する機能です。通常はブラウザーやシステムプロキシに対応したアプリで使えます。一部のゲーム、コマンドラインツール、独自のネットワーク機能を持つアプリはシステムプロキシを参照しないため、その場合にTUNを検討します。TUNは仮想ネットワークインターフェースを使って対象の通信を取り込みます。両方を同時に有効にする必要はありません。まずシステムプロキシを使ってブラウザーで確認し、特定のアプリだけ動作しない場合は、そのアプリのプロキシ設定を調べましょう。TUNが必要な場合は、クライアントの案内に従ってサービスをインストールするか権限を付与し、ほかのVPNとの競合にも注意してください。接続できなくなったら、確認済みの設定に戻してから、一つずつ変更します。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: trueクライアントが実行中と表示されても、アプリやコアが起動していることが分かるだけで、Webリクエストがプロキシ経由になったとは限りません。まず確認するサイトを開き、接続またはログ画面で該当ドメインを探します。適用されたルール、プロキシグループ、最終的な出力先を確認してください。必要であれば、信頼できる出口IP確認ページを使い、プロキシのオフ時とオン時を比較します。ルールモードでは直接接続するサイトの出口が変わらないことがありますが、これは想定どおりです。ブラウザーのキャッシュ、既存の長時間接続、ほかのプロキシ拡張機能が判定に影響することもあります。確認前に古いページを閉じて、新しく開き直すとよいでしょう。状態表示だけを見るより、個々のリクエストの経路を確かめるほうが確実です。
テストページを開く → 該当する接続を探す
適用ルールを確認 → 最終的な出力先を確認 → 出口を比較設定を変更する前に、現在正常に動作しているファイルを書き出し、有効にしているオーバーライドやマージ設定を記録しておきます。編集後に読み込めなくなった場合は、複数の項目を同時に変更せず、まずバックアップに戻してください。YAMLでよくあるミスは、インデントにタブを使う、コロンの後にスペースがない、リストの階層がずれている、といったものです。サブスクリプションからダウンロードした設定は、更新時に置き換わることがあります。長く使うカスタム設定は、クライアントが対応するオーバーライド機能に記述しましょう。元のサブスクリプションに戻しても問題が続く場合は、オーバーライドを一時的に無効にして、元ファイルと追加変更のどちらが原因か切り分けます。変更は一度に一つにして、設定が正常に読み込まれたことを確認してから接続を検証してください。
mixed-port: 7890
allow-lan: false
mode: rule
dns:
enable: trueOSに合ったインストーラーを選ぶ
まずOSとCPUアーキテクチャを確認してから、クライアントを比較しましょう。Clash Plus、Clash Verge Rev、FlClashなどは、それぞれ異なるGUIプロジェクトです。ファイル名にClashとあるだけで、対応OSを判断しないでください。ダウンロードページでは、OS別にクライアントの選択肢、メンテナンス状況、インストール時の注意点を紹介しています。トップページのリンクは各OSの案内に移動するもので、インストーラーのダウンロードを直接開始するものではありません。
初めて使う場合は、まず1台で設定の読み込みと接続確認を済ませてから、ほかの端末でも同じ手順を試すのがおすすめです。クライアントのインストールとサブスクリプションの取得は別の手順です。インストーラーはアプリを用意し、サブスクリプションは接続に必要な設定を提供します。有効なサブスクリプションを用意したら、チュートリアルに沿って進めればよく、インストール前にYAMLを一から書く必要はありません。古いクライアントがまだ使える場合は、移行を決める前に設定とカスタムルールを書き出しておきましょう。
デスクトップでは、まずClash Plus、Clash Verge Rev、FlClashを比較してください。ダウンロード前にシステム設定でCPUアーキテクチャを確認し、インストール後はサブスクリプションを読み込んでからシステムプロキシを有効にします。TUNが必要な場合は、案内に従ってサービスの権限を設定してください。インストールできたことと接続できることは別です。
Clash for Windowsから移行する場合は、サブスクリプションURL、ルール、ポート設定を先にバックアップします。アーカイブ済みのクライアントは起動できる場合がありますが、メンテナンス状況は新しいクライアントとは異なります。設定項目に互換性がない場合は、ファイル全体を置き換えず、新しいコアのドキュメントを参照しながら一つずつ対応してください。
ダウンロードへ Windowsクライアント「このMacについて」でApple SiliconかIntelかを確認し、対応するインストーラーを選びます。Clash Plus、Clash Verge Rev、FlClashなどが候補です。初回起動時に許可を求められたら、アプリの入手元を確認してから、macOSの通常の手順で進めてください。
メニューバーのプロキシ切り替えと、現在の設定内容は別々に確認します。設定を読み込んだら、選択されていることを確認し、ネットワーク設定がクライアントの待ち受けローカルポートを参照しているか調べてください。ほかのネットワークツールに切り替える際は、現在のプロキシによる通信の取り込みを先にオフにし、設定の競合を防ぎましょう。
ダウンロードへ macOSクライアントスマートフォンでは、まずClash Plusを確認し、Clash Meta for Android、FlClash、Surfboardと比較してください。最近の端末の多くはARM64ですが、端末情報をもとに選ぶ必要があります。クライアントによって対応する設定形式が異なるため、すべてのサブスクリプションURLが共通で使えるとは限りません。
初回接続時には、通常、OSからVPN接続の許可を求められます。アプリを確認して許可してください。バックグラウンドに移動すると接続が切れる場合は、バッテリー最適化やバックグラウンド動作の制限を確認します。ほかのVPNが動作している場合は、どのアプリが通信を取り込むか確認し、通知領域のアイコンだけで接続状況を判断しないでください。
ダウンロードへ AndroidクライアントiPhoneやiPadでは、ダウンロードページからClash PlusのApp Storeページに進めます。アプリの説明は公式サイト clashplus.io で確認できます。まずインストールし、クライアントが対応する形式のサブスクリプションを読み込んでから、OSの案内に従ってVPN構成を追加してください。
接続をオンにした後も、適切なポリシーを選び、実際にページを開いて確認する必要があります。サブスクリプションを読み込めてもアクセスできない場合は、設定の有効期限と現在選択中の設定を確認してください。システムのネットワーク設定を何度も削除する必要はありません。モバイル回線とWi-Fiで結果が異なる場合は、分けて記録してから原因を調べましょう。
ダウンロードへ iOSクライアントデスクトップ環境では、Clash Verge RevとFlClashを比較し、ディストリビューションに合ったパッケージ形式を選びます。GUIをインストールしたら、まずシステムプロキシでブラウザーを確認し、その後にサービスモードやTUNを検討してください。GUIが開いても、コアのサービスが正常に起動しているとは限りません。
サーバーやルーターでは、mihomoコアの導入先も確認できますが、設定ファイルのパス、権限、起動サービスは自分で管理する必要があります。コマンドラインのプログラムがデスクトップのプロキシ設定を参照するとは限りません。アプリ固有のプロキシ設定を確認してください。一つのプログラムの接続問題を解決するために、すぐに全体のルーティングを変更しないようにしましょう。
ダウンロードへ Linuxクライアントポート、DNS、TUN、LAN内共有は、初回接続のたびに変更が必要な項目ではありません。まずサブスクリプションに含まれる設定を使い、ルールモードで再現できるアクセス確認を行います。明確な問題がある場合に限り、その問題に関係する項目を変更してください。これにより、原因を調べるための基準を保ち、どの変更で結果が変わったか判断できます。
用語が分からない場合は用語早見表を確認し、変更する項目が分かっている場合は設定リファレンスをご覧ください。チュートリアルでは操作の順序を、リファレンスでは各パラメーターの意味を説明しています。両方を同時に読み進める必要はありません。
プロジェクトの関係と設定の入手先
Clashエコシステムは、すべての端末で使える一つのインストーラーにまとまった製品ではありません。GUIクライアントは設定管理、プロキシの選択、接続状況の確認、OSとの連携を担います。コアは設定を読み込み、ルールを判定して、外部への接続を確立します。mihomoは、このエコシステムで継続的に開発されているオープンソースのコアです。役割の違いを理解すると、画面上の機能スイッチと設定ファイルの項目を区別でき、問題がクライアントの設定とコアの設定のどちらにあるか判断しやすくなります。
クライアントによって、組み込まれているコアのビルド、初期設定、設定のマージ方法が異なります。そのため、メニュー名やチュートリアルの画面が完全には一致しないことがあります。画面の位置ではなく、設定画面を開く、有効な設定を読み込む、ポリシーを選ぶ、通信が取り込まれているか確認するといった操作の目的を押さえましょう。ボタンの位置が変わっても手順全体が変わるとは限りません。一方、画面上の項目名が似ていても、高度な設定をそのまま流用できるとは限りません。
Clash公式サイト、Clash Verge Revのダウンロード、Clash for Windowsの開発終了などを検索すると、古いチュートリアル、アーカイブ済みプロジェクト、後継の派生版が同時に見つかることがあります。一部の設定構文を共有していても、開発主体や配布経路はそれぞれ異なります。ダウンロード前にプロジェクト名を確認し、最新のリリース情報を読んで、OSに合ったインストーラーを選んでください。古い記事に載っている名前だけで、現在も推奨されていると判断しないようにしましょう。
アーカイブ済みでも、手元のファイルがすぐ使えなくなるわけではありません。ただし、今後の互換性や不具合修正は別途検討が必要です。移行する場合は、現在使えている設定を保存し、カスタムルール、プロキシグループ名、ローカルポートを記録してください。新しいクライアントで動作を確認してから、古いアプリを整理しましょう。差が見つかっても比較できる基準が残るため、設定一式を記憶から作り直す必要がありません。
オープンソースのリポジトリでは、ソースコード、ライセンス、コミット履歴、課題の議論を確認できます。プロジェクトの実装や変更内容を調べるための重要な情報源です。mihomoの公開リポジトリはMetaCubeX組織の下にあります。以下のコマンドはソースコードを取得するもので、実装やビルド手順を調べたい方向けです。通常、クライアントをインストールするだけならコマンドを実行する必要はありません。4ステップの初期設定に、ビルド環境を用意する必要もありません。
ソースコードが公開されていることと、実際に接続できることは別の問題です。サブスクリプションの有効性、プロキシサーバーへの到達性、ネットワーク環境でのアクセス可否、ルールの判定結果などが通信に影響します。未確認のダウンロード数や評価を操作手順の代わりにせず、実際に確認できるポイントを重視します。設定が読み込めること、ポリシーを選べること、リクエストが記録されること、最終的な出力先が想定どおりであることを確認しましょう。
クライアントの更新では、画面、OS連携、同梱コアなどが変わることがあります。サブスクリプションの更新では、URLから設定内容を再取得します。クライアントを更新してもサービスの契約は自動更新されず、サブスクリプションを更新してもアプリはアップグレードされません。サブスクリプションの更新に失敗した場合は、まずURLにアクセスできるか、返された内容が対応形式か、サービスが有効かを確認しましょう。失敗の原因をすべてクライアントの古さに求めないでください。
アップグレード前に変更内容を確認し、現在の設定を書き出しておきます。アップグレード後は、既存のプロキシグループ、オーバーライド、DNS設定が想定どおり保たれているか確認し、よく使うアプリで接続を再検証してください。サブスクリプションが生成したファイルを直接編集していると、次回の更新で変更が上書きされることがあります。長く使うルールは、クライアントが明示的に対応するオーバーライドやマージ機能に記述し、復元できるバックアップも保管しましょう。
コミュニティに相談する際は、OS、クライアント名、利用している通信の取り込み方式、どの手順から問題が起きたかをまず伝えます。すべてのサイトで失敗するのか、特定のドメインやアプリだけなのかも説明しましょう。ルールモードとグローバルモードを切り替えた結果の違いも記載します。「つながらない」とだけ書くより、状況を絞り込みやすくなり、何度も確認し合う手間を減らせます。
ログや設定には、サブスクリプションの認証情報、サーバーアドレス、個人のネットワーク情報が含まれる場合があります。共有する前に機密情報を削除し、問題に関係する項目の構造、エラー、再現手順だけを残してください。サブスクリプションURL全体を公開したり、変更した長い設定ファイルを動作中の環境にそのまま上書きしたりしないでください。まず最小限の比較テストを行い、その後でDNS、ルーティング、TUN設定を変更する必要があるか判断しましょう。
設定後に読む応用情報
接続できるようになったら、実際に起きている問題に合わせて記事を選びましょう。LAN内共有では、ほかの端末からPCのポートへアクセスする方法を扱います。証明書エラーではブラウザーの安全性確認、DNSの確認ではドメイン名の名前解決経路を調べます。問題ごとに確認箇所は異なるため、複数の記事にある設定を一度にすべて適用するのは避けてください。現在の設定を保ち、一度に一つの変更を検証しましょう。
検査ページでDNS問い合わせが漏れているかを確認してから、dnsセクションのenhanced-mode、nameserver、fallbackを項目ごとに解説し、そのまま使える設定例を紹介します。
読む際は、DNS問い合わせの経路とWeb接続の経路を分けて考えてください。検査ページに表示されるDNS事業者は手がかりの一つにすぎず、現在の通信の取り込み方式と合わせて判断する必要があります。見慣れない名前が表示されたからといって、DNS設定全体を置き換えないでください。
システム時刻のずれ、公共Wi-Fiでの通信の改ざん、ノードの異常、ルール設定の誤りなどを切り分け、証明書エラーとプロキシの実際の関係および対処法を解説します。
セキュリティ警告が表示されたら、アカウント情報や支払い情報の入力を中止し、システム時刻とアクセス先のドメインを確認して、別のネットワークでも比較してください。プロキシをオンにしたときに証明書エラーが発生しても、それだけで両者の因果関係が証明されるわけではありません。
mixed-portがHTTPとSOCKS5を同時に受け付ける仕組みを解説し、allow-lanの有効化、PCのLAN内IPアドレスの確認、スマートフォンのWi-Fi設定でのプロキシ指定を紹介します。
共有する前に、まずPC単体でアクセスできることを確認し、2台の端末が相互に通信できるLANに接続されているか調べます。LAN内共有を許可するだけでは不十分です。待ち受けアドレス、ファイアウォール、スマートフォンに入力するプロキシポートも確認してください。