サブスク URL は「設定」ではなく認証情報として扱う
Clash や mihomo で使うサブスクは、単なる設定ファイルのアドレスではありません。多くの配布サービスでは、URL のクエリ部分に契約者を識別するトークンが含まれており、その URL を知っている人はノード一覧や設定内容を取得できる場合があります。したがって、サブスク URL はパスワードや API キーに近い秘密情報として扱うのが基本です。友人とのチャット、SNS、公開フォーラム、スクリーンショット、サポート掲示板などへそのまま貼り付けるのは避けてください。
とくに注意したいのは、ブラウザのアドレスバーや Clash のプロファイル画面を撮影した画像です。URL の末尾だけを隠したつもりでも、履歴、通知、ファイル名、QR コード、設定バックアップの中に同じトークンが残っていることがあります。サポートへ相談する際は、ドメイン名や HTTP ステータスだけを残し、ユーザー ID、トークン、メールアドレス、契約番号、ノード名などをマスクしてください。サブスク URL を短縮 URL に変換する方法も、短縮サービス側に元の URL が記録されるため、安全対策としては推奨できません。
URL の入手元も確認します。正規の契約ページから発行された URL なのか、第三者が配布する無料リンクなのか、古い設定を再配布したものなのかで、信頼性は大きく異なります。見知らぬサイトからダウンロードした Clash クライアントに URL を入力すると、アプリ自体がクリップボードや設定ファイルを読み取る可能性もあります。まず公式リリースや信頼できる配布ページからクライアントを用意し、その後に契約先の管理画面から URL をコピーする順序にすると、原因の切り分けがしやすくなります。
Clash へ安全に取り込む手順
取り込み前に、現在使っているプロファイルをバックアップします。バックアップにはサブスク URL が含まれることがあるため、デスクトップや同期フォルダーへ無造作に置かず、アクセス権を限定した保存場所を選んでください。共有 PC、会社の端末、クラウドへ自動同期されるフォルダーでは、設定ファイルを保存した後に誰が読める状態なのかを確認します。バックアップを作成したら、元ファイルを直接編集するのではなく、Clash Verge、Clash Verge Rev、Mihomo Party、Clash for Android など、手元のクライアントにある購読またはプロファイル管理画面から追加します。
メニュー名はクライアントごとに異なりますが、作業の考え方は共通です。まず「プロファイル」「Profiles」「購読」「Subscriptions」のいずれかを開き、追加または URL インポートを選択します。次に、提供元から受け取った URL を貼り付け、表示名には「自宅用」「仕事用」など、秘密情報を含まない名前を付けます。貼り付け後に画面上で URL 全体が常時表示される場合は、作業が終わったら画面を閉じ、クリップボードの内容も上書きしておくと安心です。
取り込みが完了したら、いきなり TUN やシステムプロキシを有効にするのではなく、最初にプロファイルの形式とノード数を確認します。YAML として解釈できているか、プロキシグループが生成されているか、空の設定になっていないかを見てください。ノード名が表示されても、接続が正常とは限りません。設定の取得に成功したことと、実際の通信が成功することは別の段階です。まず Clash の接続ログで、プロファイル取得、DNS 解決、テスト接続がそれぞれ完了しているかを順番に確認します。
- 公式または契約先の管理画面からサブスク URL を取得する。
- 現在のプロファイルと設定を、秘密情報として安全な場所へバックアップする。
- Clash のプロファイル管理画面へ URL を登録し、意味のある表示名を付ける。
- 設定の解析、ノード数、プロキシグループ、ルールの読み込み結果を確認する。
- 短い通信テストを行い、問題がなければシステムプロキシや TUN を段階的に有効化する。
自動更新の間隔と更新失敗を管理する
サブスクは一度読み込んで終わりではなく、ノード、ルール、証明書、ポート、提供元の都合によって内容が変わります。そのため自動更新は便利ですが、短すぎる間隔に設定すると提供元へのアクセスが集中し、レート制限や一時的な拒否を招くことがあります。更新間隔は契約先の推奨値を優先し、特別な理由がなければ数時間おき、または一日一回程度から始めます。更新のたびに手作業で YAML を編集すると、次回更新で変更が消えるため、恒久的に使いたい設定はローカルオーバーライドや別のルールファイルへ分離します。
更新に失敗したときは、すぐに URL を何度も再試行しないでください。まず、前回成功した時刻、最後に更新できた時刻、表示された HTTP ステータス、Clash のエラーメッセージを記録します。404 は URL のパス変更や契約終了、403 は認証失敗やアクセス制限、429 は短時間の過剰アクセスを示すことがあります。5xx なら提供元側の障害や中継サーバーの問題も考えられますが、DNS、システムプロキシ、TUN、別 VPN の競合でも似た表示になるため、ステータスだけで断定しないことが重要です。
| 症状 | 確認する項目 | 避けたい対応 |
|---|---|---|
| 読み込みが空になる | URL の有効期限、契約状態、レスポンス形式 | バックアップなしで古い設定を上書きする |
| 403 が返る | 認証トークン、アクセス元制限、時刻ずれ | URL を公開掲示板へ貼って相談する |
| 429 が返る | 更新頻度、複数端末での同時更新 | 短時間に連続リロードする |
| 更新後だけ接続できない | ノード変更、ルール変更、コアとの互換性 | 原因を確認せずコアや全設定を同時に変える |
更新後に接続できなくなった場合は、旧プロファイルを一時的に有効化して差分を見ます。旧設定でも接続できないなら、ノード品質、ネットワーク、Clash コア、OS 側のプロキシ設定を疑います。旧設定だけ動くなら、提供元が配布した新しいノードやルールとの互換性を確認します。Mihomo 系の機能を前提にした設定を、古いコアや別実装のクライアントへ読み込むと、未知のキー、プロキシグループの欠落、ルール構文エラーが発生することがあります。更新と同時にクライアント本体まで交換するのではなく、一つずつ変更してください。
リンク流出・期限切れ・提供停止への備え
サブスク URL が流出した疑いがある場合、最初に利用端末をすべて確認します。Clash Verge とスマートフォン版 Clash for Android の両方で同じ URL を使っているなら、片方だけ削除しても問題は解決しません。契約先の管理画面に接続履歴、利用量、端末数、再発行機能がある場合は、異常な利用がないか確認します。URL の再発行後は、古い URL を各クライアント、ブラウザの履歴、パスワード管理ツール、メモアプリ、バックアップから削除し、新しい URL を必要な端末だけへ登録します。
期限切れは、更新ボタンを押せば必ず直る問題ではありません。契約更新後も古いトークンが残っている場合、提供元が新しい URL を発行している場合、端末の時計が大きくずれている場合、HTTPS 証明書の検証に失敗している場合があります。OS の日時を自動設定に戻し、Clash のログで DNS エラー、TLS エラー、HTTP エラーを分けて見ます。設定ファイルの中に期限や更新時刻が書かれていても、それを手作業で書き換えるのは避けてください。サーバー側の契約状態と一致しないため、正常化の根拠にはなりません。
提供元が停止した場合は、同じ URL を別のアプリで試しても復旧しません。複数のクライアントで同時に失敗し、契約先のサイトやサポートも応答しないなら、提供元側の障害またはサービス終了を疑います。反対に、一台の端末だけ失敗するなら、ローカル DNS、プロキシ経路、証明書ストア、コアのバージョンを調べます。障害確認のために不審な代替リンクを探すより、契約記録と公式連絡先を確認し、必要なら新しい提供先を正規の手続きで選ぶ方が安全です。
Clash V.CORE を使う場合も、サブスクの安全性はクライアントだけで自動的に保証されるものではありません。改造版や出所不明の GUI は、更新 URL の保護、ログの扱い、設定ファイルの保存場所が不透明になりやすく、一般的な VPN アプリの一部は細かな Clash 互換設定やログ確認が不足することがあります。その点、Clash V.CORE はサブスクをプロファイルとして整理し、更新結果、接続ログ、ルール、ノード選択を一つの運用手順で確認しやすい構成を目指せます。URL を秘密情報として保管しながら、更新と障害切り分けを自分で管理したい方は、正規の入手元から Clash V.CORE をダウンロードして試すとよいでしょう。
// エディターズ・チョイス
安全な購読管理を Clash V.CORE で
サブスク URL の取り込みから更新失敗の確認まで、プロファイルと接続状態を整理して扱えます。
- 購読プロファイルを分けて管理
- 更新結果と接続ログを確認
- ノードとルールを段階的に検証
- Windows・macOS・Android に対応
- 自動更新の間隔を見直しやすい設計