01 サブスクリプション設定を追加して有効化する
要点：サブスクリプションを追加した後、設定を選択してコアに読み込ませる必要があります。作業を始める前に、サービス提供元から受け取ったサブスクリプションURL、または現在のコアに対応したYAML設定ファイルを用意してください。クライアント、サブスクリプション、ノードはそれぞれ別のものです。クライアントは操作画面、サブスクリプションは設定内容、ノードはリモート接続先を提供します。クライアントをインストールしただけで接続可能なノードが使えるようになるわけではなく、サブスクリプションを追加するためにシステムのネットワーク設定を先に変更する必要もありません。
リモートサブスクリプションを追加する
クライアントを開き、「設定」「サブスクリプション」またはProfilesの画面に進み、「新規作成」「追加」「URLからインポート」などの項目を探します。リモートとローカルを選べる場合はリモート設定を選び、URL欄にサブスクリプションリンクをすべて貼り付けます。名前には「普段使い」など、見分けやすい文字列を入力してください。貼り付け後、URLの前後に空白や改行、チャットアプリが付加した句読点が混入していないか確認し、保存またはインポートをクリックします。初回のダウンロードには少し時間がかかることがあります。完了すると、設定カードまたはサブスクリプションの記録が表示されます。
サービスによっては、通常のサブスクリプション、Clash用、その他の形式のURLが用意されています。現在のクライアントまたはmihomoコアに対応すると明記された形式を選んでください。ダウンロード後に解析エラーが表示されても、プロキシモードを何度も切り替える必要はありません。この段階では、まだ設定のインポートに問題があります。サービスのページに戻ってURLの種類を確認し、クライアントが示すエラー箇所を調べてください。サブスクリプション先がログインページや期限切れの案内、その他のテキストを返している場合、ブラウザーでURLを開けても有効な設定が返されているとは限りません。
設定を有効にして内容を確認する
インポートが完了したら、該当する設定カードの有効化ボタンをクリックするか、クライアントの選択操作を実行します。現在使用中の設定には通常、選択中の印が付きます。「適用」または「再読み込み」ボタンがある場合は、それも実行してください。次に「プロキシ」またはポリシーグループの画面を開き、グループ名と選択可能なノードが表示されているか確認します。サブスクリプション名が一覧にあるだけで、プロキシグループが一つも表示されない場合は、接続準備ができたとは判断できません。設定画面に戻って正しいファイルが選択されているか、コアの読み込みが失敗していないか確認してください。
ローカルのYAMLファイルを使う場合は、同じ設定画面でファイルをインポートし、保存後に有効化してください。ローカルファイルは通常、リモートサブスクリプションのようにサーバーから定期的に更新されません。ノード情報を変更する場合は、設定を再インポートするか、該当する設定を編集します。通常のノード共有リンクを、完全なYAMLファイルとして直接読み込ませないでください。個別ノードのインポートに対応しているかどうかは、クライアントによって異なります。形式が合わない場合は、まず提供元に対応形式を問い合わせてください。アカウント情報を含むURLを、よく知らないオンライン変換ツールに送信しないようにしましょう。
この手順の完了条件は、設定が選択され、コアで設定の解析エラーが発生せず、プロキシ画面に想定したポリシーグループとノードが表示されていることです。この時点ですべてのネットワークスイッチを有効にする必要はありません。次の手順でリクエストの振り分け方法を決めましょう。設定の上書き、リモート更新、ローカル編集の関係は、設定項目リファレンスで詳しく説明しています。
02 プロキシモードと出口ノードを選択する
要点：初めて使う場合は、まずルールモードを選び、実際に使うポリシーグループにノードを指定します。モードは接続の振り分け方を決め、ノードの選択はプロキシ対象のリクエストの接続先を決めます。この二つは互いに代用できません。クライアントのホーム画面またはプロキシ画面で、「モード」「出站モード」またはModeを探し、「ルール」またはRuleを選びます。次にポリシーグループの一覧を開き、現在の設定に含まれる選択グループを確認します。使うグループを展開し、ノードを一つクリックしてください。
3つのモードの違いを確認する
ルールモードは設定内のルールを順に適用してリクエストを処理します。接続によって直接接続したり、指定したポリシーグループに転送したりするため、日常利用に適しています。グローバルモードは、コアに届いた通常のプロキシ対象リクエストをグローバルポリシーに渡します。比較やトラブルシューティングのために一時的に使えますが、グローバルポリシーで出口を選ぶ必要があります。ダイレクトモードでは、リモートのプロキシノードを使わず、接続先へ直接接続します。ここでいう「グローバル」は通信を取り込む範囲を切り替えるものではありません。コアに届いていないアプリの通信は、グローバルモードに切り替えても自動的には取り込まれません。
設定ファイルに以下の項目がある場合、それぞれ待ち受けポート、プロキシモード、ログレベルを指定しています。これは一般的な設定項目の抜粋で、ノードや振り分けルールは含まれていないため、使用中のサブスクリプション設定全体の代わりにはなりません。初めて操作する場合は、インデントの構造に不慣れなままファイルを直接編集せず、画面上のモード切り替えを使ってください。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info適切なポリシーグループでノードを選ぶ
サブスクリプションには、デフォルトのプロキシ、メディアサービス、自動選択など、用途の異なるポリシーグループが含まれている場合があります。グループ名は設定の作成者が決めるため、すべてのクライアントに共通する固定名はありません。まずデフォルトのプロキシにあたる選択グループを探して展開し、その中からノードを選びます。グループ内に別のポリシーグループが表示される場合は、最終的な出口を確認できるまで展開してください。目立つ名前のグループを一つ変更しただけで、すべてのリクエストに適用されるとは限りません。実際に使われるグループは、リクエストに適用されたルールによって決まります。
ノードの横にあるテストボタンは、通常、指定したアドレスにプローブを送り、接続性をおおまかに確認します。応答があってもすべてのサイトにアクセスできるとは限りません。タイムアウトも、プローブ先のアドレスやローカルネットワークが原因の場合があります。初期設定では、テストに応答するノードを一つ選んで確認すれば十分です。自動選択の間隔、負荷分散、アプリごとの複数のポリシーを同時に調整する必要はありません。自動選択グループでノードを手動指定できない場合は、そのグループの種類による仕様です。設定に含まれる手動選択グループを使ってください。
設定後、モードがルールのままで、該当するポリシーグループに出口が指定されていることを確認します。これで設定上の接続先は決まりましたが、ブラウザーなどのアプリがリクエストをクライアントに渡しているとは限りません。次の手順で通信を取り込みます。モード、ポリシーグループの入れ子、ルールの参照関係についてはmode項目の説明をご覧ください。モード選択に関するよくある質問はFAQで確認できます。
03 コアを起動してアプリの通信を取り込む
要点：接続するには、コアの実行、設定の読み込み、アプリ通信のコアへの取り込みの3つがすべて必要です。クライアントのホーム画面に戻り、現在の設定が先ほどインポートしたファイルのままか、コアが実行中かを確認します。デスクトップクライアントによってはウィンドウを開くとコアが起動しますが、起動ボタンを押す必要があるものもあります。ウィンドウが表示されているだけで、コアも起動していると判断しないでください。起動に失敗した場合は、ログにポートの競合や設定の読み込みエラーがないか確認し、解消してからシステムプロキシを有効にします。
デスクトップではまずシステムプロキシでブラウザーをテストする
「システムプロキシ」または「システムプロキシに設定」のスイッチを探して有効にします。システムプロキシ設定に従うブラウザーの多くは、新しいリクエストをクライアントのローカル待ち受けポートに送ります。初回の確認では、既存の接続やページキャッシュの影響を抑えるため、古いタブを閉じて新しいウェブページを開いてください。ブラウザーのプロキシ設定を変更する拡張機能は一時的に無効にし、別のプロキシクライアントも同時に起動しないようにします。最終的に使われるアドレスが、現在のクライアントの表示と異なる場合があります。
システムプロキシは初回のブラウザー確認には通常十分ですが、すべてのプログラムに強制的に通信を転送する仕組みではありません。コマンドラインツール、一部のゲーム、独自にネットワーク接続を管理するプログラムは、システムプロキシを無視することがあります。ブラウザーは使えてターミナルでは失敗する場合でも、サブスクリプションやノードが壊れているとは限りません。まずブラウザーでの確認を済ませてください。こうしたプログラムの通信も取り込む必要がある場合は、アプリごとにプロキシを設定するか、クライアントのTUN機能を検討します。一つのプログラムの通信を取り込むために、複数のネットワーク設定を一度に変更しないでください。
モバイルではシステムのVPN許可を確認する
モバイル版では通常、ホーム画面に接続ボタンがあります。タップすると、VPN接続の確立やVPN設定の追加を許可するか、システムから確認される場合があります。要求元がインストールしたクライアントであることを確認してから許可してください。クライアントに戻って接続状態を確認し、別のVPNアプリがシステムの通信を取り込んでいないかも確認します。システムにVPNアイコンが表示されていても、ネットワークインターフェースが作成されたことを示すだけで、リモートノードが使えるとは限りません。次の手順で実際のリクエストを使って確認します。アプリごとのプロキシ設定に対応するクライアントでは、テストするブラウザーが通信の取り込み対象になっているかも確認してください。
初回接続ではTUNを併用しない
TUNは仮想ネットワークインターフェースを通じて通信を取り込みます。サービスのインストール、管理者権限、ルートやDNSの設定が必要になる場合があります。システムプロキシに従わないプログラムの通信を取り込む必要がある場合に限り、クライアントの案内に従って有効にしてください。モバイル版に同じ名前のスイッチがあるかどうかは、実装によって異なります。デスクトップでの初回テストは、まずシステムプロキシだけで行い、動作を確認してからTUNに切り替えて個別にテストします。問題が起きた場合、複数の通信経路を同時に調べずに、どの変更が原因か特定できます。
ログに待ち受けポートの競合が表示された場合は、古いプロキシプロセスを終了するか、クライアントで設定できる場合は待ち受けポートを変更します。アプリにプロキシアドレスを手動で設定するときは、アドレスとポートを現在のクライアントの設定に合わせてください。例に記載されたポートをそのまま使わないでください。自分の端末だけで使う場合、LAN共有を有効にする必要はありません。共有アクセスには待ち受けアドレスやアクセス制御の設定が必要で、これは後から行う設定です。接続後は現在の設定を変えず、最後の手順でリクエストが実際にどの経路を通ったか確認します。
04 接続経路とルールの適用を確認する
要点：ウェブページが開くだけでは不十分です。接続履歴で対象、ポリシー、出口も確認してください。クライアントの「接続」またはConnections画面を開いたまま、ブラウザーで確認したいサイトにアクセスします。接続画面に戻り、直前に発生したリクエストを探します。一覧がスクロールしたかどうかだけでなく、対象ドメインを優先して確認してください。リクエストがすぐ終了する場合は、クライアントに機能があれば最近の接続を表示するか、ログも開いた状態でページを再読み込みします。
コアに届いた通信とプロキシ経由の通信を区別する
対象のリクエストを見つけたら、適用ルール、ポリシーグループ、最終的な出力先を確認します。「ダイレクト」と表示されていれば、リクエストはコアに届いていても、現在のルールによって直接接続されている可能性があります。通信がまったく取り込まれていない状態とは異なります。接続経路に選択したポリシーグループとノードが表示されていれば、そのリクエストが指定したプロキシ経路を使ったと判断できます。一つのページから複数のドメインにリクエストが送られ、その一部が直接接続され、残りがプロキシ経由になるのは正常な振り分けの場合があります。すべての行に同じノードが表示される必要はありません。
出口アドレスを表示するウェブサービスは補助的な確認に使えますが、一度の結果だけで接続履歴の確認に代えることはできません。サービスが異なるアドレスファミリーの結果を表示する場合があり、ブラウザーのキャッシュや他のネットワーク拡張機能も判断に影響します。まずリクエストが指定したノードを実際に通ったことを確認してから、出口アドレスの変化を判断してください。内蔵のノードテスト、システムのVPNアイコン、スイッチの色は、それぞれ一部の状態を示すものにすぎず、接続全体が有効になった証拠にはなりません。
必要に応じてモードを一度比較する
ルールモードで対象にアクセスできない場合は、一時的にグローバルモードに切り替え、グローバルポリシーで先ほどテストしたノードを明示的に選んで、同じリクエストを再実行します。グローバルモードでは成功し、ルールモードでは失敗する場合は、適用ルールと該当するポリシーグループの選択を優先して確認してください。どちらのモードでも失敗する場合は、ノード、ローカルネットワーク、DNSを確認します。テスト後はルールモードに戻し、一時的な調査状態を普段の設定として残さないようにしましょう。グローバルモードでは、使えないノードは直らず、通信の取り込みの代わりにもなりません。
ターミナルではローカルプロキシを明示してテストする
コマンドラインでテストする場合は、ターミナルがシステムプロキシを読み取るかどうかに頼らず、クライアントの待ち受けアドレスを明示できます。次のコマンドは、クライアントがローカルの混合プロキシポート7890で実際に待ち受けている場合にのみ使えます。ポートが異なる場合は、先に設定画面に表示されている値へ変更してください。例のドメインはリクエストが完了するかを確認するためのもので、すべてのネットワークでプロキシ経由になるとは限りません。出口は接続履歴もあわせて確認してください。
curl -I --proxy http://127.0.0.1:7890 https://example.comHTTPレスポンスを受け取れた場合、通常は対象サービスとの通信が完了しています。ステータスコードの意味は対象サイトに応じて判断してください。ローカルプロキシポートに接続できないというエラーが出た場合は、リモートノードを変更するのではなく、コアの実行状態と待ち受けアドレスを確認します。クライアントがリクエストを受け取った後に接続タイムアウトを報告する場合は、ログを見てノードやリモート経路を調べてください。ログを共有するときは、サブスクリプションURL、認証情報、公開する必要のないアクセス先を削除します。
現象に応じて対処し、複数の設定を続けて変更しない
対象の接続記録が一つもない場合は、手順3に戻り、通信の取り込み範囲、ブラウザーのプロキシ設定、クライアントの起動状態を確認します。リクエストはあるものの、ルールが誤ったグループを選んでいる場合は、手順2のモードとグループ内の選択を確認します。正しい出口が表示されるのに接続できない場合は、ノードの状態、システム時刻、ネットワーク環境を調べてください。ドメインの名前解決エラーが出た場合は、まずエラーメッセージを記録します。DNSの変更、TUNの有効化、設定全体の更新を同時に行わないでください。一度に一つだけ変更し、同じ対象を再テストすると前後の結果を比較できます。
初期設定の完了条件は、サブスクリプション設定が有効で、モードとポリシーが明確に選択され、テストするアプリの通信がコアに届き、少なくとも一度、対象リクエストが想定した経路を通ることです。確認後に、OS起動時の自動起動、自動更新、アプリ専用ルールを設定し、使用中の設定名と通信の取り込み方法を記録しておきましょう。YAMLを詳しく調整する場合は、設定項目リファレンスで項目ごとに確認できます。特定のトラブルを解決したい場合は、最初からインストール手順をやり直さず、まずFAQで症状から該当項目を探してください。