mihomo
プロキシコアプロキシプロトコルの処理、DNS、ルール照合、接続の転送を担う中核プログラムです。Clash Nyanpasuは設定管理とGUIを提供します。画面に設定項目が表示されていても、実行中のコアがその項目に対応しているとは限りません。コアの対応状況を確認してください。トラブルシューティングでは、クライアントのバージョン、コアの種類、適用中の設定を個別に記録し、クライアント名だけで動作を判断しないようにします。
REFERENCE / CLASH TERMINOLOGY
Clash用語集
画面に表示される名称から設定の概念を確認できます。コア、項目、ルール、ネットワーク、クライアントの5つに分け、設定の取得元、実行時のパラメーター、リクエストの処理経路を整理しています。
初期設定はクイックスタートをご覧ください。設定項目やYAMLの例を詳しく確認するには、YAMLガイドをご利用ください。このページでは用語の意味と適用範囲を解説します。スイッチの状態だけで、実際の接続結果を判断することはできません。
TERMS / 01
コアとプロトコル
クライアントは設定管理と画面操作を担い、コアはネットワーク処理を実行します。アプリからローカルプロキシへの接続に使うプロトコルと、ノードからリモートサーバーへの接続に使うプロトコルは、同じとは限りません。
プロキシノード
Proxy／接続先の定義ノード設定には、リモートサーバーのアドレス、ポート、プロトコル、認証情報を記述します。通常はproxiesまたはプロキシ集合に含まれます。ノードとサブスクリプションは別のものです。前者は接続先の定義、後者は設定の配布方法です。ノードをインポートしても、リクエストはモード、ルール、プロキシグループに基づいて処理されます。ノードが存在するだけでは、その出口を通信が通っているとは判断できません。
HTTPプロキシ
アプリ接続用プロトコルアプリからプロキシインターフェースに明示的に接続し、リクエストを送信するか、CONNECTでトンネルを確立します。ここでいうHTTPはアプリとローカルプロキシ間の通信方式を示すもので、リモートノードがWeb通信しか処理できないという意味ではありません。また、通信経路全体が平文であることを示すものでもありません。アプリには実際に待ち受けているローカルアドレスとポートを設定してください。HTTPS接続の証明書検証は、通常、アプリが行います。
SOCKS5
接続先アドレスの転送プロトコルアプリはSOCKS5で接続先アドレスをプロキシに渡し、接続を確立します。TCPに対応し、UDP転送の仕組みも定義されています。UDPを実際に使うには、アプリ、プロキシインターフェース、その後の通信経路がすべて対応している必要があります。名前解決の場所は、アプリがドメイン名と事前に解決したIPアドレスのどちらを渡すかによって異なります。プロキシの種類だけでDNSの経路を判断することはできません。
TLS
通信を保護するプロトコルTLSは通信相手の認証、通信の暗号化、完全性の保護を提供し、Web接続にもプロキシプロトコルの通信保護にも利用できます。ハンドシェイクに失敗した場合は、証明書、サーバー名、システム時刻、通信経路の到達性を確認してください。証明書検証を無効にすると相手の確認が弱まります。常用設定にするのではなく、まず証明書や名前の不一致の原因を特定してください。
TERMS / 02
設定ファイルの項目
項目名、階層、データ型によって設定の意味が決まります。設定例を読むときは、項目がトップレベル、DNS設定、ノード定義、プロキシグループのどこにあるかを確認してください。
YAML
設定ファイルの形式YAMLではインデントを使ってマッピングやリストを表します。Clashの設定は通常、.yamlまたは.ymlとして保存します。インデントにはスペースを使い、同じ階層の項目をそろえ、リスト項目はハイフンで記述します。構文解析に成功しても、構造を読み取れたことを示すだけです。項目が認識されるか、値が有効か、参照先が存在するかは、実際に使用するコアで確認してください。
mixed-port
HTTPとSOCKSでポートを共有この項目を設定すると、HTTPプロキシとSOCKSプロキシのインターフェースが、ローカルの待ち受けポートを共有できます。複数のアプリから同じサービスに接続する際に便利です。リモートノードのportとは意味が異なり、すべてのアプリのプロキシ設定が自動で変更されるわけではありません。起動時にポートの競合が表示されたら、まず使用中のプロセスを確認してください。待ち受けポートを変更した場合は、OSやアプリ側の設定も更新します。
mode
rule / global / direct共通項目のmodeは、リクエストをルール、グローバル、DIRECTなどのどのモードで処理するかを決めます。ルールモードはrulesに従ってポリシーを選び、グローバルモードは全体のポリシーを使い、DIRECTモードは接続先に直接接続します。モードはリクエストがコアに入った後の処理方法を決めるものです。システムプロキシやTUNはリクエストをコアに渡す方法を決めるため、グローバルモードに切り替えても、すべてのアプリが自動的に取り込まれるわけではありません。
Fake-IP
DNSによる合成アドレスの割り当てこのDNSモードでは、コアがアプリに合成アドレスを返し、そのアドレスと元のドメイン名の対応を管理します。これにより、後続の接続をドメイン名に基づいて処理できます。合成アドレスは対象サイトの実際のグローバルIPアドレスではありません。実IPでの名前解決を必要とする一部のアプリでは、フィルター設定が必要な場合があります。変更後は、古い結果に惑わされないよう、OS、ブラウザー、アプリのキャッシュも確認してください。
proxy-providers
プロキシ集合の取得元この項目は再利用可能なプロキシ集合の取得元を定義し、プロキシグループからuseで名前を指定して参照します。プロキシ集合とProfile全体では用途が異なります。集合ファイルにDNS、ルール、共通の待ち受け設定が含まれているとは限りません。更新に失敗した場合は、取得元の形式、取得先、プロキシグループからの参照を個別に確認し、集合の内容が最終的な実行設定に反映されているかを調べてください。
TERMS / 03
プロキシグループとルール
ルールは使用するポリシーを決め、プロキシグループは接続先の選び方を決めます。リクエストの経路を調べるときは、一致したルール、対象のポリシー、最終的な接続先の順に確認してください。
ルールによる振り分け
Rules／リクエストの分類ルールによる振り分けでは、ドメイン名、IPアドレスなどのリクエスト属性に基づき、DIRECT、REJECT、プロキシポリシーのいずれかを選びます。ルールは通常、上から順に評価され、最初に一致したルールの接続先が適用されます。そのリクエストに対して、後続のルールは評価されません。一般に、具体的な条件は広い条件より前に配置します。ルールを変更したら、ページが開くかどうかだけで判断せず、新しい接続のルール適用記録を確認してください。
プロキシグループ
proxy-groups／接続先の構成プロキシグループは、ノード、ほかのプロキシグループ、組み込みポリシーをまとめ、ルールから参照できる接続先を作ります。selectは主に手動選択、url-testはテスト結果に基づく自動選択、fallbackは順番に利用可能な接続先へ切り替える方式です。名前が同じでも動作が同じとは限りません。問題を調べる際は、グループの種類、メンバーの取得元、入れ子の参照が循環していないかも確認してください。
GeoIP
IP地域データベースGeoIPはローカルデータベースを使ってIPアドレスの地域を判定し、GEOIPなどのルールに利用します。IPの登録地域はアクセスするユーザーの所在地とは限らず、Webサイトの内容や法的管轄を正確に示すものでもありません。データベースの更新、CDN、共有インフラによって結果が変わることがあります。リクエストにドメイン名しかない場合、一部のIPルールで名前解決が行われることもあります。
RULE-SET
外部ルール集合の参照RULE-SETは、rule-providersで定義したルール集合をルール列から参照する機能です。長いルール一覧を分けて管理できます。集合の動作タイプとファイル形式は、providerの定義に合わせてください。ドメイン一覧と完全なルール一覧をそのまま混在させることはできません。外部ファイルに分けても、メインのルール内での配置順が優先順位に影響します。最初に一致したルールが適用される点は変わりません。
MATCH
フォールバックルールMATCHは常に一致するルールで、未照合のリクエストにデフォルトのポリシーを適用するため、通常はrulesの最後に配置します。前に置くと、それ以降のルールは評価されません。接続先にはプロキシグループや組み込みポリシーを指定できますが、参照先が有効であることを確認してください。フォールバックをDIRECTにするかプロキシにするかは、設定の目的に合わせて決めます。
TERMS / 04
ネットワークとプロキシモード
通信の取り込み、名前解決、接続先の選択は、それぞれ別の処理です。スイッチが有効になっていても、それは設定状態を示すだけです。実際の通信経路は接続記録とOSのネットワーク設定をあわせて確認してください。
システムプロキシ
OSのプロキシ設定システムプロキシは、ローカルプロキシのアドレスをOSの設定に登録し、その設定に従うアプリからのリクエストをクライアントに渡します。独自のネットワーク処理を行うプログラム、一部のコマンドラインツール、個別にプロキシを設定したアプリは、この経路を使わない場合があります。クライアントを終了してもネットワークに接続できない場合は、OSに無効なプロキシアドレスが残っていないか確認し、プロキシ設定の問題とネットワーク自体の問題を切り分けてください。
TUNモード
仮想ネットワークインターフェースによる通信の取り込みTUNは仮想ネットワークインターフェースとルーティング設定を使い、条件に合うネットワークトラフィックをコアに渡して処理します。システムプロキシに従わないアプリでよく使われます。通常は追加のシステム権限が必要で、取り込み範囲はルートの除外設定、プロトコル対応、ネットワーク環境にも左右されます。有効にした後もDNSとルールを確認してください。TUNはネットワークの問題をすべて自動で解決する機能ではありません。
DNS漏れ
想定外の名前解決経路DNS漏れとは、DNSクエリが想定した名前解決経路を通らず、別のリゾルバーに届くことです。問題になるかどうかは、あらかじめ設定したプライバシーや振り分けの目的によって異なります。ブラウザーのセキュアDNS、アプリ内蔵の名前解決、システムDNSが、それぞれ独立した経路を使う場合があります。暗号化DNSはクエリの通信が保護されることを示すだけで、想定したプロキシ出口を通った証明にはなりません。名前解決のポリシーとルーティングをあわせて確認してください。
allow-lan
LAN内からのプロキシアクセスallow-lanは、LAN内のデバイスからプロキシの待ち受けサービスへのアクセスを許可するかどうかを制御します。実際に接続できるかは、バインドアドレス、ファイアウォール、Wi-Fiのクライアント分離設定にも左右されます。ほかのデバイスからは、クライアントを実行している端末のLAN内アドレスを指定してください。各デバイス自身のループバックアドレスではありません。アクセスを許可する前に利用範囲を明確にし、適切な認証やアクセス制御を設定して、プロキシインターフェースの公開範囲を広げすぎないようにしてください。
接続遅延
測定先と方法によって異なる値画面に表示される接続遅延は、特定のテスト先へのリクエスト時間を示すことが多く、DNS、ハンドシェイク、接続先の応答、現在のネットワーク状況に左右されます。ファイルのダウンロード速度とは異なり、すべてのWebサイトでの接続状況を示すものでもありません。比較する際は、測定方法とテスト先をそろえてください。テストに失敗した場合は、ログも確認し、テスト先への接続不可、認証エラー、通信経路の異常を切り分けます。
TERMS / 05
クライアント画面
画面に表示される設定情報が、ディスク上の最終的な実行ファイルと一致するとは限りません。サブスクリプション更新後に設定が戻る、Profileを切り替えても反映されないといった場合は、まず設定の取得元と生成の流れを整理してください。
Profile
ProfileProfileは、クライアントが管理するローカルまたはリモートの設定です。通常、名前、取得元、更新設定などが含まれます。Profileを切り替えると設定の取得元が変わりますが、最終的な内容にはクライアント側のオーバーライドやマージが反映される場合があります。バックアップでは、元のファイル、リモート設定の取得元情報、オーバーライド内容を分けてください。生成後の実行ファイルだけをコピーしても、元の管理方法まで復元できるとは限りません。
サブスクリプション
リモート設定の配布サブスクリプションはURLを使って設定やノード集合を配布・更新します。取得内容はClash YAMLのほか、別のクライアント形式の場合もあります。URLにアクセスできても、現在のクライアントで直接解析できるとは限りません。インポート前に形式と用途を確認してください。サブスクリプションURLにはアクセス情報が含まれることが多いため、機密情報として扱ってください。調査やスクリーンショットの共有時はURL全体を隠し、取得元の情報を公開ページに掲載しないようにしてください。
オーバーライドとマージ
元の設定から実行時設定へオーバーライドは元の設定の項目を変更する処理で、マージは複数の設定レイヤーを組み合わせて最終的な実行設定を作る処理です。ローカルのDNS、待ち受け設定、ルールなどを維持するために使われます。スカラー値の上書き、マッピングの統合、リストの置き換え方はクライアントの実装によって異なり、すべてのリストが追加されるとは限りません。変更後は最終設定を確認してください。一時的に生成されたファイルを直接編集すると、次回の更新や切り替え時に再生成されることがあります。
接続ビュー
リクエスト経路の確認接続ビューでは、リクエスト先、適用されたルール、接続経路を確認できます。アプリの通信がコアに届いているか、ルールが想定どおりに動作しているかを調べるのに役立ちます。ポリシーを切り替えても、まず反映されるのは新しい接続です。既存の長時間接続は、以前の経路を使い続ける場合があります。変更を検証するには、リクエストを再実行するか、影響を確認したうえで該当する接続を終了し、ドメイン名とルールの記録を確認してください。アクセス結果だけから推測する必要はありません。
ログレベル
log-level／ログの詳細度log-levelはログの詳細度を指定します。一般的な値はinfo、warning、error、debugです。起動メッセージが出ても、必ずしも障害が起きているとは限りません。単一の接続エラーだけで、設定全体が無効とも判断できません。発生時刻や対象のリクエストとあわせて確認してください。一時的に詳細度を上げる場合は、ログにアクセス先のドメイン名やパスが含まれることがあります。共有前に機密情報を削除し、調査後は通常のレベルに戻してください。