V2Ray 進階設定

訂閱分組與伺服器篩選

訂閱分組用來管理來源與更新範圍，伺服器篩選則用來縮小目前顯示的清單。兩者都不會自動變更伺服器端協定，也不等同於路由分流。建議先依來源建立分組，再按用途篩選；不要把所有項目混在一起，再靠名稱猜來源。排查時務必確認三件事：項目來自哪個網址、最近一次更新是否成功，以及目前選取的項目是否仍屬於該分組。

建立可追溯來源的分組

在 v2rayN 的訂閱分組設定中新增分組，填入簡短別名與訂閱網址，儲存後單獨更新該分組。先只更新新分組，不要立刻更新所有來源。確認伺服器清單出現項目後，開啟其中一個項目的編輯畫面，核對網址、連接埠與傳輸類型。不同發行版本的介面文字可能有差異，請依「訂閱」、「分組」與「更新」對應的功能操作，不要把按鈕位置當成固定條件。

v2rayNG 與 v2flyNG 也應先建立訂閱記錄，再更新選取的訂閱。從剪貼簿匯入單一分享連結，通常只會新增伺服器項目，不會自動建立可持續更新的訂閱關係。若希望後續更新能同步來源變更，請使用訂閱網址匯入功能，不要把回傳內容逐項貼進清單。詳細操作請參閱訂閱連結匯入步驟與格式說明。

分組名稱應清楚表達管理用途，例如「日常連線」、「測試設定」或「備用來源」。名稱不能用來判斷協定能力；同一分組中的項目也可能使用不同協定與傳輸方式。訂閱網址可能包含存取憑證，請勿放入螢幕截圖、公開文件或共用記錄。記錄來源時只保留容易辨識的別名與必要備註；完整網址留在用戶端內部，移轉時再透過受控方式處理。

先檢視完整清單，再逐步篩選

篩選前先清除搜尋框、地區條件與協定條件，確認完整清單確實存在。接著每次只新增一個條件，例如先用名稱關鍵字搜尋，再篩選協定類型。名稱搜尋只會比對文字，無法證明伺服器的地理位置或實際出口位置。若清單突然變空，先還原篩選條件，再檢查訂閱更新；不要直接判定來源失效，更不必因此刪除整個分組。

部分用戶端或分支版本支援正規表示式篩選，但一般搜尋框不一定會以正規表示式比對。只有介面明確提供正規表示式模式時，才使用運算式。以下範例用來比對獨立出現的三種用途標籤，並非核心 JSON。使用前先以少量現有名稱測試，確認大小寫、分隔符號與空白處理都符合預期；若沒有相應模式，請逐一使用關鍵字篩選，不要勉強貼上。

(^|[\s_-])(work|daily|backup)([\s_-]|$)

排序與篩選也要分開看。依測試結果排序只會改變顯示順序，不一定會切換目前使用的伺服器；測試通過也不代表所有目標都能連線。選取項目後請確認啟用標記，再實際瀏覽網頁。不要只看清單最上方的項目，就認定已完成切換。測試用項目應放在獨立分組，避免臨時排序後誤將不適用的設定用於日常連線。

處理更新覆蓋與本機修改

訂閱更新通常會依用戶端策略重建或取代來源項目；本機修改名稱、連接埠或傳輸參數可能會被覆蓋。需要長期保留的手動設定，請複製到獨立的手動管理區域並記下修改原因；不要只修改訂閱項目，就以為下次更新後仍會保留。複製前請確認複製的是完整連線參數，而不只是顯示名稱，以免得到缺少驗證或傳輸欄位的項目。

更新後若項目減少，先清除篩選並查看該分組的更新結果，再判斷是來源撤回、格式不相容還是請求失敗。保留目前仍可用的連線，避免連續刪除與重新匯入，導致排查線索遺失。若回傳內容為空或解析失敗，請依照訂閱更新失敗自我檢查步驟排查。修復後只更新發生問題的分組，確認成功再恢復全面管理。

路由規則實作

路由的工作是將已進入核心的連線交給指定出站，並不負責讓應用程式流量自動進入用戶端。若系統代理未生效，再多網域規則也不會改變該應用程式的直連路徑。排查路由前，先確認本機監聽、應用程式代理與核心都正常運作，再查看連線記錄中的目標與出站標籤。只有流量已進入核心，才有討論規則命中結果的意義。

精確規則應排在寬泛規則之前

常見欄位規則會依序比對，由第一條符合的規則決定處理方向。規則內的不同條件通常必須同時成立；同一網域清單中的多個項目則用來表示可接受的比對對象。將少數明確的例外規則放在前面，較大的網域集合放在後面；不要先寫涵蓋所有流量的條件，再期待後續例外生效。調整順序後，使用相同目標重新建立連線，才能觀察差異。

網域條件中的 full: 用於比對完整網域，domain: 用於比對網域及其子網域，regexp: 則用於正規表示式。若需求能以前兩者表達，就不必使用正規表示式。一般字串的比對範圍可能比預期更廣，容易將無關網域納入規則。IP 條件則用於位址或網段，不可填入含有協定開頭的網址；連接埠與網路類型也應依各自欄位格式填寫。

以下是路由設定片段，並非完整設定。它會將精確測試網域交給名為 block 的出站，並將環回位址及常見私有 IPv4 網段交給 direct。這兩個標籤都必須存在於實際的 outbounds 中。若要保留現有其他規則，請依需求將本片段中的規則插入陣列，不要直接以此取代整份路由設定。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
        "outboundTag": "direct"
      }
    ]
  }
}

了解網域、位址與解析時機

AsIs 表示路由階段不會主動解析網域以取得位址。若應用程式只提交 IP，網域規則可能沒有可供比對的資訊；若應用程式提交網域，IP 規則在此策略下也不一定能取得解析後的位址。IPIfNonMatch 會在網域比對沒有結果時嘗試解析，再進一步判斷；IPOnDemand 則可能在遇到相關 IP 條件時觸發解析。啟用後也應一併檢查 DNS 路徑。

嗅探功能可以從部分協定交握中擷取網域，但並非所有連線都能擷取。加密交握特性、非標準協定與直接使用 IP 位址，都可能影響結果。不要把嗅探當成正確設定 DNS 的萬用解法。若用戶端提供「僅用於路由」之類的選項，也要確認它只是補充比對資訊，還是會改變後續連線目標；實際行為應以所用核心的欄位定義為準。

查看記錄驗證，不要只看網頁結果

驗證規則時，先關閉舊連線，再前往一個精確目標，檢查記錄中的入站標籤、目標網域或位址，以及選取的出站。瀏覽器可能重用既有連線，因此修改規則後應重新啟動相關應用程式或建立全新連線。若規則未命中，先檢查目標流量是否經過代理、網域格式是否一致、標籤拼寫是否正確，再逐步檢查規則順序與解析策略。

請區分「規則已命中但出站失敗」與「規則未命中」。前者應檢查對應的伺服器與協定；後者才需要繼續調整比對條件。沒有符合規則時，常見設定會使用第一個出站，不能假設一定會走代理或直連。用戶端產生的設定可能會重新排列出站，因此應查看實際執行設定，而非只記住介面中的伺服器順序。

使用地理網域或位址集合時，還要確認資源檔案存在、格式與目前核心相容，並了解集合的更新方式。資源缺失可能導致核心無法啟動，而不只是略過單一規則。先用精確網域建立最小且可驗證的規則，再加入較大的集合；遇到問題時，先還原到上一份可運作的設定，並依照已連線但無法開啟網頁的排查順序逐步檢查。

DNS 設定最佳化

設定 DNS 時，首先要釐清「由誰發出查詢、查詢送往何處、結果用在哪個步驟」，而不只是選擇某個解析位址。一次連線可能涉及系統解析器、瀏覽器安全 DNS、核心內建 DNS，以及遠端伺服器解析。修改其中一處不會自動接管其他路徑。先梳理應用程式到解析器的實際路徑，再決定是否需要核心解析、特定網域解析伺服器或加密 DNS 傳輸。

分開檢查三類網域

第一類是代理伺服器本身的網域，必須在建立連線前解析出可用位址；第二類是使用者要連線的目標網域，可能由本機或遠端解析；第三類是 DNS 服務本身的網域，使用加密 DNS 位址時還需要先完成引導解析。若讓這三類網域都依賴尚未建立的代理通道，就容易形成循環依賴。應為連線的第一步保留明確且可到達的解析路徑。

以下片段使用系統解析器，並允許查詢 IPv4 與 IPv6 位址，適合作為了解欄位的簡化基礎設定。localhost 表示呼叫系統的解析功能，不代表核心會在本機開啟 DNS 服務埠。此片段也不會強制瀏覽器停用自己的安全 DNS。這並非適用所有網路環境的最佳化方案，而是為了明確指出解析來源，之後再依需求細部調整。

{
  "dns": {
    "servers": ["localhost"],
    "queryStrategy": "UseIP"
  }
}

UseIPv4 與 UseIPv6 可用來限制需要的位址類型，但不要只因某次連線速度慢，就永久停用其中一種。請先分別確認系統是否取得對應位址、路由是否可達，以及出站是否支援，再決定採用哪種策略。解析結果包含 IPv6 位址，不代表連線一定會使用 IPv6；最後的選擇還會受到應用程式、核心、出站設定與系統網路堆疊共同影響。

依故障階段縮小排查範圍

DNS 逾時與連線逾時是不同故障。前者可能是沒有取得位址；後者則是已取得位址，卻無法完成連線。只看網頁載入失敗，無法區分這兩種情況。請對照核心記錄中的查詢結果與後續連線錯誤，必要時暫時啟用資訊層級記錄；不要長期輸出過多細節，也不要公開含有目標網域或訂閱網址的完整記錄。

在系統層級可使用 nslookup example.com 查看系統解析結果；這不代表查詢經過核心內建 DNS。比較結果時，請記錄目前網路、時間與應用程式的解析設定，避免把不同解析路徑造成的差異誤判為設定損壞。若系統解析正常，但用戶端仍失敗，請優先檢查核心解析的傳輸路徑、相關路由條件，以及代理伺服器網域是否依賴同一條故障路徑。

再考慮分域解析與快取

內網網域通常依賴所在網路提供的解析器；若全部改用公共 DNS，可能會讓內部名稱無法解析。為特定網域指定解析伺服器時，應使用目前核心支援的網域比對方式，並確認備援查詢策略是否會將這些查詢轉送至其他伺服器。不同核心支援的回退欄位與優先順序並不完全相同，不要將所有進階欄位直接在 v2rayNG 與 v2flyNG 之間複製。

加密 DNS 可以改變查詢的傳輸方式，但仍須確保解析服務可連線、憑證驗證正常且系統時間正確。若服務位址使用網域格式，請先處理引導解析；若使用 IP 位址，也要確認憑證與伺服器名稱條件符合要求。不要同時更換解析位址、路由模式與 TUN 設定，否則成功或失敗都難以判斷原因。每完成一步，都保留一份可還原的設定。

快取可能讓修改後的測試暫時沿用舊結果。驗證時可重新啟動相關應用程式與用戶端，必要時依系統提供的方法清除解析快取；不要反覆修改伺服器位址來「更新」。從家中切換到辦公室網路後，也要重新檢查內網網域與網路介面相關設定。本章的驗證標準是能說明各類查詢的來源與去向，而不只是某個網站剛好恢復連線。

TUN 模式與流量接管

TUN 模式透過虛擬網路介面接收網路層流量，適用於不會讀取系統代理設定的應用程式。它解決的是流量接管範圍，不會自動修復錯誤的伺服器參數，也不保證所有協定都使用同一條路徑。啟用前先確認一般代理模式正常，再檢查權限、路由與 DNS；否則原有連線故障與接管問題疊加後，可能導致整個系統都無法連線。

先建立可還原的基礎設定

桌面端建議先使用 v2rayN，透過系統代理成功連線一次，並記錄目前使用的伺服器、路由模式與 DNS 設定。停止其他正在接管流量的虛擬網卡或隧道工具，再啟用用戶端提供的 TUN 功能。部分實作需要系統管理員權限或輔助服務，也可能由獨立元件負責流量接管；請以用戶端目前提供的功能為準，不要將介面上的 TUN 開關直接等同於某個核心頂層欄位。

Android 上的 v2rayNG 與 v2flyNG 通常透過系統 VPN 介面接管應用程式流量。首次啟動時請詳閱系統授權提示，確認授權對象是目前使用的用戶端。系統通常不允許多個此類接管服務同時運作；切換用戶端前，請先停止前一個服務。這裡所說的系統介面是指流量接管機制，不代表用戶端已具備可連線的遠端服務；仍須另外準備伺服器設定。

檢查權限、預設路由與迴圈

啟用後先確認虛擬介面已建立、核心持續運作，且預設流量方向符合預期。若用戶端啟動後不斷重新連線，可能是代理伺服器本身的連線又被送回虛擬介面，形成迴圈。正確的實作需要排除自身的出站流量，或將其綁定至實體網路介面。不要用大量寬泛的直連規則掩蓋問題；應先檢查用戶端的介面選擇、自動路由與程序排除功能。

區域網路連線應另外驗證。印表機、共享資料夾與內部服務可能使用私有位址、鏈路本地位址或專用網域。將常用私有位址設為直連只是其中一部分，還需要檢查虛擬介面路由、名稱解析與防火牆。若可用位址連線，卻無法用名稱連線，請回到 DNS 章節；若位址也無法連線，再檢查介面路由與網段衝突，不必立刻修改伺服器協定。

分清流量接管範圍與傳輸能力

流量進入 TUN 後，UDP 能否正常處理仍取決於接管元件、所選協定、伺服器端能力與路由規則。網頁可正常瀏覽，不代表即時通訊或其他 UDP 應用程式也能使用。請選擇實際需要的應用程式個別測試，並查看其網路類型與錯誤記錄。遇到不相容情況時，先縮小接管範圍，或改用應用程式本身支援的代理設定；不要盲目切換所有參數。

確認基礎連線正常後，再考慮調整 MTU。只有在部分較大資料傳輸卡住時，才依網路環境評估分片或路徑 MTU 問題；沒有一個固定值適用所有網路。每次只調整一個級距，並用相同目標重新測試，同時記錄原始設定；失敗時立即還原。若連基本的網域解析與短連線都失敗，應先處理權限、路由與 DNS，不要一開始就反覆測試 MTU。

從睡眠狀態恢復、切換 Wi-Fi 或接上有線網路後，實體介面名稱與閘道可能改變。若啟動時正常、切換網路後失效，請停止並重新啟動流量接管，觀察自動介面選擇是否更新。長期使用時記錄觸發條件，比重複匯入訂閱更有幫助。訂閱管理不會維護系統路由；重新取得伺服器清單，通常無法解決網路介面已失效的問題。

完成本章後，應分別驗證三種目標：一般網頁、一個原本不會讀取系統代理的應用程式，以及一項實際需要的區域網路服務。三者的結果可協助判斷問題來自接管範圍、遠端傳輸還是內網例外。只看到系統顯示服務已啟動，不足以證明流量接管正確；還須確認關閉用戶端後網路能夠恢復，避免暫時成功只是沿用未清除的舊路由。

FakeDNS 位址映射

FakeDNS 會將網域映射至受控位址池中的合成位址，並在流量進入核心時還原網域。它可保留網域資訊並協助路由判斷，並非能取代所有解析工作的公共 DNS 服務。實際連線最終仍需要可用的目標與出站。啟用前應先了解 DNS 查詢路徑與 TUN 的接管範圍，否則應用程式可能取得合成位址，連線卻未進入能還原映射的核心。

確保查詢與連線形成完整流程

完整流程包含三個環節：應用程式查詢交由提供 FakeDNS 的解析路徑處理，取得合成位址後發起連線，再由對應核心攔截連線並還原網域。少了任何一個環節都會失敗。只在設定中加入位址池，不會自動將系統查詢導入其中；只啟用 TUN，也不代表核心已將所有 DNS 查詢交給 FakeDNS。請分別驗證查詢來源、回傳位址與連線入站。

以下是 Xray 格式的核心設定片段，用來說明位址池、解析伺服器與 SOCKS 入站嗅探之間的關係；它不是完整的用戶端設定，也不是適用所有核心的通用範本。此處只監聽本機；SOCKS 入站的嗅探僅處理送入該入站的連線，不會自動接管系統 DNS。若要將類似設定用於 TUN，必須透過用戶端實際提供的流量接管與 DNS 設定入口，不可直接套用此入站設定。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["fakedns"]
      }
    }
  ]
}

位址池不是伺服器清單

ipPool 表示可供合成映射使用的位址範圍，poolSize 則控制映射池容量。位址數量不等於伺服器數量，也不代表可用連線數。池內位址不可當成真正的遠端伺服器位址，儲存到訂閱或手動項目中。若網路本身已使用相同範圍，可能造成衝突；啟用前應檢查現有路由與內部網路規劃，而不只是確認設定檔語法正確。

上例中的範圍適用於基準測試等特定用途，並非可直接連線的公網目標。應用程式取得該位址後，必須經過正確的還原路徑。若記錄顯示用戶端正嘗試將此範圍直接送往實體網路，代表映射未被使用，或連線繞過了流量接管。此時新增一般代理規則通常無法根本解決問題；應先檢查嗅探能力、入站位置，以及 DNS 回傳值是否來自同一個執行個體。

留意核心差異與應用程式行為

v2rayNG 與 v2flyNG 使用的核心不同，FakeDNS 支援的欄位、設定格式與搭配方式都應分別確認。不要只因兩款用戶端介面相似，就複製整份自訂 JSON。v2rayN 也可能透過不同元件接管流量，因此必須先確認目前實際執行的核心與設定產生方式。若要了解不同分支的背景，可參閱Xray 與 V2Fly 核心關係說明。

若應用程式自行使用加密 DNS，可能會繞過預設的系統查詢路徑，取得真正的位址，而非合成位址。部分應用程式則會直接使用快取位址或固定 IP，因此沒有可還原的網域映射。不要因為某個瀏覽器能正常使用，就推斷所有應用程式都經過 FakeDNS。請選一個新網域進行測試，並搭配查詢與連線記錄觀察；必要時暫時統一測試應用程式的解析設定。

映射通常只存在於目前核心的執行狀態中，重新啟動後，舊快取中的合成位址不一定還能對應原網域。若重新啟動用戶端後只有部分應用程式失敗，先清除這些應用程式的解析快取或重新啟動應用程式，不要重新取得訂閱。停用 FakeDNS 時也要處理快取，避免用戶端停止後，應用程式仍將合成位址當成真正的目標。切換網路或從睡眠狀態恢復後也應檢查此情況。

網域還原成功後，路由才能依網域條件進一步選擇；路由設定正確，不代表遠端解析一定正常。若記錄已顯示原始網域與預期出站，接下來應檢查實際解析與連線階段。建議先只在測試環境啟用 FakeDNS，確認停用後能恢復一般解析，再逐步擴大使用範圍。若沒有明確保留網域資訊的需求，維持目前正常的解析方式通常較容易管理。

多訂閱管理與更新策略

多訂閱管理的重點是隔離更新風險並明確訂出切換依據，而不是盡可能增加清單項目。每個來源都有各自的網址、格式、有效期限與連線條件；某個來源更新失敗，不應影響其他仍正常運作的分組。管理時分別記錄來源、用途與目前使用項目，避免將名稱相同的項目誤認為同一台伺服器，也避免更新後仍依賴已撤回的舊項目。

依來源分組，依用途選擇

每個訂閱網址都建立獨立分組，再用別名區分日常、測試與備用用途。不要將不同來源的原始網址拼接在一起，也不要把多個訂閱的回傳內容直接貼進同一個匯入欄位，期待用戶端自動維護來源關係。合併後的靜態項目可能失去更新關聯；即使當下可以連線，後續新增、撤回與參數變更也會難以追蹤。請優先保留用戶端原生的訂閱記錄。

名稱相同不代表連線參數相同。判斷項目是否重複時，至少要比較協定、伺服器位址、連接埠與傳輸設定；驗證資訊則應留在本機核對。不同來源可能使用相同別名，卻指向不同服務；同一位址也可能因驗證或傳輸設定不同而形成不同項目。清理前先確認目前使用的連線來自哪個分組，並保留可用的基礎設定，避免為了整理清單而誤刪唯一可正常運作的設定。

分組不是自動故障切換功能。將分組命名為「備用」，不代表目前連線失敗時用戶端會自動切換。自動選擇、負載分配或探測屬於其他功能，是否支援及如何運作取決於用戶端與核心。若沒有明確設定這些機制，就應把備用分組視為手動切換資源，並記下切換入口與驗證方式，不要只靠分組名稱推斷實際行為。

建立固定的更新順序

新增來源時，先單獨更新一次，檢查解析結果與一個代表性項目，再安排日常更新。設定排程更新前，確認執行時用戶端是否仍在運作、網路是否可用，以及更新請求會經過哪條路徑。不同用戶端處理更新請求是否使用目前代理的方式可能不同，請查找相關選項並實際測試。訂閱更新成功與伺服器連線正常是兩個指標，不應混為一談。

更新失敗時，先確認錯誤類型，再決定是否切換請求路徑。連線逾時可能與目前網路有關；驗證失敗或網址過期則應檢查來源狀態；解析結果為空也可能是格式不相容。避免在短時間內連續重試所有來源，這不但會增加排查雜訊，也可能觸發來源端的請求限制。先只處理發生問題的分組，維持其他分組原狀，並以最近一次成功更新的狀態作為對照。

伺服器清單更新後，請確認目前使用的項目是否仍存在、是否重新建立，以及是否切換至預設項目。有些用戶端會盡量保留選取項目，有些操作則可能改變目前使用的項目；不要假設行為完全一致。確認啟用標記後，重新建立一次連線，再測試常用目標與必要的區域網路服務。若更新只改變顯示名稱，實際連線參數並未改變，就不必重新設定路由。

移轉時分開管理設定資料與連線資料

跨裝置移轉時，應分別檢查訂閱記錄、手動項目、路由規則、DNS 設定與系統流量接管選項。匯出單一伺服器分享連結，通常不會包含分組更新排程，也不會帶入系統代理或 TUN 的完整狀態。移轉後先以一般代理模式驗證連線，再逐項還原進階設定；不要直接沿用另一台裝置的介面名稱、網段假設與權限狀態。

備份可能包含訂閱存取憑證、伺服器驗證資訊與個人使用偏好，應存放在受控位置，不可當成公開的故障排查資料。需要分享排查資訊時，只擷取錯誤類型、欄位名稱與已移除敏感內容的局部片段。不要因為備份檔是文字格式，就認為可以直接上傳。還原前先確認備份所屬的用戶端與核心，以免匯入後自動覆蓋仍可正常運作的管理設定。

刪除來源前，先切換至另一個已驗證的連線，停止該分組的更新排程，再刪除訂閱記錄與不再需要的項目。最後檢查用戶端規則或自訂出站是否仍指向舊項目。清理清單後再測試一次連線，確認不是沿用尚未中斷的舊工作階段。如此才能讓多訂閱管理保持可追溯，而不是依靠歷史快取維持表面正常。

自訂出站與設定驗證

出站定義連線如何離開核心，路由則透過標籤選擇出站。伺服器項目、出站物件與路由規則彼此相關，但並不是同一個物件。用戶端通常會依選取的伺服器產生出站；若改用完整自訂設定，介面中的伺服器切換可能不再自動變更該設定。開始操作前，務必確認目前的設定入口接受的是完整 JSON、出站片段，還是用戶端專用的規則格式。

先用不含遠端驗證的最小設定驗證結構

以下是用於本機功能測試的完整基礎設定，採用 V2Fly 與 Xray 常見的 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": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      }
    ]
  }
}

設定中的 direct 與 block 是自行命名的標籤，不是只要使用這些名稱就會生效的保留關鍵字。實際行為由 protocol 決定；修改標籤時，必須同步更新所有引用。此範例中，未符合規則的連線會使用第一個直連出站，精確測試網域則會交由封鎖出站處理。測試網域僅用於觀察規則，不會提供實際網站內容。

依序檢查語法、語意與執行結果

語法檢查先確認雙引號、逗號、陣列與物件都正確閉合；標準 JSON 不接受註解或多餘的結尾逗號。語意檢查則確認欄位屬於目前使用的核心、標籤引用存在，以及連接埠與位址格式正確。完成後才啟動並觀察執行結果。JSON 工具能讀取檔案，只能證明語法有效，不能證明協定受支援、伺服器可連線或路由符合預期。

執行時先確認監聽成功，再讓一個測試應用程式使用本機 SOCKS 位址與對應連接埠。若需要使用網域規則，應用程式必須將網域交由代理端處理；若應用程式先在本機解析，只提交 IP，精確網域規則就可能沒有條件可比對。一般連線成功後，再測試測試網域並觀察封鎖行為，確認看到的是目前核心的處理結果，而不是應用程式繞過代理後的連線失敗。

範例監聽於環回位址，適合本機測試。將監聽範圍擴大到所有網路介面會改變存取邊界；尤其是沒有驗證機制的 SOCKS 服務，同一網路中的其他裝置也可能使用。若確實需要共用，應另外規劃驗證、防火牆與允許存取的來源，不要只將監聽位址改成任意位址。用戶端的「允許區域網路」選項也應先了解開放範圍，不可只為了排查問題暫時啟用，之後卻一直維持開啟。

加入實際出站時保留復原路徑

實際遠端出站應依已驗證的伺服器參數產生，再依目前核心支援的協定欄位調整。不要混用 V2Fly 與 Xray 專屬參數，也不要只複製協定名稱，卻漏掉傳輸、安全層與伺服器名稱等相關設定。參數不完整時，請先回到用戶端的一般伺服器編輯介面核對；若需選擇核心，可參考用戶端比較，不要靠反覆更換用戶端掩蓋參數缺漏。

多出站設定應使用能清楚表達用途且不重複的標籤，並記下每條路由的選擇理由。若需鏈式轉送，還要確認核心實際支援的連線方式與欄位，並區分「選擇一個出站」和「透過另一個出站建立連線」。新增兩個物件不會自動形成這種關係。初次驗證時只加入一個實際出站與一條精確規則；成功後再擴充，避免形成循環引用或難以追蹤的預設路徑。

用戶端可能在啟動、切換伺服器或更新訂閱時重新產生執行設定，直接修改暫存產生的檔案可能會遺失。長期設定應存放在用戶端明確支援的自訂入口，並確認重新啟動後仍會生效。復原時先還原上一份設定，再重新啟動核心，並檢查系統代理與 TUN 狀態；不要只替換檔案卻繼續使用舊程序，以免介面顯示與實際執行狀態不一致。