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

初期設定では、動作を確認できる接続経路を作ります。アプリがリクエストを送信し、ローカルのプロキシポートが受け付け、コアがルールに従って直接接続またはプロキシ接続を選び、接続先のサービスに到達します。インストーラーが起動しただけでは、GUIが立ち上がったことしか確認できません。サブスクリプションの取得、コアの起動、アプリからの接続は、それぞれ別に確認する必要があります。

対応するアーキテクチャを選び、コアの対応状況を確認

  • Windows：「設定」→「システム」→「バージョン情報」でシステムの種類を確認します。一般的なIntel・AMD搭載PCにはx64版を使用します。Windows on ARM搭載デバイスでは、クライアントが提供するARM64版を優先してください。
  • macOS：Appleメニューから「このMacについて」を開き、チップを確認します。Appleシリコン搭載モデルにはarm64版、Intel搭載モデルにはx64版を使用します。Universal版がある場合は、リリースノートに従って選んでください。
  • Linux：uname -mを実行します。出力がx86_64なら通常はamd64/x64、aarch64ならarm64に対応します。パッケージ形式とディストリビューションの対応状況も確認してください。
  • Android：クライアントのリリース情報を確認し、対応するアーキテクチャのAPKを選びます。アプリで有効にするVPNサービスは端末の通信を取り込む機能で、デスクトップOSの手動HTTPプロキシとは異なります。
  • iOS：設定形式に対応したクライアントを使って接続します。デスクトップ版ClashのYAMLが、すべてのiOSクライアントでそのまま読み込めるとは限りません。インポート前にサブスクリプションの形式を確認してください。

ClashのGUIクライアントはサブスクリプションの管理や接続の切り替え、状態表示を担当し、ClashまたはClash Meta（mihomo）のコアは設定の解析と通信の転送を担当します。新しいプロトコルや設定項目が使えるかどうかは、実際に動作しているコアとそのバージョンによって異なります。インポート時に未対応のプロキシタイプが表示されたら、システムプロキシを何度も切り替えるのではなく、まずクライアントの「バージョン情報」やコア情報を確認し、設定の要件と照らし合わせてください。

サブスクリプションのインポート：取得後に設定を有効化

サブスクリプションURLには通常、アクセス用の認証情報が含まれます。URLから完全なYAMLが返る場合もあれば、プロキシノードの一覧だけが返る場合もあります。完全な設定には一般にproxiesまたはproxy-providers、proxy-groups、rulesが含まれます。ノード一覧のみの場合は、クライアントのテンプレートでプロキシグループとルールを補う必要があります。どちらの形式も、すべてのインポート方法で使えるわけではありません。

  1. クライアントの「設定」または「サブスクリプション」を開き、URLからインポートする項目を選んで、サービス提供元から案内されたURLを貼り付けます。画面の名称はクライアントによって異なるため、使用中のバージョンの設定管理画面を確認してください。
  2. ダウンロードまたは更新を実行し、最終更新日時とエラー情報を確認します。HTTP 401や403が表示された場合は、URLの認証情報、アカウントの状態、サービス提供元のアクセス制限を確認してください。404の場合は、URLの有効期限が切れていないか、コピー漏れがないかを確認します。
  3. インポートした設定を選び、有効になっていることを確認してからプロキシグループ画面を開きます。ダウンロードが完了しても、コアがその設定に切り替わったとは限りません。
  4. 実際のルールから参照されている選択グループで、使用可能なノードを選びます。自動測定グループは自動で選択する場合がありますが、手動選択グループでは明示的に選ぶ必要があります。DIRECTのままになっていないか確認してください。
  5. コアのログを確認し、設定の解析エラーがないか調べます。YAMLのインデントにはスペースを使い、タブを混在させないでください。エディターでファイルを開けるだけでは、設定が有効とは限りません。

サブスクリプションの更新とローカル編集は分けて管理

取得したサブスクリプションファイルを直接編集すると、次回の更新で変更が上書きされる場合があります。ポートやDNS、ルールを固定・調整する場合は、クライアントが対応する上書き、マージ、拡張設定機能を優先してください。変更した項目と設定場所を記録し、更新後に最終的な設定を確認します。エラーを共有する際は、サブスクリプションURL、ノードのパスワード、コントロールインターフェースのキーを隠し、診断に必要な項目とエラー行だけを残してください。

システムプロキシと混合ポート：アドレスとポートを一致させる

デスクトップOSのシステムプロキシは、その設定を参照するアプリをローカルのプロキシポートへ接続させる機能です。すべてのアプリの通信が自動的にClashを経由するわけではありません。初回の確認ではシステムプロキシを使い、ブラウザーのリクエストがコアに届くことを確かめてから、ゲームやコマンドラインなど、システムプロキシ設定に従わないプログラムを設定します。

ローカルポートの例：127.0.0.1:7890

以下は基本項目を確認するための例であり、ノードに接続できる完全な設定ではありません。mixed-portはHTTPプロキシとSOCKS5プロキシの両方の接続を受け付けます。7890は例の値です。実際の値は、クライアントで有効になっている設定を確認してください。クライアントによっては、GUIの設定がファイル内のポート設定より優先されます。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
確認項目例確認方法
プロキシサーバーのアドレス127.0.0.1ローカルアプリはローカルのコアに接続します。リモートノードのアドレスは入力しません。
HTTPプロキシポート7890mixed-port、または個別に設定したportと一致していること
SOCKS5プロキシポート7890mixed-port使用時は共用できます。独立したsocks-portを使う場合は別途確認してください。
コントロールインターフェース127.0.0.1:9090よくある設定例です。コアの管理用であり、通信を受け付けるプロキシポートではありません。

各プラットフォームでシステム設定を確認する場所

  • Windows 11：「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」を開きます。クライアントでシステムプロキシを管理している場合は、クライアント側のスイッチを有効にして、ここに正しいローカルアドレスとポートが設定されているか確認してください。出所のわからないスクリプト設定を併用しないでください。
  • macOS：「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」を開きます。Webプロキシ、安全なWebプロキシ、SOCKSプロキシのアドレスとポートを確認してください。クライアントの終了後に設定が元に戻っているかも確認します。
  • Linux：デスクトップ環境のネットワークプロキシ設定と、端末の環境変数は別々に適用されます。デスクトップのプロキシを設定しても、コマンドラインツールでは明示的な引数やHTTP_PROXY、HTTPS_PROXYなどの環境変数が必要な場合があります。詳しくは各ツールのドキュメントを確認してください。

接続の確認：ポート・ルール・ノードの問題を切り分ける

確認時は一度に1つの条件だけ変更します。まずポートに接続できるかを確認し、次にルールの適用状況、最後にリモートノードを調べます。クライアントのノード遅延テストで測定されるのは、指定されたテスト先へのリクエスト時間です。ダウンロード速度ではなく、すべてのWebサイトへの接続を保証するものでもありません。

明示的なプロキシ接続でシステム設定の影響を切り分ける

Windows PowerShellではcurl.exeを使うと、一部の環境でcurlが別のコマンドとして解釈されるのを避けられます。macOSとLinuxではcurlを使えます。以下のコマンドは例のポート経由でテスト用Webページに接続し、待ち時間を最大15秒に設定します。実行前に実際の待ち受けポートに置き換えてください。

# Windows
curl.exe --proxy http://127.0.0.1:7890 --max-time 15 -I https://example.com

# macOS / Linux
curl --proxy http://127.0.0.1:7890 --max-time 15 -I https://example.com
  • ローカルポートに接続できない：コアが起動しているか、ポートが一致しているか、ログに待ち受け失敗が記録されていないかを確認してください。リクエストがまだプロキシに届いていないため、この段階でリモートノードを変更しても通常は解決しません。
  • HTTPレスポンスヘッダーを受信した：そのリクエストでプロキシの入口から接続先まで通信できたことを示します。ただし、ルールモードでは接続先が直接接続に振り分けられている場合があります。接続ログで出口を確認してください。
  • リクエストがタイムアウトした：接続ログに対象ドメインが記録されているか、どのルールに一致したか、どのノードが選ばれたかを確認します。ログがない場合は、まずアプリからの接続を調べてください。記録がある場合は、DNS、ノードへの接続、接続先サービスを確認します。

日常利用はルールモードから始める

mode: ruleは設定内のルールを上から順に照合し、通常は末尾のMATCHがその他の接続を処理します。グローバルモードは、特定の接続先が誤ったポリシーに振り分けられていないか短時間で調べるのに適していますが、ノードの停止やサブスクリプション形式の誤りは解決しません。確認後はルールモードに戻し、接続ログでルール名、ポリシーグループ、最終的に選ばれたノードを確認してください。Webページが開けたかどうかだけでは、プロキシ経由と判断できません。

TUNモード：権限・ルート・DNSの確認手順

TUNモードは仮想ネットワークインターフェースとルーティングを使って通信を取り込み、システムプロキシを参照しないアプリに適しています。システムプロキシとは異なる接続方法であり、すべての通信がリモートノードを経由するわけではありません。通信がコアに入った後も、ルールに応じてDIRECT、プロキシグループ、その他の動作が選択されます。

通常のプロキシ接続を確認してからTUNを有効にする

  1. 明示的なプロキシ接続とノードへの接続が正常に動作することを確認します。通常のプロキシ経路がまだ使えない場合は、サブスクリプション、ポート、ノードを先に修正してください。TUNを追加して問題の切り分けを複雑にしないようにします。
  2. クライアントにサービスモードや権限のインストール項目があるか確認してください。Windowsクライアントではインストール済みのバックグラウンドサービスや管理者権限が必要な場合があります。macOSでは補助コンポーネントの許可、Linuxでは権限の昇格やネットワーク管理機能が必要になることがあります。
  3. TUNを有効にしたら、仮想インターフェース、ルート、コアのログを確認します。権限エラーが発生した場合は、クライアントのインストール手順に従ってサービスを許可してください。関係のないプログラムを常に高い権限で実行するのは避けましょう。
  4. 他のVPNによる通信制御を一時的に無効にし、Webページ、対象アプリ、LAN内のリソースにアクセスできるか確認します。複数のVPNが同時にデフォルトルートやDNSを変更すると、リクエストが誤ったインターフェースに流れることがあります。

mihomoの設定では、tun.enableがTUNの有効・無効を制御し、auto-routeは自動ルーティングに関係します。dns-hijackは指定したDNS通信の取り込みに使用できます。対応状況はプラットフォーム、コアのバージョン、クライアントによる設定の上書きに左右されます。TUNの設定を貼り付けただけで、ルート、DNS、権限がすべて整ったと判断しないでください。

DNSの問題とルールによる振り分けは分けて確認

ドメインにアクセスできない一方で、他の接続には応答がある場合は、まずDNSログと現在の名前解決設定を確認します。ブラウザーのセキュアDNS、アプリ内蔵のリゾルバー、システムDNSは、それぞれ異なる経路を使うことがあります。通常のDNSリクエストを取り込んでも、すべての暗号化DNSが取り込まれるとは限りません。fake-ipモードでは、アプリに返されるアドレスが仮想アドレスプール由来の場合があります。これはコアがドメイン名を対応付ける仕組みのため、そのアドレスを安易にhostsファイルへ追加しないでください。

プリンター、NAS、社内ネットワークへのアクセスに問題がある場合は、すべてをグローバルプロキシに切り替えるのではなく、LANへの直接接続ルール、ルートの除外、社内DNSを確認します。AndroidのVPN許可ダイアログは、アプリがVPNインターフェースを作成することを許可するものです。通常、同じユーザー環境で有効にできるVPNサービスは1つだけです。他のVPNアプリが置き換えられたり、切断されたりすることがあります。

初回起動時によくあるエラー：発生箇所ごとに対処

システムのセキュリティ機能にインストールをブロックされた

WindowsでSmartScreenやセキュリティソフトの警告が表示されたら、まずダウンロード元、発行元情報、インストーラーが現在のシステムに対応しているかを確認します。会社の管理端末ではアプリの実行ポリシーが設定されている場合があるため、管理者に許可を確認してください。macOSで開発元を検証できないという警告が表示された場合は、入手元を確認したうえで「システム設定」→「プライバシーとセキュリティ」に、そのアプリを許可する項目があるか確認できます。アプリがコンピュータに損害を与える、またはファイルが破損しているという警告が出た場合は実行を中止し、入手元とリリース情報を再確認してください。すべての警告を同じ問題として扱わないようにしましょう。

address already in use：ローカルポートが使用中

このエラーは、コアがアドレスまたはポートをバインドできないことを示します。まず、クライアントが二重に起動していないか確認して終了し、ポートを使用しているプロセスを調べます。Windowsでは次のコマンドで7890の待ち受け状況を確認し、タスクマネージャーの「詳細」タブでPIDとプロセスを照合できます。ポートが使用中という理由だけで、正体のわからないシステムプロセスを終了しないでください。

netstat -ano | findstr ":7890"

macOSではlsof -nP -iTCP:7890 -sTCP:LISTEN、Linuxではss -lntpを使って待ち受け情報を確認できます。別のポートに変更する場合は、システムプロキシも合わせて更新してください。コントロールインターフェースのポート競合と、通信の入口となるポートの競合は分けて対処する必要があります。

証明書エラー：日時・接続先ドメイン・信頼チェーンを確認

通常のHTTP CONNECTやSOCKS5による転送では、ブラウザーにルート証明書をインストールする必要はありません。「証明書の有効期限が切れています」「証明書名が一致しません」などのエラーやTLSハンドシェイクエラーが発生した場合は、まずシステムの日付とタイムゾーン、アクセス先のドメイン、証明書の発行者を確認します。接続先がWeb認証を必要とするネットワークでないかも確認してください。社内ネットワークで管理されたTLS検査が行われている場合は、組織の証明書導入手順に従ってください。

クライアント終了後もインターネットに接続できない

まずシステムプロキシを無効にし、手動プロキシのアドレスが解除されていることを確認します。続いてTUNのルート、VPNサービス、他のクライアントによる通信制御が残っていないか調べてください。通常、クライアントは終了時に関連設定を元に戻しますが、異常終了後は手動で戻す必要がある場合があります。リモート操作中にデフォルトルートを変更する場合は、管理セッションまで切断されないよう、予備の接続手段を用意してください。

初期設定の確認リスト

接続が正常に動作することを確認してから、OS起動時の自動起動やサブスクリプションの自動更新など、日常的に使う機能を有効にします。必要な設定を記録しておくと、次回の更新やネットワーク変更時に、設定変更とネットワーク障害をすばやく切り分けられます。

  • サブスクリプションの最終更新が成功し、使用する設定が選択されている。コアの起動を妨げる設定解析エラーがログにない。
  • クライアント名、コアのバージョン、実際のmixed-portを記録し、システムプロキシのアドレスとポートが一致している。
  • 明示的なプロキシリクエストに応答があり、接続ログから適用ルール、ポリシーグループ、最終的な接続先を確認できる。
  • TUNが必要なアプリを個別にテストし、LAN内のデバイスやサービスにも想定どおりアクセスできる。
  • クライアントを終了すると通常のインターネット接続に戻り、再起動後もプロキシの有効状態とサービスの状態が想定どおりになっている。
  • サブスクリプションの更新後に上書き設定を確認し、認証情報を安全にバックアップします。サブスクリプションURL全体を公開の質問ページに貼り付けないでください。

以降のトラブルシューティングも、「設定が有効か→コアが待ち受けているか→アプリが接続しているか→ルールに一致しているか→ノードに接続できるか」の順に確認します。用語の意味は用語解説、ルールとコアの設定については技術リファレンスをご覧ください。