CONFIG / RULE / POLICY

Shadowrocket 規則與設定完整指南

本頁是 Shadowrocket 官方手冊的系統查閱篇，著重設定結構、比對依據與故障定位。首次匯入既有訂閱並連線，請先閱讀使用說明；完成基本連線後，再依本頁目錄調整規則。

所有範例僅用於說明語法，網域與位址皆為教學用值。操作前請備妥自己的訂閱或伺服器資訊，並保留目前可用的設定。

一、Config 檔案結構與設定範圍

區分伺服器資訊、訂閱與設定檔

Shadowrocket 中的伺服器資訊、訂閱和設定檔各自處理不同事項。伺服器項目記錄連線目標所需的位址、連接埠、驗證資料與協定參數；訂閱用來批次管理使用者已有的伺服器項目；設定檔則負責安排請求的解析、比對與處理規則。三者可能出現在同一使用流程中，但不能互相取代。匯入伺服器訂閱後，仍須確認目前使用哪份設定檔；選取設定檔，也不代表已經有可用的伺服器。排查問題時先釐清這兩個層面，可避免反覆修改無關項目。

設定通常以分段方式組成文字。方括號標示分段起始處，該段內容會持續至下一個分段標題之前。常見的 [General] 用來存放一般設定，[Rule] 存放具有先後順序的比對規則，[Host] 存放指定主機名稱的位址對應，[URL Rewrite] 則存放針對可見請求網址的改寫規則。分段標題不是說明文字，不能改成中文。規則中的逗號、等號與參數位置也屬於語法，編輯時請使用英文半形符號。

分段主要職責檢查重點
[General]一般行為與解析相關設定參數名稱、值與系統互動
[Rule]依條件選擇連線策略規則順序、條件與策略名稱
[Host]指定主機名稱的位址對應確認對應目標是否仍有效
[URL Rewrite]依表示式改寫可見請求網址比對範圍、目標與動作

從精簡範例了解各分段的關係

以下範例展示一般設定與規則如何分開撰寫。dns-server = system 表示使用系統提供的解析設定；這不代表所有網路環境下都會更快。兩條網域規則指向不同去處，最後一條則處理尚未比對到的請求。這只是結構範例，並非可直接覆蓋現有檔案的完整方案。尤其是 PROXY 實際連線的目標，仍須對照 App 中目前選取的伺服器，不能只憑這幾行文字推斷。

[General]
dns-server = system

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

閱讀較長的設定檔時，建議先標出所有分段，再找出最後的預設規則，接著回頭檢查網域與位址規則。這個順序能先釐清檔案整體範圍，再確認例外條件。不要一開始就把其中一大段複製到另一份檔案：同名策略、既有規則與一般設定可能不同，單獨看來語法正確的片段，合併後仍可能改變請求去向。遇到不熟悉的設定，先查明用途，再決定保留或刪除。

儲存、選用與保留還原點

在 Config 中編輯前，請先複製目前檔案，並以容易辨識的名稱儲存。編輯完成後確認已儲存，再檢查實際選用的是修改後的檔案。只開啟編輯器查看內容，不代表已切換目前使用的設定檔。接著也要核對 Global Routing，因為設定檔內有規則，與請求實際依規則處理，是兩個不同條件。第一次操作可參照快速上手流程完成選用，再回到本頁查閱語法。

遠端維護的設定檔也涉及更新範圍。若直接在會被遠端內容取代的檔案中加入個人規則，日後更新可能會覆蓋這些修改。較穩妥的做法是保留來源原檔，另存個人工作副本，並記錄每次修改的目的。訂閱更新、設定檔更新與 App 更新也應分開理解：前者主要涉及既有伺服器項目，第二項涉及規則文字，App 本身則透過 App Store 取得與更新。

二、Global Routing 與連線策略

先確認模式，再解讀規則結果

Global Routing 是判斷規則是否參與處理的第一個項目。設定模式對應 Config，代理模式對應 Proxy，直連模式對應 Direct。一般排查規則時，應先切回 Config，再檢查檔案內容。若處於其他模式，只修改網域規則通常無法得到預期結果。這裡說明的是整體連線路由選擇，不代表 App 會繞過系統限制，也不表示所有系統流量都能以相同方式查看。

模式名稱與規則中的策略關鍵字屬於不同層級。Proxy 是介面上的模式名稱，PROXY 則是規則中的策略值；Direct 與 DIRECT 也有類似區別。兩者字面相近，但切換模式不等於只改變某條規則的策略。若一整批請求的去向同時改變，應優先檢查模式與目前選用的設定檔，而不是逐條猜測網域規則是否失效。

模式介面用詞使用與診斷重點
設定Config依目前設定檔檢查比對條件與策略
代理Proxy確認代理方向的伺服器連線能力
直連Direct對照本機網路直接連線的狀況

PROXY、DIRECT 與 REJECT 的實際意義

PROXY 表示交由代理方向處理，但它本身不是伺服器位址。能否成功連線，仍取決於選取的伺服器、協定參數與網路是否可連通。規則正確比對到 PROXY 後若發生逾時，不能因此判定規則寫錯；應接著確認伺服器是否有效、是否支援目前請求所需的傳輸方式，以及驗證資料是否一致。若把所有錯誤都歸因於規則，便會忽略實際發生在建立連線階段的問題。

DIRECT 表示直接連線至目標，不代表略過名稱解析，也不保證目標一定可連線。本機網路的路由、防火牆、解析結果與目標本身的狀態都會影響結果。REJECT 表示拒絕符合條件的連線，適用於明確需要封鎖的範圍。拒絕後請求通常無法完成，但 App 顯示的錯誤可能只有載入失敗，不會直接顯示規則名稱，因此應搭配比對記錄判斷。

[Rule]
DOMAIN,service.example.com,PROXY
DOMAIN,intranet.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
FINAL,PROXY

範例刻意使用三個不同的主機名稱，讓各種策略的範圍更容易辨識。實際設定時，不要先寫一條涵蓋整個後綴的拒絕規則，再在後面加入某個主機名稱的允許規則；前一條若已比對成功，後面的例外就沒有機會執行。也不要把 REJECT 當成伺服器故障時的備用線路；它的作用是阻止請求，不會替使用者尋找其他連線路徑。

選取伺服器不代表所有請求都會經過該伺服器

在 Config 模式下，伺服器選擇與規則策略會共同決定結果。某個請求若比對到 DIRECT，即使目前選取了有效伺服器，仍會以直連方式處理。反過來說，預設策略設為 PROXY，也不代表前面的直連與拒絕規則會被忽略。因此，查看伺服器名稱只能知道「代理方向預計使用哪個目標」，無法單獨回答「這個請求為什麼走這條路」。

若要比較代理與直連，請選定同一個測試目標，分別記錄模式、網路類型與測試時段，完成後恢復原本的 Config 模式。不要同時更換伺服器、修改 DNS 又切換模式，否則結果改善時無法判斷是哪個變更造成的。若只有代理方向失敗，可接著查閱節點逾時與連線失敗檢查順序；若只有特定網域失敗，則應重新檢查比對條件與解析結果。

三、DOMAIN 系列規則與網域範圍

DOMAIN：比對單一指定主機名稱

DOMAIN 用於精確比對網域。規則條件應填寫主機名稱，而非完整網址，因此不要加入通訊協定前綴、路徑、查詢參數或連接埠。網址可以包含這些組成部分，但網域規則只會比對其中的主機名稱。若要只處理特定網頁路徑，應考慮其他適用機制；不要直接把路徑接在網域後面，期待精確網域規則能理解整段網址。

例如下方第一條規則只適用於 api.example.com，不會因為同屬一個組織就自動涵蓋 www.example.com。精確規則適合用於範圍已確認的單一服務入口，也適合放在較廣泛的規則之前作為例外。編輯時，從請求記錄複製主機名稱，比根據頁面名稱猜測可靠；頁面顯示的品牌名稱與實際請求網域不一定相同，靜態資源和驗證請求也可能使用其他主機名稱。

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

DOMAIN-SUFFIX：依網域層級涵蓋後綴

DOMAIN-SUFFIX 適用於根網域及其子網域需要採用相同策略的情況。條件填入 example.com 時，會涵蓋根網域與相應子網域，但不會比對任何只是包含這段字元的名稱。網域層級有明確界線，這點與關鍵字比對不同。通常不必在條件前加上星號；若直接套用瀏覽器或其他語法中的萬用字元習慣，可能會讓規則失去原本要表達的意思。

後綴規則可減少逐一維護子網域的工作，但也會擴大影響範圍。若同一後綴下既有需要代理的介面，也有只能在本機網路使用的服務，統一指定策略可能會影響其中一類。較妥善的做法是先列出範圍較小的例外，再設定後綴規則。上方範例中的登入主機名稱會先比對到 DIRECT，其餘同後綴的請求再交由後續規則處理；順序本身就是設定意圖的一部分。

DOMAIN-KEYWORD：字串條件與誤判

DOMAIN-KEYWORD 會比對網域是否包含指定關鍵字，適用範圍比完整網域後綴更廣。它無法理解關鍵字的業務意義，也不會判斷某個名稱是否確實屬於廣告、分析或更新服務。條件太短容易誤傷無關網域，尤其是常見字母組合。以下片段僅用來說明寫法，不能把其中的關鍵字當成已驗證的封鎖清單，更不應未經測試就加入日常設定。

[Rule]
DOMAIN,downloads.example.com,DIRECT
DOMAIN-KEYWORD,ads,REJECT
FINAL,PROXY

範例先為明確的主機名稱保留例外，再示範以關鍵字拒絕請求。即使如此，其他包含相同字元的網域仍可能被拒絕。若發生部分圖片無法載入或登入流程中斷，應先查看實際失敗請求的主機名稱，再確認是否被這類廣泛條件涵蓋。若只想處理已知網域，優先使用精確或後綴規則通常更容易說明，也更方便日後確認影響範圍。

將單一頁面的多種連線分開觀察

網頁載入不只涉及一個請求。主頁、指令碼、圖片、驗證與介面可能各自連到不同網域；只為網址列中的網域設定規則，無法保證所有資源都走相同方向。驗證時應區分「主頁能開啟」與「所有功能都正常」，並透過新請求確認各個重要網域。不要因一張圖片載入失敗，就把整個網站的規則擴大成更廣泛的關鍵字；也不要把暫時出現的第三方資源網域一律加入同一個後綴。

網域規則的前提是比對階段能取得網域資訊。若請求以位址形式發出，或既有連線已被重複使用，觀察結果可能與剛編輯的網域規則不同。此時先關閉測試頁面並重新發起連線，再查看記錄中實際顯示的目標。確認問題能穩定重現後，才適合決定應補上網域規則、處理位址規則，或排查 DNS。相關名稱也可參閱概念速查交叉確認。

四、IP、GEOIP 與 USER-AGENT 規則

IP-CIDR 與 IP-CIDR6 的位址範圍

IP-CIDR 用於比對 IPv4 位址範圍，IP-CIDR6 則用於比對 IPv6 位址範圍。斜線後的數字代表網路前綴長度，不是連接埠或位址數量。前綴越長，描述的範圍通常越小。規則應使用正確的網路位址與前綴組合；若只要比對單一 IPv4 位址，可使用完整主機前綴，不要隨意省略前綴並假設各種寫法意義相同。

以下以常見的私有位址範圍與 IPv6 本機位址範圍示範語法。是否需要這些規則，應依實際網路環境與既有一般設定判斷。有些系統流量或一般略過設定，可能在進入一般規則比對前就已處理，因此看不到某條位址規則命中，不一定代表語法錯誤。排查區域網路服務時，應一併記錄裝置實際位址、閘道與目前的網路類型。

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
IP-CIDR6,fe80::/10,DIRECT,no-resolve
FINAL,PROXY

no-resolve 的作用

no-resolve 用來避免只為了判斷該位址條件就觸發網域解析。它不代表整個 App 停止使用 DNS，也不保證這條規則永遠不會比對到與網域相關的連線。若請求目標原本就是位址，或比對階段已有可用的位址資訊，仍可能符合位址條件。理解這點很重要：這個參數控制的是比對時的解析行為，不是把規則改成只適用於某種 App 的特殊條件。

設定檔包含大量位址範圍時，若不必要地為每次比對主動解析，可能增加等待時間，也可能讓解析路徑影響結果。反之，若一律機械式加上這個參數，原本需要解析結果才能判斷的規則，可能無法在預期階段發揮作用。選擇前先確認「這條規則是否必須將網域解析成位址才能生效」，再觀察實際記錄，不要把參數當成通用的加速開關。

GEOIP 依據資料庫判斷，不代表網站歸屬

GEOIP 會依目標位址與所使用的地理位址資料庫進行判斷。常見寫法如下，但國家或地區代碼代表的是資料庫分類，並不等於網站營運者、內容語言或使用者所在地。網域可能使用分散式服務，不同網路或時間解析到的位址可能不同，最終分類也可能隨之變化。因此，GEOIP 適合作為較廣泛的後續規則，不適合取代用途已明確的精確網域條件。

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

地理規則結果異常時，先確認實際連線位址，再核對命中哪條規則。不要只憑頁面語言推斷位址應屬於哪裡，也不要為了配合單一例外就整體反轉地理策略。若某項服務必須穩定走指定方向，將範圍更明確的網域規則放在前面通常更容易維護。資料庫分類、DNS 結果與業務需求是三種不同資訊，應分開記錄。

USER-AGENT 的使用條件

USER-AGENT 會依可觀察到的請求識別資訊進行比對，不是依裝置上安裝的 App 名稱判斷。以下寫法示範前綴萬用條件，但能否命中取決於請求是否包含相應欄位，以及該欄位在處理階段是否可見。僅靠一條規則，無法自動讀取加密請求中的內容；若規則未命中，應先確認資訊是否可見，不要立刻擴大比對範圍。

USER-AGENT,ExampleClient*,DIRECT

同一個 App 也可能呼叫系統元件或不同網路模組，送出不同識別資訊；不同 App 也可能使用相同識別資訊，因此這類規則不適合作為嚴格的 App 身分界線。一般依網域分流時，網域條件通常更直觀。只有在已確認請求識別資訊、了解涵蓋範圍並能穩定重測時，才應保留相應規則。不要為了讓某個比對條件成立，就貿然變更憑證信任設定或擴大內容處理權限。

五、比對順序、例外與 FINAL

第一條符合條件的規則生效，不會自動挑選最精確的規則

在一般的 [Rule] 處理邏輯中，規則會由上而下逐條檢查，第一條符合條件的規則就會決定策略。精確網域不會因名稱更具體而自動取得較高優先順序；若較廣泛的後綴規則排在前面且已符合條件，後面的精確規則就不會再次改變結果。這也是許多「規則明明存在卻沒有生效」的原因。檢查時除了找到目標規則，也要從它上方開始確認是否有更早符合的條件。

閱讀規則順序時，可以把每一行視為一個判斷：條件符合就採用該行策略並停止，不符合才繼續往下。註解、分組標題與空白行有助於閱讀，但不會建立另一套優先順序。即使把例外放在醒目的標題下方，也無法跳過前面已生效的規則。維護較長的檔案時，建議以固定的分組順序表達意圖，不要依賴記憶判斷例外應放在哪裡。

[Rule]
DOMAIN,office.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

從明確例外到廣泛條件

上方範例先處理兩個明確的主機名稱，再涵蓋整個後綴，接著檢查位址範圍與地理條件，最後使用預設策略。這是方便說明的一種編排方式，不代表所有網路都必須照抄。若某項服務要求位址規則永遠優先，就需要重新安排順序，並了解對網域條件的影響。重點不是背下固定順序，而是能說明每個重疊請求會先遇到哪一條規則。

以 office.example.com 為例，即使它也符合後綴條件，第一條規則仍會先決定採用直連。若將後綴規則移到第一行，結果就會改變。再看一個不屬於該後綴的網域：它可能要經過位址或地理條件，才會到達預設規則。逐一建立這類最小測試對象，比只觀察日常瀏覽是否「看起來正常」更能找出順序問題，也更容易確認一次編輯實際改變了什麼。

FINAL 應作為其餘請求的出口

FINAL 沒有網域或位址條件，用來處理此前未比對到的請求，應放在有效規則的末尾。若放在中間，後面的規則通常就沒有執行機會；若同時存在多條預設規則，也不代表會依序嘗試多種策略。以下兩種預設方向代表不同的整體取捨：未明確處理的請求交由代理，或採用直連。選擇哪一種，應與自己的連線目標及既有設定一致。

FINAL,PROXY
FINAL,DIRECT

這兩段是互相替代的範例，不要為了「多一層保險」而同時加入。預設策略的影響範圍很大，修改前應列出幾種代表性請求，包括原本依賴預設方向的服務。只測試一個已符合精確規則的網域，無法證明新的預設方向符合預期。若不確定目前檔案的設計，先保留原有預設策略，只針對明確問題新增局部例外，避免小幅修正演變成全域行為變更。

合併規則時檢查重複與遮蔽

合併兩段設定時，不能只確認是否有相同文字，也要檢查比對範圍是否重疊。相同條件重複出現時，通常由前面的規則決定結果；後面採用不同策略的規則，可能根本沒有機會執行。廣泛的關鍵字、後綴與位址範圍也可能遮蔽後續例外。清理前先保留原檔副本，再依目標網域追蹤首次命中的位置，確認後才刪除冗餘內容。直接依字母順序排列整份檔案會破壞原有優先順序，不適用於有順序意義的規則段。

找出被遮蔽的規則後，還要判斷它是無意重複，還是為日後切換用途而保留的註記。實際生效的文字應盡量清楚，維護筆記則放在不參與執行的位置。修改後重新建立連線，避免把舊連線仍在傳輸誤認為新順序無效。若涉及多個相關主機名稱，應逐一檢查；一條規則的優先順序正確，不代表整組服務的依賴都已涵蓋。

六、DNS、Host 與連線位址的關係

解析負責取得位址，規則負責決定策略

DNS 主要回答主機名稱對應哪個位址，規則主要決定請求採用哪種策略。兩者會互相影響，但不是同一回事。網域解析成功只代表取得位址，不表示目標連接埠可連線；命中代理規則，也不代表解析一定會依使用者預期的路徑進行。排查記錄應分別包含主機名稱、解析結果、命中規則與最終連線狀態，不能把「無法開啟」當成所有處理階段的共同結論。

[General] 中的解析設定會影響後續判斷所依據的資訊。使用系統解析時，結果可能隨目前的 Wi-Fi 或行動網路而異；使用其他明確設定時，也要確認該解析服務本身是否可連線。不要同時修改多項解析選項，再只憑頁面開啟速度判斷好壞。網域可能已有快取，頁面也可能重複使用連線，這些因素都會讓測試呈現的差異比實際設定差異更明顯或更不易察覺。

[General]
dns-server = system

Host 對應不是伺服器項目

[Host] 可為指定的主機名稱設定位址。以下將教學網域對應到文件示例位址，僅用於說明格式，不代表該位址上有可連線的服務。等號左側是主機名稱，右側是目標位址。這不是填寫 Add Server 代理伺服器資料的地方，也不會變更遠端服務的驗證資訊。不要把訂閱中的伺服器位址或密碼貼到這個分段，期待它能完成伺服器匯入。

[Host]
service.example.com = 192.0.2.10
assets.example.com = 198.51.100.20

固定對應適用於位址需求明確且受控的環境，但會略過網域原有的動態調度。服務搬遷、位址失效或網路位置變更後，舊對應可能仍會把請求導向不合適的目標。若某個網域只有在啟用特定設定檔時才出現異常，應檢查是否留有舊對應，再比較系統解析與設定檔解析得到的位址。不要為了暫時恢復連線，就長期保留來源不明的固定位址。

位址變更不代表憑證身分也變更

透過主機名稱連線至加密服務時，連線位址與伺服器身分驗證彼此相關，但不能互相取代。將網域對應到另一個位址，不會讓該位址上的任意服務自動擁有正確憑證，也不保證服務能識別所需的主機名稱。若出現憑證或交握錯誤，應核對網域、服務設定與系統時間，不要把降低驗證要求當成一般解法。若要確認既有 Trojan 伺服器參數，可接著閱讀密碼、SNI 與 TLS 參數說明。

同樣地，Host 對應與網域分流也不能簡單理解為前者一定會覆蓋後者。網域條件可能先於位址條件命中；位址對應會影響連線目標，但採用哪種策略仍由比對流程決定。若要驗證兩者的關係，可只為一個教學或受控的主機名稱設定對應，記錄實際連線位址，並分別觀察網域規則與位址規則的命中情況。不要只根據最後顯示的位址反推所有前置步驟。

快取、雙位址與網路切換

同一個主機名稱可能同時對應 IPv4 與 IPv6 位址，實際使用哪一種會受網路連通性與連線過程影響。只為 IPv4 撰寫規則，不會自動涵蓋 IPv6；反過來說，看到一次 IPv6 連線失敗，也不代表應全面變更位址族設定。應先查看實際請求使用哪一類位址，再檢查相應規則與網路條件。分開記錄兩種位址族，可避免一項測試成功、另一項失敗時得出互相矛盾的結論。

切換網路後，解析快取、App 連線池與舊連線仍可能短暫影響觀察結果。驗證新設定時，應結束舊的測試連線，再重新存取固定目標；必要時依 App 提供的功能清除相關快取。只清除瀏覽器頁面快取，不一定能重新建立所有網路連線。若問題只在某個網路出現，可保持設定不變進行對照，有助於區分本機網路差異與設定本身的錯誤。

最終應讓解析設定保持清楚易懂：知道選用的來源、固定對應存在的原因，以及哪些位址規則依賴解析。設定檔中累積越多歷史選項與未知對應，故障時需要排除的可能性就越多。無法說明用途的設定，不要在工作副本中一再疊加；先回到最小可用狀態，再逐項恢復必要內容。

七、URL Rewrite 語法與處理範圍

改寫請求網址不等於選擇連線策略

[URL Rewrite] 處理符合條件且可見的請求網址，[Rule] 則負責連線策略，兩者不能互相取代。將網址改寫至另一個主機名稱，不代表已指定代理方向；新目標仍須依相關設定與實際處理階段判斷。反過來說，網域規則只能決定路由方向，不能自動把某個路徑改成另一個路徑。先確認問題是網址轉換還是連線去向，再選擇相應分段。

改寫規則通常由比對表示式、目標與動作組成。表示式包含特殊字元時，應先理解其正規表示式意義，而不是只當成一般字串閱讀。句點在正規表示式中具有特殊用途，若要比對網域中的實際句點，必須正確跳脫。開頭錨點可限制比對起點，結尾錨點可限制完整範圍；若遺漏邊界，表示式可能比預期涵蓋更多內容。

[URL Rewrite]
^http://example\.com/(.*) https://example.com/$1 302

逐項看懂範例

範例會從網址開頭比對指定的通訊協定與主機名稱，將斜線後的內容擷取成一組，再透過 $1 放入目標網址。動作 302 表示暫時重新導向。這裡使用保留作教學用途的網域，不代表需要將它加入個人設定。實際使用前，請確認目標服務確實支援目標通訊協定與路徑；重新導向只能告知請求方前往另一個網址，無法讓原本不存在的服務變得可用。

表示式與目標之間的空白負責分隔，請勿在表示式中任意加入未處理的空格。複製規則時也要留意文字編輯器是否替換了引號、反斜線或標點。與簡單的網域規則相比，正規表示式改寫更容易發生「語法可以讀取，但涵蓋範圍不如預期」的問題。驗證時除了測試一個成功範例，也應加入相似但不應命中的網址，確認範圍界線足夠精確。

網址可見是改寫的前提

僅憑網域路由，通常無法讀取加密連線中的完整路徑與查詢參數。只有在 App 具備相應請求資訊，且請求符合可處理條件時，相關改寫才可能執行。看得到連線網域，不代表看得到完整網址；看得到一個網址，也不代表所有 App 的請求都以相同形式經過處理。因此規則未執行時，應先確認請求是否可見、是否符合表示式，再檢查動作與目標。

不要只為了驗證一般改寫，就擴大至所有網域的內容處理或變更憑證信任設定。加密內容的處理有獨立的安全界線，也可能受 App 本身的驗證機制影響。本手冊不將這些條件視為一般分流的必要步驟。若只需要依網域選擇代理、直連或拒絕，使用 [Rule] 即可，無須額外以網址改寫達成相同目的。

避免循環、遺失路徑與敏感資訊轉移

如果重新導向目標再次符合原表示式，可能形成循環。即使看起來只變更了通訊協定，也應確認目標服務是否會再把請求導回原網址。也要確認路徑與查詢參數是否保留：擷取範圍太小可能遺失必要參數，太大則可能將不應傳給新目標的內容一併帶過去。尤其是驗證相關請求，不要在不了解參數用途時改寫到另一個主機名稱。

同時存在多條改寫規則時，應逐一分析比對範圍，先測試單條規則，再恢復組合。反覆使用相同的初始網址測試時，也要考慮請求方可能快取了重新導向結果。頁面直接進入新網址，不一定代表目前規則仍在執行，也可能是請求方沿用先前的結果。為避免混淆，請記錄初始輸入網址、最終網址與實際命中的規則，必要時使用新工作階段重新驗證。

若目標只是阻止連線至某個已知主機名稱，明確的 REJECT 規則通常比複雜改寫更容易維護；若只是要更換策略，也應回到規則分段。只有確實需要轉換網址、能說明比對條件與目標的關係，且具備穩定的測試方式時，才保留改寫規則。刪除暫時測試過的規則也很重要，避免舊規則日後再次觸發。

八、設定驗證、故障定位與維護流程

建立可重複的測試基準

開始修改前，應確認目前網路可正常連線，並記錄使用中的網路、目前設定檔、Global Routing 模式與選取的伺服器。測試目標應固定，並分別準備一個精確規則目標、一個後綴規則目標，以及一個依賴預設規則的目標。每次只修改一個條件，儲存後重新建立連線。這樣的測試基準比連續新增規則更有用，因為結果一旦改變，就能明確對應到哪次編輯。

測試通過也應有明確定義。頁面能開啟，只能證明部分請求成功；登入、介面與資源載入可能仍各有問題。可先確認目標請求是否命中預期策略，再確認連線是否建立，最後檢查服務功能是否正常。將這三項結果分開記錄，有助於區分「規則方向正確但伺服器無法連線」與「連線正常但服務介面回應錯誤」，避免在錯誤的層面反覆調整。

依條件、比對、連線、服務分層檢查

  1. 條件層：確認 App 已連線、選用正確設定檔，且處於 Config 模式。
  2. 比對層：核對實際主機名稱或位址，從規則頂端找出第一條符合的規則。
  3. 連線層：檢查解析結果、目標連通性、伺服器驗證與傳輸參數。
  4. 服務層：檢查目標服務回應、帳號狀態，以及多個相依請求是否完整。

若未如預期命中，先排除廣泛規則遮蔽、規則放在預設項目之後、儲存了錯誤檔案，或測試仍沿用舊連線等可能性。若已命中預期策略但連線失敗，就先停止修改規則，改為檢查該方向的實際連通性。Connectivity Test 有助於比較既有伺服器的連線狀況，但測試成功不代表所有服務目標都能使用；測試失敗也無法單獨指出是哪個協定參數有誤。

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

這段精簡範例可用來理解驗證方式：精確目標應先命中代理，同後綴的其他主機名稱應採用直連，範圍以外再依預設策略處理。實際操作時，請以自己有權測試且確實存在的目標取代教學網域。不要用教學位址能否開啟來判斷設定是否正確；保留網域與文件位址是為了說明語法，不是提供網路連線測試服務。

區分規則問題與速度問題

即使連線方向正確，速度仍然偏慢時，應比較本機網路品質、目標服務、伺服器負載與協定參數，不要一再擴大代理範圍。延遲測試與實際傳輸速度也不是同一項指標；一次快速建立連線，不代表長時間傳輸一定穩定。保持設定不變，分別在不同網路測試同一個目標，通常比同時更換設定與伺服器更容易找出原因。詳細方法請接著閱讀速度緩慢的分層排查。

若問題只在切換網路後出現，請檢查連線是否重新建立、解析結果是否改變，以及 On Demand 是否影響連線時機。按需連線負責觸發連線，不會取代網域規則來決定策略。不要把自動連線時機與規則比對混為一談。需要調整這部分時，可參照On Demand 與背景耗電排查，完成後再以相同測試目標驗證。

保留修改記錄與可還原副本

穩定的設定應保留一份清楚標示的還原副本。記錄不必包含完整訂閱網址，只要寫明修改目的、涉及分段、影響範圍與驗證結果即可。遠端設定更新後，先比較預設策略、一般設定與個人例外是否變更，再切換正式使用。一次合併大量未知規則會增加判讀難度，也可能帶入重複條件與過時對應；依實際需求逐項新增，日後更容易判斷哪些內容仍有必要。

對外分享疑難排解資訊前，請移除自己的訂閱驗證參數、伺服器密碼、個人位址與業務敏感路徑。截圖或文字只保留定位問題所需的模式、規則類型與已去識別化的目標資訊即可。本網站為 Shadowrocket 官網與官方手冊；App 為閉源商業軟體，iPhone 與 iPad 的系統需求請以 App Store 頁面標示為準。購買確認方式請見正版核驗三要點；常見的首次連線問題可返回使用說明逐步檢查。

維護目標不是規則越多越好，而是每條規則都有明確用途、每個例外都有可驗證的範圍，每次更新也都有還原方式。遇到新問題時，先重現問題，再找出最早偏離預期的階段，最後進行最小幅度的修改。能從請求目標一路說明到策略與連線結果，才算完成設定驗證。