V2Ray 進階設定
系統化查閱指南

設定分層與修改順序

進階設定最常見的問題，不是某個參數寫錯，而是將不同層級的職責混在一起。例如，伺服器篩選只決定用戶端清單中哪些項目方便選擇，並不會直接決定瀏覽器流量是否經過代理；路由規則負責將已進入核心的連線分配至不同出站，卻無法接管未遵循系統代理的應用程式；TUN 能擴大接管範圍，但不會自動修正錯誤的 DNS 伺服器或無效節點。將設定拆成輸入、選擇、接管、解析、判定與出站六層，可以大幅縮短排查路徑。

從輸入到出站的完整鏈路

輸入層包括訂閱網址、單一分享連結與手動設定。用戶端更新訂閱後，會將遠端內容轉換為本機伺服器項目。選擇層負責目前使用中的伺服器、伺服器分組與篩選結果。接管層決定哪些應用程式流量會進入核心：系統代理通常涵蓋遵循系統代理設定的程式，TUN 則透過虛擬網路介面接收更廣泛的 IP 流量。解析層將網域名稱轉換為位址，路由層依據網域、位址、連接埠、協定等條件比對規則，最後由代理、直連、阻斷或自訂出站完成連線。

這條鏈路具有明確的先後關係。瀏覽器未使用系統代理時，調整路由規則不會改變結果；DNS 已在作業系統端預先解析時，只依賴網域規則可能無法得到預期比對；路由命中代理出站後，如果目前伺服器不可用，連線仍會失敗。因此，每次修改都應回答兩個問題：變更發生在哪一層，以及用來證明它生效的觀察點是什麼。只有將驗證點與變更層對應起來，才能避免同時修改多個選項後無法判斷真正原因。

建立可回復的設定基線

開始進階調整前，應先保留一份能正常連線的基線。基線不必複雜：保留一台已驗證的伺服器、預設路由、明確的 DNS 設定，以及目前使用的系統代理或 TUN 狀態。接著一次只修改一個主題，例如先完成訂閱分組，確認伺服器選擇不受影響，再進入路由設定。若用戶端提供設定備份或匯出功能，可在關鍵階段儲存快照；也可以記錄介面選項、規則順序與測試結果，避免只能靠記憶復原。

驗證基線時不要只測試單一網頁。至少應包含一個預期直連的網域、一個預期代理的網域、一個純 IP 連線情境，以及一次 DNS 查詢。測試結果需要能區分「沒有進入用戶端」、「進入後路由錯誤」、「DNS 回傳異常」與「選取的伺服器不可用」。在 Windows 上可搭配工作管理員、系統代理設定與用戶端記錄觀察；macOS 與 Linux 可查看目前路由、代理設定與解析狀態；Android 上的 v2rayNG 或 v2flyNG 則以連線記錄、虛擬網路授權狀態與目標應用程式表現為主要依據。

用戶端介面名稱可能隨版本與平台略有差異，但核心關係不會改變。v2rayN 是桌面平台的首選管理用戶端，適合集中維護訂閱、路由與出站；Android 上的 v2rayNG 使用 Xray 核心體系，v2flyNG 則以 V2Fly 核心為主要選擇。跨平台移轉時應移轉「設定意圖」，而不是假設選單位置與所有欄位完全相同。先確認目標平台支援對應能力，再逐層重建設定，通常比直接複製一份龐大設定更容易找出相容性邊界。

訂閱分組與伺服器篩選

訂閱項目變多後，真正影響使用效率的不是清單長度本身，而是能否穩定找到符合目前任務的伺服器。分組負責建立伺服器的長期歸屬，篩選則負責在某次選擇中縮小候選範圍。兩者應分開設計：分組表達來源、用途或維護邊界，篩選表達名稱比對條件。把篩選結果當成永久分類，容易在訂閱改名後失效；把所有項目塞進單一分組，則會讓更新、測速與故障定位互相干擾。

依來源還是依用途分組

來源分組最容易維護：每個訂閱網址對應一個分組，更新失敗時可以直接定位來源，也方便撤銷某個訂閱而不影響其他項目。用途分組更適合已建立穩定命名規則的環境，例如將日常瀏覽、開發測試與臨時備用分開。實際設定通常採用兩層思路：底層保留來源邊界，上層透過篩選或收藏建立用途檢視。這樣既能追蹤項目來源，也能減少日常選擇時的資訊雜訊。

分組名稱應穩定、簡短且容易辨認，不要把更新日期或暫時狀態寫進長期名稱。更新日期屬於記錄資訊，線路狀態則應透過實際連線測試判斷。若多個訂閱中出現同名伺服器，可以在匯入階段加入來源前綴，或讓分組負責區分來源，避免在伺服器名稱中堆疊過多標籤。名稱越複雜，正規表示式篩選越容易誤判，後續訂閱方調整命名時也更難相容。

建立易維護的篩選表示式

伺服器篩選通常會針對備註名稱執行文字或正規表示式比對。應先從最小條件開始，例如只比對一個穩定關鍵字，再逐步加入同義寫法。正向篩選適合從大量項目中選出特定地區、用途或線路標示；反向篩選適合排除測試項目、過期標示或明確不適用的架構。篩選表示式不應依賴「第幾個字元」這類脆弱位置，而應依賴相對穩定的完整詞段與分隔符號。

常用篩選思路：

包含任一關鍵字：
(辦公|開發|備用)

比對名稱開頭的來源標記：
^(來源甲|來源乙)[-_ ]

排除帶有臨時或過期標記的項目：
^(?!.*(臨時|過期)).*$

同時要求兩個條件：
^(?=.*開發)(?=.*TCP).*$

正規表示式中的括號用於分組，直線表示多個候選，點號與星號組合表示任意長度的文字，前瞻可用來要求或排除某個條件。輸入表示式前，請確認用戶端對應輸入框是否啟用正規表示式模式；如果只是一般文字搜尋，特殊符號會被視為字面字元。篩選後也應人工抽查清單前後與邊界名稱，確認沒有錯誤納入同音詞、縮寫或嵌套詞。

不要用篩選結果取代連線品質判斷。名稱只能表達訂閱發布者提供的標籤，不能證明即時可用性，也不代表目前的網路路徑。完成篩選後，應在候選集合中執行實際連線測試，而不是只看基本連通結果。連線測試需要存取實際目標並觀察握手結果；若測試全部失敗，應先取消篩選確認原始清單是否正常，以區分「表示式沒有比對到項目」和「比對到的項目本身無法連線」。

更新後維持選擇穩定

訂閱更新可能新增、刪除或重新命名項目。目前選取的伺服器若被刪除，用戶端可能回退到其他項目，也可能保留一個無法繼續使用的舊參照。更新後應檢查目前選擇是否仍屬於目標分組，並重新執行一次實際連線。對於承擔固定任務的設定，不建議只依賴清單序號，因為排序變化會讓原本的第一項變成不同伺服器。更穩妥的做法是使用唯一且穩定的命名規則，或在更新後人工確認目前使用中的項目。

如果篩選條件突然得到空清單，先查看未篩選的原始分組。原始分組為空，問題在訂閱更新或解析；原始分組有內容但篩選為空，問題在名稱變化或表示式；篩選有結果但無法連線，問題才可能出在節點、網路、DNS 或傳輸設定。將這三個分支分開處理，可以避免因清單為空而誤改路由或 TUN。關於首次選擇與實際連線測試的順序，也可參考v2rayN 首次連線步驟。

當分組規則成熟後，應將它寫成簡短的維護約定：每個來源使用什麼前綴、哪些關鍵字可用於用途篩選、哪些臨時標籤會被排除，以及更新後需要執行哪些檢查。這份約定比複雜表示式本身更重要，因為它讓後續新增訂閱仍能納入同一套結構。若規則只有建立者看得懂，隨著名稱變化，分組很快又會退化成雜亂清單。

多訂閱管理與更新邊界

多訂閱管理的目標不是將更多網址集中匯入，而是讓各來源保持可識別、可停用、可復原的邊界。每個訂閱都可能擁有獨立的更新週期、命名方式與伺服器欄位。如果所有來源更新後直接混在同一個沒有標識的清單中，一旦出現重複項目、批次失效或命名衝突，就很難判斷應該修復哪一個輸入。合理的多訂閱結構應先確保來源隔離，再考慮統一篩選與日常使用便利性。

為每個來源建立獨立生命週期

新增訂閱時，先記錄用途、來源標識與預期更新方式，再執行首次更新。更新成功只代表用戶端取得並解析了內容，還需要抽查伺服器數量變化、關鍵欄位，以及至少一次實際連線。某個來源暫時異常時，應優先停用該來源或暫停自動更新，而不是立即刪除。停用能保留既有設定與排查線索；確認不再使用後再移除，可以降低誤操作造成的復原成本。

自動更新間隔不宜只追求頻繁。更新過密會增加不必要的請求，也可能讓正在使用的清單在工作期間發生變化。對穩定來源，可以安排在容易觀察的固定時段更新；對臨時來源，則可保留手動更新。若用戶端支援啟動時更新，應考慮啟動頻率與網路環境：裝置每次喚醒都更新可能造成狀態反覆，而長期不重新啟動又會錯過變化。關鍵不在於統一間隔，而是知道更新何時發生，以及更新後是否執行驗證。

處理重複項目與名稱衝突

不同訂閱可能包含相同伺服器，也可能只是名稱相同但實際參數不同。不能只憑備註名稱直接判定重複。判斷時應比較位址、連接埠、協定、傳輸、安全設定與伺服器識別等關鍵欄位。兩個項目名稱一致但傳輸參數不同，可能代表不同入口；兩個名稱不同但連線欄位完全一致，則可能只是不同來源的重複發布。保留重複項目會增加選擇雜訊，但貿然合併也可能遺失更新歸屬。

穩妥的做法是保留來源分組，並在日常用途檢視中篩選或收藏一個主要項目。即使主要來源更新失敗，仍能回到其他來源檢查同類設定。若需要重新命名，盡量使用用戶端的本機備註功能，不要直接修改訂閱內部的關鍵欄位。訂閱下次更新時，本機名稱是否保留取決於用戶端的合併策略，因此重新命名前應確認更新行為，避免將重要分類完全建立在可能被覆寫的手動名稱上。

更新失敗的分層判斷

訂閱更新失敗時，先區分取得失敗與解析失敗。取得失敗通常表現為無法建立連線、回傳狀態異常或逾時，此時要檢查訂閱網址是否完整、目前網路是否能夠存取，以及系統代理是否形成迴圈。解析失敗則表示已取得內容，但格式不符合用戶端預期，可能是回傳了網頁提示、編碼內容發生變化，或訂閱類型選擇不相符。尚未查看回傳類型前，不要反覆重新整理，因為重複請求不會修正格式問題。

如果訂閱網址只有在開啟代理時才能存取，要明確確認更新請求經過哪個出站。某些設定會讓用戶端更新自身訂閱時經過目前代理；如果目前使用的伺服器已失效，就會形成「需要更新才能取得新項目，但更新又依賴舊項目」的閉環。處理方式是暫時選擇可用來源、調整訂閱更新的代理策略，或在可直連的環境下完成更新。修改後應恢復原有策略並記錄原因，避免下次更新再次遇到相同問題。

訂閱格式之間的差異也會影響多來源合併。Base64 清單、單一分享連結與原生 JSON 設定承載的資訊範圍不同，轉換時可能遺失路由、DNS 或自訂出站等全域設定。伺服器訂閱應主要負責分發伺服器項目，用戶端的全域路由與 DNS 則由本機設定維護。不要期待單一分享連結完整表達整套用戶端策略。關於格式邊界與轉換欄位，可閱讀V2Ray 訂閱格式解析。

成熟的多訂閱方案應能回答三個問題：某個伺服器來自哪裡、某個來源失敗時會影響哪些用途，以及復原後如何驗證。建議定期清理長期停用的來源，但清理前先匯出必要設定，並確認沒有路由規則或收藏項目依賴其名稱。跨裝置移轉時先移轉來源與分組，再移轉用途篩選；等基礎項目穩定後，最後復原路由與自訂出站。這個順序能清楚分離輸入問題與進階策略問題。

路由規則實戰與命中順序

路由規則的作用，是為已進入核心的連線選擇出站。常見條件包括網域、目標 IP、連接埠、網路類型、協定與程序資訊；常見結果則是代理、直連、阻斷或自訂出站。規則系統通常依既定順序比對，連線命中一條可執行規則後便不再繼續向下。因此，路由設定的核心不是規則數量，而是條件是否互斥、順序是否清楚，以及預設流量最終會流向哪裡。

先定義結果，再撰寫條件

撰寫規則前應先列出預期結果，例如：區域網路與本機位址直連；明確的工作網域經指定代理；特定更新服務直連；其餘流量使用預設代理。結果明確後，再為每一類流量選擇最穩定的判斷條件。網域規則便於閱讀，但依賴核心能取得網域資訊；IP 規則適合位址範圍穩定的目標；連接埠規則涵蓋範圍較廣，通常只能作為輔助；程序規則具有平台差異，不適合直接複製到所有裝置。

寬泛條件應放在具體條件之後。若第一條規則將所有 TCP 與 UDP 都送往代理，後續的區域網路直連規則便沒有機會生效。相反地，如果先放置過寬的直連網域後綴，也可能讓原本應走代理的子網域提前直連。排查規則順序時，可以暫時將目標網域單獨置於最前，並指定容易辨認的出站；確認命中後，再逐步恢復其他規則，觀察是哪一條造成覆蓋。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "full:docs.example.com",
          "domain:example.net"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

範例中的 full: 表示完整網域比對，domain: 通常包含該網域及其子網域，geoip:private 用於識別私有位址範圍。最後一條網路規則負責預設出口，因此必須位於具體規則之後。範例網域僅用於說明結構，實際設定應替換為需要控制的目標。若用戶端使用圖形化路由編輯器，應將相同條件拆入對應欄位，而不是把整段 JSON 貼到不接受完整設定的輸入框。

理解網域策略與解析時機

domainStrategy 決定網域規則未命中時是否繼續解析 IP，並嘗試比對 IP 規則。AsIs 傾向保留原始網域進行比對，不主動為了路由而解析；IPIfNonMatch 會在網域規則未命中時解析，並繼續檢查 IP；某些核心還提供更積極的解析策略。策略越積極，IP 規則覆蓋越完整，但也會增加 DNS 查詢，讓解析路徑更直接地影響路由結果。

如果應用程式已自行解析網域，只將目標 IP 交給核心，網域規則可能無法取得原始名稱。TUN 嗅探、FakeDNS 或應用程式代理方式都會影響網域資訊是否可見。遇到「網域規則看似正確卻未命中」時，應先查看記錄中目標究竟以網域還是 IP 出現，再決定調整解析策略、啟用適當的嗅探，或補充 IP 條件。盲目加入更多網域後綴，無法解決核心未取得網域的問題。

建立最小規則集並逐步擴充

建議從三段式規則開始：私有位址直連、少量明確目標按需分流，其餘流量進入預設出站。確認穩定後，再加入更新服務、開發環境或特定程序規則。每新增一組規則，都要準備正向與反向測試：一個應該命中的目標，以及一個不應命中的相似目標。例如設定 domain:example.net 後，應同時測試根網域、一個子網域，以及名稱中只有相似字串的其他網域。

路由排錯應優先查看連線記錄中的目標、命中規則與出站標籤。如果記錄只顯示連線失敗，沒有規則資訊，可暫時提高用戶端記錄層級，完成測試後再恢復，避免長期產生大量記錄。若目標命中正確出站但仍失敗，問題已離開路由層，應轉向伺服器、DNS 或傳輸連線；若目標沒有出現在任何記錄中，則先檢查系統代理、TUN 或應用程式自身的代理設定。

系統代理、全域模式與按規則分流控制的是不同面向。系統代理決定部分應用程式是否將請求交給用戶端，路由模式則決定核心收到連線後如何選擇出口。需要重新確認兩者關係時，可參考V2Ray 系統代理如何選擇。當規則表現隨網路變化而波動時，還要檢查 DNS 回傳位址是否改變，因為依賴 IP 範圍的規則可能因解析結果變化而命中不同出口。

DNS 設定最佳化與解析路徑

DNS 設定的關鍵，不是簡單替換一個伺服器位址，而是確認查詢由誰發起、經過哪個出站，以及回傳結果供哪一層使用。作業系統、瀏覽器、用戶端核心與遠端伺服器都可能參與解析。若同一網域在不同層重複解析，取得的位址可能不同，路由判斷也會隨之變化。最佳化 DNS 前應先畫出查詢路徑，釐清本機解析、核心解析與遠端解析之間的邊界。

區分系統 DNS 與核心 DNS

系統 DNS 服務於未被用戶端接管的一般程式，也可能在應用程式進入代理前完成解析。核心 DNS 則供路由、TUN 或核心自身連線使用。在系統代理模式下，支援網域代理的應用程式可能將網域直接交給代理核心，也可能先在本機解析；實際行為取決於應用程式與代理類型。TUN 模式下，用戶端通常有更多機會截獲 DNS 流量，但仍需正確設定 DNS 劫持、路由與排除項目。

診斷時不要只修改作業系統 DNS 後觀察網頁。應分別檢查系統查詢與用戶端記錄。在 Windows 可使用 ipconfig /flushdns 清除系統快取，再執行 nslookup 或 PowerShell 查詢；macOS 可用 scutil --dns 查看解析器順序；Linux 可依系統環境使用 resolvectl status 檢查目前上游。清除快取只用於排除舊結果，不應視為長期解決方案。

Windows:
ipconfig /flushdns
nslookup docs.example.com

macOS:
scutil --dns
dscacheutil -q host -a name docs.example.com

Linux:
resolvectl status
resolvectl query docs.example.com

依網域選擇解析伺服器

複雜環境可以為不同網域選擇不同 DNS 伺服器。例如，區域網路內部網域需要交給本地解析器，公共網域交給一般上游，特定目標則透過代理出站查詢。DNS 分流的價值在於維持內部名稱可解析，並讓外部查詢路徑與路由意圖一致。設定時應先放具體網域規則，再放預設伺服器，避免預設項目提前覆蓋。區域網路解析器也應設定明確的位址範圍，防止它被錯誤地透過代理存取。

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "domain:internal"
        ],
        "skipFallback": true
      },
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

hosts 適合少量固定對映，不適合維護經常變動的大型網域集合。帶有 domains 的伺服器只處理符合範圍的查詢，skipFallback 用於控制失敗後是否進入其他候選。queryStrategy 決定查詢位址族群的傾向，應配合目前網路是否具備穩定的 IPv4 或 IPv6 連線來選擇。若網路沒有可用的對應位址族群，卻強制只查詢該類型，可能呈現網域可見但連線始終逾時。

快取、回退與循環查詢

DNS 快取可以減少重複查詢，但會讓設定變更後的舊結果繼續存在。調整解析伺服器、網域規則或 FakeDNS 後，也應同時考慮作業系統快取、瀏覽器快取與核心快取。關閉再開啟代理不一定會清除所有層級。測試時可以使用此前未查詢過的子網域，或依平台清理相關快取。若清理後短暫恢復正常，隨後又出現異常，應檢查是否存在多個解析器輪流回傳不同結果。

回退機制需要清楚的邊界。預設伺服器查詢失敗後切換備用伺服器可以提高可用性，但如果不同伺服器承擔不同的分流意圖，任意回退可能把內部網域送往不合適的上游，或回傳與路由不一致的位址。內部網域通常應禁止向公共上游回退；一般公共網域則可以設定有序候選。判斷是否發生回退，不能只看最終位址，也應查看記錄中的實際查詢伺服器。

循環查詢通常出現在 DNS 請求被路由到代理，而代理伺服器的網域本身又需要同一套代理 DNS 才能解析。解決思路是為伺服器位址建立啟動鏈路：優先使用已知 IP、為伺服器網域單獨指定可直接存取的解析器，或讓對應 DNS 請求經過不依賴目前代理的出站。修改時要保留最小的直連解析能力，否則用戶端可能在啟動階段就無法取得代理伺服器位址。

當連線速度變慢或部分網域偶爾失敗時，DNS 只是可能原因之一。應同時檢查伺服器狀態、網路線路、代理模式與本機資源使用量，避免把所有波動都歸因於解析。可依照V2Ray 速度慢的分層排查中的順序，先確認故障層，再決定是否調整 DNS。設定最佳化的標準是路徑可解釋、結果可重現，而不是堆疊越多上游伺服器越好。

TUN 模式的接管範圍與排除項目

TUN 模式透過虛擬網路介面接收系統流量，適合不遵循系統代理、使用獨立網路堆疊，或需要處理更多 UDP 流量的程式。它改變的是流量進入用戶端的方式，不會自動取代訂閱選擇、DNS 與路由設定。啟用 TUN 後，原本未出現在記錄中的應用程式可能開始由核心處理，錯誤路由與 DNS 問題也會因此更加明顯。使用前應先確保一般代理模式能穩定連線，再擴大接管範圍。

系統代理與 TUN 的選擇

日常瀏覽及遵循系統代理設定的桌面應用程式，通常先使用系統代理，設定簡單且影響範圍容易控制。遇到應用程式忽略系統代理、需要接管特定 UDP 連線，或希望統一應用層差異時，再考慮 TUN。不要只因某個網站無法開啟就立即切換 TUN；如果原因是伺服器不可用或路由錯誤，切換接管方式只會增加新的變數。先檢查目標請求是否已出現在用戶端記錄中，若已出現，問題通常不在接管層。

TUN 需要建立虛擬介面並調整系統路由，在 Windows、macOS 與 Linux 上可能涉及不同權限與網路元件。v2rayN 的介面會依平台提供相應入口，具體權限提示應依系統要求完成。Android 上的 v2rayNG 與 v2flyNG 透過系統提供的虛擬網路授權接管流量，執行邏輯與桌面設定入口不同。跨平台參考時應比較接管目標、DNS 流向與排除規則，不要照搬裝置名稱或介面編號。

路由表、MTU 與網路迴圈

啟用 TUN 後，用戶端會新增或調整系統路由，使目標流量進入虛擬介面。若預設路由、實體網卡路由與虛擬介面優先順序衝突，可能出現連線繞回、區域網路無法連線，或用戶端本身的伺服器流量再次進入 TUN。排查時先查看系統路由表，確認代理伺服器位址、區域網路位址與 DNS 上游的路徑。代理伺服器連線必須從真實網路介面發出，不能再次被同一個 TUN 接管。

MTU 決定單一網路封包在介面上的最大大小。設定過大可能在某些路徑產生分片或丟包，表現為小型請求正常、大型頁面或檔案傳輸停滯；設定過小則會增加封包數量與額外開銷。出現握手正常但持續傳輸異常時，可以將 MTU 列為排查項目，但沒有證據時不應任意修改。先比較不同網路環境、不同目標與不同協定的表現，再小幅調整並記錄結果。

網路迴圈也可能來自應用程式自身代理與 TUN 同時生效。例如某個程式手動設定本機代理連接埠，其連線先進入本機代理，代理出站又被 TUN 捕獲，若排除規則不完整便會重複進入。處理時應選定單一入口：要麼讓應用程式使用本機代理並排除用戶端程序，要麼取消應用程式手動代理，讓 TUN 直接接管。用戶端核心程序、更新請求與必要的本機監聽位址通常需要明確排除。

排除區域網路與關鍵程序

區域網路列印、檔案共用、路由器管理與本機開發服務通常應保持直連。路由層可以使用私有位址規則指定直連，TUN 層也可能提供繞過位址或應用程式清單。兩層規則應保持一致：如果 TUN 在接管前就排除某段位址，核心路由不會看到這些連線；如果 TUN 接管後由核心直連，則可以在記錄中觀察比對結果。採用哪種方式取決於是否需要記錄與控制這類流量。

程序排除適合解決用戶端自身迴圈，或明確不希望接管的應用程式，但程序名稱可能隨啟動器、子程序與平台而變化。只排除主程式不一定能涵蓋它建立的網路服務。更穩定的方式是先從位址與路由邊界處理，再將程序排除作為補充。每次更新應用程式後，若接管行為發生變化，應重新檢查實際發起網路連線的程序，而不是預設舊名稱仍然有效。

TUN 故障可依「介面是否建立、路由是否寫入、DNS 是否進入預期路徑、目標是否命中規則、出站是否可連線」的順序排查。關閉 TUN 後立即恢復，表示問題集中在虛擬介面、路由或 DNS 接管；關閉後仍然異常，則要檢查系統代理是否殘留、用戶端程序是否仍在執行，以及作業系統路由是否恢復。必要時先退出用戶端，再重新連線實體網路，以乾淨狀態驗證基礎網路。

FakeDNS對映原理與適用邊界

FakeDNS 的核心做法是：用戶端收到網域查詢後，不會立即將真實目標位址回傳給應用程式，而是從專用位址池分配一個暫時對映位址。應用程式接著連線到這個位址，核心依據對映表還原原始網域，再執行網域路由與遠端解析。如此一來，即使應用程式只發起 IP 連線，核心仍能保留網域資訊。它主要解決 TUN 情境下網域遺失與本機提前解析的問題，不是提升所有連線速度的通用開關。

一次查詢與連線如何完成

應用程式首先向 DNS 請求 service.example.com，FakeDNS 從位址池回傳一個對映位址，同時記錄「對映位址對應原始網域」。當應用程式向該位址發起連線時，TUN 將流量交給核心，核心查表還原網域，再用網域規則選擇出站。若代理協定與伺服器支援遠端解析，真實 DNS 查詢可以在後續鏈路中完成。對映表有容量與生命週期，過期後舊位址無法無限期維持相同關係。

這個過程要求 DNS 查詢與後續連線都進入同一套核心。如果 DNS 被瀏覽器獨立的加密解析繞過，而連線又進入 TUN，核心可能只能看到真實 IP，FakeDNS 便沒有參與；反過來，如果 DNS 回傳對映位址，但連線繞過 TUN 直接發往實體網路，該位址不會在公網上得到正確回應。啟用前必須確保查詢與連線路徑一致，否則故障表現往往是網域解析取得位址，但任何連線都立即失敗。

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

198.18.0.0/15 是常用於基準測試與對映用途的保留位址範圍，不應與實際區域網路位址重疊。poolSize 控制可分配的對映數量，實際支援方式取決於所使用的核心與用戶端產生的設定。圖形用戶端若已提供 FakeDNS 選項，應優先透過介面設定，以便同時產生所需的 DNS、嗅探與路由關係；直接插入局部 JSON 時，要確認最終設定不會出現重複欄位或互相覆蓋。

位址池衝突與旁路連線

選擇位址池時，應檢查企業網路、虛擬機器、容器與其他網路軟體是否已使用相同範圍。位址衝突會讓系統將對映流量送到錯誤介面，或讓真實內部位址被當成 FakeDNS 結果。啟用前可以查看路由表，確認該網段沒有更具體的現有路由。若衝突無法避免，應依核心支援選擇其他保留範圍，並同步更新 TUN 路由與排除設定。

某些應用程式會長時間快取 DNS 位址，甚至在網路切換後仍繼續使用舊對映。用戶端重新啟動後對映表可能已經變更，但應用程式仍持有舊位址，便會出現只有該應用程式失敗的情況。處理時應同時重新啟動目標應用程式或清理其 DNS 快取。頻繁切換 FakeDNS 開關也會讓快取狀態難以判斷，因此測試期間應固定設定，完成一輪查詢、連線與重新啟動驗證後，再決定是否保留。

區域網路網域、印表機探索、裝置廣播與需要真實 IP 的應用程式通常不適合進入 FakeDNS。內部網域可以交給區域網路 DNS，並透過網域規則跳過對映；私有位址應維持直連。對於依賴回傳位址進行存取控制或憑證繫結的程式，也要確認對映不會破壞其工作流程。FakeDNS 更適合需要在 TUN 中恢復公共網域資訊的一般 TCP 與 UDP 連線。

與嗅探及網域路由的配合

嗅探可以從部分應用層協定中恢復目標網域，FakeDNS 則從 DNS 對映關係中恢復網域，兩者並不是簡單的替代關係。嗅探依賴可識別的協定內容，對加密或非標準流量不一定有效；FakeDNS 則依賴查詢與連線都經過核心。實際設定可依流量類型組合使用，但要避免將所有目標強制覆蓋為嗅探結果。記錄中應能區分原始目標、嗅探目標與 FakeDNS 對映目標。

驗證 FakeDNS 時，先查詢一個未快取的網域，確認回傳位址位於對映池；接著立即連線到該網域，檢查記錄是否恢復原始名稱並命中預期網域規則；最後測試一個區域網路網域，確認它仍由內部 DNS 回傳真實位址。三個步驟都通過，才代表對映、還原與排除關係完整。只看到保留位址不能證明設定成功，因為後續連線可能根本未被 TUN 捕獲。

是否啟用 FakeDNS 應由實際問題決定。如果一般 DNS 與網域路由已經穩定，且應用程式能將網域交給用戶端，便沒有必要為了增加設定複雜度而切換。若 TUN 下大量連線只顯示 IP，網域分流無法可靠運作，再評估 FakeDNS。上線前應測試瀏覽器、日常應用程式、區域網路資源與網路切換，並保留關閉後的回退方案。

自訂出站、鏈式連線與整體驗證

出站是路由判定後的執行目標。基礎設定通常包含代理、直連與阻斷三類出站；進階情境還可能需要依介面直連、指定 DNS 出站、鏈式代理，或為某類流量設定獨立連線參數。自訂出站的價值在於清楚表達網路路徑，而不是增加層數。每增加一個出站，都應有唯一標籤、明確呼叫它的路由規則，以及可單獨驗證的目標。

使用穩定且易讀的標籤

出站標籤會被路由規則、DNS 設定與鏈式關係引用。標籤應使用簡短穩定的英文或數字組合，例如 proxy-main、direct-lan、dns-direct，避免使用會隨伺服器名稱變動的描述。修改標籤時要同步檢查所有引用；標籤拼寫不一致通常會在設定載入階段報錯，也可能讓規則回退到預設出站。圖形用戶端自動產生的標籤不應任意覆蓋，請先確認哪些欄位允許使用者擴充。

{
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct-lan",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "protocol": "blackhole",
      "tag": "blocked"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct-lan"
      },
      {
        "type": "field",
        "domain": [
          "domain:blocked.example"
        ],
        "outboundTag": "blocked"
      }
    ]
  }
}

freedom 表示由本機直接建立連線，blackhole 用於拒絕符合條件的流量。阻斷規則應針對明確目標，避免使用過寬條件影響正常服務。範例只展示出站與路由引用關係，不包含伺服器設定。若需要將自訂出站加入 v2rayN，應先確認目前設定範本的合併方式；有些介面會在儲存時重新產生核心設定，手動修改產生的檔案可能在切換伺服器後被覆蓋。

鏈式連線的依賴關係

鏈式連線表示一個代理出站透過另一個出站建立底層連線。它適用於確實需要中間路徑的環境，但每一層都會增加故障點。設定前應分別驗證前置出站與目標出站能獨立運作，再建立鏈式關係。若前置層失敗，後續層的記錄可能只呈現握手逾時；若後續層參數錯誤，前置層看起來仍然連線正常。排查時必須能拆開鏈路，逐段測試。

鏈式設定還要防止環路。出站甲透過出站乙撥號，而出站乙又因路由規則被送回出站甲，就會形成無法完成的迴圈。建立鏈式關係時，應明確伺服器位址的解析與連線使用哪個底層出口，並為必要位址設定不依賴鏈路的啟動規則。DNS 同樣要避免依賴尚未建立的最終出站，否則用戶端啟動時將無法解析任何一層伺服器。

不要將伺服器清單中的多個一般項目誤解為自動鏈式連線。用戶端切換目前伺服器通常只是更換主要代理出站，只有明確設定代理轉送關係，流量才會逐層經過多個出站。鏈路越長不代表連線品質越高，實際效果取決於每段網路路徑、協定開銷與故障復原方式。沒有明確需求時，單一且可驗證的代理出站更容易維護。

依網路介面或位址族群直連

多網卡裝置可能同時連線至有線網路、無線網路、虛擬網路與企業網路。自訂直連出站可用於指定本機位址或介面，使特定流量從預期網路發出。設定前應確認介面名稱與本機位址是否穩定；自動分配的位址變更後，寫死的繫結可能失效。Linux 與 macOS 通常透過系統路由與策略路由控制介面，Windows 則需要同時注意介面躍點與用戶端出站繫結。

位址族群策略也屬於出站邊界。若某個網路只有穩定的 IPv4 連線，自訂出站不應強制使用無法連線的 IPv6，反之亦然。DNS 回傳的位址族群、路由規則與出站連線策略需要一致。出現網域有多個位址但連線只在部分網路失敗時，應分別測試不同位址族群，而不是只更換伺服器。調整後還要確認直連與代理出站是否採用相同策略，避免同一網域在兩個出口呈現不同結果。

儲存、重新載入與最終驗收

完成自訂出站後，應先驗證設定能被核心載入。語法錯誤、未知標籤或不支援的欄位通常會出現在啟動記錄中。載入成功不代表路徑正確，接下來要為每個出站選擇一個明確測試目標：區域網路位址驗證直連，指定網域驗證主要代理，阻斷目標驗證拒絕規則，自訂鏈路則逐層確認。測試時記錄目標、命中規則、出站標籤與結果，建立可重複的驗收表。

圖形用戶端可能在切換伺服器、更新訂閱或變更路由方案時重新產生執行設定。儲存自訂內容後，應執行一次完整流程：重新啟動用戶端、更新一個測試訂閱、切換伺服器、重新載入路由，再確認擴充設定是否仍然存在。若內容被覆蓋，應改用用戶端支援的自訂設定入口、範本或合併功能，而不是反覆編輯暫時的執行檔案。長期設定必須放在用戶端認可的持久化位置。

完整的進階設定應維持「輸入可追蹤、規則可解釋、DNS 可觀察、接管可回退、出站可單獨測試」。連線異常時，先找出請求停在哪一層，再查看該層的記錄與系統狀態。若需要重新建立最小環境，可回到快速入門主線完成基礎連線，再逐章恢復進階能力；用戶端安裝或平台選擇問題可前往安裝套件頁面。這種從最小基線逐層恢復的方法，比同時重建訂閱、路由、DNS 與 TUN 更容易得到明確結論。