v2rayN 進階設定指南

01 設定基準與驗證順序

進階設定的第一步不是增加規則，而是先保存一組已經可正常使用的設定。確認選用的伺服器能實際開啟網頁，再記下伺服器所屬分組、系統代理狀態、路由設定名稱、核心類型，以及是否啟用 TUN。無須記錄訂閱網址或伺服器憑證；這些資訊已足以判斷後續變更影響哪個層面，也方便設定失敗時還原原本的組合。

區分用戶端、核心與系統接管

v2rayN 負責圖形介面、訂閱管理與產生設定，實際連線則由選用的核心處理。系統代理會讓遵循該設定的應用程式將要求送往本機入口，但系統代理本身不是通道。TUN 會在更底層接管網路封包，但仍需要正確的路由與輸出設定。介面顯示正在執行，只代表相關程序已啟動，無法單憑這點確認網域解析、伺服器交握及目標連線都成功。

先到「設定」查看本機監聽連接埠與目前使用的核心，不要依照教學截圖猜測連接埠。若瀏覽器使用獨立的代理擴充功能，請暫時設為跟隨系統；若應用程式有內建代理設定，也要記下它是否會覆蓋系統設定。否則同一台電腦可能同時存在多條流量路徑，造成一個網頁正常、另一個失敗，容易誤以為路由規則不穩定。

先小範圍驗證，再擴大接管範圍

建議先關閉 TUN，只使用「系統代理 → 自動設定系統代理」，並保留簡單的路由設定。依序開啟一般網域網頁、區域網路位址及實際需要使用的應用程式。測試網頁時，請重新開啟頁面，而非只重新整理已快取的分頁。區域網路測試可使用自家路由器的管理位址；不要照抄他人網路的網段，也不要拿公開服務位址當作區域網路目標。

測試紀錄應寫明「使用哪個應用程式、連線到哪一類目標、出現什麼錯誤」。例如網域無法開啟，但區域網路管理頁正常，表示不必從所有網路介面開始檢查；若只有單一應用程式失敗，先確認它是否使用獨立代理或加密 DNS。也請記下錯誤發生時間，方便在記錄檔中找到對應連線，不必對著整頁歷史紀錄猜原因。

每次只修改一個可明確說明的變數

每次調整後先儲存，再依介面提示重新載入設定或重新啟動服務。修改伺服器參數、DNS 或 TUN 參數後，既有連線可能仍沿用原本的路徑；驗證時請關閉相關應用程式的連線，再重新發出要求。不要同時更換伺服器、啟用 FakeDNS 並匯入整套路由。即使連線恢復，也無法確認是哪項設定生效，更無從判斷其他變更是否留下潛在問題。

查看記錄檔時，先區分啟動錯誤與要求錯誤。設定無法解析、監聽位址被占用，屬於服務啟動階段；連線逾時、名稱解析失敗、遠端拒絕則發生在要求階段。前者應先還原設定結構或排除連接埠衝突；後者再依序檢查入口、解析、規則與輸出。提高記錄詳細程度只適合短時間重現問題，排查後請恢復常用層級，避免記錄檔持續膨脹。

如果基本連線尚未成功，請先回到設定教學完成基本流程，再繼續閱讀本頁。安裝檔與平台選擇請見用戶端下載頁；需要快速判斷特定狀況時，可查閱常見問題。本章介紹的紀錄方式適用於後續各章：先確認變更影響的層次，再決定下一步，而非把所有開關逐一打開。

02 訂閱分組與伺服器篩選

訂閱分組用來管理伺服器來源，不負責分流。分組可以對應單一訂閱來源，也可以存放手動匯入的項目；重新命名分組不會改變伺服器的實際連線參數。建議依來源與用途命名，例如日常訂閱、備用訂閱、手動設定。名稱是用來辨識的，不應包含訂閱金鑰，也不要在備註中放入完整網址，以免截圖時連同憑證一併外洩。

確認分組後再更新

在「訂閱分組 → 訂閱分組設定」中，檢查目標分組的網址、啟用狀態及可用的篩選選項。儲存後，從「訂閱分組」選單執行更新，並確認目前指令適用於目前分組還是所有分組。若有多個分組，介面目前顯示的分組不一定等於更新指令的作用範圍；更新完成後，請切回目標分組確認項目變化，不要只看完成提示。

訂閱網址通常是用來取得一組伺服器資料的網路網址，分享連結則代表單一連線設定。將分享連結填入訂閱網址欄位，不保證更新程式能將它當作訂閱處理。若剪貼簿中的是單一連結，請使用「伺服器」選單中的對應匯入功能；若是訂閱來源提供的網址，則應填入分組設定。兩種方式的差異可參閱分享連結與訂閱網址的差別。

顯示篩選與更新篩選並不相同

主視窗的搜尋或分組選擇通常只會縮小目前顯示的範圍，不一定會刪除項目。分組設定中的篩選條件則可能在更新時決定要保留哪些伺服器。排查「更新後沒有伺服器」時，先清除主視窗的搜尋文字，再確認選取的分組，最後檢查更新篩選條件。依這個順序處理，可避免把暫時隱藏的項目誤判為訂閱解析失敗。

不同版本可能提供名稱篩選或正規表示式選項。只有欄位說明明確指出使用正規表示式時，才輸入表示式；一般文字篩選未必會將括號與直線符號解讀為特殊字元。正規表示式中的 HK|JP 代表比對任一片段，^(HK|JP)- 則要求名稱以指定前綴開頭。先用少量已知名稱驗證，再擴大範圍，避免大小寫、空格或全形符號差異導致所有目標項目都被排除。

^(HK|JP)-

以上表示式僅示範名稱前綴比對，不代表地區資訊正確，也不會自動選擇速度較快的伺服器。來源若更改命名格式，原有篩選條件可能失效。名稱中含有地區字詞，也不代表實際出口位置；需要保留哪些項目，應依來源說明與實際用途判斷。不要把複雜篩選規則當成連線品質檢測，也不要因單次測試結果就永久刪除整組項目。

篩選失敗時，沿資料流程逐步定位

可將更新流程拆成取得、解析、篩選與顯示四個階段。取得失敗時，檢查網址是否有效及更新所使用的網路；解析失敗時，確認回應內容確實是訂閱資料，而非登入頁面或到期通知；解析成功但清單為空時，檢查篩選條件；清單有項目卻看不到時，檢查搜尋條件與分組。各階段的處理方式不同，反覆點選更新通常不會帶來更多線索。

手動匯入的項目最好放在獨立分組。訂閱更新可能會重建該來源的伺服器清單，直接修改訂閱項目的名稱或連線參數，之後可能會被來源資料覆蓋。確實需要在本機修改時，請先複製到手動管理分組，並註明修改原因。複製只會建立獨立項目，不會讓過期的驗證資料重新有效，也不能取代來源端更新參數。

伺服器清單恢復後，請確認目前使用的伺服器仍指向有效項目。訂閱刪除或替換原項目時，原本的選取可能不再適用；請重新選擇並實際驗證連線。更多失敗情境請參閱訂閱更新失敗的自我檢查步驟。完成分組整理後再設定路由，才能區分「選錯伺服器」與「規則使用錯誤出口」這兩類問題。

03 路由規則與比對順序

路由規則決定送入核心的要求交由哪個輸出處理，不會負責把應用程式流量導入用戶端。未使用系統代理、也未經 TUN 接管的應用程式，不會因為新增網域規則就開始遵循規則。修改前，請先依第一章確認接管路徑，再開啟「設定」中的路由設定入口，複製現有設定用於測試，並保留原設定以便隨時切換。

先設定目標，再指定出口

規則可依網域、目標位址、連接埠或入口等條件進行比對。對同一條 Xray 欄位規則而言，多個不同條件通常必須同時符合；同一清單中的多個網域則可任選其一比對。若將網域與位址條件寫在同一條規則中，不代表「符合其中一項就直連」。不確定條件組合的含義時，請拆成兩條獨立規則，方便查看記錄檔及排查規則覆蓋關係。

規則會依序檢查，最先符合的規則會決定流量去向。因此，局部例外應放在較廣泛的規則之前，兜底條件則放在後面。例如，明確指定的內部網域直連規則，應排在涵蓋所有網域的代理規則之前。新增規則後若沒有變化，先檢查上方是否已有規則符合條件，不要立刻認定規則未儲存。用戶端介面中的排序也是設定的一部分，匯入後請重新確認順序。

了解網域策略的觸發時機

domainStrategy 控制路由比對時何時解析網域位址，不等於整個用戶端的 DNS 總開關。AsIs 會優先保留網域供規則比對；IPIfNonMatch 會在沒有符合網域規則時嘗試解析，再比對位址規則；IPOnDemand 則會在比對需要位址資訊時觸發解析。可用值以目前核心支援的範圍為準，不可直接跨核心套用。

以下是 Xray 設定中的區域網路直連片段，只展示 routing 欄位，並假設設定中已存在標籤為 direct 的輸出，也已載入相關規則資料。請將內容合併至現有設定的對應位置，不要當成完整用戶端設定匯入。網域規則與位址規則分開撰寫，方便區分比對結果。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

geosite:private 與 geoip:private 需要核心能讀取相關規則資料，不能假設所有執行環境都內建固定清單。記錄檔若提示資料檔不存在，請確認用戶端管理的規則資源是否可用。自己的特定內部網域可使用明確的網域規則；實際區域網路則可填入對應位址範圍，避免不相關的網路也被設為直連。

先用精確規則驗證，再擴大範圍

網域的寫法會影響比對範圍。在 Xray 中，full:example.com 會比對完整網域，domain:example.com 可涵蓋該網域及其子網域；使用正規表示式則需另外理解表示式語意。不要只為了比對一個網站，就使用可能涵蓋大量無關網域的關鍵字。初次驗證時可先使用完整網域，確認出口正確後，再依需求擴大至子網域。

驗證時應重新發出連線要求，並查看對應的輸出標籤。一個網頁可能連線至多個網域；主頁面直連不代表圖片、登入介面與媒體資源也走相同路徑。若頁面只載入部分內容，可逐一檢查實際失敗的目標，不要把整張規則表都改成單一出口。記錄檔中若只出現位址而沒有網域，也要確認應用程式是否自行先解析，以及是否有可用的網域識別資訊。

完成路由調整後，請同時測試一般網頁、區域網路服務，以及一個需要代理的目標。也要區分測試結果的含義：伺服器的 Tcping 可連通，不代表路由規則或目標網站也能正常使用，詳情請參閱延遲測試結果說明。保留簡單且容易理解的規則，通常比堆疊多組互相覆蓋的規則更容易維護。

04 DNS 解析路徑與設定調校

DNS 問題不只是選擇一台解析伺服器就能解決。瀏覽器、作業系統、代理核心與遠端伺服器都可能參與網域解析。第一步要釐清「哪個元件正在解析哪個網域」。若瀏覽器啟用了自己的加密 DNS，系統 DNS 設定未必會影響它；若網域透過代理傳送，本機可能不必先取得目標位址。只有將解析位置與連線位置納入同一張路徑圖，設定才有意義。

區分伺服器網域與目標網域

代理伺服器本身若使用網域名稱，建立連線前就必須先取得其位址；這一步不能依賴尚未建立的同一條代理通道。目標網站的網域則可依設定交由本機核心或遠端處理。常見的循環問題是：DNS 要求必須經由代理傳送，但代理伺服器的網域又必須先透過該 DNS 解析。若啟動後所有要求都停滯，先檢查這種先後依賴關係，不要只延長逾時時間。

在「設定」中找到 DNS 相關選項，先確認目前使用的核心與可編輯欄位。v2rayN 可能分別管理不同核心的 DNS 設定；名稱相近不代表設定結構相同。使用內建範本時，先保留範本的基本結構，只修改確實需要調整的上游伺服器與規則。若直接整份覆蓋成網路上的 JSON，可能一併刪除用戶端產生的本機監聽、路由關聯或 TUN 所需設定。

解析策略必須符合網路環境

以下展示 Xray 內建 DNS 的欄位片段，使用位址格式的上游伺服器，目的是說明 servers 與 queryStrategy 的位置。該上游能否直接連線，仍取決於本機網路；這段設定也不會自動將作業系統的所有 DNS 要求轉交給核心。實際使用時，應配合可信任的解析服務、網路需求及完整路由設定，不要將範例視為通用的最佳設定。

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

UseIP 允許取得兩種位址；若只查詢其中一種位址家族，會影響目標的可達路徑。若本機沒有可用的對應網路，卻優先取得無法使用的位址，可能會先等待一段時間才成功開啟。反之，強制只查另一種位址也可能導致依賴特定網路的服務失效。請先確認實際網路介面、預設路由及目標支援情況，再考慮縮小查詢範圍。

一般 DNS、加密 DNS 與透過代理傳送是不同概念。加密解析可以保護解析過程中的傳輸，但不會自動決定網站連線使用哪個出口；把 DNS 位址加入清單，也不代表查詢一定會透過代理連線傳送。使用加密上游時，還要考慮上游網域本身如何解析與連線。檢查設定時，應同時確認 DNS 上游、解析要求的輸出路徑，以及目標要求的輸出路徑。

分別處理內部網域與公開網域

企業或家庭的內部網域可能只有本機解析伺服器知道。若一律交由公共解析服務處理，可能會得到不存在的結果，或與內部網路無關的位址。請為明確的內部網域後綴指定本機可連線的解析路徑，同時保留區域網路直連規則。有些印表機或裝置探索功能使用區域網路名稱探索機制，單純修改公共 DNS 無法解決這類問題。

驗證 DNS 變更時，請考慮多層快取。作業系統、瀏覽器與核心可能各自保留解析結果；關閉舊連線並重新啟動相關應用程式後再測試，必要時使用系統提供的快取清除功能。系統查詢工具顯示的結果，只代表該次查詢經過的解析路徑，不一定等同代理核心使用的結果。比較測試時，請註明使用哪個查詢入口。

設定最佳化應有明確目標，例如讓內部網域回傳正確結果、減少無效的位址家族嘗試，或排除解析依賴循環。只因單一網頁開啟較快就更換整套 DNS，容易把快取差異誤當成設定改善。每次修改後，請使用相同的應用程式、目標與接管方式，並確認記錄檔中的解析錯誤是否確實消失。

05 TUN 模式與系統接管

TUN 透過虛擬網路介面接收系統封包，適合需要接管不遵循系統代理設定之應用程式的情況。它不是「增強連線」的按鈕，也無法修復失效的伺服器參數。啟用前，請先完成系統代理下的基本驗證，並記錄目前的網路介面、其他通道軟體與區域網路連線狀況。這樣發生問題時，才能判斷是原有連線路徑失敗，還是新增的系統接管層改變了流量路徑。

權限與介面是第一步檢查項目

在 v2rayN 主視窗找到「啟用 Tun」控制項，先查看「設定」中的 TUN 相關參數，再依用戶端提示啟動。Windows 可能需要管理員權限或相關服務支援；macOS 與 Linux 也可能需要系統授權及操作介面的權限。不要直接套用其他平台的驅動程式處理方式。安裝入口與平台資訊請見用戶端下載頁，實際需求以目前使用版本的提示為準。

啟用後，先查看記錄檔是否顯示介面成功建立、路由是否成功新增。若出現權限不足、介面建立失敗或裝置遭占用，先排除啟動階段的問題，再測試網站。此時反覆切換伺服器幫助不大，因為流量可能尚未進入核心。若介面已成功建立，但所有連線都失敗，再檢查預設路由、DNS，以及伺服器位址是否經由正確介面傳送。

避免多個接管工具爭用相同路徑

其他虛擬私人網路、虛擬機器網路、容器橋接及安全軟體，都可能改變介面優先順序或路由。排查時不要同時執行多套全域接管方案。先退出暫時不需要的接管工具，再重新啟用 TUN；若環境必須並存，應分別釐清哪些目標要走哪條路由。只看工作列圖示無法確認程式已退出，必要時請到系統網路設定確認介面與路由狀態。

依設定需求，系統代理與 TUN 可以同時啟用，但初次測試最好只驗證一種接管方式。否則瀏覽器可能先將要求送至本機代理，再由系統路由處理，讓流量路徑更難判讀。除非確實理解完整連線流程，也不要自行將本機代理連接埠設為另一層代理的上游；錯誤的回送設定可能造成連線循環並占用資源。

一併驗證區域網路與名稱解析

啟用 TUN 後，應測試路由器管理頁、區域網路共用資源及內部服務網域。連線失敗可能是目標位址被錯誤送往代理，也可能是內部網域改由公共 DNS 解析。前者請檢查區域網路位址規則與系統排除路由；後者請回到 DNS 章節排查。不要為了修復單一裝置就將整個位址範圍設為直連；先確認實際子網路與目標位址，並保持例外範圍明確。

接管預設路由時，也要避免代理連線繞回虛擬介面。用戶端通常會產生相應的保護規則，但多張網路卡、網路切換或自訂設定都可能改變條件。若啟用後伺服器連線立即逾時，且關閉 TUN 後恢復，應優先檢查伺服器目標的出口與實際網路介面。先還原用戶端預設 TUN 設定進行驗證，再逐項恢復自訂參數。

行動裝置的接管機制與桌面虛擬介面並不完全相同。v2rayNG 與 v2flyNG 使用 Android 系統的連線授權機制，其他同類接管應用程式也可能占用相同位置；背景省電限制則可能造成連線中斷。分應用程式代理決定哪些應用程式納入接管範圍，與桌面路由規則並不相同。授權與背景設定的詳細說明請見Android 連線授權與分應用程式代理說明。

關閉後確認系統已恢復

完成驗證後，請依正常程序關閉 TUN，並確認介面、路由與解析狀態是否恢復。若用戶端異常結束後網路仍不正常，先重新啟動用戶端，再正常停止接管，接著檢查是否殘留系統代理設定；必要時透過系統網路設定還原原狀。不要直接刪除無法辨識的介面或路由。切換無線網路或從休眠狀態恢復後也應重新測試，因為實際介面變動可能使舊的接管狀態失效。

TUN 驗收至少應包含四項：原本可用的網頁仍能開啟、不遵循系統代理的目標應用程式可以連線、區域網路存取符合預期，以及關閉接管後一般網路恢復正常。任何一項未通過，都應還原至已知可用的設定基準，再依序檢查介面、路由、DNS 與輸出。遵循這個順序，比反覆修改底層參數更容易找到可重現的原因。

06 FakeDNS 與網域對應

收到網域查詢時，FakeDNS 可以回傳專用位址池中的合成位址，並記錄網域與該位址的對應關係。應用程式隨後連線至該位址，接管鏈路便可據此找回網域。它的主要用途是讓後續路由保留網域資訊，不是替網站配置新的真實位址，也不會讓原本無法連線的伺服器變得可用。最後仍須由正確的輸出處理實際連線。

必須在同一條鏈路中完成對應

使用 FakeDNS 至少需要三個環節互相配合：查詢確實進入合成位址服務、回傳位址經由系統路由送回接管器，以及核心能在連線過程中還原對應網域。只開啟其中一項，可能導致應用程式取得合成位址後，卻經一般網路直接送出連線。排查時應檢查完整鏈路，不要只因查詢結果落在位址池範圍，就認定功能已正常運作。

Xray 的 FakeDNS 與其他核心的合成位址機制，各有不同的設定結構。v2rayN 的 TUN 可能使用與目前代理連線不同的核心元件，因此不能只根據主視窗選用的伺服器核心，就推定 TUN 設定也採用相同語法。先確認正在編輯哪一層設定，再檢查用戶端是否提供相符範本；若有受支援的介面選項，優先讓用戶端產生相應欄位。

了解位址池與容量欄位

以下是 Xray 頂層 fakedns 欄位片段，僅用來說明位址池與容量的寫法。198.18.0.0/15 屬於特殊用途範圍，不是公開網站的真實位址。此片段沒有設定 DNS 查詢入口，也未完成接管與網域還原，不能單獨作為可執行的用戶端設定。合併前請確認自己的網路沒有將此範圍用於內部服務。

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

ipPool 指定可分配的位址範圍，poolSize 則控制對應池的容量。增加容量不是通用的加速方法，也不會改變遠端頻寬；它影響維護對應關係所需的資源與可容納的項目數。若網路環境長期存取大量不同網域，請觀察實際運作情況，不要任意設定成極大值。調整位址池也會影響已由應用程式快取的舊結果。

相容性問題通常出在繞過接管與快取

部分應用程式會自行使用加密 DNS，查詢可能因此繞過 FakeDNS，接著直接連線至真實位址。另一些應用程式會將解析結果交給未經接管器的子程序，導致合成位址無法還原。也有應用程式會檢查解析位址類別，因而不接受特殊用途範圍。遇到這些狀況，應為相關應用程式或網域保留真實解析路徑，同時確認路由例外，而非不斷更換位址池。

處理內部網域時通常要格外謹慎。若某個網域用來連線本機裝置，回傳合成位址後又被送往不適合的代理出口，區域網路存取就會失敗。先確認內部名稱是否需要真實位址，以及是否由本機 DNS 回應，再設定對應的排除規則。合成位址排除、DNS 上游選擇與區域網路直連屬於不同層次，不能只修改其中一項就認定其他兩項會自動配合。

透過對照測試判斷是否需要保留

驗證時請固定使用相同伺服器、路由與應用程式，比較一般解析及 FakeDNS 兩種狀態。觀察網域規則是否能穩定命中、目標連線是否成功，以及區域網路是否維持正常。不要只比較單次頁面載入時間；快取、連線重用及伺服器負載都可能影響結果。若此功能沒有解決明確問題，反而增加相容性分支，保留一般解析通常更容易維護。

查看記錄時，應關注網域能否還原，以及輸出選擇是否符合預期，而非只注意合成位址本身。對應資訊可能屬於執行階段狀態，重新啟動核心後不要假設舊對應仍然存在。應用程式若長時間保留舊結果，可能只在重新啟動後才出現連線失敗；請先讓應用程式重新解析，再判斷是否需要修改設定。

一般 DNS、TUN 與路由都穩定後，再考慮加入 FakeDNS。依照這個順序操作，發生異常時只需回退新增的層次。若目前版本沒有明確支援的設定入口，也沒有完整的配套設定說明，就不要將其他核心的設定片段硬塞進範本。先保留容易理解的真實解析路徑，再依明確需求決定是否繼續測試。

07 多訂閱管理與更新策略

同時使用多個訂閱來源時，管理重點是來源可追溯、更新可控制、故障可隔離。不要將所有伺服器複製到一個沒有來源標記的分組；清單看似統一，更新失敗後卻難以確認哪些項目已失效。建議每個來源各自使用獨立分組，另設手動設定分組；備註只記錄用途與維護資訊，訂閱網址則保留在專用欄位。

分別設定更新範圍與更新路徑

先決定要更新目前分組還是所有分組，再選擇用戶端提供的更新方式。有些來源可在直接連線的環境下取得，有些則需要透過目前可用的代理存取；這會決定更新要求本身的網路路徑，不會決定更新後伺服器的預設路由。切換更新方式前，請確認用來取得訂閱的現有連線仍有效，否則可能陷入「必須先有新伺服器才能更新舊伺服器」的循環。

若主要訂閱失效，而更新又必須透過該訂閱中的目前使用伺服器，請改用已驗證可用的備用連線，或依來源允許的方式直接取得資料。不要把尚未驗證的項目當成復原工具。至少保留一個可以獨立驗證的備援方案，並記錄其來源與有效條件。備援方案的價值在於減少依賴，而非堆積更多名稱相似的伺服器。

避免頻繁更新與重複匯入

訂閱更新不是連線重試按鈕。來源沒有變更時，連續重新整理通常只會重複取得同一批參數，也可能觸發來源端的頻率限制。自動更新間隔應依來源說明與實際變更頻率設定，手動更新則用來確認參數是否變更。若連線失敗，先判斷錯誤類型：驗證失效、遠端逾時與訂閱取得失敗是不同問題，不能靠同一個更新動作處理。

同一來源若重複新增，清單可能出現重複項目。清理前先確認分組網址是否相同、是否使用不同用途的篩選條件，以及目前使用的伺服器屬於哪一份。名稱重複不代表內容完全相同，伺服器位址、傳輸方式與驗證參數也可能不同。不要只依顯示名稱批次刪除；先保留已知可用的項目，再逐組整理。

為手動修改保留獨立範圍

訂閱項目由來源維護，更新時可能覆蓋本機修改。若確實需要調整傳輸參數、伺服器位址或顯示備註，請先複製到手動分組，並註明修改對象。日後來源參數變更時，手動副本不一定會同步，應定期參照來源說明檢查。將手動副本與訂閱項目分開，既能避免修改遭覆蓋，也能提醒維護者這筆資料需要額外的本機維護。

完整的維護流程應有固定順序：先備份目前設定、更新單一來源、檢查項目是否合理、驗證目前使用的伺服器，最後再處理其他分組。不要更新所有來源後立刻批次去重、修改篩選條件並切換路由。將操作拆開後，即使某個來源回傳異常內容，也能清楚判斷是哪個步驟造成變更，不會讓整份伺服器清單同時陷入未知狀態。

有備用項目不代表會自動切換

分組中有多筆項目，不代表用戶端會自動選出可用伺服器。目前使用的伺服器、路由綁定的出口，以及可能存在的選擇策略都需要分別確認。有些測試只表示交握可連通，無法證明實際目標也能正常存取；下載測速也只反映特定時間的傳輸量。測試方式的限制可搭配閱讀Tcping 與實際連線延遲說明。

管理完成後，留下簡短的維護紀錄：哪些分組更新成功、哪些暫緩、目前使用的伺服器是否重新驗證，以及手動副本是否需要後續處理。紀錄只需寫狀態，不要抄入敏感資料。如此下次遇到問題時，就能從上次確認的狀態繼續處理，不必再次整理整份清單。更新失敗時，仍依取得、解析、篩選、顯示四個階段排查，不會因訂閱數量增加而改變。

08 自訂輸出與設定還原

圖形介面的現有選項無法表達需求，而且維護者能說明完整連線流程時，才適合使用自訂輸出。先釐清目標：是為某類目標建立獨立的直連出口，還是需要更複雜的轉送關係。若只需要讓單一網域直連，優先使用路由編輯器，不必替換整份設定。自訂設定提高了彈性，也代表欄位相容性、標籤引用與更新維護都要由使用者自行負責。

先確認設定檔的用途與來源

在 v2rayN 中，一般伺服器項目通常由用戶端產生執行設定；自訂設定則可能保留更多原始結構，不能假設兩者具有完全相同的介面連動能力。使用「伺服器」選單中的自訂設定入口前，請先確認需要匯入完整檔案，還是引用現有檔案，並選擇相符的核心類型。檔案能夠匯入，不代表目前核心支援其中所有欄位。

編輯前先複製一份已知可用的檔案，並在副本上操作。Xray 與 V2Fly 有一些共通概念，但具體欄位及擴充能力仍須分別確認；其他核心的輸出類型與路由結構也不能直接互換。先檢查頂層欄位、入口監聽與輸出標籤，再新增功能。若一開始就覆蓋用戶端產生的入口，系統代理可能仍指向舊連接埠，導致整個用戶端無法使用。

透過最小範例理解標籤引用

以下 Xray 片段定義一個直連輸出與一個拒絕輸出，並讓範例網域使用拒絕出口。內容只包含 outbounds 與 routing，沒有本機監聽設定，因此不是完整的執行設定。合併時應保留現有代理輸出與必要規則，並避免覆蓋同名標籤。此範例用於說明引用關係，不需要實際封鎖自己的業務網域。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "reject",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "reject"
      }
    ]
  }
}

此處的 outboundTag 必須與輸出的 tag 完全一致。顯示名稱與標籤是不同概念，大小寫或拼字不一致都可能導致引用失效。在常見的 Xray 設定中，未符合規則的流量會使用第一個輸出，因此調整陣列順序也可能改變預設行為。合併片段時，不只要檢查新增規則，也要重新確認原本的預設出口是否維持不變。

設定複雜轉送前，先畫出相依關係

需要多層轉送時，先用文字釐清本機入口、第一跳、後續連線與最終目標之間的相依關係。每個伺服器網域由誰解析、每條連線透過哪個輸出建立，都應該能個別說明。不同核心實作鏈路轉送的欄位各不相同，不能只憑「上游代理」幾個字就套用設定。若鏈路中的任一跳又依賴自己，就可能形成遞迴連線或導致服務無法啟動。

設定檔應先檢查 JSON 語法，再確認核心語意。JSON 不允許註解或末尾多餘的逗號；字串中的反斜線與雙引號也必須正確處理。通過語法檢查後，仍可能遇到欄位不受支援、標籤不存在或規則資料缺漏等問題。查看用戶端記錄檔中的第一筆有效錯誤，先修正啟動失敗原因，再處理後續連線資訊，避免被重複錯誤淹沒。

以能否還原作為驗收條件

成功啟動後，先測試最基本的目標，再測試原本可用的一般連線與區域網路連線。記錄檔應顯示流量經由預期的輸出，而不是單純沒有錯誤訊息。若自訂方案取代原有設定，關閉系統代理或 TUN 後，也應檢查本機連接埠是否仍有殘留設定。還原原方案必須有明確的操作步驟，不可只靠臨時記憶幾個開關。

更新用戶端或更換核心後，應重新驗證自訂欄位與預設行為。先保留原本可用的方案，再於副本上進行移轉；不要直接在唯一的設定檔上套用新範本。若需求能透過圖形化路由、DNS 設定或分組管理重新表達，可改回由用戶端管理的方式，減少需要手動同步的內容。自訂設定應用來解決明確需求，而不該變成維護本身的目的。

本頁的閱讀順序也是排錯順序：先確認伺服器與入口，再檢查路由和解析，最後處理 TUN、FakeDNS 及自訂鏈路。基本操作請回到快速入門教學，常見狀況請查閱常見問題，用戶端選擇與安裝資訊請見下載頁。務必保留一組已驗證可用的設定，讓下次調整有可靠的比較基準。