V2Ray 進階設定手冊

訂閱分組與伺服器篩選

分開管理訂閱網址與連線設定

在 v2rayN 開啟「訂閱分組設定」，先建立獨立分組，再填入訂閱網址。分組用來保存更新來源、備註與篩選條件；伺服器項目則保存匯入後的通訊協定參數。修改分組備註不會變更遠端連線資訊；更新訂閱也不代表切換目前使用的伺服器。更新完成後，仍須確認主視窗目前選取的是哪筆記錄。

命名分組時，請使用用途與來源說明，例如「日常使用」或「相容性測試」。不要將訂閱網址寫進備註、截圖或共用文件。網址中的路徑與查詢參數可能具有存取授權功能。排查問題時，只記錄網址類型、回應狀態與錯誤訊息，並隱去具體內容；複製網址時保留原有編碼，不要自行刪除看似重複的參數。

首次更新時先關閉篩選條件，確認能取得伺服器清單，再逐步加入限制。分別判斷「網址回應內容為空」與「有內容但遭篩除」：前者應檢查訂閱是否有效、網路是否連通及回應格式；後者則檢查篩選運算式。反覆重新整理無法修正錯誤的篩選條件，還可能掩蓋真正的回應資訊。

依欄位與比對方式縮小範圍

使用伺服器篩選前，先查看設定項目說明：比對的是伺服器備註、通訊協定類型，還是其他欄位；運算式採一般文字、包含比對，還是正規表示式。不同介面不可假設規則相同。若欄位明確支援正規表示式，可用下方運算式比對備註中的測試或備援標記；它只是比對條件，是否保留這些項目仍取決於篩選選項的定義。

(測試|備援)

一開始不要組合複雜的排除條件。先用一筆已知備註測試，再測試另一筆不應比對的備註，最後檢查空白備註。正規表示式中的括號、直線符號與句點都有特殊意義；若要比對句點字元本身，須在前面加上反斜線。是否區分大小寫，應以目前欄位的實際行為為準，不能只憑介面顯示的字母大小寫判斷。

若不同訂閱來源採用不同命名方式，建議分別設定各分組的篩選條件，不要把所有名稱塞進同一個運算式。遠端調整備註後，舊條件可能突然篩掉所有項目。更新前記下至少一個應保留的名稱特徵，更新後確認它是否仍存在。不要只憑清單數量變化判斷服務是否異常，來源本身也可能調整內容。

處理更新覆寫與連線參數差異

訂閱項目通常會由遠端資料重新產生。若需長期修改傳輸參數，先確認用戶端是否提供獨立儲存或複製為手動項目的功能；複製後請移至獨立分組，並清楚標示它不會再自動套用訂閱更新。不要直接修改訂閱項目後，就認定下次重新整理一定會保留變更。先進行一次受控更新，觀察欄位是否遭到覆寫。

遇到「匯入成功但無法連線」時，請核對通訊協定、伺服器位址、連接埠、傳輸方式及 TLS 相關欄位。匯入成功只表示用戶端能辨識格式，不代表目前核心支援所有功能。v2rayNG 與 v2flyNG 使用的核心家族不同，不能只因介面相似就互換設定。先確認通訊協定需求，再決定使用哪個用戶端。

訂閱更新失敗時，先保留目前仍可用的設定，不要立刻清空所有分組。依序檢查網址是否完整、系統時間、憑證錯誤，以及更新是否經由代理。詳細排查步驟請見v2rayN 訂閱更新失敗排查。修正來源後再恢復篩選條件，避免同時變更網址與篩選邏輯。

最後進行一次最精簡的驗證：更新一個分組、選取一筆用途明確的項目、啟動核心，再確認記錄檔沒有設定解析錯誤。驗證通過後再啟用自動更新。如此可將訂閱格式、篩選條件與連線參數三類問題分開，避免一次大量操作就失去可用的基準設定。

DNS 設定最佳化

先釐清實際解析鏈

請從應用程式、作業系統、用戶端與遠端出口等位置檢查 DNS。瀏覽器可能啟用自己的安全 DNS，系統可能使用區域網路解析器，核心可能維護獨立快取，代理伺服器也可能負責解析最終目標。修改「DNS 設定」只會影響由該設定接管的查詢，不能假設所有應用程式都會立即改用新的伺服器。

先確認應用程式交給代理的是網域還是位址。使用支援遠端解析的代理方式時，應用程式可以將網域交給代理；若應用程式先自行解析，再將位址交給用戶端，網域分流就可能缺少原始資訊。此時應檢查應用程式的代理選項或接管方式，不能只靠新增一條網域 DNS 規則就還原所有資訊。

區分兩種關鍵查詢：代理伺服器本身位址的解析，以及服務目標的解析。前者發生在建立代理連線之前，必須有能獨立運作的路徑。若唯一的引導解析器設定為「代理建立後才能存取」，就會形成啟動循環。設定網域形式的加密解析服務時，也要考慮最初如何解析該服務名稱。

依用途指派解析器

以下是內建 DNS 的簡化設定片段，適用於支援這些欄位的 V2Fly 或 Xray 設定。範例使用公共解析器處理一般查詢，並將本地域名交由系統解析。此範例用來說明網域條件與查詢策略，不代表公共解析器在所有網路環境中都能連線；實際使用前請依網路需求替換，並確認用戶端是否會覆寫這部分設定。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      "1.1.1.1",
      {
        "address": "localhost",
        "domains": ["domain:localhost"]
      }
    ]
  }
}

內網服務通常仰賴區域網路 DNS 中的私有記錄。若將所有查詢送往公共解析器，這些記錄可能不存在，或回傳不適合目前網路的位址。請為企業內部網域、路由器管理名稱與自架服務保留明確的本地解析路徑。不要將所有單標籤名稱都視為公共網域，也不要為了處理一個內部名稱就關閉整套 DNS 分流。

解析器的傳輸方式與查詢實際路徑是兩回事。使用加密 DNS 可保護相應的傳輸鏈路，但流量是否經過代理，仍取決於核心實作、出站規則與用戶端產生方式。部分本地解析模式可能會略過一般路由處理；確認實際行為時，請查看執行設定與連線記錄，不要只根據位址字串是否包含加密協定來判斷路徑。

「預期位址」一類條件用來判斷回應結果是否符合規則預期，不應視為通用的加速開關。啟用後若合法回應遭到拒絕，可能觸發回退查詢，反而增加排查難度。先確認基本解析成功，再加入結果限制；每增加一層條件，都應保留一個可供對照的網域及其預期解析範圍。

分別驗證位址族與快取

同時支援 IPv4 與 IPv6 的網路，必須分別檢查解析與連線。取得 IPv6 位址不代表目前出口有可用的 IPv6 路徑。若記錄檔顯示選取位址後連線失敗，請檢查系統路由與出口支援，再決定是否調整查詢策略。直接刪除所有 IPv6 設定只能暫時改變症狀，不能證明 DNS 服務原本有問題。

更換解析器後，瀏覽器、系統與核心可能各自保留快取。測試時請關閉舊連線、重新啟動測試應用程式，並視需要清除相應快取。不要同時更換伺服器與查詢策略，否則無法判斷結果變化的原因。系統查詢工具可以驗證系統解析鏈，但不一定會使用核心內建 DNS，因此與瀏覽器結果不同，不一定代表設定未生效。

排查時保留一條簡單的解析路徑作為對照。先關閉複雜的回退與結果篩選，確認基本查詢可完成，再逐步恢復網域分類、位址族偏好及加密傳輸。若本地名稱正常但外部名稱失敗，請檢查外部解析器是否可連線；若查詢完成但目標無法連線，請回到路由章節檢查出站，不要繼續增加解析伺服器。

最後檢查 DNS 記錄對隱私的影響。除錯記錄可能包含完整的瀏覽網域，長期保存會形成詳盡的活動紀錄。驗證完成後，請恢復日常記錄層級；分享錯誤資訊時，隱去內部名稱及訂閱關聯資訊。DNS 最佳化的目標是讓路徑明確、結果可解釋，而不是盡可能增加上游伺服器。

FakeDNS

了解虛擬位址與網域對應

FakeDNS 不會直接回傳目標的真實位址，而是從專用位址池配置虛擬位址，並保存網域與位址的對應關係。應用程式接著連線至該位址時，接管元件會透過對應資料還原原始網域，再進行路由與出站處理。它主要用來解決以位址形式傳送的流量無法辨識網域的問題，並不是能獨立取代完整 DNS 解析鏈的公共解析服務。

設定是否有效取決於整個流程能否閉合：查詢必須進入 FakeDNS，回傳的虛擬位址必須由同一套接管鏈接收，對應資料必須仍然存在，入站也必須正確還原網域。任何一環缺失，都可能出現「解析有結果卻完全無法開啟」的情況。因此，請先驗證一般 DNS 與 TUN，再加入 FakeDNS，避免在尚未穩定的接管鏈上又增加位址對應。

不要將路由中的虛擬位址直接送往真實網路。它們不是目標伺服器的位址，通常也無法在一般網路中連線。若記錄檔持續嘗試連線至位址池中的位址，請優先檢查對應還原與接管範圍，而不是尋找能連線至該位址的代理伺服器。只有還原原始網域後，後續網域規則與遠端解析才會取得正確輸入。

確認核心支援與入站設定

以下說明支援 FakeDNS 的 Xray 設定要素，分別對應位址池、DNS 伺服器與目標入站的嗅探物件。這些設定必須合併到同一份實際執行設定中的正確位置，不是三個可任意追加的頂層物件。若用戶端已產生這些設定，請使用對應選項，避免重複宣告或覆寫其他必要設定。

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

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

第二段是入站內部的 sniffing 物件，不應直接拿來取代完整入站設定。若目前入站還需要 HTTP 或 TLS 嗅探，請依核心文件合併清單，不要直接刪除原有內容。不同核心對虛擬位址與嗅探的實作可能不同；在 v2flyNG 中操作前，請先確認使用的核心與用戶端確實支援相關功能。

範例位址池使用虛擬用途網段，但仍須檢查本機與所在網路是否已使用該網段。實驗環境、其他代理元件或網路測試工具可能使用相同網段。位址重疊會使路由用途變得不明確。不要任意挑選看似閒置的公網網段；若用戶端允許修改，請遵循該實作的位址池要求，並同步檢查路由排除項目。

位址池容量會影響可保留的對應數量，不等於可連線的伺服器數量，也不是速度參數。容量過小時，網域較多可能更快淘汰舊對應；任意擴大則可能增加資源使用量。先採用實作提供的合理預設值，只有記錄與重現結果顯示對應遭淘汰時才調整，不要只因某個應用程式開啟緩慢就認定容量不足。

處理快取與繞過接管的應用程式

啟用或停用 FakeDNS 後，應用程式與系統可能繼續使用舊快取。若應用程式仍持有虛擬位址，而對應資料已因重新啟動而消失，就可能間歇性連線失敗。測試切換時，請關閉相關應用程式連線、清除相應解析快取，再重新送出要求。不要只重新啟動核心，卻讓瀏覽器長時間重用先前的位址與連線，否則新舊狀態會混在一起。

應用程式內建的加密 DNS 可能繞過預期的查詢入口；固定位址存取則根本不會進行網域查詢。這兩類流量無法自動取得 FakeDNS 對應。處理前請先確認應用程式的實際行為，再決定是否調整應用程式 DNS、代理方式或接管範圍。不能因為其他應用程式正常，就認定異常應用程式使用了相同的解析鏈。

請為區域網路名稱及依賴真實位址的應用程式保留一般 DNS 路徑。有些服務會將解析結果傳給另一個未受接管的程序，而該程序可能無法使用虛擬位址。遇到這類情況時，應為目標名稱設定明確的解析例外，而不是擴大虛擬位址在系統中的可見範圍。跨程序傳遞位址的行為須配合應用程式架構判斷。

復原時依序恢復一般解析、停用虛擬位址對應，再清除舊快取並重新建立連線。若復原後仍存取虛擬位址，請先處理快取殘留，不要繼續修改伺服器設定。FakeDNS 的用途是保留可供路由使用的網域資訊；若一般網域入站已能滿足需求，就不必為了增加設定複雜度而啟用它。

自訂出站

以標籤連結路由與出口

出站定義連線如何離開核心，路由則透過標籤選取出站。標籤只是設定內部的參照名稱，本身沒有特殊功能。將出站命名為 direct，不會自動讓它直連；真正決定行為的是通訊協定及其設定。請先檢查出站物件，再檢查路由參照；拼字一致只是設定正確的必要條件，並非充分條件。

圖形用戶端通常會產生對應目前伺服器的代理出站，以及直連與阻擋出站。需要新增自訂物件時，先確認用戶端提供的是「附加片段」、「取代完整設定」，還是專用的自訂設定入口。將局部片段匯入完整設定入口會缺少入站等必要部分；反過來，將完整設定放進附加區域也可能造成重複定義。

以下是原生 V2Ray 或 Xray 設定中常見的直連與阻擋出站片段，可用來理解標籤結構。合併前請檢查是否已有相同標籤。範例未提供代理伺服器的驗證資訊，也不是完整的用戶端設定；代理出站應由已驗證的伺服器項目產生，避免手動撰寫時遺漏傳輸與安全參數。

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

先測試單一路由，再增加組合

新增出站後，先用一條明確且範圍較小的規則參照它。選擇可控的測試目標，確認核心能啟動、標籤存在、規則符合後，再考慮擴大範圍。不要直接取代所有預設流量；設定一旦有誤，所有應用程式同時失敗會減少對照資訊，也可能讓訂閱更新與求助頁面一併失去連線。

直連出站同樣會受到解析與系統網路設定影響。直連不代表略過防火牆，也不保證使用特定實體介面。若需繫結介面或指定傳送位址，請確認目前核心提供相應選項且具備系統權限，並驗證該位址屬於本機。複製另一台裝置的介面名稱或位址，通常只會造成連線失敗，不會得到相同的路徑。

代理鏈不等於設定多個代理出站。只有明確設定轉送關係，連線才會經過多個階段；一般路由通常只會選取其中一個出口。建立鏈路前，先確認各階段都能單獨運作，再確認每一段的網域解析、傳輸協定與驗證要求。任何一段失敗都會影響整條鏈，記錄也須按階段查看，不能只看最後的逾時訊息。

特別留意 UDP 與多工行為。某個出站能承載網頁連線，不代表適用於所有資料包流量；某個協定支援多工，也不表示啟用後對所有應用程式都有幫助。先保留預設設定，只有明確觀察到連線建立成本或相容性問題時，才進行對照測試。不要把 Mux 當成無條件的加速開關，也不要混用不同核心的多工欄位。

處理預設出站、迴圈與相容性

若沒有明確設定兜底規則，預設出站可能受物件順序影響。插入新物件後，即使原有規則沒有變更，未符合規則的流量也可能改走其他路徑。修改前先記錄預設行為，修改後再專門測試一個不會符合前置規則的目標。若要穩定表達預設意圖，請使用目前核心支援的兜底方式，不要依賴偶然的排列順序。

避免出站互相參照形成迴圈，也要避免出站連線再次被本機代理入口接收。前者發生於核心設定的轉送關係中；後者可能來自系統代理、TUN 或應用程式代理設定。兩種情況都可能表現為連線重複建立與逾時。排查時先畫出每一步的下一個連線目標，直到實際網路出口；任何回到起點的箭頭都必須釐清原因。

切換核心前先儲存設定，並逐項核對通訊協定、傳輸、安全選項與資源格式。V2Fly 與 Xray 共用部分設定概念，但並非所有擴充功能都相容；v2rayNG 與 v2flyNG 也不能只因名稱相近，就視為相同的執行環境。若核心回報未知欄位，請依實際支援範圍修正，不要只刪除錯誤行，卻忽略它原本負責的功能。

維護自訂設定時，請在外部記錄每個標籤的用途，避免在嚴格 JSON 中加入註解而造成解析失敗。儲存前檢查括號、逗號、字串引號與重複鍵。每次只修改一個邏輯單元，成功啟動後再驗證網路；語法正確不代表出口可連線。若要重新選擇用戶端，請返回下載頁確認平台與核心用途。

撤銷自訂出站時，先移除或改寫參照它的規則，再刪除出站物件，最後檢查預設路徑。只刪除出站卻保留標籤參照，會讓設定在啟動或比對階段失敗。復原完成後重新建立測試連線，並確認用戶端已重新採用預期的設定產生方式，避免介面看似復原，執行檔仍停留在舊狀態。