v2rayN 進階設定

設定基準與核心適用範圍

進階設定應從一套正常運作的基準開始。桌面版建議使用 v2rayN，安裝檔可至用戶端安裝檔頁面下載；Android 裝置則可依核心需求選用 v2rayNG 或 v2flyNG。用戶端負責儲存伺服器資料、產生設定並控制執行狀態；核心負責協定連線、路由與解析。介面上有某個選項，不代表目前執行的所有核心都會以相同方式處理。排查前先確認使用的用戶端、連線協定、核心與流量接管模式，避免混淆不同層次的問題。

保留一條已驗證可用的連線路徑

先關閉額外的流量接管功能，使用已知可用的伺服器與簡單路由，確認瀏覽器透過系統代理能正常連線。接著記下本機監聽位址、HTTP 或 SOCKS 連接埠、目前的路由方案與 DNS 選項。如果這一步就失敗，先不要啟用 TUN 或 FakeDNS：新增功能只會增加變數，無法修正錯誤的節點位址、連接埠或驗證參數。替伺服器加上「基準」等本機備註，也比依賴清單中固定的列號可靠。

測試應涵蓋實際使用情境，不要只看用戶端中的單次測試結果。伺服器測試成功，通常只代表測試目標已透過對應設定完成請求；這不表示所有應用程式都會遵循系統代理，也不保證目標服務的各種連線方式都可用。可分別開啟常用網頁、完成一次需要登入的正常操作，再查看日誌中的出站選擇。若某個應用程式失敗但瀏覽器正常，應先檢查應用程式自己的代理設定、連線協定與快取，而不是立刻更換整套設定。

區分介面設定與原始設定

v2rayN 的伺服器編輯、路由編輯與 DNS 設定是設定入口；執行時產生的檔案則是這些設定的結果。直接修改產生的檔案，切換伺服器或重新啟動核心後可能會被覆寫。需要長期保留的調整，應優先透過用戶端支援的設定入口完成；確實需要自訂設定時，再使用相應功能並另存原始檔。選單文字與設定位置可能隨介面版本改變，判斷時應以功能用途與實際產生結果為準，不要依賴舊截圖上的位置。

本頁的 JSON 範例明確以 Xray 設定片段為對象，只展示相關欄位，並非可獨立啟動的完整用戶端設定。完整設定還需要入站、伺服器出站及其他必要參數。使用其他核心時，不要逐項照抄欄位；即使概念同樣稱為「路由」或「DNS」，欄位結構、預設值與處理流程也可能不同。尤其是桌面版 TUN 使用的執行元件，應以用戶端目前實際啟動的元件為準，不能只根據選取的伺服器協定推斷。

一次只調整一個變數

設定前先儲存可還原的副本，並記下這次調整的目的，例如「讓測試網域透過指定出站」，而不是籠統地寫「最佳化網路」。每次只變更一個相關變數，重新啟動必要的執行元件後，重複相同測試並記錄結果，再進行下一步。路由、DNS 與流量接管經常彼此影響，同時修改三者，即使連線恢復，也很難判斷是哪項設定生效；下次更新或重新啟動後，問題也可能再次出現。

日誌記錄以足敷排查為原則。暫時提高日誌層級，有助於確認設定載入與規則比對流程，但日誌也可能包含網域、位址與連線資訊。提供問題資訊時，只保留錯誤前後必要的片段，並移除訂閱連結、驗證欄位與個人瀏覽紀錄。若問題是連線逾時，可先依節點逾時排查步驟逐項檢查；確認基準穩定後，再閱讀下方的訂閱與路由章節。

訂閱分組與伺服器篩選

訂閱是更新一組伺服器設定的入口；分組則是用戶端儲存與顯示這些設定的整理方式。兩者彼此相關，但並非同一概念：一個分組可以連結訂閱，也可以存放手動新增的伺服器。建議依設定來源建立分組，不要把所有伺服器都放在同一份清單。如此一來，更新失敗時較容易找出來源；停用或刪除訂閱時，也能確認影響範圍。分組名稱應簡要標示用途或來源，不必照抄冗長的宣傳式節點名稱。

先整理來源，再更新伺服器

在訂閱分組設定中建立分組，填入自行取得的訂閱網址，確認儲存後只更新這個分組。更新完成後，檢查匯入數量與錯誤訊息，再回到伺服器清單確認位址、協定與備註是否合理。首次匯入先不要啟用自動更新，也不要同時匯入多個來源；先確認單一來源的擷取、解析、儲存與連線都正常，之後才能分辨問題來自網路、訂閱內容，還是新分組造成的設定衝突。

訂閱連結通常含有可識別帳戶的參數，應比照帳戶資訊妥善保管。不要將完整連結寫進伺服器備註、公開截圖或求助日誌，也不要為了縮短網址而交給不明的轉址服務。服務提供者更換網址或帳戶識別資料時，應至分組設定替換舊連結。連結仍可開啟但沒有伺服器，不一定是用戶端故障；帳戶狀態、內容格式或服務端回傳的提示頁，都可能影響解析結果。

篩選只會縮小範圍

篩選通常依伺服器備註或用戶端支援的條件，減少清單中的候選項目；它無法改變伺服器的實際位置、協定能力或可用狀態。也要區分介面搜尋與訂閱篩選：搜尋只會暫時隱藏不符合的列，清除搜尋後就會重新顯示；訂閱篩選則可能在更新時直接排除項目，使其根本不會匯入本機分組。調整前先確認設定屬於哪一種，避免把「被篩掉」誤認為「服務提供者刪除了伺服器」。

不同介面的篩選欄位可能接受一般關鍵字、多個條件或正規表示式，請依欄位說明輸入。若明確支援正規表示式，^(测试|备用) 可比對以「測試」或「備用」開頭的備註；這只是表示式範例，不代表所有用戶端的篩選欄都能解析。更新後若清單變空，先清除篩選條件並重新更新，再逐一加入條件。大小寫、空格、全形符號或服務提供者更改名稱，都可能讓原本有效的篩選突然失效。

保護本機修改與目前選取項目

從訂閱匯入的項目通常由後續更新管理。本機修改位址、連接埠或傳輸欄位後，下次更新可能會還原成訂閱中的值；備註等欄位是否保留，也取決於用戶端的合併方式。若確實需要維護不同參數的設定，可將項目複製到獨立的手動分組，並在備註中說明修改原因。如此一來，訂閱項目可繼續跟隨來源更新，手動項目則用於可控的測試，避免混淆兩種維護方式。

更新後應重新確認目前使用的伺服器。清單順序變動、項目更名或訂閱移除舊紀錄，都可能讓原本的選取項目不再適合使用。不要只確認「更新成功」，還要檢查實際啟用的伺服器是否仍屬於預期分組，並透過一次實際請求驗證。若要批次測試，先縮小至符合目前用途的項目；大量並行測試會占用網路與本機資源，結果也容易受測試目標限制，不能直接當成伺服器品質排名。

空清單與解析錯誤的處理方式

更新失敗時，先確認錯誤發生在哪個環節：請求無法完成，優先檢查連結、網路，以及更新是否需要透過代理；請求完成但解析失敗，確認回傳內容是否真的是訂閱，而非登入頁或到期提示；更新成功但清單為空，則檢查篩選條件與協定相容性。尚未確認來源有效前，不要連續重設用戶端。可進一步參閱訂閱更新失敗與解析錯誤；保留原分組再測試新設定，比直接刪除所有項目更容易還原。

路由規則與分流實作

路由負責決定連線使用哪個出站，不負責產生訂閱或修正伺服器參數。可以把它視為依序檢查條件的決策表：流量比對到某條規則後，就交給該規則指定的出站。就 Xray 的一般規則路由而言，前面的比對結果優先，因此具體例外通常應放在範圍較廣的規則之前。用戶端選擇「全域」或某個預設方案，可能會改變產生的規則；開始自訂前，先確認目前啟用的是哪套路由。

從明確的目標開始

先寫下想改變的行為，例如讓某個測試網域直連，或封鎖明確不需要的目的位址。不要一開始就匯入大量來源不明的規則，再靠網頁能否開啟猜測效果。網域規則適用於主機名稱固定的服務；IP 規則適用於位址範圍明確的網路；連接埠規則則應依應用用途謹慎設定。單一服務可能同時連線到多個網域、內容傳遞位址與登入介面，只處理首頁網域未必涵蓋完整流程。

在 Xray 規則中，full:example.com 表示比對完整網域；domain:example.com 則可涵蓋該網域及其子網域。未加這些前綴的一般字串，可能依不同的比對語意處理，因此不要混淆「包含關鍵字」與「屬於某個網域」。IP 條件可指定單一位址或 CIDR 網段。維護規則時，應記錄每條規則的用途、影響對象與測試方法；若只寫「最佳化規則」這類名稱，過一段時間就很難判斷是否能刪除。

了解同一條規則中的條件關係

同一條規則中的不同條件通常必須同時符合，例如網域與連接埠都符合才會命中；同一清單中的多個候選項目，則表示可選範圍。若要讓某個網域與另一個獨立 IP 網段都走相同出站，通常應拆成兩條規則，而不是塞進同一條規則並期待「符合其中一項即可」。這類細節容易造成規則看似存在，實際上卻從未命中。新增規則後，應以真正符合條件的請求測試，並檢查命中的出站。

以下片段示範簡單的規則順序：特定測試網域先直連，接著讓私有位址範圍直連，最後以 TCP 與 UDP 規則明確交由代理處理。範例中的 direct 與 proxy 必須對應實際的出站標籤；它們不是核心自動產生的保留名稱。片段必須合併至有效的 Xray 設定，不能單獨啟動。私有位址規則也應依實際網路用途調整，不要認為所有私有位址都屬於目前裝置所在的區域網路。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

網域、解析與預設出站

AsIs 表示路由階段不會為了比對 IP 規則而主動解析網域；原本就是 IP 的目標仍可參與 IP 比對。如果目標只有網域，某些 IP 規則可能無法如預期運作。IPIfNonMatch 會在網域規則未命中時嘗試解析，再進行比對；這也會增加對解析器與解析路徑的依賴。不要只為了讓某條 IP 規則生效，就忽略 DNS 請求本身是否可連線。也要確認未命中規則的連線會使用哪個預設出站；明確寫出最後一條規則更容易理解。

有規則不代表用戶端一定能看到需要比對的網域。應用程式可能直接連線到 IP，也可能先自行解析再發起連線；是否啟用嗅探、能辨識哪些協定，以及嗅探結果是否用於路由，都會影響可取得的資訊。嗅探無法還原所有加密流量的網域，也不該被當成萬用修補方式。先確認請求帶有網域還是 IP，再決定要調整規則、DNS 或流量接管方式，通常比不斷增加比對條件有效。

驗證時分別測試規則涵蓋的目標、規則外的目標與本機服務，避免只證明單一路徑可用。若新增規則導致大量請求失敗，先停用該規則以還原基準，再檢查順序、條件關係與出站標籤。封鎖規則尤其應限定明確範圍，否則可能連解析、驗證或更新請求也一起封鎖。路由表需要定期維護，移除過時例外，並在更新用戶端或切換核心後重新檢查產生結果；不要假設舊方案永遠會以相同方式執行。

DNS 設定與解析路徑

DNS 問題通常不只是「換一個解析位址」這麼簡單。應用程式可以使用系統解析器，用戶端核心也可以為路由或直連建立自己的解析流程；代理伺服器則可能在遠端解析目標網域。這些請求發生的位置不同，受到的路由與網路條件也不相同。先確認問題發生在應用程式解析、核心解析，還是遠端連線階段，才能選對設定入口。瀏覽器無法開啟網頁但伺服器測試正常，原因可能是 DNS，也可能是應用程式沒有使用預期的代理。

釐清三種解析路徑

第一種是裝置連線至本機解析器，負責處理應用程式一般使用的網域查詢；第二種是核心連線至指定的解析服務，可能用於 IP 路由比對或直連出站；第三種是代理出站將網域交給服務端，再由服務端完成解析。並非每條連線都會經過所有路徑。對照目前模式，記下查詢從哪裡送出、經過哪個出站，以及回傳哪類位址，就能了解為何某項 DNS 設定會影響部分網站，卻不影響其他網站。

也要檢查解析服務本身如何連線。傳統 UDP 查詢與加密的 HTTPS 查詢等方式，所需傳輸條件不同，不能只把位址換成 URL，就期待所有核心都能自動配合。Xray 的 DNS 服務設定會依位址形式採用特定處理方式，包括使用核心路由或本機連線的差異；其他元件可能使用不同欄位。請查看目前核心支援的形式，再確認解析請求確實經由預期的出站傳送。

先處理引導解析循環

使用網域形式的解析服務時，必須先知道解析服務的 IP；如果代理伺服器位址也是網域，建立代理前同樣需要先完成必要解析。若設定成「所有 DNS 都必須經過尚未建立的代理」，而代理伺服器又依賴相同 DNS 才能連線，就會形成循環，可能導致啟動後所有請求都逾時。處理方式是為伺服器位址或解析服務提供可連線的引導解析路徑，並讓它獨立於尚未建立的連線，而不是一味增加逾時與重試次數。

以下是 Xray 內建 DNS 的簡化片段：靜態對應用來示範如何覆寫測試網域；伺服器清單與查詢策略則控制內建解析器的查詢方式。範例不會接管作業系統的所有 DNS，也沒有指定解析請求使用的出站。example.com 與文件範例位址只適合用來理解結構，不應直接用於正式服務設定；實際解析服務應依所在網路的可連線性與管理需求選擇。

{
  "dns": {
    "hosts": {
      "example.com": "192.0.2.10"
    },
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

靜態對應會略過該網域正常的動態解析流程，適合短期診斷，不適合任意固定內容傳遞服務的位址。服務可能依地區、負載與時間回傳不同位址，固定結果過期後就會造成連線失敗。診斷結束後，請移除暫時對應並重新發送請求。解析結果正確也不代表服務可用，還需要檢查目標連接埠、傳輸協定與服務端的連線處理方式，避免把後續連線錯誤都歸咎於 DNS。

IPv4、IPv6 與快取

UseIP 可查詢 IPv4 與 IPv6 位址；UseIPv4 或 UseIPv6 則會限制查詢類型。限制為 IPv4 可用來比對與診斷 IPv6 路徑問題，但不能說成普遍較快的設定。裝置取得 IPv6 位址，不代表選用的出站一定能正確連線到該位址；反過來說，僅支援 IPv6 的目標也無法透過限制為 IPv4 解決。應綜合判斷裝置網路、代理伺服器與目標服務三端的能力。

作業系統、瀏覽器、應用程式與核心都可能各自保留解析快取。修改 DNS 後立刻重新整理已開啟的頁面，仍可能沿用舊位址或既有連線，因此測試時最好建立新連線，並視需要重新啟動受影響的應用程式與核心。Windows 可使用系統提供的 DNS 快取清除工具；macOS 與 Linux 的快取管理方式則依系統服務而異，不要照抄其他平台的指令。記錄調整前後的解析結果，比反覆清除所有設定更有幫助。

依實際狀況定位，不只看解析器名稱

若網域連線失敗，但同一服務透過已知 IP 位址可正常連線，優先檢查查詢逾時、位址類型與回傳結果；若網域能解析但連線失敗，就改查路由、連接埠與服務端參數。若只有 TUN 模式下失敗，接著檢查 DNS 接管與虛擬網路介面路徑。更換解析器後恢復，只能證明舊路徑在這次測試中有問題，不能證明新解析器適合所有應用程式。最終設定應符合路由需求，並保留一套可還原基準的解析方案。

TUN 模式與流量接管

遵循系統設定的應用程式會使用系統代理；TUN 則透過虛擬網路介面，將選定的 IP 流量送進處理元件，兩者接管流量的層級不同。當應用程式不讀取系統代理時，TUN 可能提供另一條路徑，但不代表「所有流量一定都會經過代理」。最終仍會受到系統路由、排除規則、DNS 接管、UDP 支援與出站設定影響。啟用 TUN 前，先保留透過系統代理正常運作的基準作為對照；不要把 TUN 當成修復伺服器連線失敗的按鈕。

確認執行元件與系統權限

在 v2rayN 啟用 TUN 前，請檢查用戶端提供的相關設定，以及啟動日誌中顯示的執行元件。伺服器使用 Xray 協定，不代表 TUN 介面就是由同一核心直接建立。不同元件的設定結構、流量堆疊與 DNS 行為可能不同，不能把原始 Xray 欄位直接套用到其他元件的 TUN 設定。首次啟用時，先使用預設或較少變更的方案，確認介面建立、路由安裝與請求路徑正常，再調整細部參數。

建立虛擬介面與調整系統路由通常需要額外權限。Windows 應依用戶端要求授予相應權限；Linux 需要具備建立介面與修改路由的權限；macOS 則應完成用戶端要求的系統授權。請從日誌與系統提示確認權限錯誤，不要只看開關狀態判斷是否成功。即使開關顯示已啟用，若介面沒有建立或路由沒有安裝，應用程式仍可能沿用原本的路徑；此時應先修正權限或啟動問題，再調整分流規則。

避免流量回圈與重複接管

TUN 擷取的連線仍須透過出站建立網路連線；出站本身的連線不能原封不動地送回入口，否則會形成循環。用戶端通常會透過介面選擇、路由排除或其他機制處理此問題。裝置同時執行其他 VPN、閘道軟體或第二套流量接管工具時，這些機制可能互相覆蓋。先停用其他接管工具建立對照，再逐一重新啟用並觀察是否出現路由衝突。兩套軟體各自顯示「已連線」，不代表它們一定能同時運作。

啟用 TUN 後，也要決定是否保留系統代理。如果應用程式先將請求傳送至本機代理，再經過另一層路徑處理，可能造成重複接管、繞路或難以理解的日誌。不同用戶端模式的設計不完全相同，因此不要一概認為兩者必須同時啟用或同時關閉；請依目前模式的說明設定並分別測試。查看本機代理連接埠是否仍有處理請求，有助於釐清為何關閉系統代理後，某些應用程式的表現會改變。

MTU、UDP 與區域網路存取

MTU 決定介面允許的封包大小。路徑中的封裝方式與網路條件可能造成大型封包處理問題，但任意調低 MTU 也可能增加分段與處理負擔。只有出現「握手成功但傳輸卡住」或特定大型請求失敗等跡象時，才將 MTU 納入排查；小幅調整後重測相同請求，不要把單一數值當成所有平台通用的答案。UDP 也必須另外驗證，因為網頁的 TCP 請求正常，不代表依賴 UDP 的應用程式也正常。

區域網路印表機、檔案共享與裝置探索需要特別檢查。部分功能仰賴廣播或多點傳送，不是加上一條私有位址直連規則就能完全恢復。先確認一般區域網路位址可正常連線，再檢查探索機制是否受到虛擬介面或防火牆影響。TUN 接管本機流量，不代表其他裝置也能使用本機代理；若要共享代理，必須另外設定監聽範圍與防火牆，請參閱允許區域網路連線說明。

分階段驗證與還原設定

啟用後依序測試：確認元件已啟動、介面與路由已建立，再檢查 DNS，最後分別測試瀏覽器、原本不遵循系統代理的應用程式與本機服務。Android 使用系統 VPN 接管時，也要檢查應用程式的包含或排除範圍，以及背景執行限制。若關閉接管後網路仍異常，請檢查系統代理、DNS 與殘留路由是否已還原；不要反覆切換開關來掩蓋殘留狀態。還原基準後，再依說明中心的現象分類繼續排查。

FakeDNS 與網域還原

FakeDNS 不會回傳目標服務的真實位址，而是為網域指派一個受控位址，並保存網域與位址之間的對應關係。應用程式接著連線到這個位址時，處理元件會透過對應關係還原網域，再執行路由與出站。如此一來，即使應用程式只向網路層提供 IP，也能保留網域資訊；但前提是查詢與後續連線都經過彼此配合的處理流程。FakeDNS 不是一般 DNS 的別名，也不能只填入解析伺服器位址就完成設定。

先確認整個請求流程完整

完整流程包含應用程式發出查詢、FakeDNS 回傳對應位址、應用程式連線至該位址，以及入口還原網域四個環節。任何一環繞過處理元件，應用程式就可能連線到無法存取的受控位址。常見原因包括系統 DNS 未被接管、應用程式使用自己的解析通道、目標位址未經由預期介面，或用戶端入口未啟用相應的網域還原功能。因此應先確認 DNS 與流量接管正常，再導入 FakeDNS；不要在 DNS 已混亂時繼續增加功能。

不同核心與 TUN 元件可能提供概念相似、欄位卻不同的功能。Xray 的 FakeDNS 設定需要搭配內建 DNS 與入口嗅探等選項；其他元件的 fake-IP 機制不能直接套用 Xray 欄位。只有目前執行的元件明確支援且提供相應入口時，才進行設定。若用戶端只讓使用者選擇一般 DNS 方案，不要把下方片段貼進不明欄位，也不要透過修改訂閱項目的伺服器位址來模擬對應關係。

位址池與對應容量

以下是 Xray 的位址池片段，單獨使用並不會啟用完整的 FakeDNS 請求流程。ipPool 指定受控位址範圍，poolSize 指定位址池容量。範例使用的網段具有特殊用途，並非應用程式可直接連線的公網服務位址；也要確認它不會與裝置既有網路或其他接管工具使用的範圍衝突。容量應依元件支援範圍設定，不要為了「效能」盲目調大，也不可超出所選位址範圍的容納量。

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

對應池容量有限，元件可能在容量不足時回收舊對應。若應用程式長期快取受控位址，之後連線時就可能遇到對應遺失或變更。因此要一併考量對應的存續時間與應用程式快取。某些問題只在長時間執行後出現，重新啟動後短暫恢復，不要立刻判定是伺服器不穩定；也可能是應用程式保留了舊位址，或接管元件重新啟動後遺失原有對應。排查時記錄重新啟動、快取與問題重現時間之間的關係。

辨識不適合使用位址對應的情境

區域網路服務、只接受實際 IP 的工具，以及會把解析結果傳給其他裝置的應用程式，都可能不適合直接使用受控位址。例如本機取得對應位址後，將它傳給區域網路中的另一台裝置，但該裝置沒有相同的對應資料，就無法建立連線。需要設定例外時，應使用目前元件支援的網域排除或真實解析機制，並確認例外請求後續使用一致的路由。不要只排除 DNS 查詢，卻仍讓實際連線走不適合的出站。

應用程式自行使用加密 DNS 或直接連線至 IP 時，FakeDNS 可能完全沒有參與。此時日誌看不到對應，不代表功能故障，而是請求走了另一條路徑。是否要調整應用程式的解析方式，應依該應用程式提供的設定處理；假設所有查詢都會被攔截，往往會造成誤判。嗅探也有協定上的限制，無法保證從任何連線還原原始網域，尤其是缺少可辨識主機資訊的請求。

以小範圍測試確認效益

先選一個可重複存取的一般測試目標，確認查詢取得受控位址、連線受到攔截、日誌能對應到原始網域，且最後使用預期的出站。接著檢查一個區域網路目標與一個已設定例外的目標，確認兩者仍使用真實解析。如果只是要讓既有網域規則生效，而目前的請求本來就帶有網域，FakeDNS 未必能帶來實際效益。簡單的路由與 DNS 設定通常更容易維護，不必為了啟用功能而增加複雜度。

還原時，依序關閉相關對應設定、恢復解析方案、重新啟動受影響的元件與應用程式，然後重新測試基準。只關閉一個開關卻保留舊位址池路由，或只修改 DNS 但讓應用程式繼續持有對應位址，都可能讓問題持續。分別保存測試設定與穩定設定，日後維護時就能確認哪些設定是為 FakeDNS 所需，避免刪除單一欄位後留下難以理解的半套請求流程。

多訂閱維護與更新控管

多訂閱管理的重點不是讓清單變長，而是讓每個來源都有明確的維護範圍。若一個來源用於日常連線，另一個用於特定環境或備援，就應分別建立分組並註明用途。訂閱擷取成功、伺服器參數正確與實際連線可用，是三種不同結果，維護時應分別確認。不同來源也不應共用來歷不明的驗證資訊；無法說明由誰提供、用途為何的連結，不適合納入長期自動更新流程。

建立來源清單與更新週期

為每個訂閱記錄來源名稱、用途、最近一次人工確認結果，以及是否需要透過代理更新。紀錄不必放進公開檔案，也不需要保存完整連結；重點是發生問題時能知道應向哪個來源查證。自動更新頻率應依提供者的更新方式與自身需求設定。頻繁擷取可能觸發伺服器限流，也會讓用戶端頻繁替換清單；使用頻率較低或仍在測試相容性的分組，則適合手動更新。

啟動時自動更新看似方便，但也要考慮啟動時網路尚未穩定的情況。裝置剛連上無線網路、代理尚未啟動，或帳戶頁面需要驗證時，訂閱請求都可能失敗。應先建立一條已儲存且可用的連線，再視需要更新依賴代理的來源。不能讓唯一可用的連線必須先從訂閱取回，而取得訂閱又必須透過這條尚不存在的連線，否則更新流程就會形成循環相依。

逐一更新分組，不要一次替換所有來源

維護多個來源時，先更新一個分組，檢查項目的新增、刪除與錯誤，再測試重要伺服器；確認無誤後才更新下一個分組。即使某個來源回傳錯誤內容，也不會因此同時失去所有對照。重要的手動修改應事先複製到獨立分組；至於訂閱內容本身的變更，應接受由來源管理的事實，不要期待用戶端永遠保留已撤除的伺服器。更新策略與本機修改策略應分開規劃。

若更新後節點數量明顯變化，先檢查篩選條件、協定相容性與服務端提示，再判斷內容是否確實變動。只比較數量不足以評估品質：同一伺服器可能有多個傳輸入口，同名項目也可能指向不同位址。必要時應比對位址、連接埠、協定與傳輸參數，不要只看備註。用戶端無法解析的項目，應確認所需的核心功能；更新軟體或許能解決部分相容性問題，但無法取代正確的服務端參數。

重複項目與故障關聯

兩個來源都出現相同備註，不代表它們是不同的備援；若位址、連接埠、驗證與傳輸條件一致，可能只是同一份設定由不同來源重複提供。即使位址不同，也可能共用相同的服務基礎設施，因此不能只因訂閱數量增加就認為故障風險已分散。整理時應保留來源資訊，確認是否需要同時維護重複項目，再決定要隱藏或刪除。不要只為了讓清單整齊就移除所有來源標籤，否則日後更新與排錯都會失去線索。

故障發生時先判斷影響範圍：單一項目失敗，優先檢查該項目的參數；整個分組失敗，檢查來源狀態與共用設定；所有來源都失敗，則檢查本機網路、系統時間、執行核心、DNS 與流量接管模式。依此順序排查可減少不必要的批次刪除與重新匯入。備援來源也應定期以少量實際請求測試，不要只讓它留在清單裡；有紀錄的可用結果，遠比「看起來還有很多伺服器」更有參考價值。

停用來源與還原設定

不再使用的來源可以先停用自動更新，再確認目前使用的伺服器是否來自該分組，最後視需要刪除。刪除前，請確認沒有路由或自訂設定間接依賴其中的項目，也沒有將唯一可用的連線留在該分組。移轉裝置時，設定副本可能包含訂閱網址與驗證資訊，應透過自行控管的方式轉移，並在新裝置完成測試後再清理舊副本。用戶端設定備份不適合作為公開分享的教學附件。

建立簡單的維護紀錄即可：本次更新了哪個來源、調整了哪項篩選、目前穩定使用哪個分組，以及發生異常時如何還原。不必把每次請求都寫成繁瑣日誌，但重要變更應有清楚說明。若主要問題仍是訂閱無法解析，請回到分組與篩選檢查匯入流程；若訂閱正常但特定應用程式失敗，則應檢查路由、DNS 或 TUN，不要繼續增加來源來掩蓋設定問題。

自訂出站與設定驗證

出站描述流量離開核心的方式，路由則負責選擇使用哪個出站。伺服器清單中的項目，不代表能在自訂規則中直接引用它的備註；規則通常引用執行設定中的出站標籤。開始自訂前，先確認需求是額外直連、明確封鎖、指定伺服器出站，還是串接多個出站。不同目的需要的欄位也不同。自訂功能適合處理用戶端一般設定無法表達的需求，不宜作為日常設定的第一步。

標籤必須在同一份設定中完整定義

每個出站都應使用清楚且唯一的 tag；規則中的 outboundTag 必須與其完全一致。標籤不是顯示名稱，也不會因為大小寫相似就自動關聯。複製規則時最常見的錯誤，是引用了其他設定中的標籤，卻沒有定義相應的出站。另一個問題是用戶端重新產生設定後改變了出站結構，因此長期使用的規則應透過支援的入口儲存，並核對實際產生的設定，不要只確認編輯欄中的文字。

以下 Xray 片段只定義兩個基本出站：freedom 用於直連，blackhole 用於封鎖。它沒有代理伺服器出站、入站或完整路由，因此無法作為完整設定啟動。實際合併時，應檢查現有標籤，避免重複定義。若要使用前述路由範例中的 proxy，同一份設定中還必須有真實且正確的代理出站；不能以空物件取代伺服器參數。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

直連解析與伺服器協定參數

直連出站最後需要連線至實際目標位址；若目標是網域，就必須考量解析路徑。Xray 的 freedom 設定中，domainStrategy 可改變直連階段處理網域的方式，但它與 routing.domainStrategy 並非同一項設定：前者用於建立出站連線，後者則用於路由比對。不要因為名稱相似就同步修改。先判斷問題發生在規則選擇之前，還是連線建立階段，再調整對應層級。

代理出站應採用服務提供者給定的協定與參數，不要只憑協定名稱猜測其他欄位。位址、連接埠、驗證、傳輸與安全設定都必須相互配合；啟用 REALITY 時，還會用到服務端提供的相關參數，可參閱REALITY 術語說明了解欄位用途。不同核心支援的範圍不完全相同，核心家族資訊可參閱Xray 條目。不要只為了通過語法檢查，就將必要參數留空。

出站串接不等於自動容錯

一個出站透過另一個出站建立連線時，也必須考量底層連線是否可達、網域在哪裡解析，以及是否支援 UDP。Xray 的出站代理關係可能使用 proxySettings；其他元件則可能採用不同欄位，必須依目前核心的結構設定引用，不能直接照抄。串接也不能形成迴圈，例如甲依賴乙，乙又依賴甲。多一層連線通常就多一層故障相依，不會自然提高可用性，也不能只靠標籤順序完成自動切換。

自動選擇或容錯還需要相應的偵測與選擇機制，並明確定義何種狀況算失敗、何時切換，以及如何處理既有連線。缺少這些機制時，只定義多個出站不會讓核心自動輪流嘗試。大多數設定查閱情境中，先分別驗證每個出站，再為明確目標設定固定規則會更穩妥。涉及串接時，應先驗證底層出站，再測試上層伺服器連線，最後測試目標請求，避免將三層錯誤都簡化成「節點逾時」。

先檢查結構，再進行對照測試

設定驗證分為三步：先檢查 JSON 是否有多餘逗號、未成對的引號或重複欄位；再確認目前核心是否支援各欄位，以及標籤引用是否完整；最後啟動元件並觀察實際請求。語法合法不代表欄位有效，核心成功啟動也不代表規則選擇符合目標。特別留意從其他元件複製而來的同名欄位，以及片段放在錯誤層級的情況。設定出錯時，先還原已儲存的原始檔，再逐步加入必要內容。

執行驗證至少應涵蓋目標規則、預設路徑、DNS 與本機服務。查看日誌是否已載入新設定、是否選擇預期的出站，以及錯誤發生在解析、握手還是傳輸階段。測試完成後，將暫時提高的日誌層級恢復成適合日常使用的設定，並移除不再需要的測試規則。穩定的設定應能說明每個出站的用途與每項例外的原因；若只剩下一大段無法解釋的文字，後續維護風險往往比最初的問題更高。

若自訂設定影響基本連線，請先依使用指南還原快速入門流程，再根據實際狀況回查相關章節。需要更換用戶端安裝檔時，請至下載頁面，不要將設定問題直接歸咎於安裝檔。進階設定的標準不在欄位數量，而在於請求路徑清楚、異常可重現、變更可還原，且日常所需的應用程式都經過實際驗證。