正版取得與購買紀錄
先確認應用程式身分,再進行購買。Shadowrocket 是 Apple 平台上的付費商業用戶端,主要使用情境為 iPhone 與 iPad,唯一取得管道是 App Store。Mac、Apple TV 與 Apple Vision 的相容性也可在同一產品頁查看;系統需求及是否支援通用購買,請以 App Store 頁面標示為準。本手冊後續步驟以 iPhone 與 iPad 為主,不將其他裝置的頁面配置視為相同操作說明。
核對名稱、開發者與 App ID
從正版核驗頁前往商店說明,依序核對應用程式名稱 Shadowrocket、開發者 Shadow Launch Technology Limited,以及產品連結中的 App ID 932747118。接著比對商店圖示與本站頁首的官方圖示。名稱相似不代表是同一款應用程式;搜尋結果的排序、附加介紹或頁面配色也不能取代身分核對,應以產品頁實際列出的資訊為準。
商店頁面也提供價格、相容性與更新紀錄查詢。購買前請展開相容性資訊,確認目前裝置是否可安裝;價格則以目前商店地區與帳戶結帳時顯示的金額為準。文章中的價格範例不是最終扣款依據,也不要只因裝置屬於某個產品系列,就推定一定支援。同一型號在系統狀態不同時,商店顯示的可用操作也可能不同。
區分用戶端購買與連線服務
Shadowrocket 採一次買斷,美國商店定價約為 2.99 美元;各商店地區會以當地貨幣顯示,實際金額請以 App Store 頁面為準。購買的是用戶端使用資格。伺服器位址、驗證資訊、服務可用期限與資料流量額度,來自使用者已有的服務設定,不會因購買用戶端而自動產生。安裝完成但清單仍為空白時,應接著匯入已有設定,而不是重複購買應用程式。
購買前建議確認目前使用的 App Store 帳戶,並保留系統產生的購買紀錄。部分裝置設定可分別管理系統帳戶與商店購買帳戶,不能只看裝置頂端顯示的姓名,就判斷購買歸屬。日後更換裝置、重新安裝或查詢付款時,重點是找到原始購買紀錄,而非依賴用戶端內的伺服器名稱、設定備註或連線狀態來證明曾經購買。
安裝、復原與更新的範圍
在商店完成購買與安裝後,先開啟應用程式一次,確認能進入主要頁面,再處理訂閱和權限。若商店顯示需要再次付費,先檢查帳戶與購買紀錄是否相符,不要急著確認付款。同一購買帳戶再次取得應用程式,以及其他裝置適用的權益,都應依商店頁面與帳戶實際紀錄判斷;是否適用「家人共享」,也請以頁面標示及帳戶設定為準。
更換裝置時,請分別處理兩件事:復原應用程式購買資格,以及復原應用程式內的資料。透過已購項目重新取得應用程式,不代表伺服器、訂閱連結與本機設定一定會一併還原。準備更換裝置時,應先確認是否有可用的設定備份,並保存自己已有服務的原始資訊。只記得一則伺服器備註,通常不足以重建連線,因為備註不包含協定、連接埠與驗證參數。
應用程式更新由 App Store 管理。更新前,請保存目前使用的設定與必要連線參數;更新後,檢查預設伺服器、Global Routing 及目前啟用的設定是否仍符合預期。若商店無法完成安裝,先處理帳戶、付款、裝置空間或系統相容性等商店層級問題。此階段尚未涉及遠端連線,修改 DNS 或規則無法解決購買與安裝問題。
本章完成標準:能在商店核對同一款產品、確認購買歸屬、正常開啟應用程式,並清楚知道已有的連線資訊存放在哪裡。不要以「圖示已出現在主畫面」作為準備工作的全部。先釐清取得應用程式與復原資料的界線,之後遇到連線失敗,才能準確判斷是應用程式狀態、參數問題,還是需要檢查遠端服務本身。
首次啟動與 VPN 設定權限
首次開啟後,先熟悉 Home 頁,再開始連線。Home 集中顯示連線開關、Global Routing、Connectivity Test 與 SERVER 清單。不同裝置及應用程式狀態可能影響區塊呈現方式,請依英文名稱辨識功能,不要依固定座標點按。詳細介面說明請參閱首次開啟與 Home 頁說明;本章著重說明權限與連線狀態的關係。
認識 Home 頁的四個判斷重點
連線開關用來啟動或停止目前的連線;Not Connected 表示目前尚未建立相應的連線狀態,不代表應用程式購買失敗。Global Routing 決定流量依設定規則處理、採用代理策略,或以直連方式傳送。SERVER 清單列出可選的伺服器項目;開啟項目進行編輯,與將它設為預設伺服器,是兩種不同操作,需分別確認。
Connectivity Test 用於檢查清單中伺服器的連通情況。測試結果有助縮小問題範圍,但不能取代完整的實際連線驗證。初次進入時清單若為空白,測試自然無法提供有效的伺服器結果;清單中有項目,也不代表每一項都可用。請先完成第三章的參數核對,再參考測試結果,避免在缺少必要資訊時反覆切換開關。
還要區分「應用程式中顯示的狀態」與「系統中保留的設定」。系統可能保存先前加入的 VPN 設定,但應用程式目前並未連線;應用程式能正常開啟,也不代表系統已允許它建立連線。查看狀態時,先確認應用程式目前選取的項目與開關,再查看系統的 VPN 狀態;不要只憑狀態列的單一圖示,就推斷所有流量的實際去向。
了解新增 VPN 設定的系統提示
當應用程式要求建立所需的網路連線時,系統會要求確認新增 VPN 設定。這是 Apple 系統管理連線權限的流程,不是購買確認,也不是訂閱登入。請先確認提示是在自己主動操作 Shadowrocket 時出現,再依系統指示允許,並完成裝置要求的身分驗證。確認前可先保存手邊的操作狀態,避免切換應用程式後忘記提示來自哪個步驟。
若先前取消授權,先返回應用程式確認是否仍可重新發起連線,再依目前的系統提示操作。系統設定路徑會隨介面改版而變動,可使用設定搜尋查找 VPN,檢查是否存在 Shadowrocket 對應的設定及其目前狀態。不要連續新增多個用途不明的設定,也不要為了重試而刪除其他仍在使用的網路設定;先確認項目歸屬再處理。
若裝置由組織管理,網路設定可能受到管理政策限制。遇到無法確認、無法新增或開關立即恢復原狀的情況,應先檢查裝置是否受到相關限制,並向裝置管理者確認允許的設定。重複匯入訂閱不會改變系統政策。排查時保留準確的系統提示文字,比憑印象描述「沒有反應」更有助於定位問題。
建立首次操作的基準狀態
初次設定時,先使用手動連線,暫不啟用 On Demand。只保留一條明確的操作流程:準備伺服器、選取預設項目、檢查路由方式、開啟連線、驗證連線。如此一來,狀態改變時就能對應到最近一次操作。若同時啟用自動觸發、修改設定並更新訂閱,連線恢復或中斷的原因便不易辨認,也難以判斷某次修改是否真正生效。
首次權限設定完成後,記錄應用程式能否維持開啟,以及系統是否顯示相應連線。若開關無法維持,優先檢查權限、設定有效性與錯誤提示;若開關能維持開啟但無法連線,則進入連線驗證流程。這兩種情況屬於不同的疑難排解方向。不要把「已允許權限」、「開關已開啟」和「目標連線成功」混為同一個籠統的成功條件。
完成本章後,應能指出 Home 頁上負責連線、路由、測試與伺服器選擇的區域,並知道是否已確認系統權限。此時不要求所有目標都能連線,但必須清楚目前欠缺的是伺服器資訊、權限確認,還是連線驗證。若只想依最短流程完成操作,可返回使用教學;若要了解參數來源與匯入範圍,請繼續下一章。
伺服器與訂閱匯入
匯入前,先確認取得的是單一伺服器資訊、伺服器分享內容、訂閱連結,還是設定檔。這些項目用途不同:伺服器項目保存單次連線所需參數;訂閱用於更新一組伺服器;設定檔則主要用來組織路由及相關設定。把設定檔網址當作訂閱輸入,或將一般網頁網址填入伺服器位址欄位,都可能造成解析失敗或內容與預期不符。
手動新增與協定參數核對
使用 Add Server 手動新增時,先選擇協定,再填寫位址與連接埠,最後核對驗證及傳輸參數。欄位內容必須來自使用者已有的服務資訊,不應靠名稱猜測。相同網域可能對應不同連接埠,相同連接埠也可能使用不同協定;欄位看似填妥,不代表組合正確。儲存後重新進入編輯頁逐項複核,尤其留意複製時多出的空格、換行與全形符號。
| 協定 | 核對重點 |
|---|---|
| Shadowsocks | 確認位址、連接埠、加密方式與密碼皆符合服務設定。 |
| VMess / VLESS | 核對 UUID、傳輸方式及相應的 TLS、路徑等參數。 |
| Trojan | 核對密碼、TLS 相關設定與伺服器名稱要求。 |
| Hysteria2 | 核對驗證資訊、TLS,以及服務端要求的相關選項。 |
| WireGuard | 核對金鑰、位址、端點與服務端要求的其他參數。 |
表格僅說明核對方向,不代表所有協定都要填寫相同欄位。若服務資訊包含傳輸路徑、主機名稱或 TLS 伺服器名稱,應依各自用途填寫,不要一律複製到位址欄。伺服器位址用來指定連線端點;TLS 相關名稱則用於相應的身分驗證。兩者可能相同,也可能由服務設定明確指定不同值,不能互相取代。
匯入已有訂閱並檢查結果
若已有訂閱,請使用應用程式的新增入口選擇 Subscribe,輸入完整訂閱網址並儲存,接著執行相應的更新操作。訂閱連結通常包含存取憑證,複製時應保持完整,但不要貼到公開聊天、截圖或問題描述中。匯入後返回 SERVER 清單,檢查是否出現預期的分組與項目;只看到訂閱名稱,不代表伺服器內容已成功取得。
若清單為空白,先確認是更新尚未完成、請求失敗,還是回傳內容無法辨識。檢查連結開頭、結尾與查詢參數是否完整,並確認取得的確實是訂閱入口,而非帳戶管理網頁。接著向原服務提供者確認訂閱狀態與支援的內容格式。不要連續重複新增同一網址,否則容易產生多個同名分組,讓後續更新與刪除更難判斷。
更新訂閱可能新增、移除或修改伺服器項目,因此不只是刷新顯示。更新前記下目前預設伺服器所屬分組,更新後重新確認選取項目是否仍有效。若伺服器名稱變更,不要只依舊備註判斷它已消失;應比對分組與服務提供者的說明。關於清單空白與解析錯誤的處理方式,請參閱訂閱解析失敗自我檢查。
分享內容、QR Code 與設定檔匯入
使用 Scan QR Code 匯入時,先確認 QR Code 來自自己已有服務的可信資料,並檢查匯入後顯示的協定、位址與備註。掃描只能減少手動輸入,不會驗證遠端服務品質,也不保證參數仍然有效。若 QR Code 顯示在同一部裝置上,請使用應用程式目前提供的相應匯入方式;不要為了辨識 QR Code,將含有憑證的圖片交給公開辨識服務。
匯入分享內容後,應確認儲存的是單一伺服器,還是訂閱入口。單一項目通常不能據此推斷日後會自動更新;訂閱中的項目則可能在更新時改變。若匯入後可編輯欄位與原始資料不符,先保留原始資料,逐項檢查協定支援與參數對應,不要立刻覆寫原本可用的伺服器,以免失去比較基準。
匯入設定檔後,還要在 Config 中確認目前啟用的是哪一份。檔案已儲存與檔案已啟用是不同狀態。匯入含有規則的設定前,先閱讀其策略參照、最終規則與 DNS 設定,並檢查是否依賴額外的規則資源。若設定引用了不存在的策略,不能只因檔案可以開啟,就認定分流邏輯完整。下一章將說明這些規則如何與 Global Routing 搭配。
本章完成標準:清單中有可辨識的伺服器,來源類型明確,重要參數可與原始資料對照,訂閱更新結果也能複核。最後請另外選取預設伺服器,不要停在編輯完成的頁面就以為已選取。保留一份可用參數作為復原依據,再進入路由設定,就能將匯入錯誤與分流錯誤分開處理。
三種路由方式與規則順序
Global Routing 的三種方式分別是設定檔 Config、代理 Proxy、直連 Direct。它們會改變連線採用的路由判斷方式,不會補上伺服器密碼,也無法修復遠端服務故障。排查前先確認目前使用的方式,尤其是「伺服器測試有結果,但某個應用程式的連線不如預期」時。問題可能是規則選擇了不同策略,而非預設伺服器失效。
先確認由誰決定流量路由
| 介面選項 | 主要判斷方式 | 檢查重點 |
|---|---|---|
| Config | 依目前設定中的規則選擇策略。 | 啟用的設定、規則順序與策略參照。 |
| Proxy | 採用代理路由方式。 | 確認所選伺服器能否連線至實際目標。 |
| Direct | 採用直連路由方式。 | 確認目前基礎網路能否連線至目標。 |
Config 適合依不同目標分別處理連線,前提是目前設定內容明確。Proxy 可用來檢查代理路徑基本上是否可用,但不應認為所有特殊流量與系統行為一定完全相同。Direct 也不等於「停止應用程式」。需要結束目前連線時,請使用連線開關;需要比較路由影響時,再切換 Global Routing。
依由上而下的順序理解規則
規則通常依序檢查,由第一條符合的規則決定相應策略。具體條件放前面,涵蓋範圍較大的條件放後面,最後以 FINAL 處理未符合其他規則的連線。若太早放入涵蓋範圍廣的規則,後面的精確規則可能就沒有機會比對。排查時不要只搜尋某個網域是否出現,也要閱讀它前面的規則,以及這些規則實際指向的策略。
[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY
這是語法範例,不是適用於所有環境的完整設定。DOMAIN 指定特定網域;DOMAIN-SUFFIX 用於比對網域後綴;DOMAIN-KEYWORD 依網域中的關鍵字比對;IP-CIDR 用於比對 IP 位址範圍。GEOIP 依賴相應的位址資料,不能將其判斷視為目標服務歸屬的絕對依據。FINAL 是末尾的預設規則,應符合使用者預期的預設路徑。
範例中,精確網域規則位於關鍵字規則之前,因此不能只因關鍵字包含 example,就斷定所有相關請求都會直連。同樣地,網域規則與位址規則比對的資訊不同;實際連線能提供哪些比對資訊,也會影響規則是否命中。不要把瀏覽器網址列顯示的頁面名稱,直接當成該頁面所有請求都只涉及一個網域的證據。
區分規則、策略與目前設定
PROXY、DIRECT 與 REJECT 是規則中常見的策略關鍵字,作用各不相同。若規則引用了自訂策略名稱,應確認相應定義確實存在,並檢查該策略最後使用哪部伺服器。檔案語法看似正確,仍可能因策略名稱拼寫不同而不符合預期。修改時保留大小寫、分隔符號與欄位順序,不要將英文逗號換成全形逗號。
Config 中可能儲存多份檔案。編輯其中一份後,先儲存,再確認目前使用的確實是這份檔案,最後依應用程式提示讓連線套用新設定。只修改檔名不會改變規則內容;遠端設定更新也可能覆寫本機修改。若要長期保留自訂規則,應明確記錄其維護位置,並在更新前保留副本,不要把所有修改都堆在來源不明的檔案中。
單一目標發生異常時,先暫時比較 Proxy 與 Config 的結果。若代理路徑正常而設定路徑異常,優先檢查規則與策略;若兩者都異常,再回頭檢查伺服器與遠端條件。比較後恢復原本需要的方式,避免將臨時排查狀態當成長期設定。測試期間每次只改變一個條件並記錄變化,才能保留有用的因果關係。
最後,規則比對不是設定一次就永遠不變。目標服務可能使用多個網域、不同位址與連線方式,設定更新也可能改變規則順序。應在實際使用情境中驗證,不要只因範例規則存在就結束檢查。涉及 DNS 與位址判斷時,可接著閱讀第七章;常見狀況的整理說明請參閱常見問題。
連線、驗證與分層疑難排解
連線是否成功應分層判斷:基礎網路可用、伺服器參數有效、系統允許建立連線、目前路由符合預期,以及實際目標能完成請求。任何一層異常都可能呈現為「無法連線」,但處理方法各不相同。先清楚描述現象,例如開關無法維持、測試逾時、只有一個目標失敗,或切換網路後出現異常,再選擇相應的檢查方式。
建立可重複的連線流程
先確認目前的 Wi-Fi 或行動網路能正常連線。若網路要求完成登入或接入確認,請先完成該流程。接著返回 Home,在 SERVER 清單中選取要驗證的伺服器,確認預設選取標記位於目標項目上。不要把點選項目進入詳細資料,誤認為已完成預設選取;也不要只看同名備註,因為不同分組中可能有名稱相同的伺服器。
接著確認 Global Routing。首次驗證可先選擇明確的代理路徑,再開啟連線,並依提示處理系統權限。狀態穩定後,執行 Connectivity Test,並在瀏覽器或實際要使用的應用程式中發出新的請求。預設選取與首次測試的完整步驟,請參閱首次連線與測試說明。
測試時盡量固定網路、伺服器與目標,避免一次操作中同時改變三者。頁面可能有快取,應用程式也可能保留原有連線;觀察結果時,應確認是否真的產生新請求。若只查看已載入的頁面,容易把快取內容誤認為網路連線成功。可重新執行明確的操作,並比對連線紀錄是否出現與目標相符的新活動。
區分測試結果與實際連線結果
Connectivity Test 顯示的是目前測試條件下的連通情況,不代表遠端所有服務都能正常運作。測試有結果但實際目標連線失敗,可能與目標本身、DNS、規則或應用程式使用的連線方式有關;測試逾時,也不能立即推斷每個已儲存欄位都填錯。先比較其他已有伺服器,再比較同一部伺服器在另一種基礎網路下的表現,有助縮小問題範圍。
若連線開關立即關閉,優先查看應用程式提示與系統 VPN 狀態,檢查權限和設定是否有效。若開關維持開啟但所有請求都失敗,先核對預設伺服器、協定、連接埠與驗證資訊,再確認遠端服務狀態。若只有 Config 下連線失敗,請檢查目前啟用的檔案與規則策略。若只有單一應用程式異常,應檢查該應用程式涉及的網域與請求,不要立刻重設所有設定。
還要區分短暫中斷與穩定重現。鎖定螢幕後恢復、網路切換或遠端連線重建期間,可能出現過渡狀態;請先等目前操作完成,再進行新的測試。若能依相同步驟重現異常,記錄發生條件;若只是偶發,不要立即修改多個底層參數。接連疊加變更可能暫時掩蓋問題,卻讓原本可重現的條件消失,增加後續維護成本。
以最少變更定位故障層
多部已有伺服器都發生異常時,先檢查共同條件:是否使用同一個基礎網路、同一份設定、相同的 DNS 設定或相同的系統限制。若只有一部伺服器異常,則應優先核對該項目的參數與遠端狀態。依條件分組判斷,比逐項亂改更有效。比較時保留一個已確認可用的項目作為對照,不要在未記錄原始值前覆寫其驗證參數。
發生 TLS 或身分驗證相關錯誤時,核對裝置時間、伺服器名稱要求與原始參數;不要隨意關閉驗證來取代檢查。發生網域解析錯誤時,先判斷是伺服器網域無法解析,還是目標網域處理異常,兩者涉及不同環節。若發生逾時,則需綜合網路、連接埠與遠端狀態分析;相同的錯誤文字不一定代表相同原因。
需要進一步協助時,請提供已遮蔽敏感資訊的現象、協定類型、網路類型、Global Routing 方式與已完成的對照測試。不要公開完整訂閱、密碼、UUID、金鑰或含查詢參數的網址。錯誤提示可保留與原因相關的部分,伺服器身分資訊則應遮蔽。聯絡原服務提供者時,說明哪個項目在何種網路下可重現,通常比傳送整份設定更清楚。
本章結束時,應得出可複核的結論:基本連線可用,或故障已縮小至權限、參數、路由、解析或目標服務其中一層。確認連線成功後,再恢復需要的 Config 方式,檢查常用目標是否符合預期。接著前往 Data 觀察實際流量,不要把單次測試數字當成長期連線品質的完整證明。
流量統計與連線觀察
Data 用於查看應用程式提供的流量資訊及相關連線活動,適合用來確認「是否產生流量」、「變化來自哪個操作」與「統計範圍為何」等問題。這與服務提供者的帳戶結算紀錄並非同一種計量系統。閱讀任何數字前,先確認頁面顯示的時間範圍、統計對象與單位,再判斷增長是否異常,避免直接相減不同範圍的數據。
比較前先確認統計口徑
上傳與下載分別表示資料傳輸方向,瞬時速率與累計資料量也不同。速率表示特定時間區間內的傳輸速度,累計量則表示相應範圍內傳輸了多少資料。頁面上的瞬時變化不能直接推算整月用量;同樣地,一段時間沒有明顯速率,也不能證明先前沒有背景傳輸。應搭配觀察的起迄時間與操作行為解讀結果。
用戶端統計、系統行動數據統計與服務提供者紀錄可能不同,因為計量邊界、工作階段範圍、更新時機及協定額外負載不一定相同。查看服務用量時,應以已有服務的帳戶紀錄與計量說明為準。若數字不一致,先確認比較的是同一時段、同一裝置與同一連線範圍,不要只憑差額就認定其中一方出錯。
若準備重設或清除統計資料,先保存需要的觀察結果,並確認操作會影響哪些本機紀錄。重設用戶端數字不會恢復遠端帳戶額度,也不會改變已發生的資料傳輸。不要為了讓數字歸零而反覆清除,否則會破壞跨時段比較所需的基準。若要長期記錄,應一併記下時間、網路與使用情境。
透過單一操作觀察流量變化
若要確認某項操作是否產生預期流量,先記錄目前讀數,暫時減少其他應用程式的活動,再執行一項範圍明確的操作,例如重新載入某個頁面。操作結束後返回 Data,比較相應紀錄的變化。若同時播放媒體、同步照片並更新應用程式,就很難將總量增加歸因於特定頁面,單一數字也就失去排查價值。
背景同步、通知與應用程式自行重新整理都可能產生連線,因此使用者沒有主動點按,不代表裝置完全沒有網路活動。觀察到流量持續增加時,先檢查系統和應用程式正在執行的工作,再分析具體連線紀錄。媒體快取與預先載入也可能使實際傳輸量大於螢幕上目前可見的內容,需搭配使用情境解讀。
若要確認分流是否正確,流量增加只能證明有資料傳輸,無法單獨證明命中了預期規則。應搭配特定目標、連線紀錄與路由策略核對。尤其使用 Config 時,載入一個頁面可能涉及多個網域,不同請求也可能符合不同策略。總量變化不能取代第四章的規則檢查,更不能據此斷言整個應用程式始終使用同一條路徑。
查看連線資訊並保護紀錄
若應用程式提供目標、策略或錯誤等連線資訊,應以單一請求為單位閱讀:先確認操作發生時間,再定位對應目標,接著檢查使用的策略與結果。不要看到清單第一列,就推斷它一定對應剛才開啟的頁面,因為背景請求可能同時出現。目標若使用共用網域或位址,也不能只憑名稱片段確認它屬於哪個應用程式。
紀錄可能包含瀏覽網域、位址、時間與其他網路細節,匯出或截圖前應先檢查內容。分享問題時,只保留與故障相關的少量項目,並遮蔽個人服務資訊與存取憑證。若完整記錄會暴露無關活動,先擷取錯誤發生時間與必要欄位;排查通常需要清楚的上下文,而非越多原始資料越好。
持續出現大量失敗連線時,先確認它們是否集中於同一目標、同一策略或同一時間點。相同目標反覆重試可能使紀錄迅速增加,但不代表有同等規模的有效資料傳輸。應回到目標與路由層檢查原因,不要只根據紀錄筆數判斷線路負載。確認統計口徑後,項目數量與資料量才有比較意義。
完成觀察後,將臨時測試與日常使用分開記錄。長期維護只需保留重要異常、變更前後的結果及必要基準,不必持續蒐集所有細節。若 Data 顯示活動正常但目標仍異常,應繼續檢查回應是否成功、內容是否完整,以及應用程式本身的狀態。有資料傳輸只能表示連線中發生了活動,不能直接等同於服務請求已完成。
常用設定與自動連線
修改 Settings 前,應先確認手動連線已可正常使用。先明確要解決的問題,再調整相應設定,並保留原始值。應用程式設定、目前設定檔與系統網路設定可能分別影響同一條連線,因此排查時要註明變更所在層級。不要只記錄「換了 DNS」或「開啟自動連線」,而應寫清楚修改位置、原始狀態與驗證結果。
DNS:先了解解析發生的位置
DNS 會將網域名稱轉換為後續連線所需的位址資訊。連線失敗可能發生在解析之前、解析過程中,或取得位址之後,因此修改 DNS 無法修復所有逾時問題。先判斷無法解析的是伺服器網域還是目標網域,再檢查目前設定中的相關項目。若伺服器位址本身無法解析,連線端點尚未確定;若目標解析異常,則需搭配目前路由與解析路徑分析。
系統 DNS、自訂 DNS 與 DNS over HTTPS 的使用方式不同,選擇時應考量目前網路能否連上解析服務。加密傳輸描述的是解析請求的一種傳輸方式,不代表它必然適用於所有網路環境。更換解析設定後,請使用相同目標與相同伺服器比較結果,避免同時切換網路而影響判斷。詳細原理請參閱DNS 設定對照說明。
[General]
dns-server = system
此範例展示在設定檔中使用系統 DNS 的位置,並非完整設定,也不是適用於所有環境的通用答案。編輯時請留意它位於 General 區段,不要放進 Rule 區段。若目前檔案已包含同名設定,先檢視原始值及相關項目,再決定如何修改,避免重複定義造成混淆。儲存後確認啟用的檔案,並依應用程式提示重新驗證。
快取會影響短時間內的比較:相同目標可能暫時沿用已取得的結果,應用程式也可能重用現有連線。測試時應搭配新的請求與連線紀錄判斷,不要修改後立即看到舊頁面,就認定設定沒有生效。若問題只影響單一目標,先檢查該目標的紀錄與規則,不要直接將所有解析策略改成另一套複雜設定。
On Demand:先確認手動連線可用,再設定自動觸發
On Demand 用於依據設定條件管理連線觸發。它不是修復伺服器狀態的功能,也不能取代首次手動授權。啟用前,先確認選取的伺服器可用、Config 運作正確,並閱讀應用程式目前提供的條件選項。只加入自己能說明用途的條件,再分別驗證符合與不符合條件時的狀態,避免自動連線不如預期卻找不到原因。
驗證自動觸發時,應記錄目前網路、連線狀態與觸發動作。例如網路變更後,觀察應用程式是否依設定進入預期狀態,再檢查實際連線。不要只因開關重新開啟,就判定遠端連線已成功。若手動中斷後又看到連線恢復,先檢查 On Demand 是否仍啟用,以及目前條件是否再次觸發,而非反覆刪除系統設定。
連線相關選項與修改原則
協定中的 TLS、傳輸方式與其他參數,應依已有服務的要求設定,不是可任意調整的通用最佳化選項。若要解決相容性問題,先確認服務端支援範圍;若要排查錯誤,先保留原始參數並記錄錯誤變化。不要只因某個選項名稱與網路有關就開啟它,這可能改變原本成立的連線條件,讓新舊問題混在一起。
設定檔與介面設定若出現相關項目,不要自行假設所有選項都採用相同優先順序。先查看目前檔案、應用程式說明與實際連線結果,確認設定從何處生效。遠端設定更新後,也要檢查先前依賴的設定是否仍存在。對用途不明的選項,保留已驗證的狀態通常比大量修改更容易維護;需要變更時,先用副本進行小範圍驗證。
每次修改只需記錄「原始值、目的、結果、復原方式」四項。目的應明確,例如確認特定網域能否完成解析,而不是籠統追求速度。結果必須能重現,不能只憑短暫的頁面載入感受判斷。若變更沒有改善,先還原原始值,再嘗試下一項。如此可避免長期累積一堆無人知悉原因的設定,也能為下一章的維護建立清楚基準。
備份、更新與日常維護
日常維護的目標是保留一套能理解、可復原的運作狀態,而不是不斷增加設定數量。至少要清楚目前的預設伺服器、訂閱來源、啟用的 Config、Global Routing 方式與自動連線條件。發生異常時,這些資訊有助判斷最近改變了什麼;準備更換裝置時,也可作為復原清單。只有一張應用程式截圖,通常不足以還原完整狀態。
分別備份伺服器、訂閱與設定
備份前先區分不同資料:伺服器參數決定連線端點與驗證方式;訂閱連結用於重新取得伺服器清單;設定檔保存分流與相關設定。單一類型的匯出內容不一定包含其他所有資料,應實際檢查備份內容。使用應用程式目前提供的匯出或備份功能時,請閱讀操作說明,並確認備份是否包含敏感資訊,以及是否依賴帳戶或其他復原條件。
將備份保存在自己能管理且有保護的地方,避免透過公開連結散布。訂閱網址、密碼、UUID 與金鑰都應視為敏感資訊。為備份加上便於辨識的說明,記錄對應的設定與使用情境,但不要在檔名中寫入完整憑證。服務資訊若已變更,舊備份可能不再適用;應保留必要的歷史說明,避免復原時誤用。
更換裝置前,最好先演練一次復原流程:確認能找到原始購買紀錄、能定位已有的訂閱或伺服器資料,也能看懂設定檔中的策略參照。演練不必刪除正在使用的資料,可在副本上核對。重點是確認復原所需資料確實存在,而不是只憑「以前匯出過」就認為準備完成。若裝置遺失後才尋找唯一儲存在裝置裡的連結,往往就失去復原依據。
更新後依固定順序複核
更新分為應用程式更新、訂閱更新與設定更新三種。應用程式更新由 App Store 管理;訂閱更新可能改變伺服器清單;設定更新則可能改變規則、策略與解析設定。盡量不要在同一次排查中同時更新三者,否則很難判斷是哪項變化影響結果。每完成一種更新,先驗證基本連線與常用目標,再進行下一項維護操作。
訂閱更新後,先檢查預設伺服器是否仍存在,再確認分組與項目變化。設定更新後,先核對啟用的檔案、最終規則與自訂策略,再檢查本機修改是否保留。應用程式更新後,則複核權限狀態、連線開關與自動觸發條件。複核不必遍歷每個網站,但應涵蓋日常確實使用的幾類目標,以及區域網路等需要直連的情境。
發現問題時,先還原最近一項有記錄的變更。若訂閱內容有變化,應向原服務提供者確認狀態,不要用舊項目強行覆蓋整份新清單;若設定規則變動導致異常,則使用已儲存的副本比對差異。復原是為了回到已知狀態並定位原因,不代表舊內容可以無限期使用。遠端伺服器若已失效,用戶端本機復原也無法讓它重新可用。
整理設定並建立故障紀錄
定期清理重複訂閱、用途不明的設定與失效項目,但刪除前先確認是否仍在使用。尤其要檢查同名檔案與同名伺服器,避免只憑名稱刪除目前有效的項目。可用清楚的備註區分測試與日常設定,記錄來源和用途,不要為每份副本加上難以辨識的序號。保留少量用途明確的復原副本,比長期堆積所有歷史檔案更容易管理。
故障紀錄只需保留有助判斷的資訊:發生條件、錯誤表現、預設伺服器類型、路由方式、最近變更與對照測試結果。請移除訂閱憑證與個人瀏覽細節。若某次調整解決問題,記下最後保留的設定,並清除不再需要的臨時嘗試;避免幾週後只記得「改過很多地方」,卻無法還原前因後果。
若必須重新安裝,先停止連線、檢查 On Demand 狀態,再確認資料已完整保存,並透過 App Store 重新取得。安裝後依本手冊順序復原:處理權限、匯入已有資訊、選取預設伺服器、啟用設定、驗證連線,最後恢復自動觸發。不要一次匯入所有歷史檔案後立即連線,以免重複項目與舊規則再次造成相同問題。
至此,日常維護已形成完整循環:保留基準、一次變更、分層驗證、記錄結果,必要時復原。需要快速重走連線流程時,請使用使用教學;遇到常見的購買或匯入疑問,請查閱常見問題;需要核對商店身分與已購項目復原時,請返回正版下載與復原說明。本頁用於說明各階段的範圍,實際參數始終以應用程式內選項與使用者已有的服務資訊為準。