Shadowrocket下から二つ目のタブ構成（Config Files）が扱うのは振り分け設定であり、ノード一覧ではない。ローカルファイル（LOCAL FILES）でチェックの付いた一本が使用中。よくある名前はdefault.conf。開くとRuleの件数が見える。購読の更新はホーム（Home）のサーバー一覧だけを変える。この設定ファイルは自動では置き換わらない。
ルールと購読を同じメモに書き、足すときに購読（Subscribe）へ貼る人は多い。アプリはルール文を振り分けとは読まない。ルールは構成（Config）で取り込むか、リモート設定ファイルを購読する。ノード購読とルールファイルはどちらもリンクに見える。相手の表記を見て、混ぜて貼らない。
三語で足りる
PROXY：ホームで選んだノードを通す。プロキシが必要な行き先は、ここに落ちることが多い。
DIRECT：ノードを通さない。手元のサイト、LAN、速さを残したい Apple のサービスがよくここ。直連は「ルールが効いていない」ではなく、迂回するなという指定。
REJECT：捨てる。広告、追跡、端末に触れてほしくないドメインで使う。常用サイトを誤ってREJECTにすると、開かないのにノード遅延は普通に見える。ルール確認（Test Rule）がそれを暴く。
日常の使い方と、グローバルを使うとき
日常はルールモード。手元の通信とログインは DIRECT、プロキシが必要な行き先だけ PROXY。電池も持ち、銀行や決済を不安定なノードに載せにくい。グローバルはほぼ全部を今のノードに流す。電池を食い、もともと速い手元のアクセスを遅くしがち。
グローバルの正しい用途は対照であり、常時スイッチではない。グローバルは通り、ルールは切れるなら、ルールの問題であってノード死ではない。逆にグローバルも通らないなら、先にノードを替える。構成（Config）でファイルを重ねない。
ホーム（Home） の グローバルルーティング（Global Routing） が対照スイッチ。構成（Config） のファイルは変わらず、今の走法だけが変わる。試し終わったら戻す。手元のサイトが急に遅くなった理由を忘れないため。
ルール一式の検収
取り込みや更新のあと、手元のサイトを開く。直連に近いはず。次にノードを通すべき行き先を開く。両方遅いなら、手元までノードに乗っているか、ルールが手元のドメインを PROXY にした疑い。手元は速く、プロキシ先が動かないなら、前の記事どおりノードか許可を見る。
構成（Config）のルール確認（Test Rule）は、あるドメインが今どの方針へ行くかを見る。勘で当てない。問題のホスト名を貼り、PROXY、DIRECT、REJECTのどれかを読む。予想と違えばルールを直すか設定を替える。ブラウザを二十回更新するより速い。
ルールファイルは古くなる。远端の一覧が更新されないと、新しいドメインは誤った方針に落ちる。ルール更新とノード購読の更新は別作業で、構成（Config）とホーム（Home）。片方だけ更新して「Shadowrocketが壊れた」と判断しない。
何セットも同時に重ねない
リモート設定を何本も重ねると、条目がぶつかり合う。後から書いたものが、思った順では効かないことがある。切り分けはランダム故障に見える。ルールを替えるときは、今チェックが付いている一本を確認してから、それを更新するか別本に替えるかを決める。
このサイトは特定のルール倉庫を付けず、勧めもしない。信頼できる出所を使い、日付と説明を読む。出所不明の設定も、常用ドメインをREJECTへ打つ、またはプロキシすべきでない通信を全部PROXYへ送ることがある。
手書きルールはよいが、先は少なく変える。ルール確認（Test Rule）で一条を確かめてから範囲を広げる。一度に数十条を変えると、どこから戻すか分からない。
ノードとバックアップと並べて見る
ノードは「プロキシするとき、どの一台へ」を決める。ルールは「プロキシするか」を決める。ノードが無いと、ルールがどれほど明確でもPROXYに出口が無い。ノードは多くても、ルールがドメインをDIRECTへ打てば、「繋がっているのに使えない」と感じる。
機種変更では、ルールファイルとノード一覧の両方を持っていく。サーバーだけ書き出して構成（Config）を忘れると、新しい端末は初期設定に戻り、古い端末と動きが違う。バックアップ失敗に見える。データ（Data）の書き出しとiCloudは一部助ける。重要なファイルは自分でも残す。
構成（Config）で実際に見えるもの
構成（Config Files）を開くと、上はローカル、下にリモート購読の設定があることもある。有効な一本は左にチェック。default.confのようなファイルを開くとGeneralとRuleが見える。Ruleの件数は多い。一条ずつ読まなくてよい。要るのは更新、入れ替え、ルール確認（Test Rule）でドメイン一条を調べること。
リモート設定はアドレスを入れる。ノード購読の足し方に似ているが、入口は構成（Config）であり、ホーム（Home）のプラスではない。場所を間違えると、ホーム（Home）に妙な条目が増えるか、構成（Config）は何も変わらない。分からなければ相手の説明に戻る。server、購読、clash、confのどれか。このサイトはそれらのアドレスは出さない。
Apple自身のサービス、システム更新、一部の決済ページは遅延と証明書に敏感。直通できるなら直通。「全部プロキシ」のためにPROXYへ押し込まない。グローバル対照では一時的にそうしてよい。日常では不要。
ルールを変えたあと、古いページ接続は前の行き方のキャッシュのまま、ということがある。プライベート窓にするか、Shadowrocketのスイッチを一度切って入れ、それから検収する。変えた直後に、すでに開いている同じタブで結論を出さない。
ルールは多いほど良い、ではない。出所がはっきりして日付が新しい一本のほうが、互いに上書きするリモート三本より保ちやすい。今有効なのはどれか、言えること。言えなければ先は一本だけ残す。チェックのある一本に通信は従う。ホーム（Home）のノード一覧が綺麗かどうかは関係ない。
画面の対照はガイド：ルール。接続の対照はスイッチは入っているのに、ページが開かない。クライアントがまだならダウンロードから、App Storeだけ。
購読はノードの出所、ルールは通信の行き先。二手を同じ入力欄に詰め込まない。