Rewrite
Rewrite changes what the request looks like, not which path it takes.
Rules answer DIRECT / PROXY / REJECT. Rewrite replaces a URL, redirects, or changes headers after the request is already seen. Route first, then rewrite. Using rewrite to “replace rules” makes Data and the page both impossible to attribute.
01
Two mechanisms that happen to sit in one configuration
In Config mode, the engine first uses Rules to decide this connection’s action. A REJECT connection is not taken to rewrite — it has already been dropped. DIRECT and PROXY connections that hit a rewrite line then continue with the rewritten URL or headers.
So: the page opens site A and you thought the rule wrote B — see whether the rule hit first, then whether rewrite swapped the path somewhere else. Data only tells you whether bytes took Direct or Proxy; it does not tell you what the URL was rewritten to.
When policy is Proxy or Direct, the rule file is skipped. Whether rewrite still runs depends on the current version and switches; do not assume “turning routing off also turns rewrite off.” To look at a pure exit, stop rewrite too, and leave one variable at a time.
02
What can usually be changed
- URL
- Replace path or host by a matched pattern. Used to point an old address at a new one, or to drop a path segment. A failed match passes through unchanged; it does not fall to FINAL — FINAL belongs to rules, not to rewrite.
- Redirect
- Makes the client request another URL. A browser shows an address-bar change or a second load. An app that does not follow redirects reports failure, which looks like a node problem.
- Request headers
- Add, delete, or rewrite header fields. Only meaningful when the request actually carries HTTP headers. Many long-lived connections and non-HTTP protocols have none of these headers; USER-AGENT in rules and header rewrite here are both no-ops for them.
Rewrite lines also have order: the first hit takes effect. Put the more specific pattern above the wider one, same as rules. How comments and blank lines are treated follows the in-app editor.
Imported configurations often ship a long rewrite list. If you do not need body-level edits, keep the rules and disable rewrite, to cut one source of “the same host is sometimes fine, sometimes jumped away.”
03
Seeing HTTPS content takes a second permission
Hostname, SNI, and destination address work in rules without decryption. If rewrite only touches the cleartext part of a URL or some headers, HTTPS decryption is not always required either.
Once you need to see or change an HTTPS path and body, you must install a user profile and let the on-device extension become a man in the middle. That changes this device’s certificate trust model. Cost, and when to remove it, are in System.
If decryption is not in effect, rewrites aimed at HTTPS bodies do not happen, and the connection may fail outright. Turn decryption off and visit: if it recovers, the problem is the certificate and the list, not the record. Do not turn decryption on “to make routing more accurate.”
04
Scripts are for rewrite, not for routing
Some versions offer scripts that rewrite a request or response with more than a one-line replace. That is still not the rule engine: it does not own FINAL, and it cannot replace Config / Proxy / Direct.
A script failure shows up as one request going wrong, not as the switch snapping back. Isolation order is still: Direct for the local network, Proxy for the record, Config for rules, and only then rewrite and scripts. Opening an imported script and an imported rule file at once multiplies attribution cost.