ルールは先に名前を見るか、アドレスを見るかです。二つの DNS は二つの答えを出します。

端末自体にシステム DNS があります（通信事業者、ルータ、または設定に書いたサーバー）。Shadowrocket は構成で独自の DNS も指定でき、暗号化クエリも含みます。二つが同時にあるとき、あるクエリがどちらを通るかは現在の構成に従い、「二つの結果の平均」ではありません。

システム DNS とアプリ内 DNS が別の再帰を指し、同じ名前に別のアドレスを返すと、ルール内の GEOIP も動きます。同じホスト名が一度は CN に当たり、一度は FINAL に落ちます。ルールファイルが直されたのではなく、宛先が替わったのです。

切り分けでは一度に一箇所だけ変えます。先に Direct 下のシステム解決が動くようにし（ポータルページ、端末アクセス）、それからトンネルを開けます。アプリ内 DNS が誤り、または到達不能だと、解決に依存する要求はすべて失敗し、スイッチは点いたままです。レコードを何度も替えるより、Data でバイトがあるかを見るほうが速いです。

ブラウザは通常、ホスト名（Host / SNI）と解決済みアドレスの両方を持つので、ドメイン行もアドレス行も当たる機会があります。それでも上から先に当たった 1 行です。

アプリが IP に直接繋ぐ、または SNI を付けないなら、ドメイン行はすべて外れ、IP-CIDR、GEOIP、FINAL にしか落ちられません。すると「同じサイトで、Safari はプロキシ、あるクライアントは直通」になります。二つのプログラムがエンジンに渡した情報が違います。ルールページの「ホスト名はどこから来るか」を見てください。

SNI は example.com、実際に繋ぐのは CDN の別アドレス: ドメイン行は example.com で照合し、GEOIP は CDN アドレスで分類します。ドメイン行が GEOIP より前にあり、すでに当たっていれば、GEOIP は問われません。ドメイン行が外れれば、見えるのは CDN のライブラリであり、その名前の印象ではありません。

IP-CIDR,10.0.0.0/8,DIRECT は IPv6 を扱いません。端末が fd00:: またはグローバル IPv6 で同じサービスへ行くと、この行は当たらず、要求は GEOIP か FINAL まで落ちます。Wi-Fi が IPv6 を出し、セルラーが出さないと、同じルールは二つの網で違って見えます。

二つのアドレス族を扱うなら IP-CIDR6 を足すか、使わないほうを設定で切ってください。アドレス族の問題を「同じドメイン DIRECT をもう 1 行」で直さないでください。ドメイン行は、「アドレスだけ、名前がない」要求には助けになりません。

一部の構成は、ドメインを先にローカルまたは偽アドレスの組へ解決し、トンネル内で本当の宛先に替えます。そのとき IP-CIDR / GEOIP が見るのは写像後のアドレスであり、サイトの公衆網上のアドレスではありません。GEOIP の国コード行はそうしたアドレスに意味がなく、結果はすべて他の行に落ちます。

リストが GEOIP に大きく依存し、解決方針を偽アドレスに替えると、振り分けは全体がずれます。解決モードを変えるのは、ルールが食べる入力を取り替えることであり、小さなオプションではありません。変える前に、固定レコードと Proxy ポリシーで出口自体が使えることを確認してください。Data です。

端末の hosts 型写像が影響するのは、書き出した名前だけです。書いていない名前は現在の DNS を通ります。写像表でルールファイルを代用しないでください。