Clashの初回インストール後に行う初期設定｜権限・ポート・サブスクリプションのよくある問題

初期設定の手順：まずコアを起動し、接続を確認する

初回起動後は、まずクライアントでコアが起動することを確認します。次にサブスクリプションを読み込み、設定を有効にしてノードを選び、最後にシステムプロキシまたはTUNを有効にします。ポート、DNS、ルーティングルールを一度に変更せず、項目ごとに確認すれば、どの設定が影響したか判断できます。

ClashのGUIクライアントは画面表示やシステム連携を担い、コアは設定の解析と接続の転送を担います。mihomoコアを使う場合、画面が正常に開いても設定が読み込まれたとは限りません。設定が一覧に表示されても、現在の実行設定として有効とは限りません。まず実行状態と起動ログを確認してから、ネットワークをテストしてください。

1. インストールパッケージのアーキテクチャを確認します。デバイスに合わせてx64またはARM64を選びます。macOSもプロセッサのアーキテクチャを確認してください。不一致の場合、起動できなかったり、システムの変換機能に依存したりすることがあります。
2. 初期状態のネットワークを保ちます。複数のプログラムがシステムプロキシ、仮想ネットワークアダプター、デフォルトルートを同時に変更しないよう、ほかのプロキシクライアントやVPNを終了してから始めてください。
3. コアの実行状態を確認します。クライアントのログで起動結果を確認し、設定の解析エラー、ポートのバインド失敗、権限エラーを優先して対処してください。
4. 設定を読み込んで有効にします。サブスクリプションを更新したら、使用する設定を明示的に選択し、プロキシグループにノードが表示されるか確認してください。
5. 通信を経由させる方法を一つずつ試します。デスクトップではまずシステムプロキシを使います。プロキシ設定に従わないアプリも経由させる必要がある場合に、TUNを確認してください。

Windowsでの初回起動：セキュリティ警告・サービス権限・ファイアウォールを確認

インストール時の警告は配布元を確認してから対応

システムのセキュリティ警告が表示されたら、インストールパッケージの配布元、ダウンロードページの説明、ファイルのプロパティを確認してください。配布元を確認できない場合は、インストールを中止します。組織の管理下にあるデバイスでは、インストールポリシーや管理者権限についてデバイス管理者に相談してください。クライアントを起動するために、システム全体の保護を無効にしないでください。

Windows 11では、「設定」→「システム」→「バージョン情報」でシステムの種類を確認できます。インストール後、画面は開くのにコアがすぐ終了する場合は、まずログを確認してください。GUIアプリを再インストールしても、YAMLの書式エラーやポートの使用中は解消しません。

サービスモードとシステムプロキシは別の機能

• システムプロキシ：ローカルのプロキシアドレスをシステムに登録します。通常のデスクトップ利用で、クライアントを常に管理者として実行する必要はありません。
• サービスモード：バックグラウンドサービスが、より高い権限を必要とする処理を実行します。対象となる処理はクライアントの実装によって異なります。サービスのインストールや修復時に、管理者の許可が求められることがあります。
• TUNモード：仮想ネットワークインターフェースを作成してルートを設定するため、サービスのサポートや管理者権限が必要になる場合があります。サービスがインストール済みでも、TUNが正常に起動したとは限りません。

TUNを有効にしたときにログで権限不足が示されたら、まずクライアントに表示されているサービスの状態を確認します。仮想インターフェースやルートの作成失敗が示された場合は、ほかのVPNがネットワークを制御していないか確認してください。最初のエラーを見落としたまま、スイッチを何度も切り替えないでください。

ファイアウォールの許可範囲は用途に合わせる

このPCだけで使う場合は、プロキシの待ち受け先をループバックアドレスにすれば十分です。LANからの受信接続を許可する必要はありません。スマートフォンからPCのプロキシに接続する場合に限り、「Windows セキュリティ」→「ファイアウォールとネットワーク保護」で、アプリの許可または受信規則を確認し、信頼できるネットワークに限定してください。ファイアウォールの許可とクライアントのallow-lanは別々の条件です。片方を有効にしても、もう片方の代わりにはなりません。

macOS・Android：権限を許可した後に通信の状態も確認

macOS：インストールを済ませてから補助サービスを設定

インストール時にアプリを「アプリケーション」フォルダへドラッグするよう案内された場合は、先にその操作を済ませてから起動してください。システムによって起動がブロックされた場合は、配布元を確認したうえで、「システム設定」→「プライバシーとセキュリティ」に表示された案内を確認します。配布元を確認できたアプリだけに許可を与え、セキュリティ設定全体を緩めないでください。表示内容はOSのバージョンやアプリの署名状態によって異なります。

クライアントがヘルパーツールやサービスのインストールを求めた場合は、起動したばかりのクライアントからの要求であることを確認してから、管理者の認証情報を入力してください。この許可は通常、システムのネットワーク設定やTUNのサポートに使われます。サブスクリプションサービスへのログインとは別の手続きであり、サブスクリプションURLの利用にデバイス管理者のパスワードが求められることはありません。

システムプロキシを調べるには、「システム設定」→「ネットワーク」→現在のネットワーク接続→「詳細」→「プロキシ」で設定を確認します。HTTPプロキシとHTTPSプロキシには、実際に待ち受けているアドレスとポートを指定してください。以前の自動プロキシ設定も有効になっている場合は、職場のネットワークで必要な設定かを確認してから変更を判断します。

Android：VPNの許可とバックグラウンド動作を個別に確認

Androidのクライアントは、通常、システムのVPNインターフェースを使って通信を経由させます。初回接続時にシステムのVPN接続要求が表示されたら、アプリ名を確認してから許可してください。一般的な利用ではroot化は不要です。デスクトップ版の「システムプロキシを設定」という手順を、Androidアプリにそのまま当てはめることはできません。

1. ほかのVPNが動作中の場合は、先に停止します。一般的な個人利用の設定では、同時に有効にできるVPNサービスは一つです。
2. クライアントを起動してシステムのVPN接続要求を許可し、システムとクライアントの接続状態が一致しているか確認してください。
3. 接続してもすぐ切断される場合は、システム設定で「VPN」を検索し、ほかのアプリの「常時接続VPN」や「VPN未接続時の接続をブロック」が有効になっていないか確認してください。
4. 画面ロック後にだけ通信が途切れる場合は、アプリのバッテリー設定とバックグラウンド動作を確認します。メニューは機種によって異なるため、すべてのアプリを無制限に設定する必要はありません。

ブラウザーでは接続できるのに特定のアプリだけ使えない場合は、アプリごとのプロキシ対象を確認してください。そのアプリが除外されているか、「選択したアプリのみプロキシ」モードの対象外になっている可能性があります。この段階でサブスクリプションの無効化を疑う必要はありません。

ポート競合：使用中のプロセスを確認してからmixed-portを変更

ログにaddress already in useやポートのバインド失敗が表示されたら、まずポートを使用しているプロセスを特定します。終了していない旧クライアント、動作中のバックグラウンドサービス、同じポートを使う別のツールなどが原因として考えられます。ウィンドウを閉じても、バックグラウンドプロセスが終了したとは限りません。

以下では7890を例に確認します。これはすべてのクライアントで共通のデフォルト値ではありません。現在の設定または実行中の設定で実際のポートを確認し、コマンド内の数字を置き換えてください。

ローカルPCのTCP待ち受けポートを確認

Windowsでは、コマンドプロンプトで次を実行します。

netstat -ano -p tcp | findstr LISTENING | findstr ":7890"

結果に表示されたローカルアドレスとポートを確認し、最後の列にあるPIDを控えてから、タスクマネージャーの「詳細」タブでプロセスを特定します。身元の分からないシステムプロセスを終了しないでください。

macOSでは、ターミナルで次を実行します。

lsof -nP -iTCP:7890 -sTCP:LISTEN

使用中のプロセスが古いプロキシアプリだと確認できたら、まずそのアプリを通常の手順で終了してください。ポートを変更する場合はmixed-portを7897にできますが、新しいポートが使用されていないことも確認します。プロキシを手動設定しているターミナル、ブラウザー、ほかのデバイスでは設定を変更してください。クライアントが管理するシステムプロキシは、再度有効にしてから設定を確認します。

mixed-portとコントローラーポートを混同しない

サブスクリプションの読み込み失敗：取得・解析・有効化を分けて確認

「読み込み失敗」は、クライアントがサブスクリプションの内容を取得できない、コアが内容を解析できない、読み込み後に設定が有効になっていない、という3つの段階で起こり得ます。エラーがどの段階に当たるかを確認してから、次の手順を決めてください。同じURLを何度も貼り付けても、新しい手掛かりは得られません。

第1段階：サブスクリプションURLから内容を取得できるか

• コピーした内容を確認します。サブスクリプションのURL全体だけをコピーし、前後の空白や改行を取り除いてください。説明文、アカウントページのURL、個別ノードのリンクを、設定一式を含むサブスクリプションURLとして使わないでください。
• レスポンスの状態を確認します。401は認証の問題がよくある原因です。403はリクエストが拒否された状態で、サービス側の案内も確認する必要があります。404ではURLを確認してください。429が返った場合は、短時間での再試行をやめて待ちます。
• システム時刻を確認します。日付が大きくずれていると、HTTPS証明書の検証に失敗することがあります。証明書の検証を無効にして回避せず、まずシステム時刻を同期してください。
• 取得経路を確認します。サブスクリプション更新がプロキシ経由に設定されている一方で、まだ利用可能な設定がない場合、起動時に依存関係が生じることがあります。クライアントに更新時の直接接続オプションがあるか確認し、現在のネットワークからアクセスできる場合にテストしてください。

ブラウザーでURLを開けても、そのブラウザーの接続経路が利用できることしか分かりません。クライアントのプロキシ設定、リクエスト情報、ネットワーク環境は異なる場合があります。ログインページやエラーページが返された場合は、リクエストが成功と表示されても、コアで使えるYAML設定ではありません。

第2段階：レスポンス形式がコアに対応しているか

単一ノードのURI、ノード一覧、完全なClash設定は、それぞれ別の形式です。サブスクリプションサービスが現在のクライアントに対応した形式を提供しているか確認してください。ノードがmihomo対応の拡張プロトコルを使う場合は、画面上の名称だけで判断せず、実際に互換性のあるコアが動作していることも確認します。

YAMLの解析エラーが出たら、ログに記録された行番号とエラーの種類を控えてください。インデントの不統一、フィールドの型の誤り、未対応プロトコルなどが読み込み失敗の原因になります。すべてのフィールドをむやみに削除せず、設定をバックアップしてからプロトコルリファレンスのコアに関する説明で対応範囲を確認してください。

第3段階：読み込み後に実行設定として有効になっているか

サブスクリプションの更新に成功したら、現在の設定を示すマーク、プロキシグループの内容、直近の読み込みログを確認します。ノードを一つ手動で選び、ルールが参照するプロキシグループが実際に存在することを確認してから、目的のWebサイトにアクセスしてください。ログにプロキシグループが見つからないと表示された場合は、DNSを変更するのではなく、先にグループ名またはルールの参照先を修正します。

初回接続の確認：3段階に分けて問題を特定

デスクトップでは、まずローカルプロキシの接続先、次にシステムプロキシ、最後にルールを確認します。AndroidではVPNの状態とアプリごとの対象範囲から確認してください。速度テストで分かるのは特定のテスト先への応答状況であり、目的のアプリで実際に接続できるかの確認にはなりません。

第1段階：ローカルプロキシの接続先を直接テスト

デスクトップでは、次のコマンドでHTTPプロキシを明示してテストできます。ポートは7890を例としており、テストURLは、アクセスが必要で正常に応答することを確認済みのアドレスに置き換えてください。Windowsではcurl.exe、macOSではcurlを使用できます。

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

接続が拒否された場合は、まずコアの待ち受け状態とポートを確認します。接続は確立するのにタイムアウトする場合は、ノード、接続先サイト、ルールを確認してください。このテストはシステムプロキシのスイッチに依存しませんが、コアの現在のモードやルールによる影響は受けます。一度成功しても、すべてのアプリや接続先にアクセスできるとは限りません。

第2段階：アプリがシステムプロキシを使っているか確認

プロキシを明示した接続は成功するのにブラウザーで失敗する場合は、システムプロキシのアドレスが127.0.0.1か、ポートが一致しているか、ブラウザー独自のプロキシ設定が有効になっていないかを確認してください。コマンドラインツールがシステムプロキシを参照するとは限りません。必要に応じて環境変数を個別に設定するか、明確な必要性がある場合にTUNを使用してください。

第3段階：接続先に適用されたルールを確認

クライアントの接続一覧で接続先のドメインを探し、直結、プロキシグループ、拒否のどのルールに一致したかを確認してください。接続履歴がまったくない場合は、通信がクライアントに届いているかを先に調べます。履歴はあるのに誤ったポリシーが選ばれている場合は、ルールの順序やプロキシグループの選択を確認してください。ログにドメイン解決の失敗が示されている場合に限ってDNSを調べ、あらゆる接続問題をDNSのせいにしないでください。

TUNが必要な場合は、個別に有効にして同じテストを繰り返します。TUNで経由される通信の範囲は、ルート、除外項目、アプリごとの設定、プラットフォームの制限にも左右されます。有効にすればすべての接続が必ず対象になるわけではありません。問題が起きたら、変更を重ねず、まずTUNを無効にして確認済みの状態に戻してください。

終了と復旧：元に戻せるよう設定を記録

初期設定が終わったら、クライアントとコアのバージョン、プロキシポート、使用中の設定名、システムプロキシとTUNの有効・無効の状態を記録してください。サポートを依頼する際は、OSのバージョン、最初に発生した関連エラー、再現手順も共有すると、「インターネットにつながらない」という説明だけより原因を特定しやすくなります。

• 終了後にネットワークにつながらない：システムプロキシが、停止したローカルポートを参照したままになっていないか確認してください。クライアントが設定したプロキシの場合は、クライアントを再起動してシステムプロキシを無効にしてから、通常の手順で終了します。
• TUNを無効にしても問題が続く：ほかのVPNが動作していないか確認し、システムのネットワーク状態を調べてください。必要であればログを保存してから、クライアントまたはデバイスを再起動します。正体の分からないネットワークインターフェースを削除しないでください。
• サブスクリプションの更新後に使えなくなった：更新前後のノード、グループ名、ルールの参照先を比較し、ローカルの上書き設定が引き続き適用できるか確認してください。
• DNSの変更を続ける前に：現在動作している設定を保存し、入門ガイドのFake-IPの説明を読んでから、一度に一項目だけ変更してください。

最後に次の4点を確認します。コアが正常に動作していること、正しい設定が有効になっていること、通信が想定した接続先から入っていること、接続先への通信に想定したルールが適用されていること。この4点を確認してから、OS起動時の自動起動やLAN共有などを設定すれば、その後の管理も容易になります。