1. クライアント・コア・サブスクリプションの役割は？

クライアントは操作画面、コアは接続とルール処理、サブスクリプションは設定データを提供します。クライアントをインストールしただけでは、利用可能なノードが手に入るわけではありません。使い始める前に、クライアントからコアを起動できること、設定をコアが読み込めること、設定内のノードが現在も利用可能であることを確認しましょう。

クライアントを選ぶ際は、まずOSとプロセッサのアーキテクチャを確認し、使用するコアがサブスクリプション内のプロトコルや設定項目に対応しているか調べましょう。「未知のプロキシタイプ」と表示された場合、ポートを何度も変更しても解決しないことがほとんどです。まずプロトコルの対応状況を確認してください。対応プラットフォームはクライアントダウンロードページ、各方式の違いはクライアント選びガイドをご覧ください。

2. サブスクリプションURLを正しく追加するには？

追加・有効化・動作確認は、それぞれ別の手順です。一覧に設定名が表示されても、クライアントに項目が保存されたことしか分かりません。ダウンロードした内容が有効であることを確認し、その設定を現在のプロファイルとして選ぶ必要があります。

  1. サービス提供元からClashまたはmihomo用のサブスクリプションURLをコピーします。アカウント管理ページのURLをサブスクリプションと取り違えないようにしてください。
  2. クライアントの「設定」または「Profiles」画面で、URLからインポートする項目を探します。メニューはクライアントごとに異なるため、実際の画面に従ってください。
  3. インポート後、更新日時とエラー表示を確認します。その設定を選択し、コアでの読み込みに失敗していないことも確認してください。
  4. プロキシグループの画面でノードを選び、システムプロキシを有効にして、ブラウザーから実際にリクエストを送ってみましょう。

ノード一覧だけを返すURLもあります。その場合は、互換性のある proxy-providers 設定に追加してください。完全なProfileとしてそのままインポートすることはできません。形式を変換するために、機密性の高いサブスクリプションを信頼できないオンラインサービスへ送信しないでください。サービス提供元が用意している対応形式を優先しましょう。

3. Profileはノード一覧？ローカルでの変更は保持される？

Profileは切り替えて使う設定一式で、ノードだけとは限りません。完全な設定には、待ち受けポート、DNS、プロキシグループ、ルールなども含まれることがあります。リモートProfileを更新すると、ダウンロードしたファイルを直接編集した内容は上書きされる場合があります。個人設定の保存には、クライアントの永続化用オーバーライド、マージ、上書き機能を使うのがおすすめです。

以下は設定の一部であり、単独でインポートできる完全なサブスクリプションではありません。ポート、モード、ログレベルがそれぞれ独立した設定項目であることを示しています。既存の設定では該当項目を変更し、ファイル末尾に同じキーを重複して追加しないでください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

「普段使いのサブスクリプション」「一時テスト」など、用途が分かる名前を付けておくと便利です。切り替え後は現在の設定名とプロキシグループの選択を確認しましょう。ローカル設定をコピーする前にノードのパスワードが含まれていないか確認し、バックアップファイルも安全に保管してください。

4. ルール・グローバル・DIRECTモードの選び方

普段はルールモード、振り分けの問題を一時的に切り分けるならグローバルモード、プロキシを経由しない通信にはDIRECTモードを使います。モードで変わるのは接続の出先を選ぶ方法です。パスワードの誤り、使えなくなったノード、接続不能なプロキシサーバーが直るわけではありません。

モード主な動作確認するポイント
ruleルールの順序に従って出先のポリシーを判定一致したルールとプロキシグループの現在の選択
global通常の接続をグローバルポリシーで処理GLOBALで現在選択されている出先
direct通常の接続はDIRECTで出力接続先にローカルネットワークから直接アクセスできるか

以下のルール例はマッチング順序を示すものです。既存の proxy-groups に「プロキシ選択」という名前のプロキシグループが定義されていることを前提としています。example.com はルール構文の例として使うドメインで、接続確認用のサイトではありません。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,プロキシ選択

ルールは通常、上から順に評価されます。末尾の MATCH は、それ以前のルールに一致しなかった接続を処理します。フォールバック用のルールを先頭に置くと、後続のルールが機能しなくなります。また、「ルールモードならすべてプロキシ経由」というのも誤解です。ルールで DIRECT を選ぶことも、プロキシグループ自体がDIRECTを選択することもあります。

5. システムプロキシを有効にしたのに、ターミナルがプロキシを経由しないのはなぜ？

システムプロキシは、すべての通信を強制的に引き受ける機能ではありません。システム設定に従うアプリにプロキシアドレスを渡す仕組みです。一部のコマンドラインツール、ゲーム、独自のネットワーク処理を行うアプリは、この設定を自動で使いません。ブラウザーもプロキシ拡張機能や個別設定の影響を受けることがあります。

明示的なプロキシ指定で、コアの問題とアプリ側の設定を切り分ける

実際のmixed-portが 7890 だとすると、Windows PowerShellでは標準搭載の curl.exe を使ってリクエストを送れます。実行ファイル名を明示することで、環境によって curl が別のコマンドとして解釈されるのを防ぎます。

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

このコマンドで、指定したポートを使うプロキシ経由のリクエストを確認できます。アクセス先はサンプルサイトのため、出口の地域やすべてのWebサイトへの接続可否を証明するものではありません。プロキシを明示すれば成功するのに、ツールを通常どおり実行すると失敗する場合は、すぐにサブスクリプションを変えず、ツール独自のプロキシ設定を確認してください。

必要に応じて、現在のターミナルだけに環境変数を設定する

$env:http_proxy = "http://127.0.0.1:7890"
$env:https_proxy = "http://127.0.0.1:7890"

以下のPowerShellの設定が適用されるのは、現在のプロセスと、そこから起動した子プロセスです。また、ツールが該当する環境変数に対応している必要があります。https_proxy の値に http:// を使うのは、ローカルのプロキシがHTTP方式だからです。接続先のHTTPSサイトが平文通信に切り替わるわけではありません。解除するには Remove-Item Env:http_proxy, Env:https_proxy -ErrorAction SilentlyContinue を実行します。

6. ポート7890が使用中の場合、どこを変更する？

まず使用中のプロセスを特定し、重複したプロセスを終了するか、待ち受けポートを変更するか判断しましょう。ログに address already in use と表示される場合、通常はコアが指定のアドレスとポートを確保できていません。リモートノードのタイムアウトを意味するものではありません。

Windowsでは、ローカルの待ち受けポートとプロセスIDを確認できます。

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

OwningProcess の数値を取得したら、タスクマネージャーの「詳細」タブでPIDを確認するか、Get-Process -Id の後ろにその数値を指定してプロセスを調べます。ポート番号だけを見て、正体の分からないプロセスを終了しないでください。別のプロキシクライアントや、同じクライアントで終了しきれなかったコアがよくある原因です。

  1. クライアントが重複している場合は、不要な方を通常の方法で終了してから、使用するコアを再起動します。
  2. ポートを変更する場合は、実際に適用されている mixed-port を、使用中の 7890 から空いている 7891 に変更します。
  3. システムプロキシ、ターミナルの環境変数、アプリに手動設定したプロキシアドレスも合わせて変更し、古いポートへの接続が残らないようにしてください。

クライアントの画面設定がYAMLのポート値を上書きすることがあります。変更後は実行ログや待ち受けポート一覧で、最終的な値を確認してください。また、プロキシの待ち受けポートと管理用ポートは別です。external-controller は管理API用のため、ブラウザーのプロキシポート欄に設定しないでください。

7. ノードがタイムアウトしたら、サブスクリプションが無効？

必ずしもそうとは限りません。タイムアウトは、あるテストが制限時間内に完了しなかったことを示すだけです。テスト用URL、DNS、ローカルネットワーク、ノードのプロトコル、サーバーの状態などが結果に影響します。クライアントの遅延テストは通信速度の測定ではないため、遅延が小さくてもダウンロード速度が速いとは限りません。

トラブルシューティングでは、「発生時刻」「接続先ドメイン」「エラーの種類」「選択したプロキシ」の4点を記録すれば十分です。connection refused は通常、接続拒否を示し、i/o timeout は関連する読み書きのタイムアウトを示します。どちらも、ログの一行だけでアカウントの期限切れとは判断できません。

8. DNSやTUNモードは最初から有効にすべき？

まず通常のプロキシ接続を確認し、必要なアプリに応じてTUNを追加しましょう。DNSは通信の取り込み方法と合わせて確認してください。TUNは仮想ネットワークインターフェースで通信を取り込み、システムプロキシに従わないアプリにも使えます。ただし、対象範囲はOS、ルーティング、除外設定によって異なり、有効にしただけですべての通信がプロキシノード経由になるわけではありません。

DNSの問題は症状から切り分ける

ログにドメインの名前解決エラーが表示された場合、「ノードサーバーのドメインを解決できない」のか、「接続先Webサイトのドメインを解決できない」のかを区別しましょう。前者ではプロキシ接続そのものを確立できない可能性があり、後者は接続先リクエストの名前解決経路に関係します。既存のサブスクリプションを残さずDNS設定一式で置き換えると、DNSサーバー、名前解決方式、通信の振り分けが同時に変わるため、避けてください。

TUNを有効にする前に確認したい3つの条件

  1. コアとクライアントが現在のシステムのTUN機能に対応し、必要な権限を取得していること。一部のデスクトップクライアントでは、サービスモードや管理者権限が必要です。
  2. 通常のプロキシを明示したリクエストが成功していること。ノードの問題と仮想ネットワークアダプターの問題を混同せずに切り分けられます。
  3. 別のVPN、仮想ネットワークアダプター、プロキシツールがデフォルトルートを同時に使用していないことを確認します。有効にした後は、接続ログとシステムのネットワーク状態も確認してください。

9. 自動起動を有効にしたのに、手動接続が必要なのはなぜ？

ログイン後のクライアント起動、コアの起動、設定の復元、プロキシの有効化は、それぞれ別の処理です。クライアントによってはウィンドウやタスクトレイのプロセスだけを復元し、システムプロキシを自動で有効にしない場合があります。サービスモードを使っても、ユーザーのログイン時にGUIが起動するとは限りません。

Windows 11の場合、「設定」→「アプリ」→「スタートアップ」でクライアントのスタートアップ設定を確認できます。または「タスクマネージャー」→「スタートアップ アプリ」で状態を確認してください。「コアを起動」「前回の状態を復元」などの項目がクライアント内にあるかどうかは、実際に使っている製品で確認しましょう。他のクライアントのメニュー手順をそのまま当てはめないでください。

ウィンドウを閉じて再度開くだけでなく、PCを完全に再起動して確認しましょう。ログイン後にネットワーク接続が少し遅れて確立する場合、最初のサブスクリプション更新に失敗しても、すぐに再インストールする必要はありません。ネットワーク接続後に手動更新し、ログを確認する方が原因を特定しやすくなります。

10. 最初の1週間の使い方と、問題発生時の復旧方法

使える設定を残し、変更は一度に一種類だけ行い、同じリクエストで再テストしましょう。DNS、モード、TUN、ノードを同時に変更すると比較できなくなり、接続が戻っても、どの変更が有効だったのか分からなくなります。

  1. 基準となる状態を記録：クライアント名、コアのバージョン、現在のProfile、待ち受けポート、プロキシモードを記録しておきます。バージョン番号はクライアントの「バージョン情報」またはコア情報画面で確認し、インストーラーのファイル名だけで管理しないでください。
  2. 更新を管理：サービス提供元の推奨に従ってサブスクリプションの更新間隔を設定します。更新に失敗したら、連続して何度も再試行せず、まずネットワークと返された内容を確認してください。
  3. 一段階ずつ変更：まずノードを変更して同じリクエストをテストします。ルールを調整する場合は一度に一つだけ変更し、接続ログで適用されたことを確認してください。
  4. 復旧手段を確保：設定を変更する前にバックアップします。使えるProfileに戻した後も、クライアントで全体設定のオーバーライドが適用されていないか確認してください。
  5. 正しい手順で終了：まずシステムプロキシを無効にしてからクライアントを終了します。TUNを使っている場合は、通信の取り込みも停止したことを確認し、存在しないローカルポートへの接続が残らないようにしてください。

終了後にブラウザーがインターネットへ接続できない場合、Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」の手動プロキシを確認してください。macOSでは「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」を確認します。組織が管理する端末では、管理対象の設定を無断で変更しないでください。コマンドラインだけに問題が残る場合は、ターミナルにプロキシ環境変数が残っていないか確認しましょう。

最初の1週間の確認項目は明確です。設定を有効にできること、プロキシを明示したリクエストが成功すること、アプリが想定した経路を使うこと、再起動後に状態が復元されること、終了後に直接インターネットへ接続できることを確認してください。YAMLの各項目を確認する場合は設定項目の解説、インストールとインポートの手順は入門ガイドをご覧ください。