Shadowrocket
規則與設定參考

[General]

設定檔結構與生效範圍

Shadowrocket 的設定檔不只是網域清單。執行參數、請求分流、名稱解析對應與 URL 處理各自放在不同段落，每個段落標頭以英文方括號括住。閱讀檔案時，先找出段落標頭，再判斷後續內容屬於哪種語法，直到遇到下一個段落標頭為止。兩行都含有網域，不代表它們屬於同一段；例如 Rule 中的網域用來決定策略，Host 中的網域則用來設定名稱對應，兩者作用不同。

從最小設定建立可驗證的基準

有可用伺服器後，可以先用以下片段了解結構。這裡的 General 僅說明是否略過部分系統流量，Rule 則設定區域網路與最終策略。這不是適用於所有網路的完整範本，也不含伺服器驗證資訊。實際操作時，請複製目前的 Config 並保留原檔，再於副本中逐項修改；尤其不要為了套用範例，就刪除原本需要的 DNS、規則或網路相關參數。

[General]
bypass-system = true

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

bypass-system = true 會影響部分系統流量是否交由用戶端處理，因此不能據此推斷所有系統請求都會出現在連線記錄中。規則記錄只反映用戶端實際接管且能辨識的請求。若某項系統功能沒有記錄，請先確認其流量是否在處理範圍內，再判斷 Rule 是否有誤；不要直接新增範圍過大的網域規則。

區分設定檔、伺服器清單與目前連線

Config 中的檔案負責描述處理方式，Home 中已有的伺服器則提供連線目標。規則設為 PROXY 不代表伺服器地址已寫入設定檔，更不表示用戶端已選取可用連線。排查時，請分別確認目前啟用的設定檔、Global Routing 模式，以及 Home 中選取的項目。檔名相似或匯入成功，都不足以證明這次請求使用的就是剛編輯的內容。

編輯後先儲存，回到 Config 確認選取的是目標檔案，再依應用程式介面提示重新套用連線。遠端設定也要區分本機修改與上游更新：重新下載可能覆蓋本機編輯，另存副本則可能不再自動同步原始內容。建議為副本取容易辨識的用途名稱，並在檔案開頭註明修改原因，不要只用數字區分多個相似版本。

語法檢查從字元與所在段落著手

規則欄位使用英文逗號，鍵值項目通常使用英文等號，段落名稱與策略名稱維持英文原文。中文標點、複製時帶入的不可見字元，以及換行後不完整的規則，都可能導致內容無法如預期解析。建議每行只寫一個有效項目；說明文字另起一行並以 # 開頭。不要把說明插在欄位中間，也不要將網頁顯示用的行號複製到檔案中。

檔案能儲存，不代表符合實際需求。儲存只處理文字與語法層面的問題，是否真正生效還取決於目前使用的檔案、模式、流量接管範圍與伺服器狀態。維護時保留一份可正常使用的基準，每次只變更一類設定，再以相同請求重新測試。如此一來，若發生問題就能明確退回前一步，不必同時追查多個段落的變動。

[Rule]

網域規則的範圍與界線

網域分流適合表達「這項服務使用哪種策略」，但必須先選對比對範圍。Rule 中常見的三種網域關鍵字是 DOMAIN、DOMAIN-SUFFIX 和 DOMAIN-KEYWORD。它們都不是完整 URL 比對：不可將協定標頭、路徑、查詢參數與連接埠一併填入網域欄位，也不能以瀏覽器網址列的完整內容取代主機名稱。判斷時先將請求拆分為協定、主機、連接埠與路徑，再取出主機部分。

DOMAIN：只處理指定的主機名稱

DOMAIN,example.com,PROXY 表示比對指定網域，不會自動涵蓋 api.example.com。若要為單一主機保留例外，DOMAIN 比範圍較廣的規則更容易檢視。例如同一服務的主站與檔案介面可能需要不同策略，先明確列出特定主機，就能避免後續整站規則涵蓋例外。網域通常不區分大小寫，但維護時統一使用小寫有助於去除重複項目。

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

這段設定只涵蓋列出的三個主機，其他名稱會套用 FINAL。若頁面仍缺少圖片或介面資料，原因可能是頁面引用了清單以外的網域，不一定是 DOMAIN 沒有生效。開啟頁面通常會建立多組連線；驗證時請分開檢查失敗資源的主機與主文件主機，不要只憑網址列的一個名稱推斷所有資源的連線方向。

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

同一網域體系下的服務需要採用相同策略時，可以使用 DOMAIN-SUFFIX,example.com,PROXY。此規則涵蓋 example.com 及其子網域，例如 api.example.com；不能把它理解成任意字串結尾比對，otherexample.com 並非 example.com 的子網域。規則欄位只填網域後綴，不加前置星號，也不寫 https://。

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

這裡將特定主機放在後綴規則之前，因此 local.example.com 可以使用 DIRECT，其餘符合該後綴的請求則走 PROXY。若將兩行順序顛倒，後綴規則會先處理該主機，後面的例外便不會再有機會生效。規則不會自動比較哪一條更精確；「精確規則放前面」是由檔案編寫者安排的結果。

DOMAIN-KEYWORD：寬泛比對需額外檢查

DOMAIN-KEYWORD 會比對網域中的關鍵字，不會依據網域所有權界線判斷。例如 DOMAIN-KEYWORD,example,PROXY 可能涵蓋多個包含 example 的名稱，而不只 example.com 這一組。它適合明確需要廣泛比對的情況，不宜只因為寫法簡短，就取代 DOMAIN-SUFFIX。關鍵字越短，越容易比對到與原意無關的目標。

觀察網域來源，而非猜測網站歸屬

用戶端能否依網域比對，取決於這次連線是否具有可用的網域資訊。應用程式直接連線至 IP、重用既有連線，或採用獨立解析方式時，記錄中的資訊可能與瀏覽器輸入內容不同。請先檢查請求記錄顯示的目標與命中規則，再決定使用網域或 IP 條件。不要為了讓整個應用程式走代理，就使用過短的關鍵字擴大範圍；這通常會造成難以解釋的連帶影響。

國際化網域在介面顯示的字元，與實際請求使用的編碼形式可能不同；排查時應以記錄中的主機名稱為準。也不要把搜尋結果的跳轉連結當成最終網站：一次跳轉可能涉及多個網域，每次新連線都會分別套用規則判斷。若需求是「指定網站走 PROXY，其餘 DIRECT」，可接著閱讀DOMAIN-SUFFIX 與 FINAL,DIRECT 的情境說明，先建立明確的網域清單，再逐步擴大範圍。

[IP]

IP、GEOIP 與 USER-AGENT

網域規則用於服務名稱，IP 規則則用於目標地址範圍，兩者不能互相取代。同一網域可能解析到多個地址，同一地址也可能承載多項服務。若需求是穩定指定某個網站，優先考慮網域條件；若要讓辦公室網段或某台裝置直接連線，IP-CIDR 則較容易清楚表達。選擇條件前，先確認要控制的是「名稱集合」還是「地址集合」。

IP-CIDR 與前綴長度

IPv4 CIDR 由網路地址與斜線後的前綴長度組成。前綴越長，涵蓋的地址越少；/32 代表單一 IPv4 地址，192.168.0.0/16 則代表較大的私有地址範圍。不要將連接埠填入 CIDR 欄位，也不要以網域取代網路地址。若只需處理一台裝置，請填寫明確地址，不要為了省事而涵蓋整個私有網路。

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

以上三組較大的範圍是常見的私有 IPv4 地址空間，不代表目前網路真的使用這些範圍。若實際網路存在路由重疊、遠端內網或專用存取需求，請依照自身地址規劃調整。規則選擇 DIRECT 只表示不經代理策略，無法替系統建立不存在的路由，也不能讓沒有網路權限的地址變得可連線。

IP-CIDR6 與雙堆疊請求

IPv6 使用 IP-CIDR6，例如 IP-CIDR6,fd00::/8,DIRECT。不要在同一個關鍵字後填入 IPv4 與 IPv6 地址。裝置可能同時取得兩種地址，應用程式也可能優先連線其中一種；因此只修正 IPv4 規則，不一定能改變實際連線方向。測試時請確認這次使用的地址族，而不是只看某次 DNS 查詢結果。

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR6,fd00::/8,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

這段設定用來表達不同地址條件的組合，不保證適用所有區域網路環境。IPv6 的連結範圍、網路介面與系統路由另有其限制。若記錄中出現 IPv6 目標，但設定只有 IPv4 項目，請先確認預期，再補上具體範圍；不要將整個地址空間設為 DIRECT，當成通用的修復方式。

GEOIP 判斷的是地址歸屬資料

GEOIP,CN,DIRECT 依據用戶端使用的 IP 歸屬資料庫判斷目標地址，不是辨識網頁語言、網域註冊地或帳號地區。內容傳遞網路可能在不同地點回傳不同地址，資料庫內容也可能與實際部署情況不符。因此 GEOIP 適合作為廣泛策略的一部分，不適合作為判斷特定網站歸屬的唯一依據；重要服務可在它前面加入明確的網域規則。

網域請求遇到需要目標地址的規則時，可能會涉及解析流程。可選用 no-resolve，避免此 IP 規則為比對網域而額外觸發解析，例如 IP-CIDR,192.168.0.0/16,DIRECT,no-resolve。這不代表關閉整個應用程式的 DNS，也不表示已知 IP 不會再比對。是否使用應依解析需求決定，不能把它當成必定能提升速度的開關。

USER-AGENT 的可見性限制

USER-AGENT,ExampleApp*,DIRECT 會依可取得的 User-Agent 資訊比對，其中的星號範例用來比對後續字元。此處比對的是請求識別字，不是作業系統中的應用程式安裝套件名稱。多個程式可能使用相同識別字，同一程式也可能在不同請求中傳送不同識別字，因此不能將它視為可靠的程序分流替代方式。

對於加密請求，用戶端不一定能讀取 HTTP 請求標頭。只在 Rule 中加入 USER-AGENT，不會自動取得這些內容，也不應因此盲目調整憑證相關設定。若記錄中沒有相應欄位，請先確認該資訊無法查看，再改用可觀察的網域或地址條件。需要存取路徑或請求標頭才能表達的需求，應與一般連線分流分開評估，避免規則看似完整，實際上卻從未有機會命中。

[Policy]

策略與 Global Routing 的關係

規則先回答「是否符合這個條件」，策略再決定「符合後如何處理」。PROXY、DIRECT、REJECT 是策略名稱，不是協定類型，也不是伺服器地址。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 等名稱描述連線方式；同樣設為 PROXY 的規則，可以透過目前可用的代理連線執行。不能只把策略名稱改成某種協定名稱，就完成伺服器設定。

PROXY：將請求交由目前的代理路徑處理

規則選擇 PROXY 時，必須有已設定且可用的代理目標。地址、連接埠、驗證、傳輸與 TLS 等參數是否正確，屬於連線設定問題；網域是否符合這條規則，則屬於分流問題。兩者可能各自成功或失敗：記錄顯示命中 PROXY 但網頁仍無法開啟，不代表規則無效，也可能是選取的伺服器無法連線、驗證錯誤，或伺服器無法連接目標。

先透過 Home 確認目前選取的項目，再使用 Connectivity Test 輔助判斷連線狀態。測試結果只反映指定測試條件下的狀況，不保證所有網站、連接埠或協定都能成功。若要檢查 Trojan 的密碼、SNI 與 TLS 欄位，可參閱Trojan 參數逐項說明；不要用新增網域規則來掩蓋遠端驗證失敗。

DIRECT 與 REJECT 的界線

DIRECT 表示目標連線不經代理策略，但仍受本地網路、系統權限、DNS、路由與目標服務影響。直連失敗不代表一定要改用代理，也不代表用戶端攔截了請求。REJECT 則用來拒絕符合條件的請求，適合已確認需要封鎖的目標；它不是「自動改走其他連線」，也不是代理失敗時暫時切換的意思。

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

此範例將拒絕條件放在前面，接著處理內部服務，再由網域後綴規則處理其餘子網域。REJECT 後用戶端如何向特定應用程式呈現失敗，可能取決於請求類型，因此不能用錯誤頁面的樣式判斷規則是否命中。較可靠的依據是目標、策略與規則記錄是否一致。

Global Routing 的三種模式

Global Routing 的設定 / 代理 / 直連，對應介面用語 Config / Proxy / Direct。Config 依目前設定檔進行分流，是驗證 Rule 的主要模式。Proxy 與 Direct 則會將處理範圍內的連線整體導向代理或直連路徑，不能再假設一般 Rule 會像 Config 模式那樣逐條執行。整體流量仍受系統接管範圍限制，不代表裝置上的所有流量都必定經過同一路徑。

模式對照用於定位問題，不要同時修改設定

若 Config 失敗而 Proxy 成功，可以懷疑分流方向或解析路徑有問題，但仍需檢查記錄確認；若兩者都失敗，請先檢查代理連線與目標服務，不要立即擴大 Rule。若 Direct 成功而 Proxy 失敗，則應確認代理端是否支援此目標與連接埠。每次切換模式後都重新送出請求，避免將重用舊連線的結果誤認為新模式的狀況。

On Demand 決定何時依網路條件啟動連線，與某個網域最後命中 PROXY 或 DIRECT 不在同一層。自動連線已觸發，不代表策略設定正確；自動連線未觸發，也無法透過 Rule 修正觸發條件。將連線開關、Global Routing、Config 與伺服器選擇分成四項檢查，能大幅縮短排查時間。相關介面術語可繼續參閱術語手冊。

[Priority]

比對順序與常見規則寫法

Rule 的關鍵原則是由上而下檢查，第一個符合條件的有效規則會決定處理策略。它不會先收集所有命中項目，再挑選看起來最具體的規則，也不會因為某行寫在後面就自動覆蓋前面的規則。整理檔案時，應將明確例外放在範圍較廣的條件之前，並將 FINAL 留在結尾。理解這一點比記住更多關鍵字重要，因為許多「規則失效」實際上只是前面的範圍已經涵蓋目標。

指定網域走 PROXY，其餘 DIRECT

這種寫法適合代理範圍明確，且希望其他請求透過本地網路存取的情況。先列出確切例外，再設定網域後綴，最後使用 FINAL,DIRECT。它不會自動找出網站相依的所有服務；若登入、圖片或介面使用其他網域，請依請求記錄逐項確認。不要只因頁面顯示不完整，就改用 DOMAIN-KEYWORD 擴大範圍，或將 FINAL 改成 PROXY。

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

測試時至少準備三類目標：一個應走代理的主機、一個應保留直連的例外，以及一個完全不在清單中的主機。分別檢查它們命中的規則與策略，才能驗證整體設定意圖。只測試 example.com 成功，無法證明 local.example.com 的例外或 FINAL 的方向也正確。

私有地址直連，其餘走 PROXY

另一種設定方式是先保留本地裝置的存取，再將其他請求交由 PROXY。這裡的「其餘」範圍很廣，包括未列出的業務網域與應用程式連線，因此應先確認伺服器可用，並了解遠端連線造成的路徑變化。私有地址項目也應符合實際網路需求；若業務需要透過代理存取遠端同名私有網段，一般的區域網路直連規則可能與目標衝突。

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
IP-CIDR,172.16.0.0/12,DIRECT
IP-CIDR6,fd00::/8,DIRECT
FINAL,PROXY

此片段不加入 GEOIP，目的是讓設定意圖保持清楚。若再加入 GEOIP,CN,DIRECT，就會變成另一套涵蓋範圍更廣的分流方案。兩種方式都能表達需求，但新增條件並非不影響行為的裝飾。每一行都應有明確用途，並對應一組可驗證的請求。

FINAL 不是網路失敗後的備用路徑

FINAL 表示前面的條件都未命中時採用此策略，不代表前面的連線失敗後改走這個策略。請求一旦命中 PROXY，之後發生逾時，通常不會再往下嘗試 FINAL,DIRECT。若要設計可用性切換，應另外了解相應策略設定，不能靠並列多條 FINAL 達成。日常維護時保留一個明確的 FINAL，比堆疊多個相同關鍵字更容易檢查。

[Rule]
# 先保留單一主機的例外
DOMAIN,download.example.com,DIRECT
# 再涵蓋其餘子網域
DOMAIN-SUFFIX,example.com,PROXY
# 最後處理前面未命中的請求
FINAL,DIRECT

合併設定前先排除規則遮蔽

將兩份規則合併前，先比較各自的 FINAL、廣泛網域條件與大範圍 IP 項目。若第一份設定的 FINAL 留在中間，第二份即使語法正確，也可能完全不會被檢查。同樣地，涵蓋整個 example.com 的後綴規則，可能遮蔽下方多個指定主機；重複項目也會讓維護者誤以為後面的修改已經生效。

建議依「明確拒絕、具體例外、服務網域、地址範圍、區域條件、最終策略」的方向檢查，但這只是整理方法，不是用戶端強制的優先順序。若業務需求是讓某個 IP 條件優先於網域條件，就應明確調整順序並留下說明。不要依關鍵字字母順序機械排序，因為排序會改變首次命中的結果。

對於共用服務，尤其不要以單次解析取得的 IP 取代長期使用的網域規則。地址可能變動，也可能同時承載無關服務；將它放在前面會影響其他請求。記錄修改前後的差異，並保留可回復的檔案，是維護複雜設定時比「項目越多越完整」更可靠的做法。更多常見現象的排查方式請參閱常見問題。

[Host]

Host 對應與 DNS 路徑

Host 與 Rule 常出現在同一份設定檔中，但處理的問題不同。Host 指定某個名稱應對應哪個地址，Rule 則決定請求採用哪種策略。將網域對應到 IP，不等於指定 DIRECT；將網域規則設為 PROXY，也不代表固定其 DNS 解析結果。排查網域存取問題時，應分開檢查「名稱如何取得地址」與「連線如何到達目標」，否則容易在錯誤的段落反覆修改。

靜態對應的基本寫法

以下 Host 範例使用文件保留地址，展示等號兩側的結構。左側是完整主機名稱，右側是目標 IP；內容不包含協定標頭或 URL 路徑。套用到實際環境時，請替換為自己確實管理或獲准使用的目標地址。不要直接拿範例地址測試連線，也不要將來源不明的地址永久固定到常用服務。

[Host]
portal.example.com = 192.0.2.20

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

這裡使用 DOMAIN 明確指定 DIRECT，再透過 Host 指定地址，方便分別說明這兩項設定。即使目標成功解析至 192.0.2.20，也不代表它能透過目前的網路連線。路由、連接埠監聽、存取權限與伺服器狀態仍須正常。實際測試請使用有效且由你管理的地址；記錄顯示對應生效與服務存取成功，是兩個不同的檢查項目。

固定地址不會改寫憑證對應的名稱

HTTPS 存取仍會使用原網域進行身分驗證，伺服器通常也會依據 SNI 選擇憑證與網站。Host 只會變更地址對應關係，無法讓不相符的憑證變得有效，也無法讓未提供該網域服務的伺服器傳回正確內容。若對應後出現憑證錯誤，請確認伺服器是否真的為該網域提供服務，不要透過放寬憑證驗證來掩蓋地址錯誤。

同樣地，瀏覽器直接存取 IP，與透過網域和 Host 對應存取，不一定會得到相同結果。請求中的主機資訊可能不同，伺服器上的虛擬網站也可能不同。排查時應保持原始網域與存取路徑不變，只變更預計驗證的對應項目；否則多項差異交疊，就無法判斷是哪項變更影響結果。

另行檢查 General 中的解析參數

General 可以包含 DNS 相關設定，例如 dns-server = system 表示使用系統的解析來源。這是用來理解預設路徑的簡短範例，不代表所有環境都必須採用此值。網路本身、應用程式的獨立解析方式與代理端處理方式，都會影響最後可觀察到的流程。不要將更換解析伺服器當成適用於所有故障的通用解法。

[General]
dns-server = system

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

這段片段沒有靜態對應，方便與 Host 設定方式比較。若舊的對應仍在生效，修改 DNS 伺服器可能不會改變該主機對應的地址；若應用程式重用既有連線，重新查詢 DNS 也未必會改變目前連線。請先確認是否有 Host 項目，以及是否建立了新連線，再判斷解析設定是否發揮作用。

快取、應用程式解析與多地址結果

DNS 結果可能快取在系統、用戶端或應用程式中，網站連線也可能長時間重用。修改後立即重新整理頁面，不一定會觸發完整的新解析流程。可以先停止正在執行的工作，重新套用連線，再開啟目標；必要時依應用程式提供的方式清除快取。不要為了清除單一目標的舊結果，順手重設所有設定與網路選項。

若同一名稱同時回傳 IPv4 與 IPv6，固定其中一種地址或只檢查一種查詢結果，都不足以證明所有連線已符合預期。請以連線記錄中的實際地址為準，分別檢查地址族、命中規則與策略。若涉及內網名稱，也應分別在原本的網路與其他網路測試，因為離開辦公室後，原有的 DNS 搜尋網域與私有地址路由可能都不存在。

維護時請註明每條固定對應的用途，並定期確認伺服器仍接受該網域。若臨時排查已完成，請刪除不再需要的對應並還原基準，避免幾個月後將地址過期誤判為規則故障。對於無法觀察的請求，不要只憑猜測新增 Host；先取得請求主機、目標地址與錯誤類型，再決定修改位置。

[URL Rewrite]

URL Rewrite 的運算式與界線

URL Rewrite 處理可辨識的 URL，與 Rule 依主機或地址選擇連線策略不同。它適用於明確的地址改寫或跳轉需求，不應當作整個應用程式的分流開關。新增前先確認需要變更的是連線路徑、名稱對應的地址，還是請求 URL 本身？前兩種需求應優先考慮 Rule 與 Host，只有第三種才屬於本節範圍。

從可觀察的 HTTP 跳轉著手

以下片段會將符合條件的明文 HTTP 地址重新導向同網域的 HTTPS 地址，並以 302 表示暫時跳轉。這只展示語法結構，不代表目標網站提供 HTTPS 服務。運算式左側比對原始地址，中間指定替換目標，最後填寫處理方式；各部分以空格分隔，請勿改用中文標點。

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

^ 將比對範圍限制在字串開頭，\. 表示網域中的實際句點，(.*) 會擷取後續內容，$1 則在替換目標中引用第一組擷取結果。若將網域中的句點直接寫成正規表示式的任意字元，比對範圍就會超出預期。若漏掉擷取引用，原路徑也可能遺失，最後跳轉到不同頁面。

限制主機與路徑，避免擴大比對範圍

較穩妥的規則通常會明確限制協定、主機與路徑前綴，而非替換所有包含特定字詞的 URL。網域與路徑可能同時出現相同關鍵字，缺少錨點的運算式也可能意外比對到查詢參數。撰寫時，準備一個應該命中的地址，以及幾個相似但不應命中的地址，透過邊界案例驗證，而不是只看一個成功範例。

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

此範例只處理指定主機下的 old 路徑前綴，不會一併改寫其他網站或路徑。若原始地址包含查詢參數，也要確認擷取後的替換結果是否符合預期。含有登入狀態、臨時授權或提交動作的 URL 尤其需要謹慎，因為變更路徑或重新導向方式可能影響伺服器對請求的判讀。

單靠一條規則無法取得 HTTPS 內容可見性

HTTPS 會將請求內容置於加密連線中，完整 URL 路徑與請求標頭不一定能由用戶端直接讀取。在規則中填入 HTTPS 運算式，不代表它就能處理所有加密請求。能否取得足夠資訊，取決於實際連線方式與相關設定。不要將新增 Rewrite 與取得內容可見性混為一談，也不要為了讓範例命中而盲目啟用憑證相關操作。

部分應用程式可能採用額外的憑證限制或獨立網路實作，在瀏覽器中有效的處理方式未必能直接套用到這些應用程式。若只是要讓某個網站走 PROXY，網域 Rule 就足以表達此需求，不必讀取加密內容。將目標限制在必要的連線層，可減少額外依賴，也更容易檢查設定的影響範圍。

跳轉循環與快取造成的誤判

若用戶端將 A 改寫為 B，而伺服器又將 B 跳回 A，就會形成循環。症狀可能是頁面反覆載入、跳轉次數過多或無法完成載入，而不是明確指出某條 Rewrite 有問題。排查時，先停用新增的單一改寫並保持 Rule 不變，觀察循環是否消失；不要同時切換 Global Routing，否則無法判斷是哪項變更影響結果。

瀏覽器也可能記住伺服器跳轉或嚴格傳輸安全策略，導致明文地址在送出前就升級為 HTTPS。此時看不到 HTTP 規則命中，不一定是運算式語法錯誤。請使用可控的測試地址與新的存取流程驗證，同時觀察實際請求協定與跳轉鏈。對正式業務的提交操作，不要反覆重送測試規則，以免造成重複動作。

Rewrite 與 Rule 可能在同一次存取中一併生效：原始地址改寫後，新請求仍須依實際目標進行連線處理。因此要確認「最後採用哪種策略」，應檢查最終請求，而不是只查最初輸入的 URL。維護時請記錄改寫的業務目的、預期輸入與輸出，測試完成後刪除臨時項目。涉及身分驗證或付款等敏感流程時，應保留服務原有的地址行為，不要將一般範例直接套用到實際業務。

[Diagnostics]

驗證、維護與故障排查

驗證設定時，必須同時確認「符合預期條件」與「連線沿預期路徑完成」，只看到頁面開啟並不足夠。頁面可能來自快取，也可能由既有連線載入；測試工具顯示可連線，也不代表目標服務接受請求。建議固定一個可重複的測試操作，每次只修改一項設定，並記錄目標主機、目標地址、命中規則、策略與結果。

依固定順序檢查六個項目

1. 確認用戶端連線已啟用，且目前網路沒有剛切換。
2. 檢查 Global Routing 是否設為這次測試需要的 Config，而非先前留下的 Proxy 或 Direct。
3. 在 Config 中確認目前選取的檔案，開啟後核對修改內容已儲存。
4. 檢查 Home 中選取的伺服器，分別確認連線參數與基本連線狀態。
5. 重新送出目標請求，查看實際網域、地址與命中策略，排除重用舊連線的可能。
6. 只修改與觀察結果直接相關的一處，再以相同操作重新測試並記錄差異。

這套檢查順序能區分連線層與規則層。若第一步就不成立，繼續修改 DOMAIN-SUFFIX 沒有意義；若目前使用的檔案不正確，即使語法正確也不會影響請求。不熟悉匯入流程的使用者，請先回到使用教學建立一次成功連線，再開始調整規則；這比在空白設定中同時調整伺服器與分流更容易判斷問題。

依現象選擇排查方向

若記錄顯示命中非預期規則，請沿檔案往上找出第一個涵蓋目標的條件；若記錄已顯示預期策略，則應轉而檢查連線與目標服務。若同一網域的不同請求表現不一致，還要比較地址族、連接埠、實際地址與建立連線的時間。不要把這些不同條件籠統歸結為「規則有時有效、有時無效」。

用小型設定重現問題，而非刪除整份檔案

複雜檔案難以定位問題時，請複製目前設定，並在副本中保留必要的 General、一個目標條件與一個 FINAL，逐步重現問題。保留原檔以便回復，不要直接清空。以下片段適合檢查特定網域條件是否能命中；使用時請將測試目標換成既有服務，不應把 example.com 的存取結果當成自己的伺服器狀態。

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

若最小片段符合預期，再分組還原原有規則，每次觀察差異何時出現。如此可以找出遮蔽規則、範圍過廣的關鍵字，或過早出現的 FINAL。還原過程也要維持 General 與解析條件一致，否則行為變化可能來自 DNS 路徑，而不是剛加回的 Rule。不要只憑一次成功就認定整份檔案正確，應涵蓋代理、直連、拒絕與最終處理等不同測試案例。

分開維護訂閱更新與本機設定

Subscribe 更新主要涉及既有伺服器資訊，Config 更新則涉及規則與處理方式；兩者可能來自不同來源，也可能採用不同的更新方式。更新後先確認實際變更的是哪個部分，不要預設伺服器清單重新整理就會同步修正本機規則。訂閱連結請向你的服務供應商取得；單一分享連結與訂閱的差異，請參閱分享連結格式說明。

設定、匯出檔案與記錄可能包含伺服器地址、帳號資訊或附有授權參數的連結。向他人說明故障時，只保留必要規則與已處理過的記錄，並移除驗證欄位及完整訂閱地址。規則範例中的網域可以公開討論，但真實存取記錄可能暴露使用習慣；分享前請逐項檢查，不要直接傳送整份設定。

修改完成後進行回歸檢查

最後，請在常用網路下分別檢查目標服務、區域網路存取，以及其他原本正常的應用程式，確認新增規則沒有擴大影響範圍。若設定了 On Demand，也應另外驗證切換網路後是否會觸發連線，不要與網域比對混在一起測試。保留修改前的檔案、修改說明與幾個測試案例，之後發生變化時才能區分是設定問題、伺服器變更或目標服務調整。

本頁說明設定原理與規則界線；安裝與取得方式請參閱下載指南，常見錯誤訊息請參閱常見問題，術語解釋則收錄於術語手冊。遇到新狀況時，先整理可觀察的資訊，再查閱對應章節。維護設定的目標是讓每條規則都有明確用途、每次修改都能驗證、每個問題都能回復，而不是一味增加檔案內容。