ClashのmacOS設定ガイド

手順1：サブスクリプションまたはローカルYAMLを追加

クライアントを開き、サイドバーから「設定」または「サブスクリプション」の画面に進み、「新規作成」「追加」「インポート」などの項目を探します。リモートサブスクリプションを使う場合は、URLからのインポートを選択し、サービス提供元から入手したURL全体を入力欄に貼り付けて、ダウンロードまたは保存をクリックします。「普段使い」など用途が分かる名前を付けてもかまいません。名前は項目を見分けるためのもので、ノードやルールには影響しません。URLにアクセス用パラメーターが含まれる場合はそのまま残し、ブラウザーに表示されたページのタイトルや説明文をコピーしないでください。

ダウンロードが完了したら、項目に成功のステータスが表示されているか確認し、「使用」「有効化」または該当する選択ボタンをクリックします。追加後に自動で有効になるクライアントもあれば、ファイルが一覧に登録されるだけのものもあります。項目が表示されているかどうかではなく、「プロキシ」画面に設定内のプロキシグループとノードが表示されるかを確認してください。プロキシ画面に切り替え、内容が読み込まれていることを確かめてから次へ進みます。

ファイルを受け取った場合は、同じ画面で「ローカルファイルをインポート」を選び、拡張子が.yamlまたは.ymlの設定ファイルを指定します。ファイルを画像、Webページ、リッチテキスト形式に変換しないでください。また、拡張子だけを変更して別形式のサブスクリプションをYAMLとして読み込ませることもできません。クライアントに設定の検証機能があれば、事前に実行してください。「インポート失敗」だけの表示より、エラーに示されたフィールド名や行番号のほうが原因の特定に役立ちます。

追加に失敗したときの確認手順

まず、現在のネットワークからURLをダウンロードできるか、返された内容が対応する設定ファイルかを確認します。ログイン画面、期限切れの案内、Webエラーページではないことも確かめてください。次に、サービス提供元がClash用とほかの形式用でサブスクリプションのURLを分けていないか確認します。ネットワークからサブスクリプションURLにアクセスできない場合は、提供元からローカル設定を入手して読み込めます。先にシステムプロキシを何度も変更する必要はありません。YAMLのインデントや共通フィールドについては、設定フィールドの解説で項目ごとに確認してください。

サブスクリプションを更新すると、リモートの内容が再取得されます。初回接続の間は追加した設定を変更せず、元のファイルを急いで編集しないでください。後から独自ルールを長期的に使う場合は、クライアントが対応するオーバーライド機能を利用します。詳しくはオーバーライドとマージをご覧ください。次回更新時にローカルの変更が上書きされるのを防ぎやすくなります。

手順2：ルールモードと接続先を選択

設定が有効になっていることを確認したら、クライアントの「プロキシ」画面を開くか、メニューバーのアイコンからモードメニューを表示します。初回は「ルール」モードを選びます。Ruleと表示される場合もあります。このモードでは、設定内のルールに基づいて、各リクエストを直接接続するか、拒否するか、プロキシグループに渡すかが決まります。すべての通信を1つのノードに送る設定ではないため、サイトによって接続先が異なるのは正常です。

続いて主なプロキシグループを展開し、現在の選択項目を確認します。グループ名は設定の作成者が付けたもので、「プロキシ選択」「自動選択」のほか、別の名前が使われる場合もあります。名前だけで用途を判断しないでください。ルールが実際に参照する選択用グループを見つけ、利用可能なノードを指定するか、設定に用意された自動選択グループを選びます。グループ内でDIRECTが選択されている場合、そのリクエストは直接接続されます。該当するルールからプロキシに転送するには、リモートノード、またはノードを含む有効なグループを選択してください。

ノードのテストは接続状況を把握する手がかりになりますが、テストに成功してもすべてのサイトにアクセスできるとは限りません。失敗した場合も、テスト先と現在のネットワークを踏まえて判断が必要です。初回は利用可能と確認済みのノードを手動で選び、接続確認が終わるまで選択を変えないようにします。DNSの変更、ルール順の入れ替え、プロキシグループの種類の変更を同時に行うと、問題の原因を特定しにくくなるため、まずは避けてください。

ここでいう「グローバル」は、コアに渡された後の処理方法を示すもので、パソコン上のすべてのアプリを自動的に経由させるという意味ではありません。アプリのリクエストがクライアントに届くかどうかは、システムプロキシ、アプリ自体の設定、またはTUNによって異なります。プロキシグループの自動選択、フェイルオーバー、負荷分散は、初回接続時に設定する必要はありません。詳しくはプロキシグループのフィールドをご覧ください。

手順3：コアとシステムプロキシを有効化

クライアントのメイン画面に戻り、コアが起動していることを確認します。設定を追加するとコアが自動で起動するクライアントもあれば、「接続」や「起動」ボタンを押す必要があるものもあります。設定エラー、ポートの競合、コアの起動失敗が表示された場合は、先に問題を解決してからシステムプロキシを有効にしてください。システムプロキシはアプリのリクエストをローカルの待ち受け先に向ける機能です。待ち受けが起動していないと、ブラウザーが接続先のないポートにリクエストを送ってしまいます。

「システムプロキシ」のスイッチを探して有効にします。設定画面、ホーム画面のショートカット、メニューバーのメニューなどにあります。初回の有効化時に、macOSまたはクライアントからヘルパーサービスのインストールやネットワーク設定の変更を求められた場合は、要求元のアプリと操作内容を確認してから案内に従って許可してください。ヘルパーサービスの名称や許可方法はクライアントによって異なります。ガイドに合わせるために、画面に存在しないボタンを探す必要はありません。

macOSの「システム設定」を開き、「ネットワーク」から現在使用中のWi-FiまたはEthernetサービスを選びます。「詳細」の「プロキシ」を開いてください。古いmacOSでは、「システム環境設定」のネットワーク詳細設定に表示される場合があります。WebプロキシとセキュアWebプロキシのアドレスとポートがクライアントの設定と一致するか確認します。クライアントでSOCKSプロキシを設定している場合は、該当項目も確認してください。ローカルアドレスは127.0.0.1、混合ポートの例は7890ですが、実際の設定を優先してください。

確認中は、ほかのプロキシツールのシステム接続スイッチをオフにして、複数のアプリが同じネットワーク設定を書き換えるのを避けてください。会社管理のプロキシ、VPN、セキュリティソフトもルーティングやDNSに影響する場合があります。所属先のネットワーク管理ルールに従って操作してください。設定後はまだTUNを有効にせず、次の手順でブラウザーの接続を確認します。この順序なら、システムプロキシと仮想ネットワークインターフェースの問題を切り分けられます。

手順4：ブラウザーとターミナルで接続を確認

まずSafari、またはシステムプロキシを使う設定のブラウザーで、確認したいHTTPSページを開きます。次に、通常は直接接続できるページも開いて比較してください。ページが表示されることは最初の確認にすぎません。クライアントの「接続」または「ログ」画面も開き、リクエストを再送して対象ドメインが記録されているか、どのルールが適用されたか、最終的にどのプロキシグループと接続先が選ばれたかを確認します。接続履歴はすぐに消える場合があるため、必要に応じてページを再読み込みし、すぐにログを確認してください。

ブラウザーに独自のプロキシ拡張機能が入っている場合は、システム設定を上書きしていないか確認してください。ダイレクトルールが適用されるサイトでは、クライアントが正常でもリモートノードを経由しないことがあります。そのため、接続元のIPアドレスが変わらないだけで、プロキシが動作していないと判断しないでください。対象サイトに適用されたルールを確認し、設定どおりに処理されているか判断します。ルールの評価順についてはルール構文をご覧ください。

現在のネットワークサービスのプロキシ設定を確認

「ターミナル」を開き、以下のコマンドでシステムのネットワークサービスを読み取り専用で確認できます。プロキシ設定は変更されません。まずサービス名を一覧表示し、続くコマンドのWi-Fiを実際に使用中のサービス名に置き換えてください。結果に表示される有効状態、サーバーアドレス、ポートがクライアントと一致しているか確認します。これでシステム設定に値が反映されていることは分かりますが、リモートノードが使えるかどうかまでは判断できません。

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
networksetup -getsocksfirewallproxy "Wi-Fi"

明示的なプロキシ指定でローカル待ち受けとシステム接続を切り分ける

ターミナルのツールはmacOSのシステムプロキシを参照しない場合があります。以下のコマンドでは、curlにローカルのHTTPプロキシを明示してリクエストを送り、待ち受けポートとその先の接続経路を個別に確認します。実行前にHTTPポートまたは混合ポートを確認してください。7890以外の場合はポート番号を書き換えます。接続先のドメインは公開されている例示用アドレスです。結果は現在のネットワーク、ノード、接続先のサービスにも左右されます。

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

ローカルポートに接続できない場合は、クライアントに戻ってコアと待ち受けポートを確認します。ローカルには接続できてもリモートへのリクエストがタイムアウトする場合は、ノード、プロキシグループ、接続先のネットワークを確認してください。有効なHTTPレスポンスを受信できれば、そのリクエストがHTTPサービスに届いたことは分かりますが、接続先の確認には接続履歴も必要です。ブラウザーは使えるのに、プロキシを指定しないcurlだけ失敗する場合は、すぐにクライアントを再インストールせず、ターミナルのプロキシ設定を確認してください。

現在のターミナルセッションにプロキシを設定

これらの環境変数に対応したコマンドラインツールでプロキシを使う場合は、現在のシェルで以下のコマンドを実行します。HTTPSリクエストもHTTPプロキシのトンネル機能を通して転送されるため、プロキシアドレスにはhttp://を指定します。この設定が適用されるのは現在のシェルと、そこから起動した子プロセスです。すでに実行中のターミナルの処理には反映されません。また、環境変数への対応状況はツールによって異なります。

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export no_proxy="localhost,127.0.0.1,::1"

curl --connect-timeout 10 -I https://example.com/

まず現在のセッションで動作を確認してから、シェルの設定ファイルに追加するか判断してください。最初から複数の起動ファイルに書き込むと、クライアント終了後も設定が残ることがあります。これでブラウザーのリクエスト、システムプロキシの設定値、プロキシを明示したテストをそれぞれ確認できました。対象アプリがシステムプロキシを使わない場合は、次のTUNの手順を検討してください。

必要に応じて設定：TUNモードと権限

TUNは仮想ネットワークインターフェースとルーティングを使ってリクエストを取り込み、システムプロキシを参照しないアプリなどを経由させたい場合に役立ちます。「ルール／グローバル／ダイレクト」とは異なる層の設定です。TUNはリクエストをコアに渡す方法を決め、プロキシモードはコアに渡された後の接続先を決めます。TUNへの対応状況、使用するネットワークスタック、ヘルパーサービスの導入方法は、クライアントと組み合わせるコアによって異なります。mihomoコアを採用したクライアントでも、設定画面の場所はそれぞれ異なる場合があります。

先にシステムプロキシの接続確認を済ませてから、クライアントのネットワーク設定または詳細設定を開き、「TUNモード」などの項目を探します。サービスモードや特権ヘルパーのインストールを求められた場合は、クライアントの案内に従って許可し、その後TUNを有効にしてください。インターネット上のルート設定コマンドを手動でコピーするのは避けます。初回はクライアントのデフォルトのネットワークスタックとルーティング設定を保ち、対象アプリからリクエストを送り直して、接続履歴に記録されるか確認してください。

有効にした後、DNSの異常、LAN内のデバイスへの接続不可、ほかのVPNとの競合が起きた場合は、まずTUNを無効にして、確認済みのシステムプロキシ設定に戻します。その後、変更は一度に1項目ずつ行ってください。スイッチがオンだからといって、すべての通信が取り込まれているとは限りません。アプリのプロトコル、除外ルート、システム権限も実際の動作に影響します。DNS、ルーティング、YAMLの構造について詳しくはYAMLガイドをご覧ください。初めて使う段階ですべて変更する必要はありません。

プラットフォーム別の補足：Windowsアプリのループバック

このセクションはWindows専用です。AppContainerで分離されたアプリの中には、ローカルのループバックプロキシへの接続がシステムによって制限されるものがあります。その場合、ブラウザーではプロキシを使えるのに、特定のアプリだけ接続できないことがあります。これはmacOSのシステムプロキシの許可とは別の問題です。MacユーザーはUWPのループバック設定を探す必要はなく、Windows向けの除外コマンドを使わないでください。

Windowsではまず、同じローカルプロキシポートを通常のデスクトップアプリから利用できることを確認し、対象アプリがループバック制限を受けているか調べます。クライアントに「ループバックの免除」などのツールがある場合は、案内に従い必要な権限で起動し、ローカルプロキシへのアクセスが必要なアプリだけを除外対象に設定してください。保存後は対象アプリを完全に終了して再起動します。クライアントにそのツールがないからといって、Windowsアプリすべてでプロキシが使えないわけではありません。ループバックの免除を万能の修復方法として扱わないでください。

ループバックの免除で許可されるのは、アプリからローカルアドレスへのアクセスです。サブスクリプションの追加、ノードの選択、システムプロキシの設定に代わるものではありません。免除後も接続できない場合は、アプリがプロキシを参照するか、UDPを使っているか、現在の設定が該当する通信を許可しているかを切り分けてください。Windows用クライアントが必要な場合は、Windowsのダウンロードページから選択できます。設定済みのMac環境を変更する必要はありません。

クライアントの終了とネットワークの復旧

テスト後にプロキシを停止する場合は、まずクライアントでTUNとシステムプロキシを無効にしてから終了します。ローカルの待ち受けが停止した後も、システム設定が以前のポートを参照し続けるのを防げます。メインウィンドウを閉じても、クライアントがメニューバーに格納されるだけの場合があります。メニューバーから終了を選んでプロセスを終了してください。実際の動作はクライアントの設定によって異なります。

クライアントが予期せず終了してブラウザーがインターネットに接続できなくなった場合は、まず現在のネットワークサービスのプロキシ設定を開き、ローカルを指すHTTP、HTTPS、またはSOCKSプロキシが残っていないか確認します。それらが直前に使っていたクライアントによって設定されたものと確認できた場合に限り、該当項目を解除してください。会社のネットワークで必要なプロキシアドレスや自動プロキシ設定をまとめて削除しないでください。ターミナルの環境変数を使っていた場合は、該当する変数を削除するか、セッションを閉じてターミナルを開き直します。

unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

~/.zshrcなどの起動ファイルに変数を追加していた場合、unsetを実行しただけでは新しいセッションで再読み込みされます。自分で追加した該当行も削除してください。復旧後はブラウザーとターミナルをそれぞれテストします。動作を確認できた設定を保存し、サブスクリプションの更新、ルールの追加、TUNの有効化は一度に1項目ずつ行いましょう。引き続き設定をカスタマイズする場合は、サブスクリプション全体を上書きするのではなく、設定のオーバーライドを確認してください。