2026-09-29 · 進階設定 · 約 10 分鐘

Shadowrocket 設定檔 .conf 結構解析：General、Rule、Host、URL Rewrite 各段用途

解析 Shadowrocket 設定檔的段落結構，說明 [General]、[Rule]、[Host]、[URL Rewrite] 各自的用途，以及規則由上而下的比對順序。

本文快速導覽

本文適合已經有自己的服務與訂閱，準備閱讀或調整 .conf 的使用者。先在 Config 確認目前啟用的檔案，再分別檢查基本參數、分流規則、網域映射與 URL 改寫；讀完後即可判斷修改項目應放在哪個段落，以及如何以最小幅度的變更找出問題。文中的網域與位址僅用於說明語法，並非可用的服務設定。

一、什麼是 .conf？如何確認目前使用的檔案？

.conf 是設定文字檔，不等同於 Home 裡的伺服器清單。Shadowrocket（小火箭）可透過設定檔管理規則與相關參數，但訂閱更新成功，不代表目前啟用的規則檔也一併更新。先進入 Config 查看目前選取的設定檔，再到 Home → Global Routing 確認模式，才能判斷檔案中的規則是否參與分流。

  1. 進入 Config，找出目前選取的檔案並記下檔名；若準備編輯，先保留一份原始檔案副本。
  2. 開啟該檔案的編輯畫面，依照方括號中的段落名稱辨識內容，不要只搜尋某個網域就直接修改。
  3. 返回 Home → Global Routing；若要測試檔案規則，請選擇 Config。Proxy 與 Direct 不會依照該檔案中的個別規則選擇連線路徑。
  4. 儲存後再次確認啟用的是修改後的檔案，再以相同目標重新測試；若連線仍沿用舊狀態，請先中斷連線再重新連線觀察。

段落名稱會決定後續內容的解讀方式。[General] 後通常是 key = value 格式的參數，[Rule] 後則是以逗號分隔的規則；遇到下一個段落名稱時，解讀方式才會切換。不要把一行 DOMAIN-SUFFIX 插入 [Host]，也不要使用全形方括號書寫段落標題。

[General]
dns-server = system

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

[Host]
lab.example.com = 192.0.2.10

二、[General] 與 [Host] 各自管理哪些內容？

[General] 管理基本行為，[Host] 指定網域與位址的靜態映射。遇到解析問題時，先在 Config 的目前設定檔中檢查這兩個段落。它們不是分流規則：將網域寫入 [Host] 不代表請求一定會走 DIRECT，修改 DNS 參數也不會自動將 Global Routing 切換為 Config。

[General] 檢查項目

內容格式
key = value
參數範例
dns-server = system
主要用途
設定 DNS 等基本項目
檢查位置
Config → 目前檔案 → 編輯畫面

先確認現有參數的用途，再逐項調整，不要一次取代整個段落。

[Host] 檢查項目

內容格式
網域 = IP 位址
語法範例
lab.example.com = 192.0.2.10
主要用途
為指定網域設定靜態位址映射
不包含的內容
URL 路徑與伺服器連接埠

映射目標變更後，記得同步更新；舊位址可能導致連線持續失敗。

dns-server = system 表示使用系統 DNS，不是為所有請求指定出口策略。如果目前使用的檔案設定了其他 DNS，請先記下原值，再比較修改前後的解析結果。網域解析出位址後，請求仍可能受到規則、所選伺服器及遠端解析方式等因素影響；不能只憑「DNS 有回應」就判斷網頁一定能開啟。

[Host] 不會變更 HTTPS 身分驗證。例如將 lab.example.com 指向自己管理的測試位址後，瀏覽器仍會以原網域存取，伺服器憑證必須適用於該網域。即使位址映射正確，憑證錯誤、目標連接埠未監聽，或伺服器未設定對應網站，都可能造成連線失敗；不要透過忽略憑證錯誤來掩蓋映射問題。

三、[Rule] 如何由上而下比對？

[Rule] 依排列順序逐條檢查，第一條符合的有效規則會決定策略。進入 Home → Global Routing → Config 後，再檢查目前檔案中規則的排列位置。以下流程僅說明規則分流的判斷方式，不代表 DNS、Host 與 URL Rewrite 在內部一定依照同一套固定流程執行。

識別請求 逐條檢查 首次符合 套用策略 套用預設處理 
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
關鍵字範例中的意思檢查重點
DOMAIN只比對完整網域 api.example.com。精確例外規則應排在涵蓋範圍較大的規則之前。
DOMAIN-SUFFIX比對 example.com 及其子網域。不要填入 https://、路徑或連接埠。
IP-CIDR比對 192.0.2.0/24 位址範圍。no-resolve 可避免為了這條規則額外觸發網域解析。
GEOIP依據 IP 地理資料庫比對 CN。依據 IP 資料判斷，不能只憑網域後綴推斷地區。
FINAL處理前面所有規則都未符合的請求。放在最後，避免提早攔截後續規則。

精確例外規則必須排在寬泛比對之前。在此範例中，api.example.com 先符合 DOMAIN，採用 DIRECT；其他符合 example.com 後綴的請求則採用 PROXY。若將前兩條規則對調，精確網域也會先符合後綴規則。此處的 PROXY 表示代理策略，不會自動建立伺服器參數；仍須在 Home 確認已選取可用的伺服器。

no-resolve 不等於停用所有 DNS。它限制的是相應 IP 規則的解析行為。對於尚未取得目標 IP 的網域請求，不應假設帶有 no-resolve 的規則一定會符合；直接以 IP 存取的請求，則可依照現有位址判斷。排查時請區分以網域存取與直接以 IP 存取這兩種測試條件。

結論：先調整精確例外規則，再修改預設策略

某個網域走錯路徑時，先檢查它上方是否有涵蓋範圍更大的規則，並將所需的精確規則移到前面；不要先把 FINAL 全域改成另一種策略，否則其他未符合規則的請求也會一併改變路徑。

四、[URL Rewrite] 與網域分流有何不同？

[URL Rewrite] 用於比對與改寫 URL，不負責選擇代理路徑。需要將某個請求網址重新導向至另一個網址時，才檢查這個段落；若只想讓某個網域走 PROXY，應修改 [Rule]。以下語法僅針對文件範例網域執行 HTTP 重新導向，不是供日常存取使用的規則。

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

連線經過 VPN，不代表 HTTPS 的完整路徑就會自動顯示。若改寫需要讀取加密後的 URL 路徑或內容，通常還涉及 MITM 相關設定、主機範圍與憑證信任；只新增一條 URL Rewrite 並不足夠。本例使用 HTTP 網址說明語法，閱讀設定時不需要擴大憑證信任範圍。

測試改寫時應檢查重新導向鏈，而不只是確認最後能否開啟頁面。瀏覽器可能快取舊的重新導向，應用程式也可能直接使用 HTTPS，因而看起來像是「規則沒有生效」。先確認原始請求確實符合正規表示式，再檢查是否發生預期的 302。不能只因「頁面最後打得開」，就認定這條改寫規則已符合。

五、修改檔案後如何逐步驗證？

一次只修改一個變數，才能釐清現象與設定之間的關係。測試前請記下目前檔案、Global Routing 模式與所選伺服器。若剛更新過既有訂閱中的伺服器清單，也應先固定測試時的選擇，避免把伺服器變更誤認為規則變更。

  1. 建立基準：保留可正常運作的原始檔案，並記錄同一目標在修改前是正常開啟、逾時、解析失敗，還是發生憑證錯誤。
  2. 確認模式：在 Home → Global Routing 選擇 Config。若使用 Scene，請先確認場景條件實際選取的模式，不要直接假設目前套用的是該檔案中的規則。
  3. 只修改一處：例如只新增一條精確的 DOMAIN 規則；儲存後確認該檔案仍處於啟用狀態，再重新送出請求。
  4. 排除舊連線：既有的長連線可能繼續沿用原本的路徑。結束原有請求，必要時重新連線，再存取相同目標。
  5. 比對並還原：若修改後才出現異常，請還原原始檔案並重新測試。還原後仍有異常，就繼續檢查伺服器、網路與目標服務，不要一再新增更多規則。

Connectivity Test 只能提供連線狀況的線索，不能取代實際服務請求的驗證。在 Home 執行測試後，仍須開啟發生問題的特定網域。測試成功只表示測試目標在相應條件下可連線，不代表所有網域的 DNS、Host 映射、規則與 URL Rewrite 都設定正確。

On Demand 用於觸發連線，不會決定個別請求套用哪條規則。若連線會隨網路條件自動變化，可到 Settings → On Demand 檢查觸發設定；若開關已開啟但網域走錯路徑，應返回 Global Routing 與 Config 檢查。這兩類問題不要反覆嘗試同一個開關來處理。

六、設定檔常見問題

我已將規則寫入檔案，為什麼流量還是都走同一條路徑？

先到 Home → Global Routing 確認目前不是 Proxy 或 Direct，再到 Config 確認啟用中的檔案。接著檢查目標規則上方是否已有涵蓋範圍更大的 DOMAIN-SUFFIX，或 FINAL 是否放得太前面；修改後重新建立連線，避免沿用舊連線。

有訂閱之後，還需要另外檢查 .conf 嗎？

需要。既有的伺服器訂閱通常用來維護伺服器資訊，規則檔則負責另一層設定。更新訂閱後，先到 Home 檢查伺服器是否有變動，再到 Config 確認目前使用的檔案；不要只因伺服器清單更新成功，就認定規則也已更新。

[Host] 可以寫成 lab.example.com:443 嗎？

此處應填寫網域與 IP 位址的映射，不要在網域後加上連接埠。伺服器連接埠由請求 URL 或連線設定決定；若目標使用 HTTPS 的 443 連接埠，應分別確認位址映射、443 是否可連線，以及憑證網域是否相符，不要把三者合併寫成一行 Host。

FINAL,DIRECT 和 FINAL,PROXY 該選哪一個？

依照你對未符合任何規則的請求之預期來選擇。前者會讓預設請求直連，後者則讓預設請求套用代理策略。先在 Config 查看 FINAL 上方涵蓋了哪些網域與位址，再決定如何處理其餘流量；這兩種寫法都不能取代完整的規則規劃。

刪除 [URL Rewrite] 能修復所有網頁異常嗎？

不能。請先保留原始檔案，只暫時移除與故障目標相關的改寫規則再測試。若狀況沒有改變，還原原內容並繼續檢查 [Host]、DNS 與 [Rule]；若異常消失，再縮小正規表示式的比對範圍，並檢查重新導向目標。

前往 App Store