効果的に問題を切り分けるには、変数を固定します。同じ設定でクライアントを変える、同じクライアントで設定を変える、同じ端末でネットワークを変える、という順に範囲を絞ります。一度に変更する条件は一つだけにし、エラーの発生時刻を記録することで、原因の所在を判断できます。最も再現しやすい組み合わせから始め、差異が出た時点でテスト範囲を広げるのを止めます。唯一変更した項目と、機密情報を伏せたログを、該当するプロジェクトまたは提供元へ提出してください。
三つの比較テストで、それぞれ何を除外できるか
三つの比較パターンを用意します。元の設定でクライアントを変える、元のクライアントで動作する設定へ変える、元の端末でネットワークを変える、という組み合わせです。各パターンでは一つの条件だけを変更し、結果を記録してください。
- 同じサブスクリプションを別の端末へインポートできるか
- 同じクライアントへ別の設定をインポートした場合は正常に動作するか
- 直接接続のネットワークからサブスクリプションのアドレスへアクセスできるか
- クライアントまたはシステムをアップグレードした後にエラーが起きたか
最小構成で、クライアント、設定、ネットワークのどこに問題があるか特定します
- まず現在の設定とログをバックアップします
- 最小構成で、一つのノードと一つの MATCH ルールをテストします（参照： 設定リファレンス）
- ネットワークまたはテザリング先を変え、サブスクリプションの更新とノード接続をテストします
- 特定のクライアントだけで失敗する場合は、バージョン番号を添えてクライアントのプロジェクトへ報告します（参照： クライアント一覧）
DNS、TUN、ルール、ノードを同時に変更すると、原因の特定が難しくなります
公開の場で報告する際は、説明だけよりも機密情報を伏せたログを添える方が有効です
サブスクリプション提供元の問題は、該当するサービスまたは設定の管理者へ問い合わせてください