用語を確認 / よく使う25語
まずサブスクリプション、ノード、設定ファイルの違いを確認し、次にルールやDNSを調べましょう。各用語は見出し横のリンクから共有できます。実際の操作はチュートリアルや設定資料をご覧ください。
読み込むのは設定ファイル、接続に使うのはノードです。通信の対象範囲はOSの設定も確認しましょう。
基礎知識
サブスクリプションは、URLを使ってノードや設定を取得・更新する仕組みであり、プロキシ接続そのものではありません。完全なYAMLが返る場合もあれば、ノード一覧だけの場合もあります。読み込む前に、クライアントが対応する形式を確認してください。更新後は設定を有効にし、ポリシーを選択する必要があります。サブスクリプションURLには認証情報が含まれることが多いため、公開したりスクリーンショットに載せたりしないでください。
サブスクリプションの読み込み手順を見る →基礎知識
ノードは、リモートのプロキシサーバーに接続するための設定情報です。通常、サーバーアドレス、ポート、プロトコル、認証情報が含まれます。画面に表示される名前はラベルにすぎず、実際の接続先や利用可能かどうかは名前だけでは判断できません。ノードを選んだうえで、通信がコアに入り、ルールやポリシーからそのノードに振り分けられる必要があります。
基礎知識
遅延は、指定したプローブにかかる時間です。接続の確立、TLSハンドシェイク、リクエストへの応答が含まれることがあり、OSのping結果と一致するとは限りません。テスト先、キャッシュ、ネットワーク状況によって値は変わります。同じ条件で接続を比較する目安にはなりますが、ダウンロード速度には換算できません。タイムアウトが発生した場合は、ログもあわせて確認してください。
基礎知識
システムプロキシは、OSがアプリに提供するプロキシアドレスの設定で、多くの場合は端末上のクライアントが待ち受けるポートを指定します。ブラウザーなどは設定に従いますが、ゲームやコマンドラインツール、独自のネットワーク処理を使うアプリは無視することがあります。設定が有効でも、そのアプリの通信が実際に取り込まれているとは限りません。該当する接続やログを確認してください。
基礎知識
混合ポートでは、1つのローカル待受ポートでHTTPとSOCKS5の両方のプロキシ接続を受け付けます。例：mixed-port: 7890。この数値は変更可能なローカルポートであり、リモートノードのポートや速度を示すものではありません。アプリに設定するポートは、実際の待受ポートと一致させてください。起動できない場合は、まず別のプロセスがそのポートを使用していないか確認しましょう。
プロトコルによって接続方式が決まり、認証、トランスポート、TLSの各設定も個別に合わせる必要があります。
プロキシプロトコル
HTTPプロキシは、アプリから送られるプロキシリクエストを受け付けます。HTTPSサイトへのアクセスでは、通常CONNECTでトンネルを確立し、その後アプリとサイト間でTLS通信を行います。プロキシの種類がHTTPだからといって、HTTPサイトにしか接続できないわけではありません。また、アプリからプロキシまでの通信が暗号化されているとも限りません。手動で設定する際は、プロキシのプロトコルと接続先サイトのプロトコルを区別してください。
プロキシプロトコル
SOCKS5は汎用プロキシプロトコルで、TCPを転送でき、双方の実装が対応していれば所定の仕組みでUDPも転送できます。ドメイン名をローカルで解決するか、プロキシ側で解決するかは、アプリの実装や設定によって異なります。SOCKS5という名称だけでは判断できません。SOCKS5自体に暗号化機能はなく、アプリがTCPプロキシに対応していてもUDPプロキシに対応するとは限りません。
プロキシプロトコル
Shadowsocksはプロキシプロトコルの一種です。クライアントとサーバーで、同じ暗号化方式と対応する認証情報を使う必要があります。ノードを読み込んでも接続できない場合は、ノード名だけでなく、アドレス、ポート、暗号化方式、認証情報を確認してください。プロトコル拡張やプラグインには別途要件があるため、どのクライアントにも同じShadowsocks設定をそのまま適用できるわけではありません。
プロキシプロトコル
Trojanは通常、TLSを使ってプロキシ通信を行います。アドレス、ポート、認証情報に加えて、TLS設定も正しく指定する必要があります。サーバー名は証明書の検証やハンドシェイクに使われる場合があり、接続先アドレスと検証する名前が同じとは限りません。証明書エラーが発生した場合は、システム時刻、名前、サーバー設定を確認してください。証明書検証の無効化を通常の対処法にしないでください。
プロキシプロトコル
VLESSはプロキシプロトコルの一種で、実際の構成ではTLS、REALITY、さまざまなトランスポート方式と組み合わせて使われます。プロトコル名だけではノードを再現できず、認証ID、トランスポート方式、対応するセキュリティ設定も必要です。クライアントに設定を読み込めても、搭載コアがすべての組み合わせに対応しているとは限りません。サーバー側の要件と実際のコアの対応状況を確認してください。
まず接続に一致したルールを確認し、次にそのルールがどのポリシーを指定しているかを確認しましょう。
ルールとルーティング
ルールベースのルーティングでは、ドメイン名やIPアドレスなどの条件に応じて接続先を決めます。通常、ルール一覧の上から照合し、一致すると指定されたポリシーに渡されます。たとえばDOMAIN-SUFFIX,example.com,DIRECTは、一致したドメインを直接接続に振り分けます。一般に上のルールほど優先されるため、正しいルールを追加しても、それより前にある広範なルールに先に一致することがあります。
ルールとルーティング
プロキシグループはノードやほかのポリシーをまとめるもので、手動選択のselect、プローブ結果に基づいて選ぶurl-test、障害時に切り替えるfallbackなどの種類があります。ルールがグループ名を指定した後、グループの種類や現在の状態に応じて実際の接続先が決まります。グループ名とノード名を正確に合わせてください。選択を変更しても、既存の長時間接続はすぐに切り替わらない場合があります。
ルールとルーティング
ルールモードでは、設定内のルールに従って接続ごとに振り分けます。グローバルモードでは通常、コアに届いた接続をグローバルポリシーで処理します。グローバルモードにしても、すべてのアプリがシステムプロキシに従うわけではなく、TUNが有効になるわけでもありません。普段はルールモードを使い、問題の切り分けで一時的にグローバルモードへ切り替える方法は有効ですが、詳細な調査の代わりにはなりません。
ルールとルーティング
GeoIPは、IPアドレスの地域分類データベースを使ってルールを照合します。たとえば接続先IPの地域に応じてポリシーを選べます。ドメイン名の分類データではなく、地域判定が常に正確とは限りません。クラウドサービスやネットワークの移転で誤差が生じることもあります。特定のサイトが誤ったポリシーに振り分けられる場合は、まず一致したルールを確認し、ドメインルールの調整かデータの更新かを判断してください。
ルールとルーティング
ルールセットでは、一連の照合条件を独立したデータとしてまとめ、rule-providersから読み込み、RULE-SETで適用するポリシーを指定します。更新や再利用に便利ですが、内容の形式をbehaviorなどの指定と一致させる必要があります。ダウンロードできた後は、ルール一覧から参照されていることと、適切な順序で照合されることも確認してください。
名前解決の経路、接続の経路、通信を取り込む範囲は、関連はありますが別々の問題です。
DNSとネットワーク
DNSはドメイン名をIPアドレスなどのレコードに変換します。Webサイトへのアクセスでは、通常、名前解決の後に接続を確立します。名前解決に成功しても、接続先に到達できることやプロキシ経由で通信していることは証明されません。逆に、接続失敗の原因がDNSとは限りません。ブラウザーが独自の暗号化DNSを使う場合もあるため、OSのDNS設定を変更した後は、アプリが実際にその経路を使っているか確認してください。
DNS設定を見る →DNSとネットワーク
Fake-IPモードは、ドメイン名の問い合わせに仮想アドレスを返し、コアがドメイン名とアドレスの対応を管理します。後続の接続をドメイン名に結び付けるために利用できます。仮想アドレスはWebサイトの実IPではないため、サーバーの所在地を判断する用途には使えません。実IPや特殊な検出方式に依存するアプリは、フィルター設定で対応が必要な場合があります。このモードを有効にしても、すべてのDNSリクエストが取り込まれるとは限りません。
DNSとネットワーク
DNSリークとは、ドメイン名の問い合わせが想定した経路を通らず、別のDNSサービスで処理される状態です。検査ページに表示されたDNSサービスの地域だけでは、リークの有無を判断できません。想定する設定、ブラウザーの暗号化DNS、IPv6、OSのルーティングもあわせて確認してください。まず、どのDNSサーバーに名前解決を任せ、リクエストをどの経路で送るのかを明確にし、実際の動作を調べましょう。地域表示だけで結論を出すのは避けてください。
DNSとネットワーク
TUNモードは、仮想ネットワークインターフェースとルーティング設定を使い、IPパケットをコアに取り込みます。システムプロキシに従わないアプリの通信も取り込みたい場合に適しています。実際の対象範囲は、権限、自動ルーティング、除外設定、OSのネットワーク環境によって変わります。初めて有効にする前に、現在のネットワーク設定を控えておきましょう。競合が起きた場合は、ほかのVPNや同様の通信制御ツールを停止し、設定を一つずつ確認してください。
DNSとネットワーク
allow-lanは、同じLAN上のほかの端末からこの端末のプロキシサービスへのアクセスを許可するかどうかを設定します。スマートフォンやほかのPCのプロキシ設定が自動で行われるわけではありません。利用するには、適切な待受アドレスとファイアウォール設定に加え、ほかの端末でこの端末のLAN内アドレスとポートを正しく指定する必要があります。信頼できるネットワークで必要な場合に限って有効にし、プロキシの待受ポートをインターネットに公開しないでください。
画面は操作の入り口です。実際のネットワーク動作は、コアと最終的な設定によって決まります。
クライアントとコア
クライアントは通常、サブスクリプション管理、ポリシー選択、OSとの連携を担当し、コアはプロトコル接続、ルール照合、DNSなどのネットワーク処理を担当します。画面が似ているクライアントでも、内蔵コアや設定の生成方法が異なる場合があります。問題を報告する際は、クライアントとコアの両方の情報を伝えてください。画面のアプリを更新しても、実行中のコアが同時に更新されるとは限りません。
プラットフォーム別にクライアントを見る →クライアントとコア
mihomoはClashエコシステムのオープンソースコアで、以前はClash.Metaという名称でした。プロキシ接続、ルーティング、DNSなどを担い、GUIクライアントに組み込むほか、サーバーやルーターで単独でも実行できます。設定項目の説明を調べる際は、実際に動作しているコアとバージョンを確認してください。ほかのコア向けの設定を、そのまま現在の環境に使えるとは限りません。
クライアントとコア
YAMLはClashの設定によく使われるデータ形式で、インデントで階層を、ハイフンでリスト項目を表します。インデントにはタブではなくスペースを使い、設定の断片をコピーする際は元ファイルでの階層も保ってください。構文解析に成功しても、形式として読み込めたことしかわかりません。項目名や値の型、コアの対応状況は、設定を読み込んだ後に表示されるメッセージも確認してください。
YAMLの構造を見る →クライアントとコア
設定の上書きは、サブスクリプションなどの元データに、設定の断片を結合したりスクリプトを使ったりして最終設定を調整する仕組みです。DNS、ルール、待受設定などをローカルで保持する際によく使われます。結合順やリストへの追加・置換の扱いはクライアントによって異なります。変更後は、元のサブスクリプションファイルだけでなく、実際に有効な設定を確認してください。更新で上書きされるファイルを直接編集しても、変更を長期的に維持するのは困難です。
クライアントとコア
外部コントローラーは、クライアントの画面や管理パネルから状態を確認したり、ポリシーを切り替えたりするためのインターフェースです。よく使われるローカル待受アドレスは127.0.0.1:9090です。これは管理用の接続先であり、ブラウザーの通信に使う混合プロキシポートではありません。用途を間違えると接続に失敗します。通常はローカルからのアクセスに限定してください。リモート管理が必要な場合は、認証を設定し、アクセス元も制限しましょう。