V2Ray 進階設定完整查閱

先分清訂閱、設定與分組

訂閱連結不是單一伺服器，更接近一份由伺服器端維護的設定清單。用戶端更新訂閱時，會讀取清單並產生多個伺服器項目；分組則是用戶端本機用來整理這些項目的管理層。三者的生命週期不同：訂閱可能定期更新，伺服器名稱與參數也可能隨之變動，而本機分組通常應保持穩定。理解這點後，設定策略就會清楚：訂閱負責接收來源變化，篩選規則負責選出所需項目，分組負責承載固定用途。不要依賴手動拖曳數十個項目來維持順序，因為下次更新可能重新產生清單，讓手動排序失去意義。

在 v2rayN 中，較穩妥的做法是先依來源建立訂閱分組，例如「日常主訂閱」「備用訂閱」「測試訂閱」，再為每個來源設定更新、篩選與別名。Android 版 v2rayNG 較適合維持較少分組：行動裝置螢幕空間有限，分組過細會增加切換成本。v2flyNG 的管理方式與 v2rayNG 接近，但核心架構不同，匯入後仍應確認協定與傳輸參數是否完整辨識。用戶端之間移轉時，應移轉訂閱地址或標準設定，不要把特定用戶端的顯示順序當成通用設定。

以正向篩選建立可預期的清單

伺服器篩選通常包含備註比對、協定篩選、地址篩選與連接埠條件。建議先設定正向條件，也就是明確保留哪些項目，再補充少量排除條件。假設訂閱備註包含地區、用途與倍率資訊，可以先保留名稱含有「常用」或明確地區標籤的項目，再排除「到期」「維護」「測試」等不應參與日常選擇的項目。正向條件越清楚，訂閱提供者調整命名時越容易發現問題；如果只維護一長串排除詞，新的異常標籤可能在未被注意時進入可選清單。

篩選運算式應依照訂閱中實際存在的命名規律撰寫。常見的正規表示式如 ^(?!.*(?:維護|到期)).*(?:常用|備用)，表示排除包含「維護」或「到期」的項目，同時只保留名稱含有「常用」或「備用」的項目。運算式中的全形標點、空格與大小寫都可能影響結果。首次撰寫時，先將幾個真實備註複製到本機文字中逐一比對，再放入用戶端。不要一開始就使用複雜運算式；兩段簡單規則通常比一段難以維護的組合規則更可靠。

{
  "group": "日常主訂閱",
  "include": "(常用|備用)",
  "exclude": "(維護|到期|測試)",
  "updateIntervalHours": 24
}

更新前後分別保留哪些內容

執行訂閱更新前，應先確認目前有一個可連線的設定，並記下它所屬的訂閱與備註。更新後先檢查項目數量是否異常變化，再確認目前選取的項目是否仍然存在。數量突然歸零時，優先懷疑訂閱存取、篩選條件或分組選擇，而不是立即修改協定參數；數量明顯減少時，先暫時關閉篩選以查看原始結果。如果原始項目完整，問題就在本機篩選；如果原始結果也不完整，則需要確認訂閱本身回傳的內容。

更新動作也涉及覆寫策略。訂閱產生的項目原則上由訂閱維護，不適合直接長期修改其中的地址、連接埠、使用者識別或傳輸層參數，因為後續更新可能覆蓋這些變更。確實需要實驗時，請複製一份項目到本機測試分組，並在名稱前加上「本機測試」以便區分。測試成功後，如果變更屬於訂閱端設定，應回到訂閱來源修正；如果只是本機路由或 DNS 需求，則應放在用戶端的全域設定或路由規則中，而不是逐一修改伺服器。

處理空清單與重複項目

訂閱匯入後沒有伺服器時，請依固定順序檢查：先確認目前查看的是正確分組，再手動更新一次，接著關閉所有包含與排除條件，最後查看用戶端日誌是否存在解析錯誤。若關閉篩選後恢復，逐一啟用規則即可找出衝突項目。若日誌顯示無法辨識內容格式，應確認訂閱回傳的是用戶端支援的設定格式，而不是登入頁面、提示文字或過期回應。相關基礎問題可繼續查看說明中心。

重複項目通常來自同一訂閱被匯入兩次、兩個訂閱包含相同伺服器，或更新時選擇了追加而非覆蓋。處理前不要只依備註判斷，因為同名項目可能擁有不同地址或傳輸參數。應比對地址、連接埠、協定、傳輸方式與安全層設定；完全相同的項目只保留一份由穩定訂閱管理，參數不同的同名項目則重新命名以標示來源。最終目標不是讓清單數量最多，而是讓每個項目都能追溯來源、用途明確，並在更新後維持可理解性。

路由判斷發生在建立連線之前

路由規則的工作不是改變伺服器參數，而是為每條目標連線選擇出站。應用程式發起存取後，核心會讀取可用資訊，包括目標網域、目標地址、連接埠、網路類型與程序來源，再依規則順序尋找符合項目。比對成功後，連線會交給指定出站，例如代理、直連或封鎖。沒有任何規則命中時，則進入最終預設出站。因此，排查路由問題時應先問「這條連線被哪條規則接住」，而不是只看目前選取了哪個伺服器。

網域與地址不一定能同時取得。某些連線進入核心時帶有網域，規則可以直接依網域比對；另一些連線只提供已解析的地址，此時網域規則可能無法生效。啟用網域嗅探後，核心可從部分協定流量中還原目標網域，但嗅探並非所有情境都可靠，也不應取代正確的 DNS 設計。穩定的路由設定應同時考慮網域規則與地址規則，並明確哪些規則依賴嗅探。

規則順序決定最終結果

大多數用戶端採用由上到下比對，第一條命中的規則會立即決定出站。應將範圍最窄、優先級最高的規則放在前面，把範圍廣的兜底規則放在後面。例如，某個內部網域必須直連，就應放在廣泛的代理網域規則之前；區域網路地址直連規則應放在預設代理之前；最後才是涵蓋其餘連線的兜底規則。若順序相反，廣泛規則會提早命中，後面的精確規則即使寫得正確也不會執行。

一組便於維護的規則通常依「特殊封鎖、指定直連、指定代理、地址範圍、預設行為」排列。封鎖規則應保持克制，只寫明確不需要連線的目標；直連規則包含區域網路、用戶端更新所需目標，以及確定應由本地網路存取的服務；指定代理規則用於確實有需求的網域或應用程式；地址範圍規則處理只帶有地址的連線；預設行為則負責未分類流量。規則層次清楚後，日誌中的出站標籤也更容易解讀。

Xray 路由結構範例

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

理解 domainStrategy，而不是機械套用數值

domainStrategy 決定網域在路由階段何時解析為地址。使用 AsIs 時，路由優先依原始網域判斷，不會為了地址規則主動執行解析；IPIfNonMatch 會先嘗試網域規則，沒有符合項目時再解析地址並繼續比對地址規則；IPOnDemand 則可能在遇到需要地址資訊的規則時更早觸發解析。沒有一個值適合所有網路。以網域規則為主、希望減少額外解析時，可以從 AsIs 開始；需要依賴地址資料庫完成分流時，IPIfNonMatch 通常更容易理解。

路由階段的解析也會受到 DNS 模組影響。如果 DNS 查詢本身走錯出站，路由可能取得不符合預期的地址，進而命中另一條規則。修改 domainStrategy 後出現「同一網域偶爾走不同出口」，應同時檢查 DNS 伺服器選擇、快取與網域規則命中情況。路由與 DNS 是前後相接的兩個系統，不適合分開盲目調整。

依連接埠、網路與應用程式縮小範圍

連接埠條件適合處理明確服務，例如只讓某個出站負責特定 TCP 連接埠，但不應把常見連接埠當作網域分類的替代品。許多服務共用 443 連接埠，單靠連接埠無法區分目標。網路條件可用來區分 TCP 與 UDP，適合在某個出站不支援 UDP，或需要單獨處理即時通訊時使用。應用程式條件則取決於用戶端能力：v2rayNG 的分應用程式代理會從 Android 應用程式層面決定哪些程式進入 VPN；進入核心後的連線仍可繼續使用網域、地址與連接埠路由。

分應用程式代理的包含模式與排除模式，只能圍繞一個清楚目標選擇。裝置上只有少數應用程式需要進入用戶端時，使用包含模式較容易控制；大部分應用程式都需要進入、只有少量本機應用程式例外時，排除模式更省維護。應用程式更新或更換套件名稱後，舊規則可能不再符合，因此系統升級後若某個應用程式突然改變路徑，應先核對應用程式選擇清單，而不是直接重寫網域規則。

用日誌驗證命中，而不是只看網頁結果

驗證路由時，先清除容易造成混淆的背景連線，再開啟用戶端日誌，接著只存取一個測試目標。重點觀察目標網域或地址、符合的規則，以及最終出站標籤。如果日誌只顯示地址，可檢查 DNS 與嗅探設定；如果出站標籤正確但存取失敗，問題更可能位於目標伺服器、選取的節點、傳輸參數或本機網路。若標籤錯誤，將對應規則暫時移到最前方測試，確認規則內容本身能否匹配，再恢復合理順序。

修改路由規則後應重新建立連線，使新設定完整載入。瀏覽器可能重用既有連線，也可能保留 DNS 快取，因此只重新整理頁面不足以驗證變更。較穩妥的流程是中斷用戶端、關閉測試應用程式的背景程序、重新連線，再發起一次新的存取。需要系統化排查「顯示已連線但無法存取」時，可參考代理連接埠、路由模式與 DNS 逐項排查清單。

先理清解析鏈路

DNS 故障之所以難以排查，通常是因為系統 DNS、用戶端 DNS、瀏覽器加密 DNS 與遠端解析同時存在。應用程式提交網域後，查詢可能先由作業系統處理，也可能由 TUN 接管；若瀏覽器啟用獨立的加密 DNS，還可能繞過用戶端設定。核心取得查詢後，還要依網域規則選擇 DNS 伺服器，並決定查詢請求走直連還是代理。最後回傳的地址可能進入快取，再交給路由模組繼續比對。任何一層變更，都可能表現為「網域打不開但地址可連」或「同一網域結果不穩定」。

最佳化的第一步不是堆疊更多 DNS 地址，而是確定唯一的主要路徑。在一般系統代理模式下，可讓用戶端負責需要代理的網域解析，同時保留系統解析處理本地資源；在 TUN 模式下，則應讓進入虛擬網卡的查詢盡量由核心統一接管。測試期間可以暫時關閉瀏覽器獨立 DNS，避免形成平行路徑。確認用戶端鏈路正常後，再決定是否恢復瀏覽器設定，並驗證其流量是否依預期進入路由。

本機 DNS 與遠端 DNS 的職責

本機 DNS 適合解析區域網路名稱、企業內部網域，以及明確應由目前網路回應的目標。遠端 DNS 適合由代理出站承載的網域查詢，使解析位置與存取出口一致。兩者不是「一個快、一個慢」的簡單選擇，而是管轄範圍不同。將內部網域交給遠端伺服器，通常得不到正確地址；將需要與代理出口一致的網域始終交給本機伺服器，也可能得到不適合目前出站的結果。

設定時可依網域集合指定伺服器，並保留一個清楚的預設解析器。若用戶端支援 DoH，可以使用類似 https://1.1.1.1/dns-query 的 HTTPS 端點；若使用一般 UDP DNS，應明確請求是否經過代理出站。DoH 只是傳輸形式，不會自動保證路由正確。端點網域本身也需要首次解析，因此在嚴格環境中可以搭配明確的伺服器地址或引導解析策略，避免形成「解析 DNS 伺服器網域還要先存取同一台 DNS 伺服器」的循環依賴。

依網域範圍選擇 DNS 伺服器

{
  "dns": {
    "hosts": {
      "router.internal.example": "192.168.1.1"
    },
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "domain:internal.example"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

queryStrategy 與地址族選擇

queryStrategy 控制查詢 IPv4、IPv6 或同時查詢。選擇 UseIP 時通常允許兩類地址，實際回傳仍取決於伺服器與網路；只使用 IPv4 可減少 IPv6 路徑不可用時的等待；只使用 IPv6 則要求本機網路、代理出站與目標服務都完整支援。不要僅因日誌出現 IPv6 地址就立即停用它，應先判斷失敗是否真的發生在 IPv6 連線階段。穩定網路可保留雙協定堆疊，不完整的網路則應選擇符合實際連通能力的地址族。

地址族問題常表現為首次開啟較慢、稍後又恢復，或同一目標在不同應用程式中表現不同。原因可能是應用程式採用不同的地址選擇演算法，也可能是其中一個地址族先失敗後回退。檢查時應分別觀察 A 與 AAAA 結果，並在用戶端日誌中確認最終嘗試的目標地址。只修改 DNS 回傳類型而不檢查出站能力，可能把原本可用的另一類地址一併排除。

快取、Fallback 與污染式誤判

DNS 快取能減少重複查詢，但也會延長錯誤結果的影響。修改伺服器或分流規則後，應中斷並重新連線用戶端，必要時重新啟動測試應用程式，讓舊快取退出。若系統仍保留解析結果，可以等待記錄過期，或使用系統提供的快取刷新方式。不要連續更換多個 DNS 後立即比較，因為此時瀏覽器、系統與用戶端可能各自持有不同階段的結果，觀察到的並非單一設定效果。

Fallback 機制用於首選伺服器不適合，或結果符合特定條件時轉向備用解析器。它需要明確的判斷條件，否則多個伺服器可能同時回傳不同結果，增加理解難度。對於內部網域，可透過 skipFallback 防止查詢洩漏到不認識內部命名的伺服器；對於一般網域，應依網域集合或地址範圍設計回退，而不是簡單並列多個伺服器後期待用戶端自動選擇「最好」的答案。設定越複雜，越需要從日誌確認實際使用了哪個解析器。

遠端 DNS 失敗的排查順序

遠端 DNS 沒有回應時，先直接檢查端點能否建立連線，再看其請求走的是代理還是直連出站。若端點使用網域，確認引導解析能取得地址；若使用 HTTPS，檢查裝置系統時間是否正確，因為時間偏差會影響 TLS 建立連線。接著檢查路由規則是否將 DNS 端點錯誤送入封鎖或不支援的自訂出站。最後再檢查用戶端日誌中的回應格式與逾時資訊。依此順序可以區分「端點無法連線」「路由錯誤」與「解析結果不適用」。

在 Android 上啟用 VPN 模式後，還要留意系統私人 DNS 設定。系統私人 DNS、瀏覽器獨立 DNS 與 v2rayNG 遠端 DNS 若同時運作，查詢路徑可能與預期不同。排錯時先保留 v2rayNG 的單一路徑，確認網域解析與存取都穩定，再逐項恢復系統功能。桌面版 v2rayN 則需要區分系統代理與 TUN：系統代理不一定接管所有程式的 DNS，TUN 才更接近全域網路層接管。兩種模式不能用完全相同的觀察方式判斷。

TUN 與系統代理的工作位置不同

系統代理依賴應用程式主動讀取作業系統的代理設定，適合瀏覽器與遵循系統網路設定的軟體。TUN 模式則建立虛擬網路介面，在更低的網路層接收流量，因此能涵蓋不支援 HTTP 或 SOCKS 代理設定的程式。它的涵蓋範圍更廣，也代表需要處理更多細節：路由表、DNS 接管、UDP、地址族、區域網路存取與其他虛擬網路軟體都可能參與。把 TUN 理解成「更強的開關」並不準確，它是一套不同的流量入口。

選擇模式時應依據應用程式需求。日常網頁與明確支援系統代理的軟體可以先使用系統代理，設定簡單、故障範圍較小；當某個程式忽略系統代理、需要處理 UDP，或希望統一接管更多應用程式時，再啟用 TUN。不要在基礎連線尚未確認時直接疊加 TUN。先以一般代理模式驗證伺服器、協定與訂閱都正常，再切換入口，才能將新增問題限定在 TUN、DNS 或路由表範圍內。

啟用前的系統準備

桌面版 v2rayN 啟用 TUN 時，通常需要系統允許建立虛擬網卡並修改路由。權限不足可能導致開關看似已啟用，但介面並未正確建立。應觀察用戶端日誌是否完成介面建立、地址配置與路由寫入，而不是只看按鈕狀態。安全軟體、防火牆以及其他虛擬網卡工具可能攔截驅動程式或改變路由優先順序。首次測試時，關閉不必要的同類網路工具，保留單一變數，確認 v2rayN 能獨立執行。

Android 版 v2rayNG 使用系統 VPN 介面實現接管，系統會顯示 VPN 狀態。此時分應用程式代理、永遠開啟的 VPN、系統私人 DNS 與省電策略都可能影響結果。若系統同時指定另一項 VPN 服務，通常無法並行佔用同一介面。切換用戶端前應先中斷目前連線，等待狀態完全釋放，再啟動新的連線。背景活動受限會導致用戶端被系統暫停，因此需要依照裝置的電池管理規則允許其穩定執行。

堆疊類型、MTU 與 UDP

TUN 實作可能提供不同的網路堆疊選項。系統堆疊更貼近作業系統行為，通常相容性較好；使用者態堆疊則將更多網路處理放在用戶端內部，便於跨平台維持一致。具體名稱會隨用戶端介面而不同，但選擇原則相同：先使用用戶端推薦的預設堆疊，只有在日誌明確指向相容性問題、UDP 異常或特定應用程式失敗時才切換。切換後重新建立連線，並對同一目標重複測試。

MTU 表示網路介面一次承載的資料大小。數值過大時，某些路徑上的封包可能需要分片或被丟棄，表現為小型頁面能開啟、大型內容卡住、上傳失敗，或建立連線後沒有資料；數值過小則會增加額外負擔。排查時可以從系統或用戶端預設值開始，遇到疑似分片問題再小幅降低，並記錄每次變化。不要直接套用極端數值，因為不同網路、傳輸方式與封裝層的有效上限不同。

UDP 需要出站與伺服器設定共同支援。TUN 接收到 UDP 不代表遠端一定能夠轉送。如果網頁正常，但即時通訊、語音或部分網域解析失敗，應查看日誌中 UDP 是否進入正確出站，以及目前伺服器設定是否允許。為了定位問題，可以暫時讓 DNS 改用基於 HTTPS 的查詢，以區分一般 UDP DNS 故障與所有 UDP 流量故障；之後仍應回到真實使用情境驗證，而不是把臨時替代方案當作問題已消失。

繞過區域網路與避免路由迴圈

TUN 接管後，區域網路印表機、路由器管理頁面與檔案分享可能被錯誤送入代理。應在路由規則前段保留私有地址直連，並依需求加入本地域名。常見私有地址集合可由核心的 geoip:private 處理，但企業網路可能使用額外地址段，仍需依實際網路補充。驗證時分別存取閘道地址、區域網路裝置地址與一個內部網域，確認地址直連與內部 DNS 都正常。

路由迴圈發生在用戶端存取代理伺服器或 DNS 端點的流量又被 TUN 重新接管，並反覆送回自身。用戶端通常會自動排除自身程序或伺服器地址，但自訂出站、鏈式代理與特殊網路環境仍可能打破這項保護。典型表現是連線後立即失去網路、日誌重複出現同一目標，或伺服器連線不斷重建。應確保代理伺服器地址、必要的引導 DNS 與用戶端自身通訊都有明確可達路徑，並避免預設規則將所有流量不加區分地送回同一入口。

TUN 情境下的基礎路由架構

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

衝突診斷與復原路徑

啟用 TUN 後完全無法存取時，先中斷連線，確認系統網路恢復；若未恢復，退出用戶端並檢查虛擬網卡或系統路由是否仍然殘留。接著重新開啟用戶端但不要啟用 TUN，使用一般代理驗證伺服器。一般代理正常後，再關閉其他 VPN、虛擬機網路增強工具與可能改寫路由的軟體，重新啟用 TUN。若此時恢復，表示是軟體衝突；若仍失敗，則查看介面建立、DNS 接管與預設路由寫入日誌。

只有部分應用程式失敗時，不要重設所有設定。先判斷失敗的應用程式是否被分應用程式規則包含，再看它使用 TCP、UDP 還是自帶 DNS，接著檢查對應連線的路由標籤。網頁可存取但應用程式登入失敗，也可能是應用程式使用了不同網域或憑證驗證鏈路。透過一次只啟動一個應用程式、篩選日誌目標的方式，可以將問題縮小到特定連線。節點逾時與連線後立即中斷的排查順序，可繼續閱讀v2rayNG 節點逾時六環節排查。

FakeDNS 解決什麼問題

部分應用程式會先自行完成 DNS 查詢，再將目標地址交給系統。連線進入 TUN 時，核心看到的可能只剩地址，原始網域已經遺失，因此無法符合以網域為基礎的路由規則。FakeDNS 的概念是：用戶端對受控查詢回傳一個虛擬地址，同時記錄「網域與虛擬地址」的對應；應用程式隨後連線到該虛擬地址時，核心從對應中還原原始網域，再依網域規則選擇真實 DNS 與出站。它主要用於保留網域資訊，不是公共 DNS 的替代品。

這套機制依賴查詢與後續連線都經過同一個用戶端。如果應用程式繞過用戶端執行獨立解析，或連線沒有進入 TUN，對應就無法建立或使用。瀏覽器加密 DNS、應用程式內建解析器與某些直連網路函式庫都可能形成旁路。因此，啟用 FakeDNS 前應先確保 DNS 接管鏈路清楚，並確認 TUN 基礎功能正常。否則發生問題時，很難區分是對應、DNS 旁路還是虛擬網卡本身造成。

虛擬地址池不是可存取的伺服器

FakeDNS 回傳的地址來自專用虛擬池，只在用戶端內部代表某個網域，並不是網際網路上真實可存取的伺服器。測試工具顯示虛擬地址不表示解析錯誤；關鍵是後續連線是否被用戶端接住並還原網域。如果應用程式將虛擬地址儲存至檔案、長期快取或分享給其他裝置，該地址在用戶端對應之外沒有意義。因此，不適合把 FakeDNS 查詢結果用於持久設定、伺服器允許清單或區域網路裝置共用。

地址池需要避免與真實網路、區域網路及其他虛擬介面發生衝突。用戶端預設值通常已考慮常見情境，除非日誌顯示路由衝突，否則不建議任意修改。若企業網路使用特殊地址範圍，或裝置上還有容器、虛擬機與其他通道，應檢查路由表是否存在重疊。衝突可能表現為某些真實地址被錯誤視為虛擬對應，或虛擬連線被另一張網卡接管。

FakeDNS 與 DNS 伺服器組合範例

{
  "dns": {
    "servers": [
      "fakedns",
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  },
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

與嗅探及路由的配合

FakeDNS 與網域嗅探都能協助核心取得網域，但路徑不同。FakeDNS 在 DNS 查詢階段建立明確對應，適用於查詢被完整接管的 TUN 流量；嗅探則嘗試從後續協定內容中辨識網域，可能用於未經 FakeDNS 的連線。兩者可以搭配，但不應把所有問題都交給嗅探。對於加密程度較高，或協定內容不帶有可辨識網域的連線，嗅探未必成功，而 FakeDNS 對應更直接。

路由規則仍會依既定順序執行。還原網域後，精確網域規則、網域集合規則與預設規則依序比對。若 FakeDNS 已成功還原網域，但流量仍走錯出站，應檢查規則順序與出站標籤，而不是繼續調整地址池。日誌中通常可以看到原始目標、還原後的網域與最終出站；將三者串起來查看，才能判斷問題發生在哪個步驟。

哪些情境應謹慎啟用

區域網路內部網域、裝置探索、列印服務與依賴真實地址回傳的應用程式需要謹慎處理。內部網域通常應交給本機 DNS 並直連，不應進入 FakeDNS；依賴 DNS 回傳地址執行區域網路掃描或存取控制的軟體，也可能無法理解虛擬地址。可以透過網域規則讓內部命名跳過 FakeDNS，直接使用區域網路解析器。若應用程式必須取得真實地址才能運作，應為它設定分應用程式繞過，或使用真實 DNS 結果。

伺服器程式、開發除錯工具與需要顯示真實目標地址的網路分析工作，也不一定適合預設啟用 FakeDNS。它們可能將虛擬地址記錄到日誌，使分析人員誤以為目標伺服器位於該地址。進行封包擷取或問題重現時，應在記錄中明確標示 FakeDNS 是否開啟，並同時保留網域對應日誌。只有這樣，虛擬地址才能正確還原為實際目標。

快取失配與應用程式異常

應用程式在 FakeDNS 關閉後仍持有舊虛擬地址，是常見的切換故障。此時用戶端已不再維護原有對應，但應用程式繼續連線到舊地址，結果自然會失敗。切換 FakeDNS 狀態後，應重新建立連線並關閉相關應用程式的背景程序；必要時等待應用程式 DNS 快取失效。反向切換也一樣：剛啟用時，如果應用程式繼續使用之前快取的真實地址，短時間內可能看不到 FakeDNS 效果。

某個應用程式啟用 FakeDNS 後立即異常，而其他應用程式正常，應優先暫時排除該應用程式建立對照。若排除後恢復，查看它是否自帶 DNS、是否長期快取地址、是否依賴區域網路探索，或是否在應用程式層驗證實際地址。不要因為一個應用程式不相容就刪除所有網域路由；較合理的做法是為該應用程式選擇真實解析路徑，同時保留其他應用程式從網域對應中受益。

為每個來源定義角色

多訂閱不是把所有連結都匯入同一份清單。每個來源都應有明確角色：主訂閱負責日常使用，備用訂閱只在主要來源異常時啟用，測試訂閱用於驗證新協定或新傳輸參數。角色會決定更新頻率、篩選規則以及是否參與自動選擇。若三個來源的項目全部混在一起，發生故障時很難判斷問題來自哪個訂閱，也容易在名稱相同的伺服器之間誤選。

命名建議包含用途，而不是個人資訊，例如「主要｜日常」「備用｜手動更新」「測試｜暫時」。在 v2rayN 中，可以利用訂閱分組維持來源邊界；在 v2rayNG 中，應控制分組數量，並以清楚的別名減少行動版切換負擔。v2flyNG 作為 Android 備用用戶端時，也應使用相同的來源命名原則，但不要假設兩個用戶端會保留完全一致的本機分組結構。

自動更新需要故障保護

自動更新能及時接收來源變化，但當訂閱暫時回傳空內容或格式異常時，也可能影響現有清單。可靠的流程應保留最近一次可用結果，並在新結果明顯異常時停止覆寫。用戶端是否具備這種行為，需要以實際介面與日誌為準；無法確認時，主訂閱可按固定週期更新，備用與測試訂閱則採手動更新。這樣既能減少無意義的請求，也能避免所有來源在同一時間發生變化。

更新計畫可以錯開執行。例如主訂閱每日檢查，備用訂閱在需要切換前手動檢查，測試訂閱只在實驗期間更新。更新後先觀察項目數量與目前選取的項目，再進行批次測速或連線測試。測速只能說明測試當下的可達性，不能取代協定參數核對；如果大量項目同時失敗，更應先檢查訂閱格式、系統時間與本機網路，而不是逐一刪除。

去重不能只看顯示名稱

兩個訂閱可能使用相同備註，但伺服器地址、連接埠、使用者識別、傳輸方式或安全設定不同。真正的重複需要綜合比較關鍵連線參數。反過來，同一個設定也可能在不同來源中使用不同名稱。去重時應先依來源保留邊界，再對確認完全相同的項目選擇一個穩定來源。不要將不同訂閱產生的項目合併成無法追蹤的本機副本，否則後續參數變化無法自動同步。

如果需要在多台裝置間保持一致，最適合共用的是訂閱連結與少量標準化設定，而不是完整的用戶端狀態。桌面版的視窗配置、測速結果、目前選取的項目與 Android 分應用程式清單都屬於裝置本機資訊，不應強求同步。可同步的層級包括訂閱來源、標準協定參數與通用路由思路；裝置層則分別維護系統代理、TUN、應用程式選擇與本機 DNS。更完整的方式比較請見訂閱連結、QR Code 與匯出設定比較。

QR Code 與匯出檔案的界線

QR Code 適合在自己的裝置之間快速移轉單一設定。掃描後仍應核對協定、地址、連接埠、傳輸與安全欄位是否完整，不要只看備註名稱。QR Code 不適合承載長期變動的多訂閱體系，因為內容一旦產生便不會自動更新。長期維護時，訂閱連結更合適；一次性移轉或離線保存少量測試設定時，QR Code 更直接。

匯出設定檔能保存更多欄位，但也可能包含目前裝置特有的路徑、連接埠與本機規則。匯入另一個平台前，應先閱讀內容，移除不適用的本機設定，並避免將含有存取憑證的檔案放在公開位置。移轉完成後，先在新裝置建立單一連線基線，再恢復路由與 DNS。直接將桌面版所有進階設定一次搬到 Android，會讓權限、網路入口與應用程式選擇差異同時進入排錯範圍。

建立變更記錄與回退點

多訂閱環境最需要的是簡潔的變更記錄。記錄不必複雜，只要包含日期、修改對象、舊狀態、新狀態與驗證結果。例如「主訂閱增加排除詞」「備用訂閱改為手動更新」「Android 僅匯入主要來源」。當清單異常時，可以快速判斷最近一次變更發生在哪裡。設定內容涉及連線憑證時，記錄只寫變更類型，不要複製完整敏感欄位。

回退點應建立在「已驗證可連線」的狀態上。修改篩選規則前保留舊運算式，批次更新前記住目前可用的項目，匯入新設定前保留原有分組。若更新後連線失敗，先恢復選取項目與篩選條件，再判斷新訂閱內容。不要一邊回退訂閱、一邊更換 DNS 與 TUN 設定；同時回退多個層次雖然可能偶然恢復，卻無法確認真正原因。

主要與備用切換的驗證流程

備用訂閱只有定期驗證，才真正具備備用價值。驗證不需要長期保持連線，可在網路穩定時手動更新，選擇一個設定進行連線測試，並確認基本 DNS 與路由能夠運作。測試結束後切回主訂閱，避免目前選取的項目無意間留在測試來源。若主備使用不同協定或傳輸方式，應分別記錄各自必要的系統條件，避免故障發生時才發現備用設定依賴尚未啟用的功能。

主要來源異常時，先判斷是訂閱更新失敗，還是現有伺服器連線失敗。訂閱暫時無法更新不代表已匯入的設定立即失效；可以保留現有清單繼續測試。只有伺服器連線也失敗時，才切換備用來源。相反地，如果訂閱更新成功但清單為空，應先關閉篩選、查看原始內容，避免將本機篩選錯誤誤判為來源故障。

出站是路由規則的執行目標

路由規則只負責判斷，真正建立連線的是出站。最基本的設定通常包含代理出站、直連出站與封鎖出站。代理出站承載目前的伺服器連線，直連出站使用本地網路存取目標，封鎖出站拒絕不需要的連線。自訂出站是在此基礎上加入額外出口，例如指定 SOCKS 上游、獨立的直連策略或特定協定連線。每個出站都應有唯一且穩定的 tag，路由透過這個標籤引用它。

標籤命名應表達功能，例如 proxy、direct、block、upstream-socks。不要使用「線路一」「測試二」這類離開目前介面就失去語意的名稱。修改標籤時必須同步修改所有路由規則、DNS 出站引用與鏈式代理關係；如果只改一處，設定可能載入失敗，也可能在未命中時落入預設出口。

建立一個可檢查的基礎結構

自訂設定應先從三類基礎出站開始，確認日誌能顯示各自的標籤，再加入額外上游。直連使用 freedom 協定，封鎖使用 blackhole，代理出站則由目前用戶端產生或由訂閱設定提供。直接編輯完整核心設定時，要注意用戶端可能在連線時重新產生設定；如果介面提供自訂設定入口，應使用其支援的覆寫或合併機制，避免修改暫存檔後在下次連線時遺失。

基礎出站與 SOCKS 上游範例

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    },
    {
      "tag": "upstream-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081,
            "users": [
              {
                "user": "example-user",
                "pass": "your-password"
              }
            ]
          }
        ]
      }
    }
  ]
}

範例中的本機 SOCKS 服務必須確實在對應地址與連接埠上執行，否則路由到該出站的連線會直接失敗。若上游不需要驗證，應依核心支援的格式移除使用者欄位，而不是保留空字串。連線至遠端上游時，應確認其地址不會再次被同一出站接管而形成迴圈。任何存取憑證都只應儲存在自己的受控設定中，分享排錯截圖與日誌前應先移除相關欄位。

鏈式代理的方向要清楚

鏈式代理表示一個出站的底層連線透過另一個出站建立。它適合有明確網路拓撲需求的情境，但會增加延遲、故障點與日誌複雜度。設計前先畫出順序：應用程式流量進入用戶端，路由選擇業務出站，業務出站再透過上游出口連線到目標。鏈條中的每一層都必須能獨立連線，而且上游連線本身不能再次回到業務出站。

驗證鏈式結構時，應先單獨測試最外層上游，再加入內層連線。若上游是本機 SOCKS 服務，先使用明確支援 SOCKS 的工具確認連接埠可用；若上游也是用戶端內的出站，先寫一條只針對測試網域的精確路由。確認日誌依預期經過兩個標籤後，再擴大比對範圍。直接將預設流量全部切換到未驗證的鏈路，一旦失敗會同時失去查詢、更新與排錯所需的連線。

DNS 流量也要選擇出口

加入自訂出站後，DNS 請求可能仍沿用原有路徑。若目標存取走 upstream-socks，而遠端 DNS 走直連，解析位置與存取出口可能不一致。是否需要一致取決於情境，但必須是明確設計，而不是偶然結果。可以為 DNS 端點新增精確路由，使其透過指定出站，也可以讓內部 DNS 始終直連。修改後觀察 DNS 端點連線與目標連線是否分別命中預期標籤。

要避免 DNS 迴圈：如果上游出站的伺服器地址是網域，而解析該網域的 DNS 又被路由到同一個上游，就可能在上游尚未建立時形成依賴。解決方式包括為上游地址提供可靠的引導解析、使用明確可達的地址，或為其 DNS 查詢設定獨立的直連路徑。選擇哪種方式取決於網路條件，核心是讓建立上游所需的基礎連線不依賴上游本身。

封鎖出站與失敗表現

封鎖出站用於明確拒絕不需要的連線。它與「連線失敗」在表面上可能相似，但日誌應能顯示流量命中了 block 標籤。排查某個目標無法存取時，先檢查是否被封鎖規則捕捉，尤其是在使用廣泛網域後綴或連接埠條件時。封鎖規則應放在適當的優先級，並限制在可解釋的範圍內。範圍過寬會使正常資源、登入流程或用戶端更新請求一併被拒絕。

封鎖方式可能是靜默丟棄，也可能主動回傳拒絕。不同應用程式對兩者的表現不同：靜默丟棄通常表現為等待逾時，主動拒絕通常會更快失敗。選擇方式時，應以減少無意義等待與維持應用程式相容性為原則。不要透過封鎖大量未知目標來取代清楚的分應用程式與路由設計；規則越難解釋，後續維護成本越高。

用戶端產生設定與手動設定的界線

v2rayN、v2rayNG 與 v2flyNG 都會依據介面設定產生核心執行設定。手動範例用於理解欄位關係，不代表所有用戶端都允許直接貼上完整 JSON。若用戶端提供自訂設定匯入，應先確認它要求完整設定、局部覆寫，還是單個出站片段。格式不符時，即使 JSON 語法正確，也可能因缺少用戶端所需結構而無法啟動。

升級或切換用戶端前，應記錄哪些內容來自訂閱、哪些內容來自用戶端介面，以及哪些屬於手動覆寫。訂閱伺服器參數通常可以重新取得，複雜的自訂出站與路由則需要另外備份。備份後可在文字中檢查標籤引用：每個 outboundTag 都應對應實際出站，每個鏈式引用都應有目標，每個 DNS 路由都應能在上游建立前完成必要解析。

從最小規則逐步上線

推出自訂出站時，先用一個專用測試網域綁定到新標籤，保留其他流量不變。日誌確認連線命中新出站、DNS 路徑正確且沒有迴圈後，再逐步增加網域集合或應用程式範圍。每次擴大範圍都記錄修改內容，並保留可快速刪除的新規則。若失敗，只回退最近一層，不要重設已驗證的訂閱、伺服器與基礎路由。

最終設定應能回答四個問題：每類流量由哪條規則比對、規則選擇哪個出站、該出站如何建立底層連線，以及建立它所需的 DNS 又經過哪裡。如果其中任何一步只能靠猜測，設定就還不適合長期執行。遇到複雜故障時，可以先恢復 proxy、direct、block 三類基礎結構，再逐一加入自訂出口。需要重新選擇適合平台的用戶端時，可查看選型指南與安裝套件頁面。