v2rayN
進階設定指南

訂閱分組與伺服器篩選

訂閱分組用來區分來源，伺服器篩選則用來篩選清單。兩者都不會自動改善伺服器端的連線品質，也不能取代路由分流。先將一個訂閱網址放入命名清楚的分組，更新後確認該組顯示伺服器，再新增篩選條件。如果同時建立分組、修改網址並啟用正規表示式，清單變空時就很難找出是哪個步驟出了問題。

建立分組，確認更新方式

在 v2rayN 的訂閱分組設定中新增分組，填寫方便辨識的備註與訂閱網址，儲存後回到主視窗。先選取該分組，再執行更新訂閱。請保留提供者給的完整網址路徑與查詢參數；從通訊軟體複製時，避免一併複製引號、換行或末尾句號。訂閱網址通常包含存取憑證，請勿將完整網址貼到截圖、日誌或公開討論區。

更新方式中的「透過代理」與「不透過代理」，只會控制取得訂閱內容時的請求路徑，不代表替更新後的所有伺服器指定路由。如果目前的代理尚未連線，強制透過代理更新可能形成相依循環：需要新設定才能連線，卻又必須先連線才能取得設定。先嘗試可連通的更新路徑，成功匯入後再決定是否調整後續更新方式。

儲存後先檢查三項：分組備註是否正確、訂閱網址是否完整，以及更新日誌是否顯示已解析出有效內容。請求成功但清單沒有變化，不一定是用戶端故障；遠端可能仍傳回相同內容，也可能傳回登入頁面或說明文字。不要只看請求完成提示，也要檢查解析結果與目標分組；必要時先停用篩選，再確認一次。

從簡單關鍵字開始撰寫正規表示式

「伺服器篩選（正規表示式）」通常會比對伺服器備註；實際套用在匯入流程或清單顯示，請以目前介面說明為準。先用一段確實存在的名稱測試，再逐步加入其他選項，不要一開始就寫複雜的排除式表示式。正規表示式中的直線符號代表「或」，圓括號用來分組，方括號代表字元集合；這些符號都不是一般文字的連接符號。

香港|日本
^(香港|日本)
香港.*專線
\[備用\]

以上四行是各自獨立的範例，請勿全部貼到同一個輸入欄位。第一行會比對包含任一關鍵字的備註；第二行要求備註以指定關鍵字開頭；第三行要求兩段文字依序出現；第四行會比對含方括號的文字。如果提供者使用其他名稱或縮寫，這些表示式可能找不到結果。篩選條件應依據實際備註撰寫，不能把地區名稱當成跨訂閱通用的命名規則。

輸入錯誤時，先清除正規表示式並儲存，確認伺服器重新出現後，再逐段加回條件。需要比對句點、括號或加號時，請留意這些字元具有特殊意義；例如要比對句點本身，通常應寫成 \.。不同用戶端版本採用的正規表示式實作可能不同，尤其是環視、內嵌選項與複雜分組。使用簡短、易理解的表示式，比依賴難以移植的進階語法更穩妥。

分辨篩選錯誤與更新失敗

篩選後看不到伺服器，先切回「全部」或對應的來源分組，清空搜尋欄，再檢查分組篩選條件。主視窗搜尋與訂閱設定中的篩選可能同時生效，只修改其中一處不一定能恢復顯示。確認問題確實來自篩選後，再決定要保留哪些條件。不要為了恢復清單而反覆刪除整個分組，這可能連備註、更新方式及其他管理設定一併刪除。

更新失敗時，依序檢查網址是否有效、請求路徑、回應內容及解析格式。如果同一網址可透過某條網路路徑取得內容，換另一條路徑卻失敗，優先檢查連線與 DNS；如果取得的是網頁而非訂閱內容，請確認網址用途與授權狀態。只要已匯入的伺服器仍可使用，就先保留現有設定，不要讓更新失敗進一步造成所有連線都無法使用。

路由規則實作

路由的核心是依序比對：核心會檢查連線目標及可用的中繼資料，符合規則後便選擇相應出站。規則越具體，通常越應放在較寬泛的規則之前。設定前先確認目前啟用的路由預設，以及用戶端是否會在啟動時重新產生核心設定。只修改暫存的產生檔案，可能在切換伺服器或重新啟動核心後被覆蓋，不能視為永久設定。

先確認出站標籤，再撰寫條件

以下範例採用 Xray 的 routing 物件格式，示範封鎖廣告網域、讓私人位址直連，以及讓指定網域集合直連。範例假設完整設定中已定義名為 direct 與 block 的出站。如果用戶端實際產生的標籤不同，必須同步修改；標籤必須完全相符，不是會自動辨識含義的保留中文字。請勿將此物件直接貼到只接受規則陣列的輸入欄位。

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

同一條規則中的不同條件類型通常必須同時符合；同一陣列中的多個候選項則用來擇一比對。例如同時填入 domain 與 port，表示網域和連接埠都須符合，而非任一條件成立即可。如果希望網域或某個位址範圍都能觸發規則，應拆成兩條規則。拆分後也要檢查順序，避免較前面的寬泛條件搶先接管連線。

未符合任何規則的流量如何處理，取決於核心的預設行為及用戶端產生的完整設定；不能只根據上述片段判斷最後是否會走代理。Xray 通常會以第一個出站處理未符合規則的流量，但圖形介面用戶端也可能加入預設規則。請檢查最終設定中的出站順序與末尾規則，再決定是否明確新增預設路徑。檢查設定時應包含開頭和結尾，不要只看新增的幾行。

了解網域、IP 與規則資料庫的關係

geosite 是網域分類，geoip 是 IP 位址分類。兩者都需要核心能讀取相應的資料檔，且檔案內包含所需的分類名稱。資料檔存在，不代表所有來源都包含相同的集合；輸入看似合理的分類名稱，也不會自動建立該分類。載入集合失敗時，先檢查資料檔來源、存放位置及核心日誌，不要靠反覆切換伺服器來處理規則資料庫錯誤。

domainStrategy 決定路由比對時是否為網域補充 IP 資訊。AsIs 不會單為比對 IP 規則而主動解析網域；IPIfNonMatch 會在網域規則未符合時嘗試解析；IPOnDemand 則可能在比對過程需要 IP 時發起解析。選擇不同策略會改變查詢時機與成本，但不會直接指定連線必須使用哪一部 DNS 伺服器。

如果應用程式只向代理提交 IP，核心可能無法取得原始網域，因此網域規則未必有可用的比對依據。部分流量可透過嗅探補回網域資訊，但無法還原所有加密連線，也不能保證辨識每種協定。遇到「同一個網站在不同應用程式中的路徑不同」，先檢查入站收到的是網域還是 IP，再確認嗅探與 DNS 流程，不要一開始就擴大所有直連或代理範圍。

使用容易理解的案例驗證規則

驗證時挑選一個明確寫入規則的網域、一個私人位址目標，以及一個不符合規則的目標，分別建立新連線。觀察日誌中的目標與出站標籤，確認比對順序符合預期。瀏覽器可能沿用舊連線，修改規則後持續重新整理未必會重新選路；請先關閉相關連線或重新啟動測試應用程式，再進行比較。規則成功載入與實際請求成功是兩件不同的事，都要確認。

某條規則意外蓋過其他規則時，先暫時移除最寬泛的比對條件，以最少規則驗證。連接埠、網路類型與程序規則也可能影響結果，尤其是用戶端產生的規則與自訂規則同時存在時。資料檔更新方式與分類寫法請參閱geoip.dat 與 geosite.dat 路由資料庫說明；更新前後應使用相同的案例重新測試。

DNS 設定最佳化

設定 DNS 前，先釐清三件事：由誰發出查詢、查詢送到哪裡，以及結果交由誰使用。系統解析器、瀏覽器安全 DNS、用戶端內建 DNS，以及核心用於路由判斷的解析流程可能同時存在。只在用戶端填入一個伺服器位址，無法保證所有應用程式都會依循這條路徑解析。最佳化的目標是讓路徑一致、結果可用且故障容易排查，而不是把所有選項都打開。

分清解析伺服器與查詢出站

以下是 Xray 的 dns 物件片段，用來說明伺服器清單與查詢類型。queryStrategy 控制內建 DNS 查詢所需的位址類型，不代表停用整個系統的 IPv6。範例中的加密解析端點也只是可供測試的選項；請先確認目前網路能夠連線，再決定是否採用。此片段未包含 DNS 流量路由，因此不能據此推斷請求一定會經過代理。

{
  "dns": {
    "servers": [
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIP"
  }
}

指定 DNS 伺服器位址與指定查詢出口是兩回事。部分核心的加密 DNS 請求可參與內部路由，另一些伺服器類型則可能直接使用本機連線。用戶端也可能在介面中提供直連 DNS、遠端 DNS 或獨立出站等選項。這些名稱反映的是用戶端的封裝方式，不應直接對應到另一個核心的欄位。先確認使用哪個核心，再依據相應文件解讀最終設定。

使用網域形式的加密 DNS 端點時，還需要處理引導解析：連線到解析服務前，系統必須先知道該服務的 IP 位址。如果引導解析本身又依賴尚未建立的代理，就可能形成循環相依。可透過固定服務位址、明確的引導路徑，或用戶端提供的啟動解析機制解決；但應選擇一種容易理解的方案，不要同時加入多部用途不明的伺服器。

依連線路徑安排解析策略

直連目標通常應取得目前網路可連通的位址；代理目標的解析方式也應配合代理連線行為。部分協定會將網域交給伺服器端解析，此時本機 DNS 可能只提供路由判斷所需的資訊；另一些連線則會先在本機解析，再連往取得的位址。如果路由判斷使用一組解析結果，實際連線卻使用另一組，就可能造成分流預期與實際存取不一致，因此也要檢查網域是否有保留。

遇到 IPv6 相關問題時，先確認網路是否有可用的 IPv6 路徑，再決定位址偏好。解析結果包含 AAAA 記錄本身不代表有錯；真正造成等待或切換備援的，是應用程式選用了無法連線的位址。暫時只查詢 IPv4 可作為對照測試，但不應視為所有網路的永久解法。也要確認代理伺服器、直連出口與 TUN 對 IPv6 採用的策略是否一致。

瀏覽器啟用內建安全 DNS 後，可能略過系統的一般解析設定；應用程式透過已建立的加密連線查詢時，也不一定會呈現為一般 DNS 連接埠流量。排錯時先記下這些設定，再暫時統一解析入口。確認用戶端的解析路徑正常後，逐一恢復應用程式設定並比較變化。不要同時清除所有系統網路設定，否則即使恢復連線，也難以確認真正有效的變更。

依序驗證「解析成功、連線成功、路由正確」

先從日誌確認查詢是否送達預期的解析器，再檢查是否傳回可用位址，最後確認連線是否走向指定出站。命令列顯示的系統解析結果，只能代表系統這一層，不能代表瀏覽器內部解析或核心內部 DNS。診斷紀錄至少要註明測試應用程式、目標網域、代理模式與測試時間，避免混淆不同路徑取得的位址。

更換 DNS 後，舊快取與連線池可能仍保留原有結果。先關閉測試應用程式並清除相關快取，必要時重新啟動用戶端核心，再以相同目標重新測試。如果只有特定網域失敗，優先檢查網域規則與解析回應；若所有網域都失敗，但 IP 連線正常，再檢查解析器是否可連線及引導路徑。一般連線尚未穩定前，不宜再加入 FakeDNS。

TUN 模式

TUN 會透過虛擬網路介面接收由系統路由導入的 IP 流量，再交由用戶端關聯的元件處理。它與系統代理不同：系統代理仰賴應用程式遵循代理設定，TUN 則在更接近網路層的位置運作。不過，特定連線是否會被接管，仍取決於路由、排除項目、位址族與執行權限。「啟用 TUN」開關亮起，只代表系統嘗試啟用功能，不表示所有流量都已依預期處理。

先確認一般連線正常，再擴大接管範圍

啟用前先關閉 TUN，透過一般系統代理完成一次正常連線，確認所選伺服器與基本協定參數可用。接著記下目前的路由預設、系統 DNS 及其他網路工具狀態。桌面用戶端可能以獨立元件或不同設定結構處理 TUN；主連線使用 Xray，不代表可以直接將 Xray 路由欄位填入另一個元件的 TUN 設定。請從用戶端介面支援的欄位開始設定。

第一次啟用時，依系統提示授予必要權限，等待虛擬介面與路由安裝完成後，再啟動測試應用程式。不要快速連續切換開關；啟動失敗後立刻再次開啟，可能受到舊程序或介面狀態干擾。先查看啟動日誌，確認是否有權限不足、介面建立失敗或位址衝突，再決定是否重試。涉及驅動程式或系統服務時，關閉介面不一定代表背景元件已停止。

避免回送，保留區域網路存取

接管系統流量時，用戶端連往代理伺服器的外層連線必須能正確連上網路，不能再被自身的接管規則無限送回。用戶端通常會處理伺服器位址繞行、程序排除或介面綁定，但自訂路由與多層代理可能破壞這些保護。若啟用 TUN 後所有連線突然中斷，先確認外層連線是否形成回送，再檢查節點參數是否真的有變更。

區域網路服務需要個別驗證。印表機、路由器管理頁面與本機開發服務可能使用私人位址，也可能先透過區域網路名稱解析取得位址。只新增私人位址直連規則，未必能解決本機名稱探索問題；也要檢查相關查詢、廣播或多點傳送是否會被目前的實作接管。不要只為了連上一台區域網路裝置，就大範圍排除所有網段；應優先設定實際需要的範圍。

「允許來自區域網路的連線」與 TUN 也不是同一個開關。前者通常會影響代理的監聽位址，以及其他裝置能否連入本機連接埠；後者則負責接管本機流量。若不需要其他裝置使用本機代理，就不必擴大監聽範圍。確有需求時，也應檢查防火牆、驗證選項與可信任網路範圍，避免將代理連接埠暴露在不必要的網路介面上。

UDP 能否正常使用，取決於應用程式流量是否進入接管範圍、用戶端相關元件是否支援，以及所選協定與伺服器路徑是否允許 UDP。即時通訊失敗不能只歸因於 DNS；也可能是 UDP 轉送、目標連接埠或路徑受到限制。先用一般網頁確認基本連線，再以實際使用的應用程式測試 UDP，不要拿只測 TCP 的成功結果代替完整驗證。

找出衝突來源並分層復原

其他 VPN、虛擬機器網路、容器網路與企業網路工具可能同時修改路由或 DNS。排查時一次只保留一套流量接管工具，先停止其他接管功能，而不是直接解除安裝軟體。觀察問題是否隨特定介面的啟用或停用而出現，並記錄介面與網段的關係。從睡眠中喚醒、切換無線網路或改用有線網路後失效，通常還要檢查出口介面是否已重新正確選取。

復原時先關閉 TUN，確認背景元件已退出，再檢查系統代理、DNS 與預設路由是否恢復預期狀態。如果一般網路仍不正常，再依照系統網路設定恢復先前記錄的值。不要一開始就重設所有網路設定。macOS 權限問題可參考安裝授權與網路權限設定步驟；Android 背景中斷則應另外檢查應用程式的省電策略。

FakeDNS

FakeDNS 會以合成位址取代真實解析結果，並儲存「合成位址對應網域」的映射。應用程式連線至合成位址時，核心會利用映射找回網域，再進行路由或代理處理。FakeDNS 的用途是保留網域關聯，並減少部分預先解析的步驟；它不會提供可直接在公用網路存取的真實伺服器位址。了解這一點，才能判斷為何繞過接管後連線會立即失敗。

先確認 DNS 與連線由同一條路徑處理

使用 FakeDNS 的前提是，產生合成回應的元件與接收後續連線的元件能共用映射。如果 DNS 由一個元件接管，連線卻交給不認得映射的另一個元件，最後只會得到無法連線的合成位址。桌面用戶端可能在不同模式下使用不同核心，切換前請確認實際實作。不要因為兩處設定都叫 FakeDNS，就認定設定格式與映射生命週期完全相同。

以下片段示範 Xray 的相關欄位：建立位址池、指定內建 DNS 使用 FakeDNS，並在指定入站啟用對應的嗅探覆寫。三個部分應分別合併至完整設定中的同名層級；尤其不能用入站物件片段取代整個入站，因為監聽位址、連接埠與協定等原有欄位仍須保留。只有相關設定路徑完整連通，這些欄位才會共同生效。

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

對應入站的嗅探設定範例：

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

ipPool 用來指定合成位址池，poolSize 則限制映射容量。範例位址範圍僅供測試，不能當作一般公用網路目標直連。設定前請確認虛擬機器、實驗網路或企業內部網路是否已使用相同範圍。如果發生衝突，應依據所用核心支援的範圍規劃替代方案，並同步檢查接管路由；不能只修改位址池字串就算完成。

處理快取、映射遺失與應用程式相容性

映射通常依賴運作中的核心狀態。核心重新啟動後，應用程式可能仍快取舊的合成位址，而新執行個體尚未知道該位址原本對應哪個網域。這時可能出現重新啟動後部分應用程式失敗，清除快取後又恢復的情況。啟用或停用 FakeDNS 時，也要考慮系統解析快取、瀏覽器快取與長連線；依序重新啟動相關測試應用程式，避免把快取殘留誤判為規則錯誤。

部分應用程式會自行驗證位址類型、儲存解析結果，或將位址傳給另一個程序使用；合成位址可能因此造成相容性問題。區域網路名稱、裝置探索，以及某些直接使用 IP 的服務，也未必適合全部納入 FakeDNS。若只有單一應用程式異常，先以真實解析結果作為對照，再考慮依網域或應用程式排除；排除位置與語法應以實際使用的 DNS 元件為準。

如果某條規則將合成位址範圍直接排除並送往系統網路，連線可能在還原網域前就離開接管路徑。反過來，只替合成位址新增「代理」規則也未必正確，因為核心可能在比對前就已還原原始網域。請檢查日誌中的最終目標資訊，確認目前實作是先還原還是先比對，再調整規則。不要將真實位址的分流經驗原封不動套用到合成位址。

切換設定進行對照，確認效益與限制

進行對照時，固定伺服器、路由預設與測試應用程式，只切換 FakeDNS。先確認目標網域取得的是合成位址，再觀察後續連線是否還原為網域，以及最終出站是否符合規則。如果看不到合成結果，可能是應用程式繞過了該 DNS；如果取得合成結果卻無法連線，應優先檢查接管範圍、映射與入站還原能力，而不是繼續更換解析伺服器。

停用時，先讓應用程式停止建立新連線，再關閉相關功能並清除舊快取，最後以真實解析重新測試。FakeDNS 並非每套設定都必須使用；一般 DNS 與路由已符合需求時，可維持現狀。只有明確需要網域關聯，且能維護完整接管路徑時，才應導入。遇到難以解釋的故障時，改回真實解析通常是最有價值的第一組對照測試。

多訂閱管理

管理多個訂閱的重點，不是把所有來源塞進同一份清單，而是維持來源、更新路徑與使用目的之間的對應關係。建議依來源建立獨立分組，並在備註中說明用途。工作、家庭或測試用途可各自採用命名規則，但不要把密碼、帳號或完整訂閱網址寫進名稱。分組備註應讓日後仍能看懂設定，而非只有匯入當天才看得懂。

記錄來源並安排更新頻率

每個分組至少記錄來源用途、更新方式與篩選條件，資料只要保存在自己的裝置即可。自動更新間隔應符合實際需求與提供者限制，不要只為了讓清單「看起來很新」而頻繁發送請求。增加請求次數不會讓訂閱內容自動變好，反覆更新還可能觸發流量限制。更新失敗時，先保留上次可用的設定，再調查該分組的問題，不要同時修改所有來源。

首次整理時，依分組逐一更新，確認每個來源都能獨立取得並解析內容，再考慮批次更新。這樣才能辨別是哪個網址失效，以及哪個分組需要調整請求路徑。如果批次更新只有部分失敗，先檢查失敗分組的回應與授權狀態，不要立刻更改全域 DNS 或代理模式。全域變更會影響原本正常的分組，也會擴大故障範圍。

同一來源可能提供多種格式的入口，光看網址外觀無法判斷內容是否相同。請選擇與用戶端相容的入口並保留必要參數；不要混淆網頁控制台網址與訂閱網址。如果網址需要登入或已過期，用戶端無法透過重試修復授權。此時應透過原提供者的正式管理介面重新取得有效入口，而不是在用戶端自行拼湊猜測的路徑。

分清重複名稱、重複設定與目前選取項目

伺服器備註不是唯一識別方式。不同來源可能使用相同備註，卻連往不同伺服器；同一部伺服器也可能因備註變更而看起來像新增項目。判斷是否重複時，應在本機比較實際協定、位址、連接埠與身分參數，避免只按名稱刪除。用戶端的去重方式可能有自己的判斷標準，執行前先確認影響範圍；必要時匯出目前設定，為誤刪預留復原方式。

更新訂閱可能會取代伺服器物件，也可能改變排序與備註。目前選取項目是否保留，取決於用戶端如何比對新舊設定，不能假設永遠不變。每次大幅更新後，先確認目前的分組與所選伺服器，再恢復日常使用。如果原項目已從遠端移除，請重新選取實際可用的項目，不要只因清單位置相同就認定連線目標沒有改變。

訂閱中的項目通常由提供者管理，手動修改欄位可能在下次更新時被覆蓋。需要長期保留的自訂設定，應放在明確獨立的手動分組中，並記錄修改原因。不要在多個分組中複製同一部伺服器，卻沒有標明用途，否則排錯時容易改錯項目。確認設定來源，比把備註寫得很複雜更重要。

遷移、備份與隱私界線

遷移至另一台裝置前，先確認要搬移的是用戶端設定、訂閱來源，還是單一伺服器設定。不同匯出方式包含的資訊不同，QR Code 與分享連結也可能帶有完整的連線身分資料。請只透過可信管道傳送，完成後刪除不必要的暫存副本。公開求助時，請以刪減後的設定說明取代完整匯出檔；日誌中的訂閱路徑與查詢參數同樣需要處理。

桌面版 v2rayN、Android 版 v2rayNG 與 v2flyNG 可匯入相容的訂閱內容，但圖形介面的分組設定、路由預設與應用程式範圍不一定會隨訂閱一併遷移。尤其是自訂路由與 DNS，應在新裝置上依其核心重新設定並驗證。安裝套件請見用戶端安裝套件頁面；不要只依舊裝置的檔名判斷新裝置的架構。

Android 背景連線中斷，也可能是省電限制造成，而非多訂閱互相衝突。先確認應用程式在前景執行時能正常連線，再檢查 VPN 授權、分應用程式範圍與背景限制；相關步驟請參閱v2rayNG 分應用程式代理與省電白名單設定。長期管理時，定期移除已確認失效的來源並保留有用紀錄，讓清單規模符合實際需求。

自訂出站

自訂出站用來設定一般用戶端介面以外的連線路徑，例如將指定目標交由本機另一個代理監聽連接埠處理。這涉及出站協定、標籤引用、監聽可達性與防止回送，不只是新增一條規則。編輯設定前，先釐清「應用程式進入哪個入站、規則選中哪個標籤、該標籤連往何處」，再開始修改。還不熟悉一般代理路徑時，不建議直接疊加多層自訂轉送。

以本機 SOCKS 出站建立最小範例

以下是 Xray 格式的三個出站物件，分別代表直連、封鎖，以及連線至本機 SOCKS 服務。請將它們合併到完整設定的 outbounds 陣列，不要直接取代既有陣列，否則可能刪除目前的伺服器出站或改變預設順序。本機位址只代表連線目標，連接埠必須與實際執行的服務一致；如果沒有對應的監聽服務，設定即使成功載入也無法轉送。

[
  {
    "tag": "direct",
    "protocol": "freedom",
    "settings": {}
  },
  {
    "tag": "block",
    "protocol": "blackhole",
    "settings": {}
  },
  {
    "tag": "local-socks",
    "protocol": "socks",
    "settings": {
      "servers": [
        {
          "address": "127.0.0.1",
          "port": 1080
        }
      ]
    }
  }
]

此範例未設定驗證，僅適用於目標監聽服務本身允許連線的情況。若實際服務需要驗證，請使用該核心支援的使用者欄位，並只在本機保存真實身分資訊。不要為了省略設定而擴大監聽範圍或停用既有驗證。回送位址指向執行核心的同一個網路環境；如果核心在容器或隔離環境中執行，該位址不一定會指向主機上的服務。

準備好出站後，再新增一條條件最明確的測試規則。以下使用保留的範例網域說明標籤引用，不代表該網域提供實際服務。實際驗證時，請換成自己明確要測試的目標，並將規則保留在適當位置。outboundTag 必須與出站的 tag 完全一致；大小寫、連字號與拼字都不能任意更改。

{
  "type": "field",
  "domain": ["full:example.com"],
  "outboundTag": "local-socks"
}

了解轉送與代理串接的差異

將業務連線交給本機 SOCKS 服務，表示由該服務繼續處理後續連線；這不代表多部代理伺服器已依指定順序串接。真正的代理串接還需要明確設定外層連線如何撥號、網域在哪一層解析，以及各層如何驗證。不同核心的串接欄位並不通用，不能把 sing-box 的欄位名稱直接搬到 Xray 設定中，也不要因為名稱相似就認定行為相同。

最危險的錯誤，是讓兩套代理互相指向：用戶端甲把請求交給乙，乙的上游卻又回到甲；或者 TUN 將本機代理的外層連線再次送回原入站。排查時從最終出口反向追蹤，確認每一跳都能連到下一跳，並且有明確的終點。先關閉 TUN，以單一應用程式代理驗證自訂出站，再逐步恢復系統層級的流量接管，能大幅縮小問題範圍。

多個出站也會放大 DNS 與 UDP 的差異。某個本機 SOCKS 服務能處理 TCP，不代表它也支援所需的 UDP 轉送；網域由前一層解析或交給後一層解析，也會影響規則與連線能力。測試時應分別檢查網域目標、位址目標與實際應用程式協定，不要把「連接埠已建立連線」當成整條路徑都已驗證完成。

保存設定、檢查結果與復原方式

優先使用用戶端提供的自訂設定、出站或路由編輯介面。有些介面接受完整設定，有些只接受物件片段；貼上前先確認介面說明與現有結構。JSON 的物件、陣列與字串都必須符合格式，不能加入註解或尾隨逗號。標籤重複、引用不存在的標籤，或將陣列放入物件欄位，都可能造成啟動失敗或難以察覺的覆寫。

儲存後先確認核心是否成功載入，再建立一條全新的連線，檢查日誌中的出站標籤與目標監聽服務是否一致。如果載入失敗，先還原修改前的設定，不要同時更換伺服器或更新訂閱。如果載入成功但連線遭拒，請檢查本機服務是否已啟動、監聽位址是否正確，以及連接埠是否一致；如果連線已建立但後續仍失敗，再沿下一跳檢查協定、驗證與解析。

設定方案穩定後，記錄用途、相依服務、監聽連接埠與復原步驟，避免下次啟動時忘記先執行上游服務。核心與用戶端的關係請參閱Project V、V2Fly 與 Xray 生態說明；跨章節問題可至常見問題依照現象查找。請始終保留一套可用的一般系統代理基準設定；自訂出站發生問題時，先回到這條最簡單的路徑。