Clash Nyanpasuのよくある質問

Clash Nyanpasuは設定やプロキシを管理するGUIクライアント、mihomoはプロトコル接続、DNS解決、ルール適用を担うコア、サブスクリプションサービスはサーバー情報や設定を提供するサービスです。クライアントをインストールしただけでは、利用可能な接続先は手に入りません。信頼でき、有効期限内のサブスクリプションか、自分で用意したサーバー設定が必要です。接続できない場合は、画面上の設定が反映されていないのか、コアが動作していないのか、サブスクリプション内のサーバーが利用できないのかを切り分けてから、該当箇所を確認してください。

ルールモードでは、現在の設定にあるルールの順序に従い、接続ごとにDIRECTまたはプロキシグループを選択します。普段使いの基本として適しています。グローバルモードでは、コアに届いた接続をグローバル選択で指定した出口に送りますが、パソコン上のすべてのアプリが制御されるわけではありません。DIRECTモードでは通常、コアに届いた接続が宛先へ直接アクセスします。モードを切り替えても、システムプロキシやTUNの設定は変わりません。アプリの通信がそもそもコアに届いていなければ、どのモードにしても出口は変わりません。

使えません。インストーラーはOSとプロセッサのアーキテクチャに合ったものを選ぶ必要があり、Windows用の実行ファイルをmacOS、Linux、スマートフォンでそのまま使うことはできません。ダウンロードページに各プラットフォーム向けのクライアントが掲載されていても、すべてのクライアントが全プラットフォームに対応しているとは限りません。まず端末のシステム情報を確認し、対応するものを選んでください。スマートフォンでは、サブスクリプションで使われているプロトコルや設定項目にクライアントが対応しているかも確認が必要です。デスクトップの設定は移行時の参考になりますが、ローカルパス、待ち受けアドレス、権限、TUNの項目などは調整し直すことがよくあります。

サブスクリプションURLは設定内容を取得するためのアドレス、YAMLは一般的な設定ファイル形式で、両者は別物です。URLによってはプロキシ、プロキシグループ、ルール、DNSを含む完全な設定が返されます。一方、ノード情報だけが返され、クライアントやサブスクリプションサービス側での変換が必要な場合もあります。インポート前にサービスの説明で対応形式を確認し、URLの見た目だけで判断しないでください。サブスクリプションURLには認証情報が含まれることがあるため、トラブル対処時にURL全体を公開したり、見知らぬオンライン変換サイトに入力したりしないでください。

普段使いには、クライアントが提供する、現在の設定と互換性のあるStable版をおすすめします。Alpha版は新機能や修正の検証向けで、動作が今後変更される可能性があります。名称が新しいという理由だけで切り替える必要はありません。新しい設定項目やプロトコル機能が必要な場合は、まずコアのリリースノートを確認し、設定をバックアップしてからテストしてください。切り替え後に起動できなくなったら、最初に表示された設定エラーを確認して元のコアに戻します。コアごとに対応する設定項目は異なり、切り替えても設定が自動変換されるわけではありません。

インポートが成功したというのは、内容が保存されたことを示すだけで、設定が有効になったわけではありません。まず設定一覧で追加した項目を選び、コアが正常に起動していることを確認します。次にプロキシ画面で、実際に使うプロキシグループに利用可能な出口を選択してください。普段はルールモードとシステムプロキシを有効にするところから始めます。システムプロキシを使わないアプリには、必要に応じてTUNを検討します。最後に、確実にアクセスできるサイトを開き、接続ログを確認してください。ログに何も表示されない場合は、サブスクリプションやノードを何度も入れ替えるのではなく、まず通信を取り込む方法を見直してください。

まずサブスクリプションの期限切れ、リセット、URLのコピー漏れがないか確認し、ログでリクエスト失敗と解析失敗を切り分けます。リクエスト失敗なら、端末のネットワーク、証明書、サーバーの応答を確認してください。解析失敗なら、ログイン画面やエラーページが返されていないか、クライアントが対応していない形式ではないかを確認します。サービス提供元が特定のUser-Agentを指定している場合は、その説明に従って設定してください。YAMLを手動編集した場合は、インデントと値の型も確認が必要です。対処中は古い設定を残し、まだ使える接続先を失わないようにしてください。

まずTUNを無効にし、通常のプロキシ方式で接続できることを確認します。そのうえで、利用中のクライアントの説明に従ってサービスモードをインストールまたは有効化し、システムの確認画面が表示されたら必要な権限を許可してください。Windowsではサービスが動作しているか、セキュリティソフトがネットワークアダプターのコンポーネントをブロックしていないかを確認します。ほかのOSでは補助サービスやネットワーク拡張の許可を確認してください。複数のプロキシクライアントを同時に起動し、仮想ネットワークアダプターを取り合う状態にしないでください。それでも失敗する場合は、ログの最初のエラーを保存し、競合するアプリを終了してから再試行します。正体の分からないアダプターを削除したり、システムのルートを変更したりするのは避けてください。

必ずしも必要ではありません。システムプロキシは、OSのプロキシ設定に従うアプリをローカルのプロキシポートに接続します。まずブラウザーで動作確認するのに適しています。TUNは仮想ネットワークインターフェースを通じて、ルーティング条件に合う通信を取り込みます。システムプロキシ設定を参照しないアプリでよく使われますが、追加の権限と適切なDNS設定が必要です。設定によっては両方を併用できますが、トラブル対処ではまず片方だけを有効にしてください。それぞれ単独で正常に動作することを確認してから、必要に応じて組み合わせます。ルート、ポート、名前解決の問題を混同しないようにしましょう。

まずサブスクリプションの取得元、自分で管理している設定、オーバーライドやマージルール、カスタムDNS、ポート、コアの選択をバックアップしてください。クライアントのエクスポートまたはバックアップ機能を使い、復元方法も確認します。設定フォルダーをコピーする場合は、ファイルへの書き込みが終わるよう、先にクライアントを終了してください。サブスクリプションの自動更新で直接編集した内容が上書きされることがあるため、継続して使う変更は対応するオーバーライド機能に記述します。バックアップにはサブスクリプションの認証情報やサーバーのパスワードが含まれる場合があります。安全な場所に保管し、公開の問い合わせに添付しないでください。

現在の設定が対応するオーバーライド機能またはルール編集画面で、対象ドメインのDIRECTルールを、該当する可能性がある広範なルールより前に配置し、ルールモードを維持します。ドメインサフィックスのルールは該当するサブドメインにも適用されるため、変更範囲を確認してください。保存して設定を再読み込みしたら、既存の接続を閉じるか該当アプリを再起動し、接続ログで一致したルールと実際の出口を確認します。ブラウザーでページが開くかどうかだけでは判断しないでください。キャッシュ、接続の再利用、アプリ独自のプロキシ設定が結果に影響する場合があります。

まず、その接続が実際に変更したプロキシグループに一致しているか確認してください。設定にプロキシグループが入れ子になっている場合、外側で自動テストグループを選んでも、実際のノードは内側のグループによって決まります。確立済みの接続は選択を切り替えてもすぐに移行しないことが多いため、古い接続を切断するかアプリを再起動してからテストしてください。グループの種類が自動選択なら、テスト先、間隔、タイムアウトの設定を確認します。テスト結果が示すのはその条件での到達性であり、すべてのサービスが同じノードで同様に動作するとは限りません。

遅延テストで測定するのは、通常、指定されたテスト先への応答時間です。利用可能な帯域幅とは異なり、動画サイトやダウンロードサーバーの速度を直接示すものでもありません。回線の混雑、サーバー側の速度制限、接続先の場所、パケットロス、プロトコルのオーバーヘッドなどが実際の速度に影響します。近い時間帯、同じネットワーク、同じ用途でノードを比較し、接続ログで想定した出口が使われているか確認してください。一度の最小遅延だけで結論を出すのではなく、継続して通信したときの安定性も参考にしましょう。

サブスクリプションからダウンロードしたファイルを直接編集すると、次回の更新で新しい内容に置き換わることがあります。継続して使うルールには、クライアントの現在のバージョンが対応するオーバーライド、マージ、スクリプト処理の仕組みを使い、適用順も確認してください。変更後は手動での再読み込みとサブスクリプション更新をそれぞれ試し、最終的に有効な設定に目的のルールが残っているか確認します。サブスクリプション内でプロキシグループ名が変わると、既存の参照が無効になることもあります。グループが見つからないエラーが出たら、古いファイルに戻すだけでなく、ルール側の参照も確認してください。

Fake-IPは、ドメイン名との対応付けに使う仮想アドレスをアプリに返し、コアがその対応情報に基づいて接続を処理する仕組みです。通信を取り込む際にドメイン名を保持しやすくなります。ただし、DNSの問題をすべて解決する機能ではありません。DNSの待ち受け、通信の取り込み、上流DNSの設定も適切にする必要があります。LAN内のサービスや実アドレスに依存するアプリでは、例外設定が必要な場合があります。変更後は関連するキャッシュを消去して接続し直し、ログと実際の名前解決経路を確認してください。検査ページに特定の地域が表示されたことだけで、設定の正しさや情報漏えいを判断しないでください。

まずプロキシを無効にして基本のネットワーク接続を確認し、システム時刻が正確かも確認してください。次に設定が有効か、サブスクリプションの期限が切れていないか、コアのログにエラーがないかを調べます。すべてのノードが同時にタイムアウトするなら、DNS、テスト先への到達性、ネットワーク制限、コアの停止など、共通する箇所を優先して確認します。特定のノードだけ失敗する場合は、そのサーバーを調べてください。信頼できる別のネットワークでも比較し、速度テストのボタンだけに頼らず実際のアクセスも試します。問い合わせ時はエラーの発生時刻と個人情報を除いたログを共有し、サブスクリプションURL全体は公開しないでください。

まずクライアントの接続ログに、そのアプリからのリクエストが表示されるか確認してください。表示されない場合は、システムプロキシのアドレスとポートがコアの実際の待ち受け設定と一致しているか、ブラウザーの拡張機能、アプリ独自のプロキシ、ほかのVPNが設定を上書きしていないかを確認します。システムプロキシを参照しないアプリもあるため、個別にプロキシを設定するか、必要性を確認したうえでTUNを使います。接続がコアに届いているのにDIRECTになる場合は、一致したルールとプロキシグループを確認してください。システムプロキシが有効と表示されていても、すべてのアプリがプロキシ経由になるとは限りません。

AppContainerで分離された一部のUWPアプリは、ループバック接続の制限により、端末上のプロキシポートに接続できないことがあります。まずデスクトップブラウザーが正常に使えることを確認し、問題のアプリがこのケースに該当するか調べてください。クライアントにUWPのループバック制限を解除するツールがある場合は、必要なアプリだけを例外に設定し、案内に従って管理者権限を許可します。Windows標準のCheckNetIsolationで例外を管理する方法もあります。すべてのアプリに一括で権限を許可しないでください。それでも解決しない場合は、アプリがシステムプロキシに対応しているか確認するか、TUNでの通信取り込みを検討します。

まずシステムのプロキシ設定が、すでに待ち受けを停止したローカルアドレスを指していないか確認し、残っている手動プロキシ設定を無効にします。次にTUN、サービスモード、ほかのVPNが動作中でないかを確認し、正常に停止してからネットワークに再接続してください。DNSを手動で変更していた場合は、現在のネットワークに適した設定に戻し、キャッシュを更新します。最初からすべてのネットワークアダプターをリセットしたり、ルートを削除したりしないでください。社内ネットワークやほかのソフトに影響する可能性があります。基本のネットワーク接続を復旧したら、クライアントを再起動して機能を一つずつ有効にし、設定の残存箇所を特定します。

まずTUNを無効にして比較し、通信の取り込みが原因か確認します。次に現在の設定で、LANアドレス、プライベートネットワーク、イントラネットのドメインがどのようにルーティング・名前解決されるかを調べてください。DIRECTにする宛先には正しいルールを適用し、イントラネットのドメインは名前解決できるDNSに渡す必要があります。プロキシルールだけを変えても、名前解決の誤りは直らないことがあります。社内VPNとTUNを同時に使うと、ルートが競合する場合もあります。実際のネットワーク範囲に合わせて例外を設定し、広すぎるアドレス範囲をまとめて除外して、ほかの接続の出口まで変えてしまわないようにしてください。