V2Ray 進階設定指南

訂閱分組與伺服器篩選

訂閱分組用來管理伺服器來源與更新範圍；伺服器篩選則決定清單中顯示哪些項目，兩者都不等同於流量分流。一個分組可以包含多台伺服器，但日常連線仍由目前啟用的伺服器負責；切換分組標籤也不一定會切換啟用中的伺服器。了解這項差異，才能避免看到另一組清單，就誤以為連線已切換。

建立可追溯的分組

在 v2rayN 的「訂閱分組」選單新增分組，先填寫便於辨識來源的備註，再貼上完整訂閱網址。網址通常包含存取憑證，備註只寫來源或用途，不要複製網址中的參數。確認前後沒有多餘空格或換行，儲存後只更新這個分組。首次更新時，先查看記錄是否完成，再確認清單中有項目；不要同時啟用自動更新、篩選和大量刪除。

分組名稱適合採用「來源＋用途」的格式，例如工作訂閱、行動網路備用。伺服器別名來自訂閱內容，後續更新時可能被改寫，不宜把手動改名當作長期分類依據。若要保留個人備註，優先使用客戶端支援的獨立備註欄位，或另行記錄。手動匯入的伺服器最好獨立分類，避免與訂閱項目混在一起而誤判更新結果。

更新時要分清楚是直接連線取得，還是透過代理取得。既有連線正常但直接更新失敗時，可以嘗試選單中的「透過代理更新訂閱」；若是首次設定、尚無可用連線，就不能預期代理更新一定能解決問題。先確認錯誤是解析失敗、連線逾時，還是伺服器拒絕要求。反覆更新無法修復已失效的網址，還可能觸發來源端的請求限制。

先確認清單，再新增篩選條件

主視窗的搜尋或篩選通常只會縮小目前顯示範圍；分組編輯中的伺服器篩選則可能影響更新時保留哪些項目。實際行為請以設定項目的說明為準。開始篩選前，先選取「全部」、清除搜尋條件，確認目標項目確實存在。接著進入目標分組，用一個簡單關鍵字測試，避免疊加多個條件後無法判斷是哪項設定排除了伺服器。

若輸入欄位明確支援正規表示式，豎線代表候選項目，括號可用來分組，句點預設可匹配任意字元。以下表示式適合篩選別名包含這兩種用途詞的項目，僅供示範篩選語法。若欄位只接受一般關鍵字，就應分別搜尋，不要直接輸入正規表示式符號。大小寫是否有差異，也應用已知項目實際測試。

(工作|備用)

訂閱更新後清單變空，先清除顯示篩選，再檢查分組篩選，最後確認來源回傳的內容。畫面空白不代表遠端訂閱沒有內容。伺服器清單中的類型、位址、連接埠與傳輸設定必須一併保留，不能只憑別名判斷重複；名稱相同的兩個項目可能使用不同傳輸方式。清理前先記下目前啟用的伺服器，避免刪除唯一可用的測試項目。

更新後的確認與還原

伺服器篩選只會依描述資訊縮小範圍，不會測試連線，也不代表會自動選擇最快的線路。更新完成後，請對保留的項目執行「測試伺服器真實連線延遲」或相應的測速功能，再手動設為啟用中的伺服器。測試結果會受目前網路、測試目標與伺服器狀態影響，應參考相同網路下的多次結果及實際服務連線狀況。

若更新取代了原有項目，客戶端可能無法保留舊的啟用選擇。此時請重新選擇伺服器、重新載入設定，再查看記錄確認核心是否成功啟動。不要直接拿舊測速結果比較新項目；別名相同不代表連線參數未變。測試失敗時，先切回已知可用的分組，確認基本連線正常，再處理更新後的清單，不要同時修改路由與解析設定。

Android 版 v2rayNG 與 v2flyNG 的訂閱入口、分組顯示和篩選功能不盡相同，不宜直接照搬桌面版的正規表示式操作。可先依來源管理訂閱，再從清單選取設定。匯出設定或分享螢幕截圖前，請移除訂閱網址、伺服器憑證及可識別帳號的備註；訂閱連結應視同帳號憑證管理，不宜放入公開筆記或問題截圖。

路由規則實作

路由規則決定進入核心的連線要使用哪個出站，但不會自動將所有應用程式流量送進核心。系統代理只影響遵循代理設定的應用程式；TUN 則從網路層接入更多連線。因此，若瀏覽器能依規則分流，另一個程式卻沒有變化，請先確認該程式是否進入代理鏈路，再檢查規則。否則可能會把流量接入範圍的問題，誤判為網域匹配錯誤。

從預設值建立基準

在 v2rayN 的路由設定中，先記下目前的預設值，再選擇「繞過中國大陸 (Whitelist)」、「黑名單 (Blacklist)」或「全域 (Global)」作為起點。預設名稱只是選項入口，實際行為取決於規則內容、預設出站與規則庫。全域模式也不一定會涵蓋本機位址等所有例外；需要精確判斷時，應查看產生的路由內容，不要只憑模式名稱推測。

規則通常依序比對，符合後便使用指定的出站。先將區域網路及必要的明確例外放在前面，再放較廣泛的集合規則，最後確認未符合任何規則的流量會前往何處。同一條規則中同時填入網域、連接埠和網路類型，通常表示這些條件必須同時符合，而不是任選一項即可。只想依網域分流時，不要順手加上無關的連接埠限制。

以下是 Xray 格式的路由片段，假設完整設定中已存在名為 direct 與 proxy 的出站。第一條規則讓私有位址直連；第二條則讓指定網域及其子網域透過代理連線。範例網域僅用來說明語法，實際使用時應換成明確的業務網域。此片段未定義預設出站，也未提供連線憑證，無法單獨啟動。

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

網域、位址與規則庫

full: 用於完全符合網域，domain: 用於指定網域及其子網域，geosite: 引用網域集合，geoip: 引用位址集合。直接填入一般字串可能採用關鍵字匹配，涵蓋範圍往往比預期更廣。精確的業務例外優先使用完整網域；確實需要涵蓋子網域時，再使用網域後綴方式，減少誤判其他網站的可能。

網域規則需要核心取得目標網域。應用程式透過代理提交網域時，通常可直接比對；若應用程式先解析，再只提交位址，可能就需要嗅探或其他網域對應機制。嗅探也無法從所有協定中還原網域。若同一網站在不同應用程式中符合不同規則，先比對記錄中的目標格式：一個可能是網域，另一個可能只有位址；不要急著擴大規則集合。

AsIs 不會為了路由比對而主動解析目標網域；其他網域策略可能在未符合規則或需要比對位址時觸發解析，實際行為請以核心文件為準。解析出的位址也可能受快取和網路位置影響，因此單純改用位址匹配不一定更穩定。對於網域明確的業務，盡量使用網域規則；只有確實需要依目標網路範圍處理時，才增加位址條件。

規則庫檔案必須與規則語法相容。可透過客戶端提供的更新功能取得所需資源；更新後仍應查看記錄，確認資源載入成功。集合名稱不存在、資源檔無法讀取或選錯核心，都可能導致設定無法啟動。不要將其他核心的規則檔直接改名使用。集合更新方式及常見寫法請參閱GeoIP 與 GeoSite 規則庫說明。

用可觀察的結果驗證

修改後先重新載入，再用一個目標網站測試，並檢查存取記錄中的目標、符合的規則或出站標籤。瀏覽器已建立的長連線可能仍沿用舊路徑，請關閉相關分頁或重新啟動應用程式後再測。每次只更動一條規則；若同時更新規則庫、切換伺服器並修改 DNS，即使問題消失，也無法判斷是哪項變更生效。

本機印表機、檔案共享或內網管理頁面無法正常存取時，先確認私有位址是否在廣泛的代理規則之前設為直連，再檢查應用程式是否被另一層代理接管。使用內部解析器解析網域的環境，也要確認 DNS 能回傳內網位址。路由正確但解析錯誤，連線仍會前往錯誤目標；因此路由與下一章的 DNS 需要一併檢查，但應分開逐輪修改。

DNS 設定最佳化

設定 DNS 前，先釐清三件事：由誰發出查詢、查詢經過哪條路徑，以及結果由誰快取。系統解析器、瀏覽器的安全 DNS 與代理核心內建解析器可能同時存在。只修改客戶端的 DNS 位址，不代表所有應用程式都會改用該位址。排查時先理清請求路徑，再處理逾時、結果不一致或內網網域失效，避免盲目增加解析伺服器。

確認解析發生在哪一層

透過代理提交網域的應用程式，可以將解析交給代理鏈路處理；先在本機解析、再連線至位址的應用程式，則已在進入核心前完成一次查詢。TUN 模式也可能透過 DNS 接管，將系統查詢導入核心。瀏覽器自行啟用的加密解析通常又是另一條獨立路徑。若瀏覽器與命令列的結果不同，應分別確認兩者的解析設定，而不是直接認定其中一方用了錯誤的伺服器。

先保留客戶端的預設 DNS 方案，使用可連線的伺服器建立基準，再依需求一次增加一項變更。例如，內網名稱只有組織內部解析器能辨識，就必須保留該解析路徑；一般公網查詢則可使用目前網路可連線的解析服務。不同網路對公用解析服務的連線條件不同，沒有一個位址適用於所有環境。最佳化的重點是結果正確、路徑穩定，而不是解析項目越多越好。

以下為 Xray 內建 DNS 的最簡欄位範例，只展示伺服器清單與結果類型，不包含 DNS 接管規則，也不保證系統查詢會進入該解析器。使用數值位址可避開解析伺服器本身網域的引導解析問題，但查詢是否直連或經過代理，仍須依路由與核心行為確認。請先在目前網路環境測試連線能力，再決定是否採用。

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

分網域解析與引導解析

內網網域、公網業務網域與代理伺服器位址，可能需要不同的解析策略。將內網網域交給公用解析器通常無法取得預期結果；若代理伺服器位址必須依賴尚未建立的代理才能解析，就會形成啟動依賴。請先確保伺服器位址有獨立可用的引導解析，再處理一般流量的解析分流。切換網路後尤其應重新驗證這條啟動路徑。

使用網域型加密解析服務時，必須先取得該服務網域所對應的位址，這個步驟就是引導解析。若引導解析也指向同一個尚未可用的服務，就可能陷入循環等待。有些客戶端提供專用的引導設定項目，有些則交由核心或系統處理，不能一概套用相同欄位。儲存設定後，請從記錄區分「無法解析解析器網域」與「目標業務網域查詢失敗」，兩者的修復位置不同。

解析規則應與流量路由保持一致。預計直連的業務若使用與目前出口相距甚遠的解析位置，可能取得不合適的內容傳遞網路位址；預計透過代理存取的業務，也可能因解析位置不同而出現服務區域判定差異。這並沒有必然的速度優劣，應比較同一業務的連線建立、頁面資源載入與持續存取狀況，而不只是單次查詢耗時。

IPv6 應依實際網路路徑決定。系統有 IPv6 位址，不代表前往目標伺服器的 IPv6 路徑一定可用；同樣地，停用所有 IPv6 也不是通用的最佳化方式。若記錄顯示持續嘗試無法連線的位址族，再調整解析結果策略或出站策略。先確認系統路由與網路支援狀況，避免只隱藏解析結果，應用程式自行解析後卻仍選用另一個位址族。

快取與故障排查

DNS 結果可能快取在系統、瀏覽器與核心中。變更設定後，重新啟動相關應用程式與核心，再用相同目標重測；必要時使用系統提供的快取清除方式。命令列查詢只代表該命令採用的解析路徑，不一定等同瀏覽器或經代理發出的請求。比對記錄時，請記下目標網域與測試時間，不要混合比較不同層級快取的結果。

「網域無法連線、位址可以」只能提醒你檢查解析，不能據此直接判定是 DNS 故障。使用位址存取 HTTPS 可能改變憑證名稱、請求主機名稱與伺服器路由，許多網站本來就不接受這種測試。較可靠的順序是先確認查詢是否成功、回傳結果是否合理、目標連接埠是否可連線，最後再檢查應用程式協定層的錯誤，並保留完整的錯誤類別。

路由策略改為需要比對位址後，原本不明顯的 DNS 問題可能立刻浮現，因為連線開始依賴本機解析。此時先還原原本的網域策略，確認基本連線正常，再單獨修復 DNS。不要同時啟用 FakeDNS 來掩蓋狀況；FakeDNS 需要額外的映射與接管條件，適用範圍請參閱後文。其他啟動與連線問題，可依常見問題中的分類繼續排查。

TUN 模式設定

TUN 模式透過虛擬網路介面與路由，將更多應用程式的連線交由代理處理，適合不讀取系統代理設定的程式。它改變的是流量接入範圍，不會自動提升連線品質，也不代表所有流量都必須走同一個出口。接管後的直連、代理與阻擋仍由路由決定。啟用前，請先確認一般代理模式可以正常連線，避免同時處理伺服器故障與網路接管故障。

權限、核心與接管範圍

在 v2rayN 主視窗啟用「啟用 Tun 模式」前，先確認目前客戶端是否具備所需權限。Windows 可能需要提高權限，或透過客戶端支援的服務方式執行；其他桌面系統也可能需要授權，以建立網路介面並修改路由。請依目前的安裝方式授予權限，不要將反覆以高權限啟動當作長期排錯方法。記錄中應能確認介面與路由是否成功建立。

桌面客戶端可能會使用不同的執行元件來提供 TUN 功能，實際欄位不一定與一般代理核心相同。請查看啟用後的執行記錄與產生的設定，確認由哪個元件負責接管與出站。不要把 Xray 的 JSON 片段直接貼到另一種 TUN 設定格式中。若介面操作正常，但記錄回報未知欄位，請先還原預設範本，再確認設定格式與執行元件是否相容。

Android 客戶端通常透過系統 VPN 服務接管應用程式流量，首次連線時需要確認系統授權。個別應用程式設定會決定哪些應用程式納入或排除，並應確認清單採用的是「代理所選應用程式」還是「略過所選應用程式」。這不等同於桌面版「啟用 Tun 模式」開關的逐項對應設定。若同時執行另一個占用系統 VPN 服務的工具，也可能互相衝突或取代連線。

先排除迴圈，再驗證分流

TUN 建立後，代理程序連線至伺服器的流量必須能避開自身接管，否則會形成迴圈。客戶端通常會自動處理相關路由或排除程序，但自訂範本、額外網卡或另一個隧道都可能破壞這項前提。常見狀況包括啟用後伺服器也無法連線、記錄反覆嘗試，或所有要求都逾時。請先關閉 TUN，恢復基本連線，再檢查出口路由，不要繼續擴大代理範圍。

存取區域網路時，路由與解析都要一併檢查。能連上公網，卻無法開啟印表機或內部服務時，請確認私有位址是否設為直連、內部網域是否使用正確的解析器，以及區域網路路由是否被範圍更大的接管規則覆蓋。不要將整段本機網路送進遠端代理來試錯。若確實需要存取遠端私有網路，應辨別本地同名位址區段，避免位址範圍重疊而無法判斷目標。

首次驗證可分為三個步驟：先開啟已知正常的網頁，再測試原本不遵循系統代理的應用程式，最後檢查區域網路與內部網域。同時確認流量確實進入客戶端，而非只看工作列圖示變化。若同時啟用了系統代理，瀏覽器連線成功仍可能是沿用舊路徑；記下原本狀態後，可暫時關閉系統代理，單獨驗證 TUN 是否成功接管。

UDP、路徑 MTU 與退出後還原

應用程式流量進入 TUN，不代表所有協定都能透過目前的伺服器傳輸。語音、遊戲與部分傳輸會使用 UDP，還需要客戶端、核心、伺服器與網路鏈路共同支援。網頁正常但即時通訊失敗時，請檢查 UDP 支援與相關記錄，不能只憑網頁測試結果推斷。部分應用程式也會選用不同傳輸協定，測試時應維持設定一致，避免將協定切換造成的差異誤認為路由問題。

少數網站能建立連線，卻在傳輸大型資源時卡住，可能與路徑 MTU 有關，也可能是封包遺失、協定或伺服器問題。不要直接套用固定的 MTU 數值。先換用已知可用的伺服器，比較關閉 TUN 後的情況，再根據記錄與網路診斷縮小範圍。只有證據指向分段或路徑問題時才調整相關參數，並記下原值；否則只會增加難以追蹤的變因。

退出時先關閉 TUN，再離開客戶端，並確認一般網路與系統 DNS 已恢復。若異常發生在休眠喚醒或切換網路之後，重新建立接管通常比立即修改設定更合理。仍無法恢復時，檢查是否有殘留的介面、路由或其他網路接管服務。不了解用途時，不要大量刪除系統路由；組織網路中的路由可能由管理政策維護。

Android 背景斷線時，還應檢查電池最佳化、背景執行限制與個別應用程式代理設定，不要照搬桌面版的網路修復指令。是否維持連線或節省電力，應依實際使用需求取捨；詳情請參閱v2rayNG 背景執行與耗電排查。完成測試後，保留一種穩定模式，避免多個接管工具同時隨開機啟動。

FakeDNS 映射機制

FakeDNS 會以合成位址暫時代表網域，並在後續連線進入核心時還原網域，以保留分流所需的網域資訊。這不是遠端伺服器的真實位址，也不是額外的加密協定。適用情境是應用程式先查詢 DNS，之後只用位址連線，但代理仍需要依網域匹配規則。若一般解析與路由已符合需求，就不必為了增加設定項目而啟用。

查詢與連線必須完整串接

完整流程如下：應用程式查詢網域，查詢交由 FakeDNS 處理，應用程式收到合成位址，接著連線至該位址，而連線再交回掌握映射資訊的核心。任何一個環節缺失，都可能出現「解析有結果，卻無法連線」的狀況。尤其要確認應用程式的 DNS 沒有繞過接管，且合成位址範圍不會被直連規則提前放行。只設定位址池，卻沒有查詢入口，不會自動生效。

以下是 Xray 格式的欄位片段，展示合成位址池、DNS 伺服器選擇與入站嗅探之間的關係。其中 198.18.0.0/15 來自保留的效能測試位址範圍，並非公網伺服器位址。此範例只說明 IPv4 映射，未展示完整的入站、出站與 DNS 轉送規則。實際合併位置應依目前客戶端產生的設定結構決定。

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

需要還原映射的相應入站，也必須設定可識別 FakeDNS 的嗅探功能。下方物件是入站內部的 sniffing 欄位範例，並非頂層設定。不支援這些欄位或採用其他設定格式的執行元件，無法直接使用此範例。請先確認核心支援，再檢查客戶端是否已自動產生等效設定，避免手動重複新增。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"]
  }
}

位址池、快取與相容性

ipPool 定義可分配的合成位址範圍，poolSize 控制映射容量。位址池必須與實際網路及其他隧道使用的範圍區隔，不可任意以正在使用的區域網路位址區段取代。預設保留範圍也不保證絕對不會衝突：測試環境或其他網路產品可能使用相同範圍。發生衝突時，先確認位址歸屬與路由，不要只改一個欄位就認定整條鏈路已完成遷移。

映射只在相關核心及其執行期間有效。核心重新啟動後，應用程式可能仍快取舊的合成位址，但新的核心執行個體已沒有對應的網域記錄，於是解析看似正常，後續連線卻失敗。切換模式時，請重新啟動受影響的應用程式、清除必要的解析快取，再從新的網域查詢開始測試。長時間執行的背景應用程式尤其容易保留過期映射。

並非所有應用程式都能接受合成位址。有些程式會自行檢查位址是否可經由公網路由，有些會把結果交給另一個程序或裝置，還有些會直接固定使用數值位址。前兩種情況可能破壞映射流程；最後一種原本就沒有可供還原的網域。若只有單一應用程式異常，優先為該應用程式改用一般解析或調整接入方式，不要不斷擴大位址池；容量無法解決相容性問題。

瀏覽器自行使用加密 DNS 查詢時，查詢可能不會經過本機 FakeDNS，因此連線也不會取得這組映射。反過來說，若將合成結果分享給未使用相同接管鏈路的其他裝置，那些裝置通常無法使用。不要將啟用 FakeDNS 的本機解析結果當成一般區域網路 DNS 服務分享，也不要將合成位址複製到靜態伺服器設定中。

搭配規則、解析與回復機制

FakeDNS 還原網域後，路由仍須符合正確的出站；實際建立連線時，也可能需要進一步解析真實位址，或將網域交由遠端處理。它無法消除所有真實 DNS 查詢。尤其應為代理伺服器位址保留可用的引導解析，避免伺服器取得只能透過已啟動隧道處理的合成結果，造成啟動依賴。

驗證時先關閉應用程式，啟動支援映射的設定，再開啟應用程式連線至明確的網域。查看查詢是否進入 FakeDNS、連線目標是否落在位址池範圍內，以及核心是否還原網域並符合預期規則。若查詢沒有進入，檢查 DNS 接管；若已回傳合成位址但連線未進入，檢查路由；若連線已進入卻無法還原網域，再檢查嗅探與映射狀態。

回復時要一併還原一般 DNS、撤銷專用的接管調整，並清除使用過合成結果的應用程式快取。只關閉位址池，可能會讓程序繼續嘗試連線至舊的合成位址。回復後先用一般解析確認基本連線，再決定是否重新啟用 FakeDNS。保留啟用前的 DNS 與路由記錄，就能將還原範圍限制在這兩個層級，不必重建整份訂閱設定。

多訂閱管理流程

多訂閱管理的重點是隔離來源、控制更新並確認切換結果，而不是把所有伺服器混成一張大型清單。主要訂閱、備用訂閱與臨時測試最好分別建立群組，讓每個項目都能追溯來源。訂閱增加後，首先要維護的是設定關係：哪一組用於日常連線，哪一組只在故障時啟用，哪些項目可以隨更新替換，哪些需要手動保留。

依來源更新，依用途選擇

先為每個來源建立獨立分組，再用清楚的備註標示用途與更新方式。不要複製同一個訂閱網址建立多個用途分組來代替分類，這會增加更新要求，也會造成重複項目。若確實需要查看同一來源的不同內容，請先了解客戶端支援哪些篩選功能。來源分組維持穩定，再用搜尋或支援的篩選條件找出所需用途，通常比重複匯入更容易管理。

新增備用訂閱時，先只更新該分組，確認記錄顯示成功、清單內容合理後，再測試實際連線。不要立刻取代主要伺服器，也不要同時大量更新其他來源。如此一來，即使訂閱回傳空內容或新設定無法啟動，影響範圍仍然明確。客戶端處理更新失敗與空結果的方式可能不同，重要的手動設定應另外備份，不要依賴更新時一定會保留。

自動更新間隔應依來源實際變動頻率設定，不要把頻繁要求當成維持內容最新的方法。裝置休眠、網路切換或代理尚未啟動，都可能導致自動更新失敗。排查時先查看最近一次成功的記錄，而不是只確認是否啟用自動更新。若訂閱必須透過代理取得，也要確認它依賴哪條現有連線，避免主要連線失效後，備用清單也無法更新。

去重與啟用伺服器維護

去重時應比較連線參數，而不只是別名。相同的位址和連接埠也可能使用不同的使用者識別碼、傳輸路徑、服務名稱或 TLS 參數，因此不能隨意合併。使用客戶端的去重功能前，先了解它依據哪些欄位判斷，並保留還原方法。對於名稱相近的伺服器，先依來源保留；確認完全重複後再清理，避免誤刪仍可使用的備用參數。

訂閱更新可能改變項目順序，也可能取代原有的內部識別碼。若習慣依清單位置選擇伺服器，容易誤操作；連線前應確認目前的別名與來源。真實連線測速結果也可能在更新後失去對應關係，不能沿用舊結果替新項目排序。主要訂閱的參數變更後，請重新測試、設為啟用中的伺服器並重新載入，再確認實際應用程式能否連線。

備用訂閱不等於自動故障切換。一般的啟用伺服器選擇通常只對應一個目前的出站；只有明確設定相應的健康檢查、選擇或負載平衡策略，才可能依策略切換。不要因為清單有多個來源，就以為系統會自動接手。對大多數日常使用情境，保留一條已驗證的備用路徑，並寫清楚手動切換步驟，比導入複雜的自動化機制更容易復原。

備份、遷移與敏感資訊

備份至少應包含訂閱分組、必要的手動伺服器、路由自訂項目與 DNS 設定。請實際確認客戶端匯出功能包含哪些內容；只匯出伺服器連結，不一定會包含路由與程式偏好設定。備份檔可能含有訂閱憑證與伺服器金鑰，應存放在受控位置。遷移至其他裝置前，先確認目標客戶端支援原本的協定與傳輸方式；成功匯入檔案不代表已完成相容性驗證。

桌面版 v2rayN 與 Android 版 v2rayNG、v2flyNG 的完整程式設定不宜直接互相覆蓋。伺服器分享格式或許可以交換，但個別應用程式代理、系統代理、TUN 接管與本機目錄各有平台差異。遷移時先匯入伺服器，再依目標平台重新設定接入方式與路由。Android 背景執行策略也應重新檢查，不要直接套用來源裝置上的穩定設定。

訂閱網址失效時，應分辨是授權過期、網址已更換，還是暫時性的網路錯誤。授權問題應向原來源取得有效網址，再於原分組中替換；若是網路逾時，先檢查目前連線與更新路徑。不建議讓失效網址持續留在自動更新佇列中。更換網址後，請清除舊記錄與含憑證的螢幕截圖，避免舊連結散落在同步筆記、剪貼簿記錄或公開問題內容中。

切換網路後，先測試主要伺服器，再測試備用來源，不要立刻重新安裝客戶端。若兩個來源都在相同階段失敗，可能是本機連接埠、DNS 或接管設定有問題；若只有一個來源失敗，則優先檢查該來源的參數。啟動記錄顯示監聽位址已被占用時，請參閱本機連接埠衝突排查方法，不要為了解決無關問題而刪除所有訂閱。

自訂出站與設定驗證

出站描述核心如何將連線送往下一跳，路由則透過標籤選擇出站。常見的直連、阻斷與代理代表不同的出口行為，並非不同的訂閱分組。客戶端通常會為選取的伺服器產生代理出站，並建立輔助出站。只有介面無法設定所需結構時，才需要考慮自訂設定；日常更換伺服器或新增網域例外，優先使用現有伺服器與路由介面。

標籤與路由引用

tag 是設定中的內部引用識別碼，必須與規則中的 outboundTag 一致。標籤名稱本身沒有固定的特殊含義，寫成 direct 不會自動變成直連；實際行為取決於協定與參數。排錯時應一併檢查標籤是否存在、是否重複，以及協定是否正確。名稱拼寫不一致可能讓規則找不到目標，客戶端記錄通常會提供相關線索。

以下是 Xray 完整的本機 SOCKS 直連測試設定，只用來理解入站、規則與出站的對應關係，不提供遠端代理連線。啟動前，應停止占用相同監聽連接埠的其他執行個體，並確認僅供本機使用。所有接入要求都會明確送往直連出站，因此無法用來測試遠端伺服器，也不應誤當成現有訂閱的替代設定。

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

範例將監聽位址限制為迴圈位址，避免未經驗證的本機代理開放給其他裝置。若改成監聽所有介面，存取範圍也會隨之改變，同一網路中的裝置可能使用該連接埠。若確實需要區域網路共享，應另外設計存取控制、驗證與防火牆規則，不能只修改監聽位址。連接埠是否可用，也必須依本機實際占用情況確認。

客戶端產生設定與自訂檔案

透過圖形介面管理的伺服器，其執行設定通常由客戶端產生；直接編輯暫存的產生檔案，可能在重新載入或切換伺服器後被覆蓋。需要長期保留的規則，應寫入客戶端支援的自訂欄位；若使用完整自訂設定，則必須清楚知道哪些功能不再由一般伺服器設定管理。不要同時修改產生的結果與介面欄位，再期待兩者長期保持同步。

建立代理出站時，位址、連接埠、使用者憑證、傳輸方式與安全參數都必須來自有效設定，不能靠猜測補齊。協定名稱相同，不代表傳輸路徑、服務名稱或憑證相關參數也相同。請先在一般伺服器設定中確認連線正常，再考慮移至自訂結構。這樣可以分開處理連線參數與多出站引用問題，縮小排錯範圍。

多個出站不代表會自動串接。讓某條規則選擇備用出站，是依條件選擇出口；讓一個代理出站透過另一個出站連線，則屬於鏈式連線，須使用特定核心支援的功能與欄位。兩者無法只靠調整出站陣列順序互相取代。鏈式連線也會增加啟動依賴、延遲與故障點，應先分別驗證每一跳，再確認沒有循環引用。

預設出口也不能忽略。部分設定結構在沒有規則符合時會使用第一個出站，其他執行元件則可能使用明確的最終出口欄位。將新出站插入清單前，必須確認未符合規則的流量會前往何處。範例使用入站標籤明確指定出口，正是為了避免依清單位置推測。實際遷移時，應檢查客戶端產生的規則與自訂規則的先後順序，避免後續規則永遠無法符合。

分層測試與還原基準

驗證順序應先確認設定能否載入，再確認本機入站能否監聽，接著檢查出站能否建立連線，最後確認業務流量是否符合正確路由。語法正確只解決第一層的部分問題；未知欄位、缺少規則庫或不存在的標籤，都可能在啟動時造成錯誤。記錄出現錯誤時，先保留原始錯誤訊息與對應設定位置，不要只憑籠統提示就同時修改多個參數。

本機連接埠可連線但業務失敗時，先確認目前是否選中了正確出站，再檢查 DNS、遠端連線與應用程式協定。若透過代理測試，測試工具也必須明確指向正確的本機協定與連接埠。不要把 HTTP 代理連接埠當成 SOCKS 連接埠；客戶端版本與執行模式可能改變監聽設定，應以狀態列與目前設定為準，不要依舊教學中的連接埠組合判斷。

暫時提高記錄詳細程度有助於確認出站選擇，但記錄也可能包含目標網域、伺服器位址與使用習慣。排查完成後，請還原日常記錄層級，分享前移除敏感欄位。若設定持續無法穩定運作，先回到已驗證的一般伺服器、預設路由與基本 DNS，確認連線恢復後再逐項加入自訂內容。備份應保留可正常啟動的基準設定，而不只是最近一次編輯結果。