1. インストール前に確認すること：クライアント、コア、システムアーキテクチャ

Clashの初期設定は、クライアントが起動する、設定を読み込める、ローカルプロキシポートが待ち受ける、アプリの通信がプロキシを経由する、の4段階に分けて確認できます。インストーラーが開いたのは、最初の段階を通過しただけです。順番に検証してからTUNや自動起動などを有効にすると、問題の切り分けが容易になります。

GUIクライアントはサブスクリプションの管理、プロキシグループの選択、システム設定を担当し、コアは設定の解析、ルール判定、外部への接続を担当します。Clash、Clash.Meta、mihomoは、自由に置き換えられるバージョン名ではありません。mihomo固有の項目や新しいプロトコルを使うサブスクリプションには、対応するコアが必要です。クライアント名だけで互換性を判断しないでください。

  • Windows：「設定」→「システム」→「バージョン情報」を開き、「システムの種類」を確認します。x64とARM64のインストーラーは、デバイスのアーキテクチャに合わせて選んでください。「Windows 11」という情報だけで判断しないようにしましょう。
  • macOS：Appleメニューから「このMacについて」を開きます。Appleシリコン搭載機ならARM64、Intelプロセッサ搭載機ならx64を選びます。
  • Android：近年の端末は通常ARM64ですが、古い端末や一部のシステムでは異なる場合があります。まずクライアントのリリース情報でAndroidの最低要件と対応アーキテクチャを確認し、判断できない場合は提供されている汎用パッケージを検討してください。

2. サブスクリプションの読み込み：ダウンロードできても設定が有効とは限らない

サブスクリプションURLにはアクセストークンが含まれることが多いため、パスワードと同様に扱ってください。信頼できる提供元からのみ取得し、URL全体を公開スクリーンショットやオンライン変換サイト、問い合わせに貼り付けないでください。サブスクリプションの応答は、ClashのYAML設定全体の場合もノード一覧だけの場合もあり、適切な読み込み画面が異なることがあります。

初回読み込み時の確認手順

  1. クライアントの設定またはサブスクリプション画面からリモート設定を追加し、URL全体を貼り付けます。画面の名称はクライアントによって異なります。プロキシサーバーのアドレス欄にURLを入力しないでください。
  2. 更新を一度実行し、設定の解析エラーが出ないか確認します。ログイン画面、期限切れの通知、通常のHTMLが返ってきた場合、ダウンロードが成功していてもYAML設定としては使えません。
  3. 読み込んだ設定を明示的に選択し、現在の設定として適用します。リストにサブスクリプションのカードが表示されただけでは、コアがその設定に切り替わったとは限りません。
  4. プロキシグループ画面を開き、利用可能なノードがあることを確認してから、ノードまたは想定するポリシーを手動で選択します。読み込みに成功してもDIRECTが選択されたままでは、通信が直接接続される可能性があります。
  5. 出力モードをルールモードに設定し、ルール一覧が空でないことと、末尾に想定したフォールバックポリシーがあることを確認します。

「サポートされていないプロキシタイプ」や「不明なフィールド」が表示されたら、まず設定が要求するコアを確認してください。HTTP 401または403の場合はトークンとアクセス権を、404の場合はURL全体が正しいか、リソースが移転していないかを確認します。エラーを切り分けずにクライアントを何度も再インストールするのは避けましょう。

サブスクリプションの更新とローカルの変更を分けて管理する

リモートサブスクリプションから生成されたファイルを直接編集すると、次回の更新で変更が上書きされることがあります。直結するドメインの追加、DNSやポートの変更には、クライアントのオーバーライド、マージ、ローカル拡張機能を優先して使い、適用後の最終設定も確認してください。元のサブスクリプションとローカル変更を分けて保存しておくと、元に戻しやすくなります。

3. ローカルポート：待ち受けアドレスとポートの競合を確認

システムプロキシには、クライアントが実際に待ち受けているアドレスとポートを指定します。よくある例は127.0.0.1:7890ですが、7890がすべてのクライアントの固定デフォルト値というわけではありません。現在の設定と実行ログを確認してください。コントロールAPI用のポートはコアの管理に使うもので、ブラウザーのHTTPプロキシ欄には指定しません。

以下はmihomoのローカル接続設定の一部です。各項目の説明用であり、ノードやルールを含む完全な設定ではありません。mixed-portは同じポートでHTTPとSOCKSのプロキシ接続を受け付けます。ループバックアドレスに限定すれば、初期設定時にLANへ誤って接続口を公開するのを防げます。

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

Windows：待ち受け中のプロセスを確認

netstat -ano | findstr :7890

ローカルアドレスが対象ポートで、状態がLISTENINGの行を確認します。最後の列がPIDです。タスクマネージャーの「詳細」タブでプロセスIDを照合できます。別のプロキシクライアントがポートを使用している場合は、まずそのクライアントを通常の手順で終了してから、現在のクライアントを起動してください。正体の分からないシステムプロセスを強制終了しないでください。

macOS：TCPの待ち受けを確認

lsof -nP -iTCP:7890 -sTCP:LISTEN

結果が表示されない場合は、コアの起動に失敗していないか、実際のポートが別の番号ではないかを確認します。未使用のポートに変更した場合は、システムプロキシやアプリ側の設定も同時に更新してください。設定だけ変更して接続先を変えないと、ブラウザーで接続拒否が発生します。

4. Windows・macOS：まずシステムプロキシを確認

システムプロキシを設定すると、システムプロキシ設定に従うアプリの通信がローカルクライアントに渡されます。端末のすべての通信を制御する機能ではありません。最初の動作確認にはブラウザーが適していますが、ゲームやコマンドラインツール、一部のアプリは独自のネットワーク設定を使うことがあります。

確認項目 Windows 11 macOS
システム設定の場所 設定 → ネットワークとインターネット → プロキシ システム設定 → ネットワーク → 現在の接続 → 詳細 → プロキシ
初回に確認する内容 手動プロキシのアドレスとポート、設定スクリプトが残っていないか Webプロキシ、セキュアWebプロキシ、SOCKSプロキシの有効状態とポート
ローカルアドレスの例 127.0.0.1、ポートは実際の待ち受け番号を指定 127.0.0.1、ポートは実際の待ち受け番号を指定

まずクライアントのシステムプロキシ切り替え機能で設定し、その後システム設定画面で確認してください。HTTPプロキシを設定する場合、macOSのWebプロキシとセキュアWebプロキシには、対応するHTTPポートまたは混合ポートを指定します。SOCKSプロキシにはSOCKSポートまたは混合ポートを使います。プロトコルが異なる接続先に、同じ数値を機械的に入力しないでください。

機能に応じて権限を許可する

  • Windowsのサービスモード：一部のクライアントでは、TUNなど権限が必要な操作をバックグラウンドサービスで実行します。必要な機能を使う場合に限ってサービスをインストールし、システムの許可画面でプログラムの提供元を確認してください。
  • macOSの補助コンポーネント：システムプロキシの設定や仮想ネットワークインターフェースの作成時に、クライアントが許可を求めることがあります。許可に失敗した場合はコンポーネントの状態を確認してください。問題を回避するためにアプリ全体を管理者権限で何度も起動するのは避けましょう。
  • システムによって起動がブロックされた場合：まずダウンロード元と、システムに表示された具体的な理由を確認してください。インストーラーを実行するために、システムのセキュリティ機能を全体的に無効にしないでください。

5. Android：VPNの許可とバックグラウンド動作

Androidクライアントは通常、デスクトップ版のシステムプロキシ設定ではなく、システムVPNインターフェースを使って通信を制御します。初めて接続ボタンをタップするとシステムのVPN許可画面が表示され、許可するとインターフェースを作成できます。ステータスバーにVPNアイコンが表示されても、確認できるのはインターフェースが作成されたことだけです。ノード、DNS、ルールが正常とは限りません。

  1. ほかのVPNを切断する。同じユーザーや仕事用プロファイルで使っているほかのVPN、ファイアウォール、フィルタリングアプリが、VPNインターフェースを取り合うことがあります。
  2. アプリの対象範囲を確認する。アプリごとのプロキシを有効にしている場合は、ブラウザーが対象に含まれているか、「選択したアプリのみ」と「選択したアプリを除外」のどちらが設定されているか確認します。
  3. バックグラウンド制限を確認する。「設定」→「アプリ」→対象クライアント→バッテリー関連の設定から、必要なバックグラウンド動作を許可します。設定画面の場所は端末メーカーによって異なります。通知権限もクライアントの要件に合わせて設定してください。
  4. 画面ロック後の復帰を確認する。接続後、数分間画面をロックしてから解除し、ページにアクセスします。クライアントの通知、接続状態、ログが途切れていないか確認してください。前面でしか動作しない場合は、まず省電力設定を調べます。

初期設定では「常時接続VPN」と「VPNを使用しない接続をブロック」を同時に有効にしないでください。後者はVPN未接続時にほかのネットワーク経路を遮断するため、サブスクリプションの更新やトラブルシューティングが複雑になります。一般的な設定場所は「設定」→「ネットワークとインターネット」→「VPN」→対象の接続設定ですが、メーカーによってメニュー名が異なることがあります。

通常のインターネット接続は正常なのに、接続後にドメインの名前解決エラーが出る場合は、AndroidのプライベートDNSとクライアントのDNS設定を確認してください。自動、指定したプロバイダー、オフを1つずつ切り替えて比較し、結果を記録します。プライベートDNSをオフにすることが、すべての端末で必須というわけではありません。

6. 通信の確認：ポートからルールまで順に検証

ノードの遅延テストに結果が出ても、すべてのアプリがプロキシを経由しているとは限りません。遅延テストの対象やプロトコルは、実際にアクセスするサイトと異なることがあります。ローカル接続口、クライアントの接続ログ、アクセス先のページを同時に確認する方法が確実です。

デスクトップ版で明示的なプロキシ接続をテスト

Windowsでは次のコマンドを使うと、PowerShellに同名のエイリアスがある場合でも回避できます。macOSではcurl.exeをcurlに置き換えてください。ポートは現在のクライアントが実際に待ち受けているHTTPポートまたは混合ポートに変更します。

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

ここで指定している接続タイムアウト10秒、全体のタイムアウト20秒は、トラブルシューティング用の値であり、速度テストの結果ではありません。HTTP応答が返れば、今回の明示的なプロキシ接続が完了したことを示しますが、ルールによって直接接続に振り分けられた可能性もあります。選択したノードを経由したか判断するには、接続詳細でルールの判定結果と最終的な出力先を確認してください。

  • 接続が拒否される：ローカルポート、待ち受けプロセス、コアの起動ログを確認します。
  • 接続ログが空：アプリがシステムプロキシを使用しているか、独自のプロキシ設定があるか、アプリ別ルールで除外されていないかを確認します。
  • DIRECTにマッチする：現在のモード、ドメインルール、ルールの順序を確認します。ノードの故障と決めつけないでください。
  • プロキシのハンドシェイクまたは認証に失敗する：サブスクリプションの状態、ノードの認証情報、プロトコルの対応状況、端末の時刻を確認します。
  • ドメインの名前解決に失敗する：DNSログ、上流サーバーへの接続性、現在のネットワークを確認します。TCPポートに接続できない問題とは分けて対処してください。

基本動作の確認後にTUNを設定する

ブラウザーがシステムプロキシ経由で動作し、特定のアプリだけがプロキシ設定に従わない場合に、TUNを検討します。TUNは仮想ネットワークアダプターとルーティングを通じて対象の通信を制御し、通常はDNSの制御や権限も必要です。ルーティング、除外設定、プラットフォームの制限があるため、「有効にすればすべての通信が必ずノードを経由する」とは限りません。

有効にした後、LAN上の機器に接続できない、ほかのVPNが切断される、ネットワークループが発生する場合は、まずTUNを無効にして元の状態に戻し、ルーティングと除外設定を確認してください。同じタイミングでノードの変更、DNSの変更、コアの切り替え、TUNのネットワークスタック調整を行うと、どの変更が影響したのか分からなくなります。

7. 自動起動と再起動後の確認

基本的な接続が安定してから、自動起動を設定します。クライアントのウィンドウが自動で開くこと、コアがバックグラウンドで動くこと、システムプロキシが復元されること、VPNが自動接続することは、それぞれ別の状態です。自動起動の項目を1つ有効にしても、4つすべてが設定されるとは限りません。Androidではアプリの自動起動とVPNの自動接続も、別の仕組みで制御される場合があります。

Windowsでは「設定」→「アプリ」→「スタートアップ」で起動項目を確認できます。macOSでは「システム設定」→「一般」→「ログイン項目」で、ログイン時に開く項目とバックグラウンドで許可する項目を確認します。クライアントに自動起動の管理機能がある場合、起動項目を手動で重複登録しないでください。2つのインスタンスが同じポートを取り合うことがあります。

  1. 現在の設定を記録する：使用中の設定名、ノードのポリシー、プロキシポート、TUNの有効状態を控えます。
  2. 端末を再起動する：クライアントとコアが実際に起動していることを確認し、ポート競合、権限、設定解析のエラーがないか調べます。
  3. 通信の制御状態を確認する：デスクトップではシステムプロキシ、AndroidではVPN接続とアプリごとの対象範囲を確認します。
  4. アクセスして状況を確認する：直接接続する想定のサイトとプロキシ経由の想定のサイトを開き、それぞれのルール判定と最終的な出力先を確認します。1つのページだけで判断しないでください。
  5. 終了後に設定が戻ることを確認する：プロキシ機能を通常の手順で終了し、基本的なネットワーク接続が使えることを確認します。異常終了後に復旧できるよう、システムプロキシとVPN設定の場所も把握しておきましょう。