Shadowrocket 規則與設定檔參考

01 · 設定檔結構與編輯原則

先分清 Subscribe 與 Config

Subscribe 通常用於更新伺服器清單，Config 則用於管理連線行為與請求分流；兩者可以分別來自不同的既有來源。伺服器清單中能選取節點，只表示連線參數已匯入用戶端，並不代表某份規則已啟用。反過來說，匯入內容完整的設定檔，也不代表其中指定的代理出口一定可用。開始編輯前，請分別確認 Home 中選取的伺服器、Config 中正在使用的檔案，以及 Global Routing 目前的模式，避免把三種不同狀態當成同一個開關。

設定檔以方括號中的段落名稱區分用途。General 放置全域連線與解析設定，Rule 放置依序比對的分流規則，Host 用於指定主機名稱的解析對應，URL Rewrite 用於改寫符合條件的請求網址。段落名稱不是一般說明文字，不能用中文標題取代方括號中的名稱。同一檔案中的設定項目應放在對應段落下；例如 FINAL 是 Rule 中的規則，不能省略段落標記，直接接在 General 設定後面，否則解析結果可能與預期不同。

# 結構範例：僅展示各段落用途
[General]
dns-server = system

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

[Host]
intranet.example.com = 192.0.2.10

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

複製檔案，建立可復原的修改流程

上述片段並非適用於所有網路的完整設定。尤其 Host 對應使用了文件專用位址，實際使用時應刪除這筆示範項目，或換成使用者確實管理的內部位址。編輯現有檔案前，先保留一份可正常運作的副本，記下所選檔名與模式，再另存測試檔。每次只調整一種行為，例如先新增一條 DOMAIN 規則，確認命中後再調整 DNS。同時修改四個段落，即使頁面恢復正常，也無法判斷究竟是哪一項發揮作用。

純文字設定檔使用半形英文標點。等號、逗號與方括號不可換成全形字元；從排版文件複製內容時，尤其要檢查自動替換的引號與不可見空白。整行註解可用井字號開頭，說明文字最好另起一行，不要把較長的中文說明直接接在規則策略後面。副檔名本身不能證明內容有效，將任意文字改成 .conf 也不會自動補上語法。儲存後應回到 Config，確認檔案可正常載入，並確認選取的是剛修改的副本。

本機編輯與遠端更新的關係

遠端設定檔再次更新時，可能會覆蓋本機內容。若要長期保留個人化規則，應先確認目前檔案是否由遠端更新管理，再選擇本機副本或應用程式實際提供的編輯方式。不要只憑「剛才已儲存」判斷修改已保留；較可靠的方式是重新開啟檔案，檢查目標規則仍在預期位置，並在更新後再次驗證。訂閱連結可能包含存取憑證，不應寫入公開筆記或故障截圖；向他人描述問題時，提供規則類型與錯誤現象即可。

若檔案包含本頁未列出的段落或欄位，不要為了比照範例而整段刪除。既有設定可能還負責本機網路、解析或特定請求處理。先了解對應欄位的用途，再決定是否保留；不確定時，回到原始副本測試。查閱本頁時，先確認段落用途，再查看具體規則，最後核對策略與比對順序。依此順序可分開檢查「語法可載入」與「實際行為正確」，避免只因檔案看起來完整，就認定設定可用。

02 · General、DNS 與連線前提

全域設定不能取代分流規則

General 中的項目會影響連線與解析的基礎行為，Rule 則決定符合條件的請求使用哪種策略。兩者彼此相關，但不能互相取代。例如，修改 DNS 伺服器可能改變目標網域解析出的位址，卻不會把明確的 DOMAIN 規則從 PROXY 改成 DIRECT；修改 Rule 也無法修正拼錯的伺服器位址。排錯時應將目標網域解析、目標請求分流、代理伺服器連線分成三件事，逐一驗證，不要把所有無法開啟的情況都歸咎於「規則不好用」。

[General]
# 使用目前系統提供的 DNS
dns-server = system

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

這段設定表示先將完整網域 example.com 交由 PROXY，其餘未命中的請求交由 DIRECT。dns-server 的 system 值表示使用系統提供的解析設定，但不保證目前網路一定能正確解析所有網域。若切換網路後行為改變，應先檢查系統網路與解析條件，再考慮應用程式設定。不要直接複製陌生設定中的多個 DNS 位址；解析服務是否可連線、回應結果與目前網路是否相容，都需要驗證，項目較多不代表查詢更可靠。

網域規則與 IP 規則判斷的資訊不同

DOMAIN 與 DOMAIN-SUFFIX 判斷主機名稱，IP-CIDR 與 GEOIP 判斷位址。當請求保留網域資訊時，前面的網域規則可以先決定出口；當規則需要位址、但目前只有網域時，則可能進行解析。解析出的位址也可能隨網路、快取與伺服器端調度而變化，因此同一網域不保證每次都命中同一條位址範圍規則。診斷紀錄中要同時查看請求網域與實際目標位址，不能只把瀏覽器網址列當成完整的連線資訊。

IP-CIDR 使用 no-resolve 的用途，是避免為了這條位址規則主動進行網域解析；它不是「整個用戶端不使用 DNS」，也不表示所有網域都會被忽略。若請求已帶有可供判斷的位址，仍可能符合相應網段；若只有網域而沒有適用的位址，則應繼續檢查後續規則。是否加入此參數，取決於希望規則在哪個階段參與判斷，而不是把它當成所有 IP 規則都必須附帶的效能開關。

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

IPv6、區域網路與快取的適用範圍

IPv4 網段規則不會自動涵蓋 IPv6 位址。若網路與目標服務使用 IPv6，請檢查是否需要相應的 IP-CIDR6 規則，並確認現有連線設定允許哪些位址路徑。單純停用某種位址類型可能暫時改變症狀，但無法證明問題根源已解決。區域網路裝置也不一定都能透過主機名稱存取：有些依賴本機探索，有些使用固定位址，還有些服務監聽不同連接埠。先確認目標裝置是否位於同一網路，再判斷分流是否相關。

解析快取與已建立的連線可能讓測試結果延遲。修改 DNS 或 Host 後，瀏覽器可能繼續重用原有連線；此時應重新發出請求，必要時重新連線，再查看新的診斷紀錄。不要因為舊頁面沒有立即變化就接連增加設定。對於既有設定中的 ipv6、bypass-system 等項目，應依照應用程式內的說明了解其作用範圍，不要只憑欄位名稱猜測。尤其是系統服務或本機網路的處理方式，也可能受作業系統自身的連線路徑影響。

遇到「網域打不開、直接使用位址卻能連線」時，不要立刻判定應設定 Host。許多服務仰賴正確的 Host 要求標頭、TLS 憑證名稱與伺服器端路由，使用位址存取本來就可能失敗。應分別記錄解析是否成功、連線是否建立、憑證是否通過，再決定下一步。其他情況可參考FAQ 中的規則與故障排查。保留原本可用的設定，只在測試副本中修改解析項目，是避免網路恢復後留下隱性錯誤的基本做法。

03 · Rule 類型與參數說明

規則先寫條件，再寫策略

多數常用規則依「類型、比對內容、策略」的順序撰寫，欄位之間以半形英文逗號分隔。類型決定後續內容的解讀方式：同樣是 example.com，放在 DOMAIN 後表示完整網域，放在 DOMAIN-SUFFIX 後則表示網域後綴。策略決定命中後的處理方式，不屬於比對條件。FINAL 是特殊的兜底規則，不需要網域或位址參數，因此寫成 FINAL,PROXY；若硬要補上第三個欄位，反而會破壞原本清楚的含義。

如何選擇三種網域規則

DOMAIN,api.example.com,PROXY 只適用於 api.example.com，不會自動涵蓋 www.example.com 或 example.com。若要讓同一網站的根網域與子網域採用相同策略，DOMAIN-SUFFIX,example.com,PROXY 會更合適。後綴比對會依網域層級邊界判斷，不是搜尋任意結尾字串。填寫比對內容時，不要加上 https://、連接埠、路徑或查詢參數；這些都不是網域的一部分，加入後通常無法如預期命中。

DOMAIN-KEYWORD,example,PROXY 會判斷網域中是否出現 example。這可能涵蓋不屬於 example.com 的其他主機名稱，因此不適合只憑品牌字串就對整個網站進行分流。優先使用邊界明確的 DOMAIN 或 DOMAIN-SUFFIX，只有確實需要字串條件時才使用 DOMAIN-KEYWORD。關鍵字 ads 也不等同於精確的廣告清單，可能命中正常業務網域；若用於 REJECT，應先核對實際請求，避免連正常內容一併封鎖。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
DOMAIN-KEYWORD,tracking,REJECT
GEOIP,CN,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
USER-AGENT,ExampleClient*,PROXY
FINAL,PROXY

位址、地區與要求標頭規則的限制

GEOIP,CN,DIRECT 依目標 IP 的地區分類決定策略，不是依網頁語言、網站公司所在地或網域後綴判斷。使用內容傳遞網路的網站可能取得不同地區的位址，位址資料庫也有更新週期與辨識限制。若某網域必須穩定指定出口，應使用明確的網域規則，並放在 GEOIP 之前。IP-CIDR 斜線後的數字代表前綴長度，數值越大通常涵蓋範圍越小；單一 IPv4 位址可用 /32，不能把主機連接埠接在位址後面當成網段。

USER-AGENT 針對可讀取的要求標頭內容，不是「選擇某個 App」的通用方式。加密流量中的要求標頭通常無法直接讀取，因此不要期待一條 USER-AGENT 規則涵蓋所有 HTTPS 請求；也不應為了這條規則任意擴大解密範圍。範例中的星號是比對模式的一部分，ExampleClient 是示範用識別字，不代表真實應用程式。多個應用程式可能共用相同的要求標頭，同一個應用程式也可能在不同請求中使用不同值，因此不能以它取代對實際目標網域的觀察。

規則表應以實際需求為準，保持簡潔。若只需讓一個完整主機名稱改走代理，就不必先加入寬泛關鍵字、整個地區與大型網段；反之，若要控制網站所有子網域，也不必手動列出目前看到的每個主機名稱。先用最精簡的條件重現預期行為，再決定是否擴大範圍。不熟悉的關鍵字可搭配術語手冊查閱，但最後仍應依據目前請求是否命中來判斷，而不是只看規則名稱推測效果。

04 · PROXY、DIRECT、REJECT 與模式

規則策略與 Global Routing 是兩層選擇

PROXY 表示將命中的請求交由目前的代理出口處理，DIRECT 表示直接連線至目標，REJECT 表示拒絕該請求。這三種策略不分別對應三組伺服器參數，也不代表設定會自動建立名為 PROXY 的節點。使用 PROXY 前，請確認使用者既有的伺服器資訊已正確匯入，並在 Home 選取適合的出口。若目前檔案使用自訂策略組名稱，則需確認該名稱已在設定中定義、拼字一致，且群組內有可用的出口可選。

Config 模式才是驗證 Rule 分流的主要環境。Proxy 與 Direct 模式可用來對照連線路徑，但不能用來證明某條 Rule 的順序正確。作業系統服務、區域網路與應用程式的實際設定，也可能有特定處理範圍；不要把模式名稱理解成能無限制涵蓋裝置的所有流量。切換模式測試時，請記下原本設定；測試結束後切回 Config，再以新請求確認規則行為，避免忘記切回而影響後續判斷。

DIRECT 不等於「停用用戶端」

DIRECT 規則表示目標請求採用直接連線策略，不代表關閉 Shadowrocket，也不會讓設定檔其餘內容全部失效。用戶端仍可能處理其他請求、執行解析或記錄診斷資訊。區域網路位址、內部服務或原本就能直接存取的網域，可以設定更具體的 DIRECT 條件。直接連線是否成功，仍取決於目前網路的路由、防火牆與目標服務；DIRECT 不是能繞過所有連線限制的修復方式。

[Rule]
DOMAIN,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,blocked.example.org,REJECT
FINAL,DIRECT

這段片段將 intranet.example.com 設為後綴規則之前的例外，因此它會直接連線，而 example.com 的其他主機名稱仍可能走 PROXY。blocked.example.org 則會遭到明確拒絕。最後一行 FINAL,DIRECT 表示其餘請求直接連線，不代表前面已命中的請求還會重新回到最後一行。閱讀設定檔時，應將每一行視為獨立判斷：先看條件，再看策略，最後配合它在檔案中的位置理解實際涵蓋範圍。

REJECT 的影響與連線失敗的差異

REJECT 是主動拒絕，不等於「代理失敗時自動改走直連」。規則刻意拒絕目標後，頁面空白、資源載入不完整或應用程式顯示網路錯誤，都可能是預期結果。使用前應確認目標確實可以封鎖，且不負責登入、圖片或 API 等其他功能。若刪除一條 REJECT 後頁面恢復，應繼續縮小比對條件，不要立刻認定網站所有請求都必須走代理。關鍵字比對範圍越廣，越容易造成這類連帶影響。

PROXY 路徑失敗時，也不要馬上把 FINAL 改成 DIRECT。問題可能出在伺服器位址解析、連接埠連線、協定驗證或目標存取等不同階段；修改兜底策略會同時影響所有未命中請求，反而掩蓋原本的問題。先使用 Connectivity Test 或明確的目標請求，確認目前出口是否可用，再核對使用者既有參數。連線測試結果與特定網站是否可達是兩回事，不能只因一項測試通過，就判定所有目標請求都會成功。

On Demand 處理的是何時建立或恢復連線，而非命中哪個網域；它與 Global Routing、Rule 的用途不同。若連線尚未建立，優先檢查連線狀態與隨選條件；若連線已建立但出口不符合預期，再檢查分流。自訂策略組也可能增加額外選擇，因此排查時應依序核對「目前模式—命中規則—指定策略—實際出口」。更詳細的模式說明請參閱代理模式，不要以反覆切換連線取代策略鏈檢查。

05 · 比對順序、優先級與兜底

先命中者生效，不會依規則名稱自動排序

Rule 中常用規則會依檔案順序由上而下判斷，已先命中的請求通常不會繼續等待後面更精確的規則。DOMAIN 不會因為「看起來更精確」就自動取得高於 DOMAIN-SUFFIX 的優先級，IP-CIDR 也不會天生優先於 GEOIP。優先級首先由位置決定。整理規則時，應先放明確例外，再放一般範圍，最後安排兜底。這樣更容易閱讀，也能減少日後新增規則時產生的覆蓋衝突。

[Rule]
# 特定主機先列為例外
DOMAIN,api.example.com,DIRECT
# 同網站的其他請求使用代理
DOMAIN-SUFFIX,example.com,PROXY
# 未命中請求直接連線
FINAL,DIRECT

依照這個順序，api.example.com 會在第一行命中並使用 DIRECT；www.example.com 不符合第一行，但會命中第二行並使用 PROXY。若交換前兩行，api.example.com 會先落入後綴範圍，原本的直連例外就難以生效。測試規則優先級時，應特別選擇同時符合兩條條件的目標，才能確認順序確實造成差異；只存取兩個互不重疊的網域，無法驗證涵蓋關係。

FINAL 不是可繼續往後比對的一般條件

FINAL 負責處理前面所有規則都未命中的請求，通常應列為 Rule 最後一條。若將它放在中間，後面的常規規則就沒有機會處理剩餘請求；在檔案末尾新增規則時，尤其要確認沒有把規則寫在 FINAL 之後。多寫幾條 FINAL，也不會形成依情境自動切換的兜底方案。若不同範圍需要不同策略，應先明確定義各範圍的條件，而不是用重複兜底表達模糊需求。

[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

在這段片段中，網域例外列在位址分類之前，因此即使 example.com 解析到可能符合 GEOIP 的位址，已先命中的請求仍會依網域規則處理。若請求沒有可用於網域比對的資訊，就需要繼續檢查位址條件。不要把這種差異誤解為規則隨機失效；規則能判斷哪些資訊，取決於請求進入處理流程時帶有哪些資料。診斷時應一併記錄主機名稱、目標位址、命中規則與最終策略，才能分辨是順序問題還是辨識條件問題。

重複規則、涵蓋範圍與遠端內容的覆蓋

重複規則不一定會造成語法錯誤，但會增加維護負擔。同一條 DOMAIN-SUFFIX 前面設定 PROXY、後面設定 DIRECT 時，後者通常無法產生預期的覆蓋效果。維護前可先搜尋相同網域，檢查是否已有範圍更大的後綴或關鍵字，再確認是否有更早的位址規則命中。刪除重複項目前，應保留原始副本，並確認其中沒有必要的例外。整理的目標是讓每條規則的作用都能說明清楚，而不是單純追求行數更少。

若現有設定還引用外部規則內容，主檔中引用項目的位置也值得檢查。不能只看外部清單寫了什麼，還要了解這段內容何時參與判斷、採用哪種策略，以及更新後涵蓋範圍是否改變。對尚未理解的引用，不要只看名稱就判斷「應該優先」。本頁的獨立片段適合先在本機測試副本中驗證基本條件，再回到現有複雜設定逐項比對；不建議直接將片段插入不明層級而不做檢查。

最有效的順序測試只需少量規則：一條例外、一條範圍規則與一條 FINAL。確認三者行為後，再分批恢復其他項目。每批新增後都存取同一組測試目標，並以新連線查看紀錄，才能準確找出是哪一批造成覆蓋。若只有切換至 Proxy 才能存取、Config 卻不行，應優先核對命中策略，不要先重新安裝應用程式。若要了解僅指定部分網站的完整情境，請接著閱讀DOMAIN-SUFFIX 規則寫法。

06 · Host 與 URL Rewrite 的適用範圍

Host 變更解析對應，不會直接選擇出口

Host 段用於指定主機名稱對應的位址。它回答的是「這個名稱解析到哪裡」，而非「連線採用哪種策略」。例如，內部服務需要固定使用使用者管理的位址時，可以在 Host 中設定明確對應，並在 Rule 中依需求選擇 DIRECT。兩段的用途應分開理解：只有 Host 對應不會自動確保請求直連，只有 DIRECT 也不會替使用者補上正確的內部解析。對應位址必須確實屬於預期服務，否則即使後續規則再精確，也只會連到錯誤目標。

[Host]
intranet.example.com = 192.0.2.10

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

192.0.2.10 是文件專用位址，這段內容只用於說明語法，不能直接作為內部服務位址使用。實際填寫前，應向使用者自己的網路管理員或服務設定紀錄確認位址與連接埠。若服務位址會隨網路變動，固定 Host 可能讓存取在某個網路正常、換網後失敗；若服務透過多個位址進行調度，固定單一位址也可能破壞故障切換。不要用長期靜態對應取代異常解析排查，更不要從陌生筆記複製某網站的舊位址。

對應設定不會取代 TLS 名稱與伺服器設定

使用網域存取 HTTPS 時，連線位址與憑證驗證名稱是不同概念。Host 可以變更連線目的位址，但伺服器仍應為該網域提供適用的憑證與回應內容。設定對應後若出現憑證錯誤，不應以忽略驗證來判定設定正確；應先確認目標服務確實支援該網域，以及伺服器端的網站綁定是否正確。同一位址可能託管多個網站，只知道位址可連線，並不足以證明該網域會傳回所需內容。

修改 Host 後的測試也會受到快取與連線重用影響。先儲存檔案並確認已選取，再發出新請求；必要時關閉舊頁面後重新開啟，並比對實際目標位址。若只有某個應用程式沒有變化，也要考慮它是否使用自己的解析方式或直接存取位址。不能因為其他應用程式受到對應設定影響，就推論裝置上的每個請求都會採用相同路徑。維護時記錄每條靜態對應的用途與來源，服務遷移後及時確認，可減少「規則沒改卻突然失效」的情況。

URL Rewrite 依位址模式處理請求

URL Rewrite 用於改寫可辨識的請求網址，不是更新伺服器清單，也不是網域分流的別名。常見格式由比對運算式、替換網址與動作組成。以下使用重新導向動作，將示範網站的 HTTP 網址導向 HTTPS，並透過擷取群組保留原路徑。正規表示式中的句點需要跳脫，起始錨點用來限制開頭；否則看似簡單的運算式也可能匹配無關網址。正式使用前，應逐一列出應匹配與不應匹配的範例，避免只用一個成功案例驗證。

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

此處的 $1 參照前面括號擷取的內容，302 表示讓用戶端繼續存取替換後的網址。目標網站仍須實際提供 HTTPS 服務；規則本身無法替伺服器新增憑證或建立頁面。重新導向也可能改變後續請求的主機名稱，進而觸發另一條 Rule，因此若看到最終出口改變，應檢查請求是否已更換目標。若替換網址再次符合原運算式，或伺服器端又導回舊網址，還可能形成迴圈，應立即停用該規則並檢查完整的重新導向鏈。

HTTPS 請求中的路徑與要求標頭通常位於加密內容中，並非所有 URL Rewrite 都能直接處理；涉及解密時，還有憑證信任、限定主機與應用程式相容性等限制。本頁不要求啟用解密來完成規則分流，也不建議為了測試簡單條件而擴大處理範圍。能用網域規則解決的出口需求，應優先放在 Rule。Host、Rule 與 URL Rewrite 各自處理不同問題；組合使用時，應分別驗證解析、策略與改寫後的新請求，避免把一次成功重新導向當成所有設定都正確。

07 · 常見規則寫法與調整方式

只讓指定網站走 PROXY

若需求是讓少數指定網站走代理、其他目標直接連線，可採用「明確網域條件加 FINAL,DIRECT」的結構。先從一個可確認的目標開始，不要立刻匯入大量未經檢查的關鍵字。以下將 example.com 及其子網域納入代理範圍，並另外保留內部主機直連。執行前應替換成使用者實際需要管理的網域，並確認目前代理伺服器可用；範例網域只用於展示比對關係，不代表存取它就能測試真實服務。

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

實際網站通常不只使用網址列中的單一網域，也會呼叫獨立的登入 API、靜態資源或檔案服務。若頁面文字正常顯示但圖片沒有載入，應查看遺失資源的實際請求，而不是直接將所有流量改走 PROXY。確認資源確實屬於需要調整的範圍後，再新增相應的 DOMAIN 或 DOMAIN-SUFFIX。若多個服務共用資源網域，範圍過大的後綴可能影響其他網站；這種情況下，完整主機名稱規則通常較容易控制影響範圍。

設定明確例外，其餘請求交由 PROXY

另一種常見需求是讓內部服務、區域網路位址或特定地區位址使用 DIRECT，其餘請求則使用代理。此時 FINAL,PROXY 只是兜底，不代表所有請求從第一行起就走代理。已知例外應放在 FINAL 之前，並依業務條件的明確程度排列網域與位址規則。若特定網域確實需要代理，可放在地區規則之前，避免因位址分類而落入 DIRECT。地區分類不能取代對重要業務的明確規則。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,intranet.example.org,DIRECT
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
GEOIP,CN,DIRECT
FINAL,PROXY

這份範例只列出部分內部位址範圍，並未涵蓋所有本機網路情況。家庭裝置、辦公室網路或虛擬網路可能採用其他位址與探索方式，應依實際網路架構補充，不要逐字複製後就認定所有本機服務都已涵蓋。也要留意 no-resolve 的適用範圍：它會避免為對應的位址條件主動解析，但不會將內部主機名稱轉換成位址。若內部名稱無法解析，仍須檢查系統 DNS、Host 或使用者自己的內部解析設定。

拒絕精確目標，避免誤傷範圍過廣

若要拒絕已確認的請求目標，請先使用 DOMAIN，不要只憑名稱中的常見字詞就大範圍套用 REJECT。完整主機名稱較容易核對，也方便日後還原。以下只拒絕 telemetry.example.com，並保留 example.com 其他主機的代理行為。若改用 DOMAIN-KEYWORD,telemetry,REJECT，可能影響其他包含相同字串的網域。是否擴大範圍，應由實際請求紀錄與明確需求決定，不應以規則「看起來更完整」為依據。

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

驗證 REJECT 時，應同時確認目標請求確實遭到拒絕、頁面核心功能仍可運作，且登入或提交操作沒有異常。某個端點可能同時負責統計與業務回應，單看名稱無法判斷封鎖後的影響。發生故障時，先停用剛新增的精確規則，以相同操作重新測試；確認因果關係後，再決定保留或刪除。不要為了維持封鎖而不斷增加例外，讓設定逐漸變成難以理解的修補集合。

將情境寫法轉為維護紀錄

這三類片段分別對應不同需求，不能直接首尾拼接，因為每一類都有自己的 FINAL。合併時先選定整體兜底策略，再擷取必要的網域例外、內部位址與拒絕項目，最後重新檢查順序。建議為每個新增條件記錄一行用途，例如「內部 API 需直連」或「指定網站使用代理」；不要記錄訂閱憑證。需求取消後，依用途刪除對應規則，比在數百或數千行中猜測來源可靠。

若更換既有訂閱後只有 PROXY 路徑失效，應先核對伺服器選取與連線參數，而不是重寫網域條件；規則指定的策略可能沒變，改變的是策略背後的出口。多個訂閱的分組與重複節點問題，可參閱多個訂閱管理說明。維護時應始終分清各自範圍：伺服器資訊由伺服器管理，目標比對由 Rule 負責，名稱解析由 General 或 Host 處理；如此才能在網路變動後快速找出需要調整的部分。

08 · 驗證流程、排錯分支與維護

建立固定測試目標與觀察紀錄

驗證設定時，不應只問「頁面能不能開啟」，還要確認是否透過預期路徑開啟。先選擇一個應走 PROXY 的網域、一個應走 DIRECT 的網域，以及一個用來檢查 FINAL 的未列出網域。若使用 REJECT，再增加一個明確拒絕的目標。為每個測試寫下預期策略，測試時記錄實際目標、命中規則與最終出口。測試目標越固定，前後比較越有意義；每次更換不同網站，可能會把伺服器端波動誤認為設定改變。

1. 確認使用者既有的伺服器資訊已匯入，並在 Home 選取可用出口。
2. 在 Config 選取測試副本，並將 Global Routing 設為 Config。
3. 建立連線，以新請求存取固定測試目標。
4. 在應用程式實際提供的請求紀錄或診斷畫面中，核對命中條件與策略。
5. 每次只修改一處，重複同一組測試；通過後儲存可復原的副本。

Connectivity Test 可協助判斷部分連線條件，但不能取代實際業務測試。成功連線至伺服器，不代表目標網站的驗證、資源載入與請求方法都正常；同樣地，網頁失敗也不一定表示伺服器整體無法使用。遇到問題時，先判斷失敗發生在解析、連線、規則比對還是應用程式回應，再選擇相應工具。若缺少足夠紀錄，保留一段最小重現設定，比反覆切換大量選項更能縮小問題範圍。

依據現象選擇排錯方向

「規則未命中」時，應優先檢查實際主機名稱，不要直接擴大後綴範圍。有些頁面會重新導向至不同網域，有些應用程式存取的是 API 主機，也有些請求會直接使用位址。若規則條件本身正確，再確認檔案是否已選取、是否成功儲存，以及 Global Routing 是否仍處於 Proxy 或 Direct。接著往上檢查更早命中的項目，尤其是範圍過廣的關鍵字、位址規則與提早出現的 FINAL。依此順序檢查，可避免把狀態錯誤變成更多規則。

「命中正確但仍無法存取」時，應轉而檢查連線路徑。確認使用者既有的位址、連接埠、驗證資訊與協定相關參數，不要用範圍更廣的 Rule 掩蓋驗證錯誤。Trojan 等使用 TLS 的連線，還要核對服務提供者提供的名稱與參數；參數應以使用者自己的服務資訊為準，不可從規則範例推測。相關欄位可參閱Trojan 密碼、SNI 與 TLS 重點。若伺服器清單本身是空的，應先處理訂閱更新；規則無法取代缺少的伺服器資訊。

復原、更新與故障資料整理

每次調整成功後，儲存一份用途明確的穩定副本，並記錄修改條件與原因。遠端設定或訂閱更新後，先檢查原有測試目標，不要等所有應用程式都出現異常才回想做過哪些修改。若新版內容造成故障，可回復至已驗證的副本，恢復基準狀態；之後再逐段比較，而不是把新舊檔案混在一起繼續修補。對於不再使用的 Host 對應、過時例外與重複規則，確認沒有依賴後應予以清理。

整理故障資料時，保留必要資訊即可：目前模式、相關 Rule 的前後幾行、測試網域、預期策略與實際結果。不要公開完整訂閱連結、伺服器密碼、存取權杖或含個人資訊的請求網址；截圖前應確認這些內容沒有顯示。若無法判斷問題來源，先用最小規則副本重新測試，再參考FAQ與訂閱更新失敗自我檢查步驟，避免將訂閱解析錯誤與規則分流錯誤混為一談。