進階設定指南

訂閱群組與伺服器篩選

訂閱群組首先是管理上的界線，不是網路出口。群組會保存訂閱網址、更新選項及相關篩選條件；伺服器記錄才包含協定、位址與連接埠。將記錄移到另一個群組，不代表連線會自動改走其他線路；同樣地，點選群組標籤通常只會變更清單的顯示範圍，不等於切換目前使用的伺服器。調整前應先分清楚「目前檢視哪個群組」與「目前使用哪台伺服器」，避免更新後誤判連線狀態。

建立可追溯的群組

在 v2rayN 的「訂閱群組」相關管理功能中新增群組，先填寫能說明來源與用途的備註，再貼上完整訂閱網址。不同介面配置可能將功能入口放在選單或工具列。訂閱網址通常包含個人授權資訊，不應貼在公開截圖、討論串或共用文件中。首次新增時先建立一個群組；更新成功後，確認清單中的協定類型與位址完整，再新增其他來源，方便將問題追查至特定訂閱。

更新方式應依目前的連線狀況選擇。「不透過代理更新」適用於目前網路可直接連上訂閱網址的情況；「透過代理更新」則須仰賴已可使用的代理連線。若尚未匯入任何可用伺服器，卻要求更新請求經由代理，就可能形成啟動相依。此時先確認訂閱網址能否直接開啟，或使用來源提供的單筆分享連結建立初始連線，再嘗試透過代理更新。更新失敗不代表所有伺服器都已失效。

篩選清單與變更資料的差異

伺服器篩選至少分為兩種：清單搜尋只會隱藏不符合條件的列；訂閱匯入篩選則可能決定哪些記錄會寫入本機資料庫。兩者的作用時機不同。先用清單搜尋確認關鍵字確實能找到目標記錄，再到群組設定使用匯入篩選。若介面明確支援正規表示式，可依別名篩選；若只支援一般文字，就不能把正規表示式語法當成通用輸入。欄位名稱與比對範圍請以目前介面的說明為準。

研究|辦公
^(研究|辦公)-

以上兩行分別示範「包含任一關鍵字」與「以指定前綴開頭」的正規表示式寫法，並非需要同時填入的設定。前者涵蓋範圍較廣，後者則要求別名採用固定命名格式。先在少量記錄上測試，確認是否區分大小寫、是否比對整段文字，再決定是否套用至整份訂閱。若結果為空，先取消篩選並重新更新；反覆修改訂閱網址通常無法解決篩選條件造成的空清單。

更新後的檢查順序

更新訂閱可能會重建伺服器記錄，手動修改的別名、傳輸參數或備註不一定會保留。需要長期維護的自訂記錄，應放在獨立的手動群組，並記下修改原因。不要直接在自動更新群組中修改伺服器端參數後長期使用，否則下次更新可能會覆蓋修改內容。若來源設定確實有誤，應先向來源確認，不要逐項嘗試未知參數。

在 v2rayNG 中，可透過「訂閱群組設定」管理來源，再執行訂閱更新；實際選單名稱請以安裝版本的介面為準。Android 的剪貼簿權限與網路環境和桌面端不同；同一網址在桌面端更新成功，不代表手機目前使用的網路也能連線。v2flyNG 是 V2Fly 核心的替代選項，還應另外確認訂閱中的協定與擴充欄位是否受支援，不能只因記錄成功出現在清單中，就認定連線參數完全相容。

更新後先確認群組中仍有預期的記錄，再確認是否需要重新選取目前使用的伺服器，最後進行實際連線測試。實際連線測試會建立連線，和單純探測主機是否有回應不同；批次測試也可能消耗流量。記錄較多時，先選取小範圍測試，結果異常再檢查日誌。延遲與倍率如何取捨，可參閱節點選擇說明；不要只依清單排序來決定所有流量的出口。

路由規則實作

路由規則決定「送進核心的連線要交給哪個出站」，但不會決定所有應用程式是否都會進入核心。未受系統代理涵蓋的應用程式，通常不會因新增路由規則就自動受到接管。先用一個會遵循系統代理設定的瀏覽器驗證規則，再考慮使用 TUN。v2rayN 的「路由」功能可選擇預設方案或編輯規則；「繞過中國大陸」等名稱代表一組具體策略，使用前應查看規則內容，不要只憑名稱推測所有網域的處理方式。

先確認比對順序與出站標記

Xray 與 V2Fly 的常見路由規則會依序尋找符合條件的項目，由第一個符合的規則決定連線去向。範圍較廣的規則若排在前面，可能會遮蔽後續的精確規則。同一個規則物件若同時設定網域、連接埠與網路類型，通常表示這些條件必須同時符合；同一個網域陣列中的多個項目則代表可供比對的候選條件。設計時先用一條明確的網域規則驗證，再逐步加入連接埠或位址條件，避免混淆「且」與「或」的關係。

以下是 Xray / V2Fly 路由欄位的結構範例，只示範私有位址直連、保留示例網域直連，以及其餘流量走代理的順序。此範例假設現有設定已定義名為 direct 與 proxy 的出站。客戶端產生的標記可能不同，必須對照實際設定調整；保留網域僅供教學示範，不能取代需要分流的實際業務網域。

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

分別驗證網域比對與位址比對

full: 用於精確比對網域，domain: 用於比對該網域及其子網域，regexp: 則使用正規表示式。沒有前綴的文字可能會依子字串規則解讀，比對範圍容易超出預期。只需處理單一固定網站時，優先使用容易閱讀的精確比對或網域後綴比對。業務頁面可能同時向登入、靜態資源與 API 網域發出請求；首頁能開啟不代表整項服務都已透過同一路徑完成，應在日誌中核對相關請求。

AsIs 傾向直接使用既有目標資訊進行比對；IPIfNonMatch 會在網域規則未符合時嘗試解析，繼續比對位址；IPOnDemand 則可能在規則需要位址資訊時觸發解析。這些策略會改變路由階段的解析時機，但不等於替瀏覽器統一指定 DNS。若規則依賴地理位址分類，還應確認網域如何解析、地理資料是否可用，以及目前連線是否帶有網域資訊。

預設規則與自訂規則的界線

地理網域分類需要相應的資料檔，分類內容不是即時網路探測結果。資料缺漏可能導致啟動錯誤，資料過舊則可能使分類結果不如預期。先確認客戶端目前使用哪一套規則資源，再透過客戶端提供的更新功能處理。不要直接貼上另一種規則引擎的語法；即使都包含網域與地區名稱，欄位、比對機制與資料格式也可能完全不同。

修改路由後，先關閉測試應用程式的舊連線再重試。瀏覽器重用連線、應用程式連線池與快取，都可能讓新規則看起來沒有生效。驗證時一次只修改一條規則，開啟對應日誌，確認新請求的目標與出站標記，再逐步恢復其他業務。若要讓所有已接管的流量都走代理，應調整路由的預設處理方式；若要接管原本不經代理的應用程式，則應參閱下文的 TUN 章節。兩者屬於不同層面，不能只用「全域」一詞帶過排查。

路由規則也應保留區域網路的存取需求。印表機、家用儲存設備與企業內部網站可能使用私有位址，也可能使用內部網域。只放行私有位址，未必能解決內部網域無法解析的問題；只放行網域，也未必涵蓋應用程式直接連線至位址的情況。先確認業務實際採用的存取方式，再搭配處理 DNS 與路由。常見連線模式的差異，可參考入門指南中的連線驗證，重新建立基準。

DNS 設定最佳化

DNS 問題常見的表現是「代理已連線，網頁卻打不開」，但並非所有網域查詢都由同一處解析。作業系統、瀏覽器、應用程式內建解析器與代理核心，可能各自維護快取及解析通道。設定前先釐清請求路徑：應用程式是將網域交給本機代理，還是先解析成位址再連線；核心是依網域比對路由，還是需要先解析位址才能比對。只有確認網域在哪一層轉換成位址，才能判斷應修改哪項設定。

區分三種解析工作

第一種是解析代理伺服器本身的網域，發生在建立代理連線之前，需要使用當下就能連線的解析路徑。第二種是解析業務目標網域，可能在本機完成，也可能交由遠端處理。第三種是供路由比對位址使用的輔助解析。若把這三種解析都設定為必須透過代理才能連線的解析服務，可能讓客戶端在啟動時陷入相依循環：代理尚未建立，解析伺服器位址卻已需要代理。

在 v2rayN 調整「DNS 設定」前，應先確認目前使用的核心與設定模式。有些選項用於產生 Xray 設定，有些則作用於 TUN 使用的網路元件；介面名稱相似，不代表會寫入同一個欄位。v2rayNG 的「啟用本機 DNS」涉及本機解析處理，仍須搭配遠端 DNS、直連 DNS 等實際選項理解。不了解作用範圍時，不要同時啟用多種 DNS 接管功能。

{
  "dns": {
    "servers": [
      {
        "address": "localhost",
        "domains": ["domain:example.com"],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

這段 Xray / V2Fly 風格的 DNS 設定範例，示範依網域選擇解析器，並為其他查詢指定一般解析位址；能否連線至該解析位址，取決於實際網路環境。localhost 表示使用系統解析器，不代表本機一定要執行獨立的 DNS 服務。skipFallback 用於限制該伺服器參與非指定網域的回退查詢，不代表所有解析失敗時都會禁止重試。此片段只作用於核心 DNS，不能直接控制所有應用程式。

加密解析仍須搭配正確路由

使用加密 DNS 時，也要考慮解析服務網域的初始解析、連線連接埠與請求使用的出站。選擇加密傳輸不會自動解決網路無法連線的問題，也不能取代業務流量的路由規則。若解析服務只能透過代理連線，應確認代理伺服器本身不會依賴這條尚未建立的通道。已有可用設定時，先單獨替換業務解析器並驗證，再考慮接管系統 DNS，避免一次加入多項相依設定。

IPv4 與 IPv6 也需要一起檢查。查詢結果包含 IPv6 位址，不代表目前網路與所選出站具備可用的 IPv6 路徑；只查詢 IPv4 或許能暫時避開問題，但不等於已修復 IPv6。部分網站逾時時，應分別觀察回傳的位址類型、實際連線位址與路由出口。UseIP、UseIPv4 或 UseIPv6 的支援範圍與作用欄位，應以目前使用的核心說明為準，不要直接跨元件照抄。

依快取層級驗證修改

修改 DNS 後，先重新啟動客戶端相關網路元件，再關閉測試應用程式的舊連線；必要時清除系統與瀏覽器快取。若瀏覽器啟用了獨立的安全 DNS，測試請求可能會繞過系統解析器，因此應在測試記錄中註明其狀態。命令列查詢結果只代表該命令使用的解析路徑，不能據此推定瀏覽器、聊天應用程式或代理核心也取得相同結果。

企業內部網域尤其需要保留原有解析路徑。公共解析器通常不認得內部名稱，統一替換後可能出現外部網站恢復正常、辦公系統反而無法使用的情況。應為內部網域保留系統或內部網路解析器，並為對應位址設定直連規則。若內部網域由網路動態提供，不要把某次查到的伺服器位址永久寫死；切換辦公網路後應重新驗證，避免將僅適用於特定環境的設定帶到其他地方。

建議固定依序排查：先確認代理伺服器網域能否解析，再確認業務網域是否回傳預期的位址類型，接著確認請求使用哪個出站，最後檢查連線錯誤。只有解析結果確實不如預期時才調整 DNS。若遇到憑證名稱不符、交握失敗或帳戶授權錯誤，應回頭檢查相應的連線參數；反覆更換解析器通常無法解決這些問題。涉及虛擬位址對應時，再參閱 FakeDNS 章節。

TUN 模式

TUN 模式透過虛擬網卡接收 IP 封包，常用於接管未遵循系統代理設定的應用程式。它與「自動設定系統代理」是不同的開關，也不等於將所有流量都送往代理伺服器。某條連線是否受到接管，由網卡與路由決定；接管後要走直連還是代理，則由規則決定。因此排查 TUN 時應分兩步：先確認封包是否進入接管路徑，再確認進入後使用哪個出站。

啟用前先建立系統代理基準

先關閉 TUN，使用系統代理完成一次網頁瀏覽與實際連線測試，確認伺服器參數本身可用。記下目前使用的伺服器、路由方案與 DNS 設定，再啟用 TUN。若系統代理階段已無法連線，就不宜再透過 TUN 增加變數。v2rayN 的 TUN 實作方式取決於平台與發行版本，相關元件可能不是主要代理核心；Xray 路由片段不能未經轉換就當成其他元件的設定。

虛擬網卡與系統路由通常需要相應權限。Windows 可能需要提高權限，macOS 可能需要網路相關授權，Linux 則涉及裝置存取與路由管理權限。啟用失敗時，先查看日誌確認是否已建立網卡、是否成功新增路由，再判斷是權限還是網路參數問題。不要將所有客戶端長期以最高權限執行當成預設解法；應先確認目前版本提供的權限申請方式與具體錯誤。

避免出口迴圈與重複接管

接管系統流量後，代理程式本身連線至伺服器的流量必須能正常離開接管路徑，否則可能再次被送回自身。成熟的客戶端通常會處理介面綁定、路由排除或程序保護，但多張網卡、其他 VPN、手動路由與防火牆規則都可能破壞這些條件。若啟用後立即斷網，先暫停其他網路接管工具，只保留一個客戶端，再比較啟用前後的路由與日誌。

同時啟用系統代理與 TUN 不一定會出錯，但會增加理解流量路徑的難度：部分應用程式先連線至本機代理連接埠，其他應用程式則直接進入虛擬網卡。排查時先採用單一接管方式，確認穩定後再決定是否需要同時使用。Android 上的 v2rayNG 與 v2flyNG 通常透過系統 VPN 介面接管流量；其他使用者空間中的 VPN 應用程式可能會競爭授權，因此連線按鈕顯示已啟動，不等於網路實際可用。

應用程式範圍、區域網路與 UDP

v2rayNG 的「分應用程式代理」用於指定哪些應用程式納入或排除 VPN 處理，選項的實際含義請依目前模式說明判斷。選取應用程式不一定代表「只代理這些應用程式」，因為納入模式與排除模式的作用方向相反。先選一個測試應用程式，完全結束後重新開啟，觀察它是否出現在客戶端日誌中，再逐步擴大範圍。系統元件、下載管理器與內嵌網頁可能由不同程序發出請求，應依實際業務情境驗證。

區域網路探索、列印與投放可能依賴廣播或多點傳播，單靠一條私有位址直連規則不一定能恢復功能。先確認相關流量是否應進入 TUN，再查看客戶端是否提供區域網路略過設定。即時通訊或遊戲常使用 UDP；網頁測試成功不代表 UDP 路徑也正常，還需確認本機接管能力、出站協定與伺服器支援情況。協定支援 UDP，不代表所有網路環境都能傳輸。

MTU 會影響單一封包的有效負載範圍。只有出現特定大型請求卡住、已建立連線但傳輸異常等線索時，才考慮調整，並記錄原始值以便逐步驗證。任意將 MTU 調得很小可能降低效率，也可能掩蓋其他問題。先排除 DNS、出站無法連線與重複接管，再進行這類底層調整；同一個數值不應被當成所有平台與網路的通用答案。

結束程式前，先透過客戶端關閉 TUN，再結束程式，隨後確認一般網路連線已恢復。若異常結束導致網路無法使用，重新開啟客戶端並正常關閉，檢查系統代理與虛擬網卡狀態；必要時重新連線目前使用的網路。不要直接刪除不認識的系統網卡，也不要清空所有防火牆規則。macOS 授權問題可參考安裝允許與網路權限說明；啟動階段的問題則應先處理客戶端本身。

FakeDNS

FakeDNS 回傳的是供本機對應使用的虛擬位址，不是業務伺服器的真實公網位址。應用程式取得虛擬位址後發起連線，接管元件會依據對應關係找回原始網域，再依網域執行路由或交由代理處理。這種機制有助於保留網域資訊，但有明確的必要條件：DNS 查詢與後續連線都必須經過能共用對應資訊的路徑。只啟用名為 FakeDNS 的選項，不會自動補齊整條鏈路。

先確認是否真的需要虛擬位址對應

若應用程式已透過本機代理提交完整網域，核心通常可以直接依網域比對，不必為了「最佳化」再加入 FakeDNS。FakeDNS 更適合需要從 IP 層接管連線，同時希望還原網域資訊的情境。是否啟用應視接管方式與客戶端支援情況而定，不要看到選項就全部開啟。不同元件中的 FakeDNS 與 fake-ip 名稱相似，但設定欄位、位址池與快取實作未必相同。

以下展示 Xray / V2Fly 風格設定中位址池、DNS 與入站嗅探之間的關係。這不是適用於所有 v2rayN TUN 實作的通用設定，也未包含完整入站與出站。只有確認目前使用的核心支援這些欄位，而且 DNS 查詢確實由該核心處理後，才應將相應部分合併至自訂設定。使用客戶端圖形介面開關時，應優先由客戶端產生設定，避免同時手動撰寫另一套互相衝突的設定。

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

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

第二段設定屬於需要還原對應資訊的入站物件內部，不能直接放在完整設定中的任意位置。位址池必須與接管路由一致，並避免與目前實際使用的網路衝突；範例使用專用測試位址範圍，不是可供應用程式直接存取的公網服務。poolSize 表示對應容量，不是伺服器數量或效能保證。若客戶端會管理對應池，應優先保留預設值，再依據明確問題調整。

對應、快取與流量嗅探的關係

一般流量嗅探會嘗試從連線初始資料中辨識網域；FakeDNS 還原則仰賴先前建立的位址對應。兩者不能簡單互相取代。部分協定或加密交握不會公開可供辨識的網域，嗅探不一定成功；若對應資料已遺失，只有虛擬位址也無法推回原始網域。v2rayNG 的「啟用流量嗅探」應搭配實際核心設定理解，不能把它當成還原任意連線目標的萬用開關。

最常見的邊界情況，是客戶端重新啟動後對應資料消失，但應用程式仍快取著舊虛擬位址。此時應用程式繼續連線至舊位址，目前的核心卻已沒有對應關係，因而出現部分應用程式失敗、重新開啟後又恢復的情況。處理時應關閉舊連線，清除相關 DNS 快取或重新啟動測試應用程式，再重新查詢網域。若只重新啟動代理，卻保留所有應用程式連線，這種不一致狀態可能持續更久，讓排查結果互相矛盾。

為特殊業務保留真實解析

有些程式會比對解析結果中的位址、將位址寫入後續協定欄位，或使用獨立解析器繞過系統 DNS。內部探索服務與仰賴位址語意的應用程式，也可能不適合使用虛擬位址回應。遇到相容性問題時，應先為相關網域或應用程式恢復真實解析路徑，再驗證業務功能，不宜繼續增加嗅探參數。區域網路網域通常應搭配內部網路解析器處理，而非一律回傳虛擬位址。

若測試工具顯示目標位於虛擬位址池，不能據此判斷業務服務部署在哪個地區，也不能將該位址用於延遲比較或手動固定伺服器。若要觀察真實連線，應查看實際出站與遠端目標日誌。反過來說，瀏覽器顯示一般公網位址，也不一定代表 FakeDNS 完全未生效；瀏覽器可能使用獨立 DNS，或命中尚未過期的快取。驗證必須從新的查詢開始。

停用 FakeDNS 時，也要依序處理快取與路由。先切換回真實解析設定並重新載入客戶端，再清除應用程式持有的虛擬位址，確認新查詢不再回傳位址池範圍，最後檢查接管規則是否恢復預期。若修改後只有少數應用程式失敗，先檢查快取；若所有業務立即失敗，應優先檢查設定產生、DNS 可連線性與接管鏈路，而不是更換伺服器記錄。

多訂閱管理

多訂閱管理的目標是保留來源界線、減少重複修改，並在更新失敗時明確回復。增加訂閱數量不會自動帶來故障切換，也不代表客戶端會依業務選出最合適的伺服器。應分別規劃「來源管理」、「目前使用的伺服器」與「業務路由」：來源負責提供記錄，目前使用的伺服器決定預設代理出口，路由則決定哪些連線交給該出口。若將三者混在一起，更新時最容易失去追溯依據。

依維護方式而非臨時用途分組

建議將自動更新的來源與手動維護的記錄分開。自動群組只保存來源提供的參數；手動群組則保存經明確驗證的本機修改，並在備註中說明用途與修改原因。來源名稱應保持穩定，不必隨目前使用的伺服器變動。業務用途可透過備註或篩選表達，避免為了「辦公」、「影片」等標籤重複匯入同一份訂閱，最後產生大量難以判斷是否重複的記錄。

判斷重複記錄不能只看別名。名稱相似的兩台伺服器可能使用不同傳輸層、連接埠、驗證參數或服務名稱；名稱不同的記錄也可能指向相同連線參數。執行去重前，應先確認客戶端依哪些欄位判定重複項目，並先備份。若無法確認判定規則，寧可保留來源群組，透過顯示篩選減少清單干擾，也不要對所有群組執行無法追溯的批次刪除。

更新排程與失敗回復

自動更新適合參數穩定、來源回應可靠的訂閱，但更新頻率不宜超出實際需求。過於頻繁可能觸發來源的流量限制，也可能讓暫時性錯誤更難重現。調整為定期更新後，應觀察一次正常流程，確認更新失敗時原有記錄是否保留、更新成功後目前使用的伺服器如何處理。不同客戶端與更新操作的行為可能不同，不要假設「更新失敗一定不會改變本機資料」。

批次更新前，先確認至少有一條已驗證且可用的連線路徑可供恢復。若更新必須透過代理，保留目前可用的記錄尤其重要；若更新後來源回傳空內容，應先檢查回應錯誤與篩選條件，不要立刻清空所有群組再試一次。回復時應還原本機備份，或重新匯入已確認的來源設定，而不是公開舊授權連結請別人代為測試。授權資訊失效時，應請來源重新簽發。

跨裝置同步與格式選擇

在桌面端與 Android 之間移轉時，優先傳送訂閱網址或客戶端支援的單筆分享連結，不要直接複製整個客戶端資料目錄。資料庫、介面狀態、路徑與執行元件都可能因平台而異，複製目錄可能帶入無效路徑或過期權限。移轉後先核對協定、傳輸參數與安全設定，再完成實際連線測試。v2rayN 可用的擴充欄位，不代表 v2flyNG 使用的核心也支援相同功能。

Base64 訂閱通常會封裝多筆分享記錄；完整 JSON 則可能包含入站、出站、路由與 DNS。將完整 JSON 當成一般訂閱匯入，客戶端未必能擷取伺服器清單；分享連結也不會自動包含原本的路由方案。遇到匯入錯誤時，先辨識內容類型與客戶端匯入入口。資料結構可參考訂閱格式與分享連結說明，不要只靠修改副檔名嘗試轉換。

匯出記錄時也要留意匯出範圍。有些操作只匯出選取的伺服器，有些會匯出目前群組；完整備份則可能包含所有群組與設定。將檔案傳到自己的另一台裝置前，先確認其中是否包含不需要移轉的來源。清理舊裝置時，也應檢查匯出檔案、剪貼簿歷史與雲端硬碟副本，避免只刪除客戶端介面中的記錄，卻仍保留可繼續存取的訂閱網址。

以變更記錄取代反覆試設定

每次進行較大幅度的調整，都應記錄原本的路由方案、目前使用的核心、接管方式與修改原因。記錄不必包含憑證，只需能回答「從哪一步開始出現異常」。多個來源同時發生問題時，先檢查共同相依項目：目前網路、DNS、系統時間、客戶端權限與代理更新路徑；只有單一來源失敗時，再檢查網址有效性、回應格式與來源授權。依照這個順序排查，比輪流重新安裝三款客戶端更能保留有效線索。

最後，也要實際測試備份還原。確認備份可以重新匯入、手動記錄仍可辨識，且路由與 DNS 都沒有遺漏，再依賴自動更新長期使用。還原測試應安排在可控時段，避免辦公連線正在使用時切換整套設定。桌面客戶端無法啟動時，可先參閱啟動閃退排查，確認執行環境；設定損毀與來源失效是不同問題，應分開處理。

自訂出站

出站是核心實際用來建立目標連線的執行對象；路由會透過標記將連線交給它。日常使用 v2rayN 時，客戶端通常會依目前使用的伺服器產生代理出站，再搭配直連與阻斷出站。只有需要明確的多出口、特殊鏈路或完整自訂設定時，才有必要直接管理出站結構。先確認需求能否透過圖形介面的伺服器選擇與路由規則達成，再手動編輯設定，可降低客戶端產生的設定與本機修改互相覆蓋的風險。

從可驗證的最小架構開始

以下是 Xray / V2Fly 風格的教學設定，只包含本機 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": {
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example.com"],
        "outboundTag": "block"
      }
    ]
  }
}

範例中未符合其他規則的連線會交給第一個出站，也就是直連出站；保留網域則用於示範阻斷規則。測試前應確認監聽連接埠未被現有客戶端占用，不要在同一連接埠啟動第二個執行個體。客戶端使用完整自訂設定時，介面中的目前使用伺服器、DNS 或路由開關是否仍有效，取決於實際匯入方式。必須透過實際產生的設定或日誌確認，不能假設所有圖形介面設定都會疊加生效。

標記命名與預設行為

tag 是本機引用名稱，不是協定名稱，也不是伺服器自動辨識的參數。路由中的 outboundTag 必須準確引用已定義的出站；名稱拼寫不一致可能造成啟動或執行問題。建議使用含義明確、彼此不重複的簡短名稱，並記下預設出站的排列順序。不要假設伺服器別名會自動轉為出站標記；客戶端清單中的顯示名稱與核心設定欄位屬於不同層級。

修改前先保存一份可正常運作的完整設定，再進行語法與啟動驗證。JSON 不允許一般註解或末尾多出的逗號；介面編輯器接受內容，也不代表核心就支援這些欄位。若日誌回報未知協定或未知欄位，先確認實際啟動的是 Xray 還是 V2Fly，以及欄位所屬層級。其他網路元件的設定即使同樣使用 JSON，也不能直接匯入。定位錯誤時，應從第一個有效錯誤開始檢查，避免受到後續連鎖錯誤干擾。

鏈式連線與多出口的限制

鏈式連線必須明確定義每一段的職責：前一段負責連到下一段，下一段負責連線至最終目標。引用另一個出站的方式、可用的傳輸能力與欄位支援情況，都取決於核心實作；不能只憑想像將兩個伺服器物件並排放置，就認定已建立鏈路。每一段都應先單獨驗證，再測試組合後的 DNS、UDP 與連線重用。組合路徑會增加相依項目，其中任何一段失效都可能影響最終連線。

同時存在多個出站，不代表已啟用自動測速、負載平衡或故障切換。若需要選擇器或平衡策略，還應另外設定候選集合、選擇邏輯與健康狀態判斷，並確認目前使用的核心確實支援。桌面使用者若只需要切換預設伺服器，優先使用 v2rayN 既有的伺服器選擇功能。在日常環境導入複雜設定前，應先說明它具體解決了簡單設定無法處理的哪個問題。

回到實際業務請求驗證

設定完成後，依序驗證入站監聽、路由符合情況、出站連線與業務回應四個層面。成功監聽連接埠只代表程式啟動至某個階段；實際連線成功也不代表目標業務的所有網域與 UDP 都可正常使用。選擇一項可重複執行的業務操作，關閉舊連線後重新測試，並記錄錯誤發生在哪個層面。暫時提高日誌詳細程度後，請留意日誌可能包含目標網域與位址；排查結束後應恢復平常使用的日誌層級。

若自訂設定失敗，但圖形介面產生的設定正常，先還原至正常方案，再比較兩者的入站、預設出站、DNS 與路由差異，不要繼續修改訂閱中的驗證參數。若要長期使用自訂方案，應在本機說明文件中記下適用核心、相依資源與還原步驟。基礎概念可查閱術語表；三款客戶端的適用範圍請參閱選型指南。若尚未建立初始連線，仍應回到入門指南，先完成最基本可用的設定。