V2Ray 進階設定指南

01 / 設定來源

訂閱分組與伺服器篩選該怎麼設定？

先依來源分組，再按用途篩選伺服器。分組用來管理「設定從哪裡取得、由誰更新」，篩選則決定「目前清單顯示哪些設定」，兩者用途不同，不應混為一談。v2rayN 的訂閱分組通常會儲存訂閱網址、更新選項與備註；伺服器清單中的搜尋或篩選功能，則用來縮小檢視範圍。伺服器暫時沒出現在清單中，不一定代表已遭刪除，也可能是目前分組或搜尋條件將它隱藏了。

建立分組前要記下哪些資訊？

先記下分組名稱、來源說明與更新方式，再填入網址。名稱最好能表達來源和用途，例如「日常連線」或「備用測試」，避免只用容易混淆的連續數字。訂閱網址通常含有存取憑證，請只貼到用戶端的網址欄位，不要放在備註、截圖或公開文件中。首次儲存後先手動更新一次，確認清單出現預期的協定與伺服器名稱，再考慮啟用自動更新。若清單為空，不要反覆刪除分組來處理。

在 v2rayN 中，可從訂閱分組相關選單編輯分組並執行更新；在 v2rayNG 與 v2flyNG 中，請先找到訂閱設定或對應的分組管理選項。不同介面對「更新目前分組」和「更新所有分組」的名稱可能不同，點選前請確認影響範圍。若匯入後只出現一台伺服器，先確認連結是單一分享連結還是訂閱網址。兩者看起來都可能是一長串文字，但更新方式並不相同。

為什麼篩選條件會把結果誤刪？

先確認篩選功能的作用。有些欄位只是搜尋清單，有些會在更新訂閱時排除項目；有些使用一般文字，有些支援正規表示式，另一些則提供獨立的包含與排除條件。不要直接貼上其他用戶端的條件。若欄位明確支援正規表示式，直線符號代表「或」、句點代表任意字元，名稱中的括號也可能被當成語法。先用一個明確關鍵字觀察結果，再逐步加入條件。

排除條件應謹慎設定，避免比包含條件更寬鬆。若所有項目都被排除，用戶端可能保留舊清單，也可能將該分組更新為空，實際情況取決於用戶端實作。調整篩選前，先備份現有設定，並記下目前使用伺服器的名稱與協定。篩選後先核對幾個已知項目，不要只因清單變短就認定設定正確。名稱可能變動；來源更新命名方式後，原本有效的關鍵字也可能失效，因此應定期檢查篩選條件。

訂閱更新成功但連線失敗，接著該檢查什麼？

更新成功只表示訂閱內容已取得並解析，不代表每台伺服器都能建立連線。先確認目前啟用的項目仍指向更新後有效的設定，再檢查協定、傳輸方式、TLS 與驗證欄位是否完整。手動修改訂閱項目，可能在下次更新時被覆寫；若要長期保留調整，請複製成獨立設定並註明來源。不要直接修改原始項目後忘記標示，否則之後很難判斷問題是來自遠端變更還是本機修改。

02 / 連線路徑

路由規則要如何排序與驗證？

將明確的例外規則放前面，範圍較廣的預設規則放後面。V2Ray 系列核心常見的路由行為是依序檢查規則，命中後選擇對應的出站；用戶端產生設定時也可能插入自有規則，因此應將介面中的順序與最終設定互相比對。規則能否命中，取決於連線提供的是網域還是 IP 位址、是否啟用嗅探，以及網域策略是否觸發解析。只新增網域規則，不代表所有連線都會提供可用的網域資訊。

網域、IP 位址與出站標籤各代表什麼？

domain 用來設定網域比對條件，ip 用來設定目標 IP 位址比對條件，outboundTag 則引用已存在的出站標籤。標籤是內部識別名稱，不是介面上可任意填寫的備註。範例中的 direct、proxy 和 block 都必須存在於出站設定中。同一條規則若同時填入網域與 IP 位址等不同類型的條件，通常表示所有條件都必須符合；若要表達「網域或 IP 位址任一命中」，應拆成獨立規則。

以下是常見 Xray/V2Ray 格式的路由片段，不能當成完整的用戶端設定匯入。此範例假設所需的 geosite 與 geoip 資料可用，而且對應的出站已定義。先封鎖廣告分類，再處理私有位址與中國網域，最後由用戶端的預設出站處理其他連線。網域分類內容取決於實際資料檔案，不是永遠固定的清單；若出現分類不存在的錯誤，應檢查資料支援情況，而不是繼續調換規則順序。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

網域策略該如何選擇？

AsIs 表示路由階段不會為了 IP 位址規則主動解析網域；IPIfNonMatch 通常會在網域未命中規則時嘗試解析，並用解析結果繼續比對；IPOnDemand 則會在比對過程需要 IP 位址資訊時觸發解析。策略會影響路由判斷，不等同於整體系統的 DNS 運作方式。若只想讓特定網域直連，先用明確的網域規則處理即可，不必為此讓所有請求都預先進行 IP 位址比對。

遇到「中國大陸網站也繞道」時，應先檢查命中的規則，而不是直接切換成全部直連。確認該網域是否包含在分類中、前面是否有範圍更廣的代理規則，以及應用是否直接連線至快取的 IP 位址。若最終設定將預設出站設為代理，未命中規則的連線便會走代理，這是預期行為。除錯時可暫時加入精確的網域規則，並在同一個應用中重新建立連線；既有長連線通常不會因設定變更而自動切換，重新整理頁面也可能沿用舊連線。

如何避免路由規則越加越亂？

依「本機資源、業務例外、分類規則、預設策略」分層記錄，並為每個例外註明用途。存取區域網路設備時，私有 IP 位址直連通常比依賴設備的網域分類可靠；企業內部網域也可能需要專用 DNS，單獨修改出站無法解決解析問題。不要將所有連接埠或所有網路等範圍過廣的規則放在前面，否則後續細分規則將無法生效。修改後分別測試一個明確的直連目標、一個明確的代理目標，以及一個區域網路目標。

驗證時請記錄目標網域、應用程式名稱、命中的規則與出站標籤，不要只記「能開啟」。有些網站的頁面與圖片會使用不同網域，主頁直連不代表所有資源都經過相同出口。若要了解協定欄位，可接著閱讀VMess 與 VLESS 的差異；路由選擇與協定選擇是兩個不同層次。

03 / 網域解析

DNS 設定最佳化，應先從哪一層著手？

先釐清 DNS 查詢路徑，再選擇解析器。應用程式可能使用系統 DNS、瀏覽器內建的加密 DNS，或透過代理協定將網域交給核心解析；核心也可能為路由判斷與直連出站分別進行解析。因此，「用戶端填了 DNS」不代表所有應用程式的查詢都會經過它。最佳化的第一步是確認由誰發起查詢、請求經過哪個出口，以及結果由誰使用，而不是將多個公共解析器依序加進清單。

本機網域與遠端網域為什麼要分開處理？

區域網路設備名稱與企業內部網域，往往只有本機或公司提供的解析器能正確解析；面向公網的網域則可能因解析器所在位置不同，而取得不同的 CDN 位址。將所有內部網域交給公共解析器，可能得到查無此網域的結果；若所有公網查詢都固定使用本機解析器，也可能取得與代理出口位置不符的位址。DNS 分流的目標是讓解析結果符合後續連線路徑，而不是簡單規定某種解析器永遠優於另一種。

以下片段示範優先為中國網域分類選擇一個解析器，其他查詢則使用另一個解析器的基本寫法。這只說明 dns.servers 的結構，不保證查詢會透過代理或直連傳送；請求路徑仍取決於核心實作、查詢協定與路由設定。不要直接用這段覆蓋用戶端的所有 DNS 設定，尤其在 TUN 環境中，還需保留用戶端為虛擬網卡與 DNS 接管產生的關聯設定。

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "1.1.1.1"
    ]
  }
}

為什麼使用加密 DNS 還是連不上？

使用 HTTPS 格式的解析網址時，必須先連上解析服務本身；若網址使用網域，也可能需要先解析該網域，形成引導解析問題。若代理伺服器位址也是網域，而查詢又被要求必須經由尚未建立的代理，就會形成循環依賴。請先確保伺服器網域與解析器網域各自有獨立可用的解析路徑，再設定其他網域的查詢出口。不要長期以臨時寫死的伺服器位址取代正常維護，遠端位址可能會變更。

請勿混淆網域策略與 DNS 伺服器的選擇。路由中的 domainStrategy 決定何時為了比對規則而解析；直連出站也可能有自己的網域解析策略。即使路由使用 AsIs，最後要直接連線至某個網域時仍可能需要解析。反過來說，路由已取得 IP 位址，也不代表瀏覽器或其他應用程式不會另外發出查詢。排查時應分別檢查「DNS 查詢路徑」與「業務連線路徑」，不要只憑單一 DNS 測試網站下結論。

如何處理快取與雙堆疊環境？

修改設定後，應重新啟動相關連線，並留意系統、應用程式與核心各自的快取。快取尚未過期時，測試可能仍使用舊結果。雙堆疊網路還需區分不同的 IP 位址記錄：只確認 IPv4 成功，不能證明 IPv6 也經過預期路徑；只停用某一層的 IPv6 查詢，也不一定能阻止應用程式使用快取位址。若網路確實支援雙堆疊，應一併檢查解析、路由與出口能力，不要把停用 IPv6 當成通用修復方式。

若 DNS 查詢正常但網頁仍無法連線，請回頭檢查路由與傳輸記錄。伺服器拒絕連線、TLS 參數不符或目標連線遭重設，都不是更換解析器就能解決的問題。常見連線狀況可繼續參考說明中心。

04 / 系統流量接管

如何區分 TUN 模式與系統代理？

TUN 透過虛擬網路介面接收系統流量；系統代理則提供代理位址給支援這項設定的應用程式。瀏覽器通常會使用系統代理，但部分終端機工具、背景服務與自帶網路堆疊的程式不一定會遵循。TUN 適用於需要接管更多流量的情境，但也會牽涉權限、路由、DNS 與虛擬網卡等設定。請先確認一般代理連線可正常使用，再啟用 TUN；否則基礎連線與系統接管同時失敗，排查範圍會更大。

啟用前要檢查哪些條件？

先儲存可正常使用的設定，記下原本的系統代理狀態，並確認目前用戶端支援該平台的 TUN 功能。v2rayN 在不同桌面平台上可能使用不同的輔助元件或執行方式，TUN 功能也不一定由目前伺服器所用的同一個核心直接實作；不要只憑伺服器協定判斷虛擬網卡是否受支援。啟用時依用戶端要求授予必要權限。若建立介面或修改路由失敗，應先處理權限與元件問題，而不是繼續調整訂閱伺服器。

Android 上的 v2rayNG 與 v2flyNG 通常透過系統 VPN 介面接管流量，授權提示是系統流程的一部分。其他使用相同系統介面的網路工具可能互相衝突，測試前請先停用衝突項目。桌面環境也要留意企業 VPN、虛擬機網路與安全性軟體，它們可能同時修改路由或 DNS。不要為了排查直接刪除所有網卡；先停用相關軟體並保留原始設定，再確認用戶端關閉後網路能否自動恢復。

為什麼啟用後無法連線到區域網路設備？

先確認區域網路位址是否遭到接管，以及是否有更明確的路由或略過設定。印表機、檔案分享與管理頁面可能分別使用私有 IP 位址、內部網域或區域網路探索協定，這是不同類型的流量。為私有 IP 位址設定直連，通常只能處理已進入核心的一般連線；部分廣播、多點傳送與探索功能仍會受到系統介面及接管機制影響。請先用設備的明確 IP 位址測試，再處理名稱解析與探索，不要一次加入大量網域例外。

伺服器連線本身必須避免再次進入接管，形成連線回圈。用戶端通常會透過綁定介面、排除路由或其他機制處理，但預設網卡變更、同時啟用另一條通道或手動修改路由時，這些假設可能失效。若啟動後記錄不斷重複連線至同一台伺服器，或停用 TUN 後立即恢復正常，應優先檢查出口介面與排除規則。不要將伺服器位址加入一般業務代理規則來「加強接管」，這反而會讓問題更複雜。

如何排查 UDP、MTU 與休眠後恢復問題？

若網頁正常，但語音、遊戲或其他 UDP 應用程式失敗，先確認所選協定、伺服器與傳輸路徑是否支援相應的轉送功能；TUN 能接收流量，不代表遠端一定支援轉送。若小型請求正常、大型內容卡住，再考慮路徑 MTU 與分片問題。不要一遇到逾時就任意降低 MTU；應先排除伺服器與目標服務故障，再於用戶端支援的範圍內小幅調整，並保留原值以便復原。

裝置從休眠恢復或切換 Wi-Fi 網路後，原有介面與預設路由可能已變更。此時先重新建立用戶端連線，確認虛擬介面是否重新綁定，再檢查系統 DNS 是否仍指向有效位址。若關閉用戶端後仍無法上網，應分別還原系統代理、DNS 與路由狀態，不要只關閉視窗。若瀏覽器與終端機的表現不同，可參考依應用程式排查系統代理，先判斷是應用程式支援問題還是系統接管問題。

05 / 網域映射

FakeDNS 在哪些條件下才有效？

FakeDNS 回傳的是供核心辨識的合成位址，不是目標網站的真實位址。應用程式取得合成位址並發起連線後，核心會將它還原為先前查詢的網域，再進行路由判斷或遠端連線。它的用途是保留「這條連線原本要存取哪個網域」的資訊，尤其適合系統解析後容易遺失網域資訊的流量接管情境。前提是 DNS 查詢與後續連線都進入同一套可建立關聯的處理流程；若只接管其中一部分，連線便可能失敗。

為什麼 DNS 查詢與連線都必須接管？

若 DNS 查詢由核心回覆，但業務連線繞過核心，系統就會嘗試直接連線到一個並非真實伺服器的位址。反過來說，若應用程式使用自己的加密 DNS 取得真實位址，即使連線進入 TUN，FakeDNS 也未必有對應映射。請先確認 DNS 請求進入哪個入口，再確認由誰接收使用回傳位址所建立的流量；不能只憑「已啟用 TUN」就認定映射流程完整。不同用戶端整合 FakeDNS 的方式不盡相同，部分流量接管方案使用另一種設定格式，請依實際元件判斷。

以下是採用相關設定格式的 Xray/V2Ray 核心片段，只展示合成位址池與 DNS 伺服器選擇。還必須搭配受支援的入站、嗅探還原與路由設定，不能單獨貼上就認定功能已啟用。位址池應避開實際使用的測試網段；若環境中已有相同網段的路由，請先處理衝突。使用圖形化用戶端時，優先採用內建的完整選項，避免只修改單一欄位而漏掉相關設定。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  }
}

FakeDNS 與嗅探是同一回事嗎？

不是。FakeDNS 會根據先前的查詢記錄還原網域；嗅探則嘗試從連線初期的資料辨識應用層目標資訊，例如部分 HTTP 或 TLS 資訊。嗅探不保證能辨識所有協定，也無法將任意 IP 位址自動還原成網域；FakeDNS 則必須有對應映射。部分核心會透過嗅探設定中的特定選項串接 FakeDNS，但兩者使用的資料來源仍然不同。啟用前請確認目前核心支援哪些欄位，不要混用不同設定格式的選項名稱。

還要區分「只用於路由判斷」與「改寫實際連線目標」。部分嗅探設定只會將辨識出的網域用於規則比對，實際連線仍使用原本的 IP 位址；另一些設定則可能讓後續出站依網域重新解析。這兩種行為都可能影響 CDN、憑證驗證與特殊應用程式的相容性。若某個應用程式在啟用嗅探後發生問題，先停用目標改寫，或使用用戶端支援的排除規則進行比對；不要直接刪除所有網域規則。

停止接管後，為什麼部分應用程式仍無法連線？

應用程式可能快取了合成位址。停用 FakeDNS 後，快取中的位址仍可能用於新連線，但此時已沒有核心負責還原。請先關閉相關應用程式的連線並清除其 DNS 快取，必要時重新啟動應用程式；也要一併考慮系統快取與核心映射。若只清除系統快取，瀏覽器本身仍保留舊結果，問題可能持續。切換設定時，盡量不要讓應用程式持續建立新連線，以免舊映射與新解析結果交錯。

相容性驗證應涵蓋瀏覽器、需要區域網路探索的應用程式，以及使用獨立 DNS 的程式。若一般 DNS 已能保留網域資訊並符合分流需求，就不必為了選項看起來更完整而啟用 FakeDNS。確有需要時，先單獨測試一個應用程式，確認查詢、映射還原與出站都符合預期，再擴大接管範圍。若發生異常，請先回到一般 DNS 設定，不要同時疊加更多嗅探與改寫設定。

06 / 更新與維護

如何管理多個訂閱，避免設定互相覆蓋？

將遠端維護的訂閱與本機維護的設定分開。多個訂閱可以提供不同來源或用途的伺服器，但不會自動形成故障切換，也不會因名稱相似就共用參數。建議每個來源各自建立分組，將本機修改另外儲存，並在備註中說明用途。如此一來，更新失敗時可以只處理單一來源，移除舊訂閱時也更容易掌握影響範圍。不要長期把所有網址與手動建立的伺服器混在同一分組，尤其不要靠顯示順序記住目前使用的項目。

同名伺服器與重複匯入該如何處理？

先比較來源與重要連線參數，再判斷是否重複。兩台伺服器名稱相同，可能使用不同連接埠、協定或傳輸方式；同一筆設定改了名稱，也不一定代表是新的伺服器。用戶端的去重邏輯可能依位址、協定欄位或內部識別碼處理，不能假設「去重」一定會保留手動修改。大量整理前先匯出備份，挑選幾個已知項目驗證，再進行大範圍清理。若只是清單難以搜尋，應優先改善分組與篩選，而不是刪除所有看起來相似的項目。

跨裝置移轉時，也要保留管理方式。只匯出單一分享連結，通常不會一併帶走訂閱更新設定、路由、DNS 與用戶端偏好；匯出完整設定則可能包含更多敏感資訊。移轉前請先確認要轉移的是伺服器參數，還是整個用戶端環境。桌面版與 Android 用戶端不保證採用相同的完整設定結構；最穩妥的方式是重新建立訂閱，再按章節移轉規則，而不是直接將桌面版內部設定匯入行動版。

何時適合啟用自動更新？

先手動更新並完成驗證，再設定更新週期。更新頻率應配合來源的實際變更情況，不必為了維持「最新」而頻繁請求。裝置休眠、網路切換或來源暫時無法連線，都可能造成排程更新失敗。有些用戶端只會在執行期間執行工作，因此設定週期不代表關機時也會更新。也要區分一般更新與透過代理更新：前者可能直接連線取得，後者則依賴目前的連線；若訂閱只能透過代理取得，請保留一組已驗證可用的設定。

更新與切換目前使用的伺服器是兩件事。若來源移除了目前使用的項目，用戶端可能會在重新啟動前繼續使用已載入的設定，也可能在重新載入時提示無效。更新完成後，請確認目前啟用的項目仍存在，再主動重新建立連線並驗證。除非已設定用戶端支援的選擇機制，否則不要假設用戶端會自動選擇伺服器。介面排序、測速結果排序與目前啟用狀態彼此獨立，排在第一列不代表正在使用。

訂閱取得失敗時，該依什麼順序排查？

先檢查網址是否完整，再確認取得路徑，最後檢查格式。複製時漏掉查詢參數、網址末尾多出空格，或來源回傳登入頁面，都可能被判定為解析失敗。先確認錯誤類型是連線逾時、驗證遭拒還是內容解析失敗，再決定後續處理方式。連線失敗應檢查網路與代理更新路徑；驗證遭拒應確認來源授權；內容解析失敗則應檢查格式相容性。不要將完整訂閱網址貼到公開求助文章中，錯誤訊息也可能回顯其中的憑證。

備份檔也應視為敏感資料妥善保存。分享截圖前，請遮住網址、驗證欄位與個人備註；完成移轉後，再清除暫存的匯出檔案。若準備更換用戶端，可前往用戶端下載頁選擇對應平台，先確認新環境可正常運作，再移除舊環境。管理多個訂閱的目標，是讓來源、更新與本機修改都能追溯，而不是讓清單越長越好；清楚說明每個分組的用途，比保留大量重複設定更重要。

07 / 設定組合

自訂出站要如何搭配路由？

先定義出站，再讓路由引用其標籤。出站描述連線如何離開核心；路由則決定哪些連線交由哪個出站處理。用戶端中的「自訂設定」可能代表接管整份設定，而不是在現有設定中追加片段；「自訂出站」也可能只允許編輯特定欄位。操作前先確認可編輯的範圍，否則貼上的出站物件可能被當成完整設定解析，或覆蓋用戶端自動產生的本機監聽與 DNS 設定。

出站標籤與預設出站有哪些限制？

出站標籤應保持唯一、穩定且易於辨識。路由引用標籤時，大小寫與拼字必須一致，不能把伺服器備註誤當成標籤。常見 V2Ray/Xray 設定在沒有規則命中時會使用第一個出站，但圖形化用戶端可能會重新排序或產生預設項目，因此必須以最終執行的設定為準。不要為了讓特定業務直連，就任意調整所有出站的順序；應優先新增對應路由，讓修改範圍明確，也更容易復原。

以下是基本出站片段，示範直連、封鎖與連線至本機 SOCKS 服務三種結構。這不是完整設定；只有在本機指定連接埠確實有可用的 SOCKS 服務時，第三個項目才有作用。該服務不能指向目前核心自己的入站連接埠，否則會形成連線回圈。範例使用回環位址，避免將本機輔助服務意外公開到區域網路；若要跨裝置存取，應另外設定監聽範圍、驗證方式與存取控制。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    },
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081
          }
        ]
      }
    }
  ]
}

為什麼鏈式連線不等於多個訂閱？

多個訂閱代表多個設定來源；鏈式連線則要求某個出站的底層連線經過另一個出站或輔助服務。具體欄位取決於執行中的核心與協定實作，不同核心的組合方式不能互換。即使用戶端允許選擇前置代理，也要確認它作用於訂閱取得、伺服器連線還是業務流量，這三者的範圍不同。先畫出每一跳的目標位址與連線責任，再修改設定，比只看「前置」這個名稱可靠。

每增加一個節點，就會增加一項依賴；發生故障時，應從最外層的連線能力開始檢查。先單獨驗證本機輔助服務，再確認它能否連上目標伺服器，最後檢查業務規則是否確實選取該出站。不要同時啟用多個互相指向的代理，尤其不要讓系統代理、TUN 與本機 SOCKS 服務彼此轉送。若記錄快速重複，或連線不斷建立後又中斷，應先排除連線回圈，再檢查驗證與傳輸參數。

協定參數與傳輸參數可以分開複製嗎？

應將兩者視為一組核對。位址、連接埠、驗證、傳輸類型、TLS 名稱與其他安全參數共同決定連線能否建立。只更換出站協定卻保留舊的傳輸參數，可能得到格式正確但無法運作的設定。REALITY 與相關流控欄位也必須與伺服器端一致，不要因為某項看起來較新，就自行啟用。欄位關係可參考REALITY 與 XTLS Vision 原理說明，再確認目前核心的支援範圍。

若用戶端儲存後又自動還原原值，原因可能是訂閱更新、範本產生或介面重新寫入設定。不要反覆修改執行中的暫存檔案，應找到實際設定來源，或使用用戶端支援的持久化自訂入口。完整自訂設定也可能略過部分圖形介面選項；介面顯示已啟用，不代表對應欄位確實寫入設定。最後應綜合執行記錄、產生的設定與實際連線結果進行判斷。

08 / 驗證流程

修改設定後，如何驗證並復原？

將「能夠連線」拆成幾個可觀察的階段，才能判斷修改是否正確。訂閱能否更新、核心能否啟動、伺服器連線是否成功、DNS 是否回傳結果、路由是否選中出站，以及應用程式是否完成存取，都是不同的檢查點。進階設定應保留一份已確認可用的基準設定，每次只修改一類項目。若同時更動協定、DNS、TUN 與規則，即使最後恢復連線，也很難知道是哪個變數造成影響。

先建立一組固定的測試目標

選擇自己有權存取且行為明確的目標，分別涵蓋直連、代理與區域網路情境，並使用同一個應用程式重複測試。不要只依賴單一綜合檢測網頁，因為它可能由多個網域、快取內容與第三方資源組成。記錄目標、時間、目前伺服器、模式與觀察到的狀況即可，不必公開驗證資訊。若測試網域本身變更了 CDN 位址，單次結果也無法代表規則長期有效，應搭配記錄確認實際命中的規則。

測試前先結束既有連線。瀏覽器可能重複使用連線，背景應用程式也可能維持長時間工作階段；儲存路由後，這些連線不一定會重新建立。必要時請關閉相關應用程式再重新開啟，而不是只重新整理一次。對照測試應維持其他條件相同，例如使用同一個網路、解析方式與目標。切換網路本身就會改變預設路由與 DNS，因此不能把切換網路後的所有變化都歸因於剛修改的用戶端設定。

記錄應從哪裡開始看？

先確認啟動階段是否成功載入設定，再查看目標連線附近的錯誤。欄位不受支援、標籤不存在、資料檔案缺漏與連接埠占用，屬於啟動或載入問題；連線遭拒、驗證失敗與解析逾時則發生在後續階段。若完全沒有與目標相關的記錄，應懷疑應用程式流量根本沒有進入用戶端，而不是先更換伺服器。提高記錄詳細程度只適合短期定位；完成後請恢復適當的記錄層級，避免長期累積包含存取目標的資料。

伺服器連線逾時時，應從本機條件逐步往遠端排查。先確認系統時間、網路連線與訂閱參數，再檢查核心記錄中的傳輸及安全性設定；只憑清單中的一次測速結果，不足以證明應用層可正常使用。有些測試只會連到伺服器，不會完整存取業務目標。可參考伺服器節點逾時排查順序，分別記錄本機、連線路徑與伺服器端問題，避免反覆修改已正確的規則。

如何安排可執行的復原順序？

先撤銷最近一次設定修改，再重新載入用戶端並重建連線；若問題仍在，關閉 TUN 或其他流量接管功能，並還原原本的系統代理與 DNS 狀態。涉及 FakeDNS 時，也要處理應用程式與系統快取，避免殘留合成位址。復原不是關閉所有開關，而是回到一組已驗證的狀態。記錄基準設定時，應一併註明目前模式與預設出站，否則即使只還原規則檔案，仍可能因模式不同而產生不同結果。

備份應區分用戶端資料與可攜式設定片段。完整資料方便在相同環境中復原；路由與 DNS 片段則方便理解差異，但兩者都可能含有敏感內容。升級用戶端或跨平台移轉前，先保留舊設定，再確認新環境支援哪些欄位與資料分類。不要將其他核心能載入的片段視為通用標準；遇到不支援的欄位時，應確認對應功能是否有等效設定，而不是只刪除錯誤欄位讓核心勉強啟動。

最後應能回答三個問題：這次修改了哪個層次、有哪些證據能證明設定生效，以及發生問題時如何復原。能回答這三點，設定才具備可維護性。下次遇到類似問題時，優先沿用同一組測試與記錄方式，不要繼續疊加臨時規則。