V2Ray 進階設定指南

釐清介面設定、核心設定與系統網路狀態

進階設定最常見的問題，不是某個參數完全寫錯，而是同時變更了多個層級。v2rayN 的介面負責訂閱、伺服器選擇、系統代理、TUN 開關與設定產生；Xray 或 V2Fly 核心負責執行入站、出站、DNS 與路由；作業系統則決定預設路由、網路介面、名稱解析順序，以及應用程式是否繞過代理。三個層級會互相影響，但排查時必須分開。看到「用戶端顯示已啟動」只能代表程序進入執行狀態，不能直接推論系統流量已依預期進入核心。

開始修改前，先保留一套已知可用的普通系統代理設定。選擇一台能正常連線的伺服器，使用預設路由模式，關閉 TUN 與 FakeDNS，確認瀏覽器和一個常用桌面程式都能存取目標網站。接著記錄目前的訂閱分組、作用中伺服器、系統代理狀態、DNS 設定與路由模式。這樣做是為了建立對照組：之後啟用某項功能出現異常時，可以立即退回基準，而不是在多個未知變數間反覆試錯。

應按職責理解設定檔。常見結構中的 inbounds 接收來自系統代理或 TUN 的流量，outbounds 定義代理、直連和阻斷等出口，routing.rules 決定流量交給哪個出口，dns 決定網域如何解析。路由規則中的 outboundTag 必須與出站的 tag 完全對應；DNS 伺服器的選擇也可能受到路由規則影響。只複製其中一段而忽略關聯標籤，通常會得到能載入但行為不完整的設定。

用最小變更法確認問題範圍

建議依照「訂閱整理 → 路由 → DNS → TUN → FakeDNS → 自訂出站」的順序推進。訂閱與伺服器篩選只影響可選伺服器集合，風險較低；路由與 DNS 會改變請求去向；TUN 接管範圍更廣；FakeDNS 又依賴 TUN 或透明代理鏈路。順序顛倒時，一旦網域解析或網路介面出問題，很難判斷根因來自伺服器、路由、DNS 還是虛擬網卡。

每次變更後至少進行三類驗證。第一類是網域存取，選擇一個明確的網頁確認 HTTP 與 TLS 連線；第二類是直接 IP 連線，用來區分 DNS 故障與傳輸故障；第三類是應用程式覆蓋範圍，分別檢查遵循系統代理的程式，以及不讀取系統代理的程式。若網域失敗而直接 IP 正常，優先檢查 DNS；若瀏覽器正常而其他程式失敗，優先確認該程式是否進入系統代理或 TUN；若全部失敗，再檢查目前伺服器、出站標籤與核心日誌。

查看日誌也應有明確目標。啟動階段重點尋找設定解析、連接埠占用、權限與虛擬網卡錯誤；連線階段重點查看網域、目標連接埠、命中的出站標籤與上游握手結果；停止階段則確認系統代理與路由是否恢復。日誌層級不宜長期維持在最詳細狀態，因為大量正常連線記錄會掩蓋關鍵錯誤。完成排查後恢復一般層級，保留問題發生前後的一小段上下文即可。

讓訂閱來源與使用目的分開呈現

訂閱分組解決的是「伺服器從哪裡來」，伺服器篩選解決的是「目前需要看到哪些伺服器」。這兩個概念不應混在同一個名稱中。分組名稱適合記錄來源或用途，例如「日常訂閱」「測試訂閱」「備用線路」；伺服器名稱則保留地區、協定或提供者原有資訊。如此一來，更新訂閱後即使伺服器名稱變動，也不會破壞整體結構。分組命名應簡短且穩定，避免把到期日、臨時狀態和長篇說明全部塞進名稱。

在 v2rayN 中新增訂閱時，先為每個連結建立獨立分組，再執行單一分組更新。首次匯入不要立刻全部更新，因為一條格式異常的訂閱可能讓結果難以判斷。更新完成後先確認伺服器數量是否符合預期，再隨機開啟幾個項目查看位址、連接埠、協定與傳輸欄位是否完整。訂閱只負責傳遞伺服器設定，不會自動替使用者決定路由策略、系統代理模式或 DNS 方案。

篩選器適合處理名稱中已有穩定標記的伺服器。常見做法是依關鍵字包含或排除，例如只查看名稱包含「低倍率」或特定地區縮寫的項目，或排除「維護」「剩餘流量」等非連線項目。正規表示式更靈活，但也更容易誤選。套用表示式前，先用一般關鍵字縮小範圍，再考慮是否真的需要正規表示式。中文括號、全形符號、空格與大小寫差異都可能影響比對結果。

包含任一關鍵字
HK|SG|JP

排除狀態類名稱
維護|到期|剩餘流量|官網

比對名稱開頭的地區標記
^(HK|SG|JP)[-_ ]

上面的表示式只用來示範篩選思路，實際名稱應以目前訂閱內容為準。篩選不會修改伺服器本身，只會改變清單結果或批次操作範圍。若篩選後清單為空，先清除條件，再檢查名稱是否使用了不同縮寫。不要為了讓篩選器運作而逐一手動重新命名大量伺服器，因為下次更新可能重新產生清單，手動名稱也可能失去與來源資料的對應。

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

同一台伺服器有時會由多個訂閱重複提供。判斷重複不能只看顯示名稱，還應比較位址、連接埠、協定與傳輸層參數。名稱相同可能是不同入口，名稱不同也可能指向相同的連線資訊。最穩妥的做法是依分組保留來源邊界，不在匯入後跨組大規模合併。需要簡化日常清單時，使用篩選檢視或固定收藏處理，而不是破壞訂閱的可更新結構。

更新訂閱後出現伺服器消失，先確認它是被來源訂閱移除、被篩選條件隱藏，還是進入了其他分組。若更新後完全沒有項目，應檢查訂閱連結是否完整、網路請求是否成功，以及回傳內容能否被用戶端識別。相關基礎操作可回到入門指南核對。若只有個別伺服器無法連線，應將問題歸入伺服器設定或網路鏈路，不要反覆刪除並重新新增整個訂閱。

伺服器排序也需要明確目的。依名稱排序適合固定地區標記，依分組排序適合區分來源；測速結果只能反映測量當下與測量目標，不代表所有服務的實際體驗。測試前應確保目前系統沒有大量下載工作，並使用相同測試方法比較。測試失敗也不必立即刪除伺服器，因為 ICMP、TCP 探測與實際協定連線所經過的流程不同，部分伺服器可能不回應某類探測，但仍能建立正常連線。

在 Android 上，v2rayNG 與 v2flyNG 的介面組織方式和桌面版不同，但原則一致：訂閱來源保持獨立，更新前確認目標分組，更新後檢查目前選取的設定是否仍然存在。行動裝置還要留意系統背景限制，訂閱更新中斷與背景連線停止是兩類問題。關於 VpnService 授權與省電白名單，可繼續閱讀v2rayNG 安卓使用要點。

隔離主要、備用與實驗來源

多訂閱管理的重點不是訂閱越多越好，而是避免不同來源互相覆蓋。建議至少分成主要、備用與實驗三種角色。主要訂閱負責日常連線，變更頻率應最低；備用訂閱只在主要來源異常時啟用；實驗訂閱用來觀察新協定或臨時設定，不應直接混入日常伺服器清單。角色確定後，更新、篩選與刪除都以分組為單位進行。

每個訂閱都應有穩定名稱與清楚用途。可以在分組名稱中寫來源簡稱與角色，但不要記錄存取憑證、完整連結或其他敏感內容。訂閱連結本身應只保存在用戶端的訂閱設定中，不要複製到截圖、公開日誌或共用設定範例。需要轉移裝置時，優先在新裝置上重新新增訂閱，而不是直接複製包含本機狀態、歷史日誌與介面偏好的整個資料目錄。

更新計畫應考慮來源穩定性。頻繁手動重新整理不會讓線路本身更快，反而可能在來源服務暫時異常時覆蓋原有結果。日常使用可以先更新單一主要訂閱，確認回傳內容正常後再更新其他分組。若用戶端支援保留更新前內容，應啟用相應的失敗保護；若沒有此選項，則在重要調整前匯出不含訂閱憑證的本機伺服器設定，或記錄目前可用項目。

處理同名、改名與來源遷移

訂閱提供者調整命名規則後，收藏、篩選表示式與手動備註可能失效。應優先根據穩定欄位重新識別伺服器，例如位址、連接埠、協定與傳輸組合，而不是只看顯示名稱。確認是同一個連線設定後，再更新篩選條件。若來源整體遷移至新訂閱連結，先將新連結新增為新分組並完成一次更新，確認伺服器可用後再停用舊分組，避免替換過程中失去回復入口。

同一個連線由多個分組提供時，不建議立即視為冗餘。不同訂閱可能有不同更新週期、參數細節或使用範圍。可以先在名稱篩選中隱藏重複項目，等連續幾次更新都確認內容一致後，再決定是否移除某個來源。刪除訂閱設定前，要區分「刪除訂閱入口」與「刪除已匯入的伺服器」，部分用戶端會分開處理兩者。

批次操作前先限定分組。批次測速、批次刪除與批次修改容易誤傷其他來源，尤其在篩選器仍然生效時，介面顯示範圍未必等於實際操作範圍。執行前應清楚確認目前分組、篩選條件與選取數量。通常不建議批次修改傳輸參數，因為訂閱中的路徑、主機名稱、TLS、REALITY 公開金鑰與短識別碼具有伺服器端對應關係，不能只憑相似名稱互換。

建立易於維護的變更記錄

在多訂閱環境中，簡單的變更記錄比複雜備份更實用。每次只記錄日期、修改模組、修改前狀態、修改後狀態與驗證結果。例如「啟用主要分組的地區篩選，未修改路由；瀏覽器與桌面程式連線正常」。發生問題時，就能快速找到最近一次影響範圍較大的變更。記錄中不要保存完整訂閱連結、伺服器金鑰或可直接重複使用的驗證欄位。

當伺服器清單突然增加或縮減時，先比較各分組的更新時間與回傳狀態，再檢查篩選條件。若只有一個來源異常，就暫停該來源的自動更新，不要立即重建全部設定。若所有來源都無法更新，但既有伺服器仍可連線，問題更可能出在訂閱請求、系統代理或 DNS 路徑；若更新正常而所有伺服器同時連線失敗，則應進一步檢查本地網路、作用中出站與系統時間。

先理解入口、條件與出口

路由規則回答三個問題：流量從哪個入口進入、符合什麼條件，以及最後交給哪個出口。常用條件包括網域、IP、目標連接埠、網路類型、入站標籤與程序資訊。出口通常至少包含代理、直連與阻斷三類。用戶端會由上到下讀取規則，第一個符合的結果決定出口，因此更具體的規則應放在前面，更寬泛的兜底規則放在後面。

網域規則只有在核心能取得網域時才會生效。如果應用程式先在本機解析，只向代理提交 IP，單純的網域規則可能無法命中。反過來，IP 規則需要解析結果或直接以 IP 為目標。domainStrategy 決定路由模組是否以及何時為網域補充 IP 判斷。常見做法是先使用網域規則，在需要比對 IP 規則時再解析；若設定為始終只按 IP 處理，會降低部分網域規則的可讀性與控制能力。

規則設計應從業務目的出發，而不是堆疊大量清單。先列出必須直連的本地位址與區域網路，再寫明確需要代理的網域群組，接著處理特定 IP 範圍，最後設定預設出口。阻斷規則只用於確定不需要建立連線的目標或協定類型。規則越多，就越要維持命名、註解與順序穩定，否則之後無法判斷某條流量為何命中某個出口。

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

domain: 通常表示比對指定網域及其子網域，full: 用於完整網域比對，一般字串規則的具體解釋取決於核心格式。對單一明確主機，優先使用完整比對；對同一服務的多個子網域，使用網域後綴比對。不要用過短的關鍵字進行寬泛比對，例如只寫一個常見單詞，可能命中大量無關網域。

從簡單三段式逐步擴充

第一階段只保留「私有位址直連、明確網域走代理、其餘使用預設出口」三段。確認結果後，再加入需要直連的業務網域或特定 UDP 處理。若用戶端提供預設路由方案，可以先複製一份再修改，不要直接反覆覆蓋唯一方案。每條規則都應有明確驗證目標，例如新增一條完整網域規則後，只測試該網域與一個不應受影響的對照網域。

程序路由依賴用戶端、核心與作業系統能力，不能作為所有平台一致適用的基礎規則。程序名稱也可能因安裝方式或子程序結構而變化。若某個應用程式支援自行設定代理，優先在應用程式內明確設定；需要接管不讀取代理的應用程式時，再考慮 TUN 與程序條件。Android 上的分應用程式代理屬於系統 VPN 接管範圍，與桌面版的程序路由不是同一種實作。

連接埠規則適合協定明確的情境，但不應根據「常見連接埠」猜測業務。現代應用程式可能共用 443 或使用動態連接埠，單靠連接埠無法準確區分服務。UDP 也不能一律阻斷，因為 DNS、即時通訊與部分傳輸會使用 UDP。若某條規則導致網頁能開啟，但媒體、語音或登入功能異常，應檢查是否錯誤處理了 UDP、QUIC 或相關網域。

判斷路由是否生效，不要只看出口 IP。更可靠的方法是結合核心日誌中的目標、規則條件與出站標籤。若日誌顯示目標進入錯誤出口，檢查規則順序與標籤；若沒有相關連線記錄，表示流量可能未進入該入站；若只看到 IP 而看不到網域，則要繼續檢查應用程式解析方式、嗅探設定或 FakeDNS 鏈路。路由設定與 DNS 密切相關，下一章應在目前路由穩定的基礎上繼續。

確認由誰解析網域

DNS 設定的第一步不是立即更換伺服器，而是確認解析發生在哪裡。瀏覽器可能啟用自己的加密 DNS，作業系統有系統解析器，用戶端核心也能設定獨立 DNS。若三者同時存在，實際請求可能繞過剛修改的那一層。排查時應暫時統一路徑：關閉瀏覽器獨立解析或明確記錄其狀態，讓測試網域進入用戶端核心，再觀察日誌中的查詢與回傳結果。

DNS 故障通常表現為網域無法開啟、直接 IP 可連線，或同一網域在不同應用程式中得到不同結果。連線逾時不一定代表 DNS 故障；如果網域已正確解析，但目標連線在 TLS 或傳輸階段失敗，應繼續檢查伺服器與路由。反過來，解析得到位址也不表示結果適合目前網路，快取、錯誤上游或分流路徑都可能導致連線到非預期位址。

建議依用途拆分上游，而不是把多個位址無序放進清單。系統 DNS 可處理區域網路主機與本地網路相關網域；指定的一般 DNS 或 DoH 可處理其他查詢；需要依網域分配上游時，為每個伺服器設定清楚的 domains 範圍。解析請求本身也要有正確出口：直連上游應透過直連出口存取，需要經代理存取的上游則由路由規則送往代理出口。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "https://dns.example.com/dns-query",
        "domains": [
          "domain:example.net"
        ],
        "skipFallback": true
      },
      "localhost"
    ]
  }
}

範例中的網域僅用於說明結構，實際設定應替換成可用的 DNS 服務位址。queryStrategy 控制查詢 IPv4、IPv6 或兩者的策略，應與目前網路能力一致。若網路沒有穩定的 IPv6 路徑，卻優先回傳 IPv6 位址，應用程式可能先等待失敗再回退，表現為首次連線緩慢。直接停用某類位址也不是固定答案；應先確認系統是否具備可用路由，再決定查詢策略。

分流、快取與回退的關係

分流解析的目標，是讓不同網域使用合適的上游，並沿正確出口送出。網域規則應盡量精確，避免同一網域同時落入多個重疊範圍。回退伺服器用於主要比對沒有結果，或依設定允許繼續查詢的情況，不應視為隨機負載平衡。若設定了 skipFallback，要確認對應網域確實只能由目前上游處理，否則主要上游暫時失敗時不會自動轉向其他伺服器。

快取會讓調整後的結果看起來沒有變化。核心、作業系統與瀏覽器可能各自快取 DNS。修改設定後，先重新啟動或重新載入核心，再清除系統與應用程式層的快取，最後使用近期未存取過的子網域作為對照。不要在短時間內反覆切換多個上游，卻只測試同一個網域，這樣很難區分新結果與舊快取。

DoH 將 DNS 查詢放入 HTTPS 連線，能統一傳輸方式，但它本身仍需要解析 DoH 伺服器的網域，因而產生引導解析問題。常見處理方式是為 DoH 服務準備可直接連線的引導位址，或讓系統解析器先解析該主機。若路由將 DoH 主機送入依賴同一 DNS 的循環路徑，核心可能長時間等待查詢。此時應檢查 DNS 伺服器位址、路由規則與出站標籤之間是否形成遞迴依賴。

需要更完整理解中國大陸與境外的分流解析、DoH 與 DNS 污染排查時，可閱讀V2Ray DNS 設定詳解。實際調整仍應以目前網路與核心日誌為準，不要把同一組上游位址機械式複製到所有裝置。桌面寬頻、行動網路與企業網路的解析限制不同，穩定方案往往來自明確分工，而不是伺服器數量。

TUN 與系統代理解決不同問題

系統代理依賴應用程式主動讀取代理設定，適合瀏覽器和多數遵循作業系統代理的桌面軟體。TUN 模式透過虛擬網路介面接收更廣泛的 IP 流量，可以涵蓋不讀取系統代理的程式。兩者不是簡單的「一般模式」與「增強模式」，而是兩種接入方式。只需要瀏覽器代理時，系統代理更容易維護；需要處理獨立網路堆疊、遊戲啟動器或命令列程式時，再評估 TUN。

啟用 TUN 前應確認一般系統代理已穩定，目前伺服器可正常連線，DNS 與路由規則也能獨立運作。接著關閉可能衝突的其他虛擬網卡軟體，記錄系統原有的預設路由與 DNS 狀態。v2rayN 啟用 TUN 時可能需要作業系統權限來建立虛擬介面、設定路由與調整 DNS。權限被拒絕時，介面開關可能已經變更，但虛擬介面並未成功建立，因此要同時查看用戶端狀態與系統網路介面。

TUN 接收的是網路層流量，仍需要核心將其轉換並交給路由與出站。常見設定涉及介面位址、MTU、自動路由、嚴格路由與協定堆疊實作。自動路由負責將目標流量導向虛擬介面；嚴格路由用於減少繞過路徑，但也可能影響區域網路、容器與虛擬機網路。首次啟用時應保留預設參數，只在發現明確相容性問題時調整。

區域網路、虛擬機與容器的處理

區域網路位址通常應直連，並排在寬泛代理規則之前。否則印表機、路由器管理頁面、檔案分享或本機開發服務可能被送往代理出口。常見私有位址範圍可以使用核心提供的 geoip:private 規則處理，但還要留意本地使用的特殊網段、虛擬機橋接網段與容器網路。企業網路可能使用額外的內部位址與網域，這些內容需要依實際情況新增。

虛擬機使用 NAT、橋接或僅主機網路時，流量入口與來源位址都不同。主機的 TUN 不一定會自動接管橋接虛擬機的全部流量，也不應假設容器流量會沿用桌面應用程式的相同路徑。排查時先在主機測試，再於虛擬環境內測試 DNS、預設路由與出口。若只在虛擬環境失敗，應檢查該環境自身的網路設定，而不是直接擴大主機路由規則。

MTU 不合適時，常見表現是小型頁面可以開啟，但大檔案、圖片或 TLS 握手在特定階段卡住。不要看到連線變慢就立即降低 MTU。先確認問題是否只發生在 TUN，以及是否與特定網路有關，再逐步調整，並限制每次的變更幅度。修改後應測試網頁、下載與 UDP 應用程式，而不是只查看單一網站。

Windows 查看介面與路由
ipconfig /all
route print

macOS 查看介面與預設路由
ifconfig
route -n get default

Linux 查看位址與路由
ip address
ip route

這些命令用於觀察系統狀態，不會直接修復設定。重點確認虛擬介面是否存在、預設路由是否符合預期、區域網路路由是否仍可連線，以及關閉 TUN 後相關項目是否恢復。不了解用途時，不要手動刪除整張路由表。若用戶端停止後網路仍然異常，先完全退出用戶端並重新連線目前網路，再檢查殘留介面與 DNS。

避免流量循環與控制連線被接管

TUN 最重要的邊界，是繞過代理程序本身與伺服器連線。若連線代理伺服器的流量再次進入 TUN，並被路由回同一個代理出站，就會形成循環。成熟的用戶端通常會自動處理伺服器位址、程序或介面繞過，但自訂規則可能破壞這層保護。出現啟動後立即斷線、日誌重複連線至同一目標，或流量快速累積時，應優先檢查循環。

DNS 也可能形成類似循環：TUN 將 DNS 請求送入核心，核心存取 DoH 伺服器時又依賴尚未完成的解析。處理方式是明確設定引導解析、DNS 出口與 TUN 排除範圍。不要同時開啟多個系統級 VPN 或透明接管工具來「增強相容性」，它們會競爭預設路由、DNS 與虛擬介面，最終狀態往往不穩定。

Android 上的 VpnService 同樣會建立系統級接管，但操作方式、權限模型與桌面 TUN 不完全相同。v2rayNG 或 v2flyNG 首次連線時需要完成系統授權，並依需求設定分應用程式代理。背景執行頻繁停止時，應檢查省電策略，而不是修改桌面版的 TUN 參數。

為什麼要為網域配置虛擬位址

某些應用程式會先自行解析網域，再只將目標 IP 交給系統網路。進入 TUN 後，核心看到的是 IP，原始網域已經遺失，基於網域的路由規則便難以命中。FakeDNS 的作用是為查詢回傳一段虛擬位址，同時保存「虛擬位址與原始網域」的映射。當應用程式連線至這個虛擬位址時，流量會被 TUN 收回，核心再還原原始網域並執行網域路由。

因此，FakeDNS 不是一般公共 DNS 的替代品，也不是單獨開啟就能運作的加速選項。完整鏈路至少包括：應用程式查詢進入核心 DNS、FakeDNS 回傳虛擬位址、應用程式發起連線、連線進入受控入站、核心識別虛擬位址並還原網域、路由選擇實際出站、出站端完成實際解析或建立連線。任何一步繞過用戶端，都會導致虛擬位址無法還原或網域規則失效。

啟用前必須先讓 TUN 與一般 DNS 分別穩定。接著選擇不與區域網路、虛擬機、容器及企業網路衝突的虛擬位址池。位址池只用於本機映射，不應傳送到真實網路。如果路由錯誤地讓虛擬位址直連，應用程式會持續逾時。位址池容量還要涵蓋活躍網域數量，但沒有必要盲目擴大到與現有網路重疊的範圍。

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

198.18.0.0/15 常用於基準測試網路，可作為虛擬位址池範例，但仍應檢查目前網路是否已使用相關範圍。設定欄位會隨核心設定方式而異，應以用戶端產生的結構為基礎，不要將片段直接替換到不相容的設定中。FakeDNS 也與 DNS 伺服器順序有關：並非所有網域都必須回傳虛擬位址，本地域名、區域網路主機與明確要求真實 IP 的應用程式可以保留一般解析。

識別虛擬位址洩漏與映射失效

如果應用程式取得虛擬位址後，連線沒有進入 TUN，而是由系統直接送往實體網路，就會出現虛擬位址洩漏。通常表現為網域解析看似成功，但連線始終逾時，核心日誌中也找不到對應請求。此時不要繼續更換上游 DNS，應檢查應用程式是否由 TUN 接管、分應用程式規則是否排除了它、自動路由是否生效，以及虛擬位址段是否被其他路由優先處理。

映射失效可能發生在核心重新啟動、快取保留或位址池重複使用之後。應用程式仍快取舊虛擬位址，但新的核心已沒有原映射，因而無法還原網域。解決時應重新載入設定，並清除應用程式與系統 DNS 快取，讓應用程式重新查詢。若問題只在長時間執行後出現，還要檢查位址池容量、快取生命週期，以及是否存在大量短期網域請求。

部分應用程式會驗證回傳位址、使用內建 DNS、直接連線固定 IP，或在應用程式內建立加密解析鏈路。這些流量不一定適合 FakeDNS。遇到單一應用程式異常時，可先將該應用程式移出 FakeDNS 測試範圍，使用真實解析並透過 IP 或程序規則處理。不要為了一個特殊應用程式，就讓所有網域改走更複雜的鏈路。

是否值得啟用 FakeDNS，取決於是否確實需要在 TUN 環境中保留網域。普通系統代理已能傳遞網域時，額外啟用通常不會帶來明顯收益。設定完成後還應測試區域網路主機、常用網頁、長連線與休眠恢復，確保虛擬映射不會影響真實的本地解析。穩定性優先於功能數量。

從直連、阻斷與本地代理開始

自訂出站用於描述流量離開核心的方式。最基礎的設定通常包含代理出站、直連出站與阻斷出站。由訂閱伺服器產生的代理出站由用戶端維護，本地規則只需透過標籤引用它。新增出站時，標籤必須唯一、含義清楚，並避免與用戶端自動產生的標籤衝突。建議使用 direct、block、local-socks 這類職責名稱，不要使用「線路一」「臨時二」等難以長期理解的標籤。

直連出站會將流量交給本機網路，仍受系統路由與 DNS 能力影響；阻斷出站會明確拒絕符合條件的流量；本地 SOCKS 出站可以將流量交給另一個執行於本機或可信任區域網路中的代理服務。自訂鏈式出口會增加故障點，只有在上游職責明確且能獨立驗證時才應使用。若一般訂閱伺服器已能滿足需求，不必額外新增多層轉發。

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

範例中的本地連接埠只有在另一個 SOCKS 服務確實監聽 127.0.0.1:1081 時才可使用。新增後先檢查連接埠監聽狀態，再寫入一條只比對測試網域的路由規則，將其送至 local-socks。若直接把預設流量全部切換過去，一旦上游未啟動，所有連線都會失敗，也難以判斷問題來自規則還是上游。

理解出站鏈路中的 DNS 與循環

自訂出站存取網域時，仍然需要解析。需要確認解析由本機系統、核心 DNS 還是上游代理完成。若希望由上游代理解析網域，應保留網域形式並使用支援遠端解析的連線方式；若由核心先解析，路由與 DNS 策略會影響取得的位址。將這點寫入設定說明，能避免出現「路由命中了正確標籤，但卻連線到錯誤位址」的情況。

本地鏈式代理特別容易形成循環。例如 v2rayN 的出站指向本機 1081，而 1081 又由同一設定的入站占用；或者上游程式的流量再次被 TUN 捕獲，送回目前的出站。排查時查看連接埠所屬程序、入站監聽位址與 TUN 繞過範圍。一個連接埠只能由一個程序穩定監聽，入站與出站目標也不能形成閉環。

伺服器出站的協定、傳輸、TLS 與 REALITY 參數應來自實際伺服器端設定或訂閱內容。不能只憑協定名稱拼湊參數。VLESS、VMess、Trojan 等協定負責不同層面的驗證與傳輸組織，WebSocket、gRPC、TCP 等傳輸還會攜帶路徑、服務名稱或主機資訊。REALITY 與 XTLS Vision 的關係可參考REALITY 與 XTLS Vision 原理科普，但設定值仍必須與伺服器端逐項對應。

依「入口—解析—路由—出口」定位故障

系統化排錯應始終沿著流量方向進行。第一步檢查入口：應用程式是否讀取系統代理，或流量是否進入 TUN；第二步檢查解析：日誌中是否保留網域，DNS 是否回傳可用結果；第三步檢查路由：目標命中了哪條規則與哪個出站標籤；第四步檢查出口：上游位址、連接埠、協定與傳輸是否能建立連線。不要從最後一步開始反覆更換伺服器，因為入口尚未接管時，更換多少伺服器都不會改變現象。

若核心無法啟動，先恢復最近一次可用設定，檢查 JSON 語法、標籤引用、連接埠衝突與權限。若能啟動但沒有連線記錄，重點檢查系統代理、TUN 與應用程式設定。若有連線記錄但規則錯誤，暫時縮減為三段式路由。若規則正確但 DNS 失敗，切回簡單上游並關閉 FakeDNS。若解析與路由都正確而出站失敗，再核對伺服器設定、系統時間與本地網路。

完成排錯後，應將臨時日誌層級、測試規則與測試出站恢復為日常設定。保留一套基準、一套目前使用的方案與簡短變更記錄即可，不必長期堆積大量幾乎相同的設定副本。需要重新選擇用戶端或安裝對應平台版本時，可前往用戶端下載頁；桌面版優先使用 v2rayN，Android 可依核心需求選擇 v2rayNG 或 v2flyNG。