V2Ray 進階設定指南

訂閱分組與伺服器篩選

先釐清訂閱網址、訂閱分組和伺服器項目各自的用途。訂閱網址是取得設定的入口；訂閱分組是用戶端保存入口及更新策略的容器；伺服器項目則是更新後取得的連線參數。三者並不相同。刪除某個伺服器通常不代表刪除訂閱，下次更新時它仍可能再次加入。若要永久停用一批設定，應先停用對應分組的更新，再決定是否刪除分組及其項目。

建立可追蹤的分組

在 v2rayN 中開啟「訂閱分組」相關設定，新增分組，填入容易辨識的備註和完整訂閱網址，然後儲存。備註可記錄來源與用途，例如「工作裝置」或「臨時測試」，請勿在備註中寫入存取密碼。訂閱網址可能包含存取權杖，複製時須包含完整的查詢字串，但不要將完整網址放進截圖或公開日誌。若輸入框前後有空格，請先清除再儲存，以免把輸入錯誤誤判為網路故障。

儲存後，先只更新這個分組。判斷更新成功，不是看提示訊息是否消失，而是確認日誌顯示請求已完成、項目數量有合理變化，且清單列出來自該分組的伺服器。接著選取一個已知可用的設定，設為作用中伺服器，再依快速入門流程驗證。若同時更新多個來源，某個分組的失敗可能被其他分組成功的訊息掩蓋，因此初次建立分組時不建議直接全部更新。

自動更新間隔應依來源的變更頻率設定。間隔太短會增加重複請求，也可能觸發來源端的存取限制。電腦進入睡眠、網路切換或應用程式未執行，都會影響排程工作；更新間隔不代表伺服器端會主動推送。更新前也要確認訂閱網址是否能直接連線；若必須透過目前的代理才能取得，請使用用戶端提供的代理更新方式，並保留一個可正常運作的作用中設定，避免更新入口與作用中連線同時失效。

篩選清單與刪除設定的差異

伺服器篩選通常只會改變清單的顯示範圍，不會修改伺服器本身。先選好分組，再輸入名稱關鍵字，以免誤操作。確認是否啟用了名稱篩選、協定篩選或僅顯示特定分組，再判斷項目是否真的遺失。部分介面支援正規表示式，部分只做一般文字比對；請以輸入框的說明為準。一般關鍵字不能直接當成正規表示式使用，反之亦然。

若篩選器明確支援正規表示式，可用 工作|備用 比對任一關鍵字，用 ^測試 限定名稱開頭。輸入後先查看結果，不要立刻批次刪除。括號、加號和方括號在正規表示式中有特殊意義；若來源名稱剛好含有這些字元，應依該介面的正規表示式規則跳脫。不確定比對方式時，改用單一一般關鍵字，比堆疊複雜運算式更容易確認結果。

更新失敗時保留現況

遇到清單空白時，先清除篩選條件並切回對應分組，再查看更新日誌。連線逾時應優先檢查網路路徑；解析錯誤則應檢查回應內容。訂閱介面若回傳登入頁面、過期提示或一般網頁，網路請求可能已成功，但用戶端無法將頁面辨識為伺服器設定。此時反覆切換協定沒有幫助，應確認網址是否失效，以及來源是否要求重新取得訂閱入口。

手動編輯訂閱產生的項目之前，先複製到獨立的本機分組。更新來源可能會重建項目並覆蓋本機修改。原始分組負責同步，複製分組用於測試；分工明確後，排錯時才能回到來源參數。Android 版 v2rayNG 和 v2flyNG 的選單位置可能不同，但同樣應區分訂閱更新與目前伺服器的選擇。常見連線問題可繼續查閱說明中心；訂閱尚未成功匯入前，請勿同時修改 DNS 和路由。

路由規則實作與比對順序

路由的工作是將進入核心的請求分配給出站，而不是替應用程式建立連線。請先確認請求確實已抵達本機代理，再檢查分流結果。若程式不讀取系統代理，即使路由規則寫得再完整，也不會改變它的連線路徑。排錯時應依序檢查應用程式入口、請求攜帶的資訊、規則比對及出站連線。把這四個步驟混在一起，容易將入口問題誤認為規則錯誤。

先確認規則所屬的設定層級

v2rayN 的路由編輯介面可能使用簡寫格式，例如 domain:example.com、geosite:private，也可能將網域和 IP 分成不同輸入欄位。這是用戶端的輸入方式，不代表核心 JSON 所有欄位的格式。核心設定中的網域應放在 domain 陣列，網段應放在 ip 陣列；不要將介面中的整行文字直接貼到任意欄位。尤其像 ip:192.168.0.0/16 這類介面簡寫，不能原樣當成核心 IP 陣列的元素。

以下是可合併至 V2Fly 或相容 Xray 設定的路由片段。此範例假設已存在名為 direct 和 proxy 的出站。第一條規則讓本機位址直連，第二條讓範例網域走代理，最後一條則接收其他 TCP 和 UDP 請求。範例僅說明比對關係，不提供遠端伺服器參數，也不能單獨構成完整的連線設定。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "::1/128", "fc00::/7"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

將例外規則放在預設規則之前

規則通常依序比對，第一條符合條件的規則會決定出站。涵蓋所有連線的預設規則必須放在最後，否則後續例外規則永遠不會生效。同一條規則若同時填入網域、連接埠和網路類型，通常必須全部符合；同一個陣列中的多個網域則代表多個候選項目。不要用一條規則描述彼此無關的需求，拆成兩條會更容易檢查。

domain:example.com 用於比對該網域及其子網域；full:example.com 則用於比對完整網域名稱。只有名稱確實具備規律時才適合使用正規表示式，不應將它當成預設選項。網域規則不會自動比對使用者直接輸入的 IP 位址。若希望目標網段也採用相同路徑，應新增獨立的 IP 條件，並留意網域解析策略是否允許在路由階段查詢位址。

AsIs 不會為了 IP 規則主動解析網域；IPIfNonMatch 會在網域階段未比對成功時嘗試解析，並繼續比對 IP；IPOnDemand 則可能在需要 IP 條件時提早觸發解析。這些選項會影響查詢次數和規則命中情況，並非單純的速度選項。選擇前請先確認是否真的需要依目標 IP 分流，以及 DNS 查詢本身能否透過正確的出站完成。

用單一請求驗證規則命中

驗證時先選一個確定的網域，關閉舊頁面或重新啟動目標應用程式，再建立新連線。規則儲存後，既有長連線不會自動改道。暫時提高日誌詳細程度，確認請求的目標、入站標籤和出站標籤是否符合預期；完成後再恢復常用的日誌層級。若只能看到 IP、看不到網域，請檢查應用程式是否傳遞主機名稱，以及流量嗅探是否適用於該協定。

規則引用的地理資料必須由目前的用戶端和核心提供。若出現找不到資料檔案或分類名稱的錯誤，應先修復資料來源，不要試圖靠調整順序掩蓋載入失敗。圖形介面的路由方案可能在核心重新啟動時重新產生設定，因此應在用戶端儲存規則，而不是長期修改暫存產生的檔案。欄位之間的關係可參考設定檔 JSON 結構詳解，分別處理格式錯誤與比對邏輯錯誤。

DNS 設定最佳化與解析路徑

排查 DNS 時，先區分三個位置：應用程式或作業系統的解析器、代理核心的解析器，以及透過代理存取的遠端服務。瀏覽器啟用安全 DNS 後，可能會略過系統解析器；應用程式將網域交給 SOCKS 入口時，則可能由代理端繼續處理。只在用戶端更換 DNS 位址，不代表裝置上的所有程式都改用該位址。應先釐清請求在哪一層轉換成 IP，再決定要修改哪項設定。

分別處理伺服器網域與目標網域

代理伺服器本身使用網域時，建立代理連線前就必須先解析該網域。若解析流程被安排在尚未建立的代理通道中，就會形成循環相依。目標網站的網域則可依分流需求選擇直連解析或透過代理查詢。兩類網域用途不同，不宜用一項含糊的「全部使用遠端 DNS」設定一概處理。啟動後完全無法連線時，應優先檢查伺服器網域能否透過獨立路徑解析。

在 v2rayN 的 DNS 設定中，先確認目前編輯的是哪一種核心的設定。不同核心後端的欄位、預設行為和可用傳輸方式可能不同，不能將某個後端的 JSON 貼到另一個後端。以下片段用來說明 V2Fly 風格的內建 DNS 設定：為保留的範例網域指定靜態位址，並向指定解析器要求 IPv4 位址。它只會影響使用該內建解析器的請求，不會自動接管系統 DNS。

{
  "dns": {
    "hosts": {
      "example.com": "192.0.2.10"
    },
    "servers": ["1.1.1.1"],
    "queryStrategy": "UseIPv4"
  }
}

範例中的靜態位址僅供文件示範，不能用來測試真實網站是否連線正常。實際設定時，應刪除這條範例對應，或填入自己管理的網域與正確位址。靜態對應適合明確且穩定的內部服務，不適合長期固定內容傳遞服務的位址。後者可能因地區、網路和時間而回傳不同結果，強行固定反而會造成連線錯誤。

調整前先建立對照組

每次只比較一項變更：保留相同的作用中伺服器、路由方案和測試網域，只更換解析路徑，再建立新連線。若同時更換伺服器和 DNS，即使結果改善也無法確認原因。系統查詢工具只能證明它本身使用的解析路徑，無法直接證明核心 DNS 運作正常。應搭配核心日誌和實際應用程式請求，觀察查詢目標、回傳類型及後續連線使用的位址。

IPv4 和 IPv6 必須配合實際出口能力。若查詢取得 IPv6 位址，但出口沒有可用的 IPv6 路徑，應用程式可能會等到連線失敗後才改用其他位址，看起來像是 DNS 很慢。暫時限制使用 IPv4 可用於定位問題，但不適合當成所有網路的固定解法。若業務需要 IPv6，應一併檢查本機網路、代理伺服器、核心出站和路由網段，不能只保留 AAAA 回應而忽略後續連線能力。

了解加密查詢與快取的界線

使用加密 DNS 時，也要考量解析服務本身的連線路徑、憑證名稱及初始解析。將解析器設為網域後，仍需要先解析該網域；某些特殊格式可能會在本機直接發出查詢，而不遵循一般的出站路由。實際行為應以目前核心支援的 DNS 類型為準。不要只因位址以加密協定開頭，就推斷查詢一定經過作用中代理。

設定儲存後，用戶端快取、作業系統快取、瀏覽器快取和應用程式長連線可能同時保留舊狀態。先重新建立測試連線，再視需要清除對應層級的快取，不必每次都重設整個網路。若核心日誌已取得正確位址，但應用程式仍連往舊目標，請檢查應用程式快取。使用 TUN 時還要確認 DNS 接管確實涵蓋目標請求；未被接管的查詢，不會因內建 DNS 欄位變更就自動改變路徑。

TUN 模式與虛擬網卡接管

系統代理會向應用程式提供本機代理入口，應用程式是否使用取決於自身實作。TUN 則透過虛擬網卡和系統路由，將符合條件的 IP 流量送進處理鏈。兩者入口不同，不能簡單視為同一個開關的不同強度。只有在一般系統代理已正常運作、但部分程式不讀取代理設定時，才有必要評估 TUN，避免將基本設定錯誤帶進更複雜的流量接管環境。

啟用前檢查權限與既有路由

先記錄目前的路由方案、作用中伺服器和 DNS 設定，確認關閉 TUN 後仍能恢復一般連線。接著檢查是否已執行其他虛擬私人網路、虛擬網卡工具或流量接管程式。多個工具同時爭用預設路由時，畫面上看似都已啟用，實際流量卻可能進入另一條鏈路。測試期間只保留一套接管機制，確認各自的工作範圍後再考慮共存。

在 Windows 上，建立虛擬網卡和修改路由通常需要系統管理員權限；在 macOS 和 Linux 上，可能需要系統授權或相關服務元件。請依目前 v2rayN 介面的權限提示操作，不要在一般權限下反覆啟動，只看開關顏色判斷狀態。權限不足、元件缺失和設定語法錯誤是不同問題，應分別從啟動日誌中確認。安裝套件可回到用戶端下載頁，依作業系統和處理器架構核對。

v2rayN 的 TUN 功能可能由獨立的接管後端處理，而不是直接在 V2Fly 或 Xray JSON 中加入通用欄位。因此，不能把網路上的任意 TUN 設定片段當成所有核心都通用的語法。請優先使用用戶端提供的開關和設定項，讓用戶端產生對應的後端設定；只有確認後端類型及設定入口後，才進一步編輯進階參數。

分階段啟用並觀察連線

啟用後依序檢查虛擬網卡是否建立、路由是否加入、DNS 是否依預期接管，以及目標應用程式是否出現新的連線日誌。開關亮起只代表使用者要求啟用，不一定表示每個步驟都已完成。先測試一般網頁，再測試原本不讀取系統代理的應用程式。若網頁也無法連線，先關閉 TUN 恢復原狀並確認基本連線，不要同時修改 MTU、路由表和伺服器參數。

代理伺服器本身的連線必須有正確的出口，不能再次被接管並送回同一條代理鏈。用戶端通常會建立排除或保護機制，但多張網卡、行動熱點和網路切換仍可能影響出口選擇。若日誌持續出現重複連線、連線數異常增加，或伺服器位址反覆進入接管鏈，請先停用 TUN，檢查伺服器位址的排除方式及預設出口網卡，不要再提高重試次數。

區域網路排除規則應涵蓋實際使用的網路，而不是只複製常見私有網段。公司網路、虛擬機器和容器網路可能使用其他位址範圍，也可能仰賴特定介面。若只有連上辦公室網路後才失敗，請先比較連線前後的路由變化。允許區域網路裝置連線至本機代理是另一項功能，涉及監聽位址和防火牆，不能用 TUN 開關取代；相關步驟請參閱區域網路代理分享設定。

區分傳輸能力與網卡接管

TUN 能接收某類封包，不代表遠端出站就能正確轉送。UDP 應用程式還取決於伺服器設定、傳輸方式和網路環境。某些探測工具使用的控制封包，也不適合直接作為代理服務可用性的判斷標準。驗證時應使用目標應用程式實際需要的協定，並在日誌中確認轉送鏈路，而非將單一探測結果當成整體網路狀態。

部分頁面載入停滯時，應先確認 DNS、路由和 UDP 路徑，再檢查 MTU。較大的封包在某些鏈路上可能遇到分片或路徑探測問題，但盲目調低 MTU 會掩蓋真正原因。每次記錄原始值、只調整一項設定，並以相同服務重新測試；若沒有改善就還原。更詳細的啟用與回復順序可參閱v2rayN TUN 模式設定；保留回復方式，比一次開啟所有進階選項更重要。

FakeDNS 對應與網域還原

FakeDNS 回傳的不是目標服務的真實位址，而是由代理維護對應關係的合成位址。應用程式連上該位址後，處理鏈會透過對應關係找回原始網域，再進行路由或遠端連線。它解決的是某些入口只能看到 IP、難以繼續依網域處理的問題，不是替一般 DNS 查詢增加快取的另一種稱呼。了解這點後，才能判斷目前的入口是否需要使用它。

啟用條件：完整的對應鏈

可用鏈路至少包含四個環節：查詢進入 FakeDNS、應用程式取得合成位址、連線回到維護對應關係的處理器，以及處理器還原網域並選擇出站。任何一個環節缺失，合成位址都可能被當成一般位址送上網路。只在設定中寫入一個位址池，卻沒有接管查詢及後續連線，不會自動形成完整功能。請先確認目前用戶端後端確實提供對應能力，再考慮啟用。

V2Fly 風格的 FakeDNS 設定，與部分 TUN 後端的合成位址功能並非同一套語法。即使名稱相似，它們的位址池、快取、持久化和網域排除方式也可能不同。不能將一種後端的開關和另一種後端的位址池拼在一起設定。以下片段僅展示支援該語法的 V2Fly 設定中，位址池、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": {
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["fakedns"]
      }
    }
  ]
}

這段設定不會自動將作業系統的 DNS 送進核心。若應用程式從其他解析器取得真實位址，FakeDNS 位址池就不會參與該次請求；若應用程式取得合成位址，卻繞過代理直接連線，同樣會失敗。測試時應確認查詢和連線都經過同一處理鏈。至於目前的 Xray 或其他後端是否支援相同欄位，應檢查用戶端實際提供的設定選項，不能以本節範例取代相容性確認。

位址池不是可連線的目標網段

合成位址池必須與目前使用的網路規劃分開檢查。範例位址範圍常用於這類對應，但部分測試環境或內部網路也可能實際使用。若網段重疊，系統無法只憑目標 IP 判斷連線是指向真實服務還是合成對應。請先核對路由表和內部網路用途，再使用後端允許的位址池；不要為了避開衝突，任意改用公網網段。

位址池容量限制的是可維護的對應數量，不等於同時連線數。網域數量龐大、網路頻繁切換或應用程式長期快取，都可能導致舊位址與目前的對應關係不符。重新啟動核心後，應用程式仍可能保留舊的合成位址，此時應讓應用程式重新查詢，而不是持續重試舊連線。只關閉瀏覽器頁面不一定能清除系統快取，請依實際快取所在層級處理。

有些應用程式會檢查目標位址是否屬於特殊網段，或將查詢結果長期儲存。這類程式可能不適合使用合成位址。若需要排除，應在支援此功能的 DNS 規則中，讓特定網域回傳真實結果，同時確保其真實連線仍依需求處理。排除 DNS 合成和選擇直連並不是同一回事：取得真實位址後，連線仍可透過代理出站。

搭配網域路由一併驗證

啟用後先驗證一個網域：日誌中應能看到合成位址還原為網域，接著命中預期規則。若合成位址直接命中一般 IP 規則，應檢查還原環節，而不是強行指定整個位址池走某個出站。將整個位址池轉送出去或許能暫時改變現象，卻無法還原遺失的網域，也可能讓遠端收到毫無意義的目標位址。

若原本的 SOCKS 網域入口已能穩定依網域分流，增加 FakeDNS 未必有幫助。它較適合確實需要從 IP 入口還原網域，而且查詢與連線都能一併受控的情境。測試完成後，請記錄啟用原因、適用入口、排除網域和回復方式；日後更換核心或接管後端時，應重新驗證，不要只複製原本的位址池就認為遷移完成。

多訂閱管理與更新範圍

多訂閱管理首先要解決來源和用途的可追蹤性，而不是把所有伺服器都堆在同一份清單。建議每個來源使用一個基礎分組，再以獨立的本機分組保存手動測試項目。若同一來源確實有不同業務入口，請在備註中說明用途，避免多個名稱相近的分組重複更新。分組結構清楚後，才能追查項目來自何處、為何變動，以及哪個設定應用於日常連線。

將同步資料與本機修改分開

訂閱回傳的伺服器參數由來源端維護；本機備註、排序和手動調整則屬於用戶端狀態。更新是否保留這些狀態，取決於用戶端辨識項目的方式，不能假設名稱相同就一定會被視為同一個項目。來源調整名稱、連接埠或識別碼後，用戶端可能會重新建立項目。因此重要的本機修改應複製到手動分組，並寫明修改用途；原始分組則維持同步用途。

整理重複設定時，不要只依顯示名稱刪除。兩個同名項目可能使用不同的連接埠、協定、傳輸或安全設定；兩個不同名稱的項目也可能指向相同端點。整理時先確認來源，再比較連線參數和實際用途。若用戶端提供去重功能，應先了解它依據哪些欄位判斷重複，並先匯出設定再操作。不確定的項目可先移到測試範圍觀察，比直接批次清空更容易復原。

本機分組和訂閱分組也應採用不同的更新策略。手動分組不需要填寫訂閱網址，以免誤以為儲存來源連結就能自動維護其中所有修改。若訂閱更新後協定參數有所變動，應先在原始分組驗證新的伺服器，再決定如何遷移本機測試項目。不要將舊參數重新覆蓋到來源項目上，否則下次更新仍會再次衝突。

規劃更新順序與故障備援

先確認至少有一個來源能在目前網路中直接更新，或所有來源都必須透過代理。如果需要透過代理更新，作用中伺服器的選擇會影響更新成功率。日常更新可逐組進行：先更新非作用中的來源，確認可以連線後，再更新目前的來源。這樣能減少作用中連線與設定同步同時變動，也能在某個分組回應異常時保留可用的對照。

多個訂閱不代表會自動切換備援。一般分組只是用來整理設定，切換作用中伺服器通常仍需使用者操作。只有明確設定用戶端支援的選擇或調度機制，才能預期自動改用其他出站；調度所需的探測條件也必須另外驗證。清單中有多台伺服器，不代表連線失敗時核心會自動尋找下一台。

測速結果也不能直接決定長期優先順序。建立連線、瀏覽網頁和持續傳輸測試所關注的指標各不相同，測試目標本身也會影響結果。請先依業務需求選擇測試類型，再比較相同條件下的結果。測試期間應維持相同的網路、路由和 DNS，避免將網路切換造成的差異歸因於訂閱來源。某個設定測試失敗時，也應確認它是否需要目前尚未啟用的協定或傳輸功能。

遷移設定並保護訂閱入口

更換電腦前，分別確認用戶端設定、訂閱網址和本機手動伺服器是否都包含在匯出範圍內。有些匯出內容只包含伺服器，不含路由、DNS 或接管選項。匯入後應逐項檢查，不要看到項目齊全就直接啟用 TUN。先驗證一般代理，再還原分流，最後恢復進階接管，能將遷移問題限制在明確的層級。

訂閱網址通常具有存取權限，應視為敏感設定妥善保存。分享排錯資訊時，可保留錯誤類型和狀態，但應遮蔽完整網址、識別參數及伺服器驗證資訊。若懷疑入口外洩，應在來源端重新產生網址並更新用戶端；只修改分組備註沒有幫助。刪除停用來源後，也要檢查是否有舊項目被複製到本機分組，避免日後誤選。

多個來源同時更新失敗時，優先檢查共同依賴項目：系統時間、DNS、目前網路、代理更新路徑和本機防火牆。只有單一來源失敗時，再著重檢查該來源的網址和回應。依此順序排查，可避免將全域故障逐一歸咎於不同訂閱。若瀏覽器能存取網站、用戶端卻無法更新，應進一步比較兩者的代理和解析路徑；瀏覽器正常並不能排除本機設定問題。

自訂出站與設定完整驗證

出站定義核心如何將請求送往下一個節點，路由則負責選擇出站。自訂出站適用於需要特殊上游、固定本機轉送鏈或明確串接連線的情況，不是匯入一般訂閱的必要步驟。開始前，請先在 v2rayN 保留一套已驗證的一般設定，並確認目前使用的是由用戶端管理的伺服器、完整自訂設定，還是可合併的設定片段。這三種入口對欄位覆寫和儲存方式的要求不同。

以標籤連結入站、規則與出站

tag 是設定內部使用的名稱。路由中的 outboundTag 必須與既有出站的標籤完全一致，大小寫和拼字都不能任意變更。建議使用能清楚說明用途的簡短名稱，不要把伺服器密碼或完整位址放進標籤。標籤缺失、重複或指向不存在的項目，都可能導致啟動失敗或實際路由偏離預期。

以下是可獨立啟動的本機轉送範例，採用 V2Fly 和相容 Xray 常見的結構：在迴路位址開啟 SOCKS 入站，並將所有流量轉交給本機另一個 SOCKS 服務。此範例要求本機連接埠 20808 已有獨立的上游服務執行；若沒有，仍可用來檢查設定結構，但實際連線會失敗。範例不包含遠端伺服器驗證資料，不能取代訂閱提供的實際設定。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-in",
      "listen": "127.0.0.1",
      "port": 10818,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "upstream-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 20808
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "network": "tcp",
        "outboundTag": "upstream-socks"
      }
    ]
  }
}

範例停用 UDP，是為了將驗證範圍限定在 TCP，不預設上游具備 UDP 傳輸能力。監聽位址限定為迴路介面，因此只供本機使用。不要為了方便測試而改成監聽所有網卡；若確實需要共用，應另外設定來源限制、身分驗證和防火牆。連接埠也不能與現有用戶端監聽連接埠衝突，否則啟動失敗與遠端連線能力無關。

避免串接連線形成迴圈

轉送鏈最常見的錯誤是入口又指向自身，或上游透過系統代理再次回到目前入口。設定前先明確畫出連線順序：應用程式、本機入站、選取的出站、獨立上游、最終目標。每一跳都記錄監聽位址和連接埠，不能只寫「走代理」。若上游也啟用了 TUN，還要確認連往上游伺服器的流量不會再次被下游接管。

也要明確決定在哪一跳解析網域。應用程式傳遞網域時，上游 SOCKS 服務可能會繼續處理該網域；若應用程式預先傳入 IP，後續鏈路通常只能使用該位址，除非有可靠的還原機制。出站鏈不會自動修正錯誤的解析結果，也不會讓不支援特定傳輸方式的上游突然具備該能力。測試串接連線時，應先確認上游可獨立運作，再加入下游轉送。

自訂完整設定可能會略過用戶端自動產生的部分路由和 DNS。儲存前應查看介面說明，確認系統代理入口仍指向實際監聽連接埠。在圖形介面修改路由後，不要假設自訂設定也會同步變更。相反地，暫存產生的檔案可能在下次啟動時被覆蓋；長期維護應使用用戶端正式支援的設定入口，並保留原始檔案以便回復。

依序驗收設定結構、入口、路由與出口

先檢查 JSON 語法，再確認核心是否支援各欄位。合法的 JSON 只代表括號、逗號和字串結構正確，不代表設定語意成立。若啟動日誌出現未知協定、找不到標籤或連接埠遭占用，應先解決這些本機錯誤。核心穩定啟動後，再從單一應用程式發出請求，確認入站是否收到連線、路由是否選到預期出站，以及上游是否接受連線。

若瀏覽器連線成功、終端機卻失敗，先確認終端機是否確實使用本機入口，不要繼續修改出站。部分終端機程式需要另外設定代理環境變數或參數，系統代理不會自動套用到所有程式。詳細排查方式請參閱系統代理未生效：分別排查瀏覽器與終端機。每次驗收都應建立新連線，舊工作階段可能仍使用原本的出口。

最後記錄四項結果：設定能否載入、目標請求命中哪條規則、使用哪個出站，以及關閉進階功能後能否恢復。接著分別驗證訂閱更新、區域網路存取和必要的 UDP 服務，不要只測試一個網頁。完成後恢復日常日誌層級，移除臨時規則和多餘入口。日後更換用戶端或核心時，依相同順序重新測試；能匯入設定檔，不代表所有行為都維持一致。