Clash クイックスタート:サブスクリプションのインポートから動作確認まで

STEP 00 / 事前準備

開始前に用意する2つのもの

この手順全体は2つの前提条件だけに依存しており、どちらか一方でも欠けると進められません:

• インストール済みの Clash クライアント:プラットフォームは問いません。ダウンロードセンターから Clash Plus または Clash Verge Rev を取得するのがおすすめです。各クライアントの機能比較はクライアント比較ページを参照してください。
• サブスクリプションリンク:プロキシサービス事業者が提供する https:// で始まる URL で、アクセスするとノード・プロキシグループ・振り分けルールを含む完全な Clash 設定ファイルが返されます。通常はサービス事業者のユーザーパネルからコピーできます。Clash または Clash Meta 形式を選ぶよう注意してください。

サブスクリプションリンクはアカウント認証情報と同等の扱いが必要で、公開の場に貼り付けないでください。リンクの内部構造(ポート、プロキシグループ、ルールセクションがそれぞれ何を担うか)はこのページの操作には影響しません。興味があれば後で技術ノートのProfile 構造解説を読んでみてください。準備が整ったら最初のステップへ進みます。

STEP 01 / 04

サブスクリプション設定のインポート

クライアントを起動し、左側のナビゲーションまたは下部のタブバーから設定ページ(Profiles / サブスクリプション / 配置文件)を探します。初回起動時はリストが空で、ページ上部に URL 入力欄があり、その横に「インポート」または「ダウンロード」ボタンがあります。

1. サブスクリプションリンクを丸ごと入力欄に貼り付けます。前後に余分な空白を入れないこと、https:// のプレフィックスを欠落させないこと——これがインポート失敗の最も多い原因です。
2. 「インポート」をクリックします(一部のクライアントでは「ダウンロード」や下向き矢印アイコンの場合もあります)。クライアントがその URL にリクエストを送り、返された内容をローカルの設定ファイルとして保存します。通常1〜3秒で完了します。
3. 成功すると、リストに新しい設定カードが表示され、設定名・トラフィック情報(サービス事業者が提供している場合)・更新日時が示されます。このカードをクリックして現在有効な設定として設定します——多くのクライアントではカードに選択マークやハイライト枠が表示されます。

カードが選択状態になっていれば、コアがその設定内のノードとルールを読み込んだことを意味し、最初のステップは完了です。インポート時にエラー(タイムアウト、404、形式が解析できない)が出た場合は、まずリンクをブラウザで正常に開けるか確認してください。それでも解決しない場合は、よくある質問の「インストールと設定」カテゴリの項目を順に確認してください。なお、サブスクリプションを更新するとサービス事業者から配信された新しい内容で設定が上書きされます。カスタマイズした変更を保持する方法についても同ページで解説しています。

STEP 02 / 04

プロキシモードの選択

設定を読み込んだら、次に決めるのはトラフィックの振り分け方式です。メイン画面の概要やプロキシページ(Proxies)にモード切り替えのコントロールがあり、通常は3つの選択肢が並んでいます:

• ルール(Rule):設定ファイル内の振り分けルールに1件ずつマッチさせ、直接接続ルールに一致した通信はプロキシを経由せず、それ以外はルールに従って対応するプロキシグループを通ります。日常使用ではこのモードのままにしてください。速度と到達性のバランスが取れます。
• グローバル(Global):すべての通信が選択中のノードを経由し、振り分けルールは無視されます。特定のノードが使えるかを一時的に確認する用途にのみ向いています。常用すると本来直接接続できる通信も迂回するため、速度が落ちてプランの通信量も消費します。
• ダイレクト(Direct):すべての通信がプロキシを経由しません。「あるサイトの異常がプロキシ由来かどうか」を切り分ける際に使い、ダイレクトとルールモードでの挙動を比較すれば原因を特定できます。

操作としては「ルール」を選ぶだけで、他に確認は不要です——モードはクリックした瞬間に反映されます。3つのモードの詳しい比較と切り替えの典型的なタイミングについては、技術ノートのプロキシモード選択ガイドを参照してください。現在ルールモードになっていることを確認したら、3番目のステップへ進みます。

STEP 03 / 04

システムプロキシの有効化とノードへの接続

この時点でコアはローカルのミックスポート(デフォルト 7890)で待ち受けていますが、システムの通信はまだそこに誘導されていません。ここでは2つの作業を行います:システムプロキシを有効にし、使用可能なノードを1つ選びます。

1. クライアントの設定ページまたはホーム画面の概要から「システムプロキシ」(System Proxy)のスイッチを見つけてオンにします。この操作でオペレーティングシステムのプロキシ設定が 127.0.0.1:7890 を指すようになり、ブラウザや大半のアプリの通信がクライアント経由で処理されるようになります。スイッチがアクティブな色に変われば成功です。
2. プロキシページ(Proxies)に切り替えます。ここには設定ファイルの定義に従って複数のポリシーグループが表示され、各グループの下に選択可能なノードが並びます。グループ内の遅延テストボタン(雷や波形のアイコン)をクリックし、各ノードの右側にミリ秒単位の遅延値が表示されるまで待ちます。
3. メインのポリシーグループで、遅延値が正常なノード(通常は数十〜300ミリ秒程度。タイムアウトや空欄表示のノードは現在利用できません)を選択します。選択した項目の前にマークが付き、そのグループの出口がこのノードに切り替わります。

ここまでで経路がつながりました:システムの通信 → ローカル 7890 ポート → ルールマッチング → 選択したノード。補足を2点:コマンドラインツールや一部のゲームなどシステムプロキシ設定を読まないプログラムは、TUN モードで通信を引き受ける必要があります。有効化の条件と注意点はよくある質問を参照してください。クライアントをシステム起動時に自動起動させたい場合は、「使い方のコツ」カテゴリに各プラットフォームでの自動起動設定方法があります。

STEP 04 / 04

プロキシが有効になっているかの確認

感覚で判断せず、2つの観察可能なシグナルで設定が本当に有効になっているかを確認します。

シグナル1:接続パネルに通信が現れ、想定のノードに一致している。クライアントの接続ページ(Connections)を開き、ブラウザで適当なウェブページにアクセスします。パネルに戻ると新しい接続記録が表示され、各記録には接続先のドメイン、マッチしたルール、実際に使われたプロキシチェーンが示されています。海外サイトへの接続がステップ3で選んだノードを経由していれば、ルールとノードの両方が正しく機能しています。

シグナル2:ローカルポート経由のリクエストが通る。ターミナルで次のコマンドを実行し、このリクエストを強制的にクライアントのミックスポート経由にします:

curl -x http://127.0.0.1:7890 -I https://www.gstatic.com/generate_204

HTTP/2 204 または HTTP/1.1 204 が返れば、プロキシ経路は利用可能です。応答が止まったり接続拒否が返る場合は、ポートが待ち受けていないかノードが通っていないことを示します。さらに、ブラウザで任意の IP 帰属確認ページにアクセスし、出口アドレスがノードの所在地域として表示されることも直感的な裏付けになります。

両方のシグナルが確認できれば、設定手順はここで完了です。「パネルに接続はあるがページが開かない」「アドレスは変わったが一部のアプリだけプロキシを通らない」といった局所的な異常が出る場合、多くは DNS 解決やアプリ自体のプロキシ方針に関係しています——DNS リークの検出と対処はよくある質問の「トラブル対処」カテゴリに専用の項目があり、Fake-IP モードの仕組みと適用範囲については技術ノートの関連記事を参照してください。