全平台指南

用戶端與平台如何對應

桌面裝置建議優先使用 v2rayN。它支援 Windows、macOS 與 Linux，適合透過圖形介面管理訂閱、節點、路由與代理狀態。Android 上建議優先考慮 v2rayNG；若訂閱或使用環境明確以 V2Fly 核心為主，也可以選擇 v2flyNG。兩款 Android 用戶端的介面細節與核心取向不同，但基本流程相同：匯入訂閱、更新節點、選擇設定、啟動本機 VPN 接管，接著進行存取驗證。

不要把用戶端、核心與訂閱混為一談。用戶端負責介面、設定管理與系統接管；Xray 或 V2Fly 等核心負責依設定建立連線與處理流量；訂閱連結則由服務提供者產生，通常包含伺服器位址、連接埠、使用者識別碼、傳輸方式，以及 TLS 或 REALITY 等參數。安裝用戶端不會自動產生可用節點，訂閱匯入成功也不代表其中每個節點都能連線。

準備訂閱資訊，但不要急著重複匯入

開始前應準備一個仍在有效期限內且可正常存取的訂閱網址。訂閱連結屬於敏感設定資料，不應貼到公開貼文、截圖或多人共用的文件中。若服務提供者給的是單一 VMess、VLESS 或其他分享連結，可以使用用戶端的「從剪貼簿匯入」功能；若提供的是訂閱網址，則應建立訂閱群組並執行一次更新。兩種入口處理的對象不同：單一連結通常會產生一個節點，訂閱網址則可能產生一組由服務提供者維護的節點。

首次匯入前，先檢查連結頭尾是否含有空格、通訊軟體是否截斷參數、瀏覽器是否改寫特殊字元。匯入後，重點查看節點名稱與數量是否符合預期，不要立即連續點擊更新。若訂閱更新失敗，應先判斷是網址本身無法存取、系統時間錯誤、憑證交握失敗，還是目前網路需要先透過既有代理才能存取訂閱服務。持續重複更新只會產生更多相同日誌，不會改變根本原因。

記錄原有代理與 DNS 狀態

設定前先記錄系統代理是否啟用、區域網路位址是否手動設定、瀏覽器是否安裝獨立代理規則，以及系統 DNS 是否為手動值。最穩妥的做法是擷取系統網路設定，或將關鍵值記錄在本機筆記中。之後若出現網頁無法開啟、區域網路裝置失聯，或退出用戶端後仍殘留代理，就能依原狀態復原。尤其在公司、學校或需要固定代理的網路環境中，不應直接覆寫既有設定而不留下記錄。

也應確認系統時間與時區正確。TLS 與 REALITY 連線都依賴合理的時間判斷，明顯偏差可能表現為憑證失敗、交握中止，或連線剛建立便關閉。時間問題無法透過更換路由規則解決，因此應在協定參數之前檢查。

下載入口與架構選擇

所有用戶端入口集中在下載頁。Windows 常見裝置選擇 x64；macOS 需根據「關於這台 Mac」中的晶片類型選擇 Apple Silicon 或 Intel；Android 近年的主流裝置通常使用 arm64，不確定時可選通用套件；Linux 除了 x64 與 arm64 外，還要依發行版選擇 deb 或 rpm。架構選錯通常會表現為安裝程式拒絕執行、系統回報格式錯誤，或應用程式啟動後立即退出，這與訂閱是否可用無關。

安裝前關閉舊用戶端，並清除其仍在生效的系統代理，不必同時保留多個用戶端爭用同一個本機連接埠。若確實需要並行比較，應為每個用戶端設定不同的本機監聽連接埠，並明確目前由誰修改系統代理。準備工作完成後，再進入對應平台章節逐項操作。

選擇桌面版或經典 WPF 版

下載頁提供 v2rayN 桌面版與經典 WPF 版。桌面版採用新一代跨平台介面，適合希望在不同桌面系統間維持相近操作邏輯的使用者；WPF 版是 Windows 上長期使用的經典介面，選單位置與教學資料相對穩定。兩者都能完成訂閱管理、節點選擇、路由設定與系統代理控制。首次使用時只安裝其中一種，避免兩個執行個體同時常駐並修改同一套系統代理。

從Windows 下載入口取得合適的安裝套件後，先退出正在執行的舊版本。若使用安裝形式，依安裝介面選擇目前使用者可寫入的目錄；若採用解壓縮執行形式，應放在長期保留且具有寫入權限的位置，不要直接從壓縮檔預覽視窗啟動。用戶端需要寫入設定、日誌與核心相關檔案，目錄不可寫入會導致設定儲存失敗，或每次啟動都像首次執行。

首次啟動與訂閱群組

啟動 v2rayN 後，先進入訂閱群組管理，新增群組名稱並貼上訂閱網址。群組名稱應表達用途，例如「日常訂閱」或「測試群組」，不建議將完整訂閱網址當作名稱。儲存後執行更新訂閱，並在主清單中確認節點確實寫入。若清單仍為空白，查看提示訊息與日誌：網址回傳網頁而非訂閱內容、連結已過期、存取被重新導向至登入頁，都會造成解析失敗。

訂閱群組是管理入口，不是連線狀態。更新成功只代表用戶端取得並解析了設定。接著選擇一個節點作為目前使用項目，再執行實際連線測試。測試時優先觀察能否建立連線，以及日誌是否出現明確錯誤，不要只看下載測速。測速還會受到目標伺服器、線路壅塞與本地頻寬影響，不能單獨證明系統代理已接管瀏覽器。

從單一連結匯入與核對參數

如果取得的是單一分享連結，可以複製後使用「從剪貼簿匯入批次 URL」。匯入完成後開啟節點編輯介面，核對伺服器位址、連接埠、使用者識別碼、傳輸方式、安全層與伺服器名稱等欄位是否完整。VLESS 設定使用 TLS 或 REALITY 時，還可能包含 flow、指紋、公鑰、短識別碼與 serverName。不要為了「相容」而隨意刪除不熟悉的參數；這些值往往必須與伺服器端一致。

遇到 VMess 與 VLESS 不知道如何選擇時，不必只依協定名稱判斷速度。協定負責身分與資料格式，TLS、REALITY、WebSocket、gRPC 等則屬於安全與傳輸組合，最終能否使用取決於整套參數是否匹配。可進一步閱讀VMess 與 VLESS 參數差異，再回到用戶端逐項比對。

先測試系統代理

對大多數瀏覽器與遵循 Windows 系統代理的桌面應用程式，首次設定先使用系統代理較容易定位問題。在 v2rayN 的系統代理選單中選擇「自動設定系統代理」，再依需求選擇路由模式。此操作會將系統代理指向用戶端的本機監聽連接埠，但不代表所有應用程式都會自動遵循。部分遊戲、命令列工具、虛擬機器與自行實作網路堆疊的軟體可能繞過系統代理。

啟用後先造訪一個平時能穩定開啟的普通網站，確認基礎網路未中斷，再造訪用於驗證代理路徑的目標網站。同時查看用戶端日誌是否出現對應連線。如果瀏覽器仍使用舊連線，可以完全關閉後重新開啟瀏覽器，或建立無快取的新視窗重新測試。詳細的交叉確認方法可參考v2rayN 首次連線驗證。

TUN 的權限與界線

當應用程式不遵循系統代理，或需要統一接管更多網路流量時，再考慮 TUN。TUN 會建立虛擬網路介面並透過路由規則接收流量，通常需要管理員權限與驅動程式支援。啟用前先清除系統代理，或明確劃分兩者職責，避免同時開啟後無法判斷實際路徑。若啟動時提示權限不足，應退出用戶端後以管理員身分執行；若虛擬介面建立失敗，則檢查舊 TUN 驅動程式、其他 VPN 類軟體與安全性原則是否衝突。

TUN 不是「連線更快」的開關，它改變的是接管範圍。區域網路存取、虛擬機器網路、開發環境與公司內網可能受到路由影響。啟用後應測試本機閘道、區域網路裝置與常用內網網域，並確認私有位址由直連規則涵蓋。出現內網無法存取時，先關閉 TUN 驗證是否恢復，再檢查 geoip:private 或私有網段直連規則，而不是立即更換節點。

Windows 常見衝突

連接埠被占用是 Windows 上的常見問題。若日誌提示本機監聽失敗，檢查是否有另一個 v2rayN 執行個體、舊用戶端或除錯工具使用相同連接埠。不要只隨意改成更大的連接埠；修改後還需讓系統代理、瀏覽器擴充功能與依賴該連接埠的應用程式同步更新。安全軟體攔截核心程序時，也可能出現介面正常但完全沒有連線日誌的情況，應結合系統事件與用戶端日誌判斷。

另一個常見誤區是把「延遲測試有結果」當作連線完成。延遲測試可能只驗證 TCP 建立連線，實際連線測試才會依節點協定發起真實請求。即使實際連線成功，系統代理未啟用時，瀏覽器仍可能直接連線。完整驗證順序應為：選擇節點、執行實際連線測試、啟用一種接管方式、重新發起瀏覽器請求、在日誌中找到對應網域或目標連線，最後再測試其他應用程式。

先確認 Apple Silicon 或 Intel

開啟系統的「關於這台 Mac」查看晶片資訊。顯示 Apple M 系列時選擇 arm64 安裝套件；顯示 Intel 處理器時選擇 x64 安裝套件。架構與用戶端功能沒有高低之分，只需與裝置匹配。若在 Apple Silicon 裝置上誤裝 Intel 建置版本，系統可能要求額外的轉譯環境，也可能出現效能或相容性問題，因此應優先使用原生 arm64 版本。

從macOS 下載入口取得對應的 dmg 後，開啟磁碟映像並將應用程式拖曳至「應用程式」目錄，再從該目錄啟動。不要長期從唯讀磁碟映像中執行，因為應用程式更新、輔助元件與設定寫入可能受到限制。首次啟動若遭系統阻止，應在「隱私權與安全性」設定中查看這次攔截紀錄並確認執行，而不是關閉整個系統安全機制。

匯入訂閱與選擇節點

進入訂閱群組管理，新增訂閱名稱與網址，儲存後執行更新。macOS 上常見的訂閱失敗不一定來自用戶端：系統 DNS 無法解析、目前網路需要網頁驗證、時間不準確或訂閱服務憑證異常，都可能導致請求失敗。先用瀏覽器確認網路驗證已完成，再查看日誌是解析失敗、連線逾時，還是回傳內容無法辨識。

節點出現後，先選擇一個設定執行實際連線測試。若同一訂閱中只有部分節點失敗，應比較失敗節點的伺服器名稱、連接埠、傳輸方式與 TLS 或 REALITY 參數，不要直接刪除整個訂閱。若所有節點都在交握階段失敗，則優先檢查系統時間、網路是否攔截目標連接埠，以及訂閱是否已更新至新的使用者識別碼。

系統代理適用於哪些應用程式

macOS 系統代理會寫入目前網路服務的代理項目。瀏覽器與遵循系統網路設定的應用程式通常能使用，但終端機命令、部分開發工具與自行維護連線的程式未必會跟隨。啟用後應進入系統網路詳細資料，查看代理狀態是否變更，並確認目前操作的是正在使用的網路服務。裝置同時保留無線網路、有線網路或多個網路位置時，修改錯誤的服務會表現為用戶端顯示已啟用，但實際流量沒有變化。

命令列工具通常需要自己的環境變數或設定。若只想讓目前的終端機工作階段暫時使用用戶端監聽連接埠，可以依用戶端實際顯示的本機連接埠設定環境變數。以下僅展示寫法，連接埠應以本機設定為準：

export http_proxy="http://127.0.0.1:本機HTTP連接埠"
export https_proxy="http://127.0.0.1:本機HTTP連接埠"
export all_proxy="socks5://127.0.0.1:本機SOCKS連接埠"

這類環境變數只會影響目前 shell 及其子程序，不應在未確認連接埠的情況下永久寫入啟動檔。測試結束後可執行 unset http_proxy https_proxy all_proxy 還原。若工具本身支援獨立代理設定，優先在工具內明確設定，方便之後辨識來源。

TUN 與網路擴充功能授權

需要接管不讀取系統代理的應用程式時，可以評估 TUN。首次啟用可能觸發管理員驗證或網路擴充功能授權。完成授權後仍應回到用戶端確認虛擬介面是否成功建立，並在日誌中觀察路由寫入結果。只看到系統彈窗並點選允許，不代表 TUN 已穩定執行；介面建立、DNS 接管與路由下發都可能個別失敗。

在 macOS 上同時執行其他 VPN 類工具、網路過濾器、企業安全軟體或虛擬化網路時，路由優先順序可能互相影響。疑難排解時先關閉其他會修改預設路由或 DNS 的程式，只保留 v2rayN 與基礎網路。若問題消失，再逐一恢復程式。不要同時切換節點、路由模式與多個網路擴充功能，否則日誌時間線會混在一起。

睡眠喚醒與 DNS 快取

裝置從睡眠狀態恢復後，網路介面與預設路由可能重新分配。若用戶端介面仍顯示執行中，但新請求持續逾時，可先停止接管、等待網路恢復，再重新啟動。頻繁切換無線網路時也應如此。若網域連線失敗而直接存取已知 IP 的測試正常，問題更可能出在 DNS 路徑，應檢查用戶端 DNS 設定、系統解析結果，以及路由規則是否將 DNS 請求送往無法存取的出口。

不要把清除 DNS 快取當成固定步驟。只有在網域記錄明顯過期、切換解析策略後仍回傳舊值時，才需要處理。多數代理問題來自接管方式、路由匹配或節點參數，反覆重新整理快取不會修復交握失敗。退出用戶端前先清除系統代理；若使用 TUN，則先正常停止 TUN，讓用戶端撤銷介面與路由後再退出。

選擇 arm64 或通用套件

近年的主流 Android 手機通常使用 arm64 架構，確認裝置架構時優先選擇 arm64 套件；無法確認或安裝程式提示不相容時，可使用通用套件。通用套件涵蓋範圍較廣，但體積通常會包含多種架構資源。架構只決定應用程式能否在處理器上執行，不會改變節點協定與訂閱內容。下載入口依 v2rayNG 在前、v2flyNG 在後的順序列出，可前往Android 下載區選擇。

安裝前若裝置中已有同名應用程式，應確認簽章來源與現有設定是否需要保留。系統拒絕覆蓋安裝時，不要直接解除安裝後才想起尚未備份訂閱。可以先記錄訂閱網址、路由模式、應用程式分流與 DNS 設定，再決定升級或重新安裝。訂閱網址屬於敏感資訊，備份檔案也應只儲存在受控位置。

匯入訂閱與單一節點連結

開啟 v2rayNG 後，可以透過訂閱群組新增網址並更新，也可以從剪貼簿匯入單一分享連結。若使用 QR Code，應確認 QR Code 來自可信來源，掃描後仍需檢查伺服器位址、連接埠、使用者識別碼、傳輸方式與安全參數。掃描只是減少手動輸入，不會驗證設定是否正確。

訂閱更新後，點選節點名稱使其成為目前設定，再啟動連線。Android 會要求建立 VPN 連線，這是系統為本機流量接管提供的標準授權。若裝置已有其他 VPN 類連線，系統通常只允許其中一個保持啟用，應先停止舊連線。拒絕授權彈窗後，用戶端無法僅靠背景服務完成接管，需要重新啟動並允許授權。

應用程式分流與繞過選項

應用程式分流用於決定哪些應用程式進入本機 VPN 介面。首次連線建議暫時不要啟用複雜分流，先讓一個瀏覽器完成驗證。確認基礎連線正常後，再依「僅代理選取的應用程式」或「繞過選取的應用程式」邏輯設定。兩種模式的含義相反，切換後應重新檢查清單，避免將目標應用程式放到錯誤的一側。

銀行、區域網路控制、投放畫面與裝置探索類應用程式可能依賴本地網路，應依實際需求設定直連。將應用程式設為直連不代表它不受 DNS 影響；若 DNS 請求仍由用戶端接管，網域解析結果也可能改變。遇到某個應用程式異常而瀏覽器正常時，先清除該應用程式的分流限制重新測試，再檢查它是否使用 QUIC、私有 DNS 或固定位址，不要先修改全域節點。

背景限制與斷線重連

Android 製造商常對背景服務實施電池最佳化、休眠與自動啟動限制。常見表現是鎖定螢幕一段時間後連線停止、切換網路後未恢復，或系統回收用戶端程序。處理時先在系統電池統計中確認用戶端是否受到限制，再為其選擇合適的背景策略。並非所有裝置都需要完全解除限制；應先觀察，再只調整影響連線的項目，避免把持續流量誤判為系統限制。

頻繁重連也會增加耗電。若日誌中反覆出現網路變更、連線逾時與立即重試，應區分是行動網路訊號不穩、節點無法存取，還是系統在背景暫停網路。可以在同一地點保持螢幕亮起測試一段時間，再鎖定螢幕比較。詳細疑難排解順序請見v2rayNG 背景耗電異常疑難排解。

私有 DNS 與用戶端 DNS

系統私有 DNS、瀏覽器內建安全 DNS 與用戶端 DNS 可能同時存在。首次排查時應先釐清目前由誰解析網域。若系統私有 DNS 設為嚴格主機名稱，但該服務在目前網路中無法存取，可能在代理啟動前就造成網域解析失敗。可先恢復自動模式驗證，再決定是否讓用戶端接管 DNS。

用戶端 DNS 的作用不只是「更換伺服器」，還涉及網域請求經由哪個出口傳送、路由規則依網域還是解析後的 IP 進行匹配，以及是否需要避免本地結果與代理出口不一致。若只有網域失敗而節點伺服器位址是 IP，可重點檢查 DNS；若伺服器位址本身無法建立 TCP 或協定交握，調整 DNS 伺服器通常沒有作用。

切換無線網路與行動網路

網路切換會更換本地位址、預設路由與 NAT 狀態，原有連線可能無法繼續重用。切換後等待系統網路穩定，再觀察用戶端是否自動重建。如果介面顯示已連線但沒有新日誌，可停止後重新啟動本機 VPN。不要快速連續點擊啟動按鈕，以免舊服務尚未釋放介面時又建立新的執行個體。

排查完成後，如果只在某個無線網路失敗而行動網路正常，檢查該網路是否需要網頁登入、是否限制目標連接埠，以及 DNS 是否回傳異常結果。若兩個網路都失敗，再回到節點參數、訂閱有效性與系統時間。透過這種對照，可以將「裝置設定問題」與「目前網路問題」區分開來。

deb、rpm 與處理器架構

Debian、Ubuntu 及其常見衍生發行版通常使用 deb；Fedora、Rocky Linux、openSUSE 等環境常見 rpm，但具體仍應以發行版套件管理體系為準。一般桌上型電腦多為 x64，arm64 常見於部分開發板與 ARM 桌面裝置。可以執行 uname -m 查看架構：常見輸出 x86_64 對應 x64，aarch64 對應 arm64。

uname -m
cat /etc/os-release

從Linux 下載入口取得相符的 v2rayN 套件。安裝本機 deb 時，可在套件所在目錄使用系統套件管理器處理相依性；rpm 發行版也應使用自身的套件管理器，而不是只解壓縮檔案。以下命令中的檔案模式需要與實際下載名稱相符，並確認目錄中沒有多個舊套件：

sudo apt install ./v2rayN*.deb
sudo dnf install ./v2rayN*.rpm

若系統提示架構不相符，回到下載頁重新選擇，不要使用強制參數跳過。若提示缺少相依套件，先重新整理發行版軟體來源，並確認桌面環境版本受到支援。以強制忽略相依性的方式安裝，往往只會將錯誤延後至啟動階段。

首次啟動與設定目錄

從桌面應用程式選單啟動 v2rayN，確認介面、系統匣與設定儲存都正常。若從終端機啟動能看到錯誤，而桌面選單沒有反應，可以從終端機執行應用程式入口，觀察缺少函式庫、顯示服務或權限提示。不要長期以 root 身分執行整個圖形用戶端，否則設定目錄可能歸 root 所有，之後普通使用者啟動時將無法寫入。

訂閱管理流程與其他桌面平台一致：新增群組、貼上訂閱網址、儲存、更新、選擇節點並執行實際連線測試。Linux 桌面通常會區分系統與使用者工作階段的代理設定，因此用戶端顯示「設定成功」後，還應進入桌面網路設定，檢查目前使用者的代理值。若使用輕量桌面或獨立視窗管理器，可能沒有統一的系統代理介面，需要為瀏覽器與特定應用程式分別設定。

桌面代理與環境變數

GNOME、KDE 等桌面環境提供系統代理設定，但應用程式是否遵循仍取決於其網路實作。瀏覽器通常可以跟隨桌面代理，終端機工具則經常讀取環境變數或自己的設定。暫時測試時可在目前 shell 設定代理變數，結束後立即取消：

export http_proxy="http://127.0.0.1:本機HTTP連接埠"
export https_proxy="$http_proxy"
export all_proxy="socks5://127.0.0.1:本機SOCKS連接埠"

# 測試結束
unset http_proxy https_proxy all_proxy

這裡的連接埠必須從 v2rayN 設定中讀取。若用戶端只監聽本機回環位址，區域網路中的其他裝置不能直接使用該連接埠，這是較穩妥的預設界線。只有明確需要共用代理時才考慮監聽區域網路位址，同時檢查防火牆與存取控制，避免將未授權的代理入口暴露給同一網路中的其他裝置。

TUN、權限與路由衝突

Linux TUN 依賴核心裝置、網路管理權限與路由寫入能力。首先確認 /dev/net/tun 存在，再從用戶端日誌判斷是裝置不可用、權限不足，還是路由規則寫入失敗。不要直接為整個應用程式永久授予 root 權限。優先使用用戶端提供的授權流程或系統能力設定，並了解升級後可執行檔變更可能使舊授權失效。

ls -l /dev/net/tun
ip route
ip rule

容器、虛擬機器、公司 VPN 與多網卡環境可能已有策略路由。啟用 TUN 前儲存 ip route 與 ip rule 輸出，啟用後再比較新增項目。若內網失聯，重點檢查私有網段是否被送入 TUN、預設路由優先順序是否變更，以及 DNS 請求是否進入不同的命名空間。關閉 TUN 後應確認新增介面與規則已撤銷。

DNS 與 systemd-resolved

Linux 的解析鏈可能包含應用程式、glibc、NetworkManager、systemd-resolved 與上游 DNS。修改用戶端 DNS 後，不能只看 /etc/resolv.conf 的表面內容，因為它可能是指向本機解析服務的連結。可使用 resolvectl status 查看每個介面的 DNS 與網域設定，再結合用戶端日誌判斷查詢是否真正進入代理。

resolvectl status
getent hosts example.com
ss -lntup

ss 可用於確認本機代理連接埠是否正在監聽，以及是否發生衝突。若用戶端退出後網路異常，先清除桌面代理與 shell 環境變數，再檢查 TUN 介面與策略路由。重新啟動裝置雖然可能恢復狀態，但會遺失最有價值的現場資訊；在重新啟動前儲存日誌與路由輸出，更有利於找出根本原因。

接管方式決定哪些流量進入用戶端

系統代理本質上是向應用程式提供一個 HTTP 或 SOCKS 代理入口。只有讀取並遵循系統設定的應用程式才會使用它，優點是界線清楚、啟用與復原簡單，適合瀏覽器與多數桌面程式。TUN 則透過虛擬介面與路由接收流量，能涵蓋更多不支援代理設定的應用程式，但也更容易影響區域網路、虛擬化環境與既有網路工具。

兩種方式不一定要同時啟用。首次設定應從系統代理開始：如果目標應用程式能被接管，就沒有必要為了「更完整」而立即增加 TUN。只有確認某類應用程式繞過系統代理，且確實需要統一接管時，再啟用 TUN。Android 的本機 VPN 接管在體驗上更接近 TUN，但應用程式分流由系統介面與用戶端共同完成。

路由規則依序匹配

路由負責決定已進入核心的流量經由哪個出口。常見條件包括網域分類、IP 分類、連接埠、網路類型與程序。規則通常依序匹配，先命中的規則生效，因此更具體的規則應放在更通用的規則之前。若一條涵蓋範圍很大的代理規則排在前面，後面的區域網路直連規則可能永遠沒有機會執行。

以下是一段用於說明結構的路由片段。它先讓常見私有位址與指定分類直連，其餘行為由設定中的後續規則與預設出口決定。實際使用時，出口標籤必須與用戶端產生的出站設定一致：

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

domainStrategy 決定路由判斷是否以及何時解析網域。使用 AsIs 時優先依原始網域規則匹配；其他策略可能在需要時解析為 IP 再進行判斷。沒有任何一種策略適合所有環境。若依賴網域分類分流，應確保請求抵達核心時仍保留網域資訊；若應用程式直接連線至 IP，網域規則自然無法命中。

GeoIP 與 GeoSite 資料

GeoIP 是 IP 分類資料，GeoSite 是網域分類資料。路由規則引用的是分類標籤，不是「自動智慧分流」。資料庫缺失、標籤不存在或核心版本不相容時，用戶端可能啟動失敗，也可能在日誌中回報規則載入錯誤。更新資料後應檢查日誌，確認新檔案已被讀取，並保留原有檔案以便復原。完整維護流程可參考GeoIP 與 GeoSite 資料庫更新指南。

不要在一次調整中同時更換資料庫、規則集與核心。若更新後出現問題，先恢復原始資料並保持規則不變；恢復正常後，再單獨驗證新資料是否包含所需標籤。規則標籤名稱拼寫錯誤時，更換節點不會有幫助。

DNS 應與路由路徑一致

DNS 決定網域取得哪個位址，路由決定請求如何抵達該位址。若網域透過本地 DNS 取得無法存取或與出口不匹配的結果，連線會在協定交握前失敗。若 DNS 請求本身需要透過代理存取，則必須確保啟動階段已有可用的基礎解析路徑，避免出現「需要先解析代理伺服器，而解析又依賴代理」的循環。

排查 DNS 時先用日誌確認請求是否抵達用戶端，再比較系統工具與用戶端內的解析結果。只有網域失敗、直接位址可達時，才應重點檢查解析鏈；若 TCP 連線已建立後在 TLS 或 REALITY 階段失敗，應核對 serverName、公鑰、短識別碼、指紋與系統時間。將交握錯誤當成 DNS 問題，會把疑難排解帶往錯誤方向。

四步驗證法

第一步確認訂閱更新結果。節點清單應出現預期內容，目前節點的關鍵參數也要完整。第二步執行實際連線測試，觀察用戶端是否能依協定建立真實請求。第三步啟用一種接管方式，並讓目標應用程式發起全新的網路請求。第四步在日誌中找到與該請求時間相符的網域、目標位址、路由出口或錯誤資訊。四步全部成立，才能表示「節點可連線且應用程式流量確實進入用戶端」。

如果實際連線測試成功但瀏覽器沒有變化，重點檢查系統代理、瀏覽器獨立代理、舊連線快取與目前網路服務。如果瀏覽器請求已進入日誌但失敗，則查看失敗發生在 DNS、TCP、TLS、REALITY 還是遠端關閉階段。如果日誌完全沒有目標請求，表示接管環節尚未成立，不應先調整協定參數。

依錯誤階段閱讀日誌

日誌中的「解析失敗」通常表示網域未取得可用位址；「連線逾時」表示在限定時間內未完成網路連線，但原因可能是目標無法存取、連接埠受限或路由錯誤；「連線被拒絕」表示目標位址有明確回應，但該連接埠未接受連線；TLS 或 REALITY 交握錯誤則更應檢查伺服器名稱、時間、公鑰、短識別碼與指紋等參數。

日誌應依時間線閱讀，不要只截取最後一行。最後一行可能只是上層對前面錯誤的總結。重現問題前先清空日誌或記住目前時間，只執行一次目標操作，再儲存從請求開始到失敗結束的連續片段。公開求助時應遮蓋訂閱網址、使用者識別碼、伺服器位址與其他敏感參數，但保留錯誤類型、時間順序與用戶端操作步驟。

用對照實驗縮小範圍

有效的對照只改變一個變數。例如在兩個網路下測試同一節點，可以判斷目前網路是否造成問題；在同一網路下更換同一訂閱中的另一個節點，可以比較節點差異；保持節點不變，分別測試系統代理與 TUN，可以判斷接管方式；保持其他設定不變，恢復預設 DNS，可以判斷自訂解析是否引入異常。

無效的對照通常一次改變太多項目：同時更新訂閱、切換節點、啟用 TUN、替換 DNS 與更新規則資料庫。即使問題暫時消失，也無法知道是哪項變更生效，下一次故障仍要從頭開始。建議為穩定設定保留一份文字記錄，包括用戶端、接管方式、路由模式與必要的自訂項目。

訂閱更新與設定備份

訂閱更新可能增加、刪除或修改節點。更新前若有手動調整的重要設定，應確認用戶端是否會在更新時覆寫。訂閱節點與本機自建節點最好分組管理，避免更新訂閱時誤刪本機內容。更新後先比較節點數量與名稱變化，再選擇一個節點驗證，不必立即對所有節點進行高頻測試。

備份應包含訂閱群組資訊、必要的路由設定與自訂 DNS，但不要將敏感資料放入公開同步空間。還原備份後仍需重新確認系統權限、TUN 授權與本機連接埠，因為這些狀態可能未完全包含在用戶端設定中。跨平台遷移時也不要假設所有設定欄位都能一一對應，應優先重新匯入訂閱，再手動還原少量必要策略。

更新用戶端、核心與規則資料

用戶端介面、代理核心與 GeoIP、GeoSite 資料屬於不同層級。更新用戶端可能帶來介面或設定格式變更；更新核心可能影響協定參數支援；更新規則資料則會影響分類標籤。穩定環境中應分開更新，每次更新後完成一次基礎連線、接管與路由驗證。若出現問題，才能準確復原對應層級。

不要依據網路上某個特定版本號判斷本機必須升級。本頁不固定版本資訊，實際可用套件以下載頁動態顯示為準。更新前退出正在執行的用戶端，並保留目前可正常工作的設定。更新後若舊設定無法載入，先查看遷移提示與日誌，不要立即覆寫原設定目錄。

訂閱更新成功，為什麼仍然無法存取？

訂閱更新成功只代表用戶端取得並解析了設定。接下來還要選擇節點、確認節點能完成實際連線、啟用一種接管方式，並驗證應用程式請求進入日誌。先檢查目前節點是否確實設為使用項目，再執行一次實際連線測試。若測試失敗，依日誌階段檢查網路、時間與連線參數；若測試成功但應用程式沒有請求日誌，檢查系統代理、TUN 或 Android 應用程式分流。

還要注意訂閱可能包含暫時無法使用或條件不同的節點。不要只測試清單第一項，也不要將所有節點失敗簡單歸因於用戶端。選擇同一訂閱中參數類型不同的少量節點進行對照，有助於判斷是單一節點問題還是整體訂閱問題。

系統代理和 TUN 需要同時啟用嗎？

通常不需要。先依目標應用程式選擇一種方式。瀏覽器與多數遵循系統代理的桌面應用程式先使用系統代理；不讀取系統代理、需要更廣泛接管範圍的應用程式，再評估 TUN。同時使用兩者可能仍能運作，但會增加路徑判斷難度，尤其是在 DNS、區域網路與虛擬網卡環境中。

從同時啟用的狀態開始排查時，先關閉 TUN，只保留系統代理並測試瀏覽器；系統代理驗證成功後，再清除系統代理並單獨測試 TUN。這樣可以確認兩個入口各自是否正常。不要在同一次測試中反覆切換而不關閉舊連線，應用程式可能繼續重用原有工作階段。

退出用戶端後為什麼網路異常？

最常見的原因是系統代理仍指向用戶端已停止監聽的本機連接埠。重新開啟用戶端，執行「清除系統代理」，再正常退出。Windows 與 macOS 還可以進入系統網路設定核對代理值；Linux 除了桌面代理外，還要檢查終端機環境變數。Android 則查看系統 VPN 狀態是否仍保留舊連線。

如果之前使用 TUN，還應確認虛擬介面與路由已撤銷。正常停止 TUN 通常會恢復，但強制結束程序、系統崩潰或權限異常可能留下狀態。Linux 可檢查 ip route 與 ip rule，桌面系統則先停用殘留虛擬介面或重新啟動網路服務。恢復網路後再分析日誌，不要一開始就刪除所有用戶端設定。

只有某個應用程式無法連線，應該更換節點嗎？

先不要更換。瀏覽器正常而單一應用程式異常，表示節點與基礎接管大致可用。檢查該應用程式是否遵循系統代理、是否被 Android 應用程式分流排除、是否使用獨立代理、固定 DNS、QUIC 或特殊網路權限。桌面應用程式若不讀取系統代理，可在其設定中指定本機 HTTP 或 SOCKS 連接埠，或單獨測試 TUN。

如果日誌能看到該應用程式的請求，但特定網域被直連或封鎖，再檢查路由規則。如果完全沒有請求日誌，問題仍在接管層。只有確認請求已進入用戶端，並在遠端連線階段失敗時，更換節點才是合理的對照方式。

REALITY 設定連線失敗，應檢查哪些欄位？

先確認伺服器位址、連接埠、使用者識別碼與 flow，再核對 serverName、公鑰、短識別碼與指紋。欄位名稱可能因用戶端介面而略有差異，但取值必須與伺服器端提供的設定一致。系統時間明顯偏差、訂閱參數被通訊軟體截斷、複製時遺漏字元，都可能導致交握失敗。

不要自行猜測缺少的值，也不要因為看到 VLESS 就預設關閉安全層。REALITY 是與連線安全相關的組合參數，不是單獨的節點名稱。若設定來自訂閱，先更新訂閱並比較服務提供者說明；若來自單一連結，重新匯入原始連結通常比手動修補更可靠。

更新 GeoIP 或 GeoSite 後用戶端無法啟動怎麼辦？

先查看日誌是否回報資料庫讀取失敗、分類標籤不存在或檔案格式不相容。恢復更新前的資料檔案，保持路由規則不變並重新啟動。若恢復後正常，表示問題集中在新資料或相容性關係；若仍然失敗，再檢查編輯規則過程中是否出現拼寫或 JSON 結構錯誤。

不要同時更換核心來掩蓋資料錯誤。應分別驗證核心、規則與資料庫。恢復穩定後，再確認目前核心支援所引用的標籤。資料更新與載入復原的完整步驟已在規則資料庫維護文章中說明。

DNS 應該填寫哪個位址？

沒有適用於所有網路的固定答案。首先確認 DNS 請求是本地直連還是透過代理出口傳送，再選擇在該路徑上穩定可達的解析服務。若沒有特殊需求，先保留用戶端預設策略完成連線驗證；只有出現網域解析異常、分流需求或隱私界線要求時，再單獨調整。

修改後使用系統解析工具、瀏覽器請求與用戶端日誌交叉確認。若直接位址也無法連線，問題通常不在 DNS；若網域取得位址後卻在 TLS 或 REALITY 階段失敗，應檢查連線參數。不要連續更換多個 DNS 位址而不記錄回傳結果。

如何復原至最小可用設定？

先停止 TUN，清除系統代理與應用程式分流，恢復預設 DNS 與基礎路由。保留一個來源明確的訂閱群組，更新後選擇一個節點執行實際連線測試。測試成功後只啟用系統代理，用一個瀏覽器發起新請求並核對日誌。桌面環境若目標應用程式不遵循系統代理，再單獨關閉系統代理、啟用 TUN 測試。

Android 上則先取消複雜的應用程式分流，保留系統 VPN 授權並使用瀏覽器測試；Linux 還要清除 shell 中的代理環境變數。最小設定穩定後，依路由、DNS、應用程式分流與背景策略的順序逐項恢復。每增加一項就重新測試一次，這比反覆重新安裝用戶端更快，也能保留問題發生的證據。