Clash 協定與核心技術指南

一、先分清協定、傳輸方式與用戶端

三種名稱，分別回答三個問題

選擇設定檔時，先把一條連線拆成三個層次來看。Shadowsocks、VMess、Trojan、VLESS、Hysteria 2 和 TUIC 是協定名稱，決定用戶端與伺服器如何驗證身分、封裝要求，以及需要哪些參數。TCP、UDP、TLS、WebSocket、HTTP/2、gRPC 和 QUIC 則描述連線使用的傳輸或封裝方式。同一種協定可以搭配不同傳輸方式，但並非每種組合都能被所有核心辨識。Clash Plus 這類用戶端提供匯入、連線開關與系統介面；實際解析設定並建立連線的是它採用的核心或實作。只看應用程式名稱，無法判斷某種協定一定能用。

例如，看到一條標示 VLESS 的分享連結，還要確認它使用 TCP 或 WebSocket、是否啟用 TLS、有沒有其他安全層，以及目標核心是否支援所需欄位。看到 Hysteria 2 或 TUIC 時，則要先確認目前網路能否穩定使用 UDP，因為兩者都以 QUIC 為基礎。協定名稱相同，但傳輸參數不同，得到的相容性結果可能完全不同。這就是為什麼必須分開判斷「連結能否匯入」與「能否建立連線」：匯入器負責將文字轉成設定項目，核心則負責解讀設定並嘗試連線。

參數應以連線服務提供者的資料為準

伺服器位址、連接埠、密碼或使用者識別碼、TLS 伺服器名稱及憑證驗證要求，都應與連線服務提供者提供的資料一致。位址與連接埠用來找到伺服器；密碼或使用者識別碼用於協定驗證；TLS 伺服器名稱通常用來比對伺服器憑證。把不同設定檔的欄位拼在一起，通常無法建立有效連線。尤其不要把「某協定支援 TLS」誤解成「勾選 TLS 就能修好連線」：伺服器必須以相同方式提供服務，用戶端的傳輸層設定也必須一致。

Clash 設定檔還包含協定以外的項目。proxies 定義可用的出站連線，proxy-groups 整理選擇關係，rules 決定要求要送往哪個出站；DNS 設定則會影響網域名稱的解析方式。即使協定正確，若代理群組沒有引用對應的出站，或規則最後指向直連，介面上仍可能看不到預期效果。反過來說，變更出站模式也不會改變節點使用的協定。需要檢查這些層次時，依序確認「設定可解析 → 出站可選擇 → 連線可建立 → 規則命中預期出站」，比反覆切換開關更容易找出問題。

協定支援取決於「用戶端版本、採用的核心、實際傳輸組合」，並非協定名稱旁永久有效的勾選項目。匯入失敗時先檢查格式；匯入成功但連線失敗，再核對欄位與網路條件。

比較前先固定測試條件

所謂某種協定「比較快」，只有在伺服器位置、線路、裝置、網路與測試時間相近時才有比較意義。行動網路與家用 Wi-Fi 的封包遺失率、UDP 可用性和休眠機制都不同；同一份設定換個網路環境，排名也可能改變。評估是否適合日常使用，建議先釐清自己的需求：網頁短連線、持續下載、播放影片，還是長時間背景待機。接著觀察連線能否穩定恢復、第一個頁面是否能及時開啟、持續傳輸是否順暢，最後再比較協定名稱。後文對資源與耗電的討論是依運作機制做定性分析，不代表任何特定 iPhone 的固定耗電結果。

二、Shadowsocks：欄位較精簡的加密代理

從輕量轉送到多種加密方式

Shadowsocks 最初以輕量代理為設計方向：用戶端與伺服器約定加密方式和密碼，由代理在兩端之間轉送流量。它並非只有一種固定的參數組合。不同實作支援的密碼方式、驗證機制與擴充功能可能不同，因此設定中的 cipher 不可省略，也不能任意替換。常見的 AEAD 方法會同時提供加密與訊息完整性保護；較新的 Shadowsocks 2022 方法則有自己的金鑰格式與實作要求。核心能辨識某種 Shadowsocks 設定，不代表它支援所有方法。

在 Clash 風格的設定檔中，基本的 Shadowsocks 出站通常寫成 type: ss，並搭配 server、port、cipher 和 password。如果服務提供者要求額外的外掛或傳輸封裝，也需要加入對應的外掛欄位；缺少外掛時，即使基本出站欄位齊全，也未必能與伺服器設定一致。匯入前應先確認提供的是標準出站欄位、ss:// 分享連結，還是含有平台專用擴充功能的訂閱。不同匯入器能轉換的連結參數與外掛欄位範圍並不相同。

適用條件與排查順序

Shadowsocks 的欄位相對容易核對，通常適合用來認識代理設定的結構。基本連線的處理流程也較直接，但實際延遲主要取決於網路往返時間、伺服器負載、DNS 與傳輸狀態，不能把「設定項目少」等同於「任何環境下都最快」。如果密碼方式與伺服器不一致，切換規則模式通常無法恢復連線；如果是外掛不相容，就要確認雙方的外掛類型與參數，而不是只改密碼。使用 iPhone 時，也要確認所選用戶端的核心是否實作該加密方式，以及訂閱轉換過程是否遺漏外掛資訊。

實用的檢查方式是先在設定詳情中逐項確認位址、連接埠、加密方式與密碼來源，再查看是否有外掛相關欄位。接著確認代理群組確實列出這條出站，選取後重新建立連線。如果「連線開關已開啟，但要求仍走直連路徑」，應優先檢查出站模式與規則，不必繼續修改加密方式。若只有某一條 Shadowsocks 出站無法使用，而同一份設定中的其他出站正常，應先比對這條設定與服務提供者原始參數的差異，避免把局部設定問題誤判為系統網路權限問題。

要特別區分「協定類型」與「服務提供者的訂閱類型」。以 YAML 提供的訂閱可能同時包含多種協定出站；以 ss:// 開頭的連結則通常只描述單一 Shadowsocks 連線。前者還可能附帶規則、代理群組與 DNS；後者通常需要由用戶端自行加入代理群組。想讓多條連線依規則運作，應確認匯入的是完整設定檔還是單一分享連結，不要只憑檔名猜測內容。

三、VMess：識別欄位與傳輸組合

協定身分不等於傳輸方式

VMess 源自 V2Ray 生態系，透過使用者識別碼等資訊區分連線，並可搭配不同的底層傳輸方式。設定中通常會看到 UUID 格式的 uuid，有時也會有 alterId。採用較新設定的連線中，alterId 通常為 0；但仍應以伺服器的實際參數為準，不要把舊訂閱的值一律改成零。VMess 的身分欄位用來識別雙方連線；TCP、WebSocket 或其他網路類型則決定資料如何傳輸。排查時必須同時檢查這兩組資訊。

分享連結中常見的 vmess:// 內容，可能是經過編碼的一組連線參數，而非可直接閱讀的 YAML。用戶端能顯示出站名稱，只能表示它完成了一定程度的解析；還要確認位址、連接埠、UUID、傳輸類型、TLS 開關、路徑與主機名稱都有正確寫入核心設定。尤其 WebSocket 的路徑與要求主機名稱，通常要與伺服器設定成對一致，少一個字元都可能導致交握失敗。TLS 伺服器名稱也應依服務提供者的要求填寫，不宜直接用出站顯示名稱代替。

比較效能時，應檢視完整連線流程

與欄位較少的基本 Shadowsocks 連線相比，VMess 可能會再加上 TLS、WebSocket 等封裝，因此建立連線時需要經過更多步驟。不過這些步驟是否會造成明顯等待，取決於連線是否重複使用、網路往返時間與伺服器實作。如果拿啟用 WebSocket 與 TLS 的 VMess 連線，和未啟用這些層的連線相比，再把所有差異都歸因於「VMess 協定較慢」，這樣的結論並不成立。更合適的做法是在同一台裝置上比較實際使用情境：首次開啟頁面、連續載入資源，以及 Wi-Fi 切換到行動網路後能否恢復。

資源使用量也不能只按協定名稱排序。加密處理、TLS、系統網路延伸功能、記錄日誌與作用中的連線數，都會影響 CPU 喚醒次數與記憶體使用量。短時間測試時，介面更新或系統背景工作也可能掩蓋差異。對 iPhone 使用者來說，優先選擇參數完整、目前核心支援其傳輸組合且連線穩定的設定，比單憑協定標籤預測耗電更可靠。如果某份設定匯入後缺少傳輸欄位，應回頭檢查原始訂閱的轉換結果，而不是自行猜測常見的 WebSocket 路徑。

VMess 排查順序：先核對 UUID 與伺服器位址，再確認網路類型；使用 TLS 時檢查伺服器名稱，使用 WebSocket 時檢查路徑與要求主機名稱。最後再檢查代理群組與規則。

如果同一份訂閱在另一個用戶端可以使用，在目前用戶端卻無法使用，應記下兩邊辨識出的設定項目並逐一比較，不要只看節點顯示名稱。有些訂閱轉換工具會依不同實作產生不同欄位，導致畫面名稱相同，實際傳輸設定卻不同。協定欄位說明可搭配術語表閱讀；若要確認連線開關、設定匯入與規則模式的操作順序，請回到快速上手指南依步驟檢查。

四、Trojan 與 VLESS：名稱相近，依賴條件不同

Trojan 的 TLS 與密碼

Trojan 將 TLS 納入連線設計的核心，設定通常包含伺服器位址、連接埠、密碼，以及 TLS 所需的伺服器名稱等資訊。它使用密碼識別用戶端，但密碼不能取代 TLS 憑證驗證。正常情況下，用戶端仍應依服務提供者提供的資訊，檢查憑證與伺服器名稱是否相符；把憑證驗證關閉當成通用修復方式，會失去原本應有的身分確認機制。遇到憑證錯誤時，應優先檢查裝置時間、填寫的伺服器名稱、憑證狀態與伺服器設定。

Trojan 也可能搭配 WebSocket、gRPC 等傳輸方式。此時只有「Trojan + 密碼」不足以還原完整連線：路徑、服務名稱或要求主機名稱仍必須與伺服器設定一致。對行動裝置而言，TLS 交握會增加首次建立連線時的處理量，但連線後的體驗更取決於網路穩定度與連線重複使用情況。不能因為有 TLS，就斷定 Trojan 一定比較耗電；頻繁斷線並反覆交握，通常比長時間穩定連線更值得排查。

VLESS 的驗證與外部安全層

VLESS 同樣源自 V2Ray 相關生態系，但它和 VMess 並非單純改名的關係。VLESS 使用使用者識別碼辨識身分，本身不提供傳輸加密，實際安全性取決於搭配的 TLS 等外部安全層與具體傳輸設定。因此看到 type: vless 時，不應只檢查 UUID，還要確認傳輸類型、安全層及其參數。有些 VLESS 設定也會使用特定安全擴充功能；是否支援，必須以用戶端採用的核心能力為準。

這點在 Clash 核心家族中尤其重要。原版 Clash 的能力範圍與 Meta、mihomo 並不相同，不能因為 YAML 檔案可以開啟，就認定其中的 VLESS 出站已能執行。即使兩種核心都能辨識 VLESS，也可能對特定傳輸方式或擴充欄位提供不同程度的支援。匯入前先查看用戶端說明中的核心資訊；匯入後檢查解析提示、出站清單與連線日誌。若出現「不支援的代理類型」或未知欄位，應先考慮設定與核心不相容，而不是修改伺服器憑證。

分開檢查安全層與連線狀況

Trojan 和 VLESS 都可能涉及 TLS，但排查方式不同。Trojan 要核對密碼與 TLS 參數；VLESS 則要核對使用者識別碼、傳輸方式與外部安全層。兩者都可能遇到連接埠可連通、交握卻失敗的情況：前者可能是密碼或憑證名稱不一致；後者可能是核心不支援擴充參數，也可能是傳輸路徑不一致。先確認訂閱原始欄位，再檢查轉換後的 Clash 設定，最後才修改用戶端中可編輯的選項，才能避免把「匯入器漏掉欄位」誤當成「協定本身無法使用」。

如果設定來源同時提供不同協定的連線，不必為了追求較新的名稱而更換已穩定運作的出站。實際選擇應考量伺服器提供的完整參數、用戶端支援範圍、所在網路的穩定度與自身使用情境。只想完成日常連線的使用者，可先前往下載頁的Clash Plus iOS 下載入口查看用戶端，再確認匯入的設定支援哪些協定；協定名稱是否熱門，不能證明設定有效。

五、Hysteria 2 與 TUIC：先確認 UDP 條件

了解 QUIC，才能正確比較

Hysteria 2 與 TUIC 都使用以 UDP 為基礎的 QUIC 連線，但它們是不同協定，驗證欄位與設定格式不能互換。QUIC 整合了連線建立、安全交握與多工等能力；在合適的網路環境中，可縮短部分連線等待，也能避免單一封包遺失時多個傳輸串流一起受阻。不過「以 QUIC 為基礎」不代表在所有網路環境下都更快。裝置與伺服器之間必須能正常傳送 UDP；某些公共 Wi-Fi、企業網路或特殊連線方式可能會限制 UDP，導致連線建立失敗或不斷重試。

Hysteria 2 延續 Hysteria 專案重視高效率傳輸的設計方向，設定中常見伺服器位址、驗證資訊與 TLS 相關參數，也有與頻寬和傳輸行為相關的選項。不同用戶端或核心版本對這些欄位的接受方式可能不同。TUIC 同樣以 QUIC 建立代理連線，設定通常需要使用者識別碼與驗證憑證，也可能包含壅塞控制等選項。這些選項會影響連線行為，並不是「數值越大越快」的效能調整鈕；若伺服器沒有要求，不要複製其他連線的參數來試。

行動網路切換與重新連線

iPhone 在 Wi-Fi 與行動網路之間切換時，網路位址、路由與系統網路延伸功能的狀態都可能改變。在某些條件下，QUIC 連線可能較快恢復，但用戶端實作、伺服器設定與系統排程同樣重要，不能把協定設計上的潛在優勢視為必然結果。實際觀察時，應確認切換後的第一個要求是否成功、是否需要手動重新連線，以及長時間鎖定螢幕後連線能否恢復。如果只在某個 Wi-Fi 下失敗、行動網路卻正常，可以先檢查該 Wi-Fi 的 UDP 可用性，不必立刻更換整份訂閱。

排查 UDP 時，應分清「伺服器無法連線」與「UDP 路徑不穩定」。如果同一份設定在多個網路都無法建立連線，先檢查位址、連接埠、驗證與 TLS 資訊；如果只在某個網路失敗，優先比較網路條件。反覆降低憑證檢查要求或盲目修改驗證欄位，無法修復受限的 UDP 路徑。如果設定同時提供 TCP 與 QUIC 類協定，可以在相同地點和時間分別測試，觀察實際使用情境是否順暢，而非只看連線清單是否顯示已選取。

在設定檔相容性方面，Hysteria 2 不能直接按早期 Hysteria 格式理解；TUIC 的欄位也不能因為同樣使用 QUIC，就套用 Hysteria 2 的寫法。若訂閱轉換服務只輸出部分欄位，匯入後可能出現名稱正常、連線卻失敗的情況。應先確認訂閱匯出的目標格式確實適用於所用核心，再查看協定類型、驗證欄位或 TLS 名稱是否缺漏。核心不支援時，修改 YAML 縮排也無法補上協定實作。

六、速度、資源使用與 iPhone 耗電

分開看首個封包、傳輸量與穩定性

「連線速度」至少有三種不同含義：建立連線需要多久、開啟新頁面的首次回應需要多久，以及持續傳輸時能維持多少傳輸量。這些表現不一定一致。某種協定的交握步驟可能較少，但伺服器線路壅塞，頁面仍然載入緩慢；另一種協定初次建立連線需要較多處理，後續要求卻能重複使用連線，讓連續瀏覽更穩定。比較時應固定裝置、網路與伺服器條件，分別記錄首次要求與連續要求的體感，避免把 DNS 等待或應用程式本身的載入時間算到協定上。

網路品質改變時，排名也可能反轉。封包遺失會影響重傳與壅塞控制；TCP 和 QUIC 處理多個並行要求的方式不同，但都需要底層網路正常運作。UDP 不穩定時，Hysteria 2 或 TUIC 未必比 TCP 設定順暢。網頁由許多短要求組成，影片播放則更重視持續傳輸與中斷後的恢復。選擇協定前，先想想自己最常遇到哪種問題：首次開啟很慢、長連線容易中斷，還是只有特定網路無法建立連線。不同問題需要不同的檢查順序。

耗電量不是協定名稱的固定屬性

iOS 用戶端通常會透過系統網路機制接管相關流量。裝置耗電會受到無線電狀態、螢幕亮度、背景 App、DNS 查詢、日誌層級、連線重試與加密處理等因素共同影響。協定欄位的數量無法直接換算成耗電量。穩定維持少量連線的設定，可能比頻繁失敗、不斷重試的「輕量協定」更省資源；但長時間持續傳輸，仍會讓無線網路與處理器維持運作。比較耗電時，應盡量維持相同的螢幕與 App 使用方式，觀察一段正常使用期間，不要只根據幾分鐘內的電量百分比變化下結論。

排查異常耗電可以從具體行為著手：先確認是否有出站不斷重新連線，再查看日誌是否持續出現連線錯誤；接著檢查訂閱自動更新間隔、DNS 設定與背景網路活動。如果問題只出現在某一份設定，請比較它與穩定設定的傳輸方式和錯誤訊息。如果所有設定都一樣，則應留意系統網路延伸功能、其他 App 的網路要求與目前的網路環境。不要為了省電而任意停用 TLS 驗證或把所有規則改成直連；這會改變連線行為，卻無法證明耗電原因。

用實際使用情境進行小規模比較

可重複的測試流程如下：在相同網路下分別選取兩條已確認參數正確的出站，等待連線建立後，依序開啟平常使用的網頁或 App，觀察首次載入、連續載入及切換網路後的恢復情況。不要同時變更 DNS、規則、協定與伺服器，否則無法判斷是哪項變更造成差異。測試完成後，保留較穩定且符合需求的設定即可，不必追求單次測速的最高數值。若想了解 DNS 模式為何會影響首次要求，可繼續閱讀Fake-IP 與 DNS 對應說明。

協定比較沒有通用的「最快」或「最省電」排名。先確認連線成功，再於相同網路、相近使用情境和相同設定下比較；若持續重試，應先排除錯誤，而不是進行效能排名。

七、原版 Clash、Meta 與 mihomo 的關係

從原版設定到擴充核心

原版 Clash 建立了廣泛使用的 YAML 設定組織方式：出站、代理群組、規則與 DNS 等頂層欄位，組成一份可由核心讀取的設定檔。後來出現的 Clash.Meta 在此基礎上擴充協定與網路功能；mihomo 則是這條核心發展路線後續使用的名稱。它們之間有設定繼承關係，但不能簡單理解成「所有原版設定都完全相同，所有擴充設定也都能反向開啟」。讀取一份檔案所需的最低能力，取決於檔案實際使用的欄位與出站類型。

例如，只使用基本 Shadowsocks 出站、常見代理群組與規則的設定，通常比包含 VLESS、Hysteria 2 或特定 DNS 擴充功能的設定更容易在不同核心間移轉。不過即使協定類型相同，擴充欄位、規則類型與預設行為仍可能不同。不要假定原版 Clash 支援 Meta、mihomo 後續加入的所有協定。用戶端介面出現「Clash」字樣，也不能取代查看其實際採用的核心或內建協定支援說明。

設定相容性須逐欄位檢查

檢查 YAML 時，先看頂層結構，再確認出站的 type，接著檢查各類型專屬欄位。proxy-groups 引用的出站名稱，必須與 proxies 中定義的名稱一致；rules 最後指向的代理群組或出站也必須存在。若核心不認得某個代理類型，光把欄位名稱改成另一種拼法也無法相容。如果只有個別設定項目名稱不同，應參考目標核心的設定文件調整，並留意預設值是否也有變化。移轉設定時，先保留原始檔，再複製一份逐項修改，比直接覆寫正在使用的設定更穩妥。

以下是一份用來理解結構的簡短 YAML 範例，展示出站、代理群組與規則之間的引用關係。範例中的網域名稱與密碼僅用來說明欄位；實際連線必須改用連線服務提供者給出的完整參數。這段結構不包含用戶端所有系統設定，也不代表所有核心都支援任意附加欄位。

mode: rule
proxies:
  - name: Sample-SS
    type: ss
    server: proxy.example.net
    port: 443
    cipher: aes-128-gcm
    password: your-password

proxy-groups:
  - name: SELECT
    type: select
    proxies:
      - Sample-SS
      - DIRECT

rules:
  - MATCH,SELECT

範例中的 MATCH,SELECT 表示尚未符合其他規則的要求會交由 SELECT 代理群組處理；SELECT 則允許選擇範例出站或 DIRECT。這說明了引用關係如何串接，並非建議所有要求都使用相同規則。實際訂閱通常包含更細緻的網域與網路規則，也可能透過規則集更新。閱讀設定時，可以從最後一條匹配規則往回追蹤：規則指向哪個群組、群組中有哪些出站，以及所選出站的協定欄位是否完整。如此比只盯著單一節點名稱，更容易找出引用錯誤。

選擇用戶端，先看系統平台與核心

下載頁依 Windows、macOS、Android、iOS 和 Linux 列出用戶端，Clash Plus 在適用的平台列為優先推薦；其他用戶端的支援範圍則應以實際實作為準。桌面平台還有 Clash Verge Rev、FlClash 等選擇；Android 也有 Clash Meta for Android 等用戶端，但同一份訂閱在不同用戶端中的匯入結果仍須分別確認。選擇 iPhone 用戶端時，先查看 iOS 下載入口與用戶端說明，再確認目前訂閱所需的協定是否受其核心支援，不要直接以桌面用戶端的能力推斷手機端功能。

若想進一步了解 port、dns、proxies 到 rules 的完整檔案結構，可參閱YAML 結構逐段解析。本章的核心判斷只有一項：相容性取決於「目標核心能否辨識並正確執行設定中實際使用的每個項目」，而不是檔案副檔名或用戶端名稱。

八、訂閱格式相容性與情境選擇

分清完整設定檔與單一分享連結

「訂閱」指的是取得與更新設定的方式，不是某一種代理協定。訂閱 URL 可能回傳完整的 Clash YAML、由多條分享連結組成的文字，或適用於其他用戶端的格式。單一 ss://、vmess:// 等連結通常只包含某個出站的連線參數；完整 YAML 還可能包含代理群組、規則、DNS 與更新所需的其他資訊。用戶端能從 URL 下載內容，只表示檔案已取得，不代表目前的匯入器能正確辨識其格式。

匯入失敗時，先確認 URL 回傳的是檔案內容，而非登入頁面或錯誤頁面；再確認服務提供者標示的匯出格式是否適用於 Clash 風格設定。匯入後若出站數量異常、名稱顯示正常卻缺少傳輸參數，應查看訂閱原文與用戶端解析結果；必要時向服務提供者索取適用於目前核心的匯出格式。不要把其他用戶端產生的檔案直接改名為 config.yaml：副檔名不會轉換欄位，也不會補齊代理群組。關於 iPhone 上多份 Profile 的新增、更新與切換方式，請參閱設定檔管理說明。

依條件篩選，不按協定名稱排名

如果剛開始使用，先選擇能由用戶端完整匯入、且欄位能與服務提供者資料逐項核對的設定。已有穩定運作的 Shadowsocks、VMess 或 Trojan 出站時，不必為了更換協定而重做整套規則。如果服務提供者提供 VLESS 設定，應確認目前核心是否支援其傳輸方式與安全擴充功能；如果提供 Hysteria 2 或 TUIC，則先在常用 Wi-Fi 與行動網路下分別確認 UDP 連線狀況。經常在不同網路間移動的使用者，也應把切換後的恢復情況列入選擇條件，而不只看靜態的協定說明。

瀏覽網頁時，首次要求與 DNS 解析體驗通常較容易察覺；持續傳輸時，連線穩定度更重要；長時間待機時，則要觀察是否有不必要的重試與背景喚醒。這些情境都無法單憑協定名稱得出通用答案。實用的選擇順序是：確認核心支援、核對欄位、在常用網路建立連線、執行實際工作、觀察恢復情況與耗電。每次只改變一個條件，留下可供比較的結果。如果某一步失敗，先解決該層的問題，不要急著比較速度排名。

保留可還原的設定

調整設定前，先保留一份目前可正常使用的 Profile。將新訂閱匯入為另一份設定，確認出站、代理群組與規則都正常後，再切換日常使用的設定。如果更新後連線失敗，可以切回舊設定，比對更新前後的協定類型、伺服器欄位與代理群組引用，快速判斷是內容變更還是網路環境改變。訂閱更新不代表用戶端核心也同步更新：新設定若加入未受支援的協定欄位，仍需選用相容的用戶端實作，或使用服務提供者提供的相容格式。

操作流程可回到快速上手指南，安裝選項請見下載用戶端；如果遇到連線開關、匯入或規則模式方面的問題，可查看說明中心。本指南適合在操作過程中隨時查閱：先判斷目前問題屬於協定、傳輸、核心還是訂閱格式，再前往對應章節確認，不要一次修改所有設定。