V2Ray 進階設定指南

訂閱分組與伺服器篩選

區分訂閱來源、顯示清單與使用中的節點

訂閱分組是用戶端管理伺服器項目的容器，不等同路由分組，也不會自動指定某類應用程式使用特定節點。訂閱網址負責提供項目，分組負責整理項目，而目前選用的伺服器才決定一般代理流量的連線目標。先釐清這三個層次，才能避免「明明換了分組，對外連線卻沒變」的誤判。切換清單後，還要明確選取伺服器，並確認用戶端已套用新的使用中設定。

在 v2rayN 開啟訂閱分組設定，為不同來源建立獨立分組。名稱建議標示用途與來源簡稱，例如「日常使用」「備用連線」，不要直接貼上完整訂閱網址。新增網址後先儲存，再更新目標分組。首次更新完成後，檢查伺服器名稱、協定類型與傳輸參數是否正確辨識。若清單為空，先查看更新記錄，不要反覆新增相同網址，造成多個空分組。

篩選只會限制項目範圍，不能證明連線品質

伺服器篩選用來縮小可見或匯入的項目範圍，實際作用位置取決於用戶端提供的篩選選項。有些會篩選目前顯示的清單，有些則是在更新訂閱時篩選項目。修改前先查看欄位說明，並保留未篩選的原始分組以供比較。地區、線路用途與倍率通常是服務提供者的命名資訊，不是用戶端獨立測得的結果。名稱包含某個地區，也不能單靠名稱確認實際出口位置。

先用一般關鍵字搜尋，確認找得到預期項目，再考慮使用正規表示式。只有明確標示支援正規表示式的欄位，才適合套用下方的表示式。此式會比對名稱包含「香港」或「新加坡」的項目；若服務提供者使用其他名稱，就需要修改文字。不要直接貼到只支援一般文字的搜尋框，否則直線符號與括號可能被當成一般字元，反而找不到結果。

(香港|新加坡)

確認篩選是否正確時，先取消篩選以顯示所有項目，再套用條件並比較清單是否符合預期。沒有結果可能是大小寫、全形字元、隱藏空格或命名方式不同所致，不一定代表訂閱失效。同時使用排除與包含關鍵字時，請檢查條件是否互相抵銷。需要複雜條件時，逐項加入；一次寫好長篇表示式，不但難以定位錯誤，也不利於日後維護。

更新訂閱時保留可復原的資訊

遠端更新可能會取代分組中的伺服器項目，本機手動修改的備註或參數不一定會保留。需要長期保留的自訂伺服器，建議放在獨立的手動分組中。更新前記下目前使用的伺服器所屬分組與可辨識名稱，但不要假設更新後項目順序不會改變。服務提供者可能更改名稱、移除線路或調整排序；若只依清單位置選擇伺服器，更新後很容易切換到不符合預期的目標。

訂閱更新失敗時，先分辨是「無法取得網址」還是「無法解析內容」。前者要檢查網址是否有效、目前網路狀態，以及更新時是否使用代理；後者則要確認回傳內容是訂閱資料，而非登入頁面、到期通知或錯誤頁面。若選擇透過代理更新，必須先有仍可連線的使用中節點。所有節點都無法使用時，這種更新方式可能形成循環依賴，需改用目前網路可行的其他更新方式。

匯入 v2rayNG 或 v2flyNG 時，也要重新確認分組與使用中的節點。不同用戶端儲存備註、排序與篩選條件的方式可能不同，不能把桌面版的清單狀態當成手機端已同步的證據。訂閱連結通常包含存取憑證，複製到剪貼簿後請勿貼到公開群組。排查時只提供已去除敏感資訊的錯誤摘要，不要在文章留言或截圖中貼出完整連結。

路由規則實作與優先順序

先設定預設出口，再新增例外規則

路由分流的作用，是將已進入核心的連線導向特定出站。它不會自動將應用程式流量導入用戶端，也不等同於系統代理開關。規則通常依序比對，由第一條符合條件的有效規則決定連線路徑；沒有符合項目時，才使用設定的預設出站行為。修改前先確認預設流量要走代理還是直連，再將少數例外規則排在前面。否則，範圍過大的規則會讓後續細項規則無法生效。

v2rayN 的預設路由模式適合作為起點，不建議直接疊加多個預設模式的規則。先選擇最符合用途的一組，再透過路由設定檢視實際項目。內網位址、指定網域、地區集合與兜底規則應分層整理。代理伺服器本身連線的繞行設定尤其重要；啟用 TUN 後，還要避免代理連線再次被接管。用戶端可能會自動處理部分例外，修改前請先確認現有行為。

網域、位址與集合各有不同的比對條件

full: 適合比對單一完整網域；domain: 適合涵蓋指定網域及其子網域；regexp: 用於正規表示式比對；geosite: 用來引用網域集合。位址規則中的 ip 可使用單一位址、網段或支援的位址集合。集合名稱不代表固定內建的服務項目，能否使用取決於目前的資料檔。使用前請確認檔案存在，且項目名稱正確。

下方範例會將示範網域及其子網域導向名為 direct 的出站。此範例只用來說明路由結構，合併至設定時必須確認沒有相同標籤的出站。請將示範網域替換成實際需要直連的目標，但不要填入完整網頁網址。通訊協定前綴、連接埠與路徑都不屬於此網域比對欄位。透過圖形介面新增同類規則時，也應分別選擇網域條件與目標出站。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

多個條件如何組合

同一條規則中的不同條件欄位通常必須同時符合；同一清單中的候選項目則通常擇一符合。因此，把網域、連接埠與網路類型放在同一條規則中，會縮小比對範圍，而非分別建立三類流量規則。需要處理不同情境時，拆成獨立規則會更容易驗證。遇到「網域明明正確卻沒有命中」時，除了檢查順序，也要確認是否加上了與實際請求不符的連接埠或入站條件。

網域規則能否生效，也取決於核心是否取得網域資訊。明確使用代理的請求可能本身就帶有網域；部分透明接管流量只有目標位址，需要透過嗅探或 FakeDNS 對應來補足資訊。domainStrategy 則會影響何時為位址規則解析網域。請勿將它與 DNS 模組的查詢策略混為一談。提早解析不代表分流一定更準確，也可能增加等待時間，並改變位址規則的比對結果。

驗證規則時，請鎖定明確的目標：記下預期出站，建立一次新連線，再查看記錄中的目標與出站標籤。瀏覽器可能重用既有連線，因此修改規則後只重新整理頁面，不一定會觸發新的路由。必要時關閉相關應用程式後再測試。若結果不符，可先暫時將目標規則移到前面測試；確認能命中後，再調整回合理位置，不要長期依賴置頂來掩蓋其他規則範圍過大的問題。

DNS 設定最佳化與解析路徑

先釐清由誰解析，以及請求從哪裡送出

一次連線可能涉及應用程式自行解析、系統解析、用戶端內建 DNS，以及代理伺服器端解析。在用戶端填入遠端 DNS，不代表所有應用程式的查詢都會自動送往該伺服器。瀏覽器的安全 DNS、應用程式內建解析器與系統快取都可能繞過預期路徑。排查前先記下測試用的應用程式、流量接管方式與目標網域，避免把不同層級的查詢混在一起判讀。網頁的出口位址也無法單獨證明 DNS 解析路徑正確。

直連 DNS 與遠端 DNS 是依用途區分，不是單看地理位置。直連目標需要解析出適合本地連線的位址；代理目標則需要符合代理連線路徑。若解析結果有明顯地域差異，解析路徑錯誤可能使內容傳遞網路選擇的節點與實際出口不符。先以用戶端預設設定建立可用的基準，再依目標範圍拆分 DNS 解析。不要一開始就同時啟用多個解析器、複雜的回退機制與特殊查詢策略。

分別檢查查詢策略與路由策略

以下是核心 DNS 設定範例，使用公用解析位址並優先限定為 IPv4 查詢結果。此範例用於說明 servers 與 queryStrategy 的位置，不是適用所有網路的建議設定。公用解析位址能否連線，需在實際環境中測試。此設定本身不會接管系統 DNS、不會自動確保查詢經由代理，也不能取代用戶端對 DNS 出站路徑的設定。

{
  "dns": {
    "servers": ["1.1.1.1"],
    "queryStrategy": "UseIPv4"
  }
}

UseIPv4 會影響此 DNS 模組選擇的查詢結果，不會停用作業系統的 IPv6，也不會阻止應用程式透過其他解析器取得 IPv6 位址。若網路具備完整的雙堆疊能力，了解相關行為後即可選用相應策略。若只有特定 IPv6 連線失敗，請先判斷問題出在系統路由、代理出站還是伺服器鏈路。全面停用一種位址族或許能暫時避開問題，卻會掩蓋真正的設定缺漏。

路由中的網域策略與 DNS 查詢策略屬於不同層級。前者決定路由判斷何時解析目標，後者決定 DNS 模組如何查詢。使用網域集合分流時，盡量先完成網域規則判斷，再為確實需要位址條件的連線進行解析。若每個請求都提早解析，位址規則可能影響原本只打算依網域處理的目標。調整後應同時觀察網域比對結果與最終連線位址，不要只確認網頁能否開啟。

加密 DNS 仍需要可連線的網路路徑

加密解析可以保護查詢傳輸，但也必須能連線至解析服務。若解析服務使用網域位址，就得先解決該服務本身的 DNS 解析；若此連線設定為走代理，代理伺服器的網域又可能依賴尚未可用的 DNS。這種循環依賴會造成用戶端啟動正常，但所有新網域連線都持續逾時。請建立明確的初始解析路徑，並確認代理伺服器位址能獨立解析或以正確方式處理。

用戶端中的「透過代理查詢」、「遠端 DNS」或類似選項，應依目前核心與產生的設定判斷實際作用。不要只憑選項名稱推斷所有查詢都會走特定出口。若啟用了依網域選擇解析器，也要確認未符合條件時使用哪個預設伺服器、失敗後是否回退，以及回退後是否改變原本要求的路徑。增加解析器不一定更可靠，也可能讓同一網域得到不一致的回覆。

驗證時先選定一個一般網域，記錄系統查詢結果，再透過目標應用程式建立新連線。終端機查詢只代表該終端工具使用的解析路徑，瀏覽器可能另行使用安全 DNS。切換設定後，請等待快取過期，或在確認影響範圍後清除相關快取。不要每次測試都更換伺服器節點，否則出口與 DNS 同時改變，就無法判斷結果來自哪項調整。

也要檢查區域網路裝置名稱、公司內部網域與本機服務。這些名稱可能只能由區域網路解析器解析；若全部交給公用解析器，印表機、內部網頁或開發環境可能無法連線。應為確實屬於內部網路的名稱保留合適的解析路徑，同時避免把所有未知網域都當成本機名稱。使用搜尋後綴的環境，需分別測試短名稱與完整網域，確認用戶端沒有改變原有的解析方式。

TUN 模式與系統流量接管範圍

系統代理與虛擬網卡解決的是不同問題

系統代理主要提供代理入口給遵循系統設定的應用程式，是否使用取決於各應用程式的實作。TUN 則透過虛擬網路介面與系統路由接管流量，讓更多不讀取系統代理設定的應用程式進入處理流程。兩者不是「一般模式」與「加速模式」的差別。網頁已能正常使用時，只有確實需要接管其他應用程式或通訊協定流量，才需要進一步評估 TUN 的權限需求與相容性。

v2rayN 的 TUN 功能可能需要搭配網路堆疊元件，實際實作請以用戶端介面與產生的設定為準。不能因為目前代理出站使用 Xray，就將任意 TUN 入站欄位直接寫入 Xray 設定。核心、接管元件與圖形介面用戶端各有不同職責。啟用前先閱讀目前用戶端的選項說明，確認所需元件已就緒，再檢查權限、虛擬網卡建立與系統路由安裝是否成功。

先單獨啟用，再排除衝突

建議依序確認一般代理可用，再關閉其他可能接管系統網路的工具，儲存工作後啟用 TUN。首次測試不要同時修改 DNS、路由與節點。若用戶端提示需要更高權限，請依系統提示授予必要權限，不要反覆點擊開關。啟用後查看記錄，分辨「介面建立失敗」、「路由新增失敗」與「代理連線失敗」；這些問題發生在不同層級，處理方式也不同。

Android 用戶端透過系統 VPN 服務接管流量，不能直接照搬桌面版虛擬網卡的排查步驟。同一個使用環境中，其他使用 VPN 服務的應用程式可能造成資源衝突。若設定了依應用程式代理，也要確認目標應用程式在接管範圍內。系統背景執行限制可能導致螢幕熄滅後連線中斷；請先觀察中斷時機，再調整必要的背景執行設定，不要把所有間歇性斷線都歸因於節點品質。

路由迴圈與區域網路存取

TUN 接管流量後，代理伺服器本身的連線必須有正確的繞行路徑。若該連線再次被送回虛擬介面，就可能形成迴圈，導致不斷重新連線、資源使用量升高或完全無法連網。用戶端通常會處理必要的繞行，但自訂路由、額外網路工具與手動系統路由可能破壞這項設定。遇到這類狀況時，先停用 TUN 以恢復基準狀態，再檢查代理目標與系統路由，不要繼續疊加例外規則碰運氣。

區域網路目標需要個別測試。可先連線至路由器管理位址，再測試檔案分享、列印服務與內部網域。依位址排除私有網段，只能解決連線路徑問題，不一定能解決內部名稱解析；反過來，DNS 回傳正確位址，也不代表系統路由會直接連線。若裝置位於多個網段或使用企業 VPN，也要確認排除範圍沒有與對方網路重疊。過度寬泛地排除整個網段，可能影響其他用途。

UDP 能否使用，取決於接管元件、核心設定、節點協定、伺服器支援與目標網路的完整鏈路，不能只靠 TUN 開關保證。網頁請求成功，也不代表即時通訊或其他 UDP 服務正常。測試時請使用實際目標應用程式，並留意是否只有特定網路環境會失敗。若 TCP 正常但 UDP 失敗，請優先檢查協定支援與相關記錄，不要不斷切換系統代理選項。

切換網路後也要重新測試。從無線網路切換至有線網路、從休眠恢復或連上企業網路，都可能改變預設閘道、介面優先順序與 DNS。若用戶端未正確重建路由，舊狀態可能持續影響連線。先停止流量接管，再重新啟用，並觀察介面狀態是否恢復。未經確認不要刪除系統中所有虛擬網卡，這可能影響其他合法網路工具，也會使復原過程更複雜。

FakeDNS 對應與網域還原

虛擬位址是對應索引，不是目標伺服器

FakeDNS 會為查詢的網域回傳一個受管理的虛擬位址，並記錄網域與位址的對應關係。應用程式連線至該位址時，接管流程會依據對應資料還原網域，讓後續分流或代理連線能使用網域資訊。這個位址不是網站的真實位址，也不是公用網路上的實際出口。若應用程式取得特殊網段位址，不要立刻判定解析錯誤；應繼續檢查對應是否正確還原，以及真實連線是否由預期的出站建立。

FakeDNS 適用於能同時控制解析與後續連線的情境。若只有查詢進入 FakeDNS，連線卻繞過用戶端，就會取得無法依預期存取的虛擬位址；若只有連線進入用戶端，查詢卻由其他解析器處理，也不會建立相應的對應關係。啟用前先完成 TUN 或其他透明接管方式的基本驗證。若明確使用代理時已能傳遞網域資訊，不一定需要再增加這一層；額外元件也代表需要維護更多狀態。

核心位址池、DNS 服務與嗅探需搭配使用

下方範例示範支援相關欄位的核心如何定義位址池，並將 FakeDNS 設為 DNS 服務。這只是局部設定範例，必須搭配支援對應還原的入站、正確路由與 DNS 流量接管才有作用。不要直接將它寫入不支援這些欄位的網路堆疊設定。若用戶端已產生 FakeDNS 設定，請優先使用介面選項，避免手動設定與自動設定同時生效。

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

範例位址池使用保留供基準測試的位址範圍，不代表這段位址在所有環境中都沒有其他用途。部分企業網路、測試環境或其他流量接管工具也可能使用這段範圍。啟用前請檢查本機路由與既有設定，避免位址重疊。位址池容量用於管理對應資源，不是越大越好，也不代表可連線的節點數量。容量與資源使用量及活躍網域規模有關，不應把範例參數當成效能最佳化的結論。

若相關入站支援 FakeDNS 嗅探還原，可在既有入站物件中合併以下 sniffing 欄位。此處只示範欄位結構，不會新增監聽位址或連接埠。若實際使用的接管元件採用另一種設定格式，必須依其實作方式處理。單獨啟用嗅探不能取代 DNS 接管，也無法憑空還原已遺失的對應資料。驗證時應連續觀察查詢、虛擬位址與後續連線。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"]
  }
}

快取、重新啟動與混合解析的限制

FakeDNS 對應通常是執行期間的狀態。核心重新啟動後，應用程式可能仍快取先前取得的虛擬位址，但新的處理程序已沒有相應的對應資料。這會造成某些應用程式失敗，重新開啟後又恢復的情況。排查時先關閉受影響應用程式及其舊連線，必要時清除相關 DNS 快取，再重新查詢並連線。不要立刻調整整個位址池，否則新舊快取與對應資料並存，反而更難判斷問題來源。

瀏覽器或應用程式內建的加密解析可能繞過 FakeDNS，讓不同應用程式取得不同類型的位址。這不一定代表所有設定都失效，但表示不能用單一應用程式的結果推論整個系統。若目標是統一依網域分流，請檢查應用程式的解析設定與流量接管範圍。若目標應用程式必須使用自己的解析方式，就要確認該流量是否還有其他可用的網域辨識途徑，並接受它可能只能依位址規則處理的限制。

區域網路服務也不適合一律透過虛擬位址回覆。內部名稱可能依賴區域網路 DNS 的搜尋後綴與特殊記錄，有些應用程式還會直接比對解析出的位址。請先建立內部網域的真實解析路徑，再將適合的外部目標交由 FakeDNS 處理。需要讀取真實位址的診斷工具、依位址設定的存取控制及部分裝置探索機制，都應分別測試，不能只用網頁瀏覽代表所有服務正常。

停用 FakeDNS 時，應同步取消 DNS 服務選擇、對應還原設定與相關路由，再讓應用程式重新取得真實解析結果。若只關閉位址池，卻保留會回傳虛擬位址的解析路徑，就會留下不完整的設定。復原完成後，確認一般網域取得符合預期的真實位址，原有分流仍正常運作。若問題只在啟用 FakeDNS 時出現，請保留一般 DNS 的基準設定並逐段排查，不要直接歸因於節點無法使用。

多訂閱管理與更新策略

依來源分開管理，再按用途整理

不要將多個訂閱直接合併成一份龐大的伺服器清單。不同來源的更新週期、命名規則與可用範圍可能各不相同。先依來源建立獨立分組，再透過搜尋或篩選滿足日常選擇需求。如此一來，某個來源更新異常時，可以單獨停用或重新匯入，不會影響其他分組。用途標籤可寫在分組備註中，但不要把服務提供者的宣傳標示當成已驗證的能力說明。

訂閱網址與伺服器分享連結是兩種不同資訊。前者用來持續取得一組項目，後者通常只描述單一伺服器。把單一節點連結填入訂閱更新欄位，可能會解析失敗；把訂閱內容當成單一節點匯入，也可能失去管理關係。新增來源前先確認內容類型，再選擇相應的匯入方式。測試成功後，記下來源用途與最近檢查結果即可，不要在公開筆記中保存含有存取憑證的完整網址。

自動更新需要可用的取得途徑

自動更新的前提是用戶端正在執行、工作排程能啟動、訂閱服務可連線，且請求使用的網路路徑正確。這不代表系統休眠或用戶端已關閉時仍會持續更新。設定更新間隔時，應考量服務提供者允許的請求頻率與實際需求，不要過度頻繁地重新整理。遇到暫時限流時，連續手動點擊只會增加請求。請先查看錯誤類型，稍後再試，並保留目前仍可用的伺服器項目。

若更新必須透過代理，請確保目前使用中的節點不會因等待這次更新而無法恢復。可以保留一個已驗證的備用來源，但仍須單獨測試，不能只因為項目出現在清單中就認定可用。若更新服務可透過直連網路存取，先測試直連路徑。重點是避免循環依賴：取得節點清單、解析代理伺服器與建立代理連線，不應互相等待尚未就緒的環節。

更新後要檢查實際變更，而不只是查看成功訊息。確認使用中的伺服器是否仍存在、名稱是否改變、協定參數是否被替換，以及篩選條件是否讓清單項目大幅減少。若服務提供者移除了某個項目，用戶端不一定會自動選擇符合原用途的替代目標，需手動重新選擇並建立新連線。長時間執行的應用程式也可能持續使用更新前的連線路徑，直到重新建立連線為止。

相同節點不代表重複項目可以任意刪除

不同訂閱可能出現相同的顯示名稱，也可能名稱不同卻指向同一服務。判斷是否重複時，應比對協定、伺服器位址、連接埠與傳輸設定，不要只看備註。即使技術參數相同，項目仍可能屬於不同管理來源；刪除後是否會在下次更新重新出現，也取決於訂閱管理方式。優先透過分組與篩選減少干擾，不要直接在大型清單中批次刪除尚未確認的項目。

手動調整的伺服器應與遠端訂閱項目分開管理。若確實需要修改傳輸參數，可在確認允許的前提下複製為手動項目，並清楚標示用途。遠端來源日後變更時，手動副本不會自動更新，需要自行重新確認。保留副本不是為了長期避開正確更新，而是讓測試變數更容易控制。測試完成後，請刪除不再使用的副本，以免日後誤選過期設定。

桌面版與手機版可以匯入相同來源，但不代表篩選規則、使用中的節點與分流設定會自動一致。v2rayN、v2rayNG、v2flyNG 對訂閱格式與參數的支援可能不同；同一項目在某個平台可用，也不代表另一平台完全相容。跨裝置排查時，先確認協定與傳輸條件一致，再分別驗證。不要傳送含驗證資訊的完整設定檔來比較介面，必要時只比對已去除敏感資訊的欄位名稱。

匯出備份前，先確認要包含哪些資料。伺服器設定、訂閱網址與驗證資訊都可能是敏感資料，備份檔應儲存在存取受控的位置。還原至其他裝置後，也要重新檢查本機監聽連接埠、網卡權限與系統代理狀態，因為複製訂閱無法還原這些環境資訊。清理舊裝置時，也應移除不再需要的設定，避免帳戶資訊長期留在未使用的用戶端目錄中。

自訂出站與設定範圍

出站標籤是路由的連線依據

出站用來描述連線如何離開核心，路由則透過標籤選擇相應出站。標籤只是本機引用名稱，不會自動辨識協定或地區。名稱寫成「direct」，不代表實際一定直連；真正行為取決於該物件的協定與設定。新增出站前先列出現有標籤，確認沒有重名，也確認路由指向的是預期物件。標籤拼錯可能導致設定檢查失敗，或使預期路徑無法建立。

一般用戶端設定通常已建立代理、直連與封鎖等出站。若只是想讓某個網域改走直連，優先新增路由規則，不必再建立功能相同的出站。自訂出站適合確實需要不同連線方式的情況，例如將特定流量轉交給受控的本機代理服務。即使如此，也要先確認用戶端是否支援合併自訂欄位，以及切換節點時是否會覆蓋手動修改。

先從清楚的基本物件了解結構

以下範例呈現直連與封鎖出站的基本物件結構，適用於支援這些協定的核心。範例不含代理伺服器，也不是可直接取代用戶端設定的完整檔案。若現有設定已有相同標籤，不要重複新增。還要留意，未符合路由規則的流量可能使用第一個出站；因此不要直接以範例陣列取代原設定，否則預設路徑可能從代理變成直連。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

封鎖出站通常用來明確拒絕特定連線，不是用來修復網路問題。測試期間若將範圍過大的網域或位址集合交給它，可能造成網頁資源缺漏，看起來像是隨機故障。使用時先測試單一目標，再擴大比對範圍。直連出站同樣不保證能繞過所有系統設定，仍會受到作業系統路由、防火牆與底層網路條件影響。核心成功選擇出站，只代表已完成路徑判斷。

連接其他本機代理時避免自我循環

若需要透過另一個本機代理轉送，先確認該服務正在監聽，並核對協定、位址、連接埠與驗證要求。監聽位址是本機迴路位址還是區域網路位址，會決定哪些裝置能連線。不要為了方便就將監聽範圍擴大至所有網路介面。若確實需要區域網路存取，也要一併設定系統防火牆與存取控制，避免將僅供本機使用的入口暴露給無關裝置。

最常見的錯誤，是自訂出站又連回目前用戶端自己的代理監聽入口。連線進入用戶端後再次選擇相同出站，就會形成循環。連接埠相同不一定代表服務相同，因此應核對監聽程序與完整處理路徑。採用多層代理時，先畫出每一跳，釐清哪一層負責網域解析、哪一層處理 UDP，以及由哪一層建立最終連線；鏈路越長，就越需要逐跳驗證。

不同代理協定處理網域、UDP 與驗證的方式各不相同。上游支援一般網頁代理，不代表它支援所有應用程式流量。若本機上游只接受特定類型的請求，就應將路由範圍限制在已驗證的用途。也不要將其他元件的出站物件直接貼進目前核心；欄位名稱相似不代表設定格式相容。先確認核心名稱與文件說明，再透過設定檢查與啟動記錄確認是否正確接受。

用戶端切換伺服器、更新訂閱或修改路由後，可能會重新產生執行設定，因此手動新增至暫存檔案的出站可能消失。請優先使用用戶端明確支援的自訂設定入口，並記錄合併方式是新增物件還是取代整個欄位。若使用完整自訂設定，選擇使用中伺服器等圖形介面功能也可能不再依一般模式運作。設定前先確認這些限制，避免介面看似切換成功，實際上仍在使用固定設定。

驗證自訂出站時，先只讓一個測試網域符合規則，查看記錄中的標籤與上游連線狀態，再逐步擴大範圍。若失敗，依序確認目標規則是否命中、上游監聽是否可連線、驗證資訊是否正確，以及網域能否解析。不要同時調整所有層級。復原時先撤銷測試路由，再移除不再引用的出站，最後確認預設代理與直連規則仍維持原本的順序與行為。

設定驗證、故障排查與復原

分開驗證「能啟動」與「符合預期」

設定檢查通過，只代表結構與部分欄位符合核心要求，不代表訂閱服務可連線、代理節點可用或分流結果正確。完整驗證應依序檢查用戶端啟動、核心執行、入站接管、路由比對、解析路徑與實際服務。每個層級都需要各自的驗證依據，不能用一次網頁連線成功取代所有檢查。TUN 與 FakeDNS 尤其涉及系統狀態與執行期間的對應資料，更需要逐層確認。

開始修改前，先記錄一組基準狀態：使用的用戶端與核心、目前使用的伺服器、系統代理狀態、TUN 狀態、路由模式，以及一個已知可存取的測試目標。記錄設定名稱與行為即可，不必公開伺服器位址或驗證資訊。為這次修改寫下明確目標，例如「讓指定網域直連」。目標越具體，越容易驗證；「整體最佳化網路」範圍太廣，難以判斷修改是否有效。

依問題症狀選擇最精簡的排查方式

用戶端無法啟動時，先處理執行環境、目錄權限與設定讀取問題，不要繼續調整 DNS。用戶端能啟動但核心隨即結束時，查看最近修改的欄位、標籤與連接埠占用情況。核心正常運作，但應用程式完全沒有走代理時，檢查系統代理、應用程式設定或流量接管範圍。只有流量已進入核心，分析路由與出站才有意義。先將問題定位在正確層級，通常比一次重新安裝所有元件更有效。

延遲測試與實際連線測試也要分開判讀。某項測試可能只探測特定目標，並使用特定請求方式，不能代表所有協定與服務。測試成功後，還應存取實際需要的目標，並確認出口與路由符合預期。若只有單一網站失敗，先檢查該網站使用的附屬網域與連線類型，不要立刻判定整條代理鏈失效。頁面主體能顯示，但圖片或登入失敗時，通常需要檢查不同資源的分流方式。

閱讀記錄時，從時間與單次請求開始。先記下測試發起時間，再查找相應的目標、入站與出站標籤。解析失敗、連線遭拒、連線逾時與驗證失敗分別指向不同問題。連線遭拒通常表示對端明確拒絕，或該連接埠沒有服務；逾時則可能與連線路徑、防火牆或遠端回應有關。若記錄資訊不足，可暫時提高詳細程度，排查完成後再恢復，避免長期累積敏感目標資訊。

復原也要依依賴順序進行

若這次修改涉及多個層級，先停止建立新的服務連線，再撤銷最外層的流量接管或新增規則，接著還原 DNS 與出站基準設定。關閉 FakeDNS 時，依前文同步處理對應設定與應用程式快取。TUN 異常時，先恢復一般系統網路，再驗證用戶端代理。不要在保留錯誤接管狀態的同時反覆更換伺服器；這樣不但無法恢復連線，也會增加新的變數。

復原後必須重新測試，不能看到開關關閉就算完成。確認用戶端已停止相關核心，或重新載入正確設定；系統代理應指向目前仍在監聽的入口，且一般網頁與區域網路存取都已恢復。若用戶端關閉後仍殘留代理設定，請檢查系統網路設定，不要再啟動第二個用戶端來掩蓋舊入口。只有基準狀態恢復可用後，才適合重新加入剛才失敗的設定，並將修改範圍縮到最小。

若需要進一步求助，請提供用戶端名稱、平台、使用的核心、最小重現步驟，以及已去除敏感資訊的錯誤摘要。請勿直接傳送訂閱連結、驗證欄位、完整伺服器設定或含私人網域的記錄。截圖前先檢查網址列、QR 碼與剪貼簿提示。用戶端啟動後立即結束的排查方式請參閱v2rayN 無法開啟與閃退處理，不要把啟動問題和連線問題混為一談。

穩定的設定應該容易理解、驗證與復原。保留必要的訂閱分組、明確的路由順序與適合目前網路的解析路徑，比不斷增加開關更容易維護。新裝置可從快速入門主流程重新建立連線，再移轉已理解的規則；遇到術語疑問可查閱概念速查。每次只增加一層功能，確認效益與限制後再保留，這份指南才能成為可重複使用的操作依據。