v2rayN 進階設定指南

訂閱分組與伺服器篩選

訂閱分組用來管理來源與更新方式，伺服器項目則儲存個別連線參數，兩者屬於不同層級：修改分組備註不會改變通訊協定，切換目前使用的伺服器也不會更新訂閱。先整理好來源，再進行篩選與選擇，可避免把「清單變動」誤判為「連線故障」。建議依用途或來源命名分組，備註中不要填入密碼、存取權杖或個人帳號。

建立分組，再確認更新結果

在 v2rayN 的訂閱分組設定中新增分組，填寫備註與訂閱網址，儲存後更新該分組。網址務必完整，尤其不可漏掉問號後的參數；從聊天視窗複製時，也要留意結尾的空格、換行與標點。更新後先檢查該分組的伺服器清單，再選擇要使用的項目。新增分組只會儲存來源，不代表內容已下載並解析。

訂閱更新是獨立的請求路徑。有些網路環境可直接連線至來源，有些則需要透過已可用的代理更新；請分別嘗試這兩種方式，不要反覆切換連線參數。若清單是空的，先查看更新記錄中的回應狀態與解析提示。若回傳的是網頁、登入頁面或存取錯誤，即使網路請求成功，也無法取得有效伺服器資料。檢查來源是否仍有效，比重新安裝用戶端更切中問題。

篩選只決定顯示範圍，不會改變通訊協定能力

伺服器篩選通常會比對備註文字，實際入口可能位於分組設定或清單篩選區。初次使用時先輸入一個明確關鍵字，確認預期項目仍會顯示，再逐步增加條件。篩選欄位可能接受一般文字或正規表示式，請依欄位提示操作。別把清單搜尋當成訂閱篩選：搜尋通常只會暫時改變目前檢視畫面，而更新篩選可能會決定哪些項目保留下來。

支援正規表示式的欄位可用以下模式理解比對範圍。直線符號代表符合任一詞，行首符號用來限制備註開頭，負向前瞻則可排除特定詞。備註規則由來源自行決定，文字標籤不能證明連線能力；備註中含有某個通訊協定名稱，也不代表實際參數就採用該協定。請先檢查項目的通訊協定、傳輸與安全性欄位，再確認所選核心是否支援。

辦公|備用
^辦公
^(?!.*測試).*$

手動修改與訂閱更新分開處理

訂閱提供的項目可能會在更新時重新建立。修改這些項目的位址、連接埠或安全性參數後，下次更新可能會覆蓋修改，也可能留下重複項目。若要長期保留實驗設定，請複製到獨立的手動分組，並在備註中說明修改原因。如此既能持續接收來源更新，也能清楚區分服務端提供的資料與本機測試資料。

Android 用戶端也應先建立容易辨識的訂閱分組，再執行更新並確認結果。v2rayNG 與 v2flyNG 的分組介面和篩選功能不一定完全相同；若沒有專用的篩選入口，請使用分組選擇或清單搜尋，不要硬套桌面版操作步驟。成功匯入只代表格式已辨識，核心是否接受通訊協定欄位，仍須透過啟動記錄與實際請求驗證。

簡單記錄每次更新的結果：來源名稱、使用的更新方式、結果是否正常，以及篩選條件是否變更。若更新後項目突然減少，先暫時清除篩選條件再重新整理；若項目恢復，問題就在篩選條件，而非核心。若仍無法解析，請前往連線驗證與復原，分別檢查訂閱請求與伺服器連線。不要反覆匯入同一個網址，以免產生重複分組。

路由規則實例

路由會接收已進入核心的請求，再決定使用哪個出站；系統代理開關則決定應用程式是否將請求交給本機代理。若應用程式完全繞過入口，修改路由就不會生效。開始編寫規則前，請先確認應用程式流量確實進入用戶端，再確認產生設定中的代理、直連與封鎖標籤；不要只憑介面名稱推測實際標籤。

依照首個符合規則的原則安排順序

一般欄位規則會依序比對，第一條符合的有效規則決定流量出口。將明確的例外放在前面，較廣泛的地區或類別規則放在後面。例如，某個測試網域需要走代理，即使它也屬於後面的直連清單，仍應先設定代理規則。多條獨立規則不會累加投票；同一條規則填入多個不同欄位時，通常必須同時符合所有欄位。

以下範例是可嵌入 Xray 設定的路由物件。它會先代理指定網域及其子網域，再讓私有位址與中國大陸位址直連，最後依所用的網域清單比對直連請求。範例假設已存在標籤為 proxy 與 direct 的出站，而且核心能讀取所需的規則資料。實際用戶端產生的標籤可能不同，使用前務必確認。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:private", "geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

區分網域比對、位址比對與解析策略

full:example.com 只會比對完整網域；domain:example.com 也會包含其子網域。未加前綴的網域文字可能以包含關係比對，容易擴大範圍；若要明確界定範圍，建議使用前綴。正規表示式適合有明確命名規律的網域，不適合取代所有一般規則。規則越複雜，排查時越難判斷究竟是哪個條件符合。

位址規則比對的是請求的目的位址，不會自動理解網域背後的服務意義。IPIfNonMatch 會在網域規則未符合時嘗試解析，再進行位址比對，因此會依賴 DNS。若應用程式只提交位址，核心也不一定知道原始網域。流量嗅探可從部分通訊協定取得網域線索，但並非適用於所有流量，不能把它當成可靠的網域還原工具。

驗證規則，不要只看網頁能否開啟

新增規則後重新啟動或載入核心，確認記錄中沒有未知標籤、欄位錯誤或規則檔案遺失。接著以單一目標發出新請求，查看存取記錄中的出口資訊。瀏覽器可能重複使用既有連線，修改規則後，舊連線仍可能沿用原本路徑；關閉相關分頁或重新建立連線，可避免誤以為規則失效。

若沒有任何規則符合，一般設定會使用預設出站，通常是出站清單中的第一項。因此，預設出口也是路由設計的一部分，不可忽略。使用封鎖規則排查時，只限制一個明確的測試目標，並預先準備復原方式。直接封鎖大類流量，可能同時影響 DNS、訂閱更新與連線建立，讓原本單純的比對問題變得更加複雜。

用戶端預設路由與自訂規則可能會一併參與設定產生。儲存後請檢查實際生效的規則順序，不要只看編輯視窗中的排列。若需要更詳細的語法對照，請閱讀自訂路由規則寫法；若要了解入口與模式的分工，請閱讀系統代理與路由模式比較。測試期間一次只移動一條規則，並保留可復原的順序。

DNS 設定最佳化

設定 DNS 前，首先要釐清「由誰負責解析」。瀏覽器、作業系統、用戶端核心與遠端出口都可能參與網域解析。只更換用戶端 DNS，不一定會改變瀏覽器的加密 DNS，也不一定會更新系統快取。最佳化時應從請求路徑著手：先確認應用程式提交的是網域還是位址，再確認哪個環節查詢上游，最後檢查 DNS 請求從哪裡出站。

分開處理目標解析與連線位址解析

瀏覽目標網站時的解析，與連線至伺服器位址時的解析，雖然都使用 DNS，負責的工作卻不同。若伺服器欄位填的是網域，建立代理連線前可能就需要先解析；此時若唯一解析路徑是尚未建立的代理，就會形成循環依賴。較穩妥的做法是先確保伺服器位址可透過基礎網路解析，再設定目標網站的分流解析。

用戶端中的「遠端 DNS」、「直連 DNS」等選項，通常是設定產生器提供的抽象選項，不一定與核心欄位一一對應。修改時請查看欄位說明，並確認產生出的設定。Android VPN 模式可能會提供專用的 DNS 入口，桌面系統代理則不一定會接管所有 DNS 請求。瀏覽器可以上網，不代表整個系統都使用同一條解析路徑。

先設定容易理解的上游與策略

以下示範 Xray 內建 DNS 的基本物件：為指定網域清單設定一個上游，其餘請求交由另一個上游處理。UseIP 允許回傳兩種位址，但實際結果仍取決於上游與網路環境。範例中的公用解析位址僅用來說明欄位，不代表適用於所有網路；請先確認目前的連線環境可以連線，再加入設定。這些查詢的出口仍須另外透過路由物件安排。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "1.1.1.1"
    ]
  }
}

網域條件只是選擇上游的依據之一，不代表所有回退請求都會受到嚴格隔離。部分上游失效時，核心可能會繼續嘗試其他伺服器；是否要限制回退，須依目前核心支援的欄位判斷。為了形式上的分流而關閉所有回退，可能使短暫的上游故障演變成所有網域都無法解析。請先確認基本查詢成功，再逐步收緊範圍。

加密解析仍須確保出口正確

使用加密 DNS 可以改變傳輸方式，但無法自動解決上游無法連線或連線循環問題。使用 HTTPS 上游時，還需要處理上游主機名稱的初始解析、連線位址、憑證驗證與路由。將加密上游設定為代理出站之前，請確認代理本身不依賴這條解析鏈。若應用程式也啟用了自己的加密 DNS，用戶端的網域清單規則可能只能看到解析後的位址。

排查位址家族問題時，請分別確認網路是否支援 IPv4 與 IPv6。只回傳其中一種位址，可以暫時縮小問題範圍，但並非通用的效能最佳化。若系統取得 IPv6 位址卻沒有可用出口，應用程式可能會先嘗試無法連線的路徑；若服務只提供 IPv6，強制使用 IPv4 則會直接失敗。請保留原本策略，每次只變更一項查詢設定，再比較結果。

快取可能會讓設定變更延遲生效。測試前請重新建立應用程式連線，必要時依作業系統提供的方式清除 DNS 快取，但不要把清除快取當成長期解決方法。命令列的系統查詢通常只會測試系統解析器，不會自動經過核心 DNS；須搭配核心記錄，才能確認新設定是否處理了該請求。請記錄測試網域、回傳位址與出口資訊，不要只憑「開啟速度」判斷。

最終設定應能清楚說明每類查詢的去向，而不是堆疊多個解析服務。若加入 TUN 或 FakeDNS，解析入口與回傳結果都會改變，請接著閱讀相關章節。出現解析錯誤時，先改回單一且可連線的上游，確認基本連線恢復，再逐步加入分流、加密與快取設定。如此才能區分上游、路由與流量接管問題。

TUN 模式

TUN 會透過虛擬網路介面接收由系統路由導入的 IP 流量，適合不遵循系統代理設定的應用程式。它會擴大流量接管範圍，但不等於修改系統代理開關，也不代表所有請求都必須使用代理出口。流量進入接管元件後，仍須由路由規則決定直連、代理或封鎖。啟用前請先透過一般代理入口確認目前伺服器可用，避免同時排查入口與遠端連線。

了解權限、路由與核心的分工

v2rayN 的 TUN 實作取決於用戶端整合的流量接管元件及其設定，不應將一般 Xray 設定片段視為通用 TUN 設定。建立虛擬介面、寫入系統路由與接管 DNS 是不同動作，其中部分操作需要提升權限。依照介面提示授予必要權限後，請確認記錄顯示介面已完成初始化；只有看到開關處於啟用狀態，並不足以證明路由已生效。

啟用前請記錄目前的預設路由、DNS 設定，以及其他正在執行的網路接管工具。多個元件同時修改預設路由，可能造成請求循環或出口衝突。測試時請保留一種接管方式，暫時停用其他會接管流量的程式。若需要存取區域網路裝置、共用資料夾或公司網路，請先記錄目標網段，避免啟用後無法存取設定入口。

避免代理連線重新進入接管路徑

代理連線本身必須能離開接管迴圈。若連往遠端伺服器的流量又被送回虛擬介面，核心就會不斷嘗試透過自身建立出口。用戶端通常會提供出口綁定、程序排除或路由例外等機制，實際採用哪一種取決於其實作。手動新增伺服器位址例外時，也要考慮網域解析結果會變動；若固定填入舊位址，來源切換後可能就會失效。

區域網路直連與系統路由排除也不是同一回事。路由中的直連出站會讓核心代為發起連線；系統排除則讓請求完全不進入核心。印表機探索、廣播與部分本機服務可能依賴後者，單純設定私有位址直連不一定能滿足所有需求。請先測試明確的本機位址，再測試探索功能，並依結果決定要調整哪個層級。

從最小接管範圍開始驗證

首次測試時使用預設且容易理解的接管設定，先開啟一個已知可存取的目標，再測試一個不遵循系統代理設定的應用程式。查看該應用程式是否確實出現在核心記錄中；若沒有記錄，應檢查系統路由與應用程式排除設定，而不是先更換伺服器。若已有記錄但連線失敗，再檢查出口與 DNS。若應用程式選擇功能同時提供包含與排除模式，請先確認目前模式的意思。

UDP、位址家族與 MTU 是常見的限制因素。網頁正常但部分即時應用程式失敗，可能與 UDP 轉送能力或防火牆有關；小型請求成功但大型傳輸停滯時，才需要進一步檢查路徑 MTU。不要隨意套用固定的 MTU 數值。請先透過記錄與網路診斷確認狀況，再小幅調整並比較結果。需要 ICMP 的功能也不一定會以與一般 TCP 相同的方式處理。

結束測試時，先關閉 TUN，再確認一般網路與區域網路是否恢復。若退出用戶端後仍有異常，請檢查虛擬介面、預設路由與 DNS 是否已還原；重新啟動用戶端並正常關閉流量接管，有時比直接結束程序更容易觸發清理。請勿在未記錄原設定的情況下刪除系統路由。若要長期啟用，請保留一般代理模式作為復原方案，並記錄必須排除的應用程式或網段。

FakeDNS

FakeDNS 會為網域指派一個內部使用的合成位址，核心之後會根據對照關係找回網域。它的用途是保留網域資訊，讓分流可依據網域判斷，而非單純加快公用 DNS 查詢。合成位址不是真實服務位址，不能脫離產生該位址的對照關係與接管鏈路使用。是否啟用，應視應用程式提交位址後遺失網域資訊的實際問題而定，不要把它當成預設的加速開關。

對照關係必須涵蓋解析與連線

正常流程包含三個環節：應用程式向已接管的 DNS 入口查詢，FakeDNS 回傳合成位址，應用程式連線至該位址時，核心再透過對照關係還原網域。若只啟用位址池，卻未將應用程式查詢導向相應入口，對照關係就不會生效；若只回傳合成位址，卻未接管後續連線，應用程式便會嘗試存取無法在公用網路使用的位址。因此 FakeDNS 常與透明接管搭配，但兩者仍須分別驗證。

以下是 Xray 的 FakeDNS 相關設定片段。fakedns 用來定義位址池，DNS 伺服器清單則會參照它。198.18.0.0/15 屬於測試用途的位址範圍，並非真實網站的位址。範例未包含接管入口與完整的嗅探設定，無法單獨構成可執行的方案；若 v2rayN 的接管元件自行實作合成位址機制，請使用該元件的欄位，不要混用另一套核心設定。

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

位址池大小與回收機制會影響對照關係的生命週期

位址池須有足夠的空間，且不可與現有網路重疊。企業網路或實驗環境可能已使用類似的測試位址，請先檢查路由表。位址池大小決定可維持的對照範圍，不是網路容量或連線速度指標。長時間執行後，對照關係可能會被回收，但應用程式仍保留舊快取；核心重新啟動後，對照關係也會重建，同一個合成位址可能因此對應到不同網域。

嗅探相關設定可協助核心取得網域資訊，但請區分讀取資訊與改寫目的地。FakeDNS 的對照還原，與從 HTTP 或 TLS 取得網域並不相同。若只啟用供路由使用的嗅探，是否符合目前組合的目的地還原需求，仍須確認接管元件的實作。建議優先使用用戶端已提供的配套選項，再從產生的設定確認它們是否都已生效。

為需要真實位址的情境保留例外

有些應用程式會把 DNS 結果交給另一個程序、存入設定，或使用回傳位址建立區域網路連線；這些行為可能讓合成位址脫離原本的接管路徑。遇到這種情況，請依網域或應用程式設定真實解析例外。區域網路裝置探索、依位址判斷的服務，以及需要與其他電腦共用解析結果的工作，尤其值得個別測試；不要一次將所有查詢都改成使用合成位址。

若應用程式內建加密 DNS，查詢可能不會經過 FakeDNS，結果仍會是真實位址；這不一定會導致連線失敗，但會改變網域規則的判斷條件。反過來說，若系統解析已取得合成位址，但應用程式連線被排除在接管之外，就可能直接失敗。測試時必須同時確認查詢入口與連線入口，不能只看 DNS 回傳內容就認定功能正常。

關閉 FakeDNS 後，請先讓應用程式停止使用舊結果，再重新建立連線；必要時清除系統與應用程式各自的 DNS 快取。否則，舊合成位址仍可能被使用，造成關閉功能後網路反而變差的錯覺。驗證復原時，請確認查詢結果已恢復為真實位址，並確認相同目標可透過原本的 DNS 與路由路徑存取。快取復原與核心復原應分開檢查。

只在確實需要保留網域資訊的範圍內啟用。個別應用程式發生異常時，先改用真實解析並比較結果，不要擴大位址池或不斷重新啟動。如果一般 DNS 與一般代理模式已足以滿足需求，就保留這個較簡單的方案。若要了解核心能力差異，請閱讀Xray 與 V2Fly 核心比較，避免將某種實作的欄位誤認為所有用戶端都支援。

多訂閱管理

多訂閱管理的重點在於隔離來源、追蹤更新與確認目前使用的伺服器，而不是把所有位址合併成一份大型清單。不同來源可能使用相同備註、不同通訊協定或不同更新週期，混在一起容易選錯項目。依來源建立獨立分組，再以用途備註輔助辨識，刪除、更新與故障復原時都能明確界定範圍。

區分來源資料與本機使用策略

來源資料包括訂閱網址、回傳項目與服務端參數；本機策略則包括分組備註、清單篩選、目前選擇與路由規則。請盡量不要把本機策略寫入會隨訂閱更新的參數。某個分組用於工作，只是管理上的約定，不會自動讓工作用應用程式使用該分組；應用程式與出口的對應，須透過路由規則或用戶端相關功能設定。

首次新增來源時，請先在獨立分組中更新並確認項目，不要立刻取代目前可用的伺服器。確認格式、核心支援狀況與連線路徑後，再決定是否納入日常選擇。若訂閱來源回傳的是用戶端設定而非伺服器清單，請依對應的匯入類型處理，不要反覆切換更新按鈕，試圖強行解析。更新記錄中的格式錯誤，應與網路逾時分開記錄。

讓更新排程與故障影響範圍一致

依不同來源設定合適的更新時間，避免短時間內重複請求。頻繁更新無法修復失效的存取憑證，反而可能觸發來源的存取限制。更新失敗時，先單獨更新該分組，不要一次重新整理所有來源；單一來源異常，通常不需要修改系統 DNS 或刪除其他分組。若所有來源同時失敗，再檢查共用的基礎網路與更新出口。

更新前請確認目前使用的項目來自哪個來源，更新後再確認選擇是否仍存在。來源刪除項目或調整識別資訊時，用戶端可能保留舊選擇、改選其他項目，或要求重新選擇；實際情況須透過清單與記錄確認。用戶端顯示「更新成功」只代表本次處理完成，不保證目前項目已切換至新參數，更不代表遠端連線已通過驗證。

去重時不能只看備註

備註相同的項目不一定相同；位址與連接埠相同，也可能使用不同的身分識別與安全性參數。去重前請比較通訊協定、位址、連接埠、使用者識別碼、傳輸類型與安全性欄位。不要為了讓清單整齊，手動刪除來源中所有相似項目；來源可能刻意提供不同的連線方式。若用戶端有去重功能，請先了解它會比對哪些欄位，並保留原分組以便復原。

備用來源應事先個別驗證，不要等主要來源故障時才第一次使用。測試時請明確切換目前使用的伺服器，再發出新的請求；只選取清單中的列，不一定代表已設為目前伺服器。多個來源本身不會自動故障轉移。若要自動選擇或負載平衡，必須使用明確支援的機制，並設定可用性判斷與出站；不要以為多個分組已組成自動切換的伺服器池。

跨裝置移轉時，請區分移轉訂閱網址與移轉完整用戶端設定。完整匯出檔可能包含本機監聽、路由、DNS 與裝置相關選項；直接複製到另一個平台，可能帶入不適用於新裝置的參數。一般建議先匯入來源，再依新裝置設定入口與路由，會更容易驗證。桌面版與 Android 版應分別確認核心支援狀況，避免某裝置可用的通訊協定組合移轉後無法啟動。

定期清理失效來源，但請先確認路由、固定出口或手動測試沒有依賴其中的項目。刪除分組前先記錄用途，並切換至可用伺服器，再執行刪除。若來源網址變更，請依提供者說明在原分組中更新，不要無限新增同名分組。訂閱更新失敗時，可返回訂閱分組章節檢查網址與篩選，再到分層排查確認更新路徑；不必把所有失敗都歸咎於伺服器。

自訂出站

出站是核心實際發起連線的方式，路由標籤則是請求出站時使用的參照名稱。自訂出站適合確實需要固定出口、局部封鎖或連線至本機代理的情況。一般使用者選擇一台伺服器並使用預設路由，通常已能完成基本操作；只有在能清楚說明新增出站的用途時，才需要編輯完整設定。設定越多，啟動檢查與復原記錄就越重要。

先確認編輯入口是否接受完整設定

v2rayN 的伺服器編輯、路由編輯與自訂設定入口各自處理不同層級。伺服器表單無法接收任意的頂層 JSON，路由編輯也不會自動建立出站。使用自訂設定前，請確認用戶端是直接載入該檔案，還是將片段合併至產生的設定。儲存在執行目錄中的檔案可能會在下次啟動時重新產生，請使用用戶端提供的永久設定入口，不要依賴暫時修改。

以下是僅監聽本機的完整 Xray 教學設定。它提供 SOCKS 入口，預設使用直連，並封鎖指定的測試網域。設定中沒有遠端代理伺服器，因此不能取代訂閱連線；用途是驗證入口、標籤與路由參照。範例所用的連接埠僅供示範，若已被占用，請同時修改設定與測試命令。未設定存取控制前，請勿將監聽位址改為所有網路介面。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "block"
      }
    ]
  }
}

標籤、預設出口與參照關係

每個需要被參照的出站都應有明確且唯一的標籤。路由中的 outboundTag 必須對應到實際存在的出站；大小寫或前後空格不符，都可能造成設定錯誤或運作結果與預期不同。沒有符合規則的請求通常會使用第一個出站，因此調整清單順序也會改變預設行為。分別記錄預設出口與例外出口，比只記下規則文字更可靠。

直連出站代表核心透過本機網路連線至目標，不代表請求從未進入用戶端；封鎖出站則會主動終止符合條件的流量。若要連線至另一個本機 SOCKS 服務，請明確確認其監聽位址、連接埠與驗證方式，並確保它不會將請求重新送回目前的入口。將同一個監聽連接埠同時當成入口與下游出口，是常見的循環設定錯誤；兩個服務也不可搶用相同的位址與連接埠。

遠端參數以服務端設定為準

新增遠端通訊協定出站時，除了位址、連接埠與身分欄位，還可能需要傳輸路徑、服務名稱、伺服器名稱或公鑰等參數。每個欄位都應與服務端設定相符，不可拼湊其他項目的欄位。REALITY 是一種傳輸安全方案，不能只將通訊協定名稱改為 REALITY 就啟用；相關參數說明請參閱REALITY 概念說明。

用戶端能顯示某種通訊協定，不代表所選核心支援所有安全性與傳輸組合。Xray 與 V2Fly 的支援範圍不同，Android 版 v2rayNG 與 v2flyNG 也不能視為欄位完全相容。載入設定前，請先確認核心選擇，再查看啟動記錄。若出現不支援某欄位的提示，請查明該欄位屬於哪種實作，不要不斷刪除安全性參數，只為勉強啟動設定。

設定鏈式代理前，須額外確認每一跳的建立路徑與解析路徑。外層出口尚未建立前，內層連線無法透過它；此外還可能遇到逾時、憑證與位址家族問題。首次設定時，請先讓各出口獨立運作，再透過核心支援的鏈式機制串接。介面上同時顯示兩台伺服器，不代表已組成鏈式代理，更不代表流量會自動依清單順序經過它們。

驗證自訂設定時，請依序確認核心啟動成功、入口可連線及單條路由正常。保留原本可用的圖形化設定作為基準；實驗失敗時切回基準設定，不要在故障狀態下繼續新增出站。查看記錄時，優先注意通訊協定欄位、標籤參照與監聽衝突，不必公開含身分欄位的完整檔案。掌握這三項關聯後，再考慮更複雜的出口組合，維護成本會更容易控制。

連線驗證與復原

排查連線時應沿著請求路徑進行：應用程式入口、本機核心、網域解析、路由出口、遠端交握與目標服務。不同錯誤發生在不同層，統稱為「伺服器壞了」會跳過最容易驗證的環節。請先選擇一個穩定且可重複測試的目標，記錄使用的用戶端、核心、入口模式與目前伺服器，再開始修改。每次只變更一個項目，才能找出是哪項設定讓連線恢復。

先確認本機入口與核心已啟動

核心啟動失敗時，系統代理可能已經設定，但應用程式仍無法連上本機監聽。請先查看記錄中是否有欄位錯誤、連接埠占用或權限不足，再確認監聽位址與連接埠。介面顯示的本機連接埠可能與自訂設定中的連接埠不同，請以實際執行設定為準。不要把 HTTP 代理連接埠當成 SOCKS 連接埠測試；兩種入口的交握方式不同，填錯可能會立即失敗。

使用以下命令可明確指定 SOCKS 入口，並讓網域解析透過代理路徑進行。此命令僅適用於裝置已提供 curl，且入口使用範例連接埠的情況；它無法驗證所有應用程式或 TUN 接管。若連線遭拒，請優先檢查本機監聽；若請求已進入代理但失敗，再查看路由與遠端記錄。測試網域只用來發出一般請求，不代表所有服務目標都有相同的網路條件。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

分別排查解析失敗與交握失敗

伺服器網域無法解析時，遠端交握尚未開始。請先檢查基礎 DNS、目前網路，以及是否形成代理解析循環。若可以解析但連線逾時，再檢查連接埠是否可連線、防火牆與來源狀態。逾時不代表通訊協定參數正確，只表示某個等待程序未能在期限內完成。若連線建立後立即中斷，則應優先檢查通訊協定、安全性與傳輸參數是否符合服務端設定。

遇到憑證錯誤時，請先檢查系統時間、伺服器名稱與憑證鏈，不要直接停用驗證來掩蓋原因。若傳輸設定使用路徑或服務名稱，大小寫、開頭斜線與空格都可能影響比對。REALITY 參數也須依來源逐項核對，不可借用相似項目的設定。公開排查資訊時，只保留錯誤類別與欄位名稱，並隱藏身分識別、位址權杖等敏感資料。

依功能反向撤除複雜設定

若問題是在剛啟用某項功能後出現，請先撤回該項設定。複雜組合可依序停用 FakeDNS、TUN、自訂 DNS 與自訂路由，逐步回到一般代理基準；每次復原後都應重新測試。關閉 FakeDNS 後還要處理舊快取，關閉 TUN 後則須確認系統路由已復原。只把介面開關切回原狀，不一定能清除先前連線與快取造成的影響。

訂閱更新失敗與網頁無法存取應分開測試。若代理請求正常但訂閱更新失敗，請檢查來源網址、回應內容與更新方式；若訂閱更新正常但伺服器無法連線，更新成功並不能證明連線參數可用。多個來源同時發生異常時，先調查共用入口與基礎網路。若只有某個項目失敗，請保留其他可用項目作為比對，不要一次刪除所有來源。

部分應用程式異常時，請比較它與正常應用程式的入口方式、獨立 DNS、UDP 使用情況及應用程式排除設定。網頁正常不代表 UDP 正常，系統代理正常也不代表虛擬介面正常。應用程式已建立的長連線也可能繼續使用舊出口，請重新建立連線後再判斷。更完整的遠端檢查順序請參閱節點逾時排查筆記。

問題解決後，請整理最精簡的變更記錄：原始狀況、確認的故障層、實際修改內容與復原測試結果。暫時提高記錄等級後，請恢復日常設定，避免長期累積含目標位址的記錄。若無法重現問題，先維持穩定的基準設定，不要再加入未經驗證的最佳化設定。想重新了解首次連線流程，可返回快速入門；需要切換平台的安裝入口時，請前往用戶端下載頁。一套能說明、能驗證、也能復原的設定流程，比不斷堆疊開關更適合長期維護。