V2Ray 進階設定手冊

訂閱群組與伺服器篩選

訂閱群組主要用來管理設定來源，不會直接決定流量的去向。群組通常會保存訂閱網址、顯示名稱、更新選項與篩選條件；伺服器清單則是更新訂閱後產生的結果。將某台伺服器移至另一個顯示群組，不代表已為特定應用程式建立代理規則。設定前，請先分清來源管理、目前選用的伺服器與路由分流這三個層次，避免在錯誤的位置尋找設定項目。

依來源建立可追蹤的群組

在 v2rayN 的訂閱群組設定中，為每個來源分別建立記錄，名稱可採用「用途－來源」格式，例如「日常－主要訂閱」和「測試－備用訂閱」。請完整貼上訂閱網址，並確認開頭與結尾沒有空格或換行；儲存後，只更新所屬群組，不要立刻一次更新所有來源。第一次更新時，先確認該群組能否產生伺服器，再逐步加入其他訂閱。

伺服器名稱只是遠端提供的備註，不能證明伺服器具備特定能力。備註中的地區、線路或倍率說明，不能取代對協定欄位的檢查，也無法保證實際出口位置。挑選伺服器時，還應確認協定、傳輸方式、加密與安全設定是否符合核心的支援範圍。若要選擇核心，可先閱讀Xray 與 V2Fly 核心差異，再決定保留哪些設定。

區分暫時搜尋與持續篩選

清單搜尋通常只會改變目前的顯示結果，清除搜尋詞後伺服器仍會保留；訂閱篩選則可能影響下次更新時實際匯入的項目。最簡單的辨別方式，是清除搜尋後能否再次看到原本的伺服器。啟用持續篩選前，請先記下未篩選時的清單狀況，並至少保留一台已確認可用的伺服器。否則，篩選條件寫錯時，可能會把空清單誤認為訂閱失效。

有些用戶端的篩選框接受一般關鍵字，另一些則支援正規表示式，不能只看輸入框名稱就判斷。若介面明確標示使用正規表示式，測試|備用表示符合任一關鍵字；但「符合時保留」或「符合時排除」，仍取決於該選項的定義。先用一個確定存在的伺服器名稱測試，再逐步擴大範圍。請勿一開始就使用複雜的前後查找，以免不同實作對正規表示式的支援不一致。

更新後檢查重複名稱、項目消失與選取狀態

更新訂閱時可能會重新建立項目，也可能依用戶端的策略合併既有記錄，因此不能假設目前選用的伺服器一定會維持不變。更新後請先確認目前使用的伺服器標記，再檢查協定參數與可用性。需要長期保留的手動項目，應放在獨立的本機群組，或在更新前匯出備份；不要靠修改遠端伺服器備註來保存個人設定，因為下次更新可能會覆蓋變更。

若更新成功卻看不到伺服器，請依序清除清單搜尋、確認目前群組、暫時停用訂閱篩選，再確認用戶端能否辨識回應內容。若更新失敗，請勿立刻刪除原有群組，原清單可能仍可使用。Android 端也應先區分訂閱群組與目前檢視畫面；v2rayNG 和 v2flyNG 的介面入口不同，但都應依照「更新單一群組、檢查結果、再選擇伺服器」的順序操作。釐清來源歸屬後，後續排錯才知道是哪次更新變更了設定。

路由規則實作

路由是在連線進入核心後，為其選擇出站的機制。判斷條件可以是目標網域、目標位址、連接埠、網路類型或入站標籤。用戶端中的「規則模式」通常是選擇一組預設路由，不代表核心會自動理解所有應用程式的用途。建立自訂規則前，請先確認目前啟用哪組設定，並備份既有規則；在編輯器中儲存規則，不一定表示執行中的核心已載入變更。

了解比對順序與規則內部關係

一般路由規則會由上而下檢查，第一條符合的規則會決定出站，因此具體規則應排在寬泛規則之前。例如，先設定需要代理的完整網域，再設定區域網路位址直連，最後才處理預設行為。同一條規則中的不同條件通常必須同時符合；同一條件欄位中的多個值則通常符合其中一個即可。把網域、連接埠與網路類型都填在同一列，會縮小符合範圍，而不是增加三種獨立的命中機會。

網域比對也有不同精確度。完整網域比對適用於單一主機；網域及其子網域比對適用於整個服務範圍；關鍵字比對則可能意外涵蓋名稱相似的其他網站。請先以最小範圍測試，再逐步擴大。不要為了解決單一下載網域的問題，就直接把所有流量改走代理；雖然可能暫時恢復存取，卻會掩蓋規則過寬、遺漏相依網域或 DNS 路徑錯誤等問題。

從一條明確規則開始驗證

以下是 Xray 常見 JSON 路由欄位的局部範例，展示完整網域、私有位址與出站標籤之間的對應關係。這不是完整的用戶端設定，必須合併至既有執行設定中，並確認已定義 proxy 與 direct 出站。範例網域僅用來說明比對語法；實際測試時，請在自己的設定中換成需要處理的目標。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

AsIs不會為了比對 IP 規則而主動解析網域，但若連線原本就帶有目標 IP，仍可符合 IP 規則。網域連線若未符合網域規則，也不會因為設定了私有位址規則，就必定先解析並辨識其區域網路屬性。若要處理內網網域，應新增明確的網域規則，或了解解析方式可能造成的影響後，再選用其他網域策略。使用 geoip:private也需要能讀取對應的資料檔；若資源不存在，請先修復載入錯誤。

預設規則、嗅探與既有連線

若沒有規則命中，核心通常會使用出站清單中的第一個出站；用戶端也可能額外產生最後一條規則。請查看實際產生的設定，不要只看介面中的最後一列。若想統一指定預設出站，可使用用戶端提供的最終出站設定；手動設定則應明確指定適用的入站或網路類型，避免留下語意不明的空條件。預設出站順序一旦改變，原本未命中的連線也可能改走其他路徑。

嗅探可從部分連線中還原 HTTP 主機名稱或 TLS 伺服器名稱，但無法保證識別所有加密協定，也不一定能讀取啟用加密握手資訊的網域。嗅探只能補充資訊，不能取代 DNS。修改規則後，請建立新的連線再測試；已建立的長連線通常不會自動切換出口。必要時請先關閉測試中的應用程式再重新開啟，不要只反覆重新整理同一個頁面。

若規則沒有生效，請先確認流量是否進入用戶端，再檢查規則是否啟用、目標是否符合、前方是否有更寬泛的規則，以及目標出站標籤是否拼寫一致。在系統代理模式下，不遵循系統代理的應用程式根本不會進入這條路由鏈。若仍無法排除問題，可參考說明中心中的代理模式說明，先確認流量入口，再調整路由內容。

DNS 設定最佳化

DNS 設定要釐清兩個不同問題：由誰解析網域，以及解析請求透過哪條網路路徑送出。瀏覽器、作業系統、用戶端核心與遠端伺服器都可能參與解析。網站能順利開啟，不代表所有應用程式都使用相同的解析路徑；變更系統 DNS 後，某個應用程式仍沒有變化，也不一定表示設定失敗，因為它可能使用自己的加密解析服務，或保留獨立快取。

先釐清解析路徑

在系統代理模式下，應用程式可能先將網域交給本機代理，再由出站或遠端伺服器處理；也可能先在本機解析出 IP，再將 IP 交給代理。在 TUN 模式下，用戶端是否接管 DNS，取決於虛擬介面、DNS 劫持與應用程式的請求方式。開始最佳化前，請記錄目前的系統解析器、用戶端 DNS 選項，以及瀏覽器的安全 DNS 設定。一次只調整一處，才能確認是哪個環節改變了結果。

用來連線代理伺服器的網域尤其重要：用戶端必須先找到伺服器，才能透過它傳送後續流量。若強制將伺服器網域的解析送進尚未建立的代理，可能形成啟動依賴迴圈。較穩妥的做法是為伺服器位址保留可連通的引導解析路徑，並明確設定其直連條件。即使代理中斷，仍應能完成必要的伺服器解析，否則重新連線時可能持續失敗。

區分網域策略與位址族策略

路由中的 domainStrategy會影響是否為符合 IP 規則而解析網域；DNS 的 queryStrategy會影響查詢使用的位址族；直連出站中的網域策略則會影響實際撥號前如何處理網域。這些欄位位於不同位置，不能因為名稱相似就互相取代。以下是內建 DNS 的最小局部範例，以系統解析器作為基準，方便先判斷問題是否來自複雜的分流解析設定。

{
  "dns": {
    "servers": ["localhost"],
    "queryStrategy": "UseIP"
  }
}

這段設定不會自動接管系統中的所有 DNS 請求，也不保證每個出站都會呼叫內建解析器。實際呼叫方式仍由路由策略、出站設定與用戶端整合方式決定。若原設定含有依網域篩選的解析器項目，直接替換整個 DNS 物件會移除這些規則；請先匯出原設定再測試。還原基準設定後，若問題消失，再逐項加入原有的伺服器與篩選條件。

處理 IPv6、快取與內網網域

雙堆疊網路應先確認 IPv6 是否真正可連線，包括本機網路、代理伺服器與目標服務三個環節。收到 IPv6 位址不代表連線一定可用。若記錄中持續出現位址族相關的連線錯誤，可暫時限制使用 IPv4 作為對照，但不應把永久停用 IPv6 當成所有 DNS 問題的通用解法。對照測試後，再決定是否保留限制，並確認是否影響原本可用的內網服務。

公司內網、路由器管理名稱與裝置探索名稱，通常仰賴本機的解析環境。將所有網域一律送往公共解析器，可能導致這些名稱無法使用。請為內網網域保留系統解析器或指定的區域網路解析器，並確保相關目標走直連。變更 DNS 後，也要考慮系統與應用程式快取的有效時間不同；重新啟動測試中的應用程式，通常比不斷切換解析器更有幫助，已建立的連線則未必會再次查詢網域。

排錯時，請分別記錄「查詢逾時」、「回傳的位址不合適」與「位址正確但連線失敗」。查詢逾時要檢查解析器是否可連線及請求路由；位址不合適要檢查篩選規則與快取；連線失敗則繼續檢查出站、目標連接埠與網路環境。加密 DNS 主要改變查詢的傳輸方式，不會自動修正錯誤的路由選擇，也無法讓無法連線的伺服器位址恢復正常。

TUN 模式與系統網路接管

TUN 透過虛擬網路介面將 IP 層流量交由使用者空間處理，適用於不遵循系統代理、但仍需要統一分流的應用程式。它不是「更強的全域代理」開關：流量進入 TUN 後，仍須透過路由規則決定直連或代理，也仍受出站協定、UDP 支援與 DNS 處理方式限制。系統代理與 TUN 的流量入口不同，請先分別測試，再考慮是否要同時啟用。

確認接管元件、權限與運作基準

v2rayN 的 TUN 功能可能由配套元件負責，不應把圖形介面中的 TUN 開關直接理解為替 Xray 加上某個同名欄位。開始前，請先確認一般代理模式運作正常、目前伺服器可用，再查看用戶端要求的執行權限、元件狀態與記錄。Android 端的 VPN 授權代表允許接管流量，不表示它使用與桌面端完全相同的虛擬介面實作或設定格式。

第一次啟用時，請保留能夠還原設定的本機操作方式。先關閉其他正在接管網路的工具，儲存目前 Wi-Fi 或有線網路的 DNS 與代理設定，再啟用 TUN。確認虛擬介面是否建立、預設路由是否變更，以及測試流量是否出現在記錄中。若介面顯示已啟用卻沒有對應的連線記錄，請先檢查介面與路由，不要立刻更換伺服器。

避免迴圈，保留區域網路存取

代理用戶端連往伺服器的連線，不能再次被自身當成待代理流量，否則會形成迴圈或不斷重試。成熟的接管元件通常提供自動路由或介面綁定機制，但手動修改路由仍可能破壞這些保護。若啟用 TUN 後代理立即中斷，請先確認伺服器位址是否被錯誤接管，再檢查是否有多個虛擬介面同時爭用預設路由。

區域網路裝置、印表機服務與路由器管理頁面通常需要直連，但只新增私有位址規則不一定能處理裝置探索。廣播、多播與依名稱探索屬於另一類問題，能否通過虛擬網路取決於實作方式與系統環境。若能透過 IP 存取裝置，卻無法解析名稱，應檢查 DNS 或探索協定，而不是不斷擴大代理範圍。企業網路的私有位址也可能與本機網段重疊，因此需要更精確地設定路由範圍。

逐步驗證 TCP、UDP 與應用程式範圍

先用一個明確的 TCP 請求驗證流量入口與出站，再測試確實需要 UDP 的應用程式。網頁可正常瀏覽，但語音或即時通訊失敗，可能是 UDP 轉送、伺服器能力或網路策略所致，不代表整個 TUN 都失效。若應用程式出現 QUIC 相關問題，也應單獨記錄 UDP 路徑；暫時停用應用程式中的相關功能只能用來比對，不能取代底層轉送能力的檢查。

同時啟用系統代理與 TUN，可能是用戶端預期的設計，也可能造成應用程式先連到本機代理，再由 TUN 攔截本機代理的連線。排錯時建議只保留一個已知入口，確認運作正常後再恢復組合設定。Android 端若將應用程式設為排除，該應用可能完全繞過用戶端路由，因此不能用其存取結果驗證核心規則。背景省電限制也可能中斷接管工作階段，請區分程序結束與伺服器斷線。

關閉 TUN 後若網路沒有恢復，請先檢查虛擬介面、預設路由與系統 DNS 是否已還原，再確認系統代理是否仍指向已停止的本機監聽連接埠。不要直接刪除所有網路介面卡或重設整個網路，避免擴大影響範圍。只撤銷這次新增的接管設定並重新連線，通常更容易保留原有的企業網路與本機裝置設定。

FakeDNS 的運作方式與使用範圍

FakeDNS 會為網域回傳一個用於本機映射的合成位址，之後連線進入代理處理鏈時，再依映射還原原始網域。它解決的是「應用程式已將網域解析成 IP，但路由仍需要依網域判斷」時如何保留網域資訊，而不是替目標網站分配真實位址。請注意，合成位址只能用於相應的接管與映射流程，一般網路裝置並不知道它代表哪個網域。

查詢、映射與連線還原必須形成完整流程

完整流程至少包含三個步驟：應用程式查詢網域並取得合成位址、應用程式連線至該位址、接管元件將位址反查為網域並交由後續路由處理。若只啟用第一步，應用程式可能取得無法直接連線的位址；只開啟網域嗅探，也不表示一定能還原 FakeDNS 映射。請使用用戶端提供的整合選項，並確認 DNS 與流量接管由相容的元件共同處理。

在 v2rayN 中，請先確認目前的 TUN 元件是否具備相應功能，不要把網路上找到的核心設定片段直接貼進所有設定欄位。v2rayNG、v2flyNG 與桌面端的整合方式也可能不同，支援情況取決於核心與用戶端的實作。若選單中沒有這項功能，請勿假設新增一個欄位就能補齊介面、DNS 劫持與位址還原的整個流程。

了解位址池與映射容量

以下展示 Xray 常見的 FakeDNS 物件格式，並使用專用的測試位址範圍作為合成位址池。這只是局部語法範例，不是可獨立運作的接管設定；還需要讓內建 DNS 呼叫 FakeDNS，並使用相容的入站還原映射。若目前使用其他接管元件，必須採用該元件自己的設定語法，不要混用欄位。

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

ipPool決定可用於映射的合成位址範圍；poolSize決定映射池容量，不代表同時連線數，也不是設定越大速度越快。設定前請確認合成網段未被目前的測試網路或特殊路由使用。不要隨意使用常見的家用區域網路網段作為位址池，否則真實裝置位址可能與合成位址衝突，導致部分裝置突然無法連線。

也要考慮映射的生命週期。核心重新啟動後，舊映射可能消失，但系統或應用程式仍快取先前的合成位址。此時新連線進入用戶端後，若無法找回對應網域，就可能出現「剛啟用時正常，重新啟動後部分應用程式失敗」的情況。請讓應用程式重新查詢 DNS，必要時關閉應用程式並清除相關快取，不要靠擴大位址池掩蓋生命週期不一致的問題。

判斷哪些應用程式需要真實位址

有些應用程式會檢查 DNS 回傳的位址、比對位址與憑證資訊，或將解析結果交給另一個不經代理的程序。這些情況未必適合使用合成位址。區域網路管理、裝置探索、部分即時通訊，以及依賴真實位址判斷的程式，通常都需要個別測試。若用戶端支援指定網域使用真實解析，可為這些目標設定例外，但仍須檢查相應的路由與 DNS 請求路徑。

瀏覽器自己的加密 DNS 可能繞過預期的 FakeDNS 查詢入口，讓同一台裝置上的部分應用程式取得真實位址，另一些則取得合成位址。若出現這種混合狀態，請先記錄各應用程式的解析方式，不要只因網頁能開啟就認定整個流程正常。測試範圍至少應包含一般網頁、需要依網域分流的目標、區域網路位址，以及一個不應走代理的應用程式。

關閉功能時一併撤除相依設定

停用 FakeDNS 不只是關閉映射池，也應一併恢復正常的解析路徑、確認用戶端不再回傳合成位址，並清除既有快取。若先關閉接管功能，卻保留合成 DNS 回應，應用程式仍會嘗試將流量送往一般網路中的合成位址，故障也會持續。復原順序應依用戶端的整合方式而定，但最後必須讓 DNS 回傳結果與流量接管方式重新一致。

建議等一般 DNS、路由與 TUN 都穩定後，再導入 FakeDNS。若目的是修正單一網域的分流，請先確認能否透過明確的網域規則解決；只有在網域資訊確實遺失、且接管流程支援還原時，才值得加入這層映射。新增功能的效益應能從記錄中確認，不要只憑啟用後某次存取速度的主觀感受判斷。

多訂閱管理與更新策略

多訂閱管理的重點，是讓來源、用途與變更都能追蹤，而不是把所有伺服器混成一份更長的清單。建議先釐清主要、備用與測試訂閱的用途：主要訂閱供日常使用，備用訂閱用於手動切換，測試訂閱則用來檢查新協定或新設定。伺服器分屬不同群組，不代表已具備自動故障切換功能，也不表示流量會依群組名稱自動分配。

為每個來源保留獨立範圍

新增來源時請使用獨立群組，先單獨更新，再檢查協定類型、項目名稱與篩選結果。即使兩個來源提供相同備註，也應保留來源資訊，因為名稱相同不代表伺服器相同。比對位址、連接埠與傳輸參數時，請只在本機操作；分享排錯資料時，記得遮蔽憑證。不要為了整理清單就直接合併來源，否則之後很難確認某個項目是由哪次更新加入。

判斷重複項目時，還要考慮實際用途。伺服器位址與連接埠相同，仍可能因使用者憑證、傳輸路徑或安全參數不同而代表不同設定；備註不同的項目也可能指向同一項服務。用戶端的去重功能通常只依據有限欄位，不能取代人工確認。批次去重前請先匯出本機備份，並確保至少保留一個可連線的項目，以免誤刪後只能等遠端重新提供。

安排可觀察的更新流程

更新訂閱會改變伺服器清單，請盡量避開長時間下載、遠端管理或重要連線期間。先更新備用或測試群組，確認沒有異常後，再更新主要群組。若能設定自動更新週期，請依實際變更頻率調整，不是越頻繁越好；過於密集的請求可能觸發來源的流量限制，也會使本機清單不斷變動，增加排錯難度。

訂閱更新是否透過代理，必須另行確認。有些來源可透過目前網路直接連線，有些則需要使用既有代理路徑。如果更新依賴目前的伺服器，而該伺服器已失效，就會陷入「需要更新才能恢復，但更新又依賴失效連線」的循環。若用戶端提供不同更新方式，可在確認來源安全後切換請求路徑；不要將訂閱網址貼到不明的線上轉換服務嘗試修復。

將個人設定與遠端內容分開管理

訂閱提供的伺服器資訊與個人路由應分開管理。自行新增的區域網路直連規則、應用程式範圍與 DNS 例外，最好儲存為用戶端支援的獨立設定，不要直接修改訂閱產生的暫存設定。產生的檔案可能在切換伺服器、更新訂閱或重新啟動時重建；若變更只存在暫存檔中，下次重建就會消失，容易讓人誤以為用戶端沒有儲存設定。

遠端訂閱也可能包含複雜的設定內容，請先確認用戶端匯入的是伺服器清單還是完整設定。兩者的權限範圍不同：伺服器清單通常只補充連線參數，完整設定則可能變更路由、DNS 與監聽行為。匯入前請看清格式說明，匯入後檢查實際執行設定，尤其是區域網路監聽與預設出站；不要只根據副檔名判斷內容。

更新失敗後的保留與復原

單次更新失敗不應立刻刪除舊清單。請先確認是連線逾時、回應狀態異常、回傳空內容，還是格式解析失敗；不同情況需要不同處理方式。若舊伺服器仍可連線，請暫時保留，並停止反覆重新整理。若訂閱網址已變更，請從可信來源取得新網址，再於原群組中替換，避免建立多筆名稱相同但狀態不同的記錄。

備用訂閱的價值，在於能獨立測試。平時應偶爾確認它仍可更新、是否有可用伺服器，以及核心是否支援，而不是等主要訂閱故障後才第一次嘗試。相關用戶端的功能範圍請見三款用戶端的平台與功能比較。確認來源已分開管理後，再考慮自動選擇或負載策略，才不會把訂閱管理問題誤認為出站調度問題。

自訂出站與設定組合

出站定義連線如何離開核心；路由則透過引用出站標籤，決定使用哪種方式。常見出站包含代理協定、直連與阻斷。新增出站物件不會自動讓流量使用它；必須有路由規則命中該出站，或將它設為預設出站。反過來說，路由引用不存在的標籤，也不會自動產生對應的連線方式，因此設定自訂內容時，首先要確認標籤一致。

先確認由誰產生設定

v2rayN 的一般伺服器模式通常會依目前選擇與介面設定產生執行設定。直接編輯產生的結果，可能在下次切換伺服器時消失。需要自訂出站時，請優先使用用戶端明確提供的進階設定入口；若選擇匯入完整自訂設定，則要確認哪些介面選項仍會生效、哪些欄位已由自訂檔案接管。混用兩種管理方式，最容易發生「介面已修改，執行結果卻沒有變化」的情況。

Android 用戶端也要區分一般設定編輯與完整設定匯入。v2rayNG 主要使用 Xray，v2flyNG 使用 V2Fly；兩者都能處理某種伺服器清單，不代表所有出站欄位都完全相容。遇到特定協定或安全層參數時，請先確認目標核心的支援範圍。社群生態關係可參閱Project V 開源生態整理，不要只憑用戶端名稱猜測內部能力。

透過直連與阻斷驗證標籤路徑

以下是可供 Xray 使用的最小本機 SOCKS 設定，用來驗證入站、路由與出站標籤之間的關係。設定只包含直連與範例網域阻斷，不含代理伺服器。監聽位址限定為本機迴圈位址，並停用 UDP，適合作為獨立測試設定；請勿覆蓋正在使用的主要設定，測試前也要確認本機連接埠未被占用。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "block"
      }
    ]
  }
}

測試應用程式應將網域交給 SOCKS 代理，而不是先在本機解析成 IP，否則範例中的完整網域規則可能無法命中。這份設定沒有啟用嗅探來補回網域資訊，目的是讓測試條件保持明確。未命中的連線會使用第一個出站，也就是 direct；若變更出站順序，預設行為也會跟著改變，因此維護設定時不能只看標籤而忽略排列順序。

新增代理出站與了解鏈式連線

實際新增代理出站時，應以已確認可用的伺服器設定為基礎，保留協定、伺服器位址、連接埠、使用者參數與傳輸安全設定，再指派唯一標籤。不要只複製位址與連接埠，因為交握失敗往往是傳輸路徑、伺服器名稱或安全參數不相符所致。每個標籤應負責明確用途，例如主要代理或備用代理，方便從記錄辨識實際出口。

鏈式連線是指一個出站透過另一個出站建立底層連線，不代表依序執行兩條路由規則。第一條路由命中後，通常不會再將同一條連線交給下一條規則。不同核心對出站轉接欄位與傳輸方式的支援可能不同，請依目標核心的語法設定；避免讓甲依賴乙、乙又依賴甲，也不要讓鏈路中的網域解析依賴尚未建立的鏈路本身。

負載平衡屬於候選出站選擇，還涉及可用性監測、選擇策略與工作階段持續性。將多個出站放入陣列，不代表會自動輪替或偵測故障。若只是偶爾切換備用伺服器，手動選擇更容易驗證；只有在確實需要自動調度，且能說明各候選出站的健康狀態時，才適合加入更複雜的組合。

設定驗證、記錄判讀與復原

設定能夠儲存，不代表可以成功啟動；核心能啟動，也不代表目標流量會依預期出站。進階設定應分層驗收：先確認語法與資源載入，再確認本機入口，接著檢查路由、解析與遠端連線。每次修改前都應先寫下預期結果，例如「只有指定的完整網域改走代理，區域網路仍維持直連」，測試失敗時才能判斷是哪個環節未達預期。

建立可重現的變更記錄

備份範圍至少應涵蓋訂閱群組、手動伺服器、路由規則、DNS 與接管設定，不能只儲存伺服器清單。匯出的檔案可能包含憑證，請存放在安全的位置。修改時記錄欄位名稱、原值與新值，並區分用戶端產生的設定與完整自訂設定。若變更由多個介面選項共同產生，最好逐一儲存畫面截圖，避免復原時只記得其中一個選項。

每次只調整一個主題：先確認訂閱更新，再調整路由，接著處理 DNS，最後才導入 TUN 與 FakeDNS。修改後重新啟動核心，或使用用戶端明確提供的重新載入功能；確認啟動成功後再測試實際用途。不要在同一輪操作中同時更新訂閱、切換核心與修改 DNS，否則即使連線恢復，也很難判斷是哪項變更發揮作用。

依流量路徑判讀記錄

先確認本機入口是否收到連線。若沒有入口記錄，應檢查應用程式的代理設定、連接埠、TUN 範圍與應用程式排除設定，不要先分析遠端交握。確認入口存在後，再查看路由目標與出站標籤；標籤不符就檢查規則順序與目標資訊。只有在標籤正確後，才繼續檢查解析、撥號、交握與伺服器回應。依照這個順序排查，可以減少在錯誤層次反覆修改參數。

暫時提高記錄詳細程度時，請控制測試時間，完成後恢復日常等級。記錄可能包含存取網域、伺服器位址與連線細節，分享前請先移除敏感資訊。連線逾時應依發生階段判斷：解析逾時檢查 DNS，撥號逾時檢查網路與連接埠，交握階段異常則檢查協定、安全設定與系統時間。只截取最後一行通常不足以說明真正原因。

進行對照測試，不只測一次速度

測試項目應涵蓋需要走代理的目標、應直連的目標、區域網路位址，以及實際使用的應用程式。每個目標都應建立新連線，避免沿用舊工作階段而掩蓋規則變更。可用性、連線延遲與實際傳輸速度反映不同情況；一次延遲測試成功，不代表 DNS、UDP 與大型檔案傳輸都正常。也不要把目標服務本身的錯誤回應直接歸咎於代理設定。

若只有一個應用程式失敗，請先與同一裝置上的另一個應用程式比較，檢查獨立 DNS、是否遵循代理設定及快取。若所有應用程式都失敗，再縮小範圍檢查系統網路與用戶端入口。若一般代理正常但 TUN 失敗，請保留同一台伺服器，只變更流量入口來比較；若更換伺服器後仍失敗，應優先檢查共用的本機設定，不要繼續大量更換伺服器。

依相反順序撤銷變更

復原時，先撤銷最後加入的複雜設定，再還原原有路由與 DNS。停用 FakeDNS 後，處理合成位址快取；停用 TUN 後，確認系統路由與解析器已復原；停止用戶端前，確認系統代理不再指向已停止的連接埠。若問題由訂閱更新引起，只要還原該群組的備份，不必連同無關的本機規則一起刪除。復原範圍越精確，越容易保留已確認正確的部分。

若仍無法找出問題，請整理用戶端名稱、作業系統、流量入口模式、核心類型、重現步驟與已去除敏感資訊的記錄片段，再參考執行記錄錯誤排查方法逐項檢查。若還原到最初基準設定後仍無法連線，請回到快速入門教學重新確認基本連線流程。設定維護的目標不是啟用更多選項，而是確保每個選項都有明確用途、可觀察的結果與可靠的復原方式。