V2Ray 進階設定指南

一、訂閱分組與伺服器篩選

訂閱是更新伺服器設定的來源；分組則是用戶端整理這些來源及其項目的方式。兩者應分開理解：伺服器清單顯示某個分組，不代表路由規則已引用該分組；切換分組檢視，也不代表正在使用其中的伺服器。整理前，先確認目前選取的伺服器、所屬訂閱及正在使用的路由模式，並記錄一組已能連線的設定，方便日後比對排錯。

依來源分組，再按用途篩選

在 v2rayN 的訂閱分組設定中，為每個來源填寫容易辨識的備註，再輸入對應網址。備註建議描述來源或用途，例如「日常連線」、「測試環境」，不要用暫時的伺服器名稱當作長期分組名稱。儲存後，更新指定分組，確認新項目是否出現在預期位置。手動匯入的連結最好獨立分組，否則之後清理訂閱項目時，可能連需要保留的手動設定也一併刪除。

訂閱網址通常含有存取憑證，應視為敏感資訊。不要在螢幕截圖、公開提問或共用文件中貼出完整網址，也不要拿不同來源的網址互相替換測試。更新失敗時，先判斷問題出在下載訂閱內容，還是解析內容：前者可能與網路、憑證或授權有關；後者則可能是訂閱格式或用戶端相容性問題。分組名稱只供本機辨識，修改備註無法修復失效的網址。

分清清單搜尋與持續套用的篩選條件

伺服器清單上的搜尋框通常只會篩選目前顯示的結果；訂閱分組的篩選設定則可能影響更新後保留或顯示哪些伺服器。操作前先閱讀欄位說明，確認篩選對象是伺服器備註、網址還是其他屬性。先用確定存在的簡短關鍵字測試，確認結果後再增加條件。不要把通用正規表示式直接填入只接受一般關鍵字的欄位，也不要假設所有用戶端的比對方式都相同。

若欄位明確支援正規表示式，可用 (?i)(test|backup) 表示不區分大小寫的候選關鍵字；但是否支援此寫法，取決於欄位使用的正規表示式引擎。不支援時，請使用介面提供的一般文字篩選。包含與排除條件應分開驗證，尤其留意空格、全形符號及備註中的特殊字元。條件太寬會留下無關項目，太嚴則可能出現「更新成功但清單空白」的情況。

更新後確認設定項目

訂閱更新可能新增、刪除或重新命名伺服器；名稱相同的項目也不一定代表連線參數完全相同。更新後除了查看備註，也要核對協定、伺服器位址、連接埠及傳輸方式。若有必須固定使用的項目，請確認用戶端更新後如何保留選取狀態；若舊項目消失，不能只因清單仍有反白項目，就認定已成功切換至替代設定。請重新選取目標伺服器，並建立新連線確認實際結果。

遇到重複項目，先判斷是同一來源重複提供，還是多個分組各自包含相同伺服器。刪除前先保留原有訂閱關係，避免下次更新又重新產生，或誤刪傳輸參數不同的項目。Android 版的分組與篩選入口可能不同，但處理原則一致：先限定單一來源，再檢查項目內容，最後測試連線。只憑名稱相似就批次刪除，往往會掩蓋真正的設定差異。

二、路由規則實作

路由處理的是已進入核心的連線。系統代理決定應用程式是否將連線送至本機入口，路由則決定這些連線使用哪個出站；兩者不能互相取代。設定前先整理實際路徑：應用程式、入口、目標識別、規則比對、出站。若應用程式根本沒有使用系統代理，修改網域規則通常不會改變它的連線方式。這兩種設定的差異，可參考系統代理與路由模式比較。

規則依序比對，具體條件放前面

一般欄位規則會依序檢查，符合後便選擇對應出口，因此例外條件應放在較寬泛的規則之前。合理的基本順序是：明確的業務例外、需要阻斷的類別、區域網路位址、常用直連範圍，最後才是預設出口。不要只按「直連、代理、阻斷」三大類隨意排列；如果前面的規則已涵蓋目標，後面的細部規則即使正確也不會生效。

同一條規則中同時填入網域、連接埠、網路類型等不同欄位時，通常必須同時符合這些條件；同一個網域陣列中的多個項目則代表候選比對值。把「某個網域或某個連接埠」寫在同一條規則裡，容易得到與預期相反的交集結果。需要聯集時，請拆成多條規則。修改前先確認要依網域判斷，還是依解析後的位址判斷；這也會決定是否需要 DNS 參與。

用最小範例建立直連與阻斷規則

以下是 Xray / V2Fly 常見欄位形式的路由片段，並非完整啟動設定。現有設定必須已包含 direct、block 及預設代理出站，並安裝含有這些分類的規則資源。此處使用 AsIs，表示不為 IP 規則主動解析尚未取得位址的網域；以 IP 形式傳入的目標仍可進行 IP 比對。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

此處沒有加入名為 final 的欄位規則，因為它不是這類 JSON 路由通用的關鍵字。未符合規則時，通常會使用出站清單中的第一個出站；圖形介面用戶端也可能自行產生兜底規則。請查看最終產生的設定，不要只看介面中的簡寫名稱。若要讓剩餘的 TCP 與 UDP 連線走代理，可在最後加入對應的網路規則，但仍須確認出口及 UDP 能力符合需求。

確認網域可見性與規則資源

網域規則要生效，前提是核心能取得目標網域。透過 HTTP 或 SOCKS 入口傳遞網域，與應用程式先由系統解析、再送出 IP 位址，是兩種不同情況。流量嗅探可從部分協定內容還原網域，但無法識別所有流量。若規則看似正確卻沒有命中，先查看記錄檔中的目標格式，再檢查嗅探設定，不要不斷加入同一網域的不同拼法。

geosite 與 geoip 需要相應的資源檔與分類。資源不存在，或目前檔案中沒有指定分類，可能導致啟動失敗或設定檢查報錯。先透過用戶端提供的資源管理入口，確認檔案位置與實際使用的核心相符；不要只把檔案放在任意工作目錄。每新增一類規則，就選一個可重現的目標建立新連線，確認命中的出口並記錄結果。規則數量增加不代表分流更精準。

三、DNS 設定最佳化

DNS 設定必須釐清三件事：由誰提出查詢、查詢交給哪個解析器，以及連往解析器的網路連線走哪條路徑。系統解析、應用程式內建解析及核心 DNS 屬於不同層次，不能用一個「啟用 DNS」開關概括。調整前先確認問題是解析失敗、解析結果不適合目前出口，還是路由無法取得網域。只有先找出查詢發生的位置，才能判斷應修改系統、用戶端或應用程式本身。

先建立一般解析，再設定網域分流

初期先保留一套容易觀察的一般解析方式，確認伺服器網域與一般連線網域都能正常解析，再加入依網域分流的伺服器。以下僅示範核心 DNS 部分：指定網域優先交由某個解析伺服器處理，其他查詢則可使用另一台伺服器。這不代表查詢會自動透過代理，也不會控制所有應用程式的系統 DNS。實際使用前，還應確認解析伺服器在目前網路中可連線，並符合裝置所在環境的管理要求。

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

含有 domains 的伺服器會優先比對指定網域，但未比對成功時的嘗試方式、失敗後的回退及結果篩選，仍會受具體核心與其他欄位影響。不要把優先比對設定視為嚴格隔離。若要禁止回退，請查閱目前核心支援的回退選項，並透過記錄檔確認；不要把某個用戶端介面中的「遠端 DNS」名稱，直接當成所有核心通用的 JSON 欄位。

分清路由解析與出站解析

路由層的 domainStrategy 會影響是否為了比對 IP 規則而進行解析；直連出站中的同名欄位則會影響直連目標如何解析及連線。兩者所在位置與用途不同。例如路由使用 IPIfNonMatch，表示網域規則未命中後可能會解析目標，再嘗試比對 IP 規則；這不代表所有連線都改用某個遠端解析器。變更策略後，應同時觀察規則命中情況及解析請求是否增加。

解析代理伺服器本身的網域時，尤其要留意啟動順序。如果必須先透過代理才能連線至某個 DNS 服務，而建立代理連線又依賴同一個 DNS 服務，就會形成循環依賴。可讓伺服器網域使用能獨立完成的解析路徑，或採用來源明確且可持續維護的伺服器位址設定。不要以長期固定的暫時解析結果取代網域管理，否則伺服器位址變更後，即使設定看似沒改，連線仍可能失效。

快取、雙堆疊與應用程式自行解析

修改 DNS 後，瀏覽器、作業系統與核心可能仍保留舊結果，既有連線也不會立即重新解析。測試時請關閉目標應用程式的舊連線，必要時依系統提供的方法清除快取，再發出新請求。IPv4 與 IPv6 結果也應分開觀察：若解析結果包含 IPv6 位址，但所選出口或目前網路無法完成相應連線，症狀可能是等待一段時間後才恢復，而非直接顯示 DNS 錯誤。

應用程式內建的加密 DNS 可能繞過系統解析路徑，這時只修改系統 DNS 不會看到預期變化。在 TUN 環境中，也不能假設所有加密查詢都能透過連接埠規則識別。先在可控測試中暫時關閉應用程式自行解析，確認系統路徑的行為，再決定是否需要相容處理。若環境涉及企業網域、區域網路裝置名稱或分離解析，請保留原有解析入口，避免將內部名稱傳送給不認識它們的公共解析器。

四、TUN 模式與系統流量接管

TUN 透過虛擬網路介面接收系統 IP 流量，適合不方便設定 HTTP 或 SOCKS 代理的應用程式。它與系統代理的差異在入口層次，不代表「啟用後所有流量一定走代理」。進入 TUN 的連線仍會經過路由規則，區域網路、直連及阻斷都可以繼續使用。用戶端顯示的 TUN 功能也可能由額外網路元件實作，不能因此認定目前的 Xray 或 V2Fly 設定原生就有相同的 TUN 欄位。

啟用接管前先建立基準狀態

啟用前，先在系統代理模式下確認伺服器可連線、常用網域可解析，並檢查基本路由是否符合預期。接著關閉其他可能接管系統網路的工具，記錄目前的網路介面卡、預設閘道與 DNS 狀態，再啟用 TUN。首次測試只開啟必要的接管選項，不要同時加入程序規則、複雜的排除清單及 FakeDNS。如此一來，若發生問題，就能判斷是入口改變所致，還是原有出站設定有誤。

權限錯誤與網路錯誤應分開處理。桌面系統可能需要管理員授權、建立虛擬介面的權限或輔助元件許可；Android 用戶端通常透過系統 VPN 授權接管應用程式流量。完成授權只代表系統允許建立入口，不代表流量已成功送達遠端。若介面顯示啟動失敗，請先檢查權限、元件檔案及介面衝突，不要在入口尚未建立時反覆更改伺服器協定。

避免回送，保留區域網路存取

代理元件本身的外連必須避免再次進入同一個 TUN 入口，否則可能形成回送，出現連線不斷重試或記錄快速重複的情況。用戶端通常會處理自動路由及自身流量排除，但自訂網路設定可能破壞這些預設行為。若啟用後整個系統都無法連線，先退出 TUN 恢復網路，再檢查自動路由、介面綁定及排除設定。不要在斷網時同時重裝多個網路元件。

區域網路存取也涉及私有位址、群播探索、廣播及本機 DNS。在路由中加入私有位址直連，有助於一般位址存取，但不保證所有裝置探索協定都能通過接管環境。驗證時先以明確位址存取本機閘道或已知裝置，再測試名稱解析與自動探索。若可用位址連線、用名稱卻不行，應優先檢查 DNS；若只有自動探索失敗，則需進一步檢查群播與應用程式的探索機制。

分階段檢查 DNS 與 UDP

TUN 能接收 UDP，不代表所選伺服器或協定路徑一定能傳送這些連線。請分別測試一般網頁、依賴 UDP 的應用程式及區域網路存取，不能只用瀏覽器開啟一個頁面就當作全部驗證完成。特定應用程式無法使用時，先確認它是否使用自行解析、特殊目的連接埠或其他網路介面，再決定要調整接管範圍、DNS 路徑，還是改用具備所需能力的現有出站。

結束測試時，先關閉 TUN，確認虛擬路由與 DNS 已恢復，最後檢查系統代理是否仍維持所需狀態。異常結束後若網路未恢復，先重新開啟用戶端，正常關閉接管功能，再檢查系統設定。macOS 的安裝允許與網路權限問題，可參考權限設定說明；安裝程式與各平台入口集中於下載中心，本章不提供額外元件下載。

五、FakeDNS 與網域映射

FakeDNS 以虛擬位址取代真實 DNS 結果，並在內部保存網域與虛擬位址的映射。應用程式取得虛擬位址後發起連線，接管元件或核心再依映射還原目標網域。它的用途是保留網域資訊，讓路由與後續解析更容易配合，而不是提供可直接連線的真實位址。若查詢經過 FakeDNS，連線卻繞過對應的接管路徑，應用程式就可能直接連向虛擬位址而失敗。

查詢與連線必須走同一套映射路徑

啟用前先確認目前的核心與用戶端確實完整支援 FakeDNS，包括 DNS 回覆、位址池接管及網域還原三個部分。不要只因設定欄位可以儲存，就認定整套功能已正常運作。以下展示支援此結構的核心設定片段，說明位址池與 DNS 伺服器的關係；仍須整合至既有設定，並搭配入口、路由與出站。範例中的位址池屬於基準測試用途位址範圍，不應用來存取一般公網目標。

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

ipPool 指定可分配的虛擬位址範圍，poolSize 控制位址池容量。位址池須與真實網路及其他接管工具的位址範圍相互配合，不能只因「看起來特殊」就任意改成正在使用的網段。容量也不是越大越好，應依核心實作與實際需求選擇。更換位址池後，應用程式快取中的舊位址不會自動更新，必須重新解析並建立新連線。

入口必須還原網域，不能只傳回虛擬位址

在支援 FakeDNS 還原的入口中，常見做法是啟用相應的嗅探功能。以下仍是入口物件內部的片段，不應覆蓋整個 inbounds 陣列。fakedns 用來嘗試從映射還原網域，HTTP 與 TLS 嗅探則補足部分應用層識別能力。是否接受這些值、是否需要額外入口設定，應以目前核心實際支援的內容為準；圖形介面產生的設定也可能採用不同實作。

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

有些設定也提供 routeOnly，讓嗅探結果只用於路由判斷，不改寫實際連線目的地。這個選項不能不加區分地套用至 FakeDNS：若最終目的地仍是虛擬位址，連線就無法依真實網域建立。應先確認網域已還原且目的地處理正確，再考慮只供路由使用的嗅探策略。把不同文章中的嗅探選項拼湊在一起，通常比保留用戶端預設設定更難排錯。

辨識快取殘留與旁路查詢

關閉 FakeDNS 後，應用程式可能仍在使用已快取的虛擬位址。此時應關閉相關應用程式的連線，清除必要的解析快取後再測試；只重新啟動核心不一定能清除瀏覽器或系統中的結果。反過來說，啟用後若應用程式仍使用原本的真實位址，也不能立刻判定 FakeDNS 未運作。請先發出一筆確定經過目標解析路徑的新查詢，再檢查回傳位址及後續網域還原記錄。

應用程式內建 DNS、固定 IP 連線及區域網路名稱都可能遇到特殊情況。固定 IP 原本就沒有網域可供還原；內部網域則需要能解析它的真實解析器。建議先讓 FakeDNS 只套用於可控的測試範圍，確認網頁、區域網路及必要應用程式都正常後，再擴大使用範圍。若問題只在啟用後出現，優先恢復一般 DNS 與原有接管方式，保留記錄檔供比對；不要同時擴大位址池並加入多組回退解析器。

六、多訂閱管理與更新注意事項

多訂閱管理的目標，是讓來源、更新及使用關係都能追蹤，而不是把所有項目合併成難以辨識的大清單。每個訂閱都應有獨立備註、更新策略及用途記錄，測試來源與日常來源也應分開。訂閱提供連線參數，但不應預設它會管理所有應用程式設定。匯入前先確認內容是伺服器清單，還是包含路由、DNS 等項目的完整設定，避免把影響範圍更大的變更當成一般伺服器更新。

分清來源下載與套用設定

更新可分成三個階段：取得遠端內容、解析成用戶端項目，以及將選取的項目用於目前連線。某一階段成功，不代表後續階段也已完成。看到更新完成後，應檢查項目變化與目前選取狀態，再建立新連線。有些應用程式會繼續使用既有連線，即使新設定已載入，也不能只靠舊網頁是否仍開啟來判斷切換結果。應確認新連線的實際出口及執行記錄。

也要另外確認訂閱更新所使用的網路路徑。透過目前代理取得訂閱，可能解決直連無法存取的問題；但若訂閱正是用來修復目前失效的伺服器，就會陷入「更新依賴失效連線」的困境。應保留可用的更新方式或獨立備用設定，並確認哪些來源需要透過代理。不了解欄位用途時，不要反覆切換更新代理選項；先找出錯誤發生在連線、授權、憑證還是解析階段。

降低自動更新帶來的不確定性

自動更新適合穩定的來源，但應安排在方便檢查結果的時段，不要一開始就設定成頻繁更新。先手動更新數次，確認來源格式穩定且能保留項目選取狀態，再啟用自動更新。若訂閱含有時效性授權資訊，也要留意網址是否可能失效。頻繁重試無法修復授權問題，反而會讓記錄檔充滿重複錯誤，掩蓋最初的原因。

若用戶端允許更新時保留原有項目或刪除失效項目，應先了解兩者的取捨：保留有助於暫時回復，但清單可能累積已無法使用的設定；刪除能讓清單與來源保持一致，卻可能讓目前使用的項目立即消失。請先確認是否有獨立備份，再決定清理方式。曾手動修改的伺服器，不應假設訂閱更新後會保留修改；必要時請複製成有明確標記的獨立設定。

合併、去重與來源可信度

去重時應比較實際連線參數，而不只是備註。相同伺服器位址可能對應不同連接埠、傳輸路徑或安全設定，不能直接合併；名稱不同也可能只是同一連線的重複表示。請先整理單一來源，再檢查不同來源之間的重複項目，並保留來源標記。若用戶端的自動去重演算法未說明比對欄位，先在測試分組試用並檢查結果，不要直接對所有日常項目進行不可逆的清理。

來源也可能附帶遠端資源網址或不熟悉的擴充欄位。只匯入必要內容；若遇到要求覆蓋系統設定、修改所有路由或額外授權的步驟，請先停下來確認用途。不要把訂閱網址交給不明的線上轉換服務，因為網址可能含有存取憑證，轉換過程也可能改變設定語意。若來源格式不相容，優先確認提供者支援哪些用戶端格式，再考慮可在本機檢視的處理方式。

移轉裝置時保留設定關係，不複製全部執行狀態

跨裝置移轉時，建議記錄分組名稱、訂閱用途、必要規則及手動設定，再透過用戶端支援的匯出與匯入功能完成。桌面版的路徑、連接埠及網路權限不應直接套用至 Android；裝置專用的 TUN 設定也需要重新確認。匯入後依序更新各來源，先恢復一條基本連線，再補上進階規則。如此便能區分來源問題與平台差異，不必面對同時包含多種變更的故障狀況。

七、自訂出站與標籤引用

出站定義連線離開核心時採用的處理方式，路由則透過標籤引用出站。常見的代理、直連與阻斷並非三個固定按鈕，而是彼此相關的設定物件。開始自訂前，先確認用戶端允許編輯的是完整設定、局部出站，還是圖形路由欄位；這些入口的合併方式各不相同。直接修改執行時的暫存檔，可能在切換伺服器或重新啟動後被覆蓋，不能當作穩定的設定來源。

先建立可追蹤的標籤關係

每個需要引用的出站都應使用清楚且唯一的 tag；路由中的 outboundTag 必須完全一致。大小寫、空格或拼字不同，都可能導致引用失敗。以下範例完整展示兩個基本出站物件，但不建議用它取代用戶端的整個出站陣列；若直接替換，原有代理出站也會消失。應在既有設定結構中確認是否已有同名物件，避免重複定義。

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

freedom 表示依本機網路狀況直連目標，blackhole 則用來丟棄符合條件的連線。直連不代表目標一定可連線，仍會受本機 DNS、位址類型、閘道及防火牆影響。阻斷也不一定會顯示一致的錯誤，應用程式可能顯示連線失敗或自行重試。測試時應參考實際出口記錄，不要只根據網頁訊息推斷規則是否生效。

預設出口與明確路由都要檢查

未符合路由規則時，一般核心設定通常會使用第一個出站；用戶端也可能自行產生兜底規則。因此，調整出站順序會實際改變行為，不只是整理清單。若單獨使用上方片段，第一個項目是直連，絕不等同於「預設代理」。若要預設走代理，應確認既有代理物件的位置或用戶端產生的最終規則；不能因介面已選取伺服器，就忽略完整設定中的實際順序。

若要讓某項業務使用獨立出口，先確認最終設定中確實存在對應物件，再加入最具體的路由條件。訂閱分組中的多個伺服器通常不會自動全部成為可引用的出站，目前選取的伺服器也可能始終使用固定標籤。若要同時使用多個出口，必須由用戶端支援相應的產生功能，或自行維護可完整啟動的自訂設定；只把伺服器備註填成標籤，並不會建立出站。

代理鏈必須明確設定撥號關係

多級轉送與多出口選擇是兩回事。多出口選擇會讓不同連線使用不同路徑；代理鏈則讓同一連線依序經過多個處理階段。設定鏈式撥號前，先確認目前核心支援的欄位、每一級伺服器的可連線狀態，以及是否會形成回送。未確認協定支援範圍前，不要把某個核心的撥號欄位直接複製到另一個核心。先分別驗證每個出口，再組合成鏈路，才容易定位故障所在。

為出站指定介面或來源位址時，也要考慮網路變化。固定使用無線介面，切換到有線網路後可能失效；固定來源位址則可能在重新取得位址後不再屬於本機。這類欄位適用於網路條件明確的情境，不應作為所有連線失敗時的通用修復方式。若只需要一般直連，保留系統路由通常更容易維護；確實需要多網卡時，再記錄介面變更後的檢查與回復步驟。

檢查產生結果，再保存為長期設定

儲存自訂內容後，先執行用戶端提供的設定檢查，再查看實際啟動記錄。重點確認標籤是否唯一、引用對象是否存在、預設出口是否正確，以及自訂物件是否遭到合併或覆蓋。若介面設定與執行結果不一致，應以實際生效的設定為排查依據。生態系與核心差異可參閱Project V、V2Fly 與 Xray 關係說明；確認設定支援範圍後，再決定是否切換核心。

八、驗證、記錄檔與設定回復

進階設定應具備可重複的驗證流程。每次修改只處理一個明確問題，並在修改前寫下預期結果，例如「某個業務網域使用指定出站」或「區域網路位址仍然直連」。不要同時更新訂閱、切換核心、啟用 TUN 及更換 DNS，再只根據一次網頁存取判斷成敗。變更範圍越大，越難找出故障原因，最後往往只能全部還原，也無法保留有用的測試結論。

建立最小測試清單

至少準備四類檢查：一般網域存取、明確的直連目標、需要代理的業務連線，以及區域網路資源。每類都選擇穩定且有權限存取的目標，並記錄預期入口與出站。若涉及 UDP、雙堆疊或特定應用程式，再增加對應測試項目。測試時應建立新連線，不要反覆重新整理可能沿用舊工作階段的頁面；應用程式連線池與瀏覽器快取都可能讓設定切換看起來沒有生效。

依連線階段閱讀記錄檔

先確認核心是否正常啟動；若啟動尚未完成，就不必繼續測試遠端存取。接著檢查本機入口是否收到連線，再查看目標網域或位址、規則選擇及出站錯誤。連接埠被占用屬於本機監聽階段，解析失敗屬於 DNS 階段，連線逾時可能與遠端可達性有關，憑證錯誤通常則出現在安全交握階段。這些問題不能一律用「更換伺服器」處理。

記錄層級應符合目前的排錯需求，完成後請恢復日常層級，避免長期啟用過於詳細的記錄。分享記錄檔時，請隱藏訂閱網址、使用者識別資訊、驗證欄位及不必要的內部網域，只保留錯誤前後的相關行。時間點也很重要：盡量清楚標示哪幾行記錄對應哪次手動測試，避免把背景應用程式的請求誤認為目標請求。常見錯誤的進一步解析，請參閱執行記錄閱讀方法。

依最近的變更逐步回復

回復時先撤銷最近一項變更，再重新測試基準狀態。若問題由 FakeDNS 引起，恢復一般 DNS 後還需清除舊映射結果；若由 TUN 引起，關閉接管後應檢查系統路由與 DNS；若由自訂出站引起，則恢復標籤及預設出口順序。不能只關閉介面上的某個開關，就認定所有衍生狀態都已撤銷。每完成一步回復，都要檢查新連線，避免快取造成誤判。

長期保留一份已驗證的設定及必要說明，內容應包括用戶端、實際核心、入口方式、依賴的規則資源與特殊權限。備份不必包含所有暫存記錄檔，但應足以還原重要設定關係。軟體更新後，先確認基本連線，再檢查自訂項目；若發生啟動當機，可參閱啟動閃退與目錄權限排查，不要把應用程式無法啟動誤判為路由故障。

整理有效設定，方便日後查閱

驗證通過後，為每項非預設設定寫下一句原因，例如「此網域必須使用內部解析」、「此業務使用獨立出口」。記錄應說明需求，而不只是抄下欄位值；環境改變時，才能判斷該設定是否仍有必要。更新訂閱、切換網路或更換核心後，重新檢查直接相關的項目；未受影響的部分不必全部重做，才能讓維護工作保持可控。

若仍無法找出問題，請將範圍縮小至一條連線、一組規則及一個出口，準備已去除敏感資訊的設定片段與相關記錄，再參閱故障排查問答。若要重新建立基本操作流程，請回到入門指南；若要調整安裝平台或裝置架構，請前往下載中心。本指南旨在讓每次設定變更都有依據、可驗證，也有明確的回復方式。