v2rayN 進階設定
訂閱、路由與網路模式

訂閱分組與伺服器篩選

訂閱網址是更新伺服器資訊的入口；訂閱分組是用戶端管理這些資訊的容器；伺服器項目則是連線時實際使用的參數。先釐清這三者，再整理清單：修改分組名稱通常不會變更遠端訂閱內容，切換清單篩選條件也不會自動切換目前使用的伺服器。排查時應分別記錄分組來源、清單顯示範圍及目前使用的項目，避免把管理介面的變化誤認為網路狀態改變。

先建立分組，再更新伺服器

在 v2rayN 的訂閱分組設定中，為每個來源建立獨立分組，填入完整訂閱網址並儲存，再更新該分組。分組名稱最好能標示來源與用途，例如「工作訂閱」、「備用訂閱」，不要依賴來源自動產生的節點名稱判斷歸屬。首次更新時先處理一個分組，確認能取得項目、選取伺服器並建立連線後，再加入其他來源。發生錯誤時，才容易確認問題出在哪次操作。

訂閱連結可能包含存取憑證，應視同帳號資訊妥善管理。請勿將完整網址放進截圖、公開記錄或共用筆記；需要描述故障時，只保留請求方式、錯誤類型及已遮蔽的主機資訊。複製網址後，先檢查前後空格、換行，以及通訊軟體附加的標點符號。若服務提供者有多種適用於不同用戶端的入口，請選擇與目前用戶端相容的格式，不要反覆貼上不同連結碰運氣。

更新失敗時，先查看訂閱更新記錄。連線逾時表示請求未能在期限內完成；驗證失敗通常需要檢查網址中的授權資訊；若請求成功但解析失敗，可能取得的是登入頁面或不相容的資料格式。若已有可用連線，可嘗試使用用戶端提供的代理更新方式；但首次匯入時未必有可用代理，不能假設此選項一定能解決問題。原始回應若含敏感資訊，請勿直接公開上傳。

篩選清單，不修改連線參數

伺服器篩選可縮小候選範圍，例如只顯示名稱包含特定地區字樣的項目，或排除已不再使用的用途標籤。先確認篩選適用於哪個分組、名稱欄位或其他欄位，再輸入條件。一般關鍵字與正規表示式的語法不同：只有介面明確支援正規表示式時才使用，否則括號、直線等字元可能只會被視為一般文字。篩選後仍須手動確認目前使用的伺服器。

若篩選欄位明確支援正規表示式，可用下列表示式比對兩個名稱關鍵字。這只是名稱篩選範例，不代表相關伺服器的線路品質，也不會決定網路流量的出口。名稱由訂閱提供者定義，大小寫、空格及命名調整都可能影響比對結果，建議先查看實際項目，再逐步縮小條件。條件一次設得太嚴格，可能讓整個分組看起來像沒有伺服器。

(香港|新加坡)

清單空白時，依序清除搜尋字詞、取消其他篩選、切回所有分組，再查看更新記錄。不要立刻刪除訂閱，因為空清單可能只是本機顯示條件造成的。伺服器篩選也不同於應用程式分流：前者決定清單顯示哪些伺服器，路由規則才決定連線使用哪個出站。即使清單只剩一個項目，已建立的舊連線仍可能沿用原本的出口。

處理更新覆寫與本機修改

更新訂閱時，來源管理的伺服器項目可能會被替換。若直接修改項目的連接埠、傳輸參數或備註，應預期這些變更可能在下次更新時被覆寫。需要長期保留的本機調整，建議複製到獨立的手動管理分組，並在備註中寫明來源與調整原因；如此既能持續接收原始訂閱更新，也能確認手動副本何時需要同步。請勿誤以為手動副本會持續自動更新。

刪除訂閱分組前，先確認用戶端是否會一併刪除該組伺服器，以及目前使用的伺服器是否屬於此分組。不同介面的刪除行為可能不同，操作前請詳閱確認提示。需要保留的項目應先匯出或複製，並另外安全備份訂閱網址；含有網址的匯出檔也屬於敏感設定。還原備份後，請重新確認分組啟用狀態、更新策略及目前使用的伺服器，不要只確認名稱仍存在。

V2Ray 路由規則實作指南

路由會將已進入核心的連線交由特定出站處理，但不會自動讓原本繞過用戶端的應用程式進入代理。設定規則前，先確認目標應用確實使用用戶端的本機入口，或已由 TUN 接管。否則，即使規則語法完全正確，核心也看不到連線，記錄自然不會出現預期的命中項目。先確認入口，再檢查規則，最後確認出站，這比反覆調整規則順序更可靠。

由上而下安排比對順序

Xray 與 V2Fly 常見的欄位式路由會依序比對，第一條命中的規則決定出站。通常應將明確拒絕的目標、私有網路直連及精確的業務例外，放在涵蓋範圍較廣的規則之前；接著安排較大的網域集合，最後確認未命中規則時的預設行為。沒有適用所有人的固定排序：若某個內部網域必須經由專用代理，就應將該網域的精確規則，放在可能涵蓋它的直連集合之前。

以下是用來說明順序的 Xray 路由片段，需合併至完整設定中。此範例假設已存在名為 proxy、direct 和 block 的出站，且可使用所引用的規則資料集合。標籤只是本機識別名稱，不會因為寫上名稱就自動建立出站；若用戶端產生的標籤不同，請依實際設定修改引用。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

此片段沒有加入通用的兜底規則。在這裡討論的常見核心設定中，未命中的連線通常會交由出站清單中的第一個出站處理；用戶端也可能透過產生額外規則來實作自己的預設策略。因此，「final → proxy」只是策略示意，並非可直接加入上述 JSON 的欄位。驗證預設行為時，請檢查實際產生的設定與執行記錄，不要只根據介面上的模式名稱推斷。

區分網域比對與 IP 位址比對

網域規則必須有可用的網域資訊才能比對。若應用直接連線至 IP 位址，或入口只提供目標位址，單獨加入網域規則未必會命中。協定嗅探可在部分連線中補充網域資訊，但並非對所有加密流量都有效，也不能保證穩定還原所有網域。先查看記錄中的目標是網域還是 IP 位址，再決定使用網域集合、IP 位址範圍，或進一步檢查 DNS 與入口傳遞的資訊。

domainStrategy 控制路由比對階段何時嘗試解析網域，不代表所有應用程式的 DNS 都已被接管。AsIs 不會為 IP 位址規則主動解析；IPIfNonMatch 可在網域規則未命中時嘗試解析，再進行 IP 位址比對；IPOnDemand 則會在規則需要 IP 位址時嘗試解析。切換策略會改變查詢次數與命中結果，應搭配 DNS 設定測試，不能簡單認為解析越積極就越準確。

用單一目標驗證規則

每次新增規則時，挑選一個能明確重現的目標，關閉舊連線後重新連線，再查看連線記錄中的目標與出站標籤。瀏覽器長連線、連線重複使用及應用程式快取，都可能讓舊連線繼續沿用修改前的路徑。只重新整理頁面未必會建立新連線；必要時請結束目標應用程式後再測試，同時保持其他設定不變。記錄中應能對照測試時間、目標及出站，而不只是顯示用戶端正在執行。

若規則沒有生效，依序檢查是否有更前面的規則先命中、標籤是否存在、資料集合是否已載入，以及連線是否帶有網域資訊。若規則已命中但仍無法連線，應轉而排查出站與 DNS，不要在同一層重複新增規則。規則資料更新也可能改變集合範圍，更新後應抽查常用服務。維護時留下簡短的規則用途說明，比堆疊大量重複例外更容易找出衝突。

DNS 設定與解析路徑

排查 DNS 時，首先要釐清三件事：由誰發起查詢、查詢如何送達解析器，以及由誰使用解析結果。應用程式可能自行查詢，作業系統可能使用快取，核心也可能為了路由或連線另外查詢。這些路徑可能同時存在，因此修改用戶端中的 DNS 伺服器，不一定會改變瀏覽器的加密 DNS，也不一定會清除系統既有快取。先釐清實際路徑，再調整伺服器，比單純替換解析器位址更有幫助。

區分系統解析與核心解析

系統代理模式主要改變遵循代理設定的應用程式連線路徑，不會自然攔截所有系統 DNS 請求。使用 SOCKS 時，目標網域由本機解析或交由代理解析，也取決於應用程式的實作與呼叫方式。TUN 搭配 DNS 接管能涵蓋更多請求，但仍須檢查路由、接管連接埠及應用程式的獨立解析設定。不能只因為 TUN 已開啟，就認定系統中的所有查詢都走相同解析路徑。

v2rayN 的核心 DNS、TUN 相關 DNS 與桌面作業系統 DNS，可能分屬不同設定入口。操作前請記錄目前啟用的執行模式與輔助元件，再確認修改的欄位由哪個元件讀取。Android 上的 v2rayNG 與 v2flyNG，也會受到 VPN 服務及應用程式選擇設定影響。跨平台移轉時應移植策略意圖，而非將桌面設定文字原封不動貼到行動版的任意欄位。

以下是 V2Fly 格式的內建 DNS 片段，Xray 是否支援則須依使用的核心確認。此範例展示一般 UDP 解析器與查詢策略的結構，不代表能自動使用加密 DNS，也未設定查詢流量的出站路徑。請依目前網路的可達性及管理需求選擇位址，合併後仍須檢查產生的設定、路由與記錄。

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

依用途選擇解析策略

直連服務的解析結果應能透過本機出口連線；代理服務則應考慮解析位置是否與出口網路一致。某些服務會依解析器所在位置回傳接入位址，因此解析成功仍可能造成連線不穩。若使用依網域選擇解析器的方案，應先設定明確易懂的精確範圍，再擴充至規則集合。不要將「解析失敗時備援」與「依路由分流」混為一談，兩者的觸發條件與查詢路徑並不相同。

使用網域形式的加密 DNS 位址時，也要考慮如何取得解析器本身的 IP 位址，這一步通常稱為引導解析。若解析器必須先透過尚未建立的代理才能解析，而代理伺服器位址又依賴同一個解析器，就會形成啟動依賴循環。處理方式是明確設定引導解析路徑，或使用用戶端提供的獨立啟動解析設定。不要靠無止盡增加備用伺服器來解決循環，新增的伺服器也可能陷入相同依賴。

IPv4 與 IPv6 應分別驗證。查詢能回傳兩種 IP 位址，不代表兩種 IP 位址族都有可用出口；作業系統優先嘗試的位址，也可能與用戶端預期不同。若部分網站要等較久才開啟，或只有特定網路無法使用，應檢查 IPv6 路由及代理伺服器對 IP 位址族的支援。只回傳 IPv4 可作為對照測試，但長期策略應依網路能力決定，並記錄調整是否影響其他應用程式。

交叉比對查詢與連線結果

以下指令用於查看作業系統預設查詢路徑的回應，無法單獨證明代理核心使用了哪個解析器。執行時記錄回應伺服器、IP 位址族及錯誤訊息，再與用戶端記錄中的網域解析事件比對。如果核心沒有發起對應查詢，可能是命中快取，也可能是應用程式已提供 IP 位址；應先確認原因再修改設定。

nslookup example.com

清除快取時應分層處理：先重新啟動目標應用程式，再依作業系統提供的方式清除系統解析快取，最後重新啟動相關核心。不要在同一輪測試中同時切換網路、修改解析器及重新啟動裝置，否則難以判斷是哪項變更影響結果。網域能解析但無法連線時，接著檢查出站可達性、憑證時間及目標連接埠；解析逾時則檢查查詢路徑與解析器可達性。兩種故障不應使用相同的修復方式。

企業網路或區域網路中的專用網域，通常需要內部解析器或搜尋網域支援。若將所有查詢一律送往公共解析器，內部服務可能會無法解析。應為內部網域保留明確的查詢路徑，並測試短名稱與完整網域名稱的差異。若公網連線正常但內部服務無法開啟，也應檢查是否只是搜尋網域遺失，不要急著修改代理伺服器或全域路由策略。

TUN 模式與接管範圍

TUN 會透過虛擬網路介面，將選定的網路流量交由使用者空間元件處理，適用於不遵循系統代理設定的應用程式。它改變的是流量入口與路由範圍，不會自動確保每種協定、每個目標都能連線。進入 TUN 的連線仍須經過解析、規則比對及出站處理。判斷是否應啟用 TUN，應從目標應用程式是否支援代理開始考量，不要把它當成解決所有連線問題的通用開關。

建立可復原的啟用順序

啟用前，先在一般系統代理模式下確認某個伺服器能正常運作，並記錄目前的系統代理狀態、DNS 設定及區域網路連線情況。接著關閉可能衝突的其他網路接管軟體，再依用戶端要求授予管理員權限或網路擴充權限。首次只開啟 TUN 所需的基本選項，暫時不要疊加複雜 DNS、FakeDNS 與自訂出站。若一開始同時啟用多項功能，發生斷網時就很難釐清依賴關係。

v2rayN 的 TUN 功能可能透過獨立元件處理虛擬介面與路由，不能假設核心連線記錄就是全部執行記錄。請同時確認 TUN 元件是否啟動、介面是否建立，以及預設路由是否如預期變更。v2rayNG 與 v2flyNG 在 Android 上會使用系統 VPN 授權建立接管入口，首次出現授權提示時，請確認要求來自目前使用的用戶端；若已有其他 VPN 服務執行，也須先處理資源占用問題。

避免迴圈並保留本機連線

代理伺服器本身的連線不能再次被同一條代理路徑反覆接管，否則可能形成迴圈。用戶端通常會透過路由排除、介面綁定或程序處理來避免此問題，但手動新增路由、自訂上游或套用舊設定後仍須驗證。常見情況包括啟用 TUN 後連伺服器都失敗、記錄中反覆出現相似連線，或請求持續逾時。此時先關閉 TUN，恢復原有基準，不要繼續新增代理鏈。

區域網路連線還須同時考慮網路層繞行與核心規則。路由表決定資料是否先進入虛擬介面，核心規則則決定進入後使用哪個出站；只設定其中一層未必足夠。測試路由器管理頁面、區域網路印表機及內部網域時，應分別記錄直接輸入 IP 位址與使用網域名稱的結果。若 IP 位址正常但名稱無法使用，應優先檢查內部 DNS；兩者都失敗，則檢查私有網段路由及直連規則。

應用程式分流與目標分流也要分開理解。Android 的應用程式選擇通常決定哪些應用程式進入 VPN，進入後的連線再由核心路由處理；桌面版能否依程序分流則取決於實際元件的能力。不要把網域規則當成程序隔離規則，也不要將某個平台的應用程式排除方式套用到其他平台。若需要隔離業務，應先確認入口層支援哪些功能，再選擇可驗證的做法。

涵蓋 UDP、休眠與網路切換情境

網頁可正常瀏覽，只能證明相關連線可用，不代表 UDP 應用程式也正常。語音、即時通訊及部分解析請求可能使用 UDP，是否支援還取決於伺服器、傳輸方式與出站設定。測試時先確認目標協定，再檢查記錄中是否出現對應連線。若只有 UDP 服務異常，應從 UDP 處理與上游能力著手排查，不要因為瀏覽器能開啟網頁就排除網路路徑問題。

從休眠恢復、切換無線網路或重新連接有線網路，都可能改變預設閘道、DNS 與介面優先順序。啟用 TUN 後應測試這些日常情境：先建立連線，再切換網路，觀察元件能否恢復，以及區域網路是否仍可存取。若切換後失效，先重新啟動 TUN 元件再驗證；若能反覆重現，請記錄介面與路由變化，不要只寫「用戶端斷線」這種籠統描述。

復原時先關閉 TUN，再結束用戶端，確認系統代理是否如預期恢復，最後測試一般網路與本機服務。不要直接刪除不明虛擬介面或大幅重設網路，避免影響其他正常運作的軟體。若結束用戶端後仍有異常，請依作業系統的網路設定逐項檢查殘留的 DNS、代理及路由。無法確認用途的系統設定，應先記錄再修改，保留復原依據。

FakeDNS 與網域對應

FakeDNS 不會直接將真實目標位址回傳給應用程式，而是從指定的位址池分配合成位址，並在內部記錄該位址與網域的對應關係。應用程式接著連線至合成位址時，接管元件會還原原始網域，再交由路由與出站處理。此機制用來保留網域資訊，尤其適合透明接管情境；它不是公共 DNS 伺服器，也不能取代實際業務伺服器位址。

先確認整個流程，再考慮啟用

啟用的前提是查詢與後續連線都必須經過能共用對應資料的處理鏈。若應用程式取得合成位址後繞過接管元件直接連線，該位址就失去意義；若查詢由一個元件產生，連線卻交給沒有對應記錄的另一個元件處理，也可能失敗。因此不能只在 DNS 清單中加入一個項目就認定設定完成，還須確認位址池路由、入口接收及網域還原環節彼此配合。

v2rayN 的 TUN 元件與 Xray、V2Fly 的 FakeDNS，並非可以任意混用的同一套設定。不同核心及輔助元件可能使用不同欄位、位址池及對應資料生命週期。先確認目前流量實際由哪個元件處理，再選擇相應機制。若用戶端已提供完整的相關預設設定，建議優先使用並檢查產生的結果；不要直接貼上另一種核心的欄位，試圖補上看似缺少的功能。

以下是 Xray 設定結構中的 FakeDNS 片段，只展示位址池與 DNS 選擇。它不是可獨立執行的完整設定，還需要實際入口的網域還原設定及合成位址接管路徑配合。範例中的位址範圍屬於基準測試專用位址，並非實際網站位址；若目前網路已使用相同範圍，應先排除衝突，不要直接套用。

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

了解位址池與對應資料的生命週期

ipPool 決定可分配位址的範圍，poolSize 控制位址池容量。池容量不是傳輸量指標，也不代表能同時維持多少業務連線。應用程式可能長時間快取位址，核心重新啟動後則可能遺失對應資料；若應用程式繼續使用舊合成位址連線，新啟動的處理程序未必知道它對應哪個網域。因此啟用、停用或重新啟動相關元件後，應讓目標應用程式重新解析。

DNS 快取與對應快取的生命週期不同，是間歇性故障的常見原因。可能的情況包括剛啟用時正常，重新啟動後少數應用程式失敗，清除應用程式快取後又恢復。排查時請記錄故障發生前是否切換模式、重新啟動核心或從休眠恢復。不要只增加位址池容量，因為調整容量無法修復舊位址對應關係遺失，還可能讓既有快取更難對照。

部分應用程式需要真實位址來進行網路探測、區域判斷或直接的協定互動，也可能自行使用加密 DNS，繞過預期的查詢入口。遇到相容性問題時，應讓特定網域或應用程式使用真實解析路徑，並確保其連線也採用相符的路由。例外範圍應盡量精確，先驗證單一目標，再擴大至相關網域集合，避免大範圍排除業務，失去原本的網域對應效果。

分段驗證解析、還原與出站

第一步確認目標查詢回傳的是合成位址，且位址位於預期的位址池中；第二步確認連線至該位址時，記錄能還原對應的網域；第三步才檢查網域命中了哪條規則及哪個出站。回傳合成位址只代表第一步完成，不表示後續路徑正常。若記錄中只有合成位址而沒有網域，應檢查接管入口與還原設定，而不是立刻新增真實目標位址規則。

路由中有位址規則時，應區分合成位址與真實解析位址。若把合成位址誤當成一般目標進行地理位置或私有位址判斷，結果可能與業務需求無關。設計規則時，應明確標示哪些判斷依據是還原後的網域，哪些需要真實解析。需要進行位址比對的連線可能仍須執行真實查詢，因此 FakeDNS 不代表所有情境都能完全略過後續 DNS 處理。

停用 FakeDNS 時，先還原一般解析設定，關閉相關位址池接管，再重新啟動目標應用程式並處理殘留快取。若停用後應用程式仍嘗試連線至合成位址，表示快取尚未更新；此時反覆更換伺服器通常沒有幫助。還原完成後，請重新檢查一般 DNS 與區域網路服務。只有在能穩定啟用、明確驗證並完整退出的情況下，才適合將此機制納入日常設定。

多訂閱管理與更新策略

多訂閱管理著重於來源隔離、更新時機及可復原性，不代表會自動進行負載平衡。將多個來源匯入同一個用戶端後，預設仍可能只使用一台目前選取的伺服器，其他項目只是候選。先確認哪些訂閱用於日常服務、哪些作為備用、哪些只保留歷史紀錄，再安排分組與更新。目標是發生變化時能說明原因，而非讓清單塞滿盡可能多的伺服器。

依來源管理，依用途篩選

分組應先依來源區分，避免更新時混淆歸屬；用途則可透過備註、關鍵字或本機篩選來標示。同一來源可能同時包含多種用途的項目，不宜為了區分用途而重複匯入同一個連結。重複匯入會增加更新請求，也會讓相同參數出現在多處，切換時難以判斷哪一份才是目前管理的項目。若確實需要分開管理，請註明複製原因及後續同步方式。

不同來源中名稱相同的項目，不能直接視為重複。名稱相同的項目可能有不同位址、連接埠、協定與傳輸設定；相同連線參數也可能使用不同名稱。整理重複項目時，應結合實際參數與來源判斷，並先保留備份。直接大量刪除訂閱產生的項目，下次更新時可能又會出現；因此建議優先使用顯示篩選，或在來源允許時調整伺服器端的訂閱偏好。

每個來源至少記錄用途、更新方式，以及是否依賴現有代理連線即可；一般筆記不必保存完整授權連結。帳號到期、授權更換或方案調整，都可能造成清單變動，用戶端無法單憑名稱判斷這些狀態。若大量項目消失，先查看該來源的回應與帳號狀態，再考慮還原舊設定；還原舊清單不代表已失效的遠端服務會恢復使用。

依實際變動頻率設定更新

自動更新間隔應依來源的變更頻率與用戶端使用習慣設定，不宜過於頻繁。遠端發生暫時性錯誤時，持續重試可能觸發請求限制，也會讓記錄難以閱讀。首次設定自動更新後，請觀察完整的一輪流程，確認網路尚未就緒時如何處理失敗，以及是否影響目前選取的伺服器。用戶端未執行或受到系統背景限制時，排程工作也未必會如預期執行。

透過代理更新與直接更新是兩種不同的連線路徑，應先確認各自的依賴條件。若目前使用的伺服器來自待更新的訂閱，且該伺服器已失效，透過代理更新也可能失敗。可先切換到其他已驗證的來源，再更新故障分組；若直接連線可用，則單獨嘗試直接更新。不要一次替所有分組切換更新方式，否則無法判斷問題是來自單一來源，還是共用的網路路徑。

記錄更新前後的伺服器數量變化有助於排查，但數量並非服務品質指標。更重要的是目前使用的項目是否仍存在、參數是否變更、手動備註是否保留，以及關鍵服務能否正常使用。更新成功後先驗證目前的業務，再整理清單。若用戶端支援更新時保留選取項目，請實際確認保留結果，不要假設名稱相同就一定是同一台伺服器。

分開處理測速、切換與服務驗證

延遲測試、連線測試與實際服務存取測量的並非同一件事。單次測試可連線，不代表長連線、UDP 或特定網域都能正常使用；測試失敗也可能與測試目標及解析路徑有關。多訂閱環境應依分組分批測試，以減少同時測試造成的干擾，最後再用實際服務確認。不要將單次排序結果直接當成長期選用依據，更不要把清單位置當成用戶端已自動切換的證明。

手動切換目前使用的伺服器後，舊連線可能仍沿用之前的路徑。驗證備用方案時，應建立新的測試連線，並檢查記錄中的出站與目標。若已設定自訂路由或固定出站，部分服務可能不會跟著主要伺服器切換，這是策略設定的結果，不一定代表切換失效。建議簡短記錄「哪些服務跟隨主要選擇、哪些服務使用固定出口」，避免故障期間誤判。

備份應包含分組設定、手動項目及本機規則，並妥善限制存取權限。還原時先匯入基本設定，逐一驗證來源後，再恢復複雜規則；不要直接用很久以前的完整狀態覆寫目前可用的環境。需要停用某個來源時，可先關閉更新並移除目前使用的項目引用，確認沒有其他依賴後再刪除。如此即使需要復原，也能在明確範圍內處理，不必重新整理所有訂閱。

自訂出站與設定復原

出站定義核心如何將連線傳送至下一段網路，路由則決定使用哪個出站。日常切換伺服器通常由用戶端產生對應的出站；自訂出站適用於需要固定出口、明確設定直連或拒絕策略，以及連接本機代理服務的情境。開始前先確認一般設定無法實現所需策略，再決定是否手動編輯。若用戶端介面已能穩定管理相關設定，通常無須再重複寫入另一份自訂設定。

先確認設定由誰管理

v2rayN 可能在啟動或切換伺服器時重新產生執行設定，直接修改暫存產生的檔案不一定能保留變更。請透過用戶端支援的自訂設定入口進行管理，並區分「完整設定」與「追加片段」的匯入方式。完整設定必須包含所有必要入口與出站；片段則依賴合併規則。選錯入口可能覆蓋原有結構。編輯前請保存目前可用的設定，並確認復原時應匯入哪個檔案。

Xray 與 V2Fly 都採用入口、路由、出站等概念，但支援的協定與欄位細節可能不同；TUN 輔助元件也可能使用另一種設定結構。檔案同為 JSON，不代表可在不同元件間互換。請先確認實際啟動的核心，再核對欄位所屬。若要了解用戶端與核心的分工，請參閱Project V、V2Fly 與 Xray 的生態系關係，不要只憑用戶端名稱猜測所有內部功能。

以下是 Xray 中兩種常見出站的片段。freedom 用於直接連線至目標，blackhole 用於丟棄連線；路由可透過標籤引用這些出站。此片段不包含代理伺服器出站，也不能取代完整的出站清單。如果將直連出站放在清單首位，卻沒有相應的兜底策略，未命中規則的連線就可能直接連線，因此新增出站時也須一併檢查順序。

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

透過標籤連結規則與出站

標籤應簡短、唯一且能說明用途。修改標籤時，須同步搜尋路由、鏈式轉送及其他引用位置；只改出站名稱而未修改引用，可能導致啟動失敗或執行時路由異常。新增出站後，先用一條精確網域規則進行測試，不要立刻將範圍廣泛的集合交給它。確認標籤引用、連線路徑與記錄表現都符合預期後，再逐步擴大使用範圍。

連接本機 SOCKS 服務時，先確認服務確實在指定位址與連接埠監聽，再新增對應出站。在同一台裝置上呼叫時，可使用本機回送位址，不要為了方便而直接開放給所有網路介面。若使用容器或不同網路命名空間，本機回送位址的意義也會改變。遇到連線遭拒時，優先檢查監聽程序與位址範圍，不要先修改路由集合；若連線逾時，還要檢查防火牆與路徑可達性。

鏈式代理會增加額外依賴：前一個節點無法連線，後續出口就無法建立；其中一個節點不支援目標協定，整體也可能只在部分服務中失敗。不要以為將多個訂閱項目排成陣列就會形成代理鏈，陣列順序本身不代表鏈式關係。具體轉送機制須依核心支援方式設定，並檢查是否造成自我引用。範例若需要驗證資訊，請在本機安全填入，不要將實際憑證放入公開設定說明。

從語法、引用與連線三個層面驗收

第一步檢查 JSON 語法，包括逗號、引號、括號及欄位型別。第二步檢查語意引用，包括標籤是否存在、協定欄位是否受支援，以及規則資料能否載入。第三步才檢查實際連線。語法通過只代表檔案可以解析，不代表伺服器可連線或路由符合預期。若用戶端提供設定測試功能，請先執行測試再啟動；發生錯誤時保留第一則關鍵訊息，避免後續重複記錄掩蓋問題。

記錄詳細程度應依排查需求暫時調整。更詳細的記錄有助於定位連線路徑，也可能記錄存取目標與網路資訊，因此應限制保存範圍，完成後恢復日常等級。分享記錄前，請移除訂閱網址、使用者識別資訊及驗證資料。若核心無法啟動，先檢查設定測試輸出；若核心已啟動但部分連線失敗，則使用明確目標重現問題，不要在尚未定位前重裝用戶端或重寫整份設定。

修改前就應準備復原方案：保存可用基準，記錄本次新增欄位與預期結果，並明確說明如何恢復用戶端自動產生設定的模式。每完成一項變更，都要分別驗證一般存取、精確規則、區域網路，以及結束用戶端後的系統網路。若只有新規則失敗，先撤銷該規則；若核心完全無法啟動，則還原整份基準。小範圍復原能保留已確認有效的設定，比一次全部清除更容易繼續排查。

系統升級、核心調整或用戶端移轉後，應重新執行相同的驗收流程。舊欄位可能不再適用，預設值也可能改變；不要因為檔案仍能載入，就認定執行行為完全相同。保留簡明的設定說明，寫清楚每個自訂項目要解決的問題、依賴的元件及驗證目標。若需求已不存在，請移除對應自訂設定並重新測試，讓長期維護的設定保持清楚、可復原。