改寫

改寫改的是請求長什麼樣，不決定走哪條路。

規則回答 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 看規則，最後才輪到改寫和腳本。同時開啟外來腳本與外來規則，歸因成本會成倍增加。