目次
データのダウンロード先を変える目的はルールの復旧ですが、サブスクリプションを正しく編集しても、アプリがそのアドレスを使うとは限りません。リソース画面の設定は複数の設定ファイルに影響する場合があります。変更するファイルの種類、有効なアドレス、元の使えるコピーを確認してから、元に戻せる形で更新します。
サブスクリプションの geox-url を変えても、別の Geo データがダウンロードされるのはなぜ？
v0.8.99は最終設定の生成時に、geox-urlをアプリ設定のgeoXUrlアドレス一式で置き換えます。そのため、サブスクリプションに記入した四つのアドレスがコアに渡るとは限らず、サブスクリプションだけを変更しても反映される保証はありません。以下の調査のために報告者のブランチをインストールする必要はなく、未マージの変更を正式な修正とみなすこともできません。
サブスクリプションのgeox-url、FlClashのリソース設定、最終設定を比較します。信頼できるミラーがサブスクリプションにしかなく、プレビューには別のアドレス群が表示され、リソースのダウンロードやルールの読み込みが失敗し続ける場合は、繰り返し更新せずに三か所の違いを記録してください。
公式リポジトリの issue #2642 は v0.8.99 の Linux AppImage でこの現象を報告し、Android でも再現するとしています。今回の確認時点で管理者が確認した修正版はありません。特定版のソースに基づく調査と一時復旧方法であり、すべての Geo エラーが同じ原因とは限りません。
最終設定のアドレスがすでに正しい場合は、ダウンロード先への到達性、データ形式、ルールが参照するカテゴリの有無を調べます。当サイトの v0.8.98 の記事で扱ったファイルサイズや時刻の表示更新とも別の問題です。画面のファイル情報が更新されても、ダウンロード元の優先順位が変わったとは限りません。
変更すべきリソースと、元のルールに合うデータを確認する
Profile、アプリ設定、現在使えるリソースをバックアップし、リソース画面の各 URL を記録します。次に、エラーが示す Geo ファイルの種類、ルール、カテゴリを確認し、FlClash の完全なバージョン、システム情報、元のテストリクエストを記録してください。サブスクリプションの認証情報や元のバックアップは端末内に保管します。
リソース画面の MMDB、ASN、GEOIP、GEOSITE は、それぞれ異なる設定フィールドに対応します。必要な項目だけを変更し、データの管理者が公開した一次情報で内容と形式を確認してください。ダウンロードできるというだけで、同じファイルを四つの項目に設定してはいけません。
リソース項目とフィールドの対応
| リソース画面の項目 | geox-url のフィールド | 確認する内容 |
|---|---|---|
| MMDB | mmdb | GeoIP 用の MMDB 系データ。v0.8.99 のデフォルトアドレスが指すファイル名は geoip.metadb です。 |
| ASN | asn | ASN データ。デフォルトのファイル名は GeoLite2-ASN.mmdb で、国別分類のファイルでは代用できません。 |
| GEOIP | geoip | GeoIP 用の dat データ。デフォルトのファイル名は geoip.dat です。 |
| GEOSITE | geosite | ドメインのカテゴリデータ。デフォルトのファイル名は geosite.dat です。 |
Mihomo の geodata-mode は、GEOIP に dat と MMDB のどちらを使うかを決めます。URL の調査中は元のモードを保ち、ダウンロードを成功させるためだけに切り替えないでください。独自のデータにも元のルールが参照するカテゴリが必要で、欠けているとダウンロードに成功してもルールを読み込めない場合があります。
ミラーを変えると、ダウンロード速度だけでなくデータの内容も変わる可能性があります。検証済みで、同じデータソースを配信するミラーを優先してください。配信元がファイルのチェックサムを公開している場合は、対応するバージョンの値と照合します。ログインページ、共有ページ、拡張子が似ているだけのエラーページを Geo データとして扱わないでください。
リソース画面でアドレスを変更し、同期が完了するまで待つ
v0.8.99 は現在の URL を入力欄に表示し、送信するとアプリ全体の geoXUrl を更新します。端末で共有するリソース設定なので、他の Profile にも影響します。元のサブスクリプションに戻すだけではアドレスは戻りません。
以下は v0.8.99 のリソース編集・同期メニューに沿った説明で、表示名は言語によって異なります。元の値を残し、信頼できて形式も合う完全な HTTPS 取得アドレスだけを入力してください。未確認のミラーは使わず、証明書検証やセキュリティソフトを無効にしないでください。
復旧が必要なリソースだけを変更する
現在の URL を保存する
FlClash のリソース画面で対象を探し、その項目の追加メニューから編集を選びます。編集欄の元のアドレスをローカルの記録へコピーし、項目が geox-url の対応するフィールドと一致するか確認してください。もともと独自アドレスでも、全体を残します。
新しい信頼できるアドレスを確定する
同じ項目の編集欄に目的のアドレスを入力して確定し、アプリの設定更新を待ちます。編集欄と最終設定のプレビューを開き直し、値が変わったことを確認してください。
対象項目を同期する
対象項目のその他メニューで同期を選び、更新を一度だけ開始します。更新中の表示が終わるまで待ち、エラーやスキップの通知、ファイル情報を確認してください。
再読み込みしてルールを確認する
アプリの通常の操作で現在の設定を再適用し、必要に応じてプロキシを通常の手順で停止してから起動します。元のリクエストで該当ルールへの一致と実際の経由先を確認し、ほかによく使う Profile も確認してください。
同期の呼び出しが戻っても、コアがリクエストを受け付けたことしか示しません。完了や失敗は後続のイベントで通知されるため、クリック直後に更新成功と判断しないでください。ファイルサイズと時刻は補助的な証拠です。内容が変わらない場合や更新がスキップされた場合は変化しないこともあるため、完了状態、ルールの読み込み、実際のリクエストを確認します。
編集した値を保存できない場合は、同期の繰り返しをやめ、エラーを記録します。アドレスは正しく保存されたのにダウンロードが失敗する場合は、現在のネットワークから配信元へアクセスできるか、リダイレクト先がデータファイルのままか、ログに形式やカテゴリのエラーがないかを確認してください。無関係なリソースの変更は続けないでください。
リソースの URL とルールを確認し、問題が残る場合は元のリソース設定に戻す
復旧後の確認リスト
- リソース画面と最終設定で対応する URL が一致し、サブスクリプションの元の内容だけで判断していない
- 同期による更新が終了し、ダウンロードや解析のエラーが未処理で残っていない
- 現在のデータにルールが必要とするカテゴリが含まれ、該当ルールを正常に読み込める
- 同じ実際のリクエストが想定したルールに一致し、想定した経由先を使う
- 通常の操作で終了して再起動しても URL が正しく、ほかによく使う Profile に影響がない
失敗した場合は、同じリソース項目の編集欄に控えておいた URL を戻し、同期して元の使える設定を再適用します。ダイアログのリセットはアプリのデフォルト値へ戻す操作です。もともと独自のアドレスを使っていた場合、リセットしても元の設定には戻りません。
URL を戻しても、置き換わったデータファイルは自動では復元されません。元の配信元にアクセスできる場合は、元のデータを再同期します。配信元にもアクセスできない場合は、現在のファイルと端末内のバックアップを保管し、更新をいったん見合わせてください。アプリ設定を復元する前にバックアップの内容を確認し、Geo ファイルも含まれるとは決めつけないでください。互換性のないファイルを手作業で組み合わせたり、設定をすべて消去したりしないでください。
それでもルールを読み込めない場合は、問題の設定を無効にし、使えることを確認済みの Profile を選びます。アプリ全体のリソースは引き続き共有されるため、切り替え後も検証してください。使える設定がない場合は、通常の操作でプロキシを停止して一般のネットワーク接続を確認し、プロキシの利用が必須の作業はアクセスを見合わせます。
上流へ報告する際は、完全な版、システム、匿名化した元の値と最終 geox-url、リソース項目、更新状態、最初のエラー、再起動後のルール一致結果を提供します。分類名と項目構造は残し、サブスクリプションの認証情報、私用ミラーの認証情報、個人のアドレスを隠してください。