01サブスクリンクを導入する
サブスクリンクはサービス提供元が発行する https:// のアドレスで、クライアントはここからノード一覧と振り分けルールをダウンロードし、以後は設定した周期で自動更新する。始める前に2点だけ確認しておく。1つ目は、リンクを先頭から末尾まで完全にコピーすること——一部の提供元ではリンク末尾に &flag=clash のようなパラメータが付いており、これが欠けるとサーバーがクライアントに解釈できない形式を返してくる。2つ目は、リンクがClash形式(提供元側で「Clash」や「YAML」と表記されていることが多い)であること。純粋なBase64ノードリスト形式のリンクは多くのClashクライアントで直接読み込めない。形式の違いと変換方法はサブスク形式の解説を参照。
- リンクをコピーする。サービス提供元のユーザーパネルで「サブスクリプション」や「ワンクリック導入」の項目を探し、コピーボタンで完全なリンクを取得する。まず任意のテキストボックスに貼り付けて、途中で切れていないか、余分な空白が混入していないかを確認しておくとよい。
- 設定管理ページを開く。クライアントを起動し、左側(モバイルでは下部)ナビゲーションの設定管理ページに移動する——Clash Verge Rev では「サブスクリプション」、Clash Plus と FlClash では「設定」と表示される。画面上部か右上にURL入力欄、または「インポート/新規作成」ボタンがある。
- 貼り付けて導入する。リンクを入力欄に貼り付け、「インポート」または「ダウンロード」をクリックする。クライアントはその場でこのアドレスから設定を取得し、通常のネットワーク環境であれば数秒で一覧に新しい設定カードが表示される。カードには設定名のほか、提供元によっては残りトラフィック量と有効期限も表示される。
- 設定を有効化する。そのカードをクリックして現在有効な設定にする。有効化に成功したかどうかは見た目でわかる——カードの枠がハイライトされるか選択マークが付き、同時にプロキシページにノードグループが表示され始める。カードがずっと灰色のまま、プロキシページが空のままであれば、まだ有効化されていないか設定の解析に失敗している。
導入段階でよくある失敗は2種類ある。1つは「解析エラー」「形式不一致」と表示される場合で、これはほぼ形式の問題と断定できるので、前述の形式解説記事に従って変換してから再試行する。もう1つはインポートボタンがタイムアウトまでずっと回り続ける場合で、これはサブスクアドレスが現在のネットワークから到達できないことを示している。別のネットワーク環境(たとえばスマートフォンのテザリング)に切り替えて再試行するか、時間を置いて再度試す。何度も失敗する場合や「導入は成功したがノードが表示されない」といった複雑なケースは、トラブル対処ページのサブスクの章に一通りの手順がまとまっている。
設定を導入しただけではノードは自動的に動作を始めない——クライアントには通信をどの方針でどのノードに流すかを指定する必要があり、それが次のステップになる。
02プロキシモードとノードを選ぶ
Clash系クライアントには3つの出口モードがあり、メイン画面か設定内の「モード」で切り替える。
- ルール(Rule):接続ごとに設定内の振り分けルールを順に照合し、直接接続ルールに合致すればローカル通信、プロキシルールに合致すればノード経由になる。日本国内のサイトは直接接続、それ以外はプロキシというのがほとんどのサブスク設定の既定動作であり、通常はこのモードを維持しておく。
- グローバル(Global):すべての通信を例外なくプロキシに通す。全通信を強制的にノード経由にしたい場合だけ一時的に使うもので、常用すると無駄にトラフィックを消費し、国内サイトへのアクセスも遅くなる。
- 直接接続(Direct):すべての通信がプロキシを経由しない、クライアントを一時的にバイパスした状態。トラブル対処時にたまに使う。
モードを「ルール」に切り替えたことを確認したら、「プロキシ」ページでノードを選ぶ。このページは設定内のポリシーグループごとにブロック分けされて表示される——手動選択グループでは直接ノードをクリックして選ぶだけでよい。「自動」「Auto」「URL Test」といった名前のグループは周期的に速度測定を行い、遅延が最も低いノードを自動的に選び続けるため手動操作は不要。多くのクライアントではグループの右上に雷アイコンや測定アイコンがあり、クリックすると各ノードの横にミリ秒数が表示される。この数値はテストアドレスへの1回のHTTPハンドシェイクにかかった時間で、ノードを相対比較する目安になるが実際の使用感とは一致しない——80msのノードでもパケットロスや帯域の制約で動画再生がカクつくことはあり、その仕組みは遅延テストの仕組み解説を参照。選ぶ際は単発の最低値よりも、複数回測定してブレが小さく安定しているノードを優先するとよい。
ここまででクライアント内部の準備は完了している——設定は有効化済み、モードも決まり、ノードも選んだ。ローカルの待受ポート(設定ページで確認できる、既定は多くの場合 7890 か 7897)は通信の到着を待っている状態だ。ただしシステム側の通信はまだこのポートに導かれていない——それを済ませるのが3番目のステップになる。
03接続をオンにする
プラットフォームごとに通信をクライアントに渡す仕組みが異なるので、自分の使っている端末の項を見ればよい。
Windows / macOS デスクトップ版
メイン画面か設定ページで「システムプロキシ」のスイッチを探してオンにする。オンにすると、クライアントはOSのHTTP/HTTPSプロキシ設定をローカルの待受ポート(前のステップで見た 127.0.0.1:7890 のようなアドレス)に向けて書き込む。以後、ブラウザやシステムプロキシに従うほとんどのアプリの通信はクライアントを経由するようになる。スイッチが有効色に変われば書き込み成功のサイン。macOSでは初回オン時にシステムの権限確認が表示されることがあり、案内に従って許可すればよい。クライアントを終了する前にこのスイッチを先にオフにしておくこと——そうしないとシステムプロキシが存在しないポートを指し続け、「Clashを終了したのに逆にネットに繋がらない」という典型的な現象が起きる。
Android
メイン画面の大きなスイッチか起動ボタンをタップすると、初回はシステムレベルの「VPN接続リクエスト」ダイアログが表示されるので許可を選ぶ——Android版はVpnServiceを通じて通信を引き受ける仕組みのため、この許可は一度だけ必要な手順になる。接続が確立するとステータスバーに鍵(VPN)アイコンが表示され、メイン画面のスイッチも有効状態になる。
iOS
App Store版クライアントは初回起動時にVPN設定の追加をリクエストするので、システムの案内に従ってパスコード入力またはFace IDで確認する。以後はアプリ内の接続スイッチをタップするだけでよく、同様にステータスバーのVPN表示で接続確立を確認できる。
TUNモードについて:デスクトップ版にはもう1つ「TUNモード」というスイッチがあり、仮想ネットワークアダプタを通じてコマンドラインツールやゲームを含む全システム通信を引き受ける。システムプロキシに従わないプログラムもカバーできるが、Windowsでは管理者権限またはシステムサービスの導入が必要で、一部のLAN環境では相性の問題もある。最初はシステムプロキシだけで十分で、TUNを有効にするタイミング・権限設定・DNS連携についてはトラブル対処ページに専用の章があり、関連するFake-IPの仕組みはこの解説記事で読める。
スイッチがオンにできず、ログに bind や address already in use のようなエラーが出ている場合は、待受ポートが他のプログラムに占有されていることを示す——設定ページでポートを変更するか、そのポートを占有しているプログラム(よくあるのは別のプロキシソフトの残留プロセス)を終了してから再試行する。
04プロキシが機能しているか確認する
接続スイッチがオンになっていても、実際に通信がノード経由になっているとは限らない。1分ほどかけて3つの確認を行い、経路全体が通っているかを確かめる。
- アクセステスト。ブラウザで、これまで開けなかった、ルール上プロキシ経由になるべきサイトを開く。正常に表示されればプロキシ経路はおおむね機能している。開けない場合はすぐにノードを変えず、以下の2項目でどの段階に問題があるかを特定する。
- 接続ログを見る。クライアントの「接続」または「ログ」ページに切り替える。正常であれば新しい接続記録が続けて表示され、各記録に宛先ドメイン、ヒットしたルール、出口ノードが表示される。ルール欄に
DIRECTと表示されればそれは直接接続、ポリシーグループ名が表示されればプロキシ経由。このページに新しい記録が全く出ない場合は、システムの通信がそもそもクライアントに入っていないことを示す——問題はステップ3にあるので、システムプロキシのスイッチやVPN許可を戻って確認する。 - 出口IPを確認する。ブラウザで任意のIP帰属確認ページを開くと、表示される出口アドレスが選んだノードの所在地域に変わっているはず。プロキシページで別の地域のノードに切り替え、確認ページを再読み込みすると帰属地も変わるはず。この確認で、通信が本当にノードを経由して出ていること(ローカルで回っているだけではないこと)がわかる。
アクセステストが失敗する場合、発生頻度が高い順に確認する。
- システムプロキシのスイッチがオフになっている、または他のソフト(ダウンロードツール、別のプロキシソフト)によってリセットされている;
- ブラウザにプロキシ切り替え系の拡張機能が入っていて、拡張機能側の設定がシステムプロキシより優先されている場合——まず拡張機能を「システムに従う」に切り替える;
- モードが誤って「直接接続」になっている、ステップ2に戻って確認する;
- ノードが全てタイムアウトしている場合は、プロキシページで速度測定を行い、遅延が正常なノードに切り替えて再試行する。
この4つで新規ユーザーの「機能しない」の9割以上をカバーできる。残りのケース——DNS汚染、TUN競合、サブスクの期限切れ、セキュリティソフトによるシステムプロキシ書き込みの妨害など——は症状別に整理したトラブル対処ページに完全な手順があるので、本ページでは網羅しない。
これで完了。4ステップを終えれば、クライアントは日常的に使える状態になっている。あとやることは2つだけ——サブスクの期限が切れる前に更新すること、そして時々設定管理ページで手動更新をタップすること(多くのクライアントは自動更新の間隔設定にも対応している)。