改写

改写改的是请求长什么样，不决定走哪条路。

规则回答 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 与这里的改头对它们都无效。

改写条同样有顺序：先命中的一条生效。把更具体的模式写在更宽的前面，与规则相同。注释、空行的处理以应用内编辑器为准。

外来配置往往附带一长串改写。不需要内容级修改时，可以只保留规则、停用改写，减少「同一个主机有时正常有时被跳走」的来源。

主机名、SNI、目的地址，规则在不开解密时就能用。改写如果只动 URL 的明文部分或某些头，也不一定要打开 HTTPS 解密。

一旦要看或改 HTTPS 的路径与正文，就必须安装用户描述文件，让本机扩展成为中间人。这会改变这台设备的证书信任模型。代价、何时该卸掉，见系统。

解密未生效时，针对 HTTPS 正文的改写不会发生，连接可能直接失败。先关掉解密再访问：若恢复，问题在证书与清单，不在记录。不要为了让分流「更准」去开解密。

部分版本提供脚本，在请求或响应上做比一行替换更复杂的改写。它仍然不是规则引擎：它不负责 FINAL，也不能代替 Config / Proxy / Direct。

脚本失败时的表现是某一次请求异常，而不是开关弹回。对照顺序仍然是：Direct 看本地网，Proxy 看记录，Config 看规则，最后才轮到改写和脚本。同时打开外来脚本与外来规则，归因成本会成倍增加。