V2Ray 進階設定：訂閱、路由、DNS 與 TUN

02 / 訂閱整理

訂閱分組與伺服器篩選

訂閱負責批次提供伺服器，但伺服器數量增加後，選擇成本與誤操作也會同步增加。有效的整理方式不是把所有節點放進一個很長的清單，而是先依來源分組，再依用途篩選。v2rayN 適合將預設分組、外部訂閱與自建節點分開；v2rayNG、v2flyNG 則可利用訂閱設定與備註欄位區分來源。分組邊界應保持穩定，節點備註可以變動，但來源、用途與維護責任不應混在一起。

每個訂閱都應使用容易辨識的名稱，例如「日常訂閱」「測試線路」「自建服務」。名稱只表示來源，不要把目前節點狀態寫進名稱，因為狀態會隨時間改變。手動新增的伺服器應獨立保留，不要移到會自動更新的訂閱群組中，以免更新時難以判斷它是否受到訂閱覆蓋。對於不再使用的訂閱，先停用自動更新並觀察一段時間，再刪除其分組；直接清空可能同時失去原有備註與選擇記錄。

篩選器要解決什麼問題

伺服器篩選適合從長清單中縮小候選範圍。常見維度包括備註關鍵字、協定類型、傳輸方式與訂閱來源。篩選條件首先應保持可理解：輸入關鍵字後，使用者能從伺服器備註看出匹配原因。複雜的正規表示式雖然靈活，但訂閱命名稍有變化就可能漏選。較穩定的做法是要求同一訂閱的備註採用一致格式，再以地區、用途或線路類別作為關鍵字。

篩選與路由是兩回事。篩選決定介面中要顯示或批次測試哪些伺服器，路由決定連線後某個請求要走哪個出站。不要用伺服器篩選取代流量分流，也不要因為某個節點被隱藏，就認為它已從設定中完全刪除。部分客戶端的篩選只會改變清單顯示，使用中的節點仍可能繼續運作；執行批次刪除前，應先確認目前選取項目與分組範圍。

關鍵字與正規表示式的使用界線

簡單關鍵字適合日常選擇，例如依備註中的「工作」「自建」或協定名稱篩選。需要表達多個備選詞時，可使用正規表示式的選擇符；需要排除測試節點時，可使用負向條件，但應先在小範圍內驗證。不同客戶端的篩選入口與正規表示式能力可能不同，複製表示式前應確認它是套用於伺服器備註、位址還是完整顯示名稱。以下表示式只展示通用思路，不依賴特定節點數量或速度資料。

工作|自建
^(?!.*測試).*
(VLESS|VMess|Trojan)

第一行會匹配備註中包含「工作」或「自建」的項目；第二行會排除包含「測試」的名稱；第三行則依顯示名稱中的協定詞進行篩選。若訂閱採用不同的命名方式，應先查看實際備註再調整。篩選結果為空時，先移除邊界符號與排除條件，確認基本關鍵字可以匹配，再逐步增加限制。不要一開始就編寫很長的表示式，否則難以判斷是哪一段造成不匹配。

更新、去重與失效項目的處理

訂閱更新應優先在單一分組內執行。更新後先確認項目是否正常解析，再切換使用中的節點。同一伺服器可能因備註不同而重複出現，也可能只是位址相同但參數不同；去重時不能只看網域與連接埠，還應比較使用者識別碼、協定、傳輸方式、TLS 與路徑等關鍵參數。自動去重適合完全一致的項目，參數有差異時保留並重新命名會更穩妥。

失效項目可分為暫時無法連線、參數錯誤與訂閱撤銷三類。一次連線失敗不足以判定長期失效，應先切換本機網路或等待線路恢復；若持續出現協定解析錯誤，則檢查訂閱是否使用目前客戶端無法識別的欄位；更新後從訂閱中消失的項目通常是來源方撤銷，不建議手動複製回自動分組。測速只用於比較目前網路條件下的回應，不能作為永久排序依據。

三款客戶端的分組重點

v2rayN 的桌面清單空間較大，適合管理多個訂閱、批次更新與細緻篩選，也是桌面平台的首選。v2rayNG 使用觸控清單，建議減少同時啟用的訂閱數量，名稱保持簡短並保留明確前綴。v2flyNG 的管理方式接近 Android 的使用習慣，但核心家族不同，匯入同一訂閱後仍應確認協定與傳輸參數是否完整識別。需要重新安裝或更換平台時，請從下載頁依系統選擇對應客戶端。

完成整理後，應進行一次可復原性檢查：記住目前使用中的訂閱與伺服器，手動更新單一分組，確認更新不會改動自建節點，再重新啟動客戶端驗證選擇是否保留。若客戶端在更新後切換了使用中項目，檢查是否啟用了自動選擇，或目前項目是否已被訂閱替換。訂閱位址屬於持續存取憑據，不應寫入公開截圖、記錄或共用規則檔案；排錯時只需說明訂閱解析結果與錯誤類型。

04 / 名稱解析

DNS 設定最佳化與分流解析

DNS 設定決定網域如何取得位址，也影響網域規則與 IP 規則之間的銜接。系統 DNS、客戶端內建 DNS、瀏覽器加密 DNS 與應用程式自帶解析可能同時存在；若查詢沒有經過預期路徑，就會出現「路由寫對但仍走錯出站」的情況。最佳化前先確認查詢來源：系統代理通常不會自動接管所有 DNS，TUN 模式更適合將系統查詢統一送入客戶端，但仍需處理瀏覽器或應用程式自行發起的加密查詢。

DNS 分流的基本目標，是讓不同網域選擇合適的解析伺服器，並讓查詢本身透過正確出站傳送。網域分類、查詢伺服器與路由出站是三個獨立決策。某個網域被分配給特定 DNS 伺服器，不代表其業務連線一定使用同一個出站；還需要路由規則提供相應限制。反過來，只寫業務路由而不處理解析路徑，應用程式可能先取得不合適的位址，接著觸發錯誤的 IP 規則。

伺服器順序與匹配範圍

核心 DNS 可以設定多個伺服器，並為伺服器附加網域匹配清單。專用匹配應放在通用伺服器之前。內部網域可指向區域網路 DNS，指定外部網域可使用加密查詢，其餘網域交給預設伺服器。若客戶端支援 skipFallback 類型的控制項，可阻止已匹配的網域繼續向後備伺服器查詢；但啟用前應確保專用伺服器穩定，否則匹配網域沒有可用結果時，也不會自動取得後備答案。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "full:intranet.example",
          "domain:office.example"
        ],
        "skipFallback": true
      },
      {
        "address": "https://dns.example/dns-query",
        "domains": [
          "domain:service.example"
        ]
      },
      "localhost"
    ]
  }
}

範例將內部網域交給區域網路解析伺服器，將指定服務交給一個範例加密查詢位址，其餘請求使用本機解析。實際設定時，加密查詢網域本身也需要能夠解析並建立連線，這項引導解析不能依賴尚未可用的同一條加密通道。解決方式是讓系統或基礎 DNS 先解析查詢伺服器網域，或直接使用客戶端支援的引導機制。若記錄持續顯示查詢伺服器網域解析失敗，應先處理這層依賴。

查詢策略與位址族

queryStrategy 控制回傳哪一類位址。UseIP 允許使用可用的位址族，UseIPv4 只請求 IPv4，UseIPv6 只請求 IPv6。選擇應以本機網路與出站鏈路是否完整支援對應位址族為準。系統取得 IPv6 位址，但代理鏈路無法建立 IPv6 連線時，應用程式可能先等待失敗再回退，表現為首次存取明顯變慢。此時可以暫時使用 IPv4 策略驗證，但長期方案仍應檢查本機網路、節點出站與路由規則對 IPv6 的處理。

不要用固定位址族掩蓋所有解析問題。某些服務會依位址族提供不同的接入方式，區域網路內部服務也可能只在特定位址族可用。調整後分別測試內部網域、常用公網網域與純 IP 連線，確認沒有破壞其他路徑。若只有一個應用程式異常，檢查它是否啟用了獨立 DNS 或連線最佳化功能，因為該查詢可能根本沒有進入客戶端。

DNS 與路由如何配合

DNS 查詢本身也是網路請求，需要由路由決定直連還是代理。加密 DNS 使用一般 TCP 或 HTTPS 連線時，可以依伺服器網域或 IP 指定出站。若查詢透過代理傳送，請確保代理出站在解析前已具備可連線的伺服器位址；訂閱節點使用網域作為伺服器位址時，尤其要注意啟動階段的解析依賴。最穩妥的啟動鏈路，是先讓節點伺服器網域可由基礎 DNS 解析，再由已建立的代理處理後續專用查詢。

路由使用 IPIfNonMatch 時，網域規則未命中便會觸發 DNS 解析，然後再匹配 IP 規則。此時 DNS 伺服器回傳的位址會直接影響路由結果。若同一網域存在多組位址，快取結果變化可能讓流量命中不同規則。應盡量優先使用穩定的網域規則，IP 規則則用於區域集合、私有位址及確實需要依位址判斷的目標，而不是為每個網域手動維護位址。

快取、洩漏路徑與驗證方法

驗證 DNS 時，先關閉瀏覽器的獨立解析選項，或明確將其納入測試範圍。重新連線客戶端後，清除系統與瀏覽器的相關快取，再發起一次全新的查詢。記錄中應能看到網域、選用的 DNS 伺服器、回傳位址，以及後續業務連線的路由結果。只使用網頁型檢測工具，無法說明所有系統查詢路徑，因為它觀察的是目前瀏覽器，而不是終端機、背景服務與其他應用程式。

如果一般系統代理下 DNS 仍由本機網路處理，這是接管範圍的差異，不一定是設定錯誤。需要統一接管更多應用程式時，再啟用 TUN，並為 DNS 設定明確的入站與路由。若啟用 TUN 後出現解析迴圈，檢查 DNS 請求是否再次進入 TUN、是否缺少查詢伺服器的直連或代理例外，以及 FakeDNS 是否與真實解析規則重疊。完整的分流解析案例可繼續查看V2Ray DNS 分流解析設定詳解。

06 / 網域映射

FakeDNS 的運作方式與適用範圍

FakeDNS 會為網域回傳保留位址池中的暫時位址，並在核心內部儲存網域與該位址的映射。應用程式連線至這個暫時位址時，核心會依映射還原原始網域，再執行路由與實際連線。它主要解決的問題是：某些應用程式先自行發起 DNS 查詢，之後只將 IP 連線交給 TUN，導致核心失去原始網域，網域規則無法命中。FakeDNS 將網域資訊保留到後續連線階段，使分流判斷更穩定。

FakeDNS 不是一般 DNS 伺服器的替代品，也不會憑空改善所有解析問題。核心還原網域後，真正建立連線時仍需要依設定完成解析，或交由相應出站處理。若路由、真實 DNS 或出站設定錯誤，FakeDNS 只會讓問題更難觀察。因此應在 TUN 基礎鏈路與一般 DNS 已穩定後啟用，並明確哪些查詢進入 FakeDNS，哪些內部網域必須回傳真實位址。

位址池與映射容量

FakeDNS 設定包含位址池與映射容量。位址池必須使用專門保留的範圍，不能與區域網路、企業網路、容器網路或現有虛擬介面重疊。發生重疊時，系統可能將暫時位址送往真實網路，或將真實內部位址誤交給 FakeDNS。容量決定可同時儲存多少網域映射；容量不足會淘汰舊映射，應用程式仍持有舊位址時可能無法還原網域。日常使用應保留客戶端預設值，只有確認存在大量並行網域且記錄顯示映射遭淘汰時才調整。

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

198.18.0.0/15 是常見的基準測試保留位址範圍，許多實作會將其用於虛擬映射。使用前仍需檢查本機網路與其他工具是否占用該範圍。設定片段只代表核心中的 FakeDNS 物件；要讓查詢真正進入其中，還需要對應的 DNS 設定、入站嗅探與 TUN 接管。單獨新增物件不會自動改變系統查詢路徑。

嗅探與目標覆寫

入站嗅探用於從連線中識別網域或協定資訊。配合 FakeDNS 時，常見的目標覆寫包含 HTTP、TLS 與 FakeDNS 映射。是否啟用目標覆寫應依客戶端範本決定：覆寫可讓路由使用還原後的網域，但也可能改變某些特殊連線的目標處理。先使用客戶端提供的標準 FakeDNS 模式，查看產生的設定後再進行自訂。不要一次開啟所有協定識別選項。

{
  "inbounds": [
    {
      "tag": "tun-in",
      "protocol": "tun",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "fakedns"
        ],
        "routeOnly": true
      }
    }
  ]
}

routeOnly 表示識別結果主要用於路由判斷，不會直接替換最終連線目標，適合希望降低目標改寫影響的環境。具體欄位是否由目前核心與客戶端設定方式支援，應以客戶端產生的結果為準。若載入設定時回報未知欄位，先撤回自訂片段，改用介面中的 FakeDNS 選項，再檢查核心家族與設定格式是否匹配。

不適合交給 FakeDNS 的目標

區域網路網域、企業內部網域、列印與探索服務通常需要真實位址，應繞過 FakeDNS 並交給內部 DNS。依賴本機位址判斷、憑證綁定或特殊解析結果的應用程式，也可能不適合虛擬映射。排除規則應盡量具體：先排除明確的內部網域與保留後綴，再觀察是否存在其他異常。直接排除大範圍網域，會讓 FakeDNS 失去保留網域資訊的意義。

部分應用程式會驗證 DNS 回傳位址、繞過系統解析，或使用自己的加密查詢。前兩種情況可能導致 FakeDNS 不生效，後一種情況則可能讓查詢直接作為一般 HTTPS 連線進入 TUN，此時核心只能依連線特徵嘗試還原網域。若記錄中看不到 FakeDNS 查詢，不要反覆修改位址池，先確認應用程式的查詢是否進入客戶端。

常見故障的判斷順序

啟用後完全無法解析，先檢查 DNS 是否將查詢送入 FakeDNS；能回傳暫時位址但連線失敗，檢查 TUN 是否接管該位址範圍，以及入站能否還原網域；只有內部服務失敗，檢查內部網域排除規則與區域網路 DNS；使用一段時間後偶爾失敗，檢查映射容量、應用程式快取與休眠恢復。每種症狀對應不同層級，不能用更換 DNS 伺服器解決所有問題。

驗證時可以觀察查詢是否回傳保留位址，再在核心記錄中確認同一位址被映射回原始網域，並查看最終出站。不要使用系統工具直接連線至暫時位址來判斷伺服器是否可達，因為它本來就不代表真實伺服器。關閉 FakeDNS 後，應清除應用程式與系統的相關 DNS 快取，避免應用程式繼續連線至已失效的暫時位址。

與真實 DNS 分流並存

成熟的設定通常會同時存在 FakeDNS 與真實 DNS：一般公網網域可先回傳暫時位址以保留網域，內部網域直接向區域網路 DNS 查詢真實位址，節點伺服器網域透過基礎 DNS 完成啟動解析，少數指定服務再使用專用加密查詢。每組網域都應有明確優先級，避免同一目標既被內部 DNS 匹配，又進入 FakeDNS。調整後分別測試公網網頁、內部服務、節點重新連線與系統休眠恢復，確認映射在生命週期變化後仍能重建。

08 / 出站編排

自訂出站、鏈式轉送與系統化排錯

出站是路由決策的最終目標。常見出站包括代理節點、直接連線、阻斷，以及轉送至本機或上游 SOCKS 服務。自訂出站適合將特定業務交給獨立出口、重用本機既有服務，或建立清楚的測試路徑。設定重點是標籤唯一、協定參數完整，且依賴關係不能形成迴圈。路由只透過標籤引用出站，因此重新命名後必須同步更新所有規則。

圖形客戶端通常會依目前節點產生主要代理出站，同時加入直連與阻斷出站。手動擴充時不要覆蓋這些基礎物件，除非已確認客戶端的合併方式。較穩妥的方法是使用客戶端提供的自訂設定、預設設定或範本入口，建立一個唯一標籤，再用一條具體路由進行測試。直接修改執行時檔案，會在切換節點或重新啟動後失效，也可能造成介面狀態與實際設定不一致。

新增本機 SOCKS 上游

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

範例建立名為 local-socks 的出站，將連線交給本機 1081 連接埠的 SOCKS 服務。使用前應確認該連接埠確實在監聽，並避免其流量再次被同一個 TUN 捕獲後送回自身。若上游需要驗證，應在客戶端支援的設定結構中加入實際憑據，並只保存在本機。測試時先將一個明確網域指向該出站，不要直接把全域流量切換過去。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:service.example"
        ],
        "outboundTag": "local-socks"
      }
    ]
  }
}

規則中的標籤必須與出站標籤逐字一致。設定載入失敗時，先檢查 JSON 結構、重複逗號與欄位位置；載入成功但沒有走上游時，檢查規則順序與網域是否命中；已命中但連線失敗時，再檢查本機連接埠、上游驗證與迴圈路由。分層檢查比反覆更換節點更快。

鏈式轉送的風險控制

鏈式轉送會讓一個出站透過另一個出站建立連線。它適合具有明確網路拓撲的環境，但會增加解析依賴、連線層數與故障點。開始前先畫出路徑：應用程式進入哪個入站，路由選擇哪個業務出站，該出站透過哪個前置出站連線，節點伺服器網域由誰解析。路徑中的任何一段重新回到前面的入口，都可能形成迴圈。

鏈式結構不應透過模糊的全域規則實現。為前置出站與業務出站使用明確標籤，為上游伺服器位址加入必要的直連或指定路由，並保留一個不經過鏈路的基礎連線作為回退。發生逾時後，先分別驗證每一跳是否可用，再進行組合測試。若各自可用但組合失敗，重點檢查 DNS 啟動依賴、UDP 支援，以及 TUN 是否再次捕獲上游連線。

直連與阻斷出站

直連出站用於區域網路、內部服務與不需要代理的目標。阻斷出站用於明確拒絕連線。阻斷規則應具體，並放在廣泛代理規則之前。直接使用大範圍分類可能影響登入、付款、更新或嵌入資源，因此新增後要驗證頁面主網域與資源網域。若只想避免某個應用程式使用代理，優先使用程序規則或入站隔離；若客戶端與核心不支援穩定的程序識別，再使用容易理解的網域與 IP 條件。

直連不代表繞過客戶端的所有處理。流量可能先進入 TUN，再由核心選擇直連出站；也可能在系統路由層直接繞過 TUN。兩種方式對記錄、DNS 與本機服務相容性有不同影響。需要記錄並統一路由時，可讓流量進入核心後直連；區域網路探索、裝置存取等對本機網路敏感的流量，通常更適合在系統路由層繞過，同時保留私有位址直連規則。

依記錄建立排錯矩陣

進階設定排錯應回答四個問題：流量是否進入客戶端、網域由誰解析、哪條路由命中，以及最終出站是否建立連線。記錄詳細程度只在排錯期間提高，完成後恢復一般等級，避免大量記錄影響查找。若記錄中沒有目標請求，檢查系統代理、應用程式代理或 TUN；有請求但沒有網域，檢查 DNS 接管與嗅探；路由標籤錯誤，調整規則順序；出站連線失敗，檢查對應伺服器與上游。

建立長期可維護的設定

可維護的設定應盡量少依賴節點名稱、暫時位址與介面排序。路由引用穩定的出站標籤，DNS 使用明確的網域群組，訂閱保持來源邊界，TUN 與 FakeDNS 只在需要時啟用。每個自訂物件都應寫明用途，並保留能正常運作的基礎設定。發生故障時先停用最近新增的物件，確認基準恢復，再將問題縮小到一條規則或一個出站。

設定完成後進行四輪驗收：重新啟動客戶端，驗證設定可載入；切換節點，驗證路由不依賴舊節點；更新訂閱，驗證自訂分組與標籤未被覆蓋；重新啟動系統，驗證 TUN、DNS 與系統代理能正確建立與恢復。只透過一次網頁存取不算完成。涉及內部網路時，還要驗證區域網路服務、內部網域與系統休眠恢復。

若問題仍無法定位，先回到快速入門主線驗證最小連線，再前往說明中心核對安裝設定與故障排查項目。涉及系統代理、DNS 或速度差異時，也可結合本站技術筆記中的分層案例繼續檢查。