官方手冊 · 設定大全

Shadowrocket
規則與設定參考大全

先確認設定是否生效，再檢查規則為何命中。本頁依檔案結構、比對條件與驗證流程編排，方便查閱欄位並判斷分流結果。

首次匯入既有訂閱、選擇伺服器並建立連線，請先閱讀快速入門教學；完成基本操作後，再回到本頁了解 Config 與規則檔。教學著重完整操作流程，本頁則說明設定之間的關係、適用範圍及修改後的核對方法。

01 設定檔結構與生效範圍

設定檔必須先能正確讀取，接著才需要確認規則是否符合預期。Shadowrocket 設定檔通常分段編排：方括號中的名稱用來標示段落，段落下方的內容則依該段語法解讀。同一行文字放在不同段落，意思可能完全不同。查閱或複製範例時，應一併確認段落名稱、行內容與目標策略，不能只擷取其中幾個關鍵字。

General、Rule、Host 的用途

[General] 儲存一般設定，例如解析與略過相關選項；[Rule] 儲存決定連線去向的規則；[Host] 儲存指定主機名稱的靜態解析對應。三者分別回答「連線依據哪些基本條件處理」、「這個目標採用哪種策略」及「這個名稱對應哪個位址」。由於用途不同，調整其中一段不一定會改變其他段落的結果。

段落主要用途核對重點
[General]一般連線與解析設定選項拼寫、取值與目前的網路狀況
[Rule]依條件選擇策略規則順序、比對欄位與策略名稱
[Host]指定名稱與位址的對應網域與位址是否仍對應同一項服務
[URL Rewrite]比對並處理可見的 URL正規表示式範圍、目標位址與處理方式

從最精簡的檔案了解語法

以下片段用於說明結構，並非適用所有網路的完整設定。範例網域與文件位址不代表可用服務。實際使用時，應保留目前設定中仍有需要的項目，並確認既有伺服器可用。PROXY 是策略，不會因為寫入檔案就自動產生伺服器；同樣地，新增網域規則也不會自動修正該網域的解析或服務狀態。

[General]
dns-server = system

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

[Host]
test.example.com = 192.0.2.10

段落標題使用英文方括號，規則欄位以英文逗號分隔，一般選項則以等號連接名稱與取值。輸入法產生的全形逗號、彎引號與不可見空格，都可能讓看似相同的文字無法依預期解析。複製後應在編輯器中逐行核對，尤其留意行尾是否貼入說明文字。解說文字應放在正文或獨立註解行，不要直接接在策略欄位後面。

檔案存在，不代表目前正在使用

進入 Config 後，先確認目前選用哪一份設定，再開始編輯。儲存未選取的檔案，不會讓正在執行的設定自動切換成該檔案。同樣地，更新既有訂閱通常只會更新伺服器清單，不能據此認定規則檔也已更新。伺服器來源、設定來源與目前選取狀態應分別核對，避免在不同項目之間反覆修改。

開始前先保留一份本機副本，並記下原本使用的檔名。若目前設定來自可更新的網址，也要區分遠端原始內容與本機修改：之後重新取得內容時，本機變更可能需要再次核對。不要把「已儲存」當成「已驗證」；儲存只代表文字寫入完成，是否生效仍須搭配 Global Routing、連線狀態與實際命中的規則判斷。

讀取時發生錯誤，先檢查最近修改的段落，再確認是否重複貼上段落名稱或把規則寫入錯誤區域。檔案可以開啟但連線結果不符，則應檢查模式、策略與比對順序。將語法問題和執行結果問題分開處理，能避免為修正一個逗號錯誤而同時改動解析、伺服器與整套規則，最後無法判斷真正原因。

02 Global Routing與策略選擇

檢查規則前，先查看 Global Routing。Config 模式依目前設定決定連線去向；Proxy 模式會將通常由此模式處理的連線交由代理路徑；Direct 模式則使用直連路徑。本文討論的網域、位址與最後後備規則，主要應在 Config 模式下驗證。切換模式後，同一條規則不再產生原本的效果，不一定代表檔案有誤。

三種模式適用於不同檢查

模式介面用語檢查用途
設定Config驗證目前設定中的規則分流
代理Proxy協助判斷代理路徑與伺服器連線狀況
直連Direct協助判斷目前網路的直連狀況

排查時可暫時比較不同模式，但比較條件應保持一致：相同網路、相同目標、相同伺服器，並盡量建立新連線。若目標在 Proxy 模式下可連線、在 Config 模式下失敗，應優先檢查設定將目標導向何處；若兩種模式都失敗，還需檢查伺服器資訊、解析與遠端服務。單次切換無法直接證明所有規則都正確。

PROXY、DIRECT、REJECT 的差異

PROXY 表示使用代理策略，實際可用路徑仍取決於目前選用的伺服器與相關策略設定；DIRECT 表示直接連線至目標；REJECT 表示拒絕符合條件的連線。這些是規則中的策略關鍵字，與介面上的模式名稱屬於不同層級。尤其不要把整體的 Proxy 模式與某條規則結尾的 PROXY 視為完全相同的設定。

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

第一行只表示目標網域應走代理路徑，並未定義伺服器位址、驗證方式或傳輸參數。若既有伺服器資訊不完整，即使記錄顯示命中 PROXY，連線仍可能失敗。反過來，命中 DIRECT 也只是選擇直連，不代表目前網路一定能連到目標。規則選擇與路徑可達性必須分別驗證，不能用其中一項結果代替另一項。

REJECT 只應用於範圍明確且確實要封鎖的目標。範圍過廣的拒絕規則可能影響登入、圖片、推播或 App 初始化，因為同一個 App 往往會連線至多個網域。測試拒絕策略時，先使用完整網域，記錄受影響的實際請求，再決定是否擴大範圍。不要因為某個請求名稱看起來像統計或廣告，就假定拒絕後不會影響其他功能。

也要核對策略名稱

某些設定會使用自訂策略名稱。遇到這種寫法，應在設定中找到相應定義，確認名稱存在、拼寫一致，且目前仍可選用有效路徑。不要任意把現成策略群組改成伺服器備註，也不要只複製引用該策略的一行規則。初次整理檔案時，先用能清楚說明的內建策略完成最基本的驗證，再檢視自訂策略之間的關係，較容易釐清問題。

App 連線開關與路由模式也要分開檢查。開關關閉時，修改檔案不會讓流量經過目前規則；開關開啟時，系統顯示連線狀態，也不能取代網頁或 App 請求的實際驗證。首次設定的操作順序可參閱教學流程，本頁則接著說明具體規則為何命中。修改後切回原本的模式，可避免臨時排查設定成為長期使用狀態。

03 DOMAIN系列網域規則

已知目標網域時，優先從網域規則著手。網域規則比對的是主機名稱，不是瀏覽器網址列中的完整網址。填入 api.example.com 時，不要附上通訊協定前綴、路徑、查詢參數或頁面標題。網址中的主機名稱之後，斜線及其後內容屬於其他資訊，不能直接當作 DOMAIN 的比對欄位。

精確比對與後綴比對

DOMAIN 用於比對完整網域。填入 example.com，不代表也涵蓋了 www.example.com。DOMAIN-SUFFIX 則適用於涵蓋某個網域及其子網域：以 example.com 為條件時，可比對該網域本身及所屬子網域。兩者的差異決定規則只影響單一入口，還是同一網域下的一組服務。

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

選用後綴規則前，應先確認網域邊界。它不是任意比對字串結尾，也不代表含有相似文字就會命中。外觀相近的名稱不一定屬於同一網域。排查時，應逐字比對記錄中的完整主機名稱與規則欄位，特別留意多出的子網域、不同的頂級網域，以及 App 跳轉後使用的其他服務網域。

DOMAIN-KEYWORD 的涵蓋範圍較廣

DOMAIN-KEYWORD 會依網域中的關鍵字比對，適用於確實需要以字串涵蓋範圍的情況。它不會辨識品牌、服務歸屬或業務用途，因此相同文字可能出現在互不相關的網域中。關鍵字越短，越難預測意外涵蓋的範圍。若能列出完整網域，精確規則通常更容易解讀，也方便日後檢查。

[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,tracking,REJECT
FINAL,PROXY

此範例將明確例外排在涵蓋範圍較廣的規則之前。存取 ads.example.com 時，會先命中精確拒絕規則；存取同一網域的其他主機時，再由後綴規則導向代理。後面的關鍵字規則不會重新處理已命中的連線。此範例僅用來說明順序，不能直接當成通用封鎖清單；實際拒絕範圍應依使用者自己的目標與記錄決定。

一個網頁往往會連線至多個網域

頁面主文件、圖片、指令碼、登入介面與媒體內容可能來自不同主機。只替網址列中的網域設定策略，無法確保所有資源都走相同路徑。遇到「首頁開得了，但圖片沒有顯示」時，應查看失敗資源實際連線的主機名稱，不要立刻將整個後綴範圍改成相同策略。逐步擴大範圍，較能避免影響其他原本正常的服務。

網域規則也仰賴連線處理時能取得相應名稱。若 App 直接連線至數字位址，或當下無法取得名稱與位址的關聯，就不能只因使用者知道該位址屬於某網站，便認定網域規則一定會命中。此時應檢查連線記錄顯示的實際目標類型，再判斷是否需要補上位址規則。不要為了處理單一請求，就把所有未識別連線一律改成直連。

修改網域條件後，應重新發出請求。瀏覽器與 App 可能重用既有連線，使新規則暫時沒有機會處理同一個工作階段。可先關閉相關頁面再開啟，必要時重新建立連線，然後查看新產生的記錄。判斷依據應是新請求的目標與比對結果，而不是頁面是否仍顯示先前載入的內容；快取頁面無法證明網路請求使用了哪條規則。

維護時，為每組規則保留簡短用途說明，例如「完整網域例外」或「整個業務網域」。某個網域失效時，先確認服務是否改用其他主機，再考慮刪除規則。長期累積的規則若缺少用途註記，很容易讓同一網域重複套用不同策略；這類衝突最終由順序決定，不會自動合併成更合理的結果。

04 IP-CIDR、IPv6 與 GEOIP

位址規則比對的是目標 IP，不是網域文字。IP-CIDR 用於 IPv4 網段，IP-CIDR6 用於 IPv6 網段，GEOIP 則依位址資料庫中的地區歸屬判斷。三者都與目標位址有關，但資訊來源與涵蓋方式不同。選用前應先確認需要的是明確網段，還是依地區歸屬分類的一組位址。

CIDR 前綴代表位址範圍

CIDR 格式由位址和斜線後的前綴長度組成。IPv4 的前綴越長，範圍越小；單一位址可使用 32 位元前綴。IPv6 的位址長度不同，不能照搬 IPv4 的前綴意義。手動填寫時，應根據使用者既有的網路資訊確認範圍，不要只因位址前幾個字元相同，就判斷它們應該放在同一條網段規則中。

[Rule]
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR,198.51.100.8/32,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

上述位址屬於文件示例範圍，僅用於展示語法，不代表可連線的實際伺服器。第二行示範單一 IPv4 位址，第三行示範 IPv6 前綴。實際設定中的位址範圍必須符合需要處理的目標；原樣複製範例並不能解決任何實際服務的分流問題，也不能用來判斷伺服器是否可用。

no-resolve 控制比對時的解析行為

連線目標仍以網域表示時，檢查位址規則可能涉及解析。規則結尾的 no-resolve 用來避免只為這條位址規則主動觸發網域解析；若處理時已有目標位址，仍可依位址進行判斷。它不會關閉所有 DNS，也不會強制連線不使用網域。若把這個選項理解為整體解析開關，便會對結果產生錯誤預期。

是否加入此選項，取決於規則用途。若只想處理原本就以位址發起的連線，或不希望位址規則為網域目標增加解析步驟，可以考慮使用。若預期某個網域先解析，再符合指定網段，就必須核對實際比對路徑；不能限制規則主動解析，卻又要求它總能依尚未取得的位址命中。設定結果應以連線記錄核對。

GEOIP 不等於服務所屬地區

GEOIP,CN,DIRECT 判斷的是目標位址在資料庫中的地區歸屬，不依頁面使用何種文字、網域後綴、公司註冊地或使用者所在地進行判斷。使用內容傳遞網路的服務可能在不同時間解析到不同位址，資料庫中的地區歸屬也可能與實際業務認知不一致。因此，地區規則適合作為較廣泛的分類條件，不能取代重要業務網域的明確設定。

規則比對對象常見限制
IP-CIDRIPv4 位址範圍網域解析結果改變後，可能不再符合範圍
IP-CIDR6IPv6 位址範圍只設定 IPv4 規則，無法涵蓋 IPv6 連線
GEOIP位址資料庫中的地區歸屬不表示網域或服務的業務歸屬

同一網域可能同時取得 IPv4 與 IPv6 結果。若只替其中一種位址設定規則，另一種連線可能繼續符合後面的地區規則或 FINAL。排查「同一網址有時直連、有時走代理」時，應一併查看 IP 版本、實際目的位址與新連線時間，不要只比較網址文字。也要另外確認網路是否具備可用的 IPv6 路徑。

建議將明確的網域例外放在涵蓋範圍較廣的位址或地區分類之前，並保留最後的後備規則。若某項服務必須使用固定策略，直接指定網域通常比猜測它會解析到哪個地區更穩定。確實需要位址範圍時，應記錄來源與用途，避免服務更換位址後，舊規則繼續影響已分配給其他用途的連線。

05 比對順序、USER-AGENT 與 FINAL

一般的 [Rule] 清單會依設定順序檢查規則，連線命中後就採用相應策略。不能將這個過程理解為「自動挑選最精確的一條」。明確條件只有排在適當位置才有機會命中；若前面的廣泛條件已涵蓋目標，後面的精確條件就不會再改寫結果。整理設定時，規則順序與條件本身同樣重要。

先列出例外，再列出較廣的範圍

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

在此範例中，登入網域先採用直連；同一網域的其他主機則由後綴規則導向代理；關鍵字規則只會處理前面尚未涵蓋，且網域包含相應文字的目標。若將後綴規則移到第一行，登入網域也會先命中代理。檔案不會因為登入網域那一行較長或較精確，就自動給它較高優先順序。

重複規則也應依順序理解。同一網域先寫 DIRECT、後寫 PROXY，不是保留兩條可選路徑，而是由前面第一條符合條件的規則決定結果。檢查衝突時，不只要搜尋完全相同的行，也要檢查能涵蓋該網域的後綴、關鍵字與其他較廣泛條件。看似不同的文字，可能對同一個請求形成覆蓋關係。

USER-AGENT 取決於能否取得請求資訊

USER-AGENT 依請求中的 User-Agent 資訊設定條件。它不是用來偵測 App 名稱，也不能只因規則中寫了某個 App 名稱，就保證辨識該 App 的所有連線。只有處理時能取得相應的請求資訊，規則才有判斷依據。對於加密連線，不能假設所有請求標頭都能直接讀取；不要把這類規則當成涵蓋所有連線的唯一條件。

[Rule]
USER-AGENT,ExampleClient*,PROXY
DOMAIN,api.example.com,PROXY
FINAL,DIRECT

範例中的用戶端識別字僅用於示範比對方式，不代表實際 App。使用時應從可核對的請求資訊確認實際欄位，並檢查比對結果。同一個 App 的不同元件可能使用不同識別字，系統服務也可能代為發出請求。若目標能以網域明確描述，通常應保留網域條件作為可解釋的依據，而不是依賴猜測得出的請求標頭文字。

FINAL 僅作為最後的後備規則

FINAL 用於前面的規則都未命中時選擇策略，通常放在清單末尾。它不是提高優先順序的標記，也不是修正規則錯誤的開關。若將它提前放入規則清單，後續規則可能就沒有比對機會。選擇 FINAL,PROXY 或 FINAL,DIRECT，應依未分類連線預期採用的路徑決定，不要照抄其他檔案的習慣。

使用代理作為後備時，未明確分類的請求會依賴既有代理路徑；使用直連作為後備時，尚未涵蓋的服務可能直接透過目前網路連線。兩種選擇都需要實際驗證。最重要的是能夠說明結果：某個目標命中最後規則，通常表示前面的條件沒有涵蓋它，而不是最後規則「搶走」原本應該命中的連線。應檢查目標名稱、位址與規則範圍。

合併設定時，先決定要保留哪一條最後規則，再將具體條件放在它前面。直接將兩份完整檔案首尾相接，往往會留下多個段落、重複規則與提早出現的後備規則。建議以一份可用檔案為基礎，依用途逐組移入規則，每加入一組就檢查目標的命中變化。這樣出現異常時，就能定位到最近加入的範圍，不必從數百行內容中重新猜測。

06 General、DNS與 Host 對應

解析與分流有關，但不是同一個流程。DNS 將名稱轉換為位址，規則則決定符合條件的連線採用哪種策略。網域可能已命中代理規則，卻仍因解析失敗而無法存取；也可能解析正常，但所選路徑無法連到目標位址。因此，「延遲有數值」不能直接證明目標網頁的名稱解析、傳輸與 App 回應都已完成。

先保留能清楚說明的基本設定

[General] 中的選項應配合目前設定與 App 內說明理解。排查解析問題時，先記下原有 DNS 設定，再一次只調整一個因素。範例中的 dns-server = system 表示採用系統解析來源的設定方式，並非適合所有網路的固定答案。目前的網路、解析服務可達性與設定中的其他選項，都可能影響最後結果。

[General]
dns-server = system

[Host]
test.example.com = 192.0.2.10

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

此範例分別撰寫靜態對應與策略。[Host] 指定測試網域的位址，[Rule] 則指定該網域採用直連。變更位址對應不等於變更策略，變更策略也不代表位址一定正確。範例位址僅供文件說明，不應用來驗證實際網頁。實際服務的對應資訊必須來自使用者可核對的網路資料。

Host 對應無法取代服務設定

靜態對應適用於確實需要固定名稱與位址關係的情境，例如使用者自己的測試環境。它會略過該名稱原本的動態解析結果，因此也可能保留已失效的舊位址。使用內容傳遞網路、輪換位址或依地區回傳不同結果的服務時，手動固定位址可能破壞原有選擇。不要把偶然成功一次的位址長期保留為通用修正方式。

即使位址可以連線，HTTPS 仍要求名稱與憑證等條件相符。將某個網域對應到另一台伺服器，不會讓該伺服器自動取得該網域的憑證或網站內容。若出現憑證警告、回應了錯誤網站或連線遭拒，應還原原有對應並核對伺服器資訊，而不是繼續擴大規則範圍。網域、位址與服務身分是三個必須同時一致的項目。

解析失敗時的檢查順序

先確認失敗發生在解析階段，還是取得位址之後。若連線記錄顯示名稱解析失敗，優先檢查 DNS 設定與其可達性；若已顯示目的位址，再檢查策略、伺服器與目標回應。不要只依據瀏覽器的一句錯誤訊息下判斷，因為不同底層原因可能顯示相似畫面。記下單次完整失敗請求的時間與目標，有助於對照記錄。

接著檢查是否留有舊的 [Host] 對應。同一網域存在靜態對應時，即使更換 DNS 伺服器，測試結果也可能看不出變化。確認設定中沒有固定的舊位址，再比較系統解析與目前設定的解析結果。比較時也要考慮快取，避免把舊記錄誤認為新設定的輸出；應重新發出相關請求，必要時重新連線後再觀察。

還要區分解析請求的路徑與業務連線的路徑。業務規則設定為 PROXY，不代表所有解析流量必然使用相同伺服器；應檢查目前解析相關設定的實際作用。調整 DNS 時，不要同時更換伺服器、修改最後策略並新增 Host 對應，否則即使網頁恢復，也無法判斷是哪項變更真正影響結果。

涉及內網名稱時，也要確認是否只有目前區域網路的解析環境能解析該名稱。離開原本網路後名稱無法解析，可能是環境改變，而非規則檔損壞。反之，在外部網路保留只適用於特定區域網路的固定位址，也可能讓連線持續失敗。網路環境改變後，應先重新核對這些依賴環境的設定。

更詳細的故障排查順序，請參閱延遲正常但網頁無法開啟的 DNS 排查說明。本頁的原則是先確認失敗階段，再修改與該階段直接相關的選項；解析完成後再檢查路由，路由正確後再檢查目標服務，避免把所有問題都歸咎於「換一個 DNS」。

07 URL Rewrite的適用範圍與限制

[URL Rewrite] 依 URL 條件處理請求，與 [Rule] 的連線策略分流不同。前者關注可取得的網址資訊及相應處理動作，後者關注連線採用哪條路徑。若要讓某個網域使用代理，應先考慮網域規則；若要讓明確的舊頁面網址轉向新網址，才需要檢視重寫條件與動作。

先寫清楚完整目標，再縮小正規表示式範圍

重寫規則通常包含比對運算式、目標與處理方式。以下範例示範將精確的舊網址以暫時重新導向方式轉至新網址，僅用於說明語法與比對範圍，不需要實際存取範例網域。實際編輯時，應在目前的 App 中確認該行能正確套用，並以新發出的請求核對結果，而不只是確認檔案能否儲存。

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

運算式開頭的 ^ 限定起始位置，結尾的 $ 限定結束位置；網域中的句點則以 \. 表示字面上的句點。若未跳脫，正規表示式中的句點通常可代表任意單一字元，因而涵蓋原本不想比對的網址。先理解每個符號再修改，比從長運算式中刪改幾個字元更能控制範圍。

此範例不涵蓋子網域、額外路徑或查詢參數。若網址結尾增加問號參數，精確結尾條件可能不再符合預期。確實需要處理參數時，應先決定參數要保留、移除或重新組合，再依目標設計運算式。不要直接加入涵蓋所有內容的寬鬆片段，因為它也可能涵蓋登入回呼、資源路徑或後續頁面。

分別驗證重新導向與連線策略

重新導向會讓請求繼續前往新目標。新目標仍需要解析，也需要依適用的路由條件建立連線。舊網址的網域採用直連，不代表重新導向後的另一個網域也會直連。排查時至少記錄初始網址與最終網址；若只查看第一個請求，很容易誤以為策略未生效，實際失敗的卻是後續目標。

不要用 URL Rewrite 修正伺服器驗證錯誤、協定欄位缺漏或 DNS 服務無法連線等問題。這些問題發生在不同層級，修改網址文字無法補上底層參數。若問題是在建立連線前就逾時，應先檢查伺服器、解析與策略。確認請求已進入可處理階段後，才需要繼續核對正規表示式與重新導向行為。

HTTPS 資訊的可見性需另外了解

HTTPS 的完整路徑與請求標頭位於加密連線中，不能假設加入重寫規則就能讀取並改寫所有內容。具體規則能否套用，取決於協定、App 行為與相關設定條件。涉及憑證信任的設定會改變安全界線，不應視為讓規則生效的預設步驟；一般網域分流也不需要讀取加密內容。

遇到重寫未生效時，先排除運算式未涵蓋實際網址、請求重用舊連線或結果來自快取等原因。不要立刻擴大處理範圍，更不要把所有網域都加入需要額外處理的集合。對於用途無法核實的憑證或設定，應先停止修改、保留原本可用狀態，再逐項確認來源與必要性。規則範圍越廣，驗證成本與影響範圍也越大。

也要避免重新導向循環：若新網址再次符合原本的比對條件，就可能不斷觸發相同動作。測試時檢查網址是否反覆變化、頁面是否提示重新導向次數過多，以及記錄中是否出現重複目標。修正方式是讓舊網址條件足夠明確，並確保目標不再符合相同條件，而不是更換代理伺服器來掩蓋循環。

維護設定時，應分別記錄連線規則與 URL 處理。刪除或停用重寫後，若基本連線恢復，就應繼續縮小這一段的問題範圍，而不是立刻改動整套分流。只需依網域選擇路徑的使用者，可讓重寫段落保持空白或不加入該段；設定是否完整，取決於是否符合實際需求，而非是否將所有可用功能都寫入檔案。

08 設定修改、驗證與故障排查

修改設定應形成可還原的完整流程：保留原始檔案、訂定明確目標、只修改一組相關條件、重新發出請求，再核對實際命中與連線結果。每次驗證最好只回答一個問題，例如「這個完整網域是否走代理」，而不是同時判斷解析、協定、所有頁面資源與整套規則是否正確。問題越明確，結果越容易解讀。

建立精簡的核對紀錄

開始前記錄目前選取的設定、Global Routing 模式、已選用的伺服器、網路環境與測試目標。紀錄不需要包含訂閱網址或驗證資訊。若要向他人描述故障，應先隱藏密碼、完整訂閱連結與其他識別資訊；本機記錄中的查詢參數也可能含有敏感內容，不能只遮住伺服器名稱就認為已處理妥當。

  1. 在 Config 中確認目前使用的檔案並保留副本，明確標出準備修改的段落。
  2. 檢查英文標點、段落位置、策略拼寫與最後規則的位置；儲存後確認檔案可正常讀取。
  3. 切換回用於驗證的 Config 模式，並確認連線開關處於預期狀態。
  4. 重新開啟目標頁面或發出新請求，對照連線記錄中的目標、命中規則與策略。
  5. 若結果不符，還原最近一組修改，再依失敗階段逐步檢查，不要繼續疊加例外規則。

依據現象縮小檢查範圍

觀察結果優先檢查下一步
設定檔讀取失敗段落名稱、英文標點與欄位數量還原最近的修改，再逐行重新加入
總是命中 FINAL目標類型與前面條件的涵蓋範圍核對實際網域、位址與可用的請求資訊
命中預期策略但連線逾時解析、伺服器與目標可達性分別驗證所選路徑，不要繼續增加規則
部分資源載入失敗子資源網域與重新導向目標針對失敗的請求檢查，不要擴大整份清單
更換網路後出現異常區域網路對應、解析條件與 IP 版本重新核對依賴環境的設定，再測試相同目標

若所有請求都命中 FINAL，先確認目前使用的是否真是剛編輯的檔案，再檢查網域欄位是否誤帶完整網址，以及前面的條件是否依賴無法取得的資訊。若只有一個目標不符預期，搜尋所有可能涵蓋它的條件，尤其是較早出現的後綴與關鍵字。最後規則只是顯示前面沒有命中的結果，不應成為最先反覆修改的項目。

若命中策略正確但連線仍失敗，先不要新增規則。確認使用者既有的伺服器資訊與相應協定一致，包括位址、連接埠、驗證與傳輸相關欄位。不同協定的相似欄位不一定能互換；修改規則也無法修復驗證失敗。需要辨認欄位時，可參閱VMess 與 VLESS 欄位說明，並依使用者既有服務資訊逐項核對。

分開管理訂閱、設定與伺服器

訂閱更新後若出現變化，應先比較伺服器清單與目前選取項目，不要假設規則檔也有變更。刪除重複項目之前，先確認它屬於哪個既有訂閱，避免手動匯入與訂閱更新同時保留相同內容。關於群組、更新與重複項目的處理方式，可接著參閱多個訂閱的管理說明；分享內容的類型則請見單一節點連結與訂閱網址的差異。

完成驗證後，保留一份最終有效的修改說明，記下目標、原因與檢查結果。已失效的臨時例外應及時移除，避免多次排查後留下互相覆蓋的規則。遠端設定重新取得後，也要再次檢查本機差異。長期維護的重點不在規則數量，而在每組條件是否仍能說明用途、是否有明確目的，以及發生異常時能否還原。

最後再確認 App 的取得方式與使用範圍。Shadowrocket 主要適用於 iPhone、iPad；Mac、Apple TV、Apple Vision 的相容性與購買適用範圍，請以 App Store 頁面標示為準。App 更新透過 App Store 管理；本頁設定範例不會改變系統需求，也不包含網路服務。購買前請核對開發者 Shadow Launch Technology Limited、官方圖示與 App ID 932747118。

若尚未完成基本操作，請返回教學依流程重新核對；若已定位到具體問題，可在疑難排查查找相應分類。保留一份能穩定重現結果的最精簡設定，再逐步還原其他規則，通常比不斷新增涵蓋範圍廣的條件更容易找出原因，也能減少對原本正常連線的影響。