目次
FlClash を v0.9.0 に更新すると、DNS ページにあった全体の上書きスイッチがなくなり、従来のカスタム上書きで使っていたプロキシグループやルールも見当たらなくなることがあります。旧版と同じ操作を続けると、設定を変えても期待した結果になりません。まず、それぞれの設定がどのプロファイルに適用されるかを確認し、移行方法を決めましょう。
更新後、従来の上書きスイッチや設定はどこへ？
v0.9.0 の正式なリリース情報には、DNS/NTP の上書きスイッチと従来のカスタム上書きを削除したことが明記されています。設定方法の変更なので、スイッチがないだけでサブスクリプションが無効になったとは判断できません。更新時にカスタム内容が新しい設定へ自動変換されるとも限りません。DNS はドメイン名をアドレスに変換し、NTP は時刻を合わせます。まず、自分がどちらを変更していたか確認してください。
この手順は、旧版から移行するデスクトップおよび Android ユーザー向けです。表示言語によって項目名は異なります。メニュー構成やバージョンが違う場合は、実際のバージョンを確認し、別のクライアントの操作をそのまま当てはめないでください。
使っているプロファイルの種類を確認する
| 変更したい内容 | v0.9.0 で適用される範囲 |
|---|---|
| URL・ファイルプロファイルの DNS | 全体の DNS ページで選んだ項目が、これらのプロファイルを上書きします。選んでいない項目は、元の設定とデフォルト値を使って引き続きマージされます。 |
| カスタムプロファイルの DNS/NTP | そのカスタムプロファイル内で設定します。DNS は最初の画面、NTP は「その他」にあります。全体の DNS ページもこれを上書きするとは考えないでください。 |
| 従来のカスタム上書きで使っていたグループとルール | 独立したカスタムプロファイルとして作り直す必要があります。新しいプロファイルは、現在のサブスクリプションに自動で重ねて適用されません。 |
更新前のバックアップと使える設定を残す
まだ更新していなければ、「ツール」から「バックアップと復元」を開き、「ローカル」で「バックアップ」を選びます。書き出したファイルはアプリのデータディレクトリ以外の場所にコピーしてください。元のサブスクリプションのアドレス、設定ファイル、カスタムのプロキシグループ、ルールとその順序も別に保存します。バックアップには機密のアドレスやアカウントが含まれるため、共有前に伏せてください。
従来のカスタム上書きのデータを移行すると、上書き用に保存されていたグループ、ノード、ルールが削除され、元のサブスクリプションは通常のプロファイルとして動作します。v0.9.0 で古いバックアップを復元した場合も、旧データの読み込みと移行が行われます。従来のカスタム上書きが戻るとは限りません。
更新済みで旧版のコピーがない場合は、まず現在の状態をバックアップし、まだ使えるサブスクリプションを残してください。データを削除したり、唯一のコピーを繰り返し上書きしたりしないでください。失われた値は、手元のファイル、スクリーンショット、独立したバックアップから探す必要があります。本記事で失われたルールを新たに復元することはできません。
更新前後に済ませる三つの確認
アプリのバージョンと現在のプロファイルを記録する
実際の FlClash バージョンを確認し、現在のプロファイル名、選択中のノード、プロキシモード、システムプロキシまたは TUN の状態を記録します。元の DNS と、残す必要がある NTP の値も保存してください。
バックアップが保存されたことを確認する
書き出したファイルを見つけて別の場所にコピーし、読み取れることとサイズがゼロでないことを確認します。元のバックアップは変更せず、以後のテストにはコピーを使います。アプリ内だけに存在する記録を、独立したバックアップとは扱わないでください。
途中で戻せる移行を計画する
プロジェクトの正式な Release から、使用するプラットフォームに合うバージョンだけを選びます。元のサブスクリプションを残し、更新後は項目ごとに移行してテストしてください。DNS、ルール、コア、すべてのプロキシスイッチを同時にリセットしないでください。
DNS の項目別上書きを解除して元の設定に戻すには？
全体の DNS ページで変更できるのは URL とファイルのプロファイルです。「ツール → 詳細設定 → DNS」を開き、上書き項目の追加で項目を選んで値を編集します。nameserver だけを変えるなら nameserver だけを追加し、ほかの項目は選ばないでください。
上書きを取り消すには、DNS ページからその項目を削除し、最終設定をもう一度確認します。値をデフォルトらしいアドレスに戻すだけでは、上書き自体は残ります。元のサブスクリプションの設定に戻ったとは判断できません。今回のテストを取り消せるよう、追加する前の項目を記録してください。
選んでいない項目でも、最終的なファイルがサブスクリプションと完全に同じになるとは限りません。実装ではデフォルトの DNS もマージされます。元の dns が有効になっていなければ、有効化、fake-ip、nameserver などのデフォルト項目が補われます。スイッチが消えたかどうかだけで判断せず、元の設定、選択した項目、最終設定を比較してください。
通常のプロファイルでは、プロファイルのメニューから「その他」→「最終設定」と進みます。カスタムプロファイルのメニューには「最終設定」が直接あります。dns 内の enable、enhanced-mode、nameserver が期待どおりか確認してください。サブスクリプションの原文を、現在動作している設定と取り違えないようにします。
DNS は毎回一項目だけ変更する
- 元の値と、元の選択項目一覧を保存します。
- 必要な項目を追加して値を編集し、最終設定に実際に反映されたことを確認します。
- 結果が違う場合は、今回追加した項目を削除し、最終設定と同じドメインへのアクセスを再確認します。
従来のカスタム上書きは独立したプロファイルとして作り直す
「プロファイル」→「プロファイルを追加」→「カスタム」と進みます。ここで作成するのは独立した Profile です。一覧で現在のプロファイルとして選べるのは一つだけです。空のカスタムプロファイルを作っただけでは、元のサブスクリプションのノード、プロキシグループ、ルールは自動で入りません。
新しいカスタムプロファイルでは、元の URL またはファイルのプロファイルにあるノードを参照できます。ただし、そのグループやルールはコピーされません。元のプロファイルを残し、必要なプロバイダーだけを参照してください。追加操作は下の手順で行います。
カスタム DNS を変更する場合は、そのプロファイル自身の DNS ページで設定します。NTP は「その他」から NTP を開き、選択した項目を設定してください。
作り直してから切り替える
新しいプロファイルに区別しやすい名前を付ける
元のサブスクリプションを使えるプロファイルとして残し、移行用のコピーを新規作成して名前を付けます。元のサブスクリプションは削除しないでください。新しいプロファイルを、元のものと同時に有効にできる上書き用の層とは扱わないでください。
プロキシグループ、ノードの参照、ルールを作り直す
新しいプロファイルのプロキシグループでノード選択を開き、ノードの追加からプロバイダーの分類にある元のプロファイル名を選びます。その後、元の記録からルールを作り直し、存在するグループを指定します。外部リソースのページは参照済みプロバイダーの確認・編集用であり、サブスクリプション全体のインポートには使いません。以前の値が見つからない、またはリソースを読み込めない場合は、元のサブスクリプションを使い続けてください。
内容の警告と最終設定を確認する
存在しないリソースの参照、設定エラー、空のグループを修正し、プロキシグループとルールの順序を確認します。NTP は選んだ項目だけをマージします。必要な項目と値は元の設定と照合してください。何も選んでいない状態を、従来の NTP 設定がすべて再作成された状態とは扱わないでください。
プロファイル一覧で新しいプロファイルを選ぶ
カスタム内容が揃ったことを確認してから、現在のプロファイルとして選び、実際の接続をテストします。一覧の選択中項目、最終設定、実際に使っているノードは、すべて同じ Profile に対応している必要があります。
切り替え、再起動、実際のアクセスで移行を確認する
画面で保存できたことやノードの遅延測定が正常なことは、操作の一部が完了したことしか示しません。移行を確認するには、同じプロファイル、ノード、対象ドメインで比較し、最終設定と接続ログを見て、もともと必要だったルールに一致するか確認してください。
全体の DNS 項目は URL・ファイルプロファイルに適用されます。その種類のプロファイルを複数保存している場合は、一つずつ切り替えて確認してください。カスタムプロファイルは別に検証します。最初のプロファイルで接続できただけで、他のプロファイルでもそれぞれの DNS の動作が保たれたとは判断しないでください。
移行後の確認項目
- 現在のプロファイル名とアプリのバージョンが正しく、元のサブスクリプションと独立したバックアップも残っています。
- 最終的な dns の enable、enhanced-mode、nameserver が、選んだ項目と元の設定から期待される値になっています。
- 普段使うドメインを名前解決でき、Web ページやアプリで実際のリクエストが完了し、ログに名前解決エラーや設定エラーが繰り返し出ていません。
- カスタムのプロキシグループに選択可能なノードがあり、重要なルールに正しく一致し、外部リソースへの参照も欠けていません。
- 他の URL・ファイルプロファイルに切り替えた後、全体の DNS が実際に与える影響を再確認します。カスタムの DNS/NTP はそれぞれ検証します。
- アプリを完全に終了して再起動しても、現在のプロファイル、選んだ項目、ノード、同じリクエストの結果が正常なままです。
移行に失敗したら、まず使えるサブスクリプションに戻す
現在のプロファイルを残しておいた元のサブスクリプションに切り替え、今回追加した DNS の上書き項目を取り消し、同じリクエストで確認します。TUN で接続できない状態が続くなら TUN を停止してください。以前の方法でシステムプロキシが使えていた場合だけ、一時的にそちらを使います。対象となる通信の範囲が違うため、TUN が直ったとは判断できません。
旧版に戻す必要がある場合は、まず新版での状態を保存し、プラットフォームに合う公式の旧版と、更新前のバックアップを使います。「ツール」→「バックアップと復元」から「ローカル」の復元へ進みます。以前のグループやルールを戻す場合は、「すべてのデータを復元」を確認してください。旧版が新版のバックアップやデータベースを読めるとは限りません。旧プログラムに唯一のデータを上書きさせないでください。
v0.9.0 で古いバックアップを復元しても移行は行われます。「すべてのデータを復元」を選んでも、従来のカスタム上書きが自動で戻るわけではありません。復元前にバックアップのバージョン、内容、復元方法を確認し、元のファイルを残してください。操作に失敗した場合は、同じコピーで現在の使える状態を繰り返し上書きしないでください。
信頼できる旧バックアップがなければ、元のサブスクリプションを使える状態に保ち、欠けている内容を一つずつ作り直すか、プロジェクトから明確な移行方法が示されるのを待ちます。報告するときは、実際のバージョン、プロファイルの種類、選んだ DNS/NTP の項目、機密情報を伏せた最終設定の一部と、最短のエラーログを添えてください。サブスクリプションの Token、アカウント、機密情報を含むバックアップ全体は送らないでください。
ここでのメニューと移行処理は、v0.9.0 の公式リリース情報、版を固定したソースコード、移行テストに基づいています。すべての環境で実機の更新を検証したわけではありません。メニューが異なる場合や移行後も問題が残る場合は、実際のログを保存し、プロジェクトの今後の回答に沿って対処してください。