設定の実践 · Clash 技術ブログ

Clash Verge Rev：プロファイル名が auto に戻る原因と対処

Clash Verge Rev でサブスクリプションを更新すると、手動で付けた名前が auto に戻りますか？対象の自動ビルドと名前の取得元を確認し、バックアップ後に名前を編集して自動更新を一時停止します。再起動と次回の更新で確かめ、設定と元に戻す手段を残します。

本文を読むブログへ戻る
  • Clash Verge Rev
  • auto
  • サブスクリプションの名前
  • 自動更新
  • 設定のバックアップ
目次
公開日
読了時間の目安
約 8 分

仕事用と普段用のサブスクリプションに名前を付けたのに、更新後にどちらのカードも auto になると、設定自体が置き換わったように見えます。まず変わったのがカード名、サブスクリプションの内容、現在の選択のどれなのかを確かめ、アプリの完全なバージョンを確認しましょう。改名だけのために、使えるサブスクリプションを削除する必要はありません。

更新後に auto と表示される。サブスクリプションは消えた？

プロジェクトの #8365 には、v2.5.9+autobuild.1020.9dd5aa6 でサブスクリプションを更新すると名前が auto になるとの報告があります。報告された環境は macOS です。メンテナーは #8360 のリモート名更新の変更と関連付けていますが、この報告だけで全プラットフォームや正式版にも影響すると判断はできません。

一方、#8348 は逆の要望です。v2.5.8 のユーザーが、サブスクリプションの更新時にサーバー側の名前も反映してほしいと求めています。両者は異なるバージョンの動作についての報告であり、後者を v2.5.8 でも手動の名前が上書きされる根拠にはできません。

まず何が変わったのかを見分ける

見えている変化最初に行うこと
カード名だけが変わり、配信先、ノード、選択状態は元の設定に対応している名前の上書きとして調べます。削除して再インポートしないでください。
ノードやルールも変わった、または別のカードが選ばれている実際に更新された内容と選択中の設定を確認します。改名ではこれらの違いを直せません。
表示名は変わらず、サーバー側で変えた名前が反映されない利用中のバージョンを記録します。新しい自動ビルドが手動の名前を上書きする問題とは別です。

なぜ名前にアドレス末尾の auto が使われる？

対象のコミットでは、リモートサブスクリプションの更新時に、新しく取得した名前を既存の設定へ書き戻します。確認した実装は応答の content-disposition を参照し、この応答ヘッダーがなければ、サブスクリプション URL のクエリパラメーターを除いた末尾の部分から名前を取得するため、auto や main と表示されることがあります。

この表示名は、ポリシーグループ名やノード名とは別です。カードの改名はサブスクリプション URL の変更ではなく、ノードの認証情報が置き換わったことも意味しません。ただし更新自体は設定内容を取得するため、選択中の設定と実際のリクエストは別途確認してください。

まずアプリ内で完全なバージョンを記録してください。v2.5.9 の部分だけで判断したり、自動ビルドを正式リリースとして扱ったりしないでください。この記事の対象は報告された特定のビルドと固定コミットです。後続のビルドでも同じ動作になるかは、そのリリース情報と実際の更新結果で確認します。

その後、上流では #8366 により名前を書き戻す変更が取り消されました。取り消しの固定コミットは 27d8a71 です。ソース上の取り消しによって、インストール済みのパッケージに修正が自動で届くわけではありません。今回確認した最新の正式版は v2.5.8 のままであり、すべてのプレビュービルドを修正済みとは呼べません。

バックアップしてからカード名を戻す

対象カードの元の名前、配信元、選択状態、自動更新のスイッチを記録します。サブスクリプション URL には認証情報が含まれることが多いため、記録はローカルに保管してください。スクリーンショットや報告ではパス内の認証情報とクエリパラメーターを隠し、完全なアドレスを名前に含めないでください。

独立したバックアップを作る場合は、「設定 → Verge詳細設定 → バックアップ設定」でローカルバックアップを作成し、「View history」を開きます。記録行の「Export Backup」で別の場所へ保存し、ファイルが読み取れることを確認してください。アプリのデータフォルダー内にバックアップを作っただけでは、エクスポートしたことにはなりません。

対象のサブスクリプションだけに必要な変更を行う

  1. 実行中の更新が終わるのを待つ

    まず対象のサブスクリプションが更新中ではないことを確認します。定期更新を無効にしても、送信済みのリクエストは強制的には取り消されません。更新が終わる前に改名すると、その更新で再び上書きされる可能性があります。

  2. 「情報を編集」を開く

    「プロファイル」ページで対象カードを右クリックし、「情報を編集」を選びます。「プロファイルを編集」ウィンドウでサブスクリプション URL が記録と一致することを確かめ、「名前」だけを変更してください。「ファイルを編集」と取り違えたり、カードを削除したりしないでください。

  3. 必要なら自動更新を一時停止する

    対象ビルドで名前を一時的に保つには、同じウィンドウの「Allow Auto Update」をオフにして保存します。元の更新間隔とスイッチの状態は記録しておいてください。実行中だった更新が終わってから、名前が正しいままかを再確認します。

  4. 再起動後に対象の設定を確認する

    アプリを通常の手順で終了して開き直し、名前、対象カード、選択状態を確認して、普段使うウェブサイトやアプリを試します。表示名を変えるために、設定の全削除、コアの切り替え、DNS の変更をする必要はありません。

自動更新の一時停止は次の上書きを減らすためのもので、命名処理自体の修正ではありません。手動で「更新」を押すとリモート設定を取得するため、名前が再び変わる場合があります。停止中は提供元の新しいノードも自動では届かないので、問題が解決したら元の更新設定に戻してください。

サーバーから識別しやすい名前を返すには？

他者が管理するサブスクリプションなら、提供元に、対象ビルドでは更新時にリモートの名前が使われることと、現在の応答に識別できる content-disposition があるかを確認してください。機密情報を隠した現象とバージョンを伝えれば十分です。公開 issue に完全なサブスクリプションアドレスを載せないでください。

サブスクリプションサービスを自分で管理している場合は、サブスクリプション内容を返す HTTP 応答ヘッダーに適切なファイル名を指定します。この項目をサブスクリプション YAML に書くものではありません。下の例は応答ヘッダーの場所と形式だけを示しています。既存のバックエンドでの設定方法は、そのバックエンドの文書に従ってください。

サブスクリプション配信の HTTP 応答ヘッダー例（YAML 設定ではありません）
content-disposition: attachment; filename="work-profile.yaml"

変更後はクライアントが実際に受け取った名前を確認し、同じサブスクリプションが更新されていることも確かめます。表示までにファイル名の解析や整形が行われる場合があるため、サーバーのどこかに名前を設定しただけでクライアントにも届いたとは断定できません。表示名のために、認証情報を含む URL を独断で変更しないでください。

再起動と次回の更新で結果を確かめる

設定を保つか決める前に確認すること

  • 対象カードの配信元、現在の選択、元の名前、更新スイッチを別途記録してある。
  • 保存して通常どおり再起動しても名前が正しく、使うサブスクリプションやノードを取り違えていない。
  • 同じウェブサイトやアプリへの新しいリクエストが完了する。名前の復元と接続の正常性は別々に確認する。
  • 自動更新を一時停止した場合、画面の状態と記録が一致している。手動更新後に再び改名された場合は、一時的な対処には制約が残ると記録する。
  • サーバー側の名前や後続ビルドでの動作を確認できたら、元の自動更新設定に戻し、次回の更新と通常の再起動で確かめる。

手動更新で比較する前に記録を残し、中断できないリクエストは一時停止してください。サブスクリプションの更新で現在の設定が再読み込みされる場合があるためです。更新前後の名前、バージョン、時刻、実際の内容を記録します。一度再起動して名前が変わらなかっただけで、更新時の上書きが直ったとは言えません。

上書きが続く場合は設定を残してバージョンを確認する

今回の名前とスイッチの変更を取り消すには、記録に従って元の値へ戻し、元のサブスクリプションと使える設定を保ちます。上書きが続いて識別しにくい場合は、上記の短期的な手動確認を使いながら、メンテナーによる明確な対処を待ってください。削除と再インポートを繰り返して解決を期待しないでください。

アプリのバージョンを変える必要がある場合は、現在のデータと独立したエクスポート済みバックアップを保管し、プロジェクトの正式なリリース元で対象バージョンを確認します。この記事ではバージョン間のデータ互換性を検証していません。唯一のデータフォルダーを別バージョンで直接上書きせず、ダウングレードすれば必ず直るとも考えないでください。

バックアップ全体の復元はアプリのデータを上書きして再起動するため、表示名だけを変える際の最初の手段には適しません。復元が本当に必要なら、現在の状態を別途保存し、バックアップの出所と対応バージョンを確認したうえで、アプリの復元手順に従い、すべてのサブスクリプションと選択を検証してください。

報告にはアプリの完全なバージョン、OS、手動改名の有無、自動更新の状態、更新前後の名前、機密情報を隠した応答ヘッダーの状況を添えます。後続の修正は具体的なコミットとリリース記録で判断してください。issue が閉じられただけでは、インストール済みのバージョンに修正が含まれるとは確認できません。

参考資料