取り込み前に確認:サブスクリプションURLか、単一ノードの共有リンクか
Clash Verge Revの「プロファイル」画面では、設定ファイルを管理します。リモートサブスクリプションは、設定内容を返すURLです。クライアントがそのURLにアクセスして設定をダウンロードし、コアに読み込ませます。サブスクリプションサービスはノードと関連設定を提供し、クライアントはそれを取得・解析して利用します。両者は別のものです。
まず、サービス提供元が指定するエクスポート形式を確認しましょう。「Clash」「Clash Meta」「mihomo」向けと明記されたサブスクリプションを優先し、現在のコアに対応していることも確認してください。Clash Verge Revはmihomoコアを使用しますが、あらゆるプロトコルのリンクや他クライアントの設定を、利用可能なYAMLに自動変換できるわけではありません。
https://で始まる:サブスクリプションURLの場合もあれば、アカウントページの場合もあります。利用できるかどうかは、アクセスして実際に返される内容で判断します。ss://、vmess://、trojan://で始まる:通常は単一ノードの共有リンクで、Clashの設定一式ではありません。.yamlまたは.ymlで終わるファイル:設定ファイルの可能性はありますが、拡張子だけでは内容が揃っているか、構文が正しいかは判断できません。- QRコード:テキストを格納する形式にすぎません。サブスクリプションURL、単一ノードのリンク、別のクライアントを起動する専用リンクなどが含まれている場合があります。
方法1:プロファイル画面にサブスクリプションURLを貼り付ける
リモートURLは、ノードの変更後も同じURLから設定を取得できるため、継続利用に適しています。操作前にURL全体をコピーしてください。Webページのボタン脇にある説明文を一緒に選択したり、疑問符以降のパラメーターを削除したりしないよう注意しましょう。
- Clash Verge Revを開き、左側の「プロファイル」画面に移動します。
- サブスクリプションURLの入力欄を見つけ、サービス提供元から案内されたClashまたはmihomo用のURLを貼り付けます。
- 「インポート」をクリックし、設定カードが作成されるまで待ちます。ボタンの位置はクライアントのバージョンによって異なる場合があるため、現在の画面に表示されている名称を確認してください。
- 取り込んだ設定カードを選択し、現在使用する設定にします。カードが表示されただけでは、切り替えは完了していません。
- 「プロキシ」画面を開き、グループとノードが表示されることを確認します。必要に応じてノードまたは自動選択グループを選んでください。
取り込み後は設定と通信をそれぞれ確認
まず、設定が読み込めるか確認します。ログにYAMLの解析エラーが繰り返し表示されたり、ポリシーグループが存在しないノードを参照したりしていないことを確認してください。次に、通信の経路を確認します。通常のブラウザーでは「システムプロキシ」を有効にする必要があります。システムプロキシに従わないアプリは、個別にプロキシを設定するか、TUNモードを使う必要がある場合があります。「Webページが開けない」ことだけを理由に、サブスクリプションの取り込み失敗と判断しないでください。
テスト時は、まず通信を制御する方式を1つだけ有効にして、トラブルの原因を絞り込みましょう。「接続」画面で、対象のリクエストに適用されたルールと使用されたポリシーグループを確認できます。ノードの遅延テストに結果が表示されても、それが示すのはテスト対象のリクエストだけです。すべてのWebサイト、プロトコル、アプリが正常に動作するとは限りません。
方法2:ローカルのYAML設定ファイルを読み込む
ローカルファイルは、オフラインでの移行、動作確認済み設定の保存、手書きルールの検証に便利です。「プロファイル」画面で「新規作成」またはファイル読み込みの項目を開き、ローカルを選んでファイルを読み込みます。項目名や操作手順はバージョンによって異なります。ファイルのドラッグ&ドロップに対応している場合は画面の案内に従ってください。すべてのバージョンで使える共通の方法とは限りません。
- 信頼できる配布元からYAMLファイルを入手し、テキストエディターで中身を確認します。ログインページやエラーメッセージ、ダウンロード手順の説明ではなく、設定テキストであることを確かめてください。
- 元のファイルを保管したうえで、
proxies、proxy-groups、rulesなど、必要な設定項目が含まれているか確認します。 - 読み込み後に設定を選択し、ログとプロキシ画面を確認します。解析エラーが発生した場合は、インデント、コロン、ポリシーグループ名を優先して確認してください。
ローカル設定には、定期取得できるリモートの配布元がないのが一般的です。サービス提供元がノードを追加したりパスワードを変更したりしても、古いファイルは自動で更新されません。新しいファイルを取得して読み込み直す必要があります。ファイル内にリモートのproxy-providersが設定されている場合、そのプロバイダーは個別の設定に従って更新できます。ただし、これはファイル内のリソース更新であり、ローカルファイル全体の置き換えではありません。
最小構成でYAMLの構造を確認する
次の最小サンプルは、項目とインデントを確認するためのものです。すべての通信は直接接続となり、プロキシノードは含まれていません。7897はサンプルの混合ポートです。実際の待ち受けポートは、クライアントの「設定」にあるポート設定と、最終的に適用された設定を確認してください。
mixed-port: 7897
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups:
- name: 手動選択
type: select
proxies:
- DIRECT
rules:
- MATCH,手動選択
YAMLではインデントで階層を表します。この例では半角スペース2つを使い、タブで代用することはできません。rulesで参照する「手動選択」は、ポリシーグループ名と一致させる必要があります。グループ名だけを変更してルールを変更しないと、参照エラーになります。リモートサブスクリプションのファイルは、クライアントの上書き設定の影響を受ける場合もあります。元ファイルを編集する前に、次回の更新で変更が上書きされないか確認してください。
方法3:QRコードを読み取り、内容を確認して取り込む
QRコードを使う目的はテキストを取得することであり、独立した設定形式ではありません。デスクトップ版にQRコードの読み取り機能がない場合は、スマートフォンやローカルのQRコード読み取りツールで内容を読み取り、信頼できる方法でサブスクリプションURLをパソコンに送ります。その後、「プロファイル」画面に戻って貼り付け、取り込んでください。トークンを含むQRコードを、見知らぬオンライン読み取りサイトにアップロードしないでください。
- 読み取った内容がHTTPSのサブスクリプションURL:ドメインがサービス提供元のものと一致することを確認し、URLの取り込み手順に従います。
- 読み取った内容が単一ノードのURI:サービス提供元の画面に戻り、Clashまたはmihomo向けのサブスクリプションをエクスポートしてください。単一ノードのURLをYAML設定一式として扱わないでください。
- 読み取った内容が特定クライアントを起動するリンク:対象のクライアントと操作内容を確認します。対応するプロトコルハンドラーがない場合、ブラウザーから起動できません。元のサブスクリプションURLを使ってください。
スマートフォンからパソコンにコピーした後、チャットアプリによるURLの切り詰め、改行や全角記号の混入、末尾の空白がないか確認してください。QRコードを読み取れたことは、テキストを取得できたというだけです。サブスクリプションが有効であることや、Clash Verge Revに適した形式で返されることを保証するものではありません。
YAMLとBase64の違い:設定構造とエンコード方式
Clash YAMLは階層構造を持つ設定テキストで、ノード、ポリシーグループ、ルール、DNSなどを記述できます。Base64はエンコード方式であり、プロキシプロトコルでも暗号化方式でもありません。一般的な「Base64形式のサブスクリプション」は、デコードすると複数行のノード共有リンクになります。通常、Clashのポリシーグループやルールを含む設定一式ではありません。
| 確認項目 | Clash YAML | 一般的なBase64形式のノード一覧 |
|---|---|---|
| テキストの形式 | 項目、コロン、インデント、リスト | エンコードされたテキスト。デコードすると複数行のURIになることが多い |
| ノードの定義 | 通常はproxiesまたはプロキシプロバイダーに記述 | 通常は各共有リンクに記述 |
| ポリシーとルール | proxy-groupsやrulesを含められる | 通常は別途作成が必要 |
| 読み込み時の処理 | コアが各項目とプロトコルに対応していることを確認して読み込む | 配布元からClash形式のエクスポートを入手する |
| プライバシー上のリスク | ノードのパスワードやリモートリソースのURLが含まれる場合がある | デコードすれば内容を読めるため、公開・共有しない |
拡張子を変更しても形式は変換されない
Base64のテキストをsubscription.yamlとして保存しても、proxiesやrulesは生成されません。同様に、ファイル名を.txtから.yamlに変更しても、構文エラーは修正されません。形式の判断基準は、ファイル名やダウンロードボタンのアイコン、URLの末尾ではなく、実際の内容です。
同じサブスクリプションサービスでも、エクスポート設定、リクエストパラメーター、User-Agentによって返される内容が異なる場合があります。ブラウザーではノード一覧が表示され、クライアントにはYAMLが返されても、必ずしも異常ではありません。サービス提供元が明示するClash用エクスポートURLを優先してください。変換が必要な場合は、信頼でき、データの取り扱いが明確なツールを選びましょう。変換サービスはサブスクリプションの機密情報にアクセスできるため、安易に送信しないでください。
更新間隔:リモート設定とプロキシプロバイダーを区別する
リモート設定の更新頻度は、設定カードの編集画面で指定します。一般的な手順は「プロファイル」→ 対象カードのメニューまたは右クリックメニュー →「編集」です。更新間隔の項目を探してください。名称や単位はバージョンによって異なる場合があります。入力前に単位を確認しましょう。単位が分の場合、360は6時間を意味します。秒の場合は、6時間を21600と入力します。別のバージョンの画面にある数値をそのまま使わないでください。
まずは6時間ごとに設定し、サービス提供元の案内に応じて調整するとよいでしょう。ノードに短期間で変更がなければ、毎分取得する必要はありません。更新頻度が高すぎると、リクエストが制限される場合があります。手動で一度「更新」を実行して結果を確認し、自動更新が想定どおり動作するかも確認してください。自動更新には通常、クライアントの起動とネットワーク接続が必要です。パソコンの電源が切れているときやスリープ中に、通常のオンラインタスクと同じように実行されるわけではありません。
proxy-providersのintervalは秒単位
mihomoの設定では、HTTPプロキシプロバイダーの更新間隔をintervalで指定できます。単位は秒です。たとえばinterval: 3600は、プロバイダーの内容を1時間ごとに取得する設定です。この設定は該当プロバイダーにのみ適用され、リモート設定全体を1時間ごとに再ダウンロードすることを意味しません。プロバイダーのヘルスチェックには別の間隔があり、ノードのテストに使われます。サブスクリプションの更新と混同しないでください。
取り込みに失敗したときの確認手順:リクエスト・内容・読み込み
- まずリクエストが成功しているか確認します。接続タイムアウトの場合は、ネットワークとサブスクリプションのドメイン名解決を確認してください。HTTP
401または403の場合は、トークン、認証状態、サーバー側のアクセス制限を確認します。429はリクエスト過多を示すため、時間をおいて更新頻度を下げてください。続けてインポートをクリックしないでください。 - 次に返された内容を確認します。HTTP
200でも、ログインページやエラーページが返されることがあります。内容が<!DOCTYPE html>で始まる場合は、アカウントページのURLをコピーしていないか、認証ページにリダイレクトされていないか確認してください。 - 続いて設定の解析結果を確認します。YAMLの行番号エラーが出た場合は、該当行とその直前の行について、インデント、引用符、コロンを確認してください。非対応のノード形式が表示された場合は、待ち受けポートを何度も変更するのではなく、エクスポート先と現在のコアが対応しているか確認しましょう。
- 最後に設定が有効になっているか確認します。プロキシ画面に想定したノードが表示されない場合は、現在選択されている設定を確認し、まだ正常に取得できていないプロキシプロバイダーだけを参照していないか調べてください。
取り込み、更新、プロキシ接続はそれぞれ別の段階です。サブスクリプションのダウンロードに失敗している場合、TUNを有効にしても解決するとは限りません。ノードに接続できない場合も、同じ設定を再度取り込むだけでは改善しないことがあります。失敗した時刻、行った操作、ログの重要なエラーを記録し、設定を1つずつ変更して結果を比較してください。
最後に、設定カードが選択されていること、プロキシ画面に想定したポリシーグループがあること、手動更新が完了すること、実際のリクエストが接続画面で正しい経路を通っていることを確認しましょう。初めて使う方はクライアントの使い方ガイドで、システムプロキシと初回接続の手順も確認できます。