V2Ray 進階設定手冊

CHAPTER 01 / BASELINE

設定基準：先分清客戶端、核心與系統網路

進階設定最常見的問題，不是某個參數打錯，而是把不同層級的設定混在一起。v2rayN、v2rayNG 與 v2flyNG 負責匯入訂閱、選擇伺服器、產生設定及控制連線狀態的圖形化客戶端；Xray、V2Fly 等核心負責執行協定、路由、DNS 與出站邏輯；系統代理、虛擬網卡及應用程式本身的網路選項，則決定流量是否真正進入核心。排查時必須先確認故障位於哪一層，否則反覆更換伺服器只會掩蓋現象。

建立可復原的設定起點

開始調整前，先在客戶端匯出目前可用的設定，或記錄訂閱來源、使用中的伺服器、代理模式、路由方案與 DNS 設定。v2rayN 的訂閱資訊、伺服器清單與路由方案屬於客戶端管理資料；核心執行時產生的設定可能隨介面選項變更，不應只複製某一段暫時性的 JSON 當作完整備份。行動裝置還要記錄是否啟用 VPN 服務、分應用程式代理及略過區域網路，因為這些選項會改變實際流量範圍。

設定基準應符合三項條件：一般瀏覽器能依預期存取網路；客戶端記錄中沒有持續重複的啟動錯誤；選定的伺服器項目包含完整的位址、連接埠、使用者識別、傳輸方式與安全性參數。只有基準可用，後續的分流與 DNS 比較才有意義。如果基本連線尚未完成，應先返回快速入門主線，依照匯入訂閱、選擇伺服器、啟動連線及驗證流量的順序處理。

讀取記錄時先找第一個錯誤

核心記錄往往會在同一個故障後連續輸出多筆訊息。真正有價值的是啟動後出現的第一個設定錯誤、解析錯誤或連線錯誤。例如，路由規則引用了不存在的出站標籤，後續所有連線都會失敗；DNS 伺服器無法連線，之後可能表現為網域逾時；系統代理未生效，客戶端記錄甚至可能完全沒有對應要求。不要只盯著最後一行，也不要把一般的連線關閉記錄當成根因。

建議依照「客戶端是否啟動核心—要求是否進入本機入口—網域是否完成解析—路由是否命中預期規則—目標出站是否建立連線」的順序檢查。若客戶端沒有啟動核心，檢查設定產生與連接埠占用；若要求沒有進入本機入口，檢查系統代理、瀏覽器獨立代理或 TUN 狀態；若只有網域失敗而直接存取 IP 有回應，重點轉向 DNS；若部分網站走錯線路，再檢查路由順序與網域集合。

參數來源與優先順序

訂閱提供伺服器連線參數，客戶端儲存本機覆寫項目，路由與 DNS 方案決定執行邏輯，系統網路決定流量入口。訂閱更新可能重建伺服器項目，因此不適合把長期規則只寫在某個伺服器備註中。需要持續保留的分組、篩選與路由策略，應放在客戶端的訂閱設定、路由方案或獨立設定中。若確實需要編輯原始設定，應先確認客戶端不會在下次啟動時覆寫。

完成本章後，應能明確判斷目前問題屬於資料管理、核心執行或系統接管。這項判斷會決定後續工具：伺服器項目混亂就處理訂閱；存取方向不正確就處理路由；網域異常就處理 DNS；只有不遵循系統代理的程式無法接入時，才考慮 TUN。拆開各個層級，是整本手冊後續設定能穩定重現的前提。

CHAPTER 02 / GROUPS

訂閱分組與伺服器篩選

單一訂閱也可能包含大量項目。把所有伺服器平鋪在同一個清單中，會讓選擇、更新與故障定位逐漸失控。分組的目標不是追求複雜層級，而是分開表達「資料來自哪裡」「項目適合什麼用途」「哪些內容應暫時隱藏」。v2rayN 適合在桌面端集中整理多個訂閱；v2rayNG 與 v2flyNG 的行動情境則應保留較少且意義明確的分組，降低切換成本。

先按來源分組，再按用途篩選

訂閱來源是最穩定的第一層界線。為每個來源設定清楚的名稱，例如「日常線路」「測試線路」「備用線路」，不要把地區、協定、倍率與用途全部塞進同一個組名。來源分組有助於判斷更新失敗影響哪一批資料，也方便單獨停用失效來源。用途則適合透過備註關鍵字與篩選條件處理，例如保留名稱含有「辦公」或「低倍率」的項目，隱藏含有「到期」「剩餘」「官網」等通知類項目。

篩選通常包含保留與排除兩個方向。保留規則適合明確的小集合，例如只顯示備註含有「日本」或「新加坡」的伺服器；排除規則適合清理通知項目與暫時不用的協定。若同時使用兩類規則，應先了解客戶端的處理順序：一般會先從訂閱取得完整項目，再套用篩選條件。篩選只會改變客戶端清單檢視或匯入結果，不會改變遠端訂閱本身。

正規表示式篩選的安全寫法

當一般關鍵字不足以表達條件時，可以使用正規表示式。地區名稱可用直線符號表示「任一項」，排除通知詞也能合併處理。正規表示式應保持簡短，並先在少量項目上驗證。過度複雜的前瞻、回溯條件不利於維護，也可能因不同客戶端的表示式實作差異而得到不同結果。

保留範例：
日本|東京|新加坡|美國

排除範例：
到期|剩餘|公告|網址|流量

精確比對常見地區前綴：
^(日本|新加坡|美國)[-_ ]

中文、英文縮寫與旗幟符號可能同時出現在備註中。若訂閱命名不一致，應先觀察完整清單，再決定關鍵字，不要直接套用網路上的冗長表示式。篩選後項目突然歸零時，先清空條件確認原始訂閱是否正常，再逐段恢復表示式。若只有部分名稱未比對，檢查全形空格、連字號與大小寫差異。

測速結果不等於可用性結論

伺服器篩選常與測速一起使用，但延遲測試只回答某個探測要求是否能抵達，不能完整代表實際協定連線、目標網站存取或持續傳輸表現。TCP 探測可達，不代表驗證參數正確；單次延遲較低，也不代表尖峰時段穩定。篩選時應先剔除明顯無法連線的項目，再以實際存取驗證候選線路，不應只依一個數字永久排序。

較穩妥的流程是：更新單一訂閱，確認項目數量與備註結構；套用排除規則，清理通知項目；選取少量候選伺服器執行連線測試；啟動其中一條並存取常用目標；最後儲存適合目前網路的排序。網路環境變化後重新測試，不要把舊結果當成固定屬性。關於節點測速失真與判斷方法，可搭配站內文章清單中的排障內容繼續閱讀。

更新後的差異檢查

訂閱更新後至少檢查三項：來源名稱是否仍對應原本分組；伺服器備註是否變更，導致篩選規則失效；目前使用中的伺服器是否被替換或刪除。如果訂閱方調整命名格式，舊關鍵字可能會把新項目全部排除。此時先關閉篩選查看原始結果，再更新表示式。若某個來源更新失敗，不要立即執行全部訂閱覆寫更新，應單獨檢查連結狀態、是否需要透過既有連線更新，以及回傳內容是否仍是客戶端能辨識的格式。

分組完成的標準不是清單看起來整齊，而是能回答三個問題：目前伺服器來自哪個訂閱、為什麼會出現在這個篩選結果中、更新失敗時應操作哪個來源。只要這三項清楚，後續多訂閱管理與路由綁定就有穩定基礎。

CHAPTER 03 / MULTI-SUBSCRIPTION

多訂閱管理與更新策略

多個訂閱同時存在時，主要風險不是項目數量，而是來源之間發生覆蓋、重名與更新時程衝突。合理的多訂閱結構應讓每個來源都能獨立更新、獨立停用、獨立排錯，同時避免把訂閱位址複製到不必要的位置。桌面端通常由 v2rayN 作為集中管理入口；Android 端可以只匯入需要隨身使用的來源，避免每次更新都要處理大量重複伺服器。

為每個來源建立獨立識別

新增訂閱時，名稱應表達用途，而不是暴露完整位址，例如「主要桌面」「行動備用」「協定測試」。如果兩個來源可能包含同名伺服器，可在訂閱名稱中加入簡短前綴，並保留客戶端提供的來源識別。伺服器備註可以變動，訂閱識別不應跟著變動。不要使用「訂閱一」「訂閱二」這類無法回想來源的名稱，也不要用目前日期作為長期名稱。

同一個位址不應重複加入多個分組。重複來源會在更新後產生相似項目，導致選擇時無法判斷實際歸屬。發現重複時，先比較訂閱位址與更新時間，再保留一筆管理記錄。若客戶端支援按訂閱移除伺服器，應使用來源層級操作，而不是在總清單中逐項刪除，因為下次更新可能再次匯入。

安排更新順序與失敗隔離

穩定的做法是先更新目前使用中的主要來源，確認可連線後，再依序更新備用來源。全部平行更新雖然操作較少，但某個來源回傳異常內容時更難定位。自動更新間隔不宜設定得過密；訂閱內容通常不是即時狀態流，頻繁請求不會讓線路本身更穩定。需要自動更新時，應選擇能涵蓋日常變動的週期，並保留手動更新入口以便故障復原。

更新失敗可從四個方向判斷：位址本身已失效；目前網路無法直接存取訂閱位址；伺服器根據請求特徵拒絕回傳；回傳內容格式與客戶端不相容。第一步是在客戶端單獨更新該來源並查看提示；第二步嘗試在已有可用連線下透過代理更新；第三步確認複製位址時沒有多餘空格、換行或截斷；第四步檢查回傳的是訂閱資料還是一般網頁。更完整的分支可參考訂閱更新失敗排查與自動更新設定。

合併、轉換與本機規則的界線

訂閱轉換適合處理客戶端格式差異、篩選欄位與合併輸出，但轉換鏈越長，定位問題越困難。若 v2rayN、v2rayNG 或 v2flyNG 能直接辨識原始來源，應優先直接匯入。確需轉換時，應明確轉換過程是只改變封裝格式，還是同時改寫協定參數、伺服器名稱與路由規則。任何改變連線參數的步驟，都可能造成原始訂閱可用而轉換結果失敗。

不要把本機長期路由規則建立在遠端訂閱的臨時備註上。備註可用於篩選伺服器，卻不適合作為網域分流條件。路由應依目標網域、IP、連接埠、程序或入站標籤編寫，並與伺服器清單來源分離。如此即使切換訂閱，存取策略仍能保持一致。只有需要將某類目標固定送往特定伺服器時，才把路由規則與穩定的出站標籤建立關聯。

行動端與桌面端的同步取捨

多部裝置之間不必追求伺服器清單完全相同。桌面端可能需要多個出站、複雜路由與 TUN 接管，行動端則更適合精簡來源與簡單的分應用程式規則。可以同步訂閱來源名稱與核心篩選原則，但系統相關設定應分開儲存。尤其不要直接把桌面端含有本機監聽連接埠、程序規則與桌面 DNS 位址的完整設定複製到行動端。

清理舊來源的順序

停用來源時，先取消自動更新，再切換到其他已驗證的伺服器，接著從該來源移除伺服器，最後刪除訂閱記錄。直接刪除目前使用中的來源，可能讓客戶端仍顯示舊連線狀態，但下次啟動時無法復原。清理後重新檢查使用中的伺服器、預設出站與路由標籤，確認沒有規則繼續引用已刪除的物件。

多訂閱管理達到穩定狀態後，每個來源都應有明確用途與更新方式；任何來源失敗都不會阻斷其他來源；路由與 DNS 不依賴臨時伺服器備註；桌面與行動端只共享必要資料。這樣的結構比簡單合併成一條超長訂閱更容易維護，也更適合後續加入自訂出站。

CHAPTER 04 / ROUTING

路由規則實戰：比對條件、順序與出站

路由的作用，是將已進入核心的連線，依照目標網域、目標 IP、連接埠、網路類型、程序或入站標籤，送往指定出站。它不會自動讓應用程式流量進入客戶端，也不會修復伺服器連線參數。系統代理或 TUN 負責入口，路由只處理入口之後的方向選擇。理解這條界線，就能避免把「應用程式沒有經過客戶端」誤判為「分流規則未命中」。

從三類出站開始

常見的基礎結構包含代理出站、直連出站與阻斷出站。代理出站指向目前選定的伺服器或自訂代理鏈；直連出站由本機網路直接存取目標；阻斷出站用於拒絕明確不需要的連線。每個出站都應有穩定且意義清楚的標籤，例如 proxy、direct、block。路由規則透過標籤引用出站，因此修改標籤後必須同步修改所有引用。

規則順序通常採用由具體到一般。先放明確的阻斷、內網直連、指定網域或指定程序規則，再放較大的網域集合與 IP 集合，最後由預設出站接收未命中的流量。如果把寬泛規則放在前面，後面的精確規則永遠沒有執行機會。例如先將所有 TCP 流量比對至代理，再寫入某個網域直連規則，直連規則就可能失效。

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

上例先讓私有位址直連，再處理指定網域與網域集合。domain: 表示比對該網域及其子網域，full: 更適合只比對完整主機名稱，keyword: 會比對包含指定片段的網域，範圍最大，誤比對風險也最高。規則語意會隨核心設定格式而變化，客戶端介面產生的方案通常更適合日常維護；直接編輯 JSON 時，要確認欄位屬於目前核心支援的設定結構。

網域與 IP 比對如何銜接

當路由只收到網域時，網域規則可以直接判斷；當規則需要依 IP 集合比對時，核心可能需要先解析網域。domainStrategy 決定何時進行這一步。僅依網域規則運作時，可以避免額外解析；需要「網域規則未命中後再依 IP 判斷」時，可使用相應的按需解析策略。若無條件先解析所有網域，會增加 DNS 請求，也可能讓路由使用的解析結果與應用程式預期不一致。

GeoSite 是網域集合，GeoIP 是 IP 位址集合。兩者依賴本機資料檔案，規則寫法正確但資料過舊時，仍可能出現新網域未涵蓋或位址分類變更。更新後應重新啟動核心，讓執行中的設定重新載入資料。具體更新與錯誤分流排查可參考GeoIP 與 GeoSite 資料庫更新教學。

內網、區域網路與私有位址

家用路由器、印表機、檔案共享與本機開發服務通常使用私有位址，應優先直連。否則存取本機裝置時可能被送往遠端出站而失敗。除了私有 IP 集合外，也要留意 localhost、.local 名稱與企業內部網域。內部網域往往只能由區域網路 DNS 解析，應在 DNS 分流中指定本機解析伺服器，並在路由中安排直連。

在 TUN 模式下，客戶端的接管範圍更廣，內網直連規則尤其重要。若啟用 TUN 後無法存取路由器管理頁面，先檢查私有 IP 是否繞過代理、虛擬網卡路由是否涵蓋區域網路網段，再確認系統防火牆。不要為了恢復一個本機位址而關閉全部路由規則，精確增加直連目標更容易驗證。

規則未生效的逐項排查

先確認請求確實進入核心，再在記錄中觀察目標是網域還是 IP。若只看到 IP，純網域規則可能無法比對；若目標網域已命中前面的寬泛規則，調整順序；若引用 GeoSite 或 GeoIP，檢查資料檔案是否載入；若規則指向自訂出站，檢查標籤是否完全一致；若客戶端提供「略過區域網路」「全域」「規則」等模式，確認目前模式沒有覆蓋自訂方案。

驗證時選擇一個目標，分別測試直連、代理與阻斷三種可觀察結果。不要同時拿多個網站判斷，因為網頁可能載入不同網域的主要資源、圖片與介面，看起來會像同一個請求走了多條線路。瀏覽器快取與持久連線也會影響結果，修改規則後應重新啟動核心並建立新連線。路由的穩定標準是能逐條解釋規則意圖、命中順序與出站標籤，而不是某次重新整理剛好成功。

CHAPTER 05 / DNS

DNS 設定最佳化：查詢路徑、分流與洩漏排查

DNS 決定網域如何轉換為位址，也會影響路由能否依網域或 IP 正確比對。進階設定中最常見的混亂，是系統 DNS、應用程式內建 DNS、客戶端 DNS 與遠端出站解析同時存在，卻沒有明確哪一層負責哪些網域。最佳化的目標不是堆疊更多伺服器，而是建立一條可解釋的查詢路徑：要求從哪裡進入、由哪台伺服器解析、查詢本身經過哪個出站，以及結果交給哪條路由。

區分系統查詢與核心查詢

在一般系統代理模式下，部分應用程式可能先在系統端解析網域，再把 IP 交給代理；另一些支援代理協定的應用程式則會將網域交給客戶端。TUN 模式可以接管更多 DNS 流量，但仍可能遇到應用程式使用加密 DNS 或自帶解析器的情況。若記錄中只出現目標 IP，表示網域資訊可能在進入核心前已經遺失，此時依網域分流的效果會受限。

核心 DNS 伺服器既可以使用傳統 IP 位址，也可以使用支援加密傳輸的服務位址，具體能力取決於核心與客戶端的產生方式。選擇時應同時考量可達性與出站路徑。若解析伺服器本身需要透過代理存取，而路由又依賴它的解析結果，可能形成循環依賴。基礎解析入口應在目前網路下明確可達，再為特定網域安排其他伺服器。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      },
      "localhost"
    ]
  }
}

這段範例表達的是依網域選擇解析伺服器，而不是要求所有網路照抄。domains 限定該伺服器負責的網域集合，expectIPs 可用於檢查回傳位址是否符合預期範圍，queryStrategy 決定查詢位址類型的偏好。若目前網路無法存取某個解析入口，應替換為可達服務，而不是繼續增加逾時重試。

DNS 分流與路由分流應保持一致

網域準備直連時，通常應使用適合本地網路的解析路徑；網域準備透過代理出站時，可以讓查詢同樣經過對應出站，避免解析位置與存取位置差異過大。兩套規則不必逐條重複，但整體方向應一致。若路由讓某個網域直連，而 DNS 查詢卻強制經過遠端出站，連線可能仍能運作，但會增加延遲與排查難度。

內部網域是最需要明確分流的情境。企業或家庭區域網路的內部名稱通常只有本機 DNS 能回答，應為相應的網域後綴指定本地解析伺服器，並在路由中直連對應位址。若公共 DNS 回覆不存在，客戶端不會自動知道還要向內部伺服器重試。相反地，公共網域不應全部交給只在區域網路有效的伺服器，否則離開目前網路後會整體失效。

快取、TTL 與切換後的舊連線

DNS 結果可能分別由應用程式、系統、客戶端與核心快取。修改解析設定後立即重新整理頁面，未必會觸發新查詢；已建立的連線也不會因 DNS 改變而自動遷移。驗證時應關閉舊連線、重新啟動核心，並在必要時清除系統 DNS 快取。不要為了追求「即時」而把快取時間設得過短，這會增加查詢數量，也無法解決伺服器本身回傳錯誤的問題。

伺服器位址變動頻繁的服務，應遵循合理的 TTL 並建立失敗重試；固定的內部服務則可以保留適度快取。若同一網域在不同網路回傳不同位址，切換網路後要特別留意舊快取。行動端從 Wi‑Fi 切換至行動網路時，重新啟動連線通常比等待所有快取自然過期更可控。

DNS 洩漏的判斷與修復

所謂 DNS 洩漏，核心問題是原本應經過指定路徑的查詢，被系統或其他應用程式傳送至未預期的解析伺服器。判斷時不能只看網頁上顯示了哪些 DNS 位址，還要結合目前網路、代理模式與預期路徑。系統代理模式無法天然接管所有應用程式的 DNS；TUN 模式覆蓋範圍較廣，但也需要正確攔截 DNS 流量。瀏覽器啟用獨立加密 DNS 後，還可能繞過系統與客戶端設定。

修復順序是先明確預期，再減少旁路：關閉或調整應用程式自己的解析器；讓系統 DNS 請求進入客戶端；為核心 DNS 指定明確出站；檢查路由是否把查詢送往錯誤方向；最後重新測試。若只在某個應用程式中出現，優先檢查該應用程式設定，而不是修改整個系統。完整操作可閱讀DNS 洩漏檢測與修復實作。

DNS 設定完成的標準，是能解釋每類網域由誰解析、查詢經過哪個出站、結果如何參與路由，並能在記錄中觀察到對應過程。伺服器數量越多不代表效果越好；一條短而清楚的查詢鏈，通常比多個隨機備用位址更穩定。

CHAPTER 06 / TUN

TUN 模式：系統流量接管與邊界控制

TUN 模式透過虛擬網路介面接收系統流量，適合不遵循系統代理、無法單獨設定代理或包含 UDP 請求的程式。它解決的是流量入口覆蓋範圍，不負責自動選擇正確伺服器，也不會取代路由與 DNS。啟用後，客戶端需要設定虛擬網卡、系統路由及 DNS 接管，因此故障範圍會從單一應用程式擴大到整個系統網路。應在一般代理模式已穩定可用後再啟用。

啟用前的檢查

先確認 v2rayN 或 Android 客戶端在一般模式下能使用目前伺服器，並儲存原有設定。桌面端需要具備建立虛擬網卡與調整路由所需的系統權限；安全軟體或企業政策可能限制這些操作。還要記錄本機區域網路網段、正在使用的 VPN 類軟體、虛擬機器網路與容器網路，因為多個虛擬介面可能爭用預設路由。

啟動 TUN 前關閉其他會修改系統路由的連線工具，避免同時接管。若必須共存，應明確每個介面的路由優先順序與目標網段，不要靠啟動順序碰運氣。客戶端異常結束後若網路中斷，先結束相關程序並恢復系統網路，再檢查殘留虛擬介面與 DNS，而不是反覆重新啟動瀏覽器。

堆疊模式與 MTU

不同客戶端與核心可能提供 system、gVisor 或 mixed 等網路堆疊選項。系統堆疊通常更貼近作業系統網路行為，相容性與效能受平台實作影響；使用者態堆疊便於在客戶端內部處理封包，對某些環境更穩定，但也可能與特定協定或應用程式存在差異。沒有明確故障時使用客戶端建議值即可，出現 UDP、區域網路或特定應用程式異常時再切換比較。

MTU 決定單一封包的最大大小。設定過大可能在複雜網路路徑中產生分片或封包遺失，表現為網頁能開啟但上傳、影片或部分介面卡住；設定過小則會增加額外負擔。不要一看到連線變慢就任意降低 MTU。應先確認問題只在 TUN 下出現，再逐步調整比較，並在每次調整後重新建立連線。恢復預設值也應作為對照組。

略過區域網路與保留位址

TUN 接管後，應明確繞過私有位址、回環位址及目前區域網路需要直連的網段。印表機、網路儲存裝置、路由器管理頁面與本機開發服務都依賴這一點。只設定「略過區域網路」開關仍不足時，應查看實際位址範圍，並用精確 IP 或網段規則補充。企業網路中還可能存在非典型內部位址，需要依實際路由表處理。

如果本機裝置透過主機名稱存取，還要同步設定內部 DNS。只讓目標 IP 直連，但把網域交給公共解析伺服器，仍可能得到不存在或錯誤的位址。區域網路問題應分成「名稱能否解析」和「位址能否直連」兩步驗證。先用 IP 測試連通，再測試網域，就能判斷問題位於 DNS 還是路由。

依應用程式控制與 UDP

行動端常用分應用程式代理，控制哪些程式進入連線。「包含」模式適合只讓少量應用程式進入，「排除」模式適合讓大多數應用程式進入但保留本地服務直連。應用程式更新或更換套件名稱後，舊選擇可能失效，應定期檢查清單。桌面端的程序路由依賴核心與權限，即使程序名稱相同也可能對應不同路徑，規則應在實際記錄中驗證。

UDP 流量包括部分 DNS、即時通訊與新型傳輸協定。伺服器與協定鏈不支援相應的 UDP 行為時，TUN 能接收封包也無法保證目標可達。排查時先判斷是所有 UDP 都失敗，還是只有某個應用程式或目標失敗；再檢查出站能力、路由與 MTU。不要把 UDP 故障簡單歸因於虛擬網卡。

關閉後的網路復原

正常結束客戶端時，自動路由與 DNS 應隨之恢復。若異常結束後網路仍無法使用，先確認 TUN 介面是否仍存在，再檢查預設路由與系統 DNS 是否保留暫時值。重新開啟客戶端後執行一次正常啟動與正常停止，有時可以觸發清理流程。仍未恢復時，使用系統網路重設功能，並重新連線目前網路。

TUN 的穩定標準不是「接管所有流量」，而是接管範圍符合預期、區域網路界線清楚、DNS 不繞路，且關閉後系統能夠復原。對只使用瀏覽器及支援系統代理應用程式的情境，一般代理模式更簡單；只有確實需要擴大入口覆蓋時，TUN 才是合適工具。

CHAPTER 07 / FAKEDNS

FakeDNS：虛擬 IP 對映、適用條件與相容性

FakeDNS 不會直接向應用程式回傳網域的真實位址，而是從保留位址池分配一個虛擬 IP，並在內部儲存「虛擬 IP—原始網域」的對映。應用程式連線至這個虛擬位址時，核心會依對映還原網域，再執行網域路由與實際解析。它的主要價值是在 TUN 情境中保留網域資訊，避免應用程式先取得真實 IP 後，核心只能依位址判斷。

對映流程如何運作

應用程式發起 DNS 查詢後，請求會由 TUN 或 DNS 劫持規則送入核心。FakeDNS 為網域分配虛擬位址並回傳，應用程式將此位址當作目標建立連線；核心識別位址屬於 FakeDNS 位址池後，從對映表取回網域，再依網域規則選擇出站，必要時透過目標出站解析真實位址。整個流程要求 DNS 請求與後續連線都經過同一個可辨識對映的核心執行個體。

如果 DNS 請求進入 FakeDNS，但應用程式連線繞過 TUN，系統會嘗試存取一個公網不存在的虛擬位址；反過來，如果連線進入 TUN，而 DNS 由應用程式自己的解析器直接完成，核心可能只看到真實 IP，FakeDNS 就不會參與。啟用前必須先確保 DNS 接管與流量接管形成閉環。

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": ["geosite:geolocation-!cn"]
      },
      "223.5.5.5"
    ],
    "fakedns": [
      {
        "ipPool": "198.18.0.0/15",
        "poolSize": 65535
      }
    ]
  }
}

範例使用保留的基準測試位址範圍作為虛擬池，並只為指定網域集合選擇 FakeDNS。實際欄位與放置位置取決於核心設定格式和客戶端產生方式，應優先使用客戶端提供的開關與範本。位址池不得與本機區域網路、企業網路、其他虛擬介面或既有路由重疊。位址池大小也不是越大越好，只需涵蓋正常使用期間的活躍對映。

適合啟用的情境

當 TUN 已穩定運作、網域規則很多，且應用程式經常在本地先解析網域時，FakeDNS 能協助核心保留網域語意。它也適合需要減少真實解析前置步驟的情境：路由先依網域選擇出站，再由目標路徑完成實際解析。如此可以避免本地解析結果過早決定目標位址。

如果主要使用支援遠端解析的系統代理，且記錄中已能看到完整網域，FakeDNS 帶來的效益通常有限。簡單網路不必為了參數更多而啟用。FakeDNS 是解決網域資訊遺失的工具，不是通用加速開關，也不會改善伺服器本身的連線品質。

不適合直接啟用的情境

依賴顯示真實 IP、位址白名單、區域網路探索或直接比較 DNS 結果的應用程式，可能無法接受虛擬位址。部分安全軟體會將連往保留位址範圍視為異常；某些遊戲、裝置控制程式或企業客戶端也可能繞過系統 DNS，導致對映鏈不完整。內部網域通常應繼續交給區域網路 DNS，並直接連線至真實位址，而不是進入 FakeDNS。

需要透過 IP 規則精確控制的目標也應謹慎處理。如果路由在還原網域之前就把虛擬 IP 當作一般位址處理，可能命中錯誤規則。設定中應確保 FakeDNS 位址識別在正確階段發生，並避免為虛擬位址池編寫一般直連規則。關於機制、適用界線與應用程式相容性問題，可繼續閱讀FakeDNS 原理詳解。

快取與對映失效

應用程式可能快取虛擬 IP，而核心重新啟動後對映表已被清空。此時應用程式繼續連線至舊虛擬位址，核心無法還原原始網域，表現為重新啟動客戶端後短時間內部分網站失敗。關閉舊連線、清除應用程式 DNS 快取或重新啟動應用程式通常可以恢復。頻繁重新啟動核心會增加這種現象，因此除錯時每次變更後都要重新發起完整查詢。

位址池耗盡或對映數量異常增加時，應檢查是否有程式持續產生隨機子網域查詢。盲目擴大位址池只能延後問題。先確認請求來源，必要時讓這類網域繞過 FakeDNS，或限制應用程式的接管範圍。啟用完成後，應分別驗證一般網域、內部網域、僅依 IP 存取的目標，以及重新啟動後的快取復原。只有這四類行為都能解釋，FakeDNS 才算穩定接入。

CHAPTER 08 / OUTBOUNDS

自訂出站、代理鏈與完整排錯流程

自訂出站用於將不同目標送往不同連線路徑，或在直連、代理、阻斷之外增加 DNS 專用、前置代理與特定伺服器出站。它是前面訂閱、路由與 DNS 結構的匯合點：伺服器參數決定出站能否連線，路由標籤決定哪些請求進入，DNS 路徑決定目標如何解析。自訂出站越多，就越需要清楚記錄標籤與依賴關係。

標籤是設定之間的介面

每個出站都應使用唯一、穩定且只表達用途的標籤。不要把伺服器位址、地區與日期全部寫入標籤，因為訂閱更新後這些資訊容易變動。可以使用 proxy-main、proxy-backup、direct、block、dns-out 等名稱。路由規則、DNS 伺服器與代理鏈只透過標籤引用，顯示名稱則可以更詳細。

刪除或重新命名出站前，應搜尋所有引用位置。設定能夠解析不代表引用一定有效，部分錯誤只會在對應規則首次命中時出現。最穩妥的做法是先新增出站並單獨測試，再將一條精確網域規則切換過去，驗證成功後逐步擴大範圍，最後刪除舊出站。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    },
    {
      "tag": "dns-out",
      "protocol": "dns",
      "settings": {
        "address": "1.1.1.1",
        "port": 53,
        "network": "tcp"
      }
    }
  ]
}

範例展示直連、阻斷與 DNS 出站的基本標籤關係。代理伺服器出站通常由訂閱與客戶端產生，不建議把驗證參數重複貼到多個本機設定中。若客戶端支援將目前伺服器作為預設代理出站，應保留這種動態引用，讓切換伺服器時不必改寫路由。只有需要固定某條線路時，才建立獨立出站。

代理鏈的方向與依賴

代理鏈表示一個出站透過另一個出站建立連線。例如目標流量先進入業務出站，該出站再指定前置出站作為傳輸路徑。設定時必須分清「誰透過誰連線」，避免把方向寫反。鏈中的每一層都會增加建立連線的步驟與排錯範圍，只有明確需要前置路徑時才使用。

代理鏈最常見的故障是循環依賴：出站 A 透過 B，B 又透過 A；或解析 A 的伺服器位址時需要經過 A 本身。應讓鏈條最終落到一個可直接建立連線的出口，並盡量使用可直接解析或固定可達的伺服器位址。驗證時先測試最外層的基礎出站，再逐層加入上層，不要一次啟用整條鏈。

依入站、連接埠與程序選擇出站

除了網域與 IP，也可以根據入站標籤、目標連接埠、網路類型或程序進行分流。入站標籤適合將不同本機監聽連接埠綁定至不同出站，例如一個連接埠使用主要線路，另一個連接埠用於測試備用線路。連接埠規則適合明確的協定服務，但現代應用程式常在同一連接埠承載多種業務，不能只憑連接埠判斷內容。程序規則適合桌面端依應用程式控制，實際支援與權限取決於核心和系統。

規則組合應避免範圍重疊。若某個程序規則與網域規則同時存在，前後順序會決定結果。建議先寫最明確的入站或程序規則，再寫目標網域規則，最後放通用集合。每條規則旁記錄用途，比單純依賴複雜名稱更容易維護。若客戶端支援備註，應寫明命中條件與目標出站。

一套可重複的排錯流程

第一步恢復最小設定：一台已驗證的伺服器、一個代理出站及一個直連出站，不啟用複雜路由、TUN 與 FakeDNS。確認基礎連線後，第二步載入 DNS 設定並驗證網域解析；第三步加入一條精確路由，觀察命中結果；第四步啟用 TUN，驗證系統流量與區域網路；第五步才加入 FakeDNS 或代理鏈。每一步都保留記錄與結果。

如果問題只在訂閱更新後出現，先比較使用中的伺服器與協定參數，不要先修改路由。如果只有某類網域失敗，檢查 DNS 分流與 GeoSite 資料。如果只有不支援系統代理的應用程式失敗，檢查 TUN 入口。如果啟用 FakeDNS 後大範圍失敗，恢復真實 DNS 並檢查對映閉環。如果自訂出站失敗，先用精確規則測試該出站，不要讓所有流量切換過去。

記錄應包含操作時間、修改項目、目前模式與第一個錯誤。無需儲存大量重複的連線關閉訊息。比較兩次設定時，只比較實際變更的部分；同時調整 DNS、路由與出站，會讓差異失去價值。遇到術語或介面含義不清時，可先查看設定與排障文章；需要重新安裝客戶端時，前往下載頁選擇 Windows、macOS、Android 或 Linux 對應版本。

長期維護的最小清單

定期維護不需要每天重做設定。訂閱層檢查來源是否仍有效、篩選是否誤傷；路由層檢查 GeoIP 與 GeoSite 資料及標籤引用；DNS 層檢查解析伺服器可達性與應用程式旁路；TUN 層檢查虛擬介面、區域網路繞過與關閉後的復原；FakeDNS 層檢查位址池衝突與應用程式相容性；出站層檢查鏈條是否仍有必要。切換核心時，還要確認設定欄位與協定特性是否相容。Xray 與 V2Fly 的差異可閱讀Xray 核心與 V2Fly 核心差異比較。

一套可維護的進階設定，應能用短句解釋每個元件的職責：訂閱提供伺服器，分組管理來源，篩選減少雜訊，DNS 提供位址，路由選擇方向，TUN 擴大入口，FakeDNS 保留網域，自訂出站建立目標路徑。任何無法解釋用途、無法單獨驗證，或刪除後沒有影響的規則，都值得重新評估。設定越接近這種清晰結構，更新客戶端、切換伺服器與遷移裝置時就越不容易失控。