リライト

リライトが変えるのは要求の形であり、どの道を通るかではありません。

ルールが答えるのは DIRECT / PROXY / REJECT です。リライトは要求が見えたあと、URL の置換、リダイレクト、リクエストヘッダの変更をします。先に振り分け、それからリライトです。リライトで「ルールの代わり」をすると、Data とページ現象の両方を帰属できなくなります。

二つの仕組みが、たまたま同じ構成に書いてある

Config モードでは、エンジンは先にルールでこの接続の動作を決めます。REJECT の接続はリライトへは渡りません。すでに捨てられています。DIRECT と PROXY の接続がリライト条に当たったときだけ、リライト後の URL またはヘッダで続きます。

したがって、ページが開いているのが A サイトで、ルールは B と書いたつもりなら、先にルールが当たったかを見、次にリライトがパスを別の場所へ替えていないかを見ます。Data が教えるのはバイトが Direct か Proxy かだけであり、URL が何に変わったかは教えません。

ポリシーが Proxy または Direct のとき、ルールファイルはスキップされます。リライトがまだ実行されるかは、現在のバージョンとスイッチに依り、「振り分けを切ればリライトも切れる」とは仮定しないでください。切り分けで純出口だけ見るなら、リライトも先に止め、一度に残す変数は一つです。

URL: 当たったパターンでパスまたはホストを置換します。古いアドレスを新しいアドレスへ指す、あるパス断片を捨てる、ために使います。照合失敗はそのまま通り、FINAL へ自動では落ちません。FINAL はルールに属し、リライトには属しません。
リダイレクト: クライアントに別の URL を要求させます。ブラウザではアドレスバーの変化や二度目の読み込みに見えます。アプリが自分でリダイレクトを追わないと失敗を出し、ノードの問題のように見えます。
リクエストヘッダ: ヘッダ欄の追加、削除、書き換えです。要求に本当に HTTP ヘッダがあるときだけ意味があります。多くの長寿命接続、非 HTTP プロトコルにはこれらのヘッダがなく、ルールの USER-AGENT もここのヘッダ変更も、それらには無効です。

リライト条にも順番があります。先に当たった 1 条が効きます。より具体的なパターンを、より広いものの前に書くのはルールと同じです。コメントと空行の扱いは、アプリ内エディタに従います。

外部構成は長いリライトを付けることが多いです。本文レベルの変更が不要なら、ルールだけ残してリライトを止め、「同じホストがときどき正常、ときどき飛ばされる」の原因を減らせます。

ホスト名、SNI、宛先は、復号を開かなくてもルールで使えます。リライトが URL の平文部分や一部ヘッダだけを動かすなら、HTTPS 復号は必須ではありません。

HTTPS のパスと本文を見る・変えるには、ユーザプロファイルを入れ、端末上の拡張を中間者にする必要があります。この端末の証明書信頼モデルが変わります。代価と、いつ外すべきかはシステムです。

復号が効いていないとき、HTTPS 本文向けのリライトは起きず、接続がそのまま失敗することがあります。先に復号を切ってアクセスします。戻るなら、問題は証明書とリストであり、レコードではありません。振り分けを「正確にする」ために復号を開かないでください。

一部のバージョンはスクリプトを提供し、1 行置換より複雑なリライトをリクエストまたはレスポンスにします。それでもルールエンジンではありません。FINAL は担当せず、Config / Proxy / Direct の代わりにもなりません。

スクリプト失敗の現れは、ある一回の要求の異常であり、スイッチが戻ることではありません。切り分けの順は変わらず、Direct でローカルネット、Proxy でレコード、Config でルール、最後にリライトとスクリプトです。外部スクリプトと外部ルールを同時に開くと、帰属コストは倍増します。