Clashの初期設定ガイド｜システムプロキシ・mixed-port・自動起動の注意点

初回起動時に確認する設定・コア・通信経路

Clashクライアントのウィンドウが開いても、プロキシ経由の通信が確立したとは限りません。通信には少なくとも、クライアントによる設定の読み込み、コアによるローカルポートの待ち受け、アプリからコアへの通信引き渡し、ルールによる有効な出口の選択が必要です。初期設定ではこの順に確認しましょう。システムプロキシやTUN、複数のネットワークツールを同時に有効にして、ページを更新しながら原因を探るのは避けてください。

この記事では、デスクトップ向けのClash系クライアントと、Clash Meta（mihomo）コアを使うクライアントを中心に、AndroidとiOSの違いも解説します。メニュー名はクライアントによって異なります。また、システムプロキシ、ルールモード、仮想ネットワークインターフェースはそれぞれ別の機能です。デスクトップ版の設定場所をそのままスマートフォン版に当てはめないでください。

1. 設定を読み込む：クライアントのサブスクリプションまたは設定ページから、サービス提供元の互換性のある設定をインポートします。更新が完了したら、使用する設定として選択してください。リストにファイルが表示されていても、適用済みとは限りません。
2. コアのログを確認する：YAMLの解析エラー、存在しないプロキシグループの参照、ポートのバインド失敗がないか確認します。エラーが続いている場合は、まず設定を修正しましょう。すぐにシステムのネットワーク設定を変更する必要はありません。
3. ルールモードを選ぶ：初めて使う場合は、設定に含まれるルールモードをそのまま使用するのがおすすめです。グローバルモードは通信をグローバルポリシーに渡すだけで、ノードのパラメーター誤りを修正するものではありません。
4. プロキシグループを確認する：グループを手動で選ぶ場合は、利用可能なノードを選択してください。DIRECTを選ぶと、該当する通信はプロキシを経由せず直接接続されます。遅延テストに成功しても、そのテスト先に接続できたことを示すだけで、すべてのWebサイトにアクセスできるとは限りません。

システムプロキシ：ローカルポートを使うアプリを決める設定

デスクトップクライアントの「システムプロキシ」は通常、OSのプロキシ設定を変更し、その設定に従うアプリの接続先を127.0.0.1:7890などのローカルアドレスに向けます。すべての通信を取り込む機能ではありません。一部のゲーム、コマンドラインツール、独自のプロキシ設定を使うブラウザー、一部のUDP通信は、この設定に自動では従いません。

Windows：トレイアイコンだけでなくプロキシの設定を確認

Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「手動プロキシ セットアップ」のアドレスとポートがクライアントの設定と一致しているか確認します。システムプロキシの設定方法はクライアントによって異なる場合があるため、クライアントの説明と現在の設定を確認してください。一般的なデスクトップアプリが使うシステムプロキシとWinHTTPの設定は別物です。ブラウザーの問題を解決するために、安易にWinHTTPを変更しないでください。

macOS：現在使っているネットワークサービスの設定を確認

macOSでは「システム設定」→「ネットワーク」→使用中のネットワークサービス→「詳細」→「プロキシ」の順に開きます。Webプロキシ、安全なWebプロキシ、SOCKSプロキシが古いポートを指していないか確認してください。Wi-Fiと有線ネットワークで設定が異なる場合があります。ネットワークを切り替えて問題が起きた場合は、以前のWi-Fiではなく、現在のネットワークサービスを確認しましょう。

Linux：デスクトップ環境とターミナルを個別に確認

Linuxのデスクトッププロキシ設定は、デスクトップ環境やアプリの実装によって異なります。ターミナルのプログラムでは、プロキシの引数や環境変数を明示する必要があるのが一般的です。ブラウザーがプロキシ経由で通信できても、ターミナルも接続されているとは限りません。以下の2つのコマンドで、同じmixed-portを使ってHTTPプロキシとSOCKS5プロキシをそれぞれテストできます。

curl -I --proxy http://127.0.0.1:7890 https://example.com
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

socks5hは、接続先のドメイン名の名前解決をプロキシ側で行う指定です。接続先サイトからHTTPレスポンスが返れば、少なくとも今回のリクエストは接続と応答まで完了しています。タイムアウト、プロキシ認証エラー、TLSエラーはそれぞれ分けて確認してください。このテストで、すべてのアプリがプロキシを使っていることや、ローカルのDNS設定が正しいことまでは確認できません。

mixed-port：7890はよく使われるポートで、固定値ではない

mixed-portは、HTTPプロキシとSOCKSプロキシで同じ待ち受けポートを使う設定です。これはローカルの接続口であり、リモートノードのポートでも、コア制御用APIのポートでもありません。よく使われる設定値は7890ですが、クライアントや設定によって異なります。現在適用されている設定と実行ログを確認してください。

ポートを使用中のプロセスを確認する

ログにaddress already in useやバインド失敗が記録されている場合は、まずポートを待ち受けているプロセスを確認します。別のプロキシクライアント、終了しきれていないコアのプロセス、開発用サービスなどが同じポートを使っている可能性があります。以下のコマンドにある7890は、エラーが発生したポートに置き換えてください。

# Windows：コマンドプロンプトで実行。結果の最後の列がPID
netstat -ano | findstr :7890

# macOS：TCPの待ち受けプロセスを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：TCPの待ち受けとプロセス情報を確認
ss -ltnp 'sport = :7890'

Windowsでは、リモート側のポート番号が同じ接続も表示される場合があります。ローカルアドレスの列とLISTENINGの状態をあわせて確認してください。Linuxでプロセス名が表示されない場合は、追加の権限が必要なことがあります。プロセスを特定したら、まず通常の方法で競合プログラムを終了してください。PIDを見ただけで強制終了しないでください。

ポートを17890に変更したら、アプリ側の設定も更新する

競合を避ける必要がある場合は、mixed-portを17890に変更できます。以下は確認が必要な項目だけを示したもので、ノードやルールを含む完全な設定ではありません。

mixed-port: 17890
allow-lan: false
mode: rule

変更後は設定を再読み込みし、新しいポートで待ち受けていることを確認してから、クライアントのシステムプロキシをいったんオフにして再度オンにします。プロキシを手動設定したブラウザー、ターミナル、ダウンロードツールも同じ値に変更してください。GUIクライアントによっては、サブスクリプションの値より独自のポート設定が優先されます。その場合はクライアントの設定画面、または対応するオーバーライド設定を変更してください。そうしないと、サブスクリプションの更新後に古い値へ戻ることがあります。

TUNと権限の確認：まず通常のプロキシ通信を確立する

TUNモードは仮想ネットワークインターフェースとルーティングを使って通信を取り込みます。システムプロキシに従わないアプリにも適していますが、「高機能だから必ず有効にする」ものではありません。デスクトップ版を初めて設定するときは、まずプロキシを明示したリクエストでノードとローカルポートの動作を確認し、必要に応じてTUNを有効にしましょう。ノードの問題とルーティングの問題を切り分けやすくなります。

• Windows：仮想ネットワークアダプターの作成やルートの追加には、通常、管理者権限が必要です。クライアントによってはサービスモードで処理します。サービスのインストールに失敗した場合は、まずログを確認してください。すべてのプログラムを常に管理者として実行するのは避けましょう。
• macOS：システムプロキシの変更、ヘルパーサービス、ネットワーク拡張では、それぞれ異なる許可を求められる場合があります。提供元が明確で、実行中の操作に必要な許可だけを与えてください。起動できない場合は、クライアントが提供するヘルパーサービスの状態を確認します。
• Linux：TUNデバイスの作成やルートの変更には、ネットワーク管理権限が必要です。実現方法はサービスやケイパビリティの設定など、環境によって異なります。使用するクライアントの説明に従ってください。デスクトッププロキシで接続できたからといって、TUNに必要な権限もそろっているとは限りません。
• Android：一般的なクライアントはシステムのVPNインターフェースを使って通信を取り込むため、VPN接続の許可が必要です。デスクトップのHTTPシステムプロキシとは異なる仕組みです。別のVPNアプリが同じシステムの接続枠を使用している場合もあります。
• iOS：必要な設定形式に対応したクライアントを使い、VPN構成の許可を確認してください。デスクトップ版ClashのインストーラーはiOSでは使えません。設定形式や機能の対応状況も、使用するクライアントごとに確認しましょう。

TUNを有効にしてからLAN内のデバイス、社内ネットワーク、別のVPNに問題が起きた場合は、まずTUNをオフにして改善するか確認し、その後ルートの除外設定とDNSを見直してください。出どころの不明なDNS設定をそのままコピーするのは避けましょう。社内ドメイン、ルーターのドメイン、一般のインターネットドメインでは、名前解決の経路が異なることがあります。通信の取り込みについて詳しく知りたい場合は、技術リファレンスをご覧ください。

自動起動：クライアントの起動・コアの実行・プロキシの復旧は別々に確認

「自動起動」は通常、ユーザーのログイン後にクライアントを起動する設定です。ログイン前からプロキシサービスが動くとは限らず、起動後に正しい設定が読み込まれることや、システムプロキシが復元されること、TUNが有効になることも保証されません。初回は設定スイッチの表示だけを見るのではなく、クライアントを完全に終了してから再ログインまたは再起動し、一連の動作を確認してください。

1. クライアントの自動起動を有効にする：クライアントの起動設定で該当する項目を有効にし、長期的に使う場所へプログラムを移動したことを確認してください。一時的な展開先、ディスクイメージ、削除予定のインストール先から起動するのは避けましょう。
2. OSのスタートアップ項目を確認する：Windows 11では「設定」→「アプリ」→「スタートアップ」、macOSでは「システム設定」→「一般」→「ログイン項目と機能拡張」を確認します。Linuxでは、使用中のデスクトップ環境の自動起動アプリまたは該当するサービスを確認してください。
3. 起動後の状態を確認する：使用する設定が選択されたままか、プロキシグループの選択が意図した状態に戻っているか、待ち受けポートが正しいかを確認します。システムプロキシやTUNがクライアントの設定どおりに有効になっているかも確認してください。
4. ネットワークが使える状態になってからサブスクリプション更新を確認する：ログイン直後は、Wi-Fi、ポータル認証、社内ネットワークの準備が整っていないことがあります。その状態で自動更新に失敗しても、既存の設定が使えないとは限りません。まずネットワークを確認し、更新を手動で再試行してください。

モバイル端末ではバックグラウンド動作とバッテリー設定も確認

Androidでは、バックグラウンドの制限によって画面ロック後にプロキシサービスが終了することがあります。「起動直後は使えるのに、しばらくすると切断される」場合は、クライアントが実行中と表示されているか、システムのVPN接続が維持されているか、バッテリー管理でバックグラウンド動作が制限されていないか確認してください。必要なアプリだけ設定を変更すればよく、端末全体の省電力機能を無効にする必要はありません。iOSの自動接続動作はクライアントとOSの対応状況によって異なるため、デスクトップ版の自動起動と同じ動作を前提にしないでください。

初回インストール時の確認手順：ローカル待ち受けからアプリの接続まで

問題を切り分けるときは順番に範囲を絞り、一度に変更するのは1項目だけにします。「ノードは正常に見えるのにアプリからアクセスできない」ときは、以下の確認表に沿ってチェックしてください。

クライアントの接続ログも確認すると、原因をさらに絞り込めます。対象のリクエストがログにまったくない場合は、アプリからプロキシへの接続経路を確認してください。リクエストが記録されていてDIRECTに一致する場合は、ルールとプロキシグループを確認します。プロキシ出口に送られてからタイムアウトする場合は、ノードへの接続と接続先サイトを確認してください。原因の特定中は一時的にログレベルを上げてもかまいませんが、解決後は通常のレベルに戻し、大量のログが出続けないようにしましょう。