V2Ray 進階設定指南

建立可個別更新的訂閱分組

訂閱連結是取得設定清單的入口，不是用戶端本身提供的連線服務。匯入前，先確認連結來源可信且仍有效，並確認沒有把帳戶管理頁面的網址誤當成訂閱網址。在 v2rayN 中開啟「訂閱分組」，進入「訂閱分組設定」，新增分組並填寫容易辨識的備註與訂閱網址，再儲存。選單排列可能隨介面調整，但「分組設定」與「更新訂閱」是兩項不同操作：儲存網址只會建立來源記錄，執行更新才會取得並解析伺服器設定。

分組備註適合標示來源或用途，例如「主要訂閱」、「備用訂閱」、「手動設定」。不要只填日期，也不要把帳戶密碼寫進備註。建立分組後，回到主視窗選取要更新的分組，再從「訂閱分組」選單執行相應的更新操作。首次匯入建議只更新一個分組，確認是否出現新的伺服器項目，以及協定、位址與傳輸設定能否正確辨識，再加入第二個來源。如此一來，發生問題時便能確認變更來自哪次匯入。

將顯示篩選與設定修改分開處理

主視窗的分組切換、搜尋框與篩選功能通常只影響目前清單的顯示，不會自動替流量加入分流規則。依備註搜尋時，先輸入明確的短詞，再確認是否也啟用了分組限制。清單突然變空，可能只是「目前分組」和「搜尋條件」同時縮小了範圍，不代表訂閱內容已遭刪除。先清除搜尋條件、切回所有分組，再判斷是否需要重新匯入。尚未確認篩選狀態前，不要反覆新增相同訂閱，以免產生重複項目。

如果用戶端提供訂閱層級的篩選運算式，先確認該欄位是用於包含條件、排除條件，還是備註改寫規則，不要混用這三種用途。只有明確標示支援正規表示式的欄位，才能使用正規表示式語法。例如 ^(工作|備用)- 可比對以指定前綴開頭的備註；它不會檢查伺服器是否可用，也無法辨識地區名稱。先用一般搜尋確認目標範圍，再將條件移至訂閱設定。儲存運算式後，通常需要重新更新訂閱才能查看匯入結果的變化。

更新失敗時檢查連線路徑

訂閱網址能在瀏覽器開啟，不代表用戶端使用相同的網路路徑。先檢查網址是否完整，尤其留意複製時帶入的換行、空格與結尾標點。接著分辨一般更新與透過代理更新：後者需要已有可用的代理出站；如果目前沒有可用伺服器，就可能陷入「必須先更新才能連線，必須先連線才能更新」的循環。遇到這種情況，優先使用可直接連線的訂閱入口，或還原先前已驗證可用的設定，不要連續切換多個網路開關。

也要判斷伺服器回傳的內容。登入頁面、錯誤訊息與空白回應都不是有效的訂閱清單；分享連結與訂閱網址也不是同一種入口。單一分享連結應使用用戶端相應的剪貼簿匯入功能，不要只因為連結可以複製，就把它填入訂閱網址欄。匯入入口的差異可參閱訂閱連結匯入教學。排錯時只記錄錯誤類型、分組名稱與操作順序，不要將完整訂閱網址放進公開截圖，因為網址可能包含帳戶憑證。

整理完成後應得到明確結果：每個訂閱來源都有獨立分組，手動伺服器與訂閱伺服器分開保存，關閉篩選後能看到完整清單。接著選取一台已知可用的伺服器並測試連線。伺服器是否顯示、是否已選取，以及是否實際用於出站，是三種不同狀態；後續路由設定應以這些狀態都已確認為前提。

先了解規則順序與預設出站

路由處理的是已進入核心的連線。應用程式若沒有使用系統代理，也未由 TUN 接管，調整路由就不會改變其連線路徑。在 v2rayN 中開啟「路由」或相關路由設定介面後，先確認目前使用的規則集，再檢查規則順序。以 Xray 常見的欄位路由為例，規則通常由上而下比對，首次符合時便選擇對應的出站。因此，特定網域的例外應排在範圍較廣的網域集合之前，涵蓋範圍廣的最終規則則應放在末尾；不能只憑備註名稱推斷優先順序。

同一條欄位規則中的不同條件欄位通常必須同時符合；同一欄位中的多個值通常代表符合任一項即可。例如同時填入網域與連接埠，表示目標必須同時符合網域條件與連接埠條件。如果原意是「這些網域或這些連接埠」，就應拆成不同規則。沒有任何規則符合時，原生 Xray 設定通常會以第一個出站作為預設出站；圖形用戶端也可能自動產生兜底規則，因此必須檢查實際產生的設定，不能只查看自訂部分。

網域集合、位址集合與解析策略

geosite:cn 是網域集合的參照，geoip:private 是私人位址集合的參照。前者依賴網域規則資料，後者依賴位址規則資料；它們不是線上服務名稱，也不會自動補上缺少的資料檔。只有核心知道目標網域時，網域規則才能比對。如果入口只提供 IP，且沒有可靠的網域還原或嗅探資訊，就不能假設網域規則一定會生效。反過來，IP 規則是否適用於網域目標，也取決於路由的網域解析策略。

以下 JSON 是 Xray 頂層設定的合併片段，用來示範私人位址直連、指定網域直連與阻擋廣告網域。範例將直連設為第一個出站，因此未符合規則的連線也會直連；它不是完整的代理設定。既有設定若包含同名出站，應沿用而非重複定義。圖形用戶端使用者應優先在規則編輯器中建立相同規則，並核對用戶端產生的標籤；不要將整段 JSON 填入只接受規則陣列的文字欄位。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:example.com", "geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      }
    ]
  },
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

先用單一目標驗證，不要一次匯入大量規則

驗證路由時，先選一個容易重現的目標，記下預期出站，再查看記錄中的實際出站標籤。儲存新規則後，依用戶端要求重新載入設定或重啟核心，並關閉應用程式既有連線後再測試。長連線可能繼續沿用舊路徑，瀏覽器快取也可能讓頁面看似沒有變化；只重新整理頁面不一定能證明新規則已生效。如果規則未命中，依序檢查目前的規則集、規則位置、目標網域格式、資料檔是否可用，以及入口提供的資訊。

區域網路裝置、共用印表機與內部服務，應優先檢查具體位址範圍；不要為了修復單一區域網路存取問題，就直接把所有流量改成直連。部分內部網域只存在於公司網路的 DNS 中，需要同時安排解析與路由。直連規則命中不代表 DNS 一定正確，網域解析成功也不代表實際連線使用了正確的出站。將記錄中的目標、命中條件與出站標籤一併記下，才能區分規則問題與解析問題。

最後保留一份精簡明確的規則集作為回復基準。每新增一類規則後，檢查一般網頁、區域網路資源與需要特殊分流的目標。若只有特定網域異常，應新增局部例外或調整規則順序，不要清空整份規則集。規則越多，就越需要註明用途；無法說明比對範圍的廣泛規則，往往比缺少規則更難排查。

先釐清一次網域查詢會經過哪些環節

DNS 會將網域名稱轉換為位址，但一台裝置上可能同時存在多條解析路徑。系統解析器服務一般應用程式；瀏覽器可能啟用自己的安全 DNS；代理核心也可能為了路由判斷、直連出站或連線至上游而進行解析。用戶端填入「遠端 DNS」，不代表所有應用程式都會使用它。開始調整前，先判斷目標應用程式是將網域交給代理，還是在本機先解析成 IP，再將位址交給代理。這兩種入口提供給路由的資訊不同，排查方式也不同。

在系統代理模式下，支援代理的應用程式通常能將網域一併交給本機代理，但實際行為仍取決於應用程式與協定。啟用 TUN 接管後，系統 DNS 請求是否進入用戶端，還取決於虛擬網卡、DNS 接管與排除設定。瀏覽器內建的加密解析也可能繞過系統 DNS 入口。為了建立可比較的測試環境，可以暫時讓瀏覽器使用系統解析，確認基本路徑後，再單獨評估其安全 DNS 設定，避免同時修改兩層解析器。

伺服器位址、查詢類型與路由不是同一個參數

選擇 DNS 伺服器時，應考慮目前網路是否能連線、內部網域能否解析，以及查詢流量應走哪條路徑。填入 1.1.1.1 只代表指定一個公共解析器位址，不會自動要求查詢透過代理。加密 DNS 可以保護裝置與解析器之間的查詢傳輸，但仍需要建立網路連線；若解析器使用網域位址，還可能先遇到引導解析問題。若一開始就無法解析，應先確認解析器本身是否可連線，不要繼續疊加更多備用位址。

以下是 Xray 頂層 DNS 設定片段，只示範單一伺服器與 IPv4 查詢策略。它不會建立流量入口，也不會自動變更系統 DNS。只有確認目前核心支援相關欄位後，才能合併設定；若由用戶端產生設定，應優先使用用戶端提供的 DNS 選項。使用 UseIPv4 適合用來排除 IPv6 路徑問題，但不建議一律作為長期設定；依賴 IPv6 的服務可能因此沒有可用位址。

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

分流解析與快取的界線

需要存取內部網域時，應保留能解析該網域的內部解析器，再依核心支援的網域條件安排查詢。公共 DNS 通常不知道公司內部主機名稱。分流 DNS 的目的不是讓每個網域都查詢所有伺服器，而是將特定網域交給合適的解析器，並確認首選解析器失敗後是否允許改用其他解析器。不同核心對伺服器選擇、回退與快取的欄位定義並不相同，不要從其他設定格式複製同名欄位後直接套用。

變更解析器後，舊位址可能仍留在系統快取、瀏覽器快取與應用程式連線池中。先重新啟動目標應用程式，再依系統方式清除解析快取，必要時重新載入用戶端核心。不要因快取尚未過期就判定設定無效，也不要只憑一次位址變化判斷解析品質。驗證時一併記錄解析是否成功、取得的位址類型，以及最終連線是否成功。如果網域能解析但目標位址無法連線，應改查路由或網路路徑，而不是繼續更換 DNS。

也要區分 DNS 失敗與憑證錯誤。系統時間不正確、目標網域與憑證不符，或應用程式連到內部攔截頁面，都可能造成網頁無法開啟，但更換解析器未必有幫助。若要固定網域對應，應記錄維護原因與還原條件，避免長期寫死臨時位址。完整的 DNS 設定不只要能回傳位址，還必須與路由、入口及網路環境彼此相容。

先確認出站可用，再啟用虛擬網卡

TUN 會透過虛擬網路介面接收符合系統路由條件的封包，適合處理不讀取系統代理設定的應用程式。它與 HTTP、SOCKS 本機監聽是不同的入口方式，但接管後的流量仍須由路由規則選擇出站。啟用前，先在一般系統代理模式下確認伺服器能建立連線，且 DNS 正常運作。如果基本連線尚未成功就啟用 TUN，問題便會同時牽涉虛擬網卡、權限、解析與路由，很難判斷最初的故障位置。

在 v2rayN 中尋找「啟用 TUN」相關開關前，先確認用戶端安裝位置穩定、所需核心與輔助元件齊全，並依目前平台要求授予必要權限。Windows 可能需要管理員權限才能建立介面或調整路由；macOS 與 Linux 的權限方式則取決於用戶端實作。不要直接套用其他平台的權限命令。各平台的安裝入口請見用戶端下載頁，首次執行的基本步驟請見入門指南。

建立單一入口的測試環境

首次測試 TUN 時，可以先清除系統代理，讓目標應用程式只透過 TUN 接管，減少多個入口造成的干擾。這不表示兩種模式永遠不能並用，而是排錯時應盡量讓路徑單一。啟用後，檢查用戶端記錄是否顯示介面初始化失敗、權限不足或路由設定失敗。系統中出現虛擬網卡，不代表 DNS 接管與出站都已成功；仍須分別測試網域存取、一般連線與區域網路資源。

其他 VPN、虛擬網卡工具、容器網路與企業安全軟體可能同時修改系統路由。若所有網路都中斷，先關閉 TUN，觀察網路是否恢復，再逐一檢查這些並行元件。多個接管工具同時執行時，不要反覆切換預設閘道。若需保留公司網路或特定網段直連，應使用用戶端支援的排除路由或規則，並確認這些規則作用於系統接管層，還是核心分流層。兩者名稱相似，但作用位置不同。

檢查 DNS、區域網路與 UDP

TUN 常見的限制是 DNS 請求未進入預期的解析路徑。若直接存取位址可用但網域失敗，先檢查虛擬網卡使用的 DNS、用戶端的 DNS 接管方式，以及應用程式自身的解析設定。不要一開始就啟用 FakeDNS；真實位址解析較適合作為容易觀察的基準。區域網路存取異常時，檢查私人位址是否正確排除或直連，尤其留意公司使用的特殊網段，以及只能透過特定介面連線的內部服務。

部分應用程式使用 UDP，但入口能接收 UDP，不代表遠端伺服器、傳輸設定與整條網路路徑都支援相同流量。若網頁正常，但語音或其他 UDP 功能異常，應分別檢查協定能力、出站設定與防火牆規則；不能只憑 TUN 開關就判定所有應用程式都已接管。MTU 也不宜任意修改；只有在特定網路中出現大型資料傳輸停滯、連線已建立但持續傳輸失敗等可重現情況時，才記錄原值並一次測試一項變更。

保留明確的退出與復原步驟

關閉 TUN 後，檢查一般網路是否恢復，再確認系統代理是否仍指向本機連接埠。用戶端已退出，但系統代理仍使用已停止監聽的連接埠，會導致應用程式持續無法存取網路。如果介面或路由沒有還原，先正常重新啟動用戶端，再次關閉接管；必要時依系統網路管理方式檢查殘留狀態。不要批次刪除不認識的路由，也不要任意移除系統虛擬介面卡，因為其中可能包含其他軟體正常使用的介面。

完成設定後，依固定順序重新測試：一般網頁、需要網域解析的目標、區域網路資源、需要 UDP 的應用程式，最後再檢查休眠喚醒與網路切換。在行動辦公環境中，網路從有線切換到無線會改變介面與路由，原本正常的接管可能需要重新初始化。只有這些情境都能清楚說明，才適合將 TUN 作為日常入口，而不是把它當成遇到任何連線問題都要開啟的總開關。

了解合成位址在連線中的作用

一般 DNS 查詢會回傳目標的真實位址，應用程式接著向該位址發起連線。FakeDNS 則會從位址池分配合成位址，並由核心保存網域與合成位址的對應關係。應用程式連線至這個位址時，接管路徑必須將請求送回掌握映射資料的核心，核心才能還原網域並繼續路由或出站。它的主要用途是保留網域資訊，不會讓目標伺服器變快，也不會自動將所有 DNS 查詢改為遠端解析。

這種機制要求解析路徑與連線路徑形成閉環。若系統收到合成位址後，後續連線卻繞過用戶端，就會嘗試存取公網上不存在的目標；若位址由一個執行個體分配，連線卻進入另一個沒有映射記錄的執行個體，也可能無法還原網域。因此，不要只複製位址池設定就認定 FakeDNS 已成功啟用。必須一併檢查 DNS 查詢如何進入核心、應用程式封包如何接管，以及對應的入站是否具備所需的網域還原能力。

位址池、解析器與嗅探設定必須配套

以下展示 Xray 頂層設定中的 FakeDNS 位址池與 DNS 伺服器片段。範例使用 198.18.0.0/15 範圍內的位址作為合成池；這不是可直接連線至目標伺服器的公網位址範圍。此片段仍須搭配實際入站的 FakeDNS 還原設定，不能單獨取代用戶端產生的 TUN 設定。如果用戶端已有「啟用 FakeDNS」選項，請優先使用其整合流程，避免在不同設定層重複宣告位址池。

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

對支援相關欄位的 Xray 入站而言，嗅探設定中的 destOverride 可以包含 fakedns。這是用來從合成位址還原目標網域，不等於一般 HTTP 或 TLS 嗅探。一般嗅探會嘗試從連線資料中辨識主機名稱；FakeDNS 還原則依賴先前建立的映射。入站的其他設定仍須保留，不要為了加入嗅探而覆蓋協定、監聽位址與連接埠。不同核心與接管實作的設定方式可能不同，應以實際產生的設定為準。

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

切換前後處理快取與繞行問題

啟用 FakeDNS 後，應用程式可能仍快取先前取得的真實位址；停用後，也可能繼續保留舊的合成位址。測試時先結束目標應用程式的連線，再重新啟動應用程式，必要時清除系統 DNS 快取並重新載入核心。否則，同一網域的多次連線可能走不同路徑，看起來像是規則偶爾生效。尤其不要在用戶端重新啟動、映射表消失後，仍讓應用程式使用先前快取的合成位址；這種失敗不一定代表訂閱或伺服器有所變動。

需要繞過接管的應用程式應謹慎處理。如果應用程式取得 FakeDNS 合成位址，卻被排除在程序或系統路由接管範圍之外，就無法透過一般網路存取該位址。若內部網路剛好使用與合成池衝突的位址，也需要調整方案。部分應用程式會直接檢查解析結果、要求真實目標位址，或自行執行連線驗證，可能不適合使用合成解析；可以讓這些目標保留真實 DNS 路徑，而不是繼續增加範圍更廣的接管規則。

從一般網域開始驗證。先確認查詢確實由 FakeDNS 回覆，再檢查連線是否進入預期的入站，最後查看記錄中是否已還原網域，以及是否命中對應路由。如果真實 DNS 模式正常、FakeDNS 模式失敗，就保留原伺服器與路由設定，只檢查映射路徑。如此可將問題範圍限縮在解析與入口之間，不必重新匯入訂閱。若實際需求只是一般網頁瀏覽，也可以繼續使用真實 DNS，減少需要維護的設定環節。

依來源建立分組，而非依臨時顯示結果分組

多訂閱管理的第一步不是一次匯入更多網址，而是確保每份設定都能追溯來源。建議每個訂閱網址使用獨立分組，手動伺服器另放一組，再透過備註或篩選條件整理日常顯示。不要只因兩個訂閱包含相似名稱，就把它們混在同一筆來源記錄中。訂閱更新、篩選條件與上游變更都以來源為單位；分組混雜後，很難判斷項目消失是上游刪除、篩選條件變動，還是另一個訂閱改變了顯示結果。

只需建立簡單的維護記錄，註明分組用途、是否允許自動更新、更新依賴直連還是代理，以及復原時使用哪份已知可用的設定。記錄可保存在本機文件中，但訂閱網址應視為敏感資訊並單獨保護。如果用戶端提供設定匯出或備份功能，先確認匯出範圍是否包含訂閱憑證、伺服器驗證資料與自訂規則。分享排錯資料給他人時，只保留欄位名稱與錯誤類型，不要直接傳送整個使用者資料目錄。

更新順序與目前選取的伺服器

更新可能新增或移除項目，也可能重新產生本機識別資料。如果目前選取的伺服器遭上游刪除或取代，用戶端後續如何選擇取決於其實作，不能假設會一直停留在同一台伺服器。重要使用時段前，先更新一個分組，確認目前的選擇仍存在，再重新建立連線。伺服器備註相同也不能證明設定相同；應檢查協定、位址、連接埠、傳輸與安全設定是否仍符合預期。

自動更新適合已驗證穩定的來源，但也要考慮裝置休眠、網路切換與更新路徑。若所有訂閱都設定在同一時間透過目前代理更新，代理不可用時就可能全部失敗。排錯期間可暫時改為手動更新，每次只處理一個分組；問題排除後，再依需求啟用自動更新。沒有明確需求時，不必追求過於頻繁的更新。更新失敗也不代表既有本機設定會立即失效，應先確認目前的出站是否仍可使用。

去重、篩選與手動修改

相同伺服器可能出現在多個來源中，但「名稱相同」並非可靠的去重條件。不同驗證資料、傳輸方式或 TLS 參數可能指向相同位址，卻各有不同用途；相反地，名稱不同的項目也可能是相同設定。使用用戶端的去重功能前，應先確認它比對哪些欄位，並保留可還原的副本。如果只是想簡化日常清單，優先利用分組與搜尋減少顯示項目，不要刪除尚未理解的設定。

訂閱內容是由上游維護的資料。本機臨時調整某台伺服器的傳輸參數，下次更新時可能會被覆蓋；需要長期使用的衍生設定，應複製到手動分組，並註明來源與修改原因。不要將上游產生的設定檔當成唯一工作檔案反覆編輯，因為用戶端重新載入時也可能重新產生該檔案。路由與 DNS 盡量放在用戶端支援的獨立設定層，讓訂閱只負責伺服器參數，降低更新時互相覆蓋的範圍。

備用分組不等於自動故障切換

在主視窗新增備用訂閱，只是增加可選的設定來源，並未自動建立健康檢查、負載平衡或故障切換機制。若未明確設定相關功能，目前的伺服器失敗後通常仍需手動選擇。即使某個介面支援測速或自動選擇，也應確認測試目標、是否檢查實際連線，以及切換是否會影響已建立的工作階段。單次測試成功無法證明所有應用程式都可用，更不能取代協定與網路路徑的相容性檢查。

維護多個來源時，最重要的是能重複執行的切換步驟：先記錄目前的分組與伺服器，選取備用設定，重新建立連線，再測試相同目標。若備用設定可用，就保留原來源不動，單獨檢查其更新與伺服器參數；若所有來源都同時失敗，則應優先檢查本機入口、DNS、權限與系統網路。將來源問題與本機環境問題分開處理，才能避免不斷新增訂閱來掩蓋真正的設定錯誤。

區分圖形用戶端、核心與設定格式

v2rayN 是圖形用戶端，負責管理伺服器、產生設定並啟動核心；實際處理協定與路由的是所選核心及其配套元件。介面欄位名稱相似，不代表底層設定格式也相同。編輯前先在用戶端設定或啟動記錄中確認目前的核心類型，再判斷各項功能由哪個元件負責。尤其是 TUN 接管與一般代理連線，可能由不同處理環節完成，不能只憑伺服器協定名稱推斷整條連線路徑的實作方式。

在 Android 上，v2rayNG 主要採用 Xray 核心，v2flyNG 則是 V2Fly 路線的替代用戶端。選擇時應先確認設定需要的協定與功能，而非只比較名稱。不同核心對協定、安全擴充功能與設定欄位的支援可能不同，不能直接交由其他核心執行複雜的 Xray 自訂設定。生態系與功能取捨可參閱Xray 與 V2Fly 核心差異。

出站標籤供路由參照，不是顯示備註

自訂出站至少需要明確標籤、受支援的協定及相應參數。路由中的 outboundTag 必須與實際出站的 tag 完全相同，大小寫也應一致。主視窗中的伺服器備註不一定等於產生設定中的標籤。儲存前，確認用戶端會保留該出站、是否已有同名標籤，以及自訂規則會合併到哪個位置。重複標籤或指向不存在標籤的規則，應在啟動階段優先處理。

以下 Xray 出站物件示範將連線轉交給本機另一個 SOCKS 服務，監聽位址為 127.0.0.1:10810。只有在該服務確實已啟動且允許本機連線時才能使用；此設定不會自動建立第二個代理。應將物件放入支援的出站陣列，再讓特定路由參照 local-socks。若只是使用一般訂閱伺服器，通常不必為了建立連線而增加這一層。

{
  "tag": "local-socks",
  "protocol": "socks",
  "settings": {
    "servers": [
      {
        "address": "127.0.0.1",
        "port": 10810
      }
    ]
  }
}

避免轉送迴圈與參數覆蓋

本機轉送最需要檢查的是連接埠的對應關係。如果目前核心自己的 SOCKS 入站也監聽同一個連接埠，而出站又指向該連接埠，就可能把連線送回自身，形成迴圈。另一個服務若也透過目前用戶端出站，同樣可能造成跨程序循環。設定前先列出每一段的監聽位址、監聽連接埠與下一個節點，確保路徑最終能抵達真正的網路出口。不要只確認連接埠有程序監聽，還要查明監聽程序是誰。

對由用戶端管理的自訂設定，應優先使用其提供的自訂伺服器、設定匯入或規則編輯入口。直接編輯執行時產生的檔案，可能在下次切換伺服器或重新啟動核心時遭到覆蓋。若確實需要維護完整設定，應明確區分哪些項目仍由主視窗控制，哪些只能在設定檔中調整；例如主介面的路由選擇可能不再影響完整的自訂設定。不要同時維護兩套看似相同、實際上會互相覆蓋的參數來源。

將相容性問題限縮在最小範圍

核心無法啟動時，先查看第一則明確錯誤，分辨是 JSON 語法、未知欄位、缺少檔案、標籤參照或連接埠占用。核心尚未啟動時，不要更換 DNS 或伺服器。若需要切換核心，先保留目前可用的設定，再用最簡單且相容的連線測試基本功能，之後逐項恢復路由、解析與自訂出站。用戶端成功匯入設定，只代表介面已讀取內容，不代表目前核心能執行所有欄位。

自訂出站投入日常使用前，應測試目標路由是否命中、下一個節點是否可連線、應用程式能否重新連線，以及關閉後能否還原。若路徑依賴另一個本機服務，也要測試該服務停止後的錯誤狀況，避免將明確的本機依賴失敗誤判為遠端故障。設計出站時應以易於理解與還原為重點：每個標籤都有用途，每個連接埠都有歸屬，每次切換都能回到已驗證的基礎設定。

先找出故障發生的階段

「無法連線」可能表示核心沒有啟動、應用程式沒有使用代理、網域解析失敗、規則選錯出站，或無法建立遠端連線。先記錄最精簡的重現步驟：目前的用戶端、核心類型、入口模式、選取的伺服器、目標應用程式與發生錯誤的操作。再換一個目標測試，判斷是單一網域異常還是所有連線都失敗。如果直接網路本身已無法使用，應先恢復系統網路，再檢查代理設定，避免將底層斷線誤認為訂閱問題。

核心啟動失敗時，先查看記錄開頭的錯誤。連接埠被占用、設定語法錯誤與權限不足，通常在啟動階段就會留下線索。連接埠號碼應以目前設定為準；不能因常見 SOCKS 連接埠是 10808、HTTP 連接埠是 10809，就認定裝置實際使用相同數值。若變更連接埠，也要同步更新手動設定代理的應用程式；系統代理自動設定與應用程式內的手動代理，也可能是兩筆獨立設定。

先驗證入口，再檢查遠端連線

啟用系統代理後，只有讀取系統設定的應用程式才會自動使用代理。對不支援系統代理的程式而言，網頁測試成功不代表該程式已進入用戶端。可以先用明確支援代理的應用程式驗證本機入口，再判斷是否需要 TUN。在 TUN 情境下，則應檢查介面、權限與接管範圍。如果用戶端記錄完全沒有目標連線，應優先排查入口，而不是修改遠端協定參數。入口沒有流量，後續路由自然也不會有比對機會。

確認流量已進入後，再區分解析錯誤與連線錯誤。若網域連線失敗，但已知位址的測試路徑正常，可以檢查 DNS；不過，直接以位址連線至 HTTPS 可能觸發憑證與主機名稱問題，不能據此判定是 DNS 錯誤。較可靠的方式是搭配記錄檢查解析結果與實際連線目標。若解析成功但連線逾時，繼續檢查出站與網路；若立即出現規則或標籤錯誤，先修正設定參照。

依症狀縮小範圍，不要不斷切換開關

如果問題只在啟用 FakeDNS 後出現，先固定伺服器與路由，改回真實 DNS 進行驗證；若只在 TUN 下出現，就保留一般代理入口作為對照。若問題發生在更新訂閱後，檢查目前伺服器是否遭替換，以及上游參數是否變更。若切換核心後才發生，則從欄位相容性與產生的設定開始檢查。每種情況都應有明確的對照條件，不要同時更換伺服器、DNS 並重設路由後，再猜測是哪個步驟生效。

查看記錄時，留意錯誤類別與發生順序。連線遭拒通常表示目標連接埠未接受連線或明確拒絕；逾時則可能與連線路徑、流量過濾或遠端未回應有關。這兩種情況都無法單獨證明伺服器設定的所有欄位正確。TLS 錯誤也應檢查系統時間、伺服器名稱與憑證驗證設定。不要為了消除錯誤訊息而任意放寬安全驗證；應先確認網域、傳輸方式與伺服器端設定一致，再重新連線。

建立可重複使用的回復基準

可還原的基準設定應包含：能正常啟動的核心、已驗證的伺服器、明確的本機入口、簡單路由與可連線的 DNS。每次修改前記錄原始值與預期結果；失敗後還原原值，不要在錯誤狀態上繼續疊加調整。涉及 TUN 與 FakeDNS 時，復原範圍也包括應用程式快取與系統接管狀態。完成還原後重新建立連線，不能只因開關已關閉就認定舊路徑已清除。

完成排錯後，將最終有效的變更縮減至必要範圍，並刪除臨時測試規則。若要快速恢復基本連線，可回到入門指南重新確認主要步驟；需要更換安裝平台或用戶端時，請使用下載頁的對應入口。日常維護應沿用相同的驗證順序：先確認核心是否執行，再確認流量是否進入，接著檢查解析、路由與出站。如此一來，新問題發生時仍能依清楚的設定層次定位，不必從頭重建所有設定。