Shadowrocket
規則與設定完整指南

設定檔結構與編輯入口

Shadowrocket 設定檔用來承載規則及相關運作設定，常見的文字檔副檔名為 .conf。它不是伺服器訂閱本身，也不等於 Home 中目前選取的伺服器。查閱規則前，先了解三者的分工：伺服器資訊說明連線目的地，訂閱用來彙整及更新既有伺服器項目，設定檔則定義請求應依哪些條件選擇處理方式。分別核對這些項目，才能避免把線路問題誤判為規則錯誤。

設定區段會決定後續各行的意義

方括號括住的標題是設定區段名稱，例如 [General] 和 [Rule]。區段名稱之後的內容都屬於該區段，直到出現下一個區段名稱為止。General 常見的是鍵值設定，Rule 使用逗號分隔的比對運算式，Host 用來指定主機名稱對應，URL Rewrite 則依請求網址執行改寫。即使兩項內容都與網域有關，也不能把 Host 對應或改寫運算式放進 Rule；解析器會先依區段判讀每一行，再讀取該行的參數。

[General]
bypass-system = true
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

[Host]
example.com = 192.0.2.10

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

上方片段僅用來說明區段邊界，不建議整段照貼。Host 中的位址是文件範例位址，無法用來連線至實際服務；重寫行也只是語法示範。正式修改時，請只取出目前問題所需的部分，放進自己的設定副本。若只要驗證網域分流，不必同時加入 Host 和 URL Rewrite，否則一次引入多個變數，即使結果改變，也難以判斷是哪項修改造成的。

先確認選取的設定，再開啟編輯

進入 Config 後，先確認目前使用哪一份設定，再檢視或編輯內容。清單中有某個檔案，不代表它已設為目前使用的設定；同名副本也可能來自不同的儲存位置。建議先記下設定名稱、來源，以及修改前某條重要規則的內容。儲存後回到 Config 確認選取狀態，避免把編輯副本誤當成已切換設定。介面入口位置請以裝置上實際顯示為準。

修改前先儲存一份可還原的副本，並使用容易辨識用途的名稱，例如「日常規則副本」。備份不能只靠記住幾行文字，因為原始檔案可能還包含策略群組、規則引用或其他 DNS 設定。若原設定來自可更新的來源，應先了解更新是否會覆蓋本機編輯內容；遠端更新與本機儲存並非同一個動作。重要修改應在更新後再次檢查，不要假設內容會永久保留。

文字格式與片段使用範圍

規則中的逗號、方括號與等號應使用英文半形字元。中文說明若寫在獨立註解行，可以使用中文標點；但若把中文逗號混進規則欄位，原本應分開的參數可能會被視為同一項。貼上片段後，請檢查行首與行尾，避免帶入排版用引號、清單編號或不可見空格。長規則在編輯器中自動折行，通常不代表實際換行；每條規則仍應各占一行。

本手冊中的程式碼區塊可能是獨立區段，也可能只是幾條待合併的規則。合併時應找到既有的對應設定區段，不要反覆新增同名區段；兜底規則也應集中管理。若原始檔案含有其他設定，不能只因本頁列出幾個區段就刪除其餘內容。先了解現有設定的用途再決定是否保留，才能減少因「整理檔案」而破壞原本正常運作的設定。

若還不清楚 Home、Config 與 Settings 各自的用途，可以先閱讀介面英文詞彙對照。編輯設定的目的不是讓檔案越短越好，而是讓每個區段的作用都能說明，每項變更都能還原。能明確指出目前使用的設定、修改位置與驗證目標，才適合繼續檢查比對行為。

General 與 Global Routing

General 用來設定一組通用運作選項，Global Routing 則決定目前採用哪種整體處理模式。兩者都會影響連線，但屬於不同層次。排查「規則沒有生效」時，先檢查 Global Routing，再檢查設定文字；若目前並非 Config，持續修改 Rule 可能不會得到預期結果。相反地，暫時切換模式後恢復正常，只能說明問題範圍有所變化，不能據此斷定伺服器或整份設定都沒有問題。

三種模式的查閱與驗證方式

表格使用「主要請求」一詞，是因為系統略過設定、區域網路條件及用戶端其他設定仍可能影響實際流量。Global Routing 不保證能覆蓋所有系統行為，也不等同於連線開關。切換至 Proxy 後仍需有可用的既有伺服器；切換至 Direct 也不代表目前網路一定能連上特定目標。進行比較時，請維持相同目標、相同網路並盡量在接近的時間測試，避免把外部變化誤認為模式差異。

在設定模式下，介面顯示的 Config 與設定區段 [Rule] 會共同參與分流；規則行末的 PROXY 則是該條規則指定的策略。三者名稱相關，但不能互換。將規則行末寫成 Config，並不會自動表示「依設定處理」；同樣地，介面選擇 Proxy，也不能證明某條 PROXY 規則確實命中。必須分別觀察整體模式與個別連線的處理結果。

認識兩項常見的 General 設定

[General]
bypass-system = true
dns-server = system

bypass-system = true 表示啟用與系統相關的略過行為。這是連線處理的邊界設定，不應視為特定網域策略的替代方案。若要保留現有預設值，應先從 Rule 查找一般流量的分流原因；只有明確懷疑系統流量或特定網路服務受到影響時，才將略過設定列為測試變數。任意切換可能同時改變多類請求，讓原本單一的問題更難重現。

dns-server = system 表示使用系統提供的 DNS 設定。此處的 system 是值，不是可任意換成中文說明的占位詞。系統 DNS 的結果可能隨 Wi-Fi、行動網路及其他系統網路設定而改變，因此「同一份設定換個網路後解析結果不同」不一定代表規則內容有變。若原設定指定了其他 DNS，請先記錄原值，再評估是否需要測試系統 DNS。

不要為了做出看似完整的設定而複製大量不熟悉的 General 參數。不同設定項目可能有前提關係，來自不同來源的片段也可能基於不同假設處理同一個問題。較穩妥的做法是保留可正常運作的基礎設定，針對明確的現象一次只修改一個參數，並記下修改原因。若裝置上已有相關選項，還需同時核對 App 內設定與目前設定檔，不能只憑檔案中是否出現某個鍵值來判斷實際行為。

連線開關、按需連線與規則各不相同

On Demand 負責在符合條件時觸發連線，不會取代網域規則。連線尚未建立時，檢查網域是否命中 Rule 無法解決授權或啟動問題；連線已建立但目標走錯路徑時，反覆調整 On Demand 通常也無法修正規則順序。應先確認 VPN 設定授權、連線狀態及目前網路，再檢查個別請求如何處理。如此才能分清「連線何時存在」與「連線中的流量如何選擇策略」。

首次連線時出現的系統提示與規則檔案屬於不同設定層，相關說明請見VPN 設定權限提示說明。若問題是背景觸發頻繁或耗電量改變，請參閱On Demand 與電池使用，不要用刪減 Rule 的方式處理所有背景狀況。不同層次的問題需要各自的證據。

完成 General 檢查後，應建立明確的運作基準：目前網路、目前設定、Global Routing、選取的既有伺服器，以及是否啟用 On Demand。之後測試規則時維持基準不變，新增規則與連線結果之間才有可解釋的關聯。

DOMAIN 網域規則

網域規則會依連線關聯的主機名稱選擇策略，不會依網頁標題、App 名稱或網址列中的完整文字比對。撰寫前先確認目標是單一完整主機名稱、整個網域及其子網域，還是名稱中含有特定片段的一組主機。這三種需求分別適合使用 DOMAIN、DOMAIN-SUFFIX 和 DOMAIN-KEYWORD。條件設得太寬會連無關請求也一併納入，設得太窄則可能只涵蓋頁面入口，漏掉實際載入資源所用的其他網域。

DOMAIN：指定單一完整主機名稱

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,static.example.com,DIRECT

第一條只適用於 api.example.com，不會自動延伸至 example.com 或 v2.api.example.com。第二條則示範同一主網域下的兩個主機可以採用不同策略。精確規則適合已確認的例外：例如大多數請求採用相同路徑，但某個主機需要另外處理。填寫欄位時，不要加上通訊協定前綴、路徑、查詢參數或連接埠，這些都不是 DOMAIN 主機名稱的一部分。

若記錄中顯示的請求主機不是預期的主機，請先確認重新導向與資源載入過程。輸入網址後，頁面可能接著連線至登入、圖片或 API 網域；為入口主機新增 DOMAIN 規則，不代表相關請求都會命中。應先查看失敗請求使用的主機，再決定是否新增規則，而不是根據網頁表面名稱擴大比對範圍。每新增一個網域，都應能說明它與故障的關聯。

DOMAIN-SUFFIX：涵蓋網域及其子網域

[Rule]
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

DOMAIN-SUFFIX,example.com,PROXY 用來比對 example.com 及其子網域。它會依網域邊界判斷後綴，不是單純搜尋任意字串，因此涵蓋範圍與 DOMAIN-KEYWORD 不同。上例先列出精確例外，再列出後綴規則，讓 local.example.com 使用 DIRECT，其餘符合條件的主機使用 PROXY。若將後綴規則放在前面，精確例外通常就沒有機會生效，因為前面的規則已經命中。

後綴規則不需要加上 *.，也不應寫成正規表示式。填入 example.com/path 無法表示「只處理這個路徑」，因為網域與路徑是不同的比對對象。若要涵蓋多個不相關的主網域，應分別撰寫規則，不要用過短的後綴取代。規則越符合實際網域邊界，之後查看記錄時越容易理解，也越不容易影響其他服務。

DOMAIN-KEYWORD：涵蓋範圍較廣的名稱片段

[Rule]
DOMAIN-KEYWORD,example,PROXY

DOMAIN-KEYWORD 會依網域是否包含指定片段進行比對。上例除了可能涵蓋 example.com，也可能涵蓋其他包含 example 的網域，因此不能把它當成 DOMAIN-SUFFIX 的簡寫。關鍵字越短，涵蓋範圍越難預測。若目標是由同一組織明確管理的網域，通常應優先考慮精確主機名稱或後綴；只有確實需要跨不同網域比對共同片段時，再評估使用關鍵字規則。

網域比對也取決於用戶端能否取得與連線相關的主機資訊。如果 App 直接使用 IP，或觀察記錄只顯示目標位址，就不能假設網域規則一定有可供比對的依據。此時應先確認連線記錄中能看到哪些資訊，再考慮位址規則，不要反覆新增同一網域的不同寫法。解析後的位址與原始網域也不一定永遠一對一。

驗證網域規則時，先選定一個明確的測試主機，關閉舊頁面並建立新請求，再檢查處理策略。瀏覽器快取、App 重複使用連線及背景請求，都可能讓舊結果持續存在。只有新的對應連線確實使用預期策略，才算驗證了這條規則；網頁能正常開啟只是其中一項結果，無法單獨證明規則涵蓋範圍正確。

IP、GEOIP 與請求條件

位址規則依目標 IP 或位址所屬資訊作為條件，適合處理明確網段、直接使用位址的連線，以及網域規則未涵蓋的後續分類。它不是網域規則的另一種寫法。一個網域可能對應多個位址，同一個位址也可能承載多個網域；只依位址分流可能影響使用相同位址的其他服務。因此，先用網域規則表達明確需求，再於適當位置補上位址規則，通常更容易控制範圍。

IP-CIDR：理解前綴，而非字串

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
FINAL,PROXY

CIDR 中斜線後的數字表示網路前綴長度，不是連接埠或位址數量。前綴越長，涵蓋範圍通常越小。上例列出常見的私有 IPv4 網段，但不代表你的區域網路一定會使用其中所有位址。撰寫規則前，應先確認裝置網路資訊中的實際環境；尤其連上組織網路或個人 VPN 時，目標位址可能不屬於目前 Wi-Fi 的本機網段。

單一 IPv4 位址可使用 /32 表示。不要只為了繞過某個目標，就把前綴從較長改成較短；這會同時改變大量位址的處理方式。若實際問題是找不到本機裝置，還應區分裝置探索所用的流量與後續連線。只新增一條私有網段規則，無法保證所有本機探索機制都會如預期運作。

IP-CIDR6 與 no-resolve 的適用範圍

[Rule]
IP-CIDR6,fd00::/8,DIRECT,no-resolve
IP-CIDR6,2001:db8::10/128,DIRECT,no-resolve

IP-CIDR6 用於 IPv6 位址，不能以 IPv4 規則取代。第二行使用文件範例位址，只示範單一位址的前綴寫法。裝置同時取得兩種位址時，同一目標的不同連線可能採用不同位址族；若只設定 IPv4 規則而未檢查 IPv6，就可能出現「有時套用這條規則，有時沒有」的狀況。應依實際連線記錄判斷，而不只是查看網域解析結果中的位址。

no-resolve 用來避免為了比對這條位址規則而額外觸發網域解析；它不代表系統停止 DNS，也不保證 App 不會進行解析。若連線目標本來就是 IP，仍可直接比對位址。若目前只有網域而沒有可用的位址資訊，這個選項可能讓位址規則無法如預期命中。測試前應先確認需求是「依已知位址判斷」，還是允許解析後再判斷。

GEOIP：依位址資料庫分類，不依語言分類

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

GEOIP 會依目標位址在地理資料庫中的分類進行比對，CN 是此規則使用的地區代碼。它無法根據網頁語言、網域後綴或機構名稱推斷比對結果。內容傳遞網路的位址調度可能改變，資料庫分類也未必符合直覺。若某個主機需要固定策略，應將明確的網域規則放在 GEOIP 前面，不要依賴某次解析恰好落在預期地區。

若使用含 no-resolve 的 GEOIP 規則，也要了解可用位址資訊的限制。規則未命中時，應先檢查目標 IP 和網域資訊是否可見，再確認資料庫分類。盲目交換 GEOIP 與 FINAL 的位置無法解決問題：FINAL 應放在兜底位置，若置於 GEOIP 前面，後者就可能失去正常比對的機會。

USER-AGENT：取決於可見的 HTTP 資訊

[Rule]
USER-AGENT,ExampleClient*,DIRECT

USER-AGENT 的條件來自 HTTP 請求標頭，不是裝置上顯示的 App 名稱。上例以虛構的標頭前綴示範萬用字元比對，不能據此識別任何實際 App。在加密連線中，用戶端未必能讀取這項資訊，因此不能將它當成適用所有請求的 App 分流規則。請求標頭也可能隨 App 更新或請求類型改變，穩定性需要另外驗證。

選擇規則類型的關鍵在於證據是否足夠：有明確主機名稱時使用網域規則，有明確位址範圍時使用 CIDR，確實需要依位址分類時使用 GEOIP。只有確認請求內容可見且條件穩定後，才考慮 USER-AGENT。依可觀察到的資訊選擇規則，能避免在不同條件間反覆嘗試，卻始終無法解釋結果。

策略、比對順序與 FINAL

規則通常由類型、比對值與策略組成，FINAL 則不需要一般比對值。類型決定要檢查什麼，策略決定命中後如何處理。PROXY、DIRECT、REJECT 是本頁使用的三種基本策略；它們與 Global Routing 的介面模式屬於不同層次。閱讀規則時，應先看條件，再看結果，最後確認規則是否有機會執行，不要只在檔案中搜尋想找的策略字詞。

PROXY、DIRECT、REJECT 分別代表什麼

PROXY 不會自動產生可用的伺服器資訊，也不保證能成功連上目標。即使規則命中，仍可能因伺服器無法連線、通訊協定參數不符，或遠端無法連上目標而失敗。DIRECT 也不是「必定成功」的策略，只表示選擇直接連線。REJECT 會明確阻止連線，不應在無法判斷時當作通用答案；若誤拒絕認證或 API 請求，整個 App 都可能出現異常。

現有設定也可能使用命名策略群組。若規則行末不是這三種關鍵字，應回到原設定查看該名稱的定義與目前選取項目。不要任意把群組名稱改成 PROXY，再假設原本的選擇邏輯不變。其他設定中的群組名稱也不能直接複製使用，因為規則引用必須有對應定義；拼字、空格或名稱不一致都可能造成引用問題。

優先採用首條命中規則，不會自動按「精確度」排序

[Rule]
DOMAIN,local.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

一般規則依排列順序檢查，前方的比對結果會決定後續規則是否還有機會執行。上例將精確例外放在後綴規則之前，接著處理私有網段與位址分類，最後才兜底。這不是適用所有環境的固定範本，而是示範一種容易閱讀的排列方式。若把涵蓋範圍廣的後綴規則放在第一行，即使後面有更精確的 DOMAIN，也不會因為「更精確」就自動取得較高優先順序。

位址規則與網域規則之間也可能有順序影響。若把涵蓋範圍很大的位址條件放得太前面，後續的網域例外可能無法發揮作用；反過來，若某個網域已被前面的規則命中，其解析位址屬於哪個地區就不會再決定這次一般規則的結果。排錯時應由上而下找出第一條符合條件的規則，不能只檢查剛新增的那一條。

重複規則容易掩蓋真正原因。若兩條條件完全相同卻指定不同策略，後面的規則通常不會如預期接手。刪除重複項前，先確認它們是否來自不同管理區段或可更新來源，再決定在哪一層修正。大型設定檔可暫時將單一精確測試規則移到前面協助定位，但測試完成後必須恢復原本的組織方式，避免留下難以解釋的優先順序補丁。

FINAL 是兜底規則，不一定要使用 PROXY

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

這段片段表示，符合 example.com 的請求使用 PROXY，其餘請求使用 DIRECT。若將最後一行改為 FINAL,PROXY，就會改變所有未被前面規則涵蓋的一般請求。兩種寫法都可能適用於不同需求；關鍵是先說明預設連線路徑，再加入例外。不要只因某段範例使用 PROXY 兜底，就直接改變自己設定檔中的整體連線假設。

FINAL 應放在一般規則的末尾，整理時也應保留明確且單一的兜底規則。若在它後面繼續新增 DOMAIN 或 GEOIP，可能出現「儲存成功但規則無效」的狀況，因為流量已經在前面被接手。檢查檔案末尾尤其重要：貼上多段片段時，最容易把其中一段的 FINAL 留在中間，再把新規則加在它後面。

若規則符合實際需求，但仍無法連線，就應停止堆疊同類規則，改查連線路徑。相關步驟請參閱連線失敗排查順序。規則層用來說明為何選擇這條路徑，連線層則用來找出路徑成功或失敗的原因；分開檢查，才容易得到可重現的結論。

Host 對應與 DNS 判斷

Host 用來指定主機名稱與位址的對應，Rule 則決定連線採用哪種策略，兩者不能互相取代。將網域對應到某個位址，不代表要求它使用 DIRECT；替網域指定 PROXY，也不代表固定其解析位址。排錯時，先分別記錄「請求主機名稱」、「實際目標位址」及「採用策略」，再判斷是哪個層次發生偏差。只看網頁是否開啟，通常無法分辨這三者的變化。

Host 的基本寫法與使用範圍

[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.20

左側是要對應的主機名稱，右側是指定的位址。此處使用文件範例位址，不代表可連線的伺服器。Host 項目不使用 Rule 的三欄逗號格式，末尾也不加 PROXY 或 DIRECT。新增後應確認是否確實需要固定位址，以及該位址是否由目標服務管理者明確提供；不能只憑某次查詢結果，就將動態服務長期綁定到單一位址。

固定對應會略過正常解析中的部分動態選擇。使用內容傳遞、負載平衡或容錯切換的服務，位址可能隨地區、網路及時間而改變。舊對應有時短期內有效，之後卻可能造成逾時、憑證異常或部分資源載入失敗。遇到這類狀況時，應將 Host 中相關項目列入檢查，先恢復正常解析進行比較，而不是立刻新增更多網域分流規則。

通常不應將 Host 理解為修改請求中的所有身分資訊。對 HTTPS 而言，憑證驗證仍與所請求的主機名稱有關；指定 IP 不代表可以接受任意網站的憑證。遇到憑證錯誤時，應檢查目標網域、對應位址與裝置時間，不要降低信任要求來掩蓋對應問題。若證據不足，撤銷對應比繼續擴大修改範圍更容易恢復原狀。

DNS 與規則的關聯

DNS 會將名稱轉換為位址；有主機資訊時，網域規則可以依名稱判斷，位址規則則需要適當的位址資訊。兩者密切相關，但並非每種連線都會以相同順序提供相同資訊。App 快取、系統快取及代理路徑中的解析方式，都可能影響觀察結果。因此，「系統查到這個位址」與「這次實際連線使用這個位址」應分開記錄。

[General]
dns-server = system

[Rule]
DOMAIN,api.example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT

這段片段用來說明不同判斷層次：第一條依明確網域處理，第二條只在已有位址資訊時比對範例網段，最後再兜底。它不是通用的 DNS 故障修復方案。若 api.example.com 已命中第一條規則，就不能只因它解析到範例網段而認定應改走第二條。相反地，若請求直接使用位址而沒有相關主機名稱，觀察到的比對路徑也可能不同。

解析故障的分支檢查方式

若所有網域都無法連線，但已知位址的連線結果不同，應先檢查目前網路的解析能力、General 中的 DNS 設定，以及是否有 Host 覆寫。若只有單一網域異常，優先確認拼字、過期的對應、服務本身狀態及是否存在拒絕規則。不能只因「某個頁面空白」就判定是 DNS 故障，因為頁面入口可能已成功載入，真正失敗的可能是後續 API 或認證請求。

在 Wi-Fi 與行動網路間切換時，應記錄網路變化。系統 DNS、IPv6 可用性與區域網路存取條件都可能隨之改變。若設定相同但結果不同，應檢查這些輸入條件，不要複製兩份彼此矛盾的規則來「適配」。對照測試的目的是找出差異來源，最終設定應能說明差異，而不只是記住在哪個網路上碰巧可用。

修改 Host 或 DNS 後，應重新建立測試連線；舊連線可能仍沿用先前的位址。必要時先關閉目標 App 再重新開啟，並觀察新的請求記錄。不要假設重新整理頁面就一定會更新所有網路狀態，也不要同時清除多種設定後只記下「重新啟動就好了」。保留變更順序，才能判斷結果是新解析、舊連線結束，還是其他操作所致。

DNS 排錯最後應留下可供核對的資訊：異常主機、當時使用的網路、是否存在對應、實際使用的位址及最終策略。若這些資訊仍不完整，繼續修改其他 General 參數只會增加不確定性。常見連線與解析問題也可搭配常見問題逐項確認。

URL Rewrite 與比對範圍

URL Rewrite 會改寫或重新導向可見的請求網址，與 Rule 選擇連線路徑是不同功能。Rule 解決「連線採用哪種策略」，URL Rewrite 則處理「符合條件的請求網址如何變更」。若需求只是讓 example.com 使用 PROXY，應撰寫網域規則，而不是新增重寫運算式。只有確實需要變更請求網址，且了解預期結果時，才應使用重寫區段。

重新導向運算式的組成

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

這一行包含比對運算式、替換網址與處理方式。範例使用 302 表示暫時重新導向：當可見的請求網址符合左側運算式時，便回傳指向右側網址的重新導向結果。此處刻意使用 HTTP 與完整、精確的路徑，避免把 HTTPS 可見性或複雜路徑擷取混入基本語法說明。範例網域僅供說明，不代表需要實際連線的測試服務。

運算式中的 ^ 錨定開頭，$ 錨定結尾，\. 表示字面上的句點。若省略跳脫，句點在正規表示式中通常有更廣泛的比對意義；若省略結尾錨點，含有其他路徑或查詢內容的網址也可能符合條件。編輯時應逐一確認各符號的作用，不要只因運算式「看起來像網址」就認為它等同一般網址文字。

右側網址也必須完整明確。將 HTTP 改成 HTTPS，不代表目標服務一定會在相同位置提供相同內容；更改主機名稱或路徑，也可能影響登入狀態、跨網域請求與 API 行為。重寫只能改變指定請求的處理方式，無法替目標服務建立頁面。若 App 不接受重新導向，瀏覽器中看似可用的運算式，也可能在該 App 的請求中失敗。

先限制範圍，再加入複雜條件

首次測試應從單一主機、單一路徑開始，避免一開始就使用涵蓋所有網域的模式。確認精確比對可如預期運作後，再逐步評估是否需要涵蓋子路徑或查詢參數。每次放寬運算式，都應列出新增涵蓋的請求類型。若需要保留查詢內容，必須明確指定參數如何帶入替換網址，不能假設它們會自動原樣傳遞。

正規表示式中的擷取群組、跳脫字元與設定文字，分屬不同層次的問題。直接編輯設定檔，與將相同文字嵌入其他格式時，所需的跳脫處理可能不同。不要把說明頁面顯示的雙重跳脫，直接當成設定檔所需的反斜線數量。本頁程式碼展示的是設定文字本身；貼上後應在編輯器中逐字檢查，不要再多加一層引號或跳脫。

同一個重寫區段中有多個運算式時，應避免條件重疊，並依由具體到一般的順序排列。不要把 Rule 的 FINAL 照搬到 URL Rewrite，兩者不是同一種語法。若現有設定包含複雜的重寫組合，應先以副本停用相關組合進行比較，再單獨啟用目標運算式驗證；不要一次加入多條來源不明的規則後，只檢查頁面是否開啟。

HTTPS、憑證與請求內容可見性

HTTPS 會保護請求內容。即使知道網域，也不能假設用戶端能讀取完整路徑並執行任意重寫。能否處理相關請求，還取決於實際功能設定與連線條件。本頁範例不要求啟用 HTTPS 解密，也不將安裝憑證列為查閱規則的前置步驟。若需求可透過網域分流解決，應優先使用影響範圍較明確的 Rule。

憑證與信任設定的變更應分開評估，尤其不要為了讓某段重寫設定「生效」，就接受來源不明的設定。憑證錯誤、App 拒絕連線及重寫未命中是不同現象。先記錄系統或 App 顯示的實際錯誤，再判斷請求是否到達可處理的層次；否則容易把可見性限制誤判為正規表示式錯誤，進而不斷擴大比對範圍。

辨識循環與快取造成的假象

若替換後的網址再次符合原運算式，就可能形成重複重新導向。瀏覽器可能持續跳轉、顯示錯誤頁面或無法完成載入。排查時應分別列出起始網址、替換網址，以及替換後的網址是否仍符合條件。驗證成功後仍應保留足夠精確的條件，不要仰賴瀏覽器剛好停止請求來避免循環。

重新導向結果也可能被 App 快取；停用運算式後，舊行為未必立即消失。應使用新的請求並記錄網址變化，必要時結束目標 App 的舊工作階段。若還原原設定後仍有異常，先檢查快取與目標服務的回應，不要立刻認定設定儲存失敗。能說明網址從原始位址到最終位址的每一步，才算完成重寫排查。

設定驗證與故障排除順序

設定排錯的目標是找出足以解釋現象的最小原因，而不是反覆切換所有設定。開始前先記錄目前網路、Global Routing、設定名稱、既有伺服器及目標請求。接著寫下具體預期，例如「api.example.com 的新連線應使用 PROXY」。目標越具體，越容易驗證；「所有功能都恢復正常」適合最後檢查，卻不適合作為單一規則測試的起點。

先確認連線基準，不急著修改規則

首先確認 Shadowrocket 已取得 VPN 設定授權，且能成功建立連線。若連線本身無法啟動，應優先檢查系統提示與連線狀態；若連線已建立但既有伺服器無法連線，先核對伺服器資訊與網路。只有基本連線具備測試條件後，才繼續判斷 Rule。Connectivity Test 可提供連線線索，但單項測試通過，不代表每個網域、每種協定請求及每條規則都已驗證。

接著確認 Config 確實是目前的 Global Routing，並檢查正在使用的設定是否就是剛才編輯的檔案。儲存到副本卻仍使用原設定，是常見的誤差來源。比對檔案中一條容易辨認的規則內容，再執行儲存及必要的重新連線操作。若 App 顯示解析錯誤，應先修正檔案語法，不能繼續根據無效設定推斷比對結果。

依條件、順序與策略逐層檢查

1. 確認請求實際關聯的主機名稱或目標位址，是否與規則欄位一致。
2. 從 Rule 開頭往下檢查，找出更早命中的條件。
3. 確認 FINAL 沒有提早攔截後續一般規則。
4. 核對命中的策略或命名策略群組，以及實際採用的路徑。
5. 使用新連線重新測試，並與修改前的記錄比較。

若請求主機與規則不一致，先處理比對對象；若主機一致但結果採用其他策略，先檢查順序或設定選取狀態；若策略正確但連線失敗，再檢查路徑與目標。這種分支檢查能避免常見的反覆嘗試：連線失敗就新增網域規則，仍失敗就改 DNS，再失敗就擴大關鍵字範圍。每次測試都應回答一個問題，而不是同時試圖驗證所有設定。

[Rule]
DOMAIN,api.example.com,PROXY
FINAL,DIRECT

這段最小設定只用來說明定位方法，不應覆蓋整份現有設定。實際測試時，請在已備份的副本中暫時加入單一精確條件，以排除寬泛規則的干擾。若精確條件能產生預期策略，再逐步還原原設定中的規則區塊；若仍不行，就檢查請求資訊是否可見、設定是否生效，以及目前模式是否正確。這樣得到的結論，比不斷新增同義規則更可靠。

將現象分類，方便逐項確認

遇到間歇性問題時，應記錄每次失敗的時間、網路與目標，不要只保留成功的紀錄。頁面可能重複使用舊連線，服務也可能變更解析位址；重複請求不一定有相同的輸入條件。查看記錄時，應以對應測試操作的新連線為準，避免把背景同步或其他 App 產生的流量誤當成測試結果。

若要查看 Data 或相關診斷記錄，只收集與目標請求有關的必要資訊。完整記錄可能包含網域、路徑、查詢內容與個人識別資訊，分享前應先清理。向他人說明問題時，可提供已移除敏感資訊的規則片段、目前模式及可重現步驟，不要直接交出整份設定與訂閱網址。讓他人能重現判斷過程，比提供大量無關記錄更有幫助。

還原、整理與後續查閱

確認原因後，只保留解決問題所需的修改，並撤銷用於定位的暫時性寬泛規則、Host 對應或重寫運算式。接著檢查日常使用的其他目標，尤其是先前由例外規則保護的請求。最後儲存新的可還原副本，並記錄修改目的。若設定可以更新，還要在下次更新後確認重要內容，確保本機調整沒有被覆蓋。

日常匯入與首次連線請繼續參閱快速入門教學；購買、App ID 與開發者核驗請查看正版核驗說明；常見操作疑問請查閱常見問題。本頁的規則參考用來說明設定如何表達預期，實際結果仍應透過目前裝置上的新連線及可觀察記錄逐項確認。