Clash Windows版：サブスクリプションの追加から接続確認まで

まず、現在も有効なサブスクリプションURLを用意します。通常はサービス提供元が発行したもので、https://で始まる場合もあれば、管理画面の「サブスクリプションをコピー」から取得する場合もあります。ブラウザーのアドレスバーに表示されるページURL、単独ノードの共有リンク、WebサイトのログインURLは、Clashが読み込めるサブスクリプションとは限りません。提供元がClash、Mihomo、または汎用サブスクリプション用の入口を明記しているか確認するのが確実です。

コピー時はURL全体を取得してください。チャットアプリや文書ツールではリンクの前半しか見えないことがありますが、コピー結果は完全な場合があります。一方で、末尾に空白や改行が混ざることもあります。追加する前にプレーンテキストエディターへ貼り付け、先頭、パラメーター、末尾が欠けていないか確認しましょう。サブスクリプションURLは設定への入口です。公開コメント、スクリーンショット、公開リポジトリに載せないでください。

クライアントにすでに動作する設定がある場合は、急いで上書きせず残しておきます。多くのGUIクライアントでは複数のProfileを共存させられるため、新しいサブスクリプションを2つ目の設定として追加できます。新しい設定の解析に失敗しても、以前の設定へ戻して使い続けられます。初回操作の目的はルールを書き直すことではなく、完全な設定をカーネルに正常に読み込ませることです。

準備ができたら、次はProfileだけを扱います。この時点ではシステムプロキシを有効にせず、DNS、ポート、TUNも同時に変更しないでください。変数が少ないほど、問題が起きたときにどの層で止まったかを特定しやすくなります。

クライアントを開き、Profiles、設定、サブスクリプション管理、または設定ファイルに似た名前の画面へ移動します。Windows版ではProfilesが左側のナビゲーションにあることが多く、モバイル版の一部ではホーム画面右上に追加ボタンがあります。URL入力欄を見つけたら、先ほどコピーしたサブスクリプションURLを貼り付け、Download、Import、更新、確認などのボタンを押します。ここで行うのはリモート設定のダウンロードであり、プロキシの起動ではありません。

通常、数秒以内に新しい設定カードが追加されます。カードには設定名、更新日時、ファイルサイズ、更新間隔などが表示されることがあります。そのカードをクリックして、現在有効なProfileにします。ダウンロードに成功しただけでは不十分です。追加後も以前の設定がアクティブなままのクライアントがあるため、選択マーク、Activeラベル、強調枠が新しい設定へ移動したか確認してください。

続いてProxies、プロキシ、またはポリシーグループの画面を開きます。複数のポリシーグループと選択可能なノードが表示されれば、設定の基本的な解析は完了しています。ポリシーグループ名は「ノード選択」「自動選択」「ストリーミング」などが一般的ですが、サービス提供元が独自に付けている場合もあります。名前は固定ではありません。重要なのは、画面が空ではなく、少なくとも1つの主要ポリシーグループを展開できることです。

proxies:
  - name: example-node
    type: ss

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - example-node

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

上記の構造は、設定が完全かどうかを判断するためのものです。proxiesはノードを提供し、proxy-groupsは選択ロジックを構成し、rulesは通信の行き先を決めます。GUIクライアントでは通常、YAML全体を直接表示しませんが、追加後には少なくともプロキシグループが生成されます。設定名だけが表示され、Proxiesを開いても完全に空の場合は、サブスクリプションの内容が非対応、Webページのテキストが返されている、またはサブスクリプションの期限切れなどが考えられます。

追加に失敗したら、まずクライアントに表示された元のエラーメッセージを確認します。タイムアウトはサブスクリプションURLへ一時的にアクセスできないことを示します。異常なステータスコードはリンク切れやパラメーター不足の可能性があります。YAML解析エラーは、サーバーから返された設定形式に問題があることを示します。何十回も更新を連打したり、すぐにクライアントを再インストールしたりしないでください。まずURLをコピーし直してもう一度試します。それでも失敗する場合は、エラーが「ダウンロード段階」と「解析段階」のどちらで起きたかを切り分け、ヘルプセンターで該当する項目を確認してください。

設定を読み込んだら、Mode、モード、実行モードなどの項目を探します。初回はRuleを選択します。Ruleモードは設定内のルールを上から順に照合し、リクエストをDIRECT、PROXY、REJECT、または指定されたポリシーグループへ渡します。ローカルサービスは直接接続し、プロキシが必要な宛先はノードへ送り、遮断ルールはカーネル層で接続を終了します。日常利用では、グローバルプロキシよりも設定ファイル本来の設計に適しています。

Globalは大半の通信を1つのプロキシポリシーへまとめて送るモードです。「ルールのせいで特定サイトの経路が間違っているか」を短時間で確認する用途には向きますが、初回設定の標準モードには適しません。Directは通信をできるだけ直接接続にするモードで、プロキシ経路を一時停止したり比較テストをしたりするときに使います。クライアントによってRule、Global、Directと表記される場合も、ルール、グローバル、直接接続と翻訳される場合もありますが、意味はほぼ同じです。

Ruleを選択したら、Proxies画面でポリシーグループを設定します。まず最終出口を担当する主要選択グループを探します。一般的にPROXYという名前ですが、必ずしもそうとは限りません。展開して利用可能なノードを選びます。設定に「自動選択」やURL-Testグループがあれば、まず自動グループを選び、設定側のテストルールに出口を決めさせても構いません。この段階で全ノードを一つずつ試す必要はありません。遅延の数字だけで実速度を判断するのも避けてください。遅延テストはテスト先との1回の往復時間であり、帯域幅や継続的な安定性を示すものではありません。

主要グループの下に地域グループ、アプリグループ、自動グループが含まれている場合は、現在選択されている経路をたどり、最下層が実際のノードへ到達できるか確認します。よくある空振りは、最上位グループで別のポリシーグループを選んでいるのに、下位グループに有効なノードがないケースです。GUIでは通常、チェック、丸印、ハイライトなどで選択中の項目が示されます。最下層まで確認し、具体的なノード名が表示されれば完了です。

モードとノードを決めたら、ほかの設定はそのままにします。特にFake-IP、Sniffer、IPv6、DNSの項目を見つけても、一度にすべて切り替えないでください。サブスクリプションには通常、ルールに合わせた基本設定が含まれています。複数の項目を同時に変更すると、単純な接続テストが多変数の切り分けになってしまいます。各プロトコル、カーネルの関係、設定の互換性については技術リファレンスで詳しく解説し、このページでは接続に必要な選択だけを扱います。

General、ホーム、または設定画面に戻り、System Proxy、システムプロキシのスイッチを有効にします。Windowsクライアントは通常、現在のユーザーのネットワーク設定にシステムプロキシを書き込みます。その後、ブラウザーやシステムプロキシに対応するデスクトップアプリがリクエストをClashのローカルポートへ渡します。macOSクライアントではメニューバーから切り替える場合があります。AndroidとiOSでは通常、システムVPNインターフェースで接続し、初回有効化時にシステムの許可を確認します。

有効化後はクライアントの状態を確認します。カーネルがRunning、起動済みなどの状態を維持し、システムプロキシのスイッチもすぐにオフへ戻らないことを確認してください。ネットワーク、VPN、ファイアウォールの許可が表示されたら、要求元が現在インストールしているクライアントであることを確認し、プラットフォームの指示に従って許可します。必要な権限を拒否すると、画面上は接続済みでも、実際のアプリ通信がカーネルに入らない場合があります。

この段階では、システムプロキシだけで最初のテストを行います。ブラウザーは通常すぐに新しいプロキシ設定を読み込みますが、長時間起動しているアプリの中には古い接続をキャッシュするものがあります。その場合は完全に終了してから再起動してください。最初からTUNを同時に有効にしないでください。システムプロキシでは、プロキシ設定に従わないプログラム、一部のコマンドラインツール、一部のゲーム通信を取り込めません。TUNはより広い経路を処理できますが、仮想NIC、ルーティング、権限などの要素が増えます。まずノード、サブスクリプション、ルールが機能することを確認し、必要に応じてTUNを有効にします。

TUNが本当に必要な場合は、TUN Mode、仮想NIC、拡張モードなどのスイッチを探します。Windowsでは管理者権限が必要になる場合があり、モバイル端末ではシステムのVPN経路を使用します。有効化後はクライアントログを確認し、NIC作成失敗、ルート書き込み失敗、権限不足が繰り返し発生していないか確認してください。システムプロキシとTUNを同時に有効にできるかは実装によって異なります。自動調整するクライアントもあれば、TUNだけを有効にするよう推奨するクライアントもあります。現在のクライアントの画面表示を基準にし、他のクライアントの手順をそのまま当てはめないでください。

接続後は、しばらくクライアントのウィンドウを閉じたりバックグラウンドプロセスを終了したりしないでください。システムプロキシは通信先をローカルの待受ポートへ向けるだけで、実際に接続を処理するのは起動中のClashまたはmihomoカーネルです。カーネルを終了したままシステムプロキシが残っていると、ブラウザーですべてのページに接続できなくなることがあります。これはサブスクリプションが無効になったという意味ではなく、クライアントを再起動するか、残ったシステムプロキシを無効にすれば復旧できます。

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

dns:
  enable: true
  enhanced-mode: fake-ip

上記の項目は、よくある動作関係を示しています。modeは分岐モード、mixed-portはローカルプロキシの待受ポート、DNSモジュールは名前解決の流れを担当します。実際のポート番号とDNSの内容は現在の設定に従うため、例に合わせて手動変更する必要はありません。クライアントがカーネルを起動し、システム通信を取り込めれば、確認手順へ進めます。

確認は3段階で行います。第1段階はカーネルの状態です。クライアントでエラーが継続しておらず、現在のProfile、Ruleモード、ノードが選択されたままか確認します。第2段階はシステム通信です。ブラウザーで普段直接開けるサイトを開き、続けてサブスクリプションのルール上プロキシ経由になる対象へアクセスします。第3段階はルール適用状況です。Connections、接続、ログなどの画面を開き、直前のリクエストが表示され、対応するポリシーが示されているか確認します。

Webページが開いただけでは、ルール分岐が正しいとは限りません。キャッシュから表示された可能性や、もともと直接接続できるサイトである可能性があります。接続ログのほうが確実です。通常、対象ドメインの横に適用されたルール、ポリシーグループ、最終ノードが表示されます。直接接続すべきリクエストがDIRECT、プロキシ対象が主要プロキシグループまたは具体的なノード、遮断対象がREJECTになっていれば、ルール経路が想定どおりに動作しています。

クライアントにログレベルの選択がある場合、通常の確認では初期値のままで構いません。接続一覧はスクロールするログより読みやすいことが多いです。対象ページを更新してから、すぐにクライアントで最新の記録を確認します。ドメインが見つからない場合は、ページ内検索や時刻順の並べ替えを使います。接続一覧に新しい記録がまったくない場合は、システムプロキシが本当に有効か、現在のアプリがシステムプロキシに従うかを優先して確認してください。

次に切り戻しテストを行います。System Proxyを無効にするか、モバイル端末のVPNを切断して、先ほどのページを更新します。プロキシ対象のアクセス結果が変わり、クライアントの接続一覧にも新しいリクエストが表示されなくなるはずです。再接続してもう一度テストします。この比較により、ブラウザーキャッシュ、別のプロキシツールの起動、システムに残った古いプロキシ設定などの影響を切り分けられます。

最後に、すべてのソフトを一度に開くのではなく、普段使うアプリを確認します。まずブラウザー、次に日常的なクライアントを1つテストします。コマンドラインツール、仮想マシン、コンテナ、LAN内デバイスは後回しにしてください。これらは独自のDNS、ネットワーク名前空間、プロキシ設定を使う場合があり、問題がClashの主要接続にあるとは限りません。初回設定では、ブラウザーのルール分岐と接続ログが正しければ、信頼できる基準を確立できています。