2026-09-14 · 進階設定 · 約 8 分鐘

Shadowrocket .conf 設定檔結構解析：General、Rule、Host、URL Rewrite 寫法

解析 .conf 設定檔中的各個段落，說明 General、Rule、Host、URL Rewrite 的用途與書寫格式，並附上範例。

本文摘要

Shadowrocket（小火箭）的 .conf 檔案以段落組織設定，並非填入訂閱網址就能完成分流。本文適合已有自己的服務商與訂閱，準備在 Config 中檢查設定的使用者。先了解各段用途，再參考完整規則、網域對應與重新導向範例，最後依序進行單項修改、重新連線及檢查請求記錄。

1. .conf 的段名、鍵值與生效條件

設定檔是文字檔。方括號中的名稱用來標示段落，例如 [General]；直到下一段出現前，內容都屬於目前段落。段名中的空格須保留，[URL Rewrite] 不可任意改成其他拼法。鍵值設定通常使用 鍵 = 值，規則則以逗號分隔欄位，兩種格式不可混用。

Home 用來管理連線與伺服器選擇，Config 用來管理設定檔。匯入或儲存文字不代表已啟用設定：請先在 Config 確認目前選取的檔案，再前往 Home → Global Routing 選擇 Config。Proxy 是全域代理模式，Direct 是全域直連模式；Scene 則依照已設定的情境選擇路由方式。檢查規則順序時，請先固定使用 Config，避免切換情境影響判斷。

儲存設定 選取設定 啟用 Config 重新連線 檢查請求

以下僅展示可獨立閱讀的基本結構。範例會將未符合規則的流量交由 DIRECT 處理，適合用來觀察檔案能否正常解析，並非適用於所有網路的完整方案。example.com 是文件範例網域，不代表本站提供此服務。

[General]
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT
  • 請使用一般文字編輯器，並採用英文半形標點；不要將說明文字直接接在規則後方。
  • 每條規則各占一行。需要備註時，請另起一行並以 # 開頭。
  • 請先保留原始檔案副本，再編輯測試副本；不要同時修改 DNS、規則與重寫設定。
  • 實際檔案可能包含更多段落，本文介紹的四段並非所有功能的完整清單。

2. General：設定基本行為，不負責排列規則

[General] 用來放置全域基本設定。以 dns-server = system 為例，表示使用系統 DNS 設定；但不保證系統選用的解析器在所有網路環境中都可連線。將此行改成其他解析方式前，請先記錄目前使用的 Wi-Fi 或行動網路、目標網域及遇到的問題。

DNS 負責將網域解析為位址，Rule 負責選擇流量策略。兩者彼此相關，但不是同一個設定。解析失敗時，新增 DOMAIN-SUFFIX 規則不會自動修復解析器；同樣地，DNS 成功回傳位址，也不代表目標連接埠或代理路徑一定可用。

General 基本檢查

段名
[General]
設定項目
dns-server
範例值
system
書寫格式
dns-server = system

先確認原本的解析方式，再決定是否修改。

App 內生效狀態檢查

檔案位置
Config
路由入口
Home → Global Routing
驗證模式
Config
自動連線入口
Settings → On Demand

On Demand 控制符合條件時的連線，不會取代 Rule 的比對邏輯。

編輯文字時，請勿只憑名稱猜測設定項目。未確認支援的鍵值可能會遭忽略或造成解析問題。若要擴充 General，請以 App 內設定編輯介面中的對應項目及說明為依據，並保留修改前的值。也請另外檢查 On Demand 的自動連線行為，避免排查期間因自動重新連線而中斷。

3. Rule：由上而下比對，FINAL 放在最後

[Rule] 中的每一行都描述比對條件與執行策略。規則依排列順序逐條判斷，符合後便採用該條指定的策略。因此，具體網域規則通常應排在較寬泛的規則之前，FINAL 則放在最後。若將兜底規則放在前面，後續條件就無法如預期獲得比對機會。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
關鍵字範例含義檢查重點
DOMAIN-SUFFIX比對 example.com 及其子網域。只填網域，不加通訊協定、連接埠或路徑。
IP-CIDR比對 192.0.2.0/24 位址範圍。這是文件保留網段，不是可用的伺服器位址。
GEOIP依據 IP 地理資料庫判斷 CN。判斷結果取決於 IP 地理資料庫，不能只憑網域後綴判斷。
FINAL為前面未符合規則的請求選擇 PROXY。沒有比對值欄位，請寫成 FINAL,PROXY。

no-resolve 用來避免為了比對這條 IP 規則而主動進行網域解析。它並非「關閉所有 DNS」：請求本身或其他規則仍可能需要解析。若目前請求只有網域，沒有可供判斷的 IP，這條含有 no-resolve 的 IP 規則可能不會符合，請依實際記錄確認。

PROXY 代表代理策略，DIRECT 代表直連策略；兩者都不是通訊協定名稱。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 是連線通訊協定，連線參數仍須來自使用者自己的服務。將策略設為 PROXY 不會憑空建立可用連線，測試前請確認 Home 中已有可用伺服器。

排查規則問題：先確認請求符合哪一行

目標網域的連線方式不如預期時，請先在請求記錄中核對網域、符合的規則與策略，再移動該條具體規則。不要先更改所有 General 設定，否則無法判斷是哪項修改造成影響。

4. Host：固定網域對應，不等於選擇輸出策略

[Host] 用來指定網域與位址的對應關係。最直接的寫法是 網域 = IP 位址。它會變更目標網域對應的位址，但不會取代 Rule 中的 DIRECT 或 PROXY，也無法讓無法連線的位址變得可用。

[Host]
lab.example.com = 192.0.2.10

此片段僅說明語法；192.0.2.10 是文件保留位址，不能直接用來測試連線。在自己的測試環境中，請填入明確受控的網域與實際可連線的位址，並確認服務正在監聽的連接埠。Host 每行只設定名稱對應，不要寫成 192.0.2.10:443；HTTP 常用 TCP 80，HTTPS 常用 TCP 443，連接埠由 URL 或 App 的連線參數決定。

  • 網域請填寫 lab.example.com，不要填入 https://lab.example.com/path。
  • 使用 HTTPS 時，伺服器憑證仍須符合請求的網域。固定 IP 不會略過憑證驗證。
  • 測試前請中斷舊連線並重新發出請求，避免重用連線或快取掩蓋修改結果。
  • 移除測試用對應設定後再次檢查，確認沒有將臨時位址留在正式設定檔中。

若「位址已變更，但頁面仍無法開啟」，請分別檢查位址是否可連線、連接埠服務、憑證與路由策略。Host 是排查解析問題的工具之一，不適合將從網路上隨意找到的位址寫入長期設定。

5. URL Rewrite：比對 URL，再指定重新導向動作

[URL Rewrite] 用來處理 URL 比對與重寫。以下範例使用正規表示式比對一個 HTTP 網址，再以 302 回傳重新導向目標。它不會建立 DNS 對應，也不是將網域指定給 PROXY 的另一種寫法。

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302
  1. ^ 限定 URL 開頭，$ 限定結尾，避免只比對到網址中間的一部分。
  2. example\.com 中的句點已跳脫，表示字面上的句點，而非正規表示式中的任意字元。
  3. (.*) 會擷取斜線後的內容；目標中的 $1 則引用第一個擷取群組。
  4. 302 代表重新導向動作。瀏覽器收到回應後會再向目標網址發出請求，並非兩端流量直接互換。

此表示式只會比對以 http://example.com/ 開頭的網址，不會比對 https://example.com/，也不會比對含明確連接埠的 http://example.com:80/。請在測試前先釐清這些適用範圍。不要為了「全部都比對」而任意放寬網域條件，否則可能改寫無關的請求。

遇到循環重新導向時，請先移除新增的重寫規則，再觀察原始網站的回應。只將 HTTP 單向導向 HTTPS 的規則，仍可能受到伺服器自身重新導向邏輯影響；請分別記錄初始 URL、回應狀態與重新導向目標，不要只看最後能否開啟頁面。

6. 分段驗證：分開檢查解析、路由與重寫

四個段落分別處理基本行為、流量分流、名稱對應與 URL 處理。它們並非固定依序執行的四個步驟；不同請求是否需要解析、是否能看見 URL，以及是否符合網域規則，都會影響實際處理方式。以下數字僅描述本文範例結構，不代表 App 的完整支援範圍。

4 個段落
本文解析：General / Rule / Host / URL Rewrite
4 種類型
規則範例：DOMAIN-SUFFIX / IP-CIDR / GEOIP / FINAL
80 / 443
HTTP / HTTPS 常用的 TCP 連接埠
  1. 在 Config 中保留原始檔案副本，並確認已選取測試檔案。前往 Home → Global Routing，固定使用 Config。
  2. 先只測試 General 與 Rule。使用自己確認可連線的目標，記錄時間、網路類型及所選伺服器。
  3. 停止後重新連線，再發出一筆新請求。區分解析錯誤、連線逾時、TLS 錯誤與 HTTP 狀態碼。
  4. 需要使用 Host 時，只新增一筆受控的網域對應，並比較修改前後的目標位址。
  5. 最後再單獨測試 URL Rewrite，觀察重新導向目標。若測試失敗，請撤銷最近一項修改，不要覆寫整份設定。

伺服器延遲測試有結果，只能表示該次測試收到回應，不能證明目標網站的 DNS、TCP 443、TLS 與 HTTP 請求都正常。收到 HTTP 403 表示伺服器已回應請求，應檢查伺服器端的存取條件，不要直接歸因於 .conf 語法。

7. 常見問題：檔案已儲存，為什麼結果沒有改變？

修改了 Rule，網站卻仍然全部走代理？

先查看 Home → Global Routing 是否設為 Proxy。改成 Config 後，回到 Config 確認目前選取的是剛修改的檔案，重新連線並發出新請求，再檢查符合的規則；不要只憑網頁開啟速度判斷策略。

FINAL 可以放在檔案第一行嗎？

應放在 Rule 段的最後。請將具體網域與位址規則移到它之前，例如先寫 DOMAIN-SUFFIX,example.com,DIRECT，再寫 FINAL,PROXY，該網域才有機會符合直連規則。

更新訂閱後，自己修改的設定會保留嗎？

請先區分 Home 中的伺服器訂閱與 Config 中的遠端設定。前者通常會更新伺服器項目；後者重新取得設定文字時，可能會覆蓋本機修改。若要長期保留編輯內容，請另存為獨立的本機副本，並在更新後確認目前選取的檔案。

Host 改成某個 IP 後，HTTPS 為什麼會出錯？

確認該 IP 上是否有提供目標網域的 HTTPS 服務，以及憑證是否涵蓋該網域。先撤銷 Host 對應，比較結果；不要以關閉憑證驗證來取代修正網域、位址或伺服器端設定。

儲存設定後的最後檢查可歸納為三項：目前檔案正確、Global Routing 模式正確、新請求符合預期規則。確認這三項後，再處理 DNS、目標服務與重寫範圍，可減少將連線故障誤判為檔案格式錯誤。

App Store 正版查核 →