v2rayN
進階設定指南

設定層級與修改前備份

區分用戶端、核心與作業系統

v2rayN 主視窗會儲存伺服器資料、訂閱分組、路由預設與介面選項。啟動連線時，用戶端會依據這些資料產生核心所需的執行設定。系統代理則屬於作業系統設定，負責告知遵循此設定的應用程式，將要求交給本機代理連接埠。三者彼此相關，但並非同一個開關。修改伺服器清單不會自動改變所有應用程式的連線入口；切換系統代理也不會替核心新增路由規則。

查看設定檔前，先在用戶端確認目前伺服器、路由預設與執行核心，再查看底部狀態列及記錄。本網站的桌面操作主要以 v2rayN 為例，Android 對應 v2rayNG，使用 V2Fly 核心的替代用戶端則是 v2flyNG。用戶端介面相似，不代表設定欄位相同；即使都能匯入同一種分享連結，產生的內部設定也可能不同。跨用戶端遷移時，先遷移連線資料，再逐項重新設定進階選項。

建立可復原的基準設定

修改前，請透過用戶端提供的備份或匯出功能儲存現有設定，並記錄系統代理狀態、監聽位址、本機連接埠、目前路由預設及 TUN 開關。若要複製用戶端資料夾，請先結束用戶端，讓資料庫與設定檔完成寫入。備份檔可能包含訂閱網址和伺服器驗證資料，建議存放於受控的本機位置，不要直接附在公開的問題說明中。

基準設定不只是「網頁能開啟」。也要確認日常使用的應用程式能正常連線、區域網路裝置可供存取，以及關閉用戶端後系統網路能恢復。分別記錄這些操作依賴系統代理還是 TUN。之後若只有特定類型的要求出錯，就能將問題定位在入口、規則或解析，而不必把所有設定一次改回原狀。若需重新建立基本連線，請依使用指南的步驟完成驗證，再繼續設定進階功能。

一次只變更一個變數

建議依序調整訂閱、路由、DNS、TUN。每次只修改一個主題，儲存並重新載入後，再建立新的連線；仍在執行的長連線通常不會因規則變更而立即切換。查看記錄時，請使用相同目標與相同應用程式，避免把快取、應用程式重試或網站暫時故障誤認為設定效果。若要比較兩種設定，先寫下預期變化，例如「區域網路目標從代理改為直連」，再確認實際出站。

記錄等級也應維持基準。一般使用時保留用戶端預設等級即可，排查問題時再短暫提高詳細程度。記錄中可能包含網域、位址、路徑及訂閱要求資訊；分享前請刪除驗證參數與個人網路資訊。錯誤記錄能指出發生了什麼，不一定代表原因就在最後一行。請從首次失敗的位置往前查看，先確認核心成功啟動，再判斷 DNS 與目標連線，避免把後續連鎖錯誤當成多個獨立問題。

不要直接編輯用戶端暫時產生的執行檔，並期待變更能長期保留。重新連線、切換伺服器或更新訂閱，都可能觸發重新產生設定。可在圖形介面儲存的選項，請直接在介面修改；需要自訂設定時，使用用戶端明確提供的自訂入口，並備份原始內容。欄位通過 JSON 語法檢查，不代表目前核心支援該欄位。若出現未知欄位、協定不支援或設定解析失敗，請先確認核心類型，再檢查巢狀位置。

本頁後續設定皆遵循這項原則：用戶端負責儲存設定意圖，核心負責執行規則，作業系統負責流量入口。若遇到啟動失敗、連接埠被占用或系統代理殘留，請前往常見問題依症狀查閱；主視窗位置相關說明，請參考v2rayN 主介面功能一覽。

訂閱分組與伺服器篩選

讓每個訂閱各自管理

訂閱分組適合依設定來源分類，而非依單次測速結果分類。在 v2rayN 的「訂閱分組」中新增分組，填寫容易辨識的備註與訂閱網址，儲存後再更新。分組備註最好標明來源與用途，例如工作裝置設定或測試設定；不要將網址中的驗證參數複製到備註。新增完成後，先只更新該分組，確認內容來自預期來源，再納入日常選用。

「全部」通常只是伺服器清單的彙整檢視，不代表所有項目都來自同一個訂閱。需要刪除或批次操作時，先切換到目標分組，確認目前的篩選條件與選取範圍。不同分組可能有相同別名，別名也不是伺服器的唯一識別方式。判斷項目是否重複時，應一併檢查協定、目標位址、連接埠與傳輸設定，不要只因名稱相同就刪除其中一項。

分清清單搜尋與更新篩選

伺服器清單中的搜尋主要影響目前顯示的項目；訂閱設定中的篩選條件則可能影響更新後保留哪些項目，兩者的風險不同。清單中找不到某個項目時，先清除搜尋文字，再確認分組是否正確，最後檢查訂閱更新篩選條件。不要在篩選仍生效時就判定訂閱已清空，也不要立即刪除分組後重新新增，以免遺失原本可用的篩選與更新設定。

部分介面使用關鍵字比對，部分篩選欄位則接受正規表示式。請以輸入欄位的說明為準，不要混用兩種語法。如果明確支援正規表示式，可先用較寬鬆的包含條件測試，再逐步縮小範圍。以下範例示範依別名篩選的寫法，只比對明確的名稱片段；它不是路由規則，也不會決定流量使用哪個出站。名稱由訂閱提供，不能據此保證伺服器的實際位置或能力。

香港|日本
^(香港|日本)
測試|備用

第一行表示名稱包含其中一個詞，第二行要求名稱以其中一個詞開頭，第三行可用於支援排除正規表示式的輸入欄位。每一行都是獨立範例，不是要一起貼上的多行設定。如果用戶端只有一個篩選欄位，請先確認它用於包含還是排除；正規表示式中的豎線表示「或」，不是一般文字分隔符號。若訂閱名稱包含括號、加號等字元，也要考慮正規表示式的跳脫方式。

更新前保留可用項目

更新訂閱通常會取代由該來源管理的伺服器資料；手動修改訂閱伺服器的欄位，可能在下次更新時被覆蓋。若要長期保留個別修改，先複製到專用的手動分組，再修改副本並註明用途。如此一來，就能區分由來源維護的資料與本機維護的資料。手動副本不會自動取得訂閱後續的位址變更，因此也要定期確認是否仍然有效；複製不代表永久可用。

修改篩選條件後，先單獨更新一次該分組，並查看更新提示。若結果為空，依序檢查篩選方向、表示式、訂閱回應與網路連線。收到的內容可能是錯誤頁面、登入提示或額度說明，而非可解析的伺服器清單；更新失敗不一定是正規表示式有問題。請保留原分組資料，還原較寬鬆的條件後再試，不要連續執行全部更新來覆蓋現有可用設定。

分享連結匯入與訂閱更新也要分開理解。從剪貼簿匯入的是當下的一組連線資料；訂閱網址則是後續更新的入口。兩者可能匯入相同伺服器，但維護方式不同。需要持續更新的設定，應保留來源清楚的訂閱分組；一次性的測試分享連結則放入手動分組，日後較容易清理。QR Code 或連結含有連線憑證，不適合當作一般截圖公開分享。

選擇伺服器時應搭配實際連線驗證。TCP 連接埠能建立連線，只代表部分鏈路可達，不表示協定交握、目標解析與網頁要求都成功。不要只依一次短暫測試，就透過訂閱篩選永久排除大量項目。想了解不同測試結果的差異，請參閱TCPing、實際連線延遲與下載測速的差異，再決定日常篩選依據。

路由規則實作：順序、比對與出站

先確認規則處理哪些流量

路由規則只處理已進入核心的連線。若應用程式沒有使用系統代理，也未由 TUN 接管，修改核心路由就不會改變它的網路路徑。「全域」預設通常表示進入核心的要求優先使用代理出站，不等於作業系統的所有流量都已經進入代理。排查規則前，先確認應用程式的流量入口；系統代理與路由的差異，可搭配閱讀系統代理與路由模式說明。

在 v2rayN 的路由設定中，先複製現有預設，再於副本中新增或刪除規則。核心通常會由上而下檢查規則，由最先符合的規則決定出站，因此具體例外應排在範圍較廣的規則之前。同一條規則若同時指定網域與連接埠，通常必須同時符合兩種條件；同一個網域陣列中的多個項目則任一符合即可。將一連串條件全部塞進同一條規則，限制可能比預期更嚴格。

建立容易驗證的規則順序

以下片段先處理區域網路網域與私人目標位址，再加入精確網域拒絕範例，最後示範網域集合直連。內容只展示 routing 物件，完整設定必須已定義名為 direct 和 block 的出站，並載入對應的規則資料。範例中的保留網域用來說明語法，不表示需要拒絕任何實際服務。未符合規則的要求會使用哪個出站，仍取決於完整設定。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:lan"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

full: 用於精確網域，domain: 用於網域及其子網域，geosite: 用於引用網域集合，geoip: 用於引用位址集合。集合是否存在及包含哪些內容，取決於實際載入的資料檔。缺少規則資料可能導致設定載入失敗或規則無法使用；欄位拼寫正確，不代表環境設定完整。更新資料後，網域分類也可能改變，重要服務應重新驗證。

geoip:private 比對的是私人或保留用途的目標位址，不等於「所有本機服務名稱」。透過網域存取路由器、印表機或內部服務時，核心可能尚未取得目標位址；使用 AsIs 策略時尤其需要為內部網域設定明確規則。企業網路也可能使用不在常見私人位址範圍內的內部位址，此時應依實際網段新增 CIDR，不要盲目擴大直連範圍。

了解網域策略與預設行為

AsIs 不會為了 IP 規則主動解析所有網域。IPIfNonMatch 可在網域規則未符合時嘗試解析，再比對位址。IPOnDemand 則會在需要位址規則時更積極地進行解析。後兩者會讓路由結果與 DNS 結果互相影響，也可能增加查詢與等待時間。選擇策略前，先判斷規則主要依據網域還是位址；不要把積極解析當成通用的效能最佳化。

在完整的 Xray 設定中，未符合路由規則的連線通常會使用出站陣列中的第一個出站；用戶端預設也可能額外產生預設規則。因此，無法只靠局部片段推斷最終的預設行為。若要用最後一條規則作為預設，必須明確設定適用的網路類型及目標出站，並確認它不會搶先涵蓋後續規則。更換預設後，請查看用戶端產生的設定或路由命中記錄，核對實際順序，不要只看預設名稱。

驗證時，為每條重要規則選擇可重複執行的要求：內部服務檢查直連、精確網域檢查指定出站，其他網域則檢查預設行為。每次建立新連線，記錄目標網域、解析位址與出站標籤。若規則未生效，依序檢查「是否進入核心、規則是否排在前面、條件是否同時符合、出站標籤是否存在」。瀏覽器快取與連線重用可能掩蓋變更；重新載入頁面不一定會建立新的網路連線。

DNS 設定最佳化：配合解析流程與路由

分別檢查解析器與目標連線

一次存取可能涉及系統 DNS、瀏覽器安全 DNS、用戶端內建 DNS 及遠端解析；不一定全部都會參與，也不一定走相同的網路路徑。應用程式將網域交給代理時，本機可能不必先解析目標；若應用程式先取得位址再連線，核心看到的可能只有位址。最佳化前，先釐清「誰在查詢、查詢哪個伺服器、查詢經過哪裡」，否則更換 DNS 伺服器後，實際使用的解析器可能完全沒變。

DNS 設定中的伺服器位址，與查詢最終走直連還是代理，是兩個不同問題。部分核心內部的 DNS 要求可以參與路由；某些特殊模式則會略過一般處理流程。伺服器端能否解析目標，也與本機選擇的解析器不同。排查時先透過用戶端記錄確認要求由哪一層發出，再判斷失敗發生在查詢階段還是目標連線階段；不要把目標交握失敗簡單歸因於 DNS 污染或解析器故障。

先從小範圍分流開始

以下是 Xray 內建 DNS 的局部範例：一般查詢使用一個公開解析器，指定網域集合與區域網路名稱則優先交由區域網路解析器處理。192.168.1.1 僅適用於該位址確實提供 DNS 的網路；使用前應替換為目前閘道或內部 DNS 的實際位址。此處使用一般 DNS 來說明職責，不代表適合所有網路，也不表示查詢已加密。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": ["geosite:cn", "domain:lan"],
        "skipFallback": true
      },
      "1.1.1.1"
    ]
  }
}

domains 表示該伺服器優先處理的網域範圍，skipFallback 用來避免它參與其他網域的一般預設選擇，但無法單獨保證內部網域永遠不會交給其他伺服器。若要嚴格隔離內部網域，還須搭配所用核心的回退選項，並檢查實際查詢記錄。若內部解析器沒有回應，應先修復內部記錄，不要任意新增公開解析器作為回退，以免將內部命名資訊傳送至無關的解析服務。

UseIPv4 只是查詢策略範例，並非建議所有使用者停用 IPv6。網路具備穩定的 IPv6 時，可採用適合該核心的雙堆疊策略；只有 IPv6 連線持續失敗時，才需要比較測試不同位址家族。解析結果包含 IPv6 位址，但應用程式或出站沒有可用的 IPv6 路徑時，就會出現等待後再回退的情況。請分別確認系統位址、預設路由、DNS 回應及代理端支援，不要只移除一筆解析結果。

避免解析要求繞回自身

加密 DNS 若以網域作為伺服器位址，必須先解析該解析器網域，這就是引導解析問題。若引導流程又依賴尚未建立的同一條加密連線，就會形成循環。用戶端可能提供引導 DNS 或靜態主機對應，請依目前核心的說明設定。啟用 TUN 後，也要確認解析器連線不會再次被錯誤送入同一個入口。記錄中反覆出現相同查詢與連線重試，是檢查迴圈的線索。

網域分流最好與 DNS 分流維持一致的設定意圖。內部業務走直連時，應能取得內部網路可辨識的位址；透過代理存取目標時，則要考量遠端是否能連上該位址。位址集合規則仰賴解析結果；不同解析器回傳不同位址時，可能命中不同出站。若目標存取路徑經常變動，先比對路由的網域策略與 DNS 伺服器選擇，不要立即將所有網域改寫成位址規則。

修改 DNS 後，必須明確處理快取。應用程式、系統與核心都可能快取解析結果，只重新啟動其中一層不一定有效。先重新建立應用程式連線，再依系統提供的方式清除快取，必要時重新啟動用戶端核心。若瀏覽器啟用了自己的安全 DNS，可能會繼續略過系統解析設定；驗證時可暫時改用系統解析進行比較，確認原因後再還原原設定。不要同時修改瀏覽器、系統與核心的三種解析器。

比較設定時，應固定使用相同應用程式與目標，分別觀察首次查詢、命中快取後的要求，以及重新建立連線時的行為。解析器越多不一定越快，過多回退反而會讓路徑更難預測。確認一個預設解析器與少數必要例外後，再考慮細分規則；發生異常時先還原預設 DNS，保留原路由，以便判斷問題是否確實來自解析層。

TUN 模式：接管範圍與路由復原

TUN 負責流量入口，不取代連線資料

TUN 透過虛擬網路介面接收系統交付的 IP 流量，再交由用戶端搭配的網路堆疊或核心元件處理。它適合不遵循系統代理的應用程式，但不代表所有協定都能有相同表現。一般系統代理主要處理應用程式主動提交的代理連線；TUN 則會影響系統路由、DNS 與虛擬介面。兩者的入口不同，後續仍需要可用的伺服器與適當的路由規則。

在 v2rayN 中啟用「啟用 Tun 模式」前，先確認一般代理模式能正常存取目標。伺服器本身無法使用時，啟用 TUN 只會擴大故障影響範圍。用戶端可能需要系統管理員權限、系統網路延伸授權或配套元件；實際提示會因平台與安裝方式而異。請依介面提示完成授權，不要為了避開錯誤而任意關閉系統防護，或將整個應用程式資料夾設為所有使用者皆可寫入。

先完成一輪最小範圍接管測試

首次測試前，先退出其他會建立虛擬網卡或變更預設路由的軟體，記錄目前的網路介面，再啟用 TUN。查看啟動記錄是否已建立介面，確認系統中出現對應的虛擬介面，再使用原本不走系統代理的應用程式進行驗證。若介面開關已開啟但核心尚未啟動，流量可能沒有正確交由 TUN 接管。請以記錄與實際要求為準，不要只看開關顏色。

桌面用戶端的 TUN 介面可能由不同元件負責，不要將 Xray 路由片段當成通用的 TUN 設定。先使用用戶端提供的預設範本，確認基本功能正常後，再修改排除網段、DNS 接管或網路堆疊選項。Android 的 v2rayNG 透過系統 VPN 介面接管應用程式流量，相關選項與桌面介面並不完全相同；調整應用程式範圍後，必須重新建立連線才能可靠驗證。

區分入口排除與核心直連

入口排除表示流量不會進入 TUN；核心中的 direct 則表示流量已進入核心，再由核心直接連線至目標。兩者都可能讓區域網路正常存取，但對記錄、DNS 與系統路由的影響不同。存取印表機、檔案分享或內部業務時，先判斷協定是否適用於目前的網路堆疊，再決定要使用入口排除還是核心直連。不要因為網頁能開啟，就認為所有區域網路探索協定也會正常運作。

特別要留意伺服器自身連線的出口。代理出站連往伺服器的連線，必須能夠抵達實際網路，不能再被送回同一個 TUN 入口而形成迴圈。用戶端預設範本通常會設定相關排除或介面繫結，但自訂路由、多個虛擬介面與外部網路工具可能破壞這項設定。記錄中反覆建立相同的伺服器連線、CPU 使用率異常或連線立即逾時時，應先檢查出口迴圈，而不是繼續更換節點。

同時啟用系統代理與 TUN 不一定有問題，但會增加判斷流量入口的難度。部分應用程式可能透過系統代理連至本機連接埠，其他應用程式則由 TUN 直接接管，排查時容易混淆。建立基準設定時，可先清除系統代理，只啟用 TUN 進行驗證；需要恢復一般代理模式時，再關閉 TUN 並啟用系統代理。修改過程中請記錄每個步驟，避免關閉用戶端後留下指向已停止連接埠的系統代理。

從休眠狀態喚醒、切換無線網路或插入有線網路後，預設介面與閘道可能改變。若只有這些情況會發生故障，可先重新建立用戶端連線，查看介面與 DNS 是否隨網路更新。不要透過永久擴大接管範圍來掩蓋復原問題。結束測試時，關閉 TUN、確認虛擬路由已撤除，再使用不經用戶端的方式驗證基本網路；若仍有異常，再依系統網路設定逐項復原。

FakeDNS：虛擬位址與網域還原

虛擬位址不是目標伺服器位址

FakeDNS 會為網域配置一個內部使用的虛擬位址，並在核心中儲存網域與位址的對應。應用程式取得此位址並發起連線後，流量必須再次進入能讀取對應資料的處理流程，核心才能還原網域並繼續路由。此功能用來保留網域資訊，特別適合應用程式先解析再連線的情況。虛擬位址本身不提供遠端服務，也不能直接用於一般網路存取。

因此，FakeDNS 並不是單純更換 DNS 伺服器就能完成的功能。DNS 回應、虛擬網段接管、對應查詢與出站處理必須互相配合。若應用程式取得虛擬位址，卻未讓連線進入對應核心，要求就會逾時。若由一個程序回覆 DNS，卻由另一個未共用對應資料的程序處理連線，也無法可靠還原網域。設定前先畫出完整流程，比先調整位址池大小更重要。

設定片段必須搭配入站

以下是 Xray 格式的局部範例，展示虛擬位址池與 DNS 選擇。範例不包含 TUN 接管、完整入站與出站，因此無法獨立執行。位址範圍屬於保留用途，使用前仍須確認目前網路及其他虛擬介面是否已使用。不要將這段設定直接複製到採用其他欄位結構的 TUN 核心；若用戶端提供完整的 FakeDNS 範本，應優先採用，以維持各部分設定一致。

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

在支援此機制的 Xray 入站中，還需要相應的網域還原功能。以下只展示入站物件中的 sniffing 欄位，不能單獨作為入站使用。此處的 fakedns 表示嘗試利用虛擬位址對應還原目標網域，不代表能讀取所有加密協定的應用層內容。是否同時啟用其他目標探測選項，應依實際協定與核心行為決定。

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

位址池大小決定可維護的對應數量，不會決定網速。位址池過小、並行網域過多或快取存留時間過長時，舊的對應可能遭到取代。若應用程式仍快取舊位址，後續連線可能失去原有的網域關聯。增加位址池容量只是其中一種處理方式，也要確認記憶體用量、應用程式快取與重新連線行為。不要把擴大位址池當成所有偶發連線錯誤的通用解法。

處理需要真實位址的例外

區域網路名稱、內部驗證服務，或需要將解析位址交給其他裝置的應用程式，可能需要真實位址。這類查詢應依網域或用途排除 FakeDNS，並交由合適的內部解析器處理。例外不只涉及 DNS 規則，也必須與路由一致：真實位址要求應使用正確出站，虛擬位址要求則必須留在對應處理流程中。同一網域若有時回傳真實位址、有時回傳虛擬位址，請先檢查解析器選擇與快取來源。

應用程式內建的安全 DNS 也可能略過 FakeDNS。如此一來，部分連線使用真實位址，部分則使用虛擬位址，造成行為不一致。驗證時先固定 DNS 入口，確認查詢結果是否位於設定的位址池，再檢查核心能否還原網域。看到虛擬位址只能證明 DNS 回應生效，不能證明後續連線成功；還必須確認要求符合預期的網域規則，並最終抵達實際目標。

安全復原可依序進行：還原一般 DNS 設定、重新載入核心、清除系統與應用程式的 DNS 快取，再重新建立連線。必要時，結束仍保留連線集區的應用程式。確認不再出現虛擬位址後，再檢查一般解析與路由是否正常。若只有某個應用程式在啟用 FakeDNS 時失敗，可先為它設定受控例外進行比較，不要立刻擴大整個位址池或將所有流量改為直連。

是否值得啟用 FakeDNS，取決於是否需要解決因網域資訊遺失而造成的分流問題。若網域入口穩定，一般 DNS 與路由也運作正常，就可以維持現況。FakeDNS 是用來改變解析與連線關係的工具，不是必備的效能開關；穩定性來自完整閉合的處理流程、明確的例外，以及可執行的快取清除與復原步驟。

多訂閱管理：更新、去重與跨裝置遷移

先訂定命名與更新規則

同時使用多個訂閱時，最容易失控的不是數量，而是來源與用途混在一起。建議依來源建立獨立分組，再以備註區分正式使用、臨時測試與手動保留。分組名稱應保持穩定，伺服器別名則可由來源更新。不要使用訂閱網址作為分組名稱；網址可能含有驗證資訊，也不適合在截圖與記錄中安全引用。分組順序可依使用頻率排列，避免每次都要在「全部」檢視中尋找。

自動更新應依實際需求設定，不是越頻繁越好。先確認手動更新正常，再啟用合適的更新週期。多個訂閱若同時更新，遇到網路尚未就緒或來源回應緩慢時，錯誤容易連帶發生。如果用戶端支援個別設定更新週期，可將測試來源與日常來源分開；若不支援，至少在切換網路後先確認基本連線，再執行批次更新。

保留訂閱更新所需的網路路徑

訂閱更新可能使用直連，也可能透過目前的代理，具體取決於用戶端選項。若更新必須依賴目前伺服器，而該伺服器已失效，就會形成維護上的循環依賴。可保留一組近期驗證可用的設定作為復原入口，或在來源允許的網路環境中直接更新。尚未取得新資料前，不要刪除最後一組可用伺服器；更新失敗也不代表整個訂閱已失效。

更新失敗時，先區分連線逾時、回應內容異常與解析失敗。連線逾時應檢查網路路徑，回應內容異常應確認是否收到訂閱資料，解析失敗則應檢查格式與用戶端支援範圍。錯誤頁面也可能以成功的網路回應傳回，因此「要求已完成」不代表匯入成功。保留原分組並記錄錯誤類型，比重複貼上網址更有助於排查；分享錯誤資訊時，請刪除網址中的驗證資訊。

去重不能只比對別名

兩個訂閱可能包含同一台伺服器，也可能只是使用相同位址，卻有不同的驗證、傳輸或 TLS 設定。去重時應比較完整連線參數，並確認用戶端的去重功能依據為何。只依別名刪除，可能誤刪名稱相同但設定不同的項目；只依位址刪除，也可能將不同服務合併。正式清理前先備份，先處理單一分組，再確認目前選取的伺服器仍存在。

訂閱中的伺服器遭取代或刪除後，用戶端原本的選擇可能失效，也可能自動改選其他項目。更新後應確認目前伺服器、路由預設與連線狀態；清單中仍有內容，不代表工作階段已恢復。若自動選擇依賴測試結果，也要確認測試方式符合實際用途。需要穩定的業務路徑時，維護明確的手動選擇流程，通常比頻繁重新排序整份清單更容易排查。

遷移連線資料，不要盲目複製執行環境

電腦與手機共用訂閱網址，代表兩端分別從同一來源取得資料，不代表路由、DNS 與應用程式接管範圍會自動同步。遷移至 v2rayNG 或 v2flyNG 時，應重新檢查核心支援、VPN 授權與應用程式範圍。桌面端的本機檔案路徑、監聽連接埠與 TUN 範本，也不適合原封不動移至其他平台。先讓目標裝置完成基本連線，再補上必要的進階規則。

完整備份適合還原相同環境，單節點分享適合臨時遷移，訂閱網址則適合持續維護。選擇方式時，應考量來源是否允許多裝置使用、裝置數量限制與更新頻率。備份內容不只有伺服器清單，也可能包含介面設定與本機路徑；還原後應檢查記錄目錄、監聽位址與啟動選項。若要詳細比較三種方式，請閱讀電腦與手機共用設定方案。

若訂閱網址意外公開，只刪除截圖並不能讓舊網址失效；應透過設定來源提供的管理介面更換或撤銷相關網址，再更新各裝置。日常維護時，可保留一份不含驗證資料的操作紀錄，記下分組用途、篩選意圖與復原步驟。如此即使更換裝置，也能重新建立管理架構，不必靠記憶判斷每個分組的用途。

自訂出站：標籤、介面與連線流程

出站標籤必須對應設定中實際存在的項目

出站是核心將連線交由下一步處理的位置。direct、block 和 proxy 常用作標籤，但標籤只是設定中的名稱，不會因為出現這些字就自動產生功能。路由中的 outboundTag 必須對應實際的出站物件。名為 direct 的標籤若綁定其他協定，其行為不會因名稱而改變。查看自訂設定時，應一併確認標籤、協定與參數。

以下片段定義兩個 Xray 出站：一個透過 Freedom 協定直接連線至目標，另一個透過 Blackhole 協定拒絕連線。範例用來說明路由目標，不包含遠端代理伺服器。直連出站位於陣列第一個項目；若完整設定沒有符合的路由，預設行為可能因此採用直連。合併至現有設定時，必須重新檢查順序，不要直接覆蓋用戶端產生的出站陣列。

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

遠端代理出站還需要完整的伺服器資料、驗證資訊、傳輸設定與安全參數。本頁不提供虛構的伺服器設定。實際使用時，請透過已匯入的資料產生設定，再使用用戶端支援的路由或自訂設定入口加以引用。若用戶端會自動產生 proxy 標籤，不要未經檢查就建立同名物件；重複標籤可能造成設定錯誤或不可預期的選擇，應讓每種用途都有清楚且唯一的名稱。

明確確認連線經過幾層代理

多個出站並列存在，通常只是提供多個可選路徑，不會自動串成連線鏈。路由選擇某個出站後，要求通常會交由該出站處理；若要讓一個代理出站再透過另一個出站建立連線，必須使用核心明確支援的轉送或連線鏈設定。相關欄位會依核心而異，不要混用不同設定格式。修改前先畫出應用程式、本機入站、第一跳、下一跳與目標，確認各層職責。

連線鏈不一定能提升效能。它會增加交握步驟、故障點與排查難度，也可能改變 DNS 的執行位置。若第一跳無法連線，後續設定再正確也無濟於事。應先分別驗證每個出站都可用，再測試組合路徑；記錄中要區分連線代理伺服器失敗，還是透過代理連線至目標失敗。一般 TCP 要求能夠通過，不代表 UDP 或其他傳輸方式也同樣受支援，必須依實際業務分別測試。

自訂本機出站與監聽範圍

若要將要求轉交給本機的另一個代理程式，先確認對方的監聽位址、連接埠與協定。SOCKS 與 HTTP 代理不可互換。兩個程式也不能監聽相同的位址與連接埠組合。連線至本機服務時，應優先使用回送位址；只有確實需要讓區域網路裝置使用時，才考慮擴大監聽範圍，並一併檢查防火牆與存取控制。開放監聽不會自動提供身分驗證。

出站綁定網卡或本機位址適用於明確的多網路情境，但可攜性較差。切換無線網路、中斷有線連線或系統休眠後，原本綁定的介面可能消失。除非需要固定出口且能維護相關設定，否則先使用系統一般路由會比較容易復原。在 TUN 環境中特別要確認綁定是否避開虛擬入口，避免出站連線重新送回自身。修改介面設定後，應測試斷線後重新連線，而不只驗證目前的連線。

驗證自訂出站時，可先建立一條精確網域規則，將測試目標指向新標籤，其餘要求維持原本預設。確認核心正常啟動、標籤存在、規則命中且目標要求完成後，再擴大適用範圍。若記錄顯示出站不存在，請檢查拼字及物件是否遭用戶端覆蓋；若出站存在但連線逾時，請檢查本機監聽、遠端可達性與傳輸支援。設定成功載入只是第一步，完整要求成功才是最終驗證。

日常使用時，保留一套標準設定作為復原入口，比長期維護多層自訂連線更重要。需要新增伺服器時，先前往用戶端下載頁確認用戶端選擇，再依使用指南建立基本連線；只有標準入口無法滿足具體需求時，再新增自訂出站。完成後記下設定意圖、重要標籤與復原方式，讓下次修改仍能從明確的基準開始。