構成は文書です。レコードは出口です。同じ一度の貼り付けではありません。

構成ファイルは端末上の文書です。よくある内容は、一般オプション（DNS、IPv6、ポートなど）、ルールリスト、ときにリライトと復号ホストのリストです。サーバーレコードはファイルに出ることも、アプリのサーバー一覧にだけ生きることもあり、取り込み方次第です。「アプリを入れれば使える出口が付いてくる」と思わないでください。ストアのライセンスにサーバーは含まれません。

手書きまたは外部ファイルのルール段の構文は ルール です。リライト段は リライト です。DNS 関連のオプションは DNS です。三ブロックは同じ文書に書かれても、実行時は三つの仕組みです。先に振り分け、必要ならリライト、名前解決の方針は常に貫きます。

ss:// を丸ごと「構成 URL」に貼る、または構成ファイルを「サーバーアドレス」に貼ると、オブジェクトのマスが違います。保存はできます。そのあとの失敗を「ノードがダメ」では説明できません。

アプリは複数の構成を同時に保存でき、それぞれに名前を付けられます。現在の構成を切り替えると、リストとオプションがまとめて置き換わります。FINAL が二つ重なるのではなく、「こちらの GEOIP とあちらのドメイン行」が自動で組み合わさるのでもありません。

構成を切り替えても変わらないのは、今ハイライトされているレコード、スイッチがオンか、Data カウンタの数字です。だから「新しいリストに替えたのに、ページが変わらない」ように見えます。ポリシーが実際は Proxy で、エンジンは新しいファイルを読んでいません。先にポリシーを見、それから選ばれているのがどれかを見てください。

二つの構成が同じソースを購読し、更新時刻だけ違うと、一覧は「だいたい同じ」ファイルが二つあるように見えます。今チェックされている 1 つが基準です。一方を編集しても他方には書き込まれません。ただし実際に同じ購読 URL を指し、次の更新でローカルの変更が上書きされる場合は別です。

取り込み経路は通常、ファイル、クリップボード、URL です。URL 型の構成はサーバーコンテナと同じです。保存するのはアドレスで、取得が成功してから対向の内容でローカル文書を置き換えます。失敗時は直前に成功したファイルを残し、失敗のためにルールを空にはしません。

起動時の更新、バックグラウンド更新は、この取得の繰り返しです。バックグラウンドは、システムがこのアプリのバックグラウンド更新を許しているかにも制約されます。システム を見てください。更新はそのときのネットワーク経路を通ります。スイッチが失効したレコードに繋がっていると、構成の購読自体も失敗し得ます。ポリシーを Direct にする、または先にスイッチを切るのは、経路を隔離することです。

書き出しで得られるのは、ルール、オプション、ファイルに書いた認証情報を含む文書です。秘密として扱ってください。別の端末に渡す前は、中にパスワードと UUID があると仮定してください。

外部リストは FINAL と GEOIP を先に読み、使うかを決めます。著者は自分の出口に合わせて書いています。ある場所のノード向けに書かれたリストを、別の場所のノードで使うと、無関係な要求が大量にノードへ入ります。逆なら、指名されていないトラフィックはすべて直通です。ルールページの「外部ファイル」を見てください。

アカウントシステムはありません。開発者サーバーはあなたの一覧を預かりません。iCloud を許すと、同じ Apple ID の端末同士で構成とレコードを同期できます。Apple アカウントの同期であり、Shadowrocket アカウントではありません。

同期が衝突するとき、同じ購読型構成を二台で同時に大きく編集しないでください。次の更新は URL の戻り値を基準にし、端末の変更は上書きされます。リストを凍結するなら、購読しないローカルファイルとして書き出し、それを編集します。

iCloud を切る、または Apple ID を替えても、開発者へ「ログアウト」は自動では起きません。もともと無いからです。端末上のファイルは、アプリを消すか文書を消すまで残ります。アプリを消すと、バックアップしていない構成も消えます。ストアのアプリを入れ直しても、iCloud か自分の書き出しが残っていなければ、ノードは戻りません。