初期設定 · 4ステップ

Clash Nyanpasuの使い方ガイド

「サブスクリプションを追加 → プロキシモードを選択 → 接続 → 動作確認」の順に初期設定を進めます。まずブラウザーで接続を確認し、その後でTUN、自動更新などを調整しましょう。利用可能なサブスクリプションがあれば、基本設定は通常10分ほどで完了します。

別のプラットフォームで使う場合は、まずクライアント名を確認してください。このページでは主にClash Nyanpasuデスクトップ版の操作を説明します。Windows、macOS、Linuxでは、メニュー名やサービスのインストール先がクライアントやリリースによって異なる場合があります。Android、iOSではダウンロードから対応するクライアントを選んでください。モバイル版では通常、デスクトップ版のシステムプロキシではなく、システムのVPN許可を通じて通信を取り込みます。「設定/サブスクリプション」「プロキシ/ポリシーグループ」など表示名が異なる場合は、機能に合わせて操作すればよく、同じ名前のボタンを探す必要はありません。

事前準備:クライアントをインストールしてサブスクリプションを用意

まずダウンロードから、OSとプロセッサーのアーキテクチャに合ったインストーラーを選び、クライアントをインストールして起動します。初回起動時にネットワークアクセスの許可を求められたら、用途を確認して必要に応じて許可してください。プロキシクライアントを複数同時に起動したり、すぐにTUNを有効にしたりするのは避けましょう。別のツールがシステムプロキシや仮想ネットワークアダプターを管理している場合は、先に切断してください。そうしないと、別のプログラムによる接続を確認してしまう可能性があります。

クライアントは設定の読み込み、コアの実行、通信の管理を担いますが、それだけでリモートの接続先が用意されるわけではありません。先へ進むには、信頼できる提供元から入手した有効なサブスクリプションURL、または使用するコアに対応した設定ファイルが必要です。サブスクリプションは通常、サービス提供元のアカウントページからコピーします。アカウントへのログインURLやサービス紹介ページのURLではありません。サブスクリプションをまだ入手していない場合でも画面の確認はできますが、クライアントをインストールしただけではリモートプロキシに接続できません。

サブスクリプションURLはアカウント情報の一部として扱ってください。公開コメントに投稿したり、相談用のスクリーンショットにURL全体を写したりしないでください。このガイドでは、高度なDNS設定、待ち受けポート、コアのバージョンを変更する必要はありません。まずは初期設定のまま使い、現在の設定名と使用するポリシーグループを控えておくと、問題発生時に変更箇所を特定しやすくなります。

ステップ1:サブスクリプションを追加して設定を有効化

設定画面でリモートサブスクリプションを追加

サイドバーの「設定」または「サブスクリプション」を開き、「新規作成」「追加」「インポート」などの項目を探します。リモートURLとローカルファイルを選べる場合、サブスクリプションURLがあるならリモートURLを選択してください。入力欄にURL全体を貼り付け、先頭や末尾に空白、改行、説明文が混入していないか確認します。「日常用」など見分けやすい設定名を入力し、「インポート」または「保存」をクリックして、ダウンロードと解析が終わるまで待ちます。

正常に追加されると、設定一覧に新しい項目が表示されます。バージョンによっては更新日時や更新状況も表示されますが、設定カードが表示されただけでは使用中とは限りません。その設定の有効化ボタンをクリックするか、現在の設定として選択します。次に「プロキシ」画面を開き、ポリシーグループとグループ内の選択肢が表示されることを確認してください。グループ名はサブスクリプションの内容によって異なり、「Proxy」や「ノード選択」とは限りません。ガイド中の英語名をそのまま探すのではなく、実際の設定内容から判断してください。

ローカル設定ファイルを使う場合は、ファイルのインポート画面から選択し、同様に有効化してください。ファイルをインポートしても、通常はリモートサブスクリプションのような自動更新機能は追加されません。元のファイルを後から編集しても、クライアントが自動で再読み込みするとは限りません。初めて使う場合は、現在使用する設定を一つに絞りましょう。設定Aを更新しているつもりで、実際には設定Bを使っていたという混乱を防げます。

解析の成功を確認してから次へ進む

インポート時に解析エラーが表示されたら、全局モードやTUNで回避しようとせず、まずここで止めてください。よくある原因は、サブスクリプションの期限切れ、URLからログインページが返されること、形式の非互換、ローカル設定ファイルのインデント誤りです。クライアントのログで今回のインポートに関する記録を確認します。ダウンロードエラーならURLと現在のネットワークを確認し、未対応の項目や構文エラーなら、提供元に適切なサブスクリプション形式を問い合わせてください。ノード一覧だけのデータにはルールやポリシーグループが含まれず、ルール振り分けの動作確認には別途設定が必要な場合もあります。

不慣れなオンライン変換サイトにサブスクリプションを貼り付けるのは避けてください。形式の違いを解決する必要がある場合は、まずプロトコルとコアの技術資料で互換性の説明を確認しましょう。更新に失敗した場合の確認方法はよくある質問を参照してください。設定を正常に有効化でき、プロキシ画面に利用可能なポリシーグループが表示されてから、モードを選択します。

ステップ2:プロキシモードとポリシーグループを選択

初回はルールモードを選択

ホーム画面またはプロキシ画面で「ルール/全局/直結」のモード切り替えを見つけ、まず「ルール」を選択します。ルールモードでは、現在の設定に含まれるルールに基づいて、リクエストごとにポリシーが振り分けられます。直結が必要なサービスとプロキシが必要なサービスを日常的に使う場合に適しています。全局モードでは通常、リクエストが全局ポリシーグループに送られますが、そのグループが必ずリモートの出口を選択しているとは限りません。直結モードは主に直接アクセスするためのものです。初期設定では何度も切り替えず、ルールモードに固定して、以降の確認に使う基準をそろえましょう。

モードの切り替えと出口の選択は別々の操作です。ルールモードを選んだ後、現在の設定でプロキシ通信を担当するメインのポリシーグループを確認します。グループを展開し、サブスクリプション内の利用可能な出口か、設定済みの自動選択グループを選んでください。グループで「DIRECT/直結」が選ばれていると、システムプロキシを有効にしても、そのグループに一致するリクエストは直接接続される場合があります。スイッチがオンになっているだけで、すべての通信がリモートの出口を通るとは判断しないでください。

ポリシーグループをたどって最終的な選択先を確認

「日常用プロキシ」から「自動選択」へつながり、さらに複数の出口から経路を選ぶ設定もあります。このような階層を見つけても、すべてのグループを変更する必要はありません。現在選択されている項目を順にたどり、最終的にサブスクリプションで提供される利用可能な出口へつながることを確認します。サイトの種類ごとに分かれた個別のポリシーグループは、初回はサブスクリプションの初期値を維持してください。特定のアクセスだけ出口が想定と異なると分かった場合に、そのグループを調整します。

クライアントに接続テスト機能があれば、一度手動で実行して、明らかに利用できない選択肢を除外できます。テストに成功しても、その時点で指定されたリクエストが完了したことを示すだけで、すべてのサイトにアクセスできるとは限りません。また、遅延の数値はダウンロード速度を表しません。すべて失敗する場合は、サブスクリプションの状態、端末の時刻、現在のネットワークを確認してください。モード、DNS、コアを次々に変更するのは避けましょう。複数の条件を同時に変えると、原因を特定しにくくなります。

この手順の完了時には、現在ルールモードを使っていることと、プロキシ通信のメインのポリシーグループで何を選んでいるかを把握できている状態が目安です。「ルール」「ポリシーグループ」「自動選択」の違いは用語集で、ルールの評価順序やプロトコルの選び方は技術資料で確認できます。選択内容はそのままにして、次の手順ではアプリの通信をクライアントに取り込む設定だけを行います。

ステップ3:コアを起動して接続を有効化

コアの動作を確認してからシステムプロキシを有効化

クライアントのホーム画面または設定画面に戻り、コアが正常に動作しているか確認します。設定の有効化後にコアが自動起動するバージョンもあれば、起動操作が必要なバージョンもあります。使い始めるためにテスト用コアへ切り替える必要はありません。まずは現在の安定版を使ってください。ポートの競合、設定の読み込み失敗、コアの停止が表示された場合は、ログを開いて該当するエラーを解決します。コアが起動していない状態でシステムプロキシを有効にすると、ブラウザーが応答のないローカルサービスへ接続しようとすることがあります。

正常に動作していることを確認したら、「システムプロキシ」を有効にします。OSのプロキシ設定が変更され、その設定に従うアプリのリクエストがローカルのコアへ送られます。まずは一般的なブラウザーで次のテストを行います。ブラウザーにプロキシ拡張機能や手動のプロキシ設定がある場合は、一時的に無効にして設定の競合を防いでください。「LAN内の接続を許可」は有効にする必要はありません。この設定は主に他の端末からこの端末のプロキシを利用するためのもので、初回のインターネット接続に必須ではありません。

システムプロキシを有効にした後は、クライアントをバックグラウンドで動作させておく必要があります。メインウィンドウを閉じたときにトレイへ最小化されるか、アプリが終了するかは設定によって異なります。初回の動作確認中はウィンドウを開いたままにしてください。通常アクセスできていたサイトが突然開けなくなった場合は、まずシステムプロキシをオフにして通常のネットワークが復旧するか確認し、その後でコアの状態とポリシーグループを調べます。システムがローカルプロキシを参照している間に、プロセスを強制終了しないでください。

ブラウザーで接続を確認してから、必要に応じてTUNを有効化

すべてのアプリがシステムプロキシ設定に従うわけではありません。ブラウザーでは想定どおりアクセスできるのに、特定のデスクトップアプリの接続ログが表示されない場合は、TUNの利用を検討します。TUNは仮想ネットワークインターフェースを使って通信を取り込みます。サービスのインストール、管理者権限、システムのネットワーク許可が必要な場合があります。クライアントの案内に従って必要な設定を行い、他のVPNや仮想ネットワークアダプターを使うツールが同時に通信を制御していないことを確認してから、TUNだけを有効にして再度検証してください。ネットワークスタック、自動ルート、DNSはクライアントの推奨値のままにし、別の端末のスクリーンショットをそのまま真似る必要はありません。

システムプロキシで必要な通信ができているなら、TUNは無効のままで構いません。両方を有効にする必要があるかはクライアントの実装と利用するアプリによって異なり、「両方オン」を接続成功の基準にしないでください。モバイル端末では通常、接続をタップするとシステムのVPN許可画面が表示されます。使用中のクライアントからの要求であることを確認して許可し、アプリに戻って接続状態を確認してください。デスクトップのシステムプロキシとモバイルのVPN状態は仕組みが異なるため、同じものとして扱うことはできません。接続機能を有効にした後は、画面上の接続表示だけでなく、実際のリクエストで動作を確認します。

ステップ4:ウェブページ、ルール、実際の出口を確認

新しいリクエストを送信して接続ログを確認

ブラウザーで、アクセス権があり現在のルールではプロキシを使うはずのサイトを開き、ページを再読み込みします。すでに開いているタブはキャッシュによって新しい接続が発生しない場合があるため、それだけで確認しないでください。次にクライアントの「接続」画面へ戻り、アクセスした時刻に近いリクエストの対象ドメインを探して、適用されたルール、ポリシーグループ、ポリシーチェーンを確認します。表示項目はバージョンによって多少異なりますが、リクエストがコアに届き、想定したポリシーに渡されていることが重要です。

ページが開き、接続ログにも想定したプロキシポリシーが表示されていれば、そのアクセス経路はおおむね正常です。次に、設定上は直結されるはずの日常的なサービスにもアクセスし、ログで直結ポリシーが適用されているか確認します。ルールモードの目的は設定に応じてリクエストを振り分けることであり、すべてのログをプロキシ表示にすることではありません。外部のIPアドレス確認サービスを使った場合、その結果はそのリクエストの出口を推測する補助情報にすぎません。一つのIPアドレスだけで端末上のすべてのアプリが通信を取り込まれているとは判断できません。

「通信の入口 → ポリシー → 出口」の順に確認

ページが開かず、接続画面にも該当するリクエストがない場合は、まずブラウザーがシステムプロキシに従っているか、プロキシ拡張機能が設定を上書きしていないか、システムプロキシが有効かを確認します。アプリがシステムプロキシを使わない場合は、ブラウザーで接続できることを確認したうえでTUNを試してください。リクエストがまだコアに届いていないため、この段階で出口を変えても解決しないことが多いです。ただし、リクエストがすぐに終了すると接続一覧に記録されないこともあるので、ログも合わせて確認します。

接続記録があるのに適用されたポリシーが想定と異なる場合は、ステップ2に戻って現在の設定、モード、ポリシーグループを確認します。確認している設定が実際に有効化されているものか確かめ、適用されたルールも確認してください。ポリシーは正しいのにエラーが続く場合は、ログで接続タイムアウト、名前解決の失敗、ハンドシェイクエラーを確認します。変更する要素は一度に一つにし、たとえばポリシーグループ内の出口だけを変更して同じURLを再試行します。一つのリクエストを調べるために設定全体を書き換える必要はありません。

「ブラウザーは使えるが、他のアプリは使えない」場合は、アプリのプロキシ対応と通信の取り込み方法を確認します。「すべてのアクセスに失敗する」場合は、まず通信の取り込み機能をオフにして通常のネットワークを確認してください。DNSやネットワークスタックの詳しい確認はトラブル対処で行えます。初期設定の段階で複雑な項目を変更する必要はありません。プロキシを使うべきリクエストと直結するべきリクエストがそれぞれ想定どおりなら、現在の設定を維持して初回の動作確認は完了です。

設定完了後:サブスクリプションの更新と安全な終了

初回接続が成功してからサブスクリプション画面に戻り、必要に応じて自動更新を有効にします。更新間隔はサービス提供元の推奨に従えばよく、頻繁に手動更新する必要はありません。更新後は、現在の設定が引き続き選択されているか、選択していた出口が名称変更や削除によって変わっていないかを確認してください。更新成功はダウンロードと解析の完了を示すもので、すべての出口が実際のアクセスで確認済みという意味ではありません。

普段は「設定を確認 → モードを確認 → ポリシーグループを確認」の順にチェックします。問題が起きたら、クライアントを何度も再インストールするより、同じリクエストを再現してログを確認するほうが役立ちます。他の人に相談する際は、OS、クライアント名、エラーが発生した手順、必要部分を伏せたログを共有できますが、サブスクリプションURL、認証情報、不要なアクセス記録は必ず隠してください。

プロキシを使わないときは、まずシステムプロキシをオフにします。TUNを有効にした端末ではTUNもオフにしてから、クライアントを終了してください。これにより、設定が残ってその後のネットワーク接続に影響する可能性を減らせます。基本設定の後にプロトコルの違いやコアの互換性を確認する場合は技術資料、設定名の意味を調べる場合は用語集、インストールや接続でよくある問題はよくある質問を参照してください。