官方手冊 · 設定參考

Shadowrocket 規則與設定指南

從設定檔段落到最終策略，依請求處理順序核對規則。

Shadowrocket 是僅透過 App Store 發行的 Apple 平台付費用戶端，主要供 iPhone 與 iPad 使用。首次使用時，請先依快速入門教學匯入既有訂閱並驗證連線；本頁用於查閱設定結構、規則範圍與故障排除方式，不取代首次連線的操作流程。

以下範例均以使用者已有訂閱或伺服器資訊為前提。用戶端一次性購買 ≠ 連線服務方案；購買 App 與取得連線服務是兩回事。正版取得與購買項目還原方式請參閱App Store 下載與核驗說明；系統需求與相容範圍以 App Store 頁面標示為準。

01 設定檔結構與修改範圍

在 Shadowrocket 中，伺服器資訊、訂閱項目與設定檔各有不同用途。伺服器資訊描述連線端點與協定參數；訂閱用於匯入並更新使用者已有的一組連線資訊；設定檔則負責組織一般設定、比對條件與處理策略。在 Home 看得到伺服器，不代表目前的 Config 已包含適用於該請求的規則；反過來說，規則完整的設定檔也無法補上缺少的伺服器位址、密碼或協定參數。開始排除問題前，應分別確認這三個層面，避免把所有問題都歸咎於規則。

先辨認段落名稱，再理解各行內容

常見設定檔會以方括號中的段落名稱區分內容。[General] 存放一般行為設定，[Rule] 存放依序執行的規則，[Host] 存放靜態網域對應，[URL Rewrite] 存放 URL 比對與改寫項目。段落名稱決定後續內容的解讀方式；同一行文字若放錯段落，可能無法如預期解析。閱讀時應先找到最近的段落名稱，再查看鍵值或規則欄位；不要只因某行出現網域名稱，就判定它是分流規則。

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

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

[Host]
localhost = 127.0.0.1

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

這段範例僅用來說明各段落之間的關係：一般設定使用系統 DNS；規則將範例網域交由 PROXY 處理；部分位址依 GEOIP 判斷；其餘請求交由 FINAL 處理；Host 與 URL Rewrite 則各自負責其他類型的工作。這不代表所有使用者都適合採用這組設定，尤其 DNS、IPv6 與最終策略，必須配合當地網路與使用者既有的連線服務確認。修改時請保留原有必要欄位，不要為了符合範例而刪除尚未了解的設定。

在 Config 中確認目前使用的檔案

開啟 Config 後，先分清楚「檔案已存在」與「目前正在使用」是兩回事。匯入成功只代表內容已加入檔案列表，不代表目前連線已選用該檔案。請確認目前選取狀態，再查看對應檔案內容；需要測試時，先使用 App 目前提供的複製或匯出功能備份，並為副本取一個易於辨認用途的名稱。備份後請再次確認目前使用的項目，避免編輯的是測試檔，實際連線卻仍使用另一份舊設定，最後誤以為變更沒有生效。

檔案來源也會影響修改能否保留。如果設定檔會從遠端網址更新，請先了解再次更新時是否會覆蓋本機編輯內容。使用者訂閱中的伺服器更新與設定檔更新並非同一件事：更新節點清單不一定會變更 Rule，重新取得遠端設定檔也不一定會更新訂閱。若有自訂規則需要長期保留，請記錄新增項目、插入位置與修改目的；遠端內容變更時，應比對差異後重新合併，不要只因檔名相同就認定內容沒有改變。

一次只修改一個層面

建議依「連線資訊正確、已選取設定檔、規則順序正確」的次序建立基準。第一次調整時只修改一條網域規則，保留 General、Host 與改寫段落不動，然後重新發出待測請求。若同時更換伺服器、切換 DNS、變更最終策略並啟用改寫，即使恢復正常，也無從判斷是哪項變更起了作用；若仍失敗，也沒有明確的回復依據。請用一句具體文字描述修改目的，例如「讓範例網域及其子網域使用 PROXY」，會比「最佳化所有規則」更容易驗證。

還原檔案時也應分層處理。換回原設定檔後，再確認目前的路由模式與選取的節點；必要時中斷連線並重新連線，之後再送出新的請求。舊連線、快取頁面與背景重試可能延續修改前的狀態，不宜只憑這些現象判斷設定是否已還原。若尚未完成首次匯入，請先返回教學流程完成基本連線驗證，再閱讀本頁後續章節；這樣可避免連線端點無法使用時，反覆修改無關的規則。

02 General、DNS 與位址解析

[General] 控制一組一般行為設定，但它不是「速度參數集合」。其中的 DNS、IPv6、系統流量繞過等設定，會影響請求進入規則判斷前後可取得的資訊，也可能改變網路相容性。檢視既有設定時，應將每個鍵值與 App 內相應說明一併核對，不要把其他人的設定視為通用標準。尤其在 Wi-Fi 與 Cellular 之間切換後，網路提供的解析器、位址類型與可用路徑可能改變；相同設定出現不同結果，不一定代表規則文字有誤。

DNS 負責解析，不等於最終策略

存取網域通常需要取得目標位址。DNS 回答網域對應哪個位址；Rule 則決定符合條件的請求採用哪種策略。兩者彼此相關，卻不能互相取代：網域解析成功後，PROXY 指向的連線仍可能失敗；IP 規則結果異常，也可能是實際解析出的位址與預期不同。排查時，先記錄存取的網域，再確認解析是否成功、回傳哪些位址，以及請求最後符合哪條規則；不要把「無法開啟」直接等同於「DNS 有問題」。

[General]
dns-server = system
ipv6 = false

dns-server = system 表示此設定使用系統 DNS，不是手動指定固定的公共解析位址。這適合用來了解現有網路行為，但不保證適用於所有網路。若網路有內部網域，任意更換解析器可能導致內部名稱無法正確解析；若系統解析本身異常，也需要先檢查目前的網路。修改 DNS 前請保留原值，修改後以新的解析與連線結果驗證，不要只重新整理一個可能已被瀏覽器快取的頁面。

IPv6 開關應依連線可達性判斷

ipv6 = false 在此範例中會關閉相關 IPv6 行為，並非普遍適用的效能建議。支援 IPv6 的網路與服務可能有不同於 IPv4 的連線條件；關閉後若觀察到變化，只能表示值得進一步檢查位址類型或連線路徑，不能據此判斷某種位址類型一定比較快。若需要啟用 IPv6，應一併確認目標是否提供 IPv6 位址、所用伺服器與協定是否能如預期處理，以及 Rule 中是否有相應的 IP-CIDR6 項目。

使用位址規則排錯時，必須採用本次請求實際使用的位址。如果只檢查 IPv4 網段，但請求選用的是 IPv6，原有判斷就缺乏依據。也不要把單次測試得到的位址固定成長期 Host 對應：相同網域可能因網路、地區或服務調度而回傳不同位址；固定後反而可能略過正常的可用性調整。應先透過網域規則選擇連線路徑；只有明確需要靜態對應時，再評估 Host 的維護成本與適用範圍。

了解系統流量繞過與規則記錄的界線

bypass-system = true 涉及系統流量的繞過行為，應依照 App 目前的說明確認具體範圍。這不代表所有業務請求都會逐一進入同一組 Rule，也不保證啟用後各個 App 的行為都一致。若某次存取沒有出現預期記錄，除了檢查規則，也應考慮請求是否沿用舊連線、是否由系統元件發起，或是否符合其他繞過設定。請先確認待測請求確實進入目前的連線處理流程，再檢查 Rule 的比對順序。

可重複執行的測試流程如下：先保留系統 DNS 作為基準，選定單一網域並記錄解析與存取結果；只修改一項解析相關設定，再重新連線並送出新請求；最後比較位址、符合的規則與錯誤發生階段。若變更 DNS 後只有某個網路恢復，應進一步檢查該網路提供的解析服務，不要立刻將新設定套用到所有裝置。規則設定的目標是讓行為可解釋；某次成功開啟頁面只是其中一項證據，不足以證明所有請求都符合預期。

若同一設定在家中 Wi-Fi 正常，切換到 Cellular 後卻異常，請先分別記錄測試條件。確認是否有 On Demand 條件改變連線狀態，再核對 Global Routing、目前伺服器與位址解析結果。相關觸發條件可參閱On Demand 按需連線說明。將網路變化與解析變化分開檢查，通常比連續更換多組 DNS 設定更容易找出穩定且可重現的原因。

03 DOMAIN 系列規則與網域範圍

網域規則適合表達「某個名稱或一組名稱應採用哪種策略」。相較於將單次解析結果寫成固定 IP，網域規則更貼近服務名稱，通常也更容易維護。常見類型包括 DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD；三者的差異在於比對範圍，而非優先順序。Shadowrocket 依清單順序檢查；範圍較精確的規則如果排在範圍較廣的規則之後，仍可能沒有執行機會。選擇類型時，先描述目標範圍，再決定條件；不要先複製規則，才猜測它會涵蓋哪些請求。

DOMAIN：只比對完整網域名稱

DOMAIN,api.example.com,PROXY 用於比對指定的完整網域名稱。適合將 API 子網域與同一網站的其他子網域分開處理。這裡的值不是 URL，不包含 https://、路徑、查詢參數或連接埠。若要處理特定頁面路徑，單靠 DOMAIN 無法表達，因為相同網域下的不同路徑仍符合相同的網域條件。將瀏覽器網址列中的完整網址貼到網域欄位，是常見的比對失敗原因。

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

此範例分別處理兩個完整網域名稱，其他子網域則交由後續規則處理。驗證時，請確認請求實際使用的名稱與規則中的名稱相符：頁面可能先存取主網域，再跳轉至登入網域，接著從另一個靜態資源網域載入內容。主頁面成功開啟，不代表所有資源都採用相同策略。請從請求記錄找出發生問題的具體網域，再決定新增精確規則或擴大比對範圍；不要一遇到資源載入失敗，就讓整個網站的所有網域都使用相同策略。

DOMAIN-SUFFIX：比對網域及其子網域

DOMAIN-SUFFIX,example.com,PROXY 用於涵蓋範例網域及其子網域，適合統一處理同一網域樹。它依網域邊界比對，不是比對任意字串是否包含；例如 notexample.com 不會只因尾端字元相似，就被視為該網域樹的一部分。撰寫時通常直接填入根網域，不必在前面加星號，也不要將路徑寫入值中。如果只想讓某個 API 直連，可以先寫完整網域的例外，再寫後綴規則。

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

這個順序明確表示「API 例外優先，其餘範例網域使用 PROXY」。若將兩行對調，API 請求會先符合後綴條件，後面的精確例外便沒有機會生效。DOMAIN 並沒有天生優先於 DOMAIN-SUFFIX 的特殊規則，結果取決於條目位置。維護大量網域時，可先將同一業務的精確例外放在一起，再列出範圍規則，並在變更記錄中說明例外原因，避免日後整理時誤刪。

DOMAIN-KEYWORD：謹慎使用字串比對範圍

DOMAIN-KEYWORD,example,PROXY 會依網域中的關鍵字比對，涵蓋範圍通常比後綴規則廣。適合目標確實由穩定關鍵字定義的情況，但也容易比對到原本不打算處理的其他名稱。關鍵字若短到只有常見片段，誤比對風險會更高；不能因為一次測試有效，就認定它等同於某項服務的完整網域集合。若需要可預測的範圍，優先使用明確的 DOMAIN 或 DOMAIN-SUFFIX 項目。

類型	比對範圍	檢查重點
`DOMAIN`	指定的完整網域名稱	不含通訊協定、路徑與連接埠
`DOMAIN-SUFFIX`	網域及其子網域	例外項目應排在前面
`DOMAIN-KEYWORD`	網域中的關鍵字	檢查是否涵蓋不相關的名稱

網域比對也取決於用戶端能否取得相應名稱。若連線資訊只顯示 IP，就不能假設它一定符合 DOMAIN；對已建立的長連線，修改規則也不一定會立即反映在舊的連線工作階段。驗證時請建立新連線，查看記錄中的實際目標與符合項目；必要時先關閉相關 App，再重新送出請求。如果問題是「某個網域始終沒有套用例外」，先檢查上方是否有範圍更廣的規則，再確認是否取得名稱資訊，最後才檢查解析與快取。

04 GEOIP、IP-CIDR 與其他規則

除了網域規則，IP 規則會直接依目標位址判斷。它們適用於已知網段、內部服務及依位址歸屬分類的需求，但無法自動涵蓋某個網站的所有業務範圍。網站可能使用多個位址，同一位址也可能由多項服務共用；若將單次解析得到的位址擴大成整個網段，其他目標也可能一併符合規則。設定位址條件前，應先確認要比對的是固定位址、受控網路範圍，還是依賴資料庫歸屬判斷的集合；這三種需求應分別處理。

IP-CIDR 與 IP-CIDR6 的範圍

IP-CIDR 用於 IPv4 網段，IP-CIDR6 用於 IPv6 網段。斜線後的數字代表網路前綴長度，不是連接埠號碼；IPv4 的 /32 代表單一位址，IPv6 的 /128 代表單一位址。前綴越短，通常涵蓋的範圍越大。內部網路應依實際網段填寫，不要只因位址開頭相似就任意擴大範圍。範例中的文件保留位址僅用來說明格式，不代表實際連線目標。

[Rule]
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR,198.51.100.0/24,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

no-resolve 可避免僅為嘗試比對此 IP 條件而額外進行網域解析。它不是「忽略所有 DNS」的開關，也不保證整個請求流程完全不需要解析。如果請求只有網域資訊，尚無可供判斷的目標位址，就不應假設含此選項的 IP 條件一定會符合；之後仍會繼續檢查其他適用規則。是否使用此選項取決於規則目的：避免額外解析，與利用解析結果進行位址分類，是不同的取捨。

GEOIP 用於判斷 IP 位址歸屬

GEOIP,CN,DIRECT 會依可用的位址歸屬資料，判斷目標是否屬於指定的地區代碼。這裡檢查的是 IP 歸屬，不是網域後綴、頁面顯示的語種或使用者所在位置，也不保證能完整反映服務的實際部署情況。相同網域在不同網路下可能解析出不同位址，因此比對結果也可能不同；資料庫分類與服務實際營運情況之間也可能存在差異。因此，對於必須固定策略的特定網域，應在 GEOIP 前加入明確的網域規則，不要期待地區分類取代業務例外。

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

此順序會先指定 API 的策略，再對其他可判斷的目標套用 GEOIP，最後由 FINAL 處理。若 API 本次解析出的位址符合 CN，仍會先符合前面的 DOMAIN，使用 PROXY。反過來說，若將 GEOIP 放在前面，API 可能在符合地區條件時就結束比對。檢查這類問題時，必須同時確認實際位址與規則位置；不能只列出一個網域和一個地區標籤，就判定用戶端判斷錯誤。

USER-AGENT 的適用條件與限制

USER-AGENT 依賴可取得的請求標頭資訊，並不是能可靠識別所有 App 的機制。App 可能修改請求標頭，同一個 App 的不同請求也可能使用不同值；加密連線中的請求標頭也不一定能直接取得。不能因為請求來自某個 App，就假設它一定帶有可供比對的 USER-AGENT。若要穩定選擇服務路徑，應先確認能否用明確的網域與位址表達條件，不要只依 App 顯示名稱推測規則條件。

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

範例中的 ExampleClient* 只用來說明比對值的格式；實際使用時應以可觀察到的資訊及 App 支援的比對方式為準。不要為了讓這條規則符合條件，就直接啟用不了解的流量解密設定；本頁不將 USER-AGENT 視為通用分流的前提。若記錄中沒有請求標頭，改用可觀察的網域或 IP 條件會更容易驗證，也更便於跨網路維護。設定是否易讀，取決於條件是否明確，而非使用的規則類型越多越好。

回歸檢查位址規則時，至少選一個應符合的目標與一個不應符合的目標，並確認兩者都建立了新連線。內部網段也應在不同 Wi-Fi 下分別測試，因為相同位址範圍在另一個網路中可能對應完全不同的裝置。如果問題是整體連線變慢，而非單條規則異常，可繼續閱讀速度變慢的分層排查指南，分別檢查伺服器可達性、本機網路與規則比對。

05 PROXY、DIRECT、REJECT 與 Global Routing

規則末端通常會指定處理策略。PROXY、DIRECT 與 REJECT 分別代表透過代理連線、直接連線與拒絕處理，但它們不等同於 Global Routing 中的三種路由模式。策略是在規則符合後決定如何處理；路由模式則決定目前整體連線採用哪種路由方式。混淆兩者，容易誤以為「寫了 DIRECT 卻仍透過代理」或「修改規則後完全沒有變化」。開始測試前，先查看 Global Routing，再確認目前的 Config，最後檢查實際符合的項目。

設定 / Config：依目前設定檔檢查

設定模式對應的介面名稱是 Config，是驗證 Rule 的主要工作狀態。在此模式下，已進入相應處理流程的請求會依設定條件選擇策略。這不代表所有業務都會自動符合使用者預期，實際結果仍取決於目前的設定檔與相關選項。若選錯檔案、上方有範圍較廣的規則，或 Host 改變了位址，結果仍可能不同。修改規則、記錄畫面或請他人協助時，註明目前採用 Config，比只說「連線已開啟」更有幫助。

代理 / Proxy 與直連 / Direct：作為對照

代理模式對應 Proxy，主要用於檢查代理連線路徑；直連模式對應 Direct，主要用於觀察直接連線的結果。兩者可作為對照條件，但不應視為能覆蓋所有系統流量繞過、位址解析或協定行為的絕對開關。測試時請維持伺服器、網路與目標一致，只切換路由模式；若 Proxy 可存取而 Config 無法存取，應優先檢查規則、最終策略與相關設定。若 Proxy 本身也無法存取，先確認連線資訊與伺服器可達性，不必立刻重寫 Rule。

模式	主要用途	測試時檢查
設定 / `Config`	依目前設定檔選擇策略	選取的檔案、符合的規則、FINAL
代理 / `Proxy`	對照代理連線路徑	目前伺服器、協定參數、可達性
直連 / `Direct`	對照直接連線路徑	本機網路、解析與目標可達性

PROXY 不會建立連線服務

PROXY 只會將符合規則的請求交由相應的代理路徑處理，不會自動建立伺服器資訊，也無法修復已失效的訂閱。請先在 Home 確認選取的伺服器來自使用者既有的連線資訊，並核對位址、連接埠、驗證資料與協定參數。部分協定還涉及傳輸方式、TLS 名稱或其他擴充欄位，不能只因名稱相同就認定參數完整。App 一次性購買與連線服務彼此獨立；規則正確也不代表伺服器一定可用。

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

DIRECT 表示透過目前網路直接連線至目標，不代表目標一定能存取。內部名稱可能需要特定 Wi-Fi 提供 DNS；有些伺服器也可能只允許特定來源位址。DIRECT 失敗時，應檢查本機網路與解析結果，不要立刻改成 PROXY。確認規則是否正確，與確認目標是否可達，是兩個不同問題：即使符合預期的 DIRECT 規則，目標仍可能拒絕連線；這表示規則可能已正確執行，只是連線環境不符合目標要求。

REJECT 應明確限制比對範圍

REJECT 用於拒絕符合條件的請求，適合用於明確確定不需要存取的目標。不要一開始就以範圍過廣的關鍵字或大型位址區段設定 REJECT，否則頁面所需的 API、登入跳轉或資源請求也可能一併遭到封鎖。若頁面部分空白、反覆載入或登入失敗，應檢查相關請求是否符合拒絕項目。刪除規則前，請先在副本中暫時縮小範圍，並以相同操作重新測試，確認問題確實來自該條件後，再保留最小必要的修改。

FINAL 也需要指定策略。例如 FINAL,PROXY 表示未符合前面任何規則時，交由代理路徑處理；FINAL,DIRECT 則表示其餘請求直接連線。兩者代表不同的設定目標，沒有適用所有使用者的預設答案。決定最終策略前，應列出哪些請求需要例外、使用的服務是否可達，以及規則如何維護。更多常見情況請參閱常見問答；排查記錄仍應註明目前的路由模式與實際符合的策略，不要只寫「連線失敗」。

06 比對順序、例外與 FINAL

規則清單的核心原則是由上而下檢查；第一條符合的適用項目會決定策略。不要把它想成先收集所有條件，再自動選出「最精確」的一條；在一般的順序規則中，後面的精確條件不會自動推翻前面的廣泛條件。因此，檢查設定檔時，不只要看有哪些規則，也要看它們的排列位置。排查某條規則未生效時，從清單頂端往下閱讀，通常比只搜尋該行更快，因為真正攔截請求的可能是早已存在的上方項目。

先列出明確例外，再列範圍條件

一種便於維護的排列方式是：先列出具體業務例外，再列網域樹或受控網段規則，接著列一般分類，最後列出 FINAL。這不是唯一合法的結構，但能讓閱讀者清楚了解「為什麼這個目標與多數目標不同」。例如，API 必須使用 PROXY，而同一網域樹下的其他請求要使用 DIRECT，就應將 API 的 DOMAIN 規則放在 DOMAIN-SUFFIX 前面。若之後新增關鍵字規則，也要重新檢查它是否越過原有的例外範圍。

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

對 api.example.com 的新請求，第一行已符合條件，因此不應再以後續的後綴條件解釋結果。對 static.example.com 的請求，第一行不符合，才會繼續檢查第二行。未符合網域規則的目標，再檢查位址條件與 GEOIP。這種閱讀方式也適合人工檢查：逐行註記目標是「符合」或「不符合」，找到第一條符合的規則，就能判斷設定是否符合修改目的。

FINAL 是預設處理，不是用來修正規則

FINAL 通常放在 Rule 末尾，為未符合前面條件的請求提供明確結果。若將它放在前面，後續一般規則就沒有執行機會，也容易讓人誤以為後面仍有有效的例外。重複出現 FINAL 通常表示合併設定檔時沒有整理結構；請在副本中保留一條符合目標的末尾預設規則，再檢查前面的項目。不要用新增第二條 FINAL 的方式「覆蓋」第一條，也不要將它當成統計或測試標記。

合併兩份設定檔時，不要只把兩個完整 Rule 段落的內容直接首尾相接。應先整理各自的精確例外，檢查相同條件是否指定了不同策略，再決定廣泛項目的先後順序，最後合併成一條明確的預設規則。重複條件即使語法正確，也可能讓維護者誤判真正生效的項目。整理時不要只依文字去重，也要理解涵蓋關係：一條後綴規則可能涵蓋許多網域名稱不同的完整網域規則。

用衝突案例驗證理解

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

在此範例中，API 請求先符合第一行，因此第二行沒有機會決定結果。修正方式是調整兩行順序，不是更換代理伺服器，也不是再於末尾複製一條相同的 DOMAIN。反過來說，如果第一行的 DIRECT 原本就應涵蓋所有子網域，就應刪除沒有實際作用的後續例外，讓檔案反映真正的設定目的。規則越少不一定越好，但每一條保留的規則都應有明確的適用範圍與測試依據。

修改規則後，請考量連線重用造成的觀察延遲。已建立的連線可能沿用原有路徑，重新整理網頁也不一定會建立你預期的新連線。請先儲存設定並確認已選取正確檔案，再重新建立連線，之後執行新的測試操作。若要比較結果，請固定使用同一網路、同一伺服器與同一目標，避免把網路切換造成的位址變化誤認為規則順序的影響。對於動態配置位址的網域，也應記錄每次測試的實際解析結果。

最後進行反向檢查：除了確認目標例外已生效，也要確認相鄰業務沒有受到新規則影響。例如將精確網域改為關鍵字後，至少檢查一個包含相同字串但無關的名稱。將 GEOIP 移到前面後，也要確認原本必須固定使用 PROXY 的 API 仍會先符合例外。維護規則是在維護條件之間的界線，不是持續在末尾新增項目；每次整理都應保留可回復的副本，並重新執行一組固定測試。

07 Host 與 URL Rewrite 的作用範圍

Host 與 URL Rewrite 常會同時出現在設定檔中，但它們與 Rule 解決的不是同一個問題。Host 透過靜態對應影響名稱解析結果；URL Rewrite 依 URL 條件進行改寫或重新導向；Rule 則負責選擇處理策略。網域符合 PROXY，不代表解析或改寫一定正確；新增 Host 也不會自動讓請求改為直連。排錯時應分別停用或還原相關設定，觀察「目標變成什麼」與「目標透過哪條路徑連線」，不要混為一談。

Host 固定名稱與位址的對應關係

[Host]
localhost = 127.0.0.1
test.example.com = 192.0.2.10

第一行是常見的本機名稱對應範例，第二行以文件保留位址說明語法，並非可用服務。實際使用時，只有在明確知道目標位址且確有測試需求時，才應固定對應。網站的正常解析可能包含多個位址與容錯切換機制；Host 則會將本機觀察結果固定為指定位址。服務位址若有所變更，原本可用的對應可能成為故障來源。因此，請為每條自訂對應記錄用途，並在臨時測試結束後評估是否移除。

靜態對應通常不會改變請求使用的網域名稱，也不能取代 TLS 中的名稱驗證。將 HTTPS 網域指向另一台伺服器後，該伺服器仍須能正確處理原網域並提供相符的憑證；只要位址可連線就認為一定能存取，是常見誤解。若出現憑證名稱不符，請先恢復正常解析或檢查伺服器設定；不要將憑證錯誤歸咎於 DOMAIN-SUFFIX 策略，也不要以關閉驗證掩蓋目標對應錯誤的問題。

URL Rewrite 比對 URL 條件

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

此範例會將符合條件的 HTTP 位址重新導向至範例 HTTPS 位址。正規表示式中的 ^ 表示起始位置，\. 表示網域中的字面句點，結尾斜線則用於收緊比對範圍。若句點未跳脫，在正規表示式中可能代表任意字元；若網域後缺少適當的邊界，也可能符合原本不打算處理的位址。此處的目標位址是固定值，不要假設它會自動保留所有路徑與查詢參數。

302 表示重新導向回應。重新導向會讓用戶端存取新的 URL，不是在原始請求中悄悄替換所有連線行為。新的請求仍須進行解析、選擇路由並完成連線；若目標無法連線，即使改寫成功，頁面仍不會正常開啟。測試時應分別確認原始位址是否符合表示式、回應是否指向預期目標，以及後續請求是否正常處理。只看到瀏覽器網址變更，不能證明後續資源請求也都正確。

先確認可觀察範圍，再啟用改寫

HTTP 與 HTTPS 可見的資訊不同，不能假設只要在設定中加入規則，就能直接讀取所有加密請求的完整 URL。若需要觀察額外內容，請先閱讀 App 目前的相關說明，並評估涉及的憑證與信任設定。本頁的一般規則分流不需要啟用流量解密，也不將其作為修復存取問題的預設步驟。若目的只是替某個網域選擇 PROXY，使用 Rule 即可，無須為了比對路徑引入額外處理層。

容易維護的改寫規則應說明原始比對範圍、目標位址與預期回應。複製含有擷取群組的複雜正規表示式時，請先確認替代字串如何引用擷取內容，再分別測試最簡單的路徑與含查詢參數的路徑；不要因表示式語法相似，就認定它們效果相同。臨時診斷用規則應與長期使用的規則分開記錄，結束後再清除，避免日後存取其他路徑時觸發遺留行為。複雜不代表更精確；能滿足實際需求的最簡表示式通常更容易檢查。

合併排錯時，先保留正常 DNS 與最精簡的 Rule，確認目標本身可達，再加入 Host 或 URL Rewrite。若只有加入 Host 後才失敗，請檢查位址與憑證；若只有加入改寫後才失敗，請檢查比對範圍、目標與循環；若移除兩者後仍失敗，再回頭檢查伺服器與網路。依此順序處理，可避免用更多規則補償錯誤對應或錯誤重新導向，也能清楚確認最後保留的每個段落實際解決了什麼問題。

08 設定驗證、故障排除與回復

完成編輯後，驗證應以明確目標為準，不要只用「網頁能開啟」作為結論。先說明預期結果：使用哪個網域、處於什麼網路、使用哪台伺服器、應符合哪條規則，以及預期採用 PROXY、DIRECT 還是 REJECT。接著確認目前的 Config 與 Global Routing，再送出新的請求並觀察結果。即使請求失敗，也能據此判斷規則是否正確執行，以及問題發生在解析、連線、驗證或目標回應階段，而不是繼續盲目增刪項目。

建立可重複的測試記錄

每次測試都記錄目標、網路環境、選取的伺服器、設定檔與比對結果。至少準備三類目標：明確應使用 PROXY 的例外、明確應使用 DIRECT 的例外，以及應交由 FINAL 處理的一般目標。若涉及拒絕規則，再增加一個預期採用 REJECT 的目標。請使用使用者實際有權存取的服務，不必為了測試而尋找新的連線服務。比較兩輪結果時，除了正在修改的項目外，其他條件應盡量保持不變。

觀察項目	記錄內容	異常時優先檢查
設定狀態	目前的 Config 與 Global Routing	是否編輯了未選取的檔案
解析結果	目標網域與實際位址	DNS、Host、位址類型
規則結果	第一個符合的項目與策略	上方的廣泛規則、FINAL 位置
連線結果	失敗階段與錯誤訊息	伺服器參數、本機網路、目標狀態

將 Connectivity Test 與業務請求分開檢查

Connectivity Test 可協助判斷特定測試條件下的連線狀況，但測試成功不代表每個網站、每種請求與每條分流規則都能正常運作。業務請求可能使用不同網域、位址類型、連線方式或驗證流程。反過來說，某項測試失敗也不代表所有業務都無法使用，應先查看測試對象與錯誤訊息。正確做法是先用測試工具縮小問題範圍，再以實際業務的新請求確認規則與路徑，不要把單一結果當成整體網路狀態。

若所有 PROXY 請求都失敗，先保留最精簡的設定，核對目前的伺服器與使用者既有服務狀態；若只有某個網域失敗，檢查符合的規則、解析結果與目標回應；若頁面主體可用但資源缺漏，分別查找資源網域與 REJECT 項目；若只有切換網路後才失敗，記錄 DNS、On Demand 與位址類型的變化。這種分流排查方式比一次修改所有 General 參數更有效，也能避免因單一業務 API 異常而破壞原本正常的其他規則。

記錄僅保留必要資訊

利用 App 提供的記錄查看目標、符合的規則與錯誤階段，但不要將訂閱連結、密碼或驗證欄位直接貼到公開討論區。需要保存排錯資料時，請先檢查截圖與文字是否包含敏感資訊，再提供足以重現問題的最小規則片段。伺服器名稱也可能包含使用者自訂標記，請一併確認。分享完整設定檔不會自動提升排錯效率；清楚記錄請求條件與第一個符合的項目，通常比大量未整理的記錄更有幫助。

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

上述最小片段可以說明規則順序，不會揭露連線憑證。整理問題時，可用範例網域取代實際業務名稱，同時保留「精確例外在後綴規則之前」等結構關係；若問題取決於實際位址歸屬，應註明資料已去識別化，避免讀者將範例位址當成真實測試結果。重現資料需要足以說明邏輯，但不必包含使用者的訂閱或伺服器驗證資訊，更不要把私人連結放在問題標題或檔名中。

回復設定並確認遠端更新未再次覆蓋

出現不符合預期的行為時，先還原修改前的副本，確認已選取該檔案，再恢復原本的 Global Routing 與伺服器選擇。重新建立連線後，執行相同的一組測試。若還原後立即恢復正常，可逐項重新加入修改以找出最小差異；若還原後仍然失敗，請檢查網路與服務狀態是否也有變化。遠端設定再次更新可能覆蓋本機修改，因此完成回復後也應核對檔案內容，不要只看列表中的名稱是否與上次相同。

日常維護時，可保留一份穩定設定、一份測試副本與簡短的變更記錄。新增規則後執行固定測試；訂閱更新後確認選取的節點仍符合預期；更換裝置後重新核對設定是否已匯入，不要假設 App 的已購狀態會同步所有連線資訊。iPad 的取得與購買項目關係請參閱iPad 已購 App 與使用說明；還原購買項目只處理 App 的取得，不會取代設定遷移與伺服器參數核對。

需要重新完整走過連線流程時，返回Shadowrocket 使用教學；要快速查找常見情況時，查看問答與故障排除；要確認 App 來源時，前往正版三項核驗。請在商店頁一併核對 App 圖示、開發者 Shadow Launch Technology Limited 與 App ID 932747118。設定維護應以容易理解、可驗證、可回復為準，不應以規則數量或檔案長度評斷品質。