進階設定手冊

訂閱分組與伺服器篩選

分組結構：來源、用途與可追溯性

訂閱分組的用途是標示「這些伺服器來自哪裡」，不能取代路由策略。建議先按設定來源建立獨立分組，再於備註註明用途，例如日常連線、臨時測試或核心相容性驗證。分組名稱只方便整理與選取，不會自動決定特定應用程式的流量走向；若要依網域或位址選擇出口，仍須設定路由。

操作入口：在 v2rayN 的訂閱分組設定中新增分組，填入容易辨識的名稱，並將訂閱網址填入該分組的網址欄位。儲存後只更新這個分組，先確認解析成功，再檢查伺服器清單是否歸入預期位置。不同版本的選單名稱可能不同；尋找設定入口時，請核對「分組名稱、訂閱網址、更新」等欄位，不要只依照截圖座標操作。

資訊保護：訂閱網址通常包含可辨識帳戶的路徑或參數，應視為存取憑證。分組備註不要貼上完整網址，排錯截圖也應遮蔽敏感資訊。將設定匯出交給他人前，也要檢查伺服器位址、使用者識別資訊與驗證欄位；只刪除訂閱連結，不代表匯出的伺服器設定已完成去識別化。

篩選規則：先確認比對對象

伺服器篩選：先確認目前篩選的是訂閱回傳內容、已匯入的伺服器，還是介面正在顯示的清單。搜尋框通常只會變更可見範圍，不會刪除設定；訂閱篩選則可能影響下次匯入結果。兩者混用時容易誤以為伺服器遺失，實際上可能只是顯示條件仍在作用，或更新時被篩掉。

比對語法：不同篩選欄位不一定都支援正規表示式，也不一定採用相同的大小寫規則。先用一個確定存在的短詞測試，再嘗試組合條件。若設定入口標示支援正規表示式，可用 辦公|測試 比對備註中的任一詞；若只支援一般文字，這段內容可能會被視為完整字串，因而找不到結果。

逐步收緊條件：先保留較寬的比對範圍，確認所需設定出現後，再逐步加入排除條件。不要一開始就使用複雜的反向比對，因為節點備註可能被來源方改名，括號、空格與地區縮寫也不一定固定。是否支援某項協定，應檢查設定本身與核心記錄，不要只憑備註中的關鍵字判斷。

更新驗證：區分下載失敗與解析失敗

更新路徑：訂閱更新是由用戶端發起的網路請求，與瀏覽器目前能否開啟網頁並非同一項測試。若無法透過直連取得內容，可評估「更新訂閱時使用代理」等設定，但前提是已有可用出口。首次匯入時尚未建立連線，啟用代理更新可能造成依賴循環；應先確認基本連線路徑。

解析結果：更新顯示成功後，不要只看項目總數變化，還要檢查協定類型、位址、連接埠與分組歸屬。回傳內容可能是過期提示頁或驗證頁面；網路請求成功，不代表取得的就是有效訂閱。若記錄顯示格式異常，先確認網址是否完整、訂閱是否過期，再判斷目前用戶端是否支援該格式。

本機修改：手動調整過的訂閱伺服器，可能在下次更新時被取代。若要長期保留變更，請使用用戶端支援的獨立設定，或複製到人工維護的分組，並記錄與來源設定的差異。不要在多個分組中反覆編輯同一項設定，否則排錯時難以確認實際啟用的是哪一份。

復原順序：伺服器數量突然減少時，先清除清單搜尋，再停用新增的篩選條件，最後只更新受影響的分組。先比對錯誤記錄與原始設定類型，不要立刻刪除所有訂閱重建。更新失敗的詳細排查方式，請參閱v2rayN 訂閱更新失敗與自動更新設定；若涉及多個來源的維護時程，請接著閱讀多訂閱管理。

路由規則實作

請求路徑：入站、比對與出站

路由模型：應用程式請求先進入某個入站，核心再依目標網域、目標位址、連接埠等條件比對規則，並將連線交給相應出站。系統代理或 TUN 決定請求能否進入這條路徑；路由只處理已交由核心處理的流量。因此，應用程式若未使用本機代理，反覆修改網域規則通常不會改變連線結果。

比對順序：規則通常依排列順序逐一檢查，第一條符合的規則會決定出站。請將範圍明確的例外規則排在前面，再列出涵蓋範圍較廣的規則。同一規則物件中的不同條件通常必須全部符合；同一條件陣列中的項目通常則符合其一即可。若將網域條件與位址條件放在同一物件中，匹配範圍可能比預期更窄。

協定範圍：VMess、VLESS 與 Trojan 是連線協定；REALITY 則屬於傳輸安全相關設定，不能取代路由。節點能匯入，只代表用戶端識別了設定格式，不代表每個執行核心都支援所有欄位。選擇協定應以伺服器端參數為準，再確認實際啟動的核心；不要為了符合某條分流規則而更改節點協定。

規則片段：局部合併與標籤確認

範例用途：以下是 Xray 路由的局部片段，會將私有位址與中國大陸網域集合交由名為 direct 的出站處理。使用前請確認該出站已存在，且本機有可讀取的規則資料檔案。這段片段沒有定義代理出口，也沒有指定所有未符合規則的請求要如何處理，因此不能據此認定其餘流量必定經由代理。

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

標籤對應：outboundTag 是對出站識別標籤的參照，不是任意設定的顯示名稱。用戶端可能會產生其他標籤，引用前必須查看實際生效的設定。若儲存時檢查通過，執行時卻提示找不到出站，請先確認標籤的大小寫與拼寫；若用戶端重新產生設定後標籤改變，應改用受支援的路由編輯入口處理。

網域策略：AsIs 優先使用現有網域資訊比對，不會為了位址規則主動進行解析；IPIfNonMatch 會在網域未符合時嘗試解析，再繼續比對位址；IPOnDemand 則會在規則需要位址資訊時觸發解析。後兩者可能增加對解析流程的依賴，不能簡單理解成解析越積極就越準確。

比對驗證：透過記錄區分規則與連線問題

資訊來源：應用程式透過 SOCKS 傳入網域時，核心可以直接比對網域；若應用程式先自行解析，只傳入位址，可用資訊就不同。流量嗅探可能從部分協定中找回網域，但並非所有連線都能識別。若記錄中只有位址，請先確認請求攜帶的資訊，再判斷是否需要嗅探、調整 DNS 或搭配 TUN。

驗證方式：選一個目標明確的操作，暫時減少背景應用程式干擾，查看連線使用的入站、目標與出站標籤。若符合預期的出站但連線仍失敗，應檢查該出口的連線能力與伺服器端設定；若出站不符，才繼續檢查規則順序、網域是否可見，以及位址集合是否涵蓋目標。不要用網頁載入速度代替路由符合規則的證據。

預設處理：自訂設定中，未符合規則的流量通常會交給預設出站；預設出站可能與出站清單順序有關。圖形介面用戶端也可能自行產生預設規則。新增或調整出站順序前，應先確認這項行為。若將直連出站移到前面，原本經代理處理的未符合規則請求可能改走直連，影響範圍遠大於新增一條規則。

復原方式：每次只新增一類條件，並保留修改前的規則順序與目前出口記錄。發生異常時先停用新規則，再重新啟動核心或建立測試連線，因為既有連線未必會重新比對規則。若要了解規則集合名稱，請參閱名詞解釋；若規則符合預期但仍無法連線，再依照節點逾時排查順序逐步檢查。

DNS 設定最佳化

解析分層：先確認由哪一層查詢

解析路徑：系統解析器、瀏覽器內建的安全 DNS、用戶端內建 DNS 與伺服器端解析可能同時存在。修改用戶端 DNS，不一定會改變瀏覽器自行送出的解析請求；啟用系統代理，也不代表系統的所有查詢都會進入核心。最佳化前先釐清實際路徑，確認應用程式送出的是網域還是位址，以及最後由哪一層選擇解析伺服器。

問題分類：網域無法解析、解析結果無法連線、解析速度過慢，以及路由目標錯誤，都是不同問題。若已取得位址但連線逾時，繼續更換解析伺服器未必有用；若同一網域在不同網路取得不同位址，也不必立刻認定異常，分散式服務本來就可能依來源位置回傳不同結果。應搭配連線記錄與目標網路狀況判斷。

目標限制：DNS 最佳化不是不斷增加公共 DNS 伺服器，而是減少不必要的相依關係。若核心啟動時需要解析節點伺服器網域，而解析請求又設定為必須經過尚未連線的節點，就會形成啟動循環。應保留一條能在目前網路中完成基本解析的路徑，再逐步調整服務網域的查詢方式。

欄位比較：位址族與網域查詢

基本範例：以下是 Xray 內建 DNS 的局部寫法，用來說明查詢伺服器與位址族的選擇。位址僅用於示範設定結構，使用前請確認目前網路可連線，且符合自身解析需求。這段片段不會自動將系統 DNS 重新導向核心，也沒有指定查詢流量要經由哪個出站，因此無法單獨接管整台裝置的解析。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "1.1.1.1"
    ]
  }
}

查詢範圍：伺服器物件中的 domains 用來指定優先交由該伺服器處理的網域集合，但不能只憑這個欄位就斷定其他伺服器永遠不會收到相關查詢。回退機制、預期位址條件與核心實作都會影響後續嘗試。若要嚴格限制查詢去向，應進一步查閱目前核心支援的回退欄位，並透過記錄或本機網路觀察進行驗證。

位址族選擇：網路具備可用的雙堆疊連線時，不應只為了減少記錄就永久限制位址族。暫時使用 UseIPv4 有助於判斷故障是否與另一個位址族有關；測試成功後，仍應檢查系統路由、出口能力與伺服器端監聽設定。內建 DNS 的選擇只會限制相關解析操作；若應用程式直接提供位址，並不會因此轉換位址。

快取與回退：讓測試結果更明確

快取干擾：調整解析伺服器後，系統、瀏覽器與用戶端都可能繼續使用快取。先關閉既有連線，再依實際涉及的元件清除快取或重新啟動應用程式，不必每次都重開整台裝置。記錄修改前後的回傳位址與出口標籤，才能分辨設定是否確實生效，或只是碰巧沿用仍可連線的舊位址。

回退取捨：設定備用伺服器可在單一路徑故障時提升可用性，但也會讓解析行為更複雜。若所有伺服器都逾時，問題可能出在查詢使用的出站或目前網路，而不是網域本身。若只有特定網域異常，應先確認網域集合是否符合及回傳位址是否正確，避免全面更換 DNS，連帶影響其他正常運作的應用程式。

本機網路：印表機、區域網路主機與內部服務可能依賴路由器解析或本機搜尋網域。若將所有查詢都送往公共伺服器，這些名稱可能無法解析。應為明確的內部網域保留本機解析路徑，並確認存取位址仍經由直連出站；只補上一筆解析紀錄，卻將對應私有位址送往遠端出口，同樣無法正常存取。

完整驗證：先在系統代理模式確認一般網域能解析並連線，再啟用 TUN，最後才評估 FakeDNS。每個步驟都應保留可復原的設定，不要同時修改位址族、查詢伺服器與路由策略。若遇到憑證名稱不符，請改查TLS 握手與 SNI 排查方式，不要以停用憑證驗證來掩蓋解析或設定錯誤。

TUN 模式

接管範圍：虛擬網卡不等於出口

TUN 的用途：虛擬網卡會將符合系統路由的網路流量交由使用者空間處理，適合不遵循系統代理設定的應用程式。它解決的是流量如何進入用戶端，不會自動修復節點驗證、伺服器無法連線或路由規則錯誤。啟用後仍需要可用出口、正確的 DNS 路徑，以及不會反覆接管用戶端自身連線的系統路由。

模式差異：系統代理依賴應用程式讀取系統代理設定；TUN 則在更接近網路層的位置接收封包。在某些環境中兩者可以並用，但初次排錯時建議先只驗證一種流量接管方式。瀏覽器正常而其他應用程式異常，可能只是後者未使用系統代理；不能因此推斷所有節點或核心都需要更換。

核心分工：桌面用戶端的 TUN 功能可能由獨立元件與代理核心協作完成，實際設定欄位與權限需求取決於使用的組合。不要將網路上的某份含有 tun 欄位的設定直接貼進任意 Xray 設定。建議優先使用 v2rayN 提供的 TUN 設定入口，並查看啟動記錄，確認相關元件確實運作。

啟用流程：從基準狀態到系統路由

連線基準：啟用前先在系統代理模式下，使用已知可用的伺服器測試，並記錄選取項目、路由模式與 DNS 設定。接著關閉其他可能修改路由或建立虛擬網卡的網路工具，避免多個元件爭用預設路由。先不要同時啟用 FakeDNS，讓一般解析與 TUN 接管各自形成可判讀的測試結果。

權限準備：在 Windows 上建立網卡或寫入路由可能需要提高權限；macOS 與 Linux 也可能要求系統授權或相應服務權限。實際需求請依用戶端提示處理。若開關一啟用就自動關閉，應檢查權限遭拒、元件啟動失敗或網卡建立錯誤，不要反覆點擊開關。取得授權後，也要確認路由確實已建立。

行動裝置行為：v2rayNG 與 v2flyNG 在 Android 上通常透過系統 VPN 介面接管流量，首次啟動時需要確認系統授權。這與桌面 TUN 的實作方式不同，不應逐項照搬桌面設定。系統中其他使用相同介面的應用程式可能與其互斥；切換前請確認目前由哪個用戶端負責接管流量。

接管驗證：先測試先前不遵循系統代理的應用程式，再查看用戶端連線記錄是否出現相應目標。接著檢查一般網頁、區域網路服務與訂閱更新是否仍可使用。只看到網卡存在或圖示顯示已連線並不足夠，因為網卡建立成功後，DNS 路由、出口路由與應用程式存取仍可能各自失敗。

常見衝突：繞過、迴圈與封包大小

自身流量繞行：代理元件連接伺服器的流量必須有正確的繞行方式，否則可能再次進入虛擬網卡，形成迴圈。用戶端通常會自動產生相關路由，但手動修改預設路由、介面綁定或自訂出站，可能破壞這些設定。若記錄持續顯示重複建立同類連線，而且所有存取都異常，請先停用新增設定，還原用戶端的預設接管方式。

區域網路存取：遠端桌面、印表機或內部位址無法使用時，先確認私有網段是否被接管，再檢查路由是否將其導向直連出站。部分網路中的內部資源不使用標準私有位址，因此只新增私有網段規則未必足夠。請依實際網段新增範圍最小的例外，不要為了存取單一資源而繞過整段無關流量。

封包大小：若部分網站可開啟，但大型檔案或長連線卡住，可將 MTU 列為後續排查項目，不要一開始就任意修改。先排除 DNS、協定與伺服器問題，再透過用戶端提供的設定入口逐一測試，並保留原始數值。不同網路的封裝負擔各異，沒有適用於所有裝置與連線的固定最佳值。

穩定性確認：從睡眠狀態喚醒、切換無線網路或更換預設網卡後，都應重新驗證，因為舊介面與舊路由可能已失效。確認基本接管穩定後，再加入網域分流或 FakeDNS。常見概念差異可參閱常見問題；首次連線尚未完成時，請回到設定教學主線，避免在多個尚未驗證的層次間反覆修改。

FakeDNS

對應原理：以虛擬位址保留網域資訊

運作方式：FakeDNS 不會直接回傳目標伺服器的真實位址，而是為網域指派一個對應位址。應用程式接著連線至該位址時，配套處理元件會依照對應表找回原始網域，再交由路由或出站處理。它的用途是讓只傳送位址的流量仍保留網域關聯，並不是讓遠端網路出現一台使用該位址的真實伺服器。

適用條件：應用程式的查詢必須進入指定的 FakeDNS 解析路徑，後續連線也必須由能讀取這份對應資料的元件接收。只完成其中一半就會失敗：系統取得虛擬位址後若直接送往一般網路，通常無法抵達真正目標；反之，若連線已被接管，但查詢繞過對應服務，也無法憑空還原關聯。

路由效益：網域規則涵蓋完整，且應用程式傾向先解析再連線時，位址映射有助於維持網域層級分流的一致性。但它無法修正錯誤的規則順序，也不能取代真實 DNS 的所有用途。若應用程式直接存取固定位址，或使用自己的加密解析管道，仍可能不經過這套映射流程。

設定關係：位址池、解析入口與嗅探

結構範例：以下片段展示 Xray 中位址池與 DNS 服務的關聯寫法。198.18.0.0/15 是供基準測試使用的位址空間，不是遠端服務的真實位址。設定前請確認它不會與現有網路規劃、其他虛擬網卡或測試環境衝突；若有重疊，應先處理位址規劃，不要直接啟用。

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

入站配合：負責接收這些連線的入站也必須能還原映射。以下僅展示可合併至相應入站物件的嗅探欄位，並未定義入站協定、監聽位址或連接埠。圖形介面用戶端可能已產生等效設定，請先查看實際設定，避免重複新增。不同接管元件管理的映射，不能只靠複製欄位就彼此共用。

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

核心差異：上述寫法用於說明 Xray 相關設定的關係，未經確認不可直接移植至 v2flyNG 或其他 TUN 元件。若用戶端提供 FakeDNS 開關，請優先使用該設定入口，並確認實際運作的核心。若沒有明確的支援資訊，保留一般 DNS 路徑，比勉強拼接不同實作的欄位更容易維護。

相容性與恢復一般解析

應用程式相容性：需要顯示真實解析位址、執行位址歸屬檢查、尋找區域網路裝置，或將解析結果直接交給其他程序的應用程式，可能不適合全面使用映射。部分程式也會快取虛擬位址，在用戶端停止後仍嘗試連線。若只有單一應用程式異常，先確認其查詢與連線是否經過相同處理路徑，再決定排除範圍。

快取期限：映射表與應用程式快取的生命週期不同，是重新啟動後偶發失敗的常見原因。核心重新啟動後，舊映射可能已不存在，但應用程式仍保留先前取得的位址。此時只更換節點未必有效；應先關閉舊連線、清除相關應用程式的解析快取，再重新查詢以建立新的映射關係。

驗證方式：啟用後，系統或應用程式查詢目標網域時，應取得映射池中的位址；同時用戶端應能將連線對應回原始網域，並選擇預期的出站。只看到保留位址不代表設定完整；還要確認服務連線成功、區域網路存取正常，且未使用映射的真實位址流量仍依原有規則處理。

停用順序：先關閉相關 FakeDNS 設定並恢復一般解析伺服器，再清除系統與應用程式快取，並關閉仍使用舊映射的連線。若只關閉虛擬網卡，卻保留應用程式快取中的映射位址，存取仍可能失敗。復原後應重新檢查 DNS 回傳值，確認不再將位址池中的結果當成遠端伺服器的真實位址。

是否採用：只有在一般 DNS 與 TUN 已穩定，且確實遇到網域資訊遺失問題時，才值得增加這一層。若主要故障是訂閱失效、伺服器逾時或驗證失敗，FakeDNS 無法改善這些環節。若想進一步了解映射原理與適用情境，請閱讀FakeDNS 原理與 v2rayN 啟用時機，並保留未啟用時的設定作為比較。

多訂閱管理

維護方式：來源隔離與統一命名

來源隔離：管理多個訂閱時，首先要確保各來源的更新範圍清楚，每個來源使用獨立分組，人工維護的設定則另行存放。不要只為了讓清單看起來整齊，就將所有伺服器複製到無法追溯來源的大型分組。發生失效、格式變更或更新覆寫時，來源清楚有助於縮小問題範圍，也方便只停用受影響的項目。

命名慣例：建議在分組名稱或備註中標明來源簡稱、用途與維護方式，但不要包含帳戶資訊或完整訂閱網址。節點備註可以保留來源提供的文字，必要時另加本機識別標記。手動重新命名能否在更新後保留，取決於用戶端實作；長期依賴備註的篩選規則應定期檢查，不要把備註視為永久不變的識別標記。

選取範圍：增加訂閱不會自動建立負載平衡、故障切換或應用程式分流。一般伺服器清單通常仍只有一個目前啟用的項目，多個來源只是提供更多設定選項。若要讓不同流量使用不同出站，應明確設定路由與出口的對應關係；不要把分組順序或清單排序誤認為核心選擇出口的優先順序。

更新時程：降低連動故障

手動驗證：新增來源時，先單獨匯入並更新，檢查協定類型與核心支援情況，再實際建立一次連線。確認可用後，才將其納入定期更新。若一開始就和所有舊來源一起更新，當前連線失效時，很難判斷是新增內容改變設定，還是原有來源也發生變更，增加排查成本。

自動更新間隔：更新頻率應依來源的設定變更速度與服務需求決定，不是越頻繁就越可靠。過於密集的請求可能造成無效更新，也可能觸發來源端限制。若用戶端支援個別分組更新，可按需求分別安排；若只支援統一間隔，應選擇容易穩定維護的頻率，並保留手動更新入口以因應臨時變更。

代理依賴：使用代理更新可解決部分來源無法直連的問題，但不要讓所有來源都依賴同一個尚未驗證的出口。若目前節點失效，代理更新也可能一起失敗，讓人誤以為所有訂閱都已失效。應先檢查更新請求使用的網路路徑，再確認連線狀態；必要時切換至已知可用的設定後，個別重試。

去重、移轉與備份範圍

去重原則：名稱相同不代表設定相同，位址相同也不代表驗證方式與傳輸參數一致。刪除重複項目前，應比較協定、連接埠、使用者識別資訊、傳輸方式與安全欄位。若自動去重只依據部分欄位，可能誤刪原本用於不同連線方式的設定；不清楚判定條件時，先在副本中測試，再處理主要分組。

跨裝置移轉：v2rayN、v2rayNG 與 v2flyNG 的訂閱解析、介面儲存方式與自訂設定支援範圍並不完全相同。移轉時應分別確認訂閱能否解析、節點能否運作，以及路由與 DNS 是否需要重新設定。成功匯入伺服器清單，不代表桌面端的 TUN、系統代理或所有自訂規則也已同步至行動裝置。

備份內容：至少保存分組結構、必要的訂閱資訊、本機獨立設定與規則設定，並存放於受控位置。不要只備份暫時產生的核心檔案，因為其中可能不包含介面端的來源資訊與更新設定。還原前先確認備份對應哪個用戶端及設定入口，避免將舊欄位覆寫至結構不同的新環境。

變更記錄：每次重大調整只需記錄必要的行為變更，例如某個分組改用代理更新、某項篩選條件放寬，或某條規則移至前面。不必保存敏感網址，也不要將含有憑證的設定貼到公開筆記。故障發生時，知道最後修改了哪一層，通常比保存大量未附說明的設定副本更有幫助。

停止使用來源：來源不再使用時，先確認目前伺服器、自動更新工作或自訂出口沒有引用它，再停用分組。確認其他來源可獨立正常運作後再刪除，避免留下無法解析的標籤引用。若只是暫時的網路故障，應優先暫停更新並保留現有設定；訂閱失效與解析問題可搭配常見問題及訂閱分組章節逐項確認。

自訂出站

核心與生態：先確認設定歸屬

核心關係：Project V 是理解這類代理工具生態背景的重要脈絡；V2Fly 與 Xray 則是需要區分的核心系列。圖形介面用戶端負責訂閱、介面與產生設定，核心負責執行實際連線。兩款用戶端介面相似，不代表能使用同一份設定；即使是同一用戶端，切換執行核心時也應重新確認協定與欄位支援情況。

Xray 設定：v2rayNG 採用 Xray 核心，v2flyNG 則是 V2Fly 核心的替代選項；v2rayN 的實際行為應以目前執行的元件為準。設定自訂出站前，先查看記錄中的啟動資訊與用戶端設定，確認使用的是哪一套設定。開放原始碼代表程式碼可供研究與維護，不代表不同實作的設定可以任意互換。

REALITY 範圍：REALITY 涉及連線安全相關參數，必須與伺服器提供的設定一致，並非本機分流開關。修改出口標籤、調整直連規則或新增本機 SOCKS 出站，都無法補正錯誤的伺服器名稱、公鑰等連線參數。使用這類節點時，應保留原始設定，先確認基本連線正常，再新增自訂連線路徑。

出站定義：直連與阻斷的最小結構

定義方式：出站物件以 tag 提供路由可引用的識別標籤，並以 protocol 指定行為。以下展示 Xray 中直連與阻斷出站的局部清單，標籤僅供示範，須與前面的路由片段相對應。合併至既有設定時，不要覆蓋原有代理出站，也不要在尚未確認預設行為前改變整份清單的順序。

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

預設行為：這段片段沒有遠端代理出口，也不是完整路由。若將它當成完整出站清單使用，未符合規則的請求可能會預設走第一個直連出站。阻斷出站也只有在規則選中時才會生效。新增物件後，應先確認產生的設定與預設出口，再用一條範圍明確且較小的規則，測試標籤引用是否正確。

本機上游：避免連線回到自身

鏈式轉送：有時需要將特定請求交由本機另一個受控的 SOCKS 服務處理。以下片段定義名為 local-upstream 的出站，並連線至回送位址的指定連接埠。使用前提是該連接埠確實有相容服務在監聽，而且不是目前用戶端接收同一批流量的入站；若沒有上游服務，這段設定本身不會提供可用出口。

{
  "tag": "local-upstream",
  "protocol": "socks",
  "settings": {
    "servers": [
      {
        "address": "127.0.0.1",
        "port": 10810
      }
    ]
  }
}

迴圈檢查：若本機入站也監聽相同位址與連接埠，轉送流量可能重新進入自身，造成連線遞迴或迅速失敗。使用 TUN 模式時，也要確認上游程序的外連不會再次被接管，形成另一種迴圈。應先獨立驗證上游，再讓一條測試規則指向該上游，最後才擴大使用範圍；不要一開始就接管所有流量。

能力確認：SOCKS 上游是否支援驗證、網域傳遞與 UDP，必須分別確認。網頁存取成功只能證明相關連線路徑可用，不能證明所有類型的資料都能轉送。若只有部分應用程式失敗，應檢查請求類型與上游能力，不要立刻複製更多代理欄位，徒增難以觀察的巢狀層次。

生效檢查：入口、語法與持續保存

編輯入口：完整自訂設定模式與介面產生設定模式，通常由不同元件負責維護。前者可能需要自行定義入站、路由、DNS 與出站；後者則由用戶端保留部分控制權。儲存前先確認哪些欄位會遭覆寫，以及切換節點後自訂內容是否仍保留；不能只因暫存檔曾出現某個欄位，就認定設定會持續生效。

錯誤分類：啟動時立即失敗，先檢查 JSON 逗號、括號、欄位類型與協定名稱；成功啟動但規則未符合時，檢查路由標籤；規則符合後仍無法連線，再檢查監聽、驗證與網路連線能力。可在受控測試期間暫時提高記錄層級；完成排查後，請恢復常用層級，並避免公開分享含有目標位址與驗證資訊的完整記錄。

維護原則：每新增一層出站，都應說明輸入來自何處、輸出交給哪個元件，以及失敗時如何復原。若無法回答這三個問題，應優先保留用戶端預設設定。安裝檔與元件選擇請回到安裝檔頁面確認；基本連線驗證請回到設定教學。待連線穩定後，再依本手冊逐層加入路由、解析與流量接管設定，避免將多個獨立故障混成一個無法重現的問題。