V2Ray 完整使用指南

一、核心概念與連線流程

客戶端、核心與伺服器各自負責什麼

V2Ray 通常指 Project V 相關的代理技術生態，並非內含連線服務的單一帳號方案。圖形化客戶端負責儲存伺服器資訊、管理訂閱、產生設定並啟動核心；核心處理入站連線、協定通訊與路由規則；遠端伺服器則接收符合設定的連線並轉送請求。安裝客戶端只是準備好本機工具，還需要取得有權使用的伺服器參數，才能建立完整的資料傳輸路徑。

V2Fly 與 Xray 是相關生態中的不同核心專案，支援的協定擴充功能與設定細節並不完全相同。v2rayN 提供桌面操作介面，v2rayNG 常用於 Android 上的 Xray 設定，v2flyNG 則提供 V2Fly 路線的選擇。客戶端能匯入某個名稱，不代表目前使用的核心支援其中所有選項；要確認相容性，還得檢查傳輸方式、安全層與擴充參數。

將伺服器參數拆成三層

第一層是代理協定，例如 VMess、VLESS、Trojan、Shadowsocks，決定連線雙方如何識別彼此及傳遞請求。第二層是傳輸方式，例如 TCP、WebSocket、gRPC，決定協定資料如何承載。第三層是安全相關設定，例如 TLS、REALITY 與伺服器名稱。三層設定都必須符合伺服器端配置，不能因為位址和連接埠正確，就任意替換其他欄位。

伺服器名稱、連線位址與請求目標是三個不同概念。連線位址用來找到遠端服務；TLS 伺服器名稱會參與交握時的身分驗證；請求目標則是應用程式實際存取的網域名稱。這些項目有時相同，有時不同。修改分享連結中的伺服器名稱來「修正網域」，反而可能造成交握失敗。對參數有疑問時，請先逐項比對服務提供者的原始說明。

沿著資料傳輸方向定位問題

常見請求會依序經過應用程式、本機監聽連接埠、核心路由、遠端伺服器，最後抵達目標服務。系統代理只會影響願意讀取該設定的應用程式；已進入本機代理的請求，還要由核心規則決定出口。DNS 負責將網域名稱解析為位址，可能由應用程式、作業系統或核心處理。若把這些環節全都當成單一「代理開關」，就容易在錯誤的位置反覆調整。

排查問題時，先確認故障發生在哪個環節。客戶端無法啟動，檢查執行環境與連接埠；瀏覽器沒有連上客戶端，檢查應用程式的代理設定；日誌出現交握錯誤，檢查協定參數與系統時間；只有部分網域異常，則檢查規則和解析結果。單一日誌錯誤要配合發生時間判讀，背景應用程式的失敗請求不一定與目前頁面有關。

建立可重現的基本設定

開始設定時，只使用一台已確認可用的伺服器、一種應用程式入口和一組簡單路由。先關閉不必要的自動切換，也不要同時啟用多種網路接管方式。如此每次測試只改變一個條件，結果才有判斷依據。連線成功後，記下客戶端名稱、核心選擇、監聽連接埠與路由模式；這些資訊比「昨天還能用」更有助於還原狀況。

繼續閱讀前，請先確認伺服器參數的來源、哪個程式負責啟動核心，以及測試應用程式連接哪個本機連接埠。若這三點仍不清楚，先整理來源與設定，不要急著配置複雜分流。釐清概念後，下一章會依平台選擇客戶端；之後再逐步加入訂閱管理、網域規則與虛擬網卡，每個階段都保留可還原的測試結果。

二、選擇客戶端與準備平台

桌面平台優先選用 v2rayN

Windows、macOS、Linux 桌面環境建議先從 v2rayN 開始，方便透過同一套介面了解伺服器、訂閱群組、系統代理與路由。先前往客戶端下載頁選擇平台，再確認處理器架構與安裝套件格式。平台名稱相同，不代表安裝套件可以互換；選錯架構可能導致程式無法啟動，或需要額外的相容執行環境。

Windows 桌面版採用跨平台介面，經典 WPF 版則保留傳統操作方式。初次使用可先選擇桌面版；若已習慣經典介面，也可依需求選用 WPF 版。兩種介面的版面配置不同，不要只照教學截圖找按鈕。移轉前先匯出需要保留的設定，確認新介面能匯入伺服器後，再決定是否取代原本的使用環境。

依晶片與發行版選擇安裝格式

macOS 使用者應先到系統裝置資訊確認晶片類型：Apple Silicon 對應 arm64，Intel 對應 x64。不要根據電腦外觀或購買年份猜測。安裝後也要確認程式具備正常執行所需的權限；TUN 所需權限與一般啟動不同，因此介面能開啟，不代表所有網路功能都已準備就緒。首次測試應先以系統代理建立基本基準。

Linux 使用者需要一併確認處理器架構、發行版的套件管理方式與桌面工作階段。deb 與 rpm 分屬不同套件體系，arm64 與 x64 則對應不同指令集架構。套件安裝成功後，若系統匣圖示或系統代理表現異常，請再確認桌面環境是否支援。由應用程式自行設定本機代理通常較容易驗證，不要只憑系統匣圖示是否出現來判斷核心狀態。

Android 依核心需求選擇

Android 裝置可優先考慮 v2rayNG；若使用 V2Fly 相關設定，再評估 v2flyNG。多數較新的主流裝置可選 arm64；不確定裝置架構時，可查看系統資訊，或依下載頁說明考慮通用版。不要同時啟動兩個客戶端來測試連線，它們可能會競用系統 VPN 介面，使後啟動的連線取代先前連線，讓測試結果難以判讀。

Android 客戶端透過系統 VPN 介面接管網路時，系統會顯示授權提示。這代表正在建立本機網路入口，不表示系統已確認遠端伺服器可用。還要留意省電策略、背景執行權限與依應用程式設定的代理清單。若前景使用正常、鎖定螢幕後失效，先檢查背景限制，不要馬上更換協定。不同裝置品牌的設定入口可能不同，請依權限名稱搜尋。

先整理需求再選擇，不必追求功能數量

客戶端是否合適，取決於實際需要的協定、訂閱格式、規則功能與網路入口。若只使用瀏覽器，一般本機代理通常已足夠；需要涵蓋更多應用程式時，再研究 TUN。使用 REALITY 等特定設定前，先確認所選核心能處理完整參數。介面功能多，不代表每項都要啟用；開關越多，排查範圍也越大。

更換客戶端無法直接解決伺服器本身無法使用的問題。先保留同一組參數與相同網路環境，再比較兩款客戶端的日誌與行為，結果才有參考價值。若想進一步比較管理方式，可閱讀三款客戶端功能比較。選定後就固定使用一款客戶端完成安裝，避免尚未建立基本基準就頻繁移轉設定。

三、安裝與首次執行基準

安裝至可持續寫入的資料夾

先依下載頁說明完成安裝或解壓縮，再啟動客戶端。需要解壓縮的程式，請先完整解壓到獨立資料夾，不要直接從壓縮檔預覽中執行。資料夾應允許目前使用者寫入設定與日誌，也要方便日後備份。測試時避免使用同步工具頻繁改寫的資料夾，以免設定檔被舊版本覆蓋，或多台裝置同時寫入同一份執行狀態。

首次啟動若出現執行環境提示，請依提示安裝所需元件，再重新開啟客戶端。介面正常顯示但核心無法啟動時，檢查核心程式路徑、執行權限與安全軟體的封鎖紀錄。不要直接關閉整套系統防護；先確認遭封鎖的檔案及原因。涉及系統權限的操作應盡量縮小範圍，一般代理測試不必一開始就啟用 TUN。

檢查核心與本機監聽連接埠

進入設定，確認目前核心與伺服器設定相容，再查看本機監聽位址與連接埠。本指南以 10808 作為連接埠範例，實際設定請以客戶端介面為準。有些介面會分別顯示 HTTP、SOCKS 或混合入口，有些則提供統一入口；應用程式填入的代理類型必須符合對應的監聽方式，不能只複製連接埠數字。

本機應用程式通常連線至 127.0.0.1。這個位址代表目前裝置本身；在另一台裝置填入相同位址，只會連到那台裝置自己。初次設定請維持僅本機監聽，暫時不要開放區域網路連線。日後若要供其他裝置使用，再確認監聽範圍、存取控制與防火牆規則，並了解開放連接埠會擴大可存取範圍，不只是多一個方便入口。

以最少變數完成首次測試

匯入一台已獲授權的伺服器並設為使用中，先保持 TUN 關閉。選擇自動設定系統代理後，使用會遵循系統代理設定的瀏覽器發出新請求，同時觀察客戶端日誌。瀏覽器快取與既有長連線可能仍沿用舊路徑，必要時請關閉測試分頁再重新開啟。記下測試時間，方便在日誌中找到同一批請求，不必逐行翻查所有歷史輸出。

「核心已啟動」只表示程式已進入執行狀態，不代表遠端交握成功。若頁面無法開啟，先檢查日誌中是否出現該請求；若沒有紀錄，優先排查應用程式入口；若有紀錄但連線失敗，再檢查伺服器位址、連接埠與安全層。若程式日誌顯示載入設定錯誤，應先修正錯誤，繼續切換節點通常無法改變同一份錯誤設定的結果。

區分網路權限與程式權限

系統防火牆允許程式連上網路，與允許區域網路裝置存取本機連接埠，是兩種不同方向的權限。初次使用只需滿足目前的測試路徑，不要為了排錯一次開放所有輸入規則。macOS 的安全提示、Linux 的執行權限與 Windows 的執行環境問題，也應分別處理。安裝相關注意事項可參閱首次安裝設定筆記。

連線成功後，記下程式所在資料夾、設定儲存位置、目前使用的核心、監聽連接埠與測試應用程式。接著正常結束客戶端，確認系統代理是否依預期清除，再重新啟動並確認設定仍保留。若結束程式後瀏覽器仍連到本機連接埠，請檢查系統代理是否殘留。完成啟動、連線與結束程式的整套測試，才算建立可重現的安裝基準；之後再加入訂閱與規則。

四、匯入訂閱與管理伺服器

分清訂閱網址與分享連結

訂閱網址用來下載並更新一組伺服器，分享連結通常則描述單一伺服器。以 vmess://、vless://、trojan://、ss:// 開頭的內容，應從分享連結匯入入口匯入；訂閱網址則應填入訂閱群組的網址欄位。兩者填反可能導致解析失敗，也可能只匯入文字，沒有建立可用的伺服器。

訂閱網址通常包含個人專屬憑證，應視為敏感資訊妥善保存，不要放進公開截圖或聊天紀錄。複製時檢查開頭、結尾與換行，避免連同說明文字、標點或空格一起複製。若網址來自 QR Code，也要先確認客戶端辨識出的內容類型。不要把訂閱交給來源不明的轉換服務，轉換過程可能讓第三方讀取網址與伺服器參數。

建立群組後再更新

在 v2rayN 的訂閱群組管理中新增群組，填入容易辨識的名稱與訂閱網址，儲存後更新該群組。首次更新時請留意結果提示，並確認伺服器清單確實有變化。群組名稱只供本機管理，不會改變遠端連線。不同來源請分開保存，方便日後找出特定來源的更新問題，也能避免手動新增的伺服器混在訂閱項目中而遭覆蓋。

更新失敗時，先分辨是下載失敗還是解析失敗。下載失敗要檢查目前網路是否能連上網址、是否需要透過已可用的代理、憑證是否正常，以及系統時間是否正確；解析失敗則要確認回傳內容是否為客戶端支援的訂閱格式。帳號頁面、錯誤提示頁與過期回應都可能以一般文字回傳；顯示「下載完成」不代表已成功匯入。

了解更新方式與影響範圍

部分客戶端提供直接更新與透過代理更新兩種方式。首次設定時若沒有可用伺服器，依賴代理的更新可能形成循環；建立可用連線後，才有條件透過代理存取訂閱網址。選擇前先確認更新流量會經過哪條路徑，不要在同一個錯誤入口上反覆點選。若服務提供者要求特定格式，請使用明確支援該格式的客戶端訂閱入口。

更新訂閱可能會取代該群組中的項目，因此不要直接修改訂閱節點後，期待變更能長期保留。若確實需要本機調整，可複製到獨立的手動群組，並註明修改原因。更新前後確認目前使用的伺服器仍存在，尤其是項目名稱或識別資訊變動時。客戶端顯示舊名稱，不足以證明目前連線仍使用同一個位址；請開啟詳細資訊核對。

確認匯入後的重要欄位

分享連結成功解析後，依序檢查協定、位址、連接埠、使用者識別資訊或密碼、傳輸方式與安全層。WebSocket 可能還涉及路徑與 Host，gRPC 涉及服務名稱，REALITY 則涉及公鑰、短識別碼與伺服器名稱等參數。這些欄位應與來源一致，不要把其他節點的設定整批套用。別名可以自行整理，連線參數則必須保留原有意義。

更新完成後，先測試目前使用的伺服器，再安排自動更新。自動更新頻率應符合來源說明，更新過於頻繁並不會提高穩定性。長期不使用的群組可停用自動更新，同時保留必要紀錄。若只有某個群組異常、其他群組正常，先追查該訂閱來源；常見故障情況可前往說明中心查閱，避免把局部問題擴大成整套重裝。

五、系統代理與流量入口

系統代理不會接管整台裝置

系統代理會提供本機代理位址給應用程式，是否採用則由應用程式自行決定。瀏覽器通常會讀取系統設定，部分工具有自己的代理選項，也有應用程式完全忽略系統代理。因此，切換「自動設定系統代理」後，不能只看單一應用程式的結果，就認定所有流量都已進入核心。驗證入口時，請使用已知會遵循系統代理設定的測試應用程式。

「清除系統代理」通常會移除目前系統中的代理設定；「不變更系統代理」則會保留既有狀態，兩者並不相同。若系統原本已有其他代理設定，使用前先記錄，避免切換後無法還原。客戶端結束執行後，若系統仍保留本機代理位址，應用程式可能持續連到已關閉的連接埠，造成客戶端結束後網路反而異常。

路由模式作用於入口之後

全域、繞過中國大陸、直連等路由模式，決定已進入核心的請求要使用哪個出口，與系統代理屬於不同層級。將路由切換為全域，不會自動接管忽略系統代理的應用程式；將系統代理設為自動，也不代表所有請求都會經由遠端。先確認請求有進入客戶端，再分析出口選擇，才能正確判斷切換模式帶來的變化。

全域代理適合用來暫時確認遠端連線是否正常，但仍要檢查目前預設是否保留私有網路等例外。繞過中國大陸通常會依據網域名稱與 IP 資料集，讓相應目標使用直連出口；直連模式則會讓進入核心的流量優先直接連線。不同客戶端的預設規則可能不同，模式名稱只是入口，請開啟規則內容確認實際作用，不要只憑名稱推斷完整行為。

為個別應用程式設定代理

應用程式有獨立代理選項時，依客戶端實際監聽方式選擇 HTTP 或 SOCKS，位址填入本機迴圈位址，連接埠則填入對應的本機連接埠。不要將遠端伺服器位址直接填進一般代理欄位；遠端協定通常需要由核心處理。應用程式也可能提供「透過代理解析網域」之類的選項，這會影響網域由哪一端解析，需與後續路由策略一併考量。

每次測試只保留一個明確的應用程式代理來源。瀏覽器擴充功能、系統代理與應用程式內部設定同時存在時，先確認優先順序，避免以為已修改系統代理，實際請求卻仍經由擴充功能儲存的舊連接埠。切換後關閉舊連線再測試，並記錄哪種設定生效。長期使用時也應減少重複入口；設定來源越少，還原與移轉越容易。

依使用情境選擇設定組合

一般瀏覽可從自動設定系統代理搭配明確的分流規則開始；單一開發工具可使用應用程式的獨立代理；若需要接管更多不遵循系統代理的程式，再考慮 TUN。區域網路裝置存取服務另有監聽範圍與防火牆要求，不是系統代理開關本身能處理的功能。每增加一種入口，都應單獨測試，確認新入口沒有改變既有流量預期使用的出口。

若瀏覽器正常、其他應用程式失敗，先確認失敗的應用程式是否有連上客戶端，不要馬上調整網域規則。若應用程式都有進入客戶端，只有特定類型的目標失敗，再檢查路由、解析與遠端連線狀態。更多設定組合範例請參閱系統代理與路由模式的差異。下一章會在入口已確認的前提下，進一步說明規則順序與網域策略。

六、路由分流與 DNS 策略

由上而下理解規則比對

路由規則描述哪些請求應交給哪個出站。常見條件包括網域名稱、目標 IP、連接埠與網路類型等；同一規則中的不同條件通常必須同時符合，而同類候選項則依各自語意判斷。核心會依序尋找符合的規則，命中後選擇對應出站，因此特定例外通常應排在範圍較廣的規則之前。若沒有符合規則，接著要檢查預設出站與客戶端產生的設定。

先寫下預期行為，再決定比對條件。例如要讓某個內部網域直連，應先確認客戶端取得的是網域名稱還是只有 IP，再選擇網域規則或位址規則。只讓一個公開網域直連，不一定涵蓋它載入的所有資源，因為頁面也可能請求其他網域。請依實際日誌逐步補充規則，不要一看到單一失敗，就把大範圍目標全部改用同一出口。

網域策略會決定何時嘗試解析

AsIs 著重依現有目標資訊比對，不為路由主動增加網域解析；IPIfNonMatch 會在網域未符合相關規則時嘗試解析位址，並繼續比對 IP 條件；IPOnDemand 則會在比對需要 IP 的規則時嘗試解析。實際行為應依所選核心的實作方式判斷。調整網域策略主要會改變路由判斷流程，不等於取代所有應用程式使用的系統 DNS。

geosite:cn 用來選取網域資料集，geoip:cn 用來選取位址資料集，兩者不能互相取代。資料檔是否存在、內容是否符合目前需求，都會影響比對結果。網域解析出的位址可能隨網路與時間改變，不能只憑單次位址歸屬，就認定路由永遠正確。更新資料後也應重新驗證重要網域，不要假設規則行為完全不變。

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

上例是路由片段，不是完整的執行設定。它需要可用的資料檔與名為 direct 的直連出站，也沒有定義其他請求的最終出口。圖形化客戶端可能會產生不同的標籤名稱，請在對應規則介面中設定，不要整段覆蓋客戶端設定。第一條規則處理私有位址，第二條處理網域集合；其他流量仍由其餘規則與預設出站決定。

區分 DNS 問題與連線問題

網域名稱無法解析時，連線通常還未進入目標服務的交握階段；若解析成功但連線逾時，可能與位址可達性、路由出口或遠端狀態有關。先查看日誌顯示的錯誤階段，再決定要調整哪個設定。有些應用程式會自行解析網域，進入代理時只傳送位址；在這種情況下，單純新增網域規則未必有效。開啟流量探測有時能補充目標資訊，但並非所有協定都能辨識。

流量探測會嘗試從連線資訊辨識網域名稱；辨識結果是否用於路由、是否會改變目標位址，取決於具體設定。不要把它當成能自動修復所有 DNS 問題的開關。若需要存取區域網路名稱，也應確認本機解析流程沒有被不適用的遠端解析取代。公司或校園網路可能使用內部網域，修改前請先記下原有解析方式與存取需求。

小幅調整並逐項回歸測試

每次只新增一條規則，測試一個應該符合的目標與一個不應符合的目標，再確認出口是否符合預期。驗證通過後才擴大範圍，並記錄規則用途。發生異常時，先撤回最近的變更，回到最小規則集，再逐條新增。不要同時切換 DNS、網域策略與伺服器；否則即使連線恢復，也無法確認是哪項變更生效，日後維護仍會失去依據。

七、TUN 模式與系統網路接管

虛擬網卡用來處理流量入口

TUN 透過虛擬網路介面接收系統依路由送來的 IP 封包，再交由相關元件處理。它主要是擴充流量進入代理處理流程的方式，不會自動修復伺服器參數、訂閱或遠端網路。啟用前，先用一般代理確認同一台伺服器可正常使用。若基本連線尚未建立，加入虛擬網卡只會同時增加權限、系統路由與 DNS 等變數，讓故障更難定位。

TUN 不代表所有請求一定會經由遠端代理。進入接管範圍的流量仍可能依規則選擇直連、代理或其他動作；部分流量也可能因系統路由或應用程式綁定網卡等原因，未進入接管範圍。介面顯示已啟用只是其中一項狀態，還要確認虛擬介面是否建立成功、相關路由是否生效，以及測試應用程式的請求是否出現在日誌中。

啟用前先排除介面衝突

先關閉其他正在接管網路的 VPN 連線或重複的 TUN 執行個體，確認一般網路正常後，儲存目前設定。依客戶端提示授予必要權限，啟動後查看日誌是否出現驅動程式、介面建立、路由寫入或權限錯誤。不要只是不斷點選開關等待恢復。若啟動失敗，應先處理最早出現的明確錯誤；之後的連線逾時可能只是介面未建立所造成的連帶結果。

遠端伺服器連線必須保留可到達的出口，不能被路由再次送回同一個接管入口，形成迴圈。客戶端通常會處理必要的路由安排，但多張網卡、其他網路工具或手動路由都可能改變結果。啟用後若立即完全無法連網，先關閉 TUN 以恢復基本狀態，再檢查預設路由與衝突工具；不要在斷網時繼續大量更新規則與訂閱。

分別驗證 DNS、UDP 與區域網路

啟用 TUN 後，先測試一般網頁，再檢查依賴 UDP 的實際應用程式，並確認路由器管理頁、印表機與內部服務是否可用。網頁能開啟只代表部分路徑正常，不能推論所有協定都沒問題。UDP 能否轉送，取決於客戶端接管方式、核心、遠端協定與伺服器設定。測試失敗時，應沿同一條連線路徑逐段檢查，不要把所有問題都歸因於系統權限。

DNS 接管可能改變原本的解析路徑，因此應比較啟用前後的網域解析結果。若公開網域正常、內部名稱失效，優先檢查本機 DNS 與區域網路例外；若只有特定位址範圍無法連線，再檢查私有位址規則與路由。調整 MTU 應有分片或特定傳輸異常的依據；隨意套用較小數值可能掩蓋真正問題，也可能影響其他連線效率。

為桌面與 Android 分別準備還原方式

桌面客戶端的 TUN 可能會呼叫額外的網路元件，實際功能取決於客戶端的封裝與實作，不能假設所有核心都有相同的原生介面。Android 客戶端使用系統 VPN 介面時，也要檢查依應用程式設定的清單與背景限制。若某個應用程式被排除在清單外，或客戶端遭系統暫停，都可能造成部分功能失效；處理方式與遠端伺服器故障不同。

電腦從睡眠喚醒、切換 Wi-Fi 或接上有線網卡後，都應重新確認網路接管狀態。舊介面或解析狀態可能暫時保留；正常停止並重新啟動客戶端，有助於重新建立網路環境，但應先記錄異常，避免失去線索。若每次切換網路都遇到同一問題，請整理網路類型、觸發順序、介面狀態與相關日誌，再前往說明中心依症狀查找；不要長期依賴強制結束程序。

八、日常維護與故障排查

分別維護程式、設定與訂閱

日常維護有三種彼此獨立的項目：客戶端及其網路元件、使用者儲存的設定，以及遠端訂閱內容。更新客戶端不一定會更新訂閱；重新整理訂閱也不會自動改變本機路由規則。開始維護前先確認這次要解決的問題，只更新相關項目。若一次同時更換客戶端、核心與規則，即使發生異常，也很難判斷是哪個環節造成變化。

更新程式前先匯出必要設定，並確認備份包含哪些內容。有些匯出功能只會儲存伺服器資訊，不一定包含路由、訂閱群組與介面設定；複製整個執行資料夾，也不一定適合跨平台還原。備份後請確認對應的匯入功能能辨識檔案。備份可能包含帳號資訊與訂閱憑證，儲存位置應設有適當的存取限制，不要直接放在公開共用資料夾。

建立固定的檢查順序

完全無法連線時，先停止網路接管並確認基本網路，再檢查客戶端程序與核心狀態，接著確認應用程式入口、目前使用的伺服器、交握情況與目標存取。只有部分應用程式異常時，先比較它們是否使用相同入口；只有部分網域異常時，再著重檢查路由與 DNS。這個順序依照環節相依性逐步排查，避免上游尚未正常，就先修改下游規則，造成更多難以解釋的變化。

日誌應針對一次明確操作收集。記下測試時間、應用程式、目標類型與當時使用的模式，清除無關的舊輸出後再重現問題。遇到設定解析錯誤，先檢查相關欄位與核心相容性；遇到驗證或交握錯誤，核對參數與系統時間；遇到逾時，再檢查連線位址、出口與網路環境。光憑「逾時」兩個字，無法判定伺服器永久失效或某種協定不適用。

測試指標應符合實際用途

延遲通常反映特定探測的往返時間，速度測試則反映特定連線條件下的資料傳輸狀況，兩者不能互相取代。某台伺服器的探測結果不錯，也可能因目標服務、併發數或時段變化而不適合目前用途。日常驗證應包含實際需要使用的應用程式，並控制測試次數。大量測試本身會產生連線與流量，也可能干擾正在進行的下載或會議。

系統時間錯誤可能影響安全交握；電腦從睡眠喚醒後，也應確認時間與網路狀態。若切換到另一個網路後立即恢復，表示原本的網路路徑值得進一步檢查，但仍不能直接認定是某一台設備造成。可保留相同客戶端與參數，只更換網路進行比較；也可以維持網路不變，只更換一台已確認可用的伺服器。每次對照只改變一個主要條件。

分享診斷資訊前先移除敏感欄位

尋求協助時，可先提供客戶端名稱、作業系統平台、核心選擇、使用模式與完整錯誤階段，讓問題開始有方向。分享截圖前，請遮蔽訂閱網址、使用者識別資訊、密碼、公鑰相關資訊，以及不適合公開的伺服器細節。不要直接上傳整個設定資料夾。日誌也可能包含目標網域與本機路徑，分享前請檢查上下文，保留足夠的錯誤資訊，同時減少無關的個人資料。

設定長期穩定後，簡單記下最近修改的項目、修改原因、驗證方式與還原方法。發生異常時，先回復到最近一次已知可用的狀態，不要反覆匯入相同訂閱或重裝程式。常見新手疑問可參考新手連線問題速查；若還原後仍能重現問題，再沿著入口、解析、路由與遠端連線逐層排查。

九、進階設定與驗證流程

先檢視產生的設定，再嘗試自訂

熟悉圖形介面後，可透過客戶端提供的檢視或匯出設定功能，了解產生的內容。重點查看入站、出站、路由、DNS 與日誌等部分，觀察介面中的某個選項如何對應到設定欄位。先閱讀，不急著修改。客戶端可能會在啟動時重新產生檔案，直接編輯執行中的設定不一定能長期保留，也可能在下次切換伺服器或更新訂閱時被覆蓋。

自訂設定適合用來處理介面尚未涵蓋的明確需求，不適合取代對基本連線流程的理解。開始前先儲存原始設定，確認所選核心接受相應語法，再以最小幅度的修改進行驗證。出站標籤必須與規則引用一致，連接埠不能與現有入口衝突；設定片段也不能脫離所依賴的資料與元件獨立執行。啟動失敗時，先還原至最後一份可用設定，不要繼續疊加欄位。

透過小型實驗理解適用範圍

以下範例是僅供本機 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": {}
    }
  ]
}

這項實驗先確認應用程式能否連上指定連接埠，再觀察直連出口是否正常。遠端驗證與安全交握暫時不在測試範圍內，因此適合用來說明本機入口問題，卻不能證明遠端伺服器可用。測試結束後請還原原有設定，避免把暫時的直連環境誤當成日常代理環境。範例的價值在於辨識變數，而不是把所有範例都複製進愈來愈大的設定檔。

依需求學習協定與傳輸方式

學習協定時，可先了解哪些欄位必須一致：使用者身分、傳輸方式、安全層與選用的擴充功能。接著再認識這些欄位參與哪個階段，最後才研究效能。REALITY 與 XTLS Vision 是特定技術組合，能否使用取決於客戶端核心與伺服器設定，不能只改一個下拉選項就完成移轉。原理說明請參閱REALITY 與 XTLS Vision 筆記。

比較傳輸方式時，應盡量維持相同的網路、伺服器資源、測試目標與時間條件。不同目標服務的回應差異，不能直接歸因於協定名稱。連線重用、UDP 處理與 DNS 策略也可能影響使用體驗，應逐項驗證。若沒有實際需求，請保留相容且穩定的設定；不要為了追求理論上的優勢而同時更換多個環節，最後卻無法判斷效能變化的來源。

將進階設定整理成可維護的配置

完成一項進階設定後，記下它的用途、前置條件、預期行為與還原方法。例如新增應用程式分流時，記錄比對條件與預設出口；調整網域策略時，記錄受影響的解析路徑；啟用 TUN 時，記錄區域網路存取與網路切換的測試結果。紀錄應描述實際行為，不要只保存介面截圖；介面改版後，截圖可能無法說明設定背後的邏輯。

最後的回歸測試應涵蓋程式重新啟動、訂閱更新、網路切換、睡眠喚醒與正常結束，確認設定不依賴偶然保留的連線狀態。若某項功能只有在特定順序下才能運作，就應繼續檢查相依關係，而不是把操作順序當成永久解法。能說明單一請求的入口、解析、規則比對與出口，並在故障時還原基本狀態，才算真正完成從入門到進階的學習流程。

後續可依問題查閱對應章節：重新安裝請看第三章，伺服器更新請看第四章，應用程式未接入請看第五章，目標分流異常請看第六章，虛擬網卡問題請看第七章。若要重新走過最精簡的連線流程，請回到快速使用指南；若需更換平台或安裝格式，再前往下載頁選擇相應客戶端，讓下載、設定與診斷各有清楚分工。